- 13 Aug, 2010 40 commits
-
-
Marek Vasut authored
commit 81cbb0b1 upstream. This patch corrects a problem where gen_nand driver assumed there can be only one chip and ignored the pdata->chip.nr_chips value. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Bénard authored
commit 6a8cfcfb upstream. * preset should be done before sending the reset command * without this, I get the following error on an i.MX35 : [ 0.900000] ------------[ cut here ]------------ [ 0.900000] WARNING: at kernel/irq/manage.c:290 __enable_irq+0x4c/0x88() [ 0.900000] Unbalanced enable for IRQ 33 [ 0.900000] Modules linked in: [ 0.900000] [<c002ffb8>] (unwind_backtrace+0x0/0xf0) from [<c02f7d0c>] (dump_stack+0x18/0x1c) [ 0.900000] [<c02f7d0c>] (dump_stack+0x18/0x1c) from [<c0049a44>] (warn_slowpath_common+0x54/0x6c) [ 0.900000] [<c0049a44>] (warn_slowpath_common+0x54/0x6c) from [<c0049b00>] (warn_slowpath_fmt+0x38/0x40) [ 0.900000] [<c0049b00>] (warn_slowpath_fmt+0x38/0x40) from [<c008f65c>] (__enable_irq+0x4c/0x88) [ 0.900000] [<c008f65c>] (__enable_irq+0x4c/0x88) from [<c008fca0>] (enable_irq+0x54/0x98) [ 0.900000] [<c008fca0>] (enable_irq+0x54/0x98) from [<c021e618>] (wait_op_done+0x40/0x134) [ 0.900000] [<c021e618>] (wait_op_done+0x40/0x134) from [<c021e808>] (send_cmd+0x30/0x38) [ 0.900000] [<c021e808>] (send_cmd+0x30/0x38) from [<c021eb8c>] (mxc_nand_command+0x26c/0x328) [ 0.900000] [<c021eb8c>] (mxc_nand_command+0x26c/0x328) from [<c021aa60>] (nand_scan_ident+0x188/0x6c0) [ 0.900000] [<c021aa60>] (nand_scan_ident+0x188/0x6c0) from [<c001a9cc>] (mxcnd_probe+0x2b8/0x3d0) [ 0.900000] [<c001a9cc>] (mxcnd_probe+0x2b8/0x3d0) from [<c01f9e88>] (platform_drv_probe+0x20/0x24) [ 0.900000] [<c01f9e88>] (platform_drv_probe+0x20/0x24) from [<c01f8c38>] (driver_probe_device+0xb0/0x164) [ 0.900000] [<c01f8c38>] (driver_probe_device+0xb0/0x164) from [<c01f8d54>] (__driver_attach+0x68/0x8c) [ 0.900000] [<c01f8d54>] (__driver_attach+0x68/0x8c) from [<c01f8348>] (bus_for_each_dev+0x50/0x84) [ 0.900000] [<c01f8348>] (bus_for_each_dev+0x50/0x84) from [<c01f8a9c>] (driver_attach+0x20/0x28) [ 0.900000] [<c01f8a9c>] (driver_attach+0x20/0x28) from [<c01f7c00>] (bus_add_driver+0x144/0x2dc) [ 0.900000] [<c01f7c00>] (bus_add_driver+0x144/0x2dc) from [<c01f906c>] (driver_register+0xb0/0x13c) [ 0.900000] [<c01f906c>] (driver_register+0xb0/0x13c) from [<c01fa13c>] (platform_driver_register+0x4c/0x60) [ 0.900000] [<c01fa13c>] (platform_driver_register+0x4c/0x60) from [<c01fa170>] (platform_driver_probe+0x20/0xa0) [ 0.900000] [<c01fa170>] (platform_driver_probe+0x20/0xa0) from [<c001a708>] (mxc_nd_init+0x18/0x24) [ 0.900000] [<c001a708>] (mxc_nd_init+0x18/0x24) from [<c002938c>] (do_one_initcall+0x64/0x1bc) [ 0.900000] [<c002938c>] (do_one_initcall+0x64/0x1bc) from [<c00084c4>] (kernel_init+0xe8/0x1ac) [ 0.900000] [<c00084c4>] (kernel_init+0xe8/0x1ac) from [<c002aee8>] (kernel_thread_exit+0x0/0x8) [ 0.900000] ---[ end trace 8bf72ac6ba089a19 ]--- [ 1.140000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit) Signed-off-by:
Eric Bénard <eric@eukrea.com> Signed-off-by:
-
Peter Zijlstra authored
commit 396e894d upstream. Norbert reported that nohz_ratelimit() causes his laptop to burn about 4W (40%) extra. For now back out the change and see if we can adjust the power management code to make better decisions. Reported-by:
Norbert Preining <preining@logic.at> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Mike Galbraith <efault@gmx.de> Cc: Arjan van de Ven <arjan@infradead.org> LKML-Reference: <new-submission> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Cyril Lacoux authored
commit 0a79f674 upstream. Device class is ff(vend.) instead of e0(wlcon). Output from command `usb-devices`: T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8215 Rev=01.82 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller S: SerialNumber=7C6D62936607 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none) Signed-off-by:
Cyril Lacoux <clacoux@ifeelgood.org> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hovold authored
commit b58af406 upstream. As David VomLehn points out, it was possible to receive an interrupt before clearing the free-urb flag which could lead to the urb being incorrectly marked as busy. For the same reason, move tx_bytes accounting so that it will never be negative. Note that the free-flags set and clear operations do not need any additional locking as they are manipulated while USB_SERIAL_WRITE_BUSY is set. Reported-by:
David VomLehn <dvomlehn@cisco.com> Tested-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
Christian Lamparter authored
commit b3e67044 upstream. This patch fixes a race condition in two utility routines related to the removal/unlinking of urbs from an anchor. If two threads are concurrently accessing the same anchor, both could end up with the same urb - thinking they are the exclusive owner. Alan Stern pointed out a related issue in usb_unlink_anchored_urbs: "The URB isn't removed from the anchor until it completes (as a by-product of completion, in fact), which might not be for quite some time after the unlink call returns. In the meantime, the subroutine will keep trying to unlink it, over and over again." Cc: Oliver Neukum <oneukum@suse.de> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Ming Lei authored
commit e10e1bec upstream. This patch fixes the warning below: [30753.755998] ------------[ cut here ]------------ [30753.755998] WARNING: at /home/tom/git/linux-2.6/linux-2.6-next/arch/x86/include/asm/dma-mapping.h:155 hcd_buffer_free+0xb1/0xd4 [usbcore]() [30753.755998] Hardware name: 6475EK2 [30753.755998] Modules linked in: uvcvideo ehci_hcd usbtest cdc_ether usbnet vfat fat usb_storage nfsd lockd nfs_acl auth_rpcgss exportfs mii tun videodev v4l1_compat v4l2_compat_ioctl32 fuse bridge stp llc sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table mperf kvm_intel kvm arc4 ecb ath5k usbhid mac80211 snd_hda_codec_conexant ch341 usbserial ath cfg80211 thinkpad_acpi snd_hda_intel pcspkr wmi hwmon yenta_socket iTCO_wdt iTCO_vendor_support i2c_i801 e1000e snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc pata_acpi uhci_hcd ohci_hcd usbcore i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: uvcvideo] [30753.755998] Pid: 0, comm: swapper Tainted: G W 2.6.35-rc6-gkh-wl+ #49 [30753.755998] Call Trace: [30753.755998] <IRQ> [<ffffffff8104478a>] warn_slowpath_common+0x80/0x98 [30753.755998] [<ffffffff810447b7>] warn_slowpath_null+0x15/0x17 [30753.755998] [<ffffffffa00ce02d>] hcd_buffer_free+0xb1/0xd4 [usbcore] [30753.755998] [<ffffffffa00c1345>] usb_free_coherent+0x1c/0x1e [usbcore] [30753.755998] [<ffffffffa00b13e4>] simple_free_urb+0x23/0x2f [usbtest] [30753.755998] [<ffffffffa00b210b>] iso_callback+0xbb/0x10f [usbtest] [30753.755998] [<ffffffffa00c7390>] usb_hcd_giveback_urb+0x8c/0xc0 [usbcore] [30753.755998] [<ffffffffa0449b35>] ehci_urb_done+0x84/0x95 [ehci_hcd] [30753.755998] [<ffffffffa044b5a5>] ehci_work+0x41a/0x7dd [ehci_hcd] [30753.755998] [<ffffffffa044e298>] ehci_irq+0x33b/0x370 [ehci_hcd] [30753.755998] [<ffffffff8100fb05>] ? sched_clock+0x9/0xd [30753.755998] [<ffffffff8105e641>] ? sched_clock_local+0x1c/0x82 [30753.755998] [<ffffffff8105e76a>] ? sched_clock_cpu+0xc3/0xce [30753.755998] [<ffffffff81067c7e>] ? trace_hardirqs_off+0xd/0xf [30753.755998] [<ffffffff8105e7b8>] ? cpu_clock+0x43/0x5e [30753.755998] [<ffffffffa00c6999>] usb_hcd_irq+0x45/0xa1 [usbcore] [30753.755998] [<ffffffff81092e02>] handle_IRQ_event+0x20/0xa5 [30753.755998] [<ffffffff81094cea>] handle_fasteoi_irq+0x92/0xd2 [30753.755998] [<ffffffff8100c0ed>] handle_irq+0x1f/0x2a [30753.755998] [<ffffffff8100b75d>] do_IRQ+0x57/0xbe [30753.755998] [<ffffffff8136a693>] ret_from_intr+0x0/0x16 [30753.755998] <EOI> [<ffffffff81223baa>] ? acpi_idle_enter_bm+0x231/0x269 [30753.755998] [<ffffffff81223ba3>] ? acpi_idle_enter_bm+0x22a/0x269 [30753.755998] [<ffffffff812c4b6b>] cpuidle_idle_call+0x99/0xce [30753.755998] [<ffffffff81008dd5>] cpu_idle+0x61/0xaa [30753.755998] [<ffffffff8136374b>] start_secondary+0x1c2/0x1c6 [30753.755998] ---[ end trace 904cfaf7ab4cb1a2 ]--- Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Alessio Igor Bogani authored
commit 356c5a48 upstream. Signed-off-by:
Alessio Igor Bogani <abogani@texware.it> Signed-off-by:
-
dranch@trinnet.net authored
commit b6180ef7 upstream. This patch is to add a US Interface, Inc. "Navigator" USB device. Specifically, it's a HAM Radio USB sound modem that also incorporates three pairs of unique FTDI serial ports. The standard Linux FTDI serial driver will only recognize the first two serial ports of an unknown FDTI derived device and this patch adds in recognition to these specific new IDs. Signed-off-by:
David A. Ranch <dranch@trinnet.net> Signed-off-by:
-
Andrew Bird authored
commit 0372a754 upstream. This patch adds the product IDs of Huawei's K3765 and K4505 mobile broadband usb modems to option.c. It also adds a quirk to the option probe function so that binding to the device's network interface(class 0xff) is avoided. This is necessary to allow another driver to bind to that, and to avoid programs like wvdial opening a nonfunctioning tty during modem discovery. Signed-off-by:
Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by:
-
Pavel Kazlou authored
commit b972302b upstream. The patch adds Huawei ETS 1220 product id into the list of supported devices in 'option' usb serial driver. Signed-off-by:
Pavel Kazlou <p.i.kazlou@gmail.com> Signed-off-by:
-
John G. Rogers authored
commit afad1964 upstream. I have added the ProductID=0xe729 VendorID=FTDI_VID=0x0403 which will enable support for the Segway Robotic Mobility Platform (RMP200) in the ftdi_sio kernel module. Currently, users of the Segway RMP200 must use a RUN+="/sbin/modprobe -q ftdi-sio product=0xe729 vendor=0x0403 in a udev rule to get the ftdi_sio module to handle the usb interface and mount it on /dev/ttyXXX. This is not a good solution because some users will have multiple USB to Serial converters which will use the ftdi_sio module. Signed-off-by:
John Rogers <jgrogers@gmail.com> Signed-off-by:
-
Phil Dibowitz authored
commit 93362a87 upstream. The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by:
Phil Dibowitz <phil@ipom.com> Signed-off-by:
-
Steven Robertson authored
commit 33d973ad upstream. Enlarging the buffer size via the MON_IOCT_RING_SIZE ioctl causes general protection faults. It appears the culprit is an incorrect argument to mon_free_buff: instead of passing the size of the current buffer being freed, the size of the new buffer is passed. Use the correct size argument to mon_free_buff when changing the size of the buffer. Signed-off-by:
Steven Robertson <steven@strobe.cc> Acked-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Alan Stern authored
commit ae68a83b upstream. This patch (as1405) fixes a small bug in ehci-hcd's isochronous scheduler. Not all EHCI controllers are PCI, and the code shouldn't assume that they are. Instead, introduce a special flag for controllers which need to delay iso scheduling for full-speed devices beyond the scheduling threshold. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Anand Gadiyar authored
commit 0936fb5e upstream. DMA_ADDR and DMA_COUNT are 32-bit registers, not 16-bit. Marking them as 16-bit in the table causes only the lower 16-bits to be dumped and this is misleading. Signed-off-by:
Anand Gadiyar <gadiyar@ti.com> Acked-by:
Felipe Balbi <felipe.balbi@nokia.com> Signed-off-by:
Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by:
-
Uwe Kleine-König authored
commit 868003ca upstream. This is a follow up to 14cb0deb (arm/imx/gpio: add spinlock protection) and fixes the following build failure: CC arch/arm/mach-imx/pcm970-baseboard.o In file included from arch/arm/include/asm/gpio.h:6, from include/linux/gpio.h:8, from arch/arm/mach-imx/pcm970-baseboard.c:20: arch/arm/plat-mxc/include/mach/gpio.h:40: error: expected specifier-qualifier-list before 'spinlock_t' Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Will Deacon authored
commit cdf357f1 upstream. On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Tested-by:
Rob Clark <rob@ti.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 492c5d94 upstream. On SMP systems, the SMSC911x registers may be accessed by multiple CPUs and this seems to put the chip in an inconsistent state. The patch adds spinlocks to the smsc911x_reg_read, smsc911x_reg_write, smsc911x_rx_readfifo and smsc911x_tx_writefifo functions. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Igor Grinberg authored
commit a6cd7eb3 upstream. ffuart is available on cm-x300 only with pxa300. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Nathan Lynch authored
commit a2a20c41 upstream. If signalfd is used to consume a signal generated by a POSIX interval timer or POSIX message queue, the ssi_int field does not reflect the data (sigevent->sigev_value) supplied to timer_create(2) or mq_notify(3). (The ssi_ptr field, however, is filled in.) This behavior differs from signalfd's treatment of sigqueue-generated signals -- see the default case in signalfd_copyinfo. It also gives results that differ from the case when a signal is handled conventionally via a sigaction-registered handler. So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER, __SI_MESGQ) where ssi_ptr is set. akpm: a non-back-compatible change. Merge into -stable to minimise the number of kernels which are in the field and which miss this feature. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Acked-by:
Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tejun Heo authored
commit aca27ba9 upstream. Commit a82afdfc (block: use the same failfast bits for bio and request) moved BIO_RW_* bits around such that they match up with REQ_* bits. Unfortunately, fs.h hard coded RW_MASK, RWA_MASK, READ, WRITE, READA and SWRITE as 0, 1, 2 and 3, and expected them to match with BIO_RW_* bits. READ/WRITE didn't change but BIO_RW_AHEAD was moved to bit 4 instead of bit 1, breaking RWA_MASK, READA and SWRITE. This patch updates RWA_MASK, READA and SWRITE such that they match the BIO_RW_* bits again. A follow up patch will update the definitions to directly use BIO_RW_* bits so that this kind of breakage won't happen again. Neil also spotted missing RWA_MASK conversion. Stable: The offending commit a82afdfc was released with v2.6.32, so this patch should be applied to all kernels since then but it must _NOT_ be applied to kernels earlier than that. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-and-bisected-by:
Vladislav Bolkhovitin <vst@vlnb.net> Root-caused-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Philipp Reisner authored
commit 6710a576 upstream. Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
Philipp Reisner authored
commit 85f4cc17 upstream. Signed-off-by:
-
Julia Lawall authored
commit ceeab929 upstream. The comments in the code indicate that file_info should be released if the function fails. This releasing is done at the label out_free, not out. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = kmem_cache_zalloc(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return <+...x...+>; | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmem_cache_zalloc %s" % (p1[0].file,p1[0].line) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Lino Sanfilippo authored
commit 31f73bee upstream. In ecryptfs_lookup_and_interpose_lower() the lower mount is not decremented if allocation of a dentry info struct failed. As a result the lower filesystem cant be unmounted any more (since it is considered busy). This patch corrects the reference counting. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by:
-
Tyler Hicks authored
commit c43f7b8f upstream. Lower filesystems that only implemented unlocked_ioctl weren't being passed ioctl calls because eCryptfs only checked for lower_file->f_op->ioctl and returned -ENOTTY if it was NULL. eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL. This patch introduces ecryptfs_unlocked_ioctl() and ecryptfs_compat_ioctl(), which passes the calls on to the lower file system. https://bugs.launchpad.net/ecryptfs/+bug/469664Reported-by:
James Dupin <james.dupin@gmail.com> Signed-off-by:
-
Chris Wright authored
commit b7300b78 upstream. The cgroup device whitelist code gets confused when trying to grant permission to a disk partition that is not currently open. Part of blkdev_open() includes __blkdev_get() on the whole disk. Basically, the only ways to reliably allow a cgroup access to a partition on a block device when using the whitelist are to 1) also give it access to the whole block device or 2) make sure the partition is already open in a different context. The patch avoids the cgroup check for the whole disk case when opening a partition. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=589662Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Acked-by:
Serge E. Hallyn <serue@us.ibm.com> Tested-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: "Daniel P. Berrange" <berrange@redhat.com> Signed-off-by:
-
Al Viro authored
commit 7a4dec53 upstream. If sget() finds a matching superblock being set up, it'll grab an active reference to it and grab s_umount. That's fine - we'll wait for completion of foofs_get_sb() that way. However, if said foofs_get_sb() fails we'll end up holding the halfway-created superblock. deactivate_locked_super() called by foofs_get_sb() will just unlock the sucker since we are holding another active reference to it. What we need is a way to tell if superblock has been successfully set up. Unfortunately, neither ->s_root nor the check for MS_ACTIVE quite fit. Cheap and easy way, suitable for backport: new flag set by the (only) caller of ->get_sb(). If that flag isn't present by the time sget() grabbed s_umount on preexisting superblock it has found, it's seeing a stillborn and should just bury it with deactivate_locked_super() (and repeat the search). Longer term we want to set that flag in ->get_sb() instances (and check for it to distinguish between "sget() found us a live sb" and "sget() has allocated an sb, we need to set it up" in there, instead of checking ->s_root as we do now). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dan Williams authored
commit 556ab45f upstream. On some platforms (MacPro3,1) the BIOS assigns the ioatdma device to the incorrect iommu causing faults when the driver initializes. Add a quirk to catch this misconfiguration and try falling back to untranslated operation (which works in the MacPro3,1 case). Assuming there are other platforms with misconfigured iommus teach the ioatdma driver to treat initialization failures as non-fatal (just fail the driver load and emit a warning instead of triggering a BUG_ON). This can be classified as a boot regression since 2.6.32 on affected platforms since the ioatdma module did not autoload prior to that kernel. Acked-by:
Chris Li <lkml@chrisli.org> Tested-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Jeff Kirsher authored
commit 2d0bb1c1 upstream. Based on patches from Sonny Rao and Milton Miller... Combined the patches to fix up clean_tx_irq and clean_rx_irq. The PowerPC architecture does not require loads to independent bytes to be ordered without adding an explicit barrier. In ixgbe_clean_rx_irq we load the status bit then load the packet data. With packet split disabled if these loads go out of order we get a stale packet, but we will notice the bad sequence numbers and drop it. The problem occurs with packet split enabled where the TCP/IP header and data are in different descriptors. If the reads go out of order we may have data that doesn't match the TCP/IP header. Since we use hardware checksumming this bad data is never verified and it makes it all the way to the application. This bug was found during stress testing and adding this barrier has been shown to fix it. The bug can manifest as a data integrity issue (bad payload data) or as a BUG in skb_pull(). This was a nasty bug to hunt down, if people agree with the fix I think it's a candidate for stable. Previously Submitted to e1000-devel only for ixgbe http://marc.info/?l=e1000-devel&m=126593062701537&w=3 We've now seen this problem hit with other device drivers (e1000e mostly) So I'm resubmitting with fixes for other Intel Device Drivers with similar issues. CC: Milton Miller <miltonm@bga.com> CC: Anton Blanchard <anton@samba.org> CC: Sonny Rao <sonnyrao@us.ibm.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
NeilBrown authored
commit 51e9ac77 upstream. If the 'bio_split' path in raid10-read is used while resync/recovery is happening it is possible to deadlock. Fix this be elevating ->nr_waiting for the duration of both parts of the split request. This fixes a bug that has been present since 2.6.22 but has only started manifesting recently for unknown reasons. It is suitable for and -stable since then. Reported-by:
Justin Bronder <jsbronder@gentoo.org> Tested-by:
-
NeilBrown authored
commit bb4f1e9d upstream. Move the deletion of sysfs attributes from reconfig_mutex to open_mutex didn't really help as a process can try to take open_mutex while holding reconfig_mutex, so the same deadlock can happen, just requiring one more process to be involved in the chain. I looks like I cannot easily use locking to wait for the sysfs deletion to complete, so don't. The only things that we cannot do while the deletions are still pending is other things which can change the sysfs namespace: run, takeover, stop. Each of these can fail with -EBUSY. So set a flag while doing a sysfs deletion, and fail run, takeover, stop if that flag is set. This is suitable for 2.6.35.x Signed-off-by:
-
Dan Williams authored
commit 147e0b6a upstream. Commit b821eaa5 "md: remove ->changed and related code" moved revalidate_disk() under open_mutex, and lockdep noticed. [ INFO: possible circular locking dependency detected ] 2.6.32-mdadm-locking #1 ------------------------------------------------------- mdadm/3640 is trying to acquire lock: (&bdev->bd_mutex){+.+.+.}, at: [<ffffffff811acecb>] revalidate_disk+0x5b/0x90 but task is already holding lock: (&mddev->open_mutex){+.+...}, at: [<ffffffffa055e07a>] do_md_stop+0x4a/0x4d0 [md_mod] which lock already depends on the new lock. It is suitable for 2.6.35.x Reported-by:
Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com> Signed-off-by:
-
Borislav Petkov authored
commit 11071282 upstream. ide_cd_error_cmd() can complete an erroneous request with leftover buffers. Signal this with its return value so that the request is not accessed after its completion in the irq handler and we oops. Signed-off-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Yinghai Lu authored
commit d9e1b6c4 upstream. After the commit that changed ipmi_si detecting sequence from SMBIOS/ACPI to ACPI/SMBIOS, | commit 754d4531 | Author: Matthew Garrett <mjg@redhat.com> | Date: Wed May 26 14:43:47 2010 -0700 | | ipmi: change device discovery order | | The ipmi spec provides an ordering for si discovery. Change the driver to | match, with the exception of preferring smbios to SPMI as HPs (at least) | contain accurate information in the former but not the latter. ipmi_si can not be initialized. [ 138.799739] calling init_ipmi_devintf+0x0/0x109 @ 1 [ 138.805050] ipmi device interface [ 138.818131] initcall init_ipmi_devintf+0x0/0x109 returned 0 after 12797 usecs [ 138.822998] calling init_ipmi_si+0x0/0xa90 @ 1 [ 138.840276] IPMI System Interface driver. [ 138.846137] ipmi_si: probing via ACPI [ 138.849225] ipmi_si 00:09: [io 0x0ca2] regsize 1 spacing 1 irq 0 [ 138.864438] ipmi_si: Adding ACPI-specified kcs state machine [ 138.870893] ipmi_si: probing via SMBIOS [ 138.880945] ipmi_si: Adding SMBIOS-specified kcs state machineipmi_si: duplicate interface [ 138.896511] ipmi_si: probing via SPMI [ 138.899861] ipmi_si: Adding SPMI-specified kcs state machineipmi_si: duplicate interface [ 138.917095] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x0, irq 0 [ 138.928658] ipmi_si: Interface detection failed [ 138.953411] initcall init_ipmi_si+0x0/0xa90 returned 0 after 110847 usecs in smbios has DMI/SMBIOS Handle 0x00C5, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x00 NV Storage Device: Not Present Base Address: 0x0000000000000CA2 (I/O) Register Spacing: 32-bit Boundaries in DSDT has Device (BMC) { Name (_HID, EisaId ("IPI0001")) Method (_STA, 0, NotSerialized) { If (LEqual (OSN, Zero)) { Return (Zero) } Return (0x0F) } Name (_STR, Unicode ("IPMI_KCS")) Name (_UID, Zero) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0CA2, // Range Minimum 0x0CA2, // Range Maximum 0x00, // Alignment 0x01, // Length ) IO (Decode16, 0x0CA6, // Range Minimum 0x0CA6, // Range Maximum 0x00, // Alignment 0x01, // Length ) }) Method (_IFT, 0, NotSerialized) { Return (One) } Method (_SRV, 0, NotSerialized) { Return (0x0200) } } so the reg spacing should be 4 instead of 1. Try to calculate regspacing for this kind of system. Observed on a Sun Fire X4800. Other OSes work and pass certification. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by:
Matthew Garrett <mjg@redhat.com> Cc: Len Brown <len.brown@intel.com> Cc: Myron Stowe <myron.stowe@hp.com> Cc: Corey Minyard <minyard@acm.org> Signed-off-by:
-
John W. Linville authored
commit 8f1d2d2b upstream. ieee80211_beacon_get can return NULL... Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Johannes Berg authored
commit e95b7435 upstream. The TX tracing code copies with the wrong length, which will typically copy too little data. Fix this by using the correct length variable. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Peter Huewe authored
commit fa260c00 upstream. Fix a build failure "error: void value not ignored as it ought to be" by removing an assignment of a void return value. The functionality of the code is not changed. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Acked-by:
Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by:
-
KAMEZAWA Hiroyuki authored
commit 966cca02 upstream. Since 2.6.31, swap_map[]'s refcounting was changed to show that a used swap entry is just for swap-cache, can be reused. Then, while scanning free entry in swap_map[], a swap entry may be able to be reclaimed and reused. It was caused by commit c9e44410 ("mm: reuse unused swap entry if necessary"). But this caused deta corruption at resume. The scenario is - Assume a clean-swap cache, but mapped. - at hibernation_snapshot[], clean-swap-cache is saved as clean-swap-cache and swap_map[] is marked as SWAP_HAS_CACHE. - then, save_image() is called. And reuse SWAP_HAS_CACHE entry to save image, and break the contents. After resume: - the memory reclaim runs and finds clean-not-referenced-swap-cache and discards it because it's marked as clean. But here, the contents on disk and swap-cache is inconsistent. Hance memory is corrupted. This patch avoids the bug by not reclaiming swap-entry during hibernation. This is a quick fix for backporting. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Reported-by:
Ondreg Zary <linux@rainbow-software.org> Tested-by:
Andrea Gelmini <andrea.gelmini@gmail.com> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
-
