commit da1785bfc8e5e84b51f396d9a5c31d4b5d5b22f6 Author: Greg Kroah-Hartman Date: Wed Mar 23 13:17:22 2011 -0700 Linux 2.6.32.34 commit d79a1f96cc0d512e8198d463d5ee7b3ebf06f023 Author: Vivien Didelot Date: Mon Mar 21 17:59:35 2011 +0100 hwmon: (sht15) Fix integer overflow in humidity calculation commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream. An integer overflow occurs in the calculation of RHlinear when the relative humidity is greater than around 30%. The consequence is a subtle (but noticeable) error in the resulting humidity measurement. Signed-off-by: Vivien Didelot Signed-off-by: Jean Delvare Cc: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d3dd00569dfcc9fa732f16e832ddcb75f1e52186 Author: Alexander van Heukelum Date: Fri Mar 11 21:59:38 2011 +0100 x86, binutils, xen: Fix another wrong size directive commit 371c394af27ab7d1e58a66bc19d9f1f3ac1f67b4 upstream. The latest binutils (2.21.0.20110302/Ubuntu) breaks the build yet another time, under CONFIG_XEN=y due to a .size directive that refers to a slightly differently named (hence, to the now very strict and unforgiving assembler, non-existent) symbol. [ mingo: This unnecessary build breakage caused by new binutils version 2.21 gets escallated back several kernel releases spanning several years of Linux history, affecting over 130,000 upstream kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially affecting all major Linux distro kernel configs). Git annotate tells us that this slight debug symbol code mismatch bug has been introduced in 2008 in commit 3d75e1b8: 3d75e1b8 (Jeremy Fitzhardinge 2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs) The 'bug' is just a slight assymetry in ENTRY()/END() debug-symbols sequences, with lots of assembly code between the ENTRY() and the END(): ENTRY(xen_do_hypervisor_callback) # do_hypervisor_callback(struct *pt_regs) ... END(do_hypervisor_callback) Human reviewers almost never catch such small mismatches, and binutils never even warned about it either. This new binutils version thus breaks the Xen build on all upstream kernels since v2.6.27, out of the blue. This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels impossible on such binutils, for a bisection window of over hundred thousand historic commits. (!) This is a major fail on the side of binutils and binutils needs to turn this show-stopper build failure into a warning ASAP. ] Signed-off-by: Alexander van Heukelum Cc: Jeremy Fitzhardinge Cc: Jan Beulich Cc: H.J. Lu Cc: Linus Torvalds Cc: Andrew Morton Cc: "H. Peter Anvin" Cc: Kees Cook LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2006e74de08d502eda1226adbb1fd5d7b210d74e Author: Milton Miller Date: Sat Jun 12 03:48:47 2010 +0000 powerpc: rtas_flash needs to use rtas_data_buf commit bd2b64a12bf55bec0d1b949e3dca3f8863409646 upstream. When trying to flash a machine via the update_flash command, Anton received the following error: Restarting system. FLASH: kernel bug...flash list header addr above 4GB The code in question has a comment that the flash list should be in the kernel data and therefore under 4GB: /* NOTE: the "first" block list is a global var with no data * blocks in the kernel data segment. We do this because * we want to ensure this block_list addr is under 4GB. */ Unfortunately the Kconfig option is marked tristate which means the variable may not be in the kernel data and could be above 4GB. Instead of relying on the data segment being below 4GB, use the static data buffer allocated by the kernel for use by rtas. Since we don't use the header struct directly anymore, convert it to a simple pointer. Reported-By: Anton Blanchard Signed-Off-By: Milton Miller Tested-By: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh Babulal Signed-off-by: Greg Kroah-Hartman commit 4d4d502715479044f02ae7464474bbb615b2d158 Author: Michael Neuling Date: Thu May 13 19:40:11 2010 +0000 powerpc/kdump: Fix race in kdump shutdown commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream. When we are crashing, the crashing/primary CPU IPIs the secondaries to turn off IRQs, go into real mode and wait in kexec_wait. While this is happening, the primary tears down all the MMU maps. Unfortunately the primary doesn't check to make sure the secondaries have entered real mode before doing this. On PHYP machines, the secondaries can take a long time shutting down the IRQ controller as RTAS calls are need. These RTAS calls need to be serialised which resilts in the secondaries contending in lock_rtas() and hence taking a long time to shut down. We've hit this on large POWER7 machines, where some secondaries are still waiting in lock_rtas(), when the primary tears down the HPTEs. This patch makes sure all secondaries are in real mode before the primary tears down the MMU. It uses the new kexec_state entry in the paca. It times out if the secondaries don't reach real mode after 10sec. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh Babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman commit 5a2ada86a6766f4b3ebc6534d127eb0d9043b03d Author: Michael Neuling Date: Thu May 13 19:40:11 2010 +0000 powerpc/kexec: Fix race in kexec shutdown commit 1fc711f7ffb01089efc58042cfdbac8573d1b59a upstream. In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets the hw_cpu_id() to -1. The primary does this while leaving IRQs on which means the primary can take a timer interrupt which can lead to the IPIing one of the secondary CPUs (say, for a scheduler re-balance) but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU -1... Kaboom! We are hitting this case regularly on POWER7 machines. There is also a second race, where the primary will tear down the MMU mappings before knowing the secondaries have entered real mode. Also, the secondaries are clearing out any pending IPIs before guaranteeing that no more will be received. This changes kexec_prepare_cpus() so that we turn off IRQs in the primary CPU much earlier. It adds a paca flag to say that the secondaries have entered the kexec_smp_down() IPI and turned off IRQs, rather than overloading hw_cpu_id with -1. This new paca flag is again used to in indicate when the secondaries has entered real mode. It also ensures that all CPUs have their IRQs off before we clear out any pending IPI requests (in kexec_cpu_down()) to ensure there are no trailing IPIs left unacknowledged. Signed-off-by: Michael Neuling Signed-off-by: Greg Kroah-Hartman Signed-off-by: Kamalesh Babulal cc: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt commit 468b2ed1cf894718e6dd7fca66ba7784df92c12a Author: Stefan Nilsson XK Date: Tue Mar 1 14:41:04 2011 +0100 mmc: sdio: remember new card RCA when redetecting card commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream. During redetection of a SDIO card, a request for a new card RCA was submitted to the card, but was then overwritten by the old RCA. This caused the card to be deselected instead of selected when using the incorrect RCA. This bug's been present since the "oldcard" handling was introduced in 2.6.32. Signed-off-by: Stefan Nilsson XK Reviewed-by: Ulf Hansson Reviewed-by: Pawel Wieczorkiewicz Signed-off-by: Linus Walleij Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit 15e5405e7d7b9ed7665df3954446a47d251f0c47 Author: Roman Fietze Date: Sun Mar 20 14:50:52 2011 +0100 i2c: Fix typo in instantiating-devices document commit 6ced9e6b3901af4ab6ac0a11231402c888286ea6 upstream. The struct i2c_board_info member holding the name is "type", not "name". Signed-off-by: Roman Fietze Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 413064f97a8b21ccfd0110544acb60ab8920d751 Author: Thomas Gleixner Date: Mon Feb 7 19:28:01 2011 +0100 fix per-cpu flag problem in the cpu affinity checkers commit 9804c9eaeacfe78651052c5ddff31099f60ef78c upstream. The CHECK_IRQ_PER_CPU is wrong, it should be checking irq_to_desc(irq)->status not just irq. Signed-off-by: Thomas Gleixner Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 02c85f07011cb958b278f51ad2b8c9d43f177e7b Author: Milton Miller Date: Tue Mar 15 13:27:17 2011 -0600 smp_call_function_many: handle concurrent clearing of mask commit 723aae25d5cdb09962901d36d526b44d4be1051c upstream. Mike Galbraith reported finding a lockup ("perma-spin bug") where the cpumask passed to smp_call_function_many was cleared by other cpu(s) while a cpu was preparing its call_data block, resulting in no cpu to clear the last ref and unlock the block. Having cpus clear their bit asynchronously could be useful on a mask of cpus that might have a translation context, or cpus that need a push to complete an rcu window. Instead of adding a BUG_ON and requiring yet another cpumask copy, just detect the race and handle it. Note: arch_send_call_function_ipi_mask must still handle an empty cpumask because the data block is globally visible before the that arch callback is made. And (obviously) there are no guarantees to which cpus are notified if the mask is changed during the call; only cpus that were online and had their mask bit set during the whole call are guaranteed to be called. Reported-by: Mike Galbraith Reported-by: Jan Beulich Acked-by: Jan Beulich Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 907ca374f80ef1b95426cbe21299756574a79149 Author: Tilman Schmidt Date: Mon Jul 5 14:18:27 2010 +0000 isdn: avoid calling tty_ldisc_flush() in atomic context commit bc10f96757bd6ab3721510df8defa8f21c32f974 upstream. Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER branch of isdn_tty_modem_result(), as already proposed in commit 00409bb045887ec5e7b9e351bc080c38ab6bfd33. This avoids a "sleeping function called from invalid context" BUG when the hardware driver calls the statcallb() callback with command==ISDN_STAT_DHUP in atomic context, which in turn calls isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there, tty_ldisc_flush() which may sleep. Signed-off-by: Tilman Schmidt Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ba456fd7ec1bdc31a4ad4a6bd02802dcaa730a33 Author: Shaohua Li Date: Wed Mar 16 11:37:29 2011 +0800 x86: Flush TLB if PGD entry is changed in i386 PAE mode commit 4981d01eada5354d81c8929d5b2836829ba3df7b upstream. According to intel CPU manual, every time PGD entry is changed in i386 PAE mode, we need do a full TLB flush. Current code follows this and there is comment for this too in the code. But current code misses the multi-threaded case. A changed page table might be used by several CPUs, every such CPU should flush TLB. Usually this isn't a problem, because we prepopulate all PGD entries at process fork. But when the process does munmap and follows new mmap, this issue will be triggered. When it happens, some CPUs keep doing page faults: http://marc.info/?l=linux-kernel&m=129915020508238&w=2 Reported-by: Yasunori Goto Tested-by: Yasunori Goto Reviewed-by: Rik van Riel Signed-off-by: Shaohua Li Cc: Mallick Asit K Cc: Linus Torvalds Cc: Andrew Morton Cc: linux-mm LKML-Reference: <1300246649.2337.95.camel@sli10-conroe> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b70b2521c983c8e5221f8cf9d66ef177e0480e19 Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: add missing ordering commit 45a5791920ae643eafc02e2eedef1a58e341b736 upstream. Paul McKenney's review pointed out two problems with the barriers in the 2.6.38 update to the smp call function many code. First, a barrier that would force the func and info members of data to be visible before their consumption in the interrupt handler was missing. This can be solved by adding a smp_wmb between setting the func and info members and setting setting the cpumask; this will pair with the existing and required smp_rmb ordering the cpumask read before the read of refs. This placement avoids the need a second smp_rmb in the interrupt handler which would be executed on each of the N cpus executing the call request. (I was thinking this barrier was present but was not). Second, the previous write to refs (establishing the zero that we the interrupt handler was testing from all cpus) was performed by a third party cpu. This would invoke transitivity which, as a recient or concurrent addition to memory-barriers.txt now explicitly states, would require a full smp_mb(). However, we know the cpumask will only be set by one cpu (the data owner) and any preivous iteration of the mask would have cleared by the reading cpu. By redundantly writing refs to 0 on the owning cpu before the smp_wmb, the write to refs will follow the same path as the writes that set the cpumask, which in turn allows us to keep the barrier in the interrupt handler a smp_rmb instead of promoting it to a smp_mb (which will be be executed by N cpus for each of the possible M elements on the list). I moved and expanded the comment about our (ab)use of the rcu list primitives for the concurrent walk earlier into this function. I considered moving the first two paragraphs to the queue list head and lock, but felt it would have been too disconected from the code. Cc: Paul McKinney Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fb29684a7d574f3303c53b1dd396187e8ca0bfcb Author: Milton Miller Date: Tue Mar 15 13:27:16 2011 -0600 call_function_many: fix list delete vs add race commit e6cd1e07a185d5f9b0aa75e020df02d3c1c44940 upstream. Peter pointed out there was nothing preventing the list_del_rcu in smp_call_function_interrupt from running before the list_add_rcu in smp_call_function_many. Fix this by not setting refs until we have gotten the lock for the list. Take advantage of the wmb in list_add_rcu to save an explicit additional one. I tried to force this race with a udelay before the lock & list_add and by mixing all 64 online cpus with just 3 random cpus in the mask, but was unsuccessful. Still, inspection shows a valid race, and the fix is a extension of the existing protection window in the current code. Reported-by: Peter Zijlstra Signed-off-by: Milton Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b22f15b8d6a2b098366d44b9232733e60166d302 Author: Eric Sandeen Date: Fri Mar 4 16:04:08 2011 -0600 ext3: Always set dx_node's fake_dirent explicitly. commit d7433142b63d727b5a217c37b1a1468b116a9771 upstream. (crossport of 1f7bebb9e911d870fa8f997ddff838e82b5715ea by Andreas Schlick ) When ext3_dx_add_entry() has to split an index node, it has to ensure that name_len of dx_node's fake_dirent is also zero, because otherwise e2fsck won't recognise it as an intermediate htree node and consider the htree to be corrupted. Signed-off-by: Eric Sandeen Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 3a579b0ce569d5738120d74bdcc8f76b740c97c4 Author: Anton Blanchard Date: Wed Mar 9 14:38:42 2011 +1100 perf, powerpc: Handle events that raise an exception without overflowing commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 upstream. Events on POWER7 can roll back if a speculative event doesn't eventually complete. Unfortunately in some rare cases they will raise a performance monitor exception. We need to catch this to ensure we reset the PMC. In all cases the PMC will be 256 or less cycles from overflow. Signed-off-by: Anton Blanchard Signed-off-by: Peter Zijlstra LKML-Reference: <20110309143842.6c22845e@kryten> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6f197b73304b3bd3d5a43b931383a5331d6b2987 Author: Frederic Weisbecker Date: Mon Mar 7 21:27:09 2011 +0100 perf: Handle stopped state with tracepoints commit a0f7d0f7fc02465bb9758501f611f63381792996 upstream. We toggle the state from start and stop callbacks but actually don't check it when the event triggers. Do it so that these callbacks actually work. Signed-off-by: Frederic Weisbecker Cc: Arnaldo Carvalho de Melo Cc: Paul Mackerras Cc: Stephane Eranian Signed-off-by: Peter Zijlstra LKML-Reference: <1299529629-18280-2-git-send-email-fweisbec@gmail.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7762386ff2f35364d13703579503e4b9f130cd75 Author: Trond Myklebust Date: Tue Mar 15 19:56:30 2011 -0400 SUNRPC: Ensure we always run the tk_callback before tk_action commit e020c6800c9621a77223bf2c1ff68180e41e8ebf upstream. This fixes a race in which the task->tk_callback() puts the rpc_task to sleep, setting a new callback. Under certain circumstances, the current code may end up executing the task->tk_action before it gets round to the callback. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit dc655ad7c9075c577492d8b53c23c9203c5928ae Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:58 2011 +0100 ALSA: ctxfi - Clear input settings before initialization commit efed5f26664f93991c929d5bb343e65f900d72bc upstream. Clear input settings before initialization. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6e81878cf3d41708bdc4710cfef32873b229d698 Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:57 2011 +0100 ALSA: ctxfi - Fix SPDIF status retrieval commit f164753a263bfd2daaf3e0273b179de7e099c57d upstream. SDPIF status retrieval always returned the default settings instead of the actual ones. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0d2faa172d18223c5f43a962fbe9731446fe73a4 Author: Przemyslaw Bruski Date: Sun Mar 13 16:18:56 2011 +0100 ALSA: ctxfi - Fix incorrect SPDIF status bit mask commit 4c1847e884efddcc3ede371f7839e5e65b25c34d upstream. SPDIF status mask creation was incorrect. Signed-off-by: Przemyslaw Bruski Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 13ffe47637ef65ec464fc77d9403f9872fbab4b4 Author: Ben Hutchings Date: Thu Jan 13 19:47:56 2011 +0000 PCI: sysfs: Fix failure path for addition of "vpd" attribute commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream. Commit 280c73d ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 85dcbf8c826a7fc14c7f5a81c2f8fd09dcf2ee0f Author: Jiri Slaby Date: Mon Feb 28 10:45:10 2011 +0100 PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream. Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740 Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 01526e47d9bd398502261c8225b898dfe423a321 Author: Jiri Slaby Date: Mon Feb 28 10:45:09 2011 +0100 PCI: add more checking to ICH region quirks commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream. Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by: Jiri Slaby Cc: Bjorn Helgaas Cc: "David S. Miller" Cc: Thomas Renninger Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 123079517faa3e2accc731f0f8b9f89bb9b033d6 Author: Brandeburg, Jesse Date: Mon Feb 14 09:05:02 2011 -0800 PCI: remove quirk for pre-production systems commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream. Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944 Author: Yu Zhao Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdf Signed-off-by: Yu Zhao Signed-off-by: Jesse Barnes This quirk was added before SR-IOV was in production and now all machines that originally had this issue alreayd have bios updates to correct the issue. The quirk itself is no longer needed and in fact causes bugs if run. Remove it. Signed-off-by: Jesse Brandeburg CC: Yu Zhao CC: Jesse Barnes Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit fa958081e1b2038ce669e2db878ee8df6a63b677 Author: Vitaliy Kulikov Date: Wed Mar 9 19:47:43 2011 -0600 ALSA: hda - fix digital mic selection in mixer on 92HD8X codecs commit 094a42452abd5564429045e210281c6d22e67fca upstream. When the mux for digital mic is different from the mux for other mics, the current auto-parser doesn't handle them in a right way but provides only one mic. This patch fixes the issue. Signed-off-by: Vitaliy Kulikov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dd152cbc245edb3c3f6df1d01a8794195bdfb2de Author: Sarah Sharp Date: Wed Feb 23 18:12:29 2011 -0800 xhci: Fix cycle bit calculation during stall handling. commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream. When an endpoint stalls, we need to update the xHCI host's internal dequeue pointer to move it past the stalled transfer. This includes updating the cycle bit (TRB ownership bit) if we have moved the dequeue pointer past a link TRB with the toggle cycle bit set. When we're trying to find the new dequeue segment, find_trb_seg() is supposed to keep track of whether we've passed any link TRBs with the toggle cycle bit set. However, this while loop's body while (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) { Will never get executed if the ring only contains one segment. find_trb_seg() will return immediately, without updating the new cycle bit. Since find_trb_seg() has no idea where in the segment the TD that stalled was, make the caller, xhci_find_new_dequeue_state(), check for this special case and update the cycle bit accordingly. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp Tested-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c79e294f47de4595a47ae4cef68c86b872e4550c Author: wangyanqing Date: Fri Mar 11 06:24:38 2011 -0800 USB: serial: ch341: add new id commit d0781383038e983a63843a9a6a067ed781db89c1 upstream. I picked up a new DAK-780EX(professional digitl reverb/mix system), which use CH341T chipset to communication with computer on 3/2011 and the CH341T's vendor code is 1a86 Looking up the CH341T's vendor and product id's I see: 1a86 QinHeng Electronics 5523 CH341 in serial mode, usb to serial port converter CH341T,CH341 are the products of the same company, maybe have some common hardware, and I test the ch341.c works well with CH341T Cc: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 691027e05a05ec4e64939c9099a47e30b9b23f54 Author: Jiri Slaby Date: Mon Feb 28 10:34:06 2011 +0100 USB: serial/kobil_sct, fix potential tty NULL dereference commit 6960f40a954619857e7095a6179eef896f297077 upstream. Make sure that we check the return value of tty_port_tty_get. Sometimes it may return NULL and we later dereference that. The only place here is in kobil_read_int_callback, so fix it. Signed-off-by: Jiri Slaby Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 9390d630e93fd278b9838611ccd2074d61064762 Author: Senthil Balasubramanian Date: Wed Dec 22 21:14:20 2010 +0530 ath9k_hw: Fix incorrect macversion and macrev checks commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by: Senthil Balasubramanian Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit d49bba0df98497d17e258462d6e41981556f82d0 Author: Andreas Herrmann Date: Tue Mar 15 15:31:37 2011 +0100 x86, quirk: Fix SB600 revision check commit 1d3e09a304e6c4e004ca06356578b171e8735d3c upstream. Commit 7f74f8f28a2bd9db9404f7d364e2097a0c42cc12 (x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems) introduced a regression. It removed some SB600 specific code to determine the revision ID without adapting a corresponding revision ID check for SB600. See this mail thread: http://marc.info/?l=linux-kernel&m=129980296006380&w=2 This patch adapts the corresponding check to cover all SB600 revisions. Tested-by: Wang Lei Signed-off-by: Andreas Herrmann Cc: Andrew Morton LKML-Reference: <20110315143137.GD29499@alberich.amd.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b8f71b5843d1c61dab407ca70e600baaa4a30210 Author: Sean Hefty Date: Wed Feb 23 08:17:40 2011 -0800 IB/cm: Bump reference count on cm_id before invoking callback commit 29963437a48475036353b95ab142bf199adb909e upstream. When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit df6f45842854d176147739fe1a8536ac6ce4acf1 Author: Sean Hefty Date: Wed Feb 23 08:11:32 2011 -0800 RDMA/cma: Fix crash in request handlers commit 25ae21a10112875763c18b385624df713a288a05 upstream. Doug Ledford and Red Hat reported a crash when running the rdma_cm on a real-time OS. The crash has the following call trace: cm_process_work cma_req_handler cma_disable_callback rdma_create_id kzalloc init_completion cma_get_net_info cma_save_net_info cma_any_addr cma_zero_addr rdma_translate_ip rdma_copy_addr cma_acquire_dev rdma_addr_get_sgid ib_find_cached_gid cma_attach_to_dev ucma_event_handler kzalloc ib_copy_ah_attr_to_user cma_comp [ preempted ] cma_write copy_from_user ucma_destroy_id copy_from_user _ucma_find_context ucma_put_ctx ucma_free_ctx rdma_destroy_id cma_exch cma_cancel_operation rdma_node_get_transport rt_mutex_slowunlock bad_area_nosemaphore oops_enter They were able to reproduce the crash multiple times with the following details: Crash seems to always happen on the: mutex_unlock(&conn_id->handler_mutex); as conn_id looks to have been freed during this code path. An examination of the code shows that a race exists in the request handlers. When a new connection request is received, the rdma_cm allocates a new connection identifier. This identifier has a single reference count on it. If a user calls rdma_destroy_id() from another thread after receiving a callback, rdma_destroy_id will proceed to destroy the id and free the associated memory. However, the request handlers may still be in the process of running. When control returns to the request handlers, they can attempt to access the newly created identifiers. Fix this by holding a reference on the newly created rdma_cm_id until the request handler is through accessing it. Signed-off-by: Sean Hefty Acked-by: Doug Ledford Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit f5e341e640060f10769f01b4ca93220eb8ee79f2 Author: Seth Heasley Date: Fri Mar 11 11:57:42 2011 -0800 ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controller commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream. This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 81394de45f0f8070ffcf7adc28c9794e9be279d0 Author: Seth Heasley Date: Mon Jan 10 12:57:17 2011 -0800 ahci: AHCI mode SATA patch for Intel DH89xxCC DeviceIDs commit a4a461a6df6c0481d5a3d61660ed97f5b539cf16 upstream. This patch adds the AHCI-mode SATA DeviceID for the Intel DH89xxCC PCH. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit a7f6edd03a4129f7992f2a945be157754ae9ced7 Author: Seth Heasley Date: Thu Sep 9 09:44:56 2010 -0700 ahci: AHCI and RAID mode SATA patch for Intel Patsburg DeviceIDs commit 992b3fb9b5391bc4de5b42bb810dc6dd583a6c4a upstream. This patch adds the Intel Patsburg (PCH) SATA AHCI and RAID Controller DeviceIDs. Signed-off-by: Seth Heasley Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit df73d6c6c2fe55bff1da3173a81910e47fa34c2f Author: Kamal Mostafa Date: Thu Feb 3 17:38:05 2011 -0800 x86: Emit "mem=nopentium ignored" warning when not supported commit 9a6d44b9adb777ca9549e88cd55bd8f2673c52a2 upstream. Emit warning when "mem=nopentium" is specified on any arch other than x86_32 (the only that arch supports it). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-2-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6564c8095de4ccf9e52de6959a49d0ed31feb985 Author: Kamal Mostafa Date: Thu Feb 3 17:38:04 2011 -0800 x86: Fix panic when handling "mem={invalid}" param commit 77eed821accf5dd962b1f13bed0680e217e49112 upstream. Avoid removing all of memory and panicing when "mem={invalid}" is specified, e.g. mem=blahblah, mem=0, or mem=nopentium (on platforms other than x86_32). Signed-off-by: Kamal Mostafa BugLink: http://bugs.launchpad.net/bugs/553464 Cc: Yinghai Lu Cc: Len Brown Cc: Rafael J. Wysocki LKML-Reference: <1296783486-23033-1-git-send-email-kamal@canonical.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4db6055ac0d0bfe40daec0448b4d2824c991ad07 Author: Steven Rostedt Date: Thu Feb 10 21:26:13 2011 -0500 ftrace: Fix memory leak with function graph and cpu hotplug commit 868baf07b1a259f5f3803c1dc2777b6c358f83cf upstream. When the fuction graph tracer starts, it needs to make a special stack for each task to save the real return values of the tasks. All running tasks have this stack created, as well as any new tasks. On CPU hot plug, the new idle task will allocate a stack as well when init_idle() is called. The problem is that cpu hotplug does not create a new idle_task. Instead it uses the idle task that existed when the cpu went down. ftrace_graph_init_task() will add a new ret_stack to the task that is given to it. Because a clone will make the task have a stack of its parent it does not check if the task's ret_stack is already NULL or not. When the CPU hotplug code starts a CPU up again, it will allocate a new stack even though one already existed for it. The solution is to treat the idle_task specially. In fact, the function_graph code already does, just not at init_idle(). Instead of using the ftrace_graph_init_task() for the idle task, which that function expects the task to be a clone, have a separate ftrace_graph_init_idle_task(). Also, we will create a per_cpu ret_stack that is used by the idle task. When we call ftrace_graph_init_idle_task() it will check if the idle task's ret_stack is NULL, if it is, then it will assign it the per_cpu ret_stack. Reported-by: Benjamin Herrenschmidt Suggested-by: Peter Zijlstra Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit d2ab16a60fa7873dffbb7c92eca6fc347f3ea80a Author: Andrey Vagin Date: Wed Mar 9 15:22:23 2011 -0800 x86/mm: Handle mm_fault_error() in kernel space commit f86268549f424f83b9eb0963989270e14fbfc3de upstream. mm_fault_error() should not execute oom-killer, if page fault occurs in kernel space. E.g. in copy_from_user()/copy_to_user(). This would happen if we find ourselves in OOM on a copy_to_user(), or a copy_from_user() which faults. Without this patch, the kernels hangs up in copy_from_user(), because OOM killer sends SIG_KILL to current process, but it can't handle a signal while in syscall, then the kernel returns to copy_from_user(), reexcute current command and provokes page_fault again. With this patch the kernel return -EFAULT from copy_from_user(). The code, which checks that page fault occurred in kernel space, has been copied from do_sigbus(). This situation is handled by the same way on powerpc, xtensa, tile, ... Signed-off-by: Andrey Vagin Signed-off-by: Andrew Morton Cc: "H. Peter Anvin" Cc: Linus Torvalds LKML-Reference: <201103092322.p29NMNPH001682@imap1.linux-foundation.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ec3eb823853639a674a4fdea11b0a8f47437df0d Author: Florian Fainelli Date: Sun Feb 27 19:53:53 2011 +0100 MIPS: MTX-1: Make au1000_eth probe all PHY addresses commit bf3a1eb85967dcbaae42f4fcb53c2392cec32677 upstream. When au1000_eth probes the MII bus for PHY address, if we do not set au1000_eth platform data's phy_search_highest_address, the MII probing logic will exit early and will assume a valid PHY is found at address 0. For MTX-1, the PHY is at address 31, and without this patch, the link detection/speed/duplex would not work correctly. Signed-off-by: Florian Fainelli To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/2111/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 19f8ff2017f6b45273dbf957f79042eaa34c949d Author: Tejun Heo Date: Thu Dec 9 15:59:32 2010 +0100 libata: no special completion processing for EH commands commit f08dc1ac6b15c681f4643d8da1700e06c3855608 upstream. ata_qc_complete() contains special handling for certain commands. For example, it schedules EH for device revalidation after certain configurations are changed. These shouldn't be applied to EH commands but they were. In most cases, it doesn't cause an actual problem because EH doesn't issue any command which would trigger special handling; however, ACPI can issue such commands via _GTF which can cause weird interactions. Restructure ata_qc_complete() such that EH commands are always passed on to __ata_qc_complete(). stable: Please apply to -stable only after 2.6.38 is released. Signed-off-by: Tejun Heo Reported-by: Kyle McMartin Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 59310870d3e8d138d2758e640041aad55bf90913 Author: Axel Lin Date: Mon Mar 7 11:04:24 2011 +0800 mtd: add "platform:" prefix for platform modalias commit c804c733846572ca85c2bba60c7fe6fa024dff18 upstream. Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS with "platform:"), the platform modalias is prefixed with "platform:". Signed-off-by: Axel Lin Signed-off-by: Artem Bityutskiy Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 654f6be10192136652cc8bb04865908e1e7c0266 Author: Hans de Goede Date: Sun Mar 13 13:50:33 2011 +0100 hwmon/f71882fg: Set platform drvdata to NULL later commit d9ebaa45472c92704f4814682eec21455edcfa1f upstream. This avoids a possible race leading to trying to dereference NULL. Signed-off-by: Hans de Goede Acked-by: Jean Delvare Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman