user/sven/linux.git, branch v2.6.27.4

Linux 2.6.27.4

2008-10-25T22:05:07Z

V4L/DVB (9300): pvrusb2: Fix deadlock problem

2008-10-25T21:32:42Z

commit c82732a42896364296599b0f73f01c5e3fd781ae upstream Fix deadlock problem in 2.6.27 caused by new USB core behavior in response to a USB device reset request. With older kernels, the USB device reset was "in line"; the reset simply took place and the driver retained its association with the hardware. However now this reset triggers a disconnect, and worse still the disconnect callback happens in the context of the caller who asked for the device reset. This results in an attempt by the pvrusb2 driver to recursively take a mutex it already has, which deadlocks the driver's worker thread. (Even if the disconnect callback were to happen on a different thread we'd still have problems however - because while the driver should survive and correctly disconnect / reconnect, it will then trigger another device reset during the repeated initialization, which will then cause another disconect, etc, forever.) The fix here is simply to not attempt the device reset (it was of marginal value anyway). Signed-off-by: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mike Krufky Signed-off-by: Greg Kroah-Hartman

PCI hotplug: cpqphp: fix kernel NULL pointer dereference

2008-10-25T21:32:42Z

commit d2174c3c07adad88dd9ba37a731e0b00b746822a upstream The following patch fixes the regression in 2.6.27 that causes kernel NULL pointer dereference at cpqphp driver probe time. This patch should be backported to the .27 stable series. Seems to have been introduced by f46753c5e354b857b20ab8e0fe7b2579831dc369. The root cause of this problem seems that cpqphp driver calls pci_hp_register() wrongly. In current implementation, cpqphp driver passes 'ctrl->pci_dev->subordinate' as a second parameter for pci_hp_register(). But because hotplug slots and it's hotplug controller (exists as a pci funcion) are on the same bus, it should be 'ctrl->pci_dev->bus' instead. Tested-by: Ingo Molnar Signed-off-by: Kenji Kaneshige Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

SCSI: scsi_dh: add Dell product information into rdac device handler

2008-10-25T21:32:42Z

commit 650849d71ca05d55a1553fe42fb21af9dce5612b upstream. Add Dell Powervault storage arrays into device list of rdac device handler. Signed-off-by: Yanqing Liu Signed-off-by: James Bottomley Cc: shyam iyer Signed-off-by: Greg Kroah-Hartman

proc: fix vma display mismatch between /proc/pid/{maps,smaps}

2008-10-25T21:32:42Z

[ backport of 7c88db0cb589df980acfb2f73c3595a0653004ec to 2.7.27.3 by Joe Korty /tmp/smaps; diff /proc/1/maps /tmp/smaps 1 25d24 2 < 7fd7e23aa000-7fd7e23ac000 rw-p 7fd7e23aa000 00:00 0 3 28a28 4 > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] The bug has something to do with setting m->version before all the seq_printf's have been performed. show_map was doing this correctly, but show_smap was doing this in the middle of its seq_printf sequence. This patch arranges things so that the setting of m->version in show_smap is also done at the end of its seq_printf sequence. Testing: in addition to the above grep test, for each process I summed up the 'Rss' fields of /proc/pid/smaps and compared that to the 'VmRSS' field of /proc/pid/status. All matched except for Xorg (which has a /dev/mem mapping which Rss accounts for but VmRSS does not). This result gives us some confidence that neither /proc/pid/maps nor /proc/pid/smaps are any longer skipping or double-counting vmas. Signed-off-by: Joe Korty Cc: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Alexey Dobriyan

ACPI suspend: Always use the 32-bit waking vector

2008-10-25T21:32:42Z

commit a6629105dd03d370fcb31e97bddf223fa4bb651e upstream. According to the ACPI specification 2.0c and later, the 64-bit waking vector should be cleared and the 32-bit waking vector should be used, unless we want the wake-up code to be called by the BIOS in Protected Mode. Moreover, some systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit waking vector is used. Therefore, modify the code to clear the 64-bit waking vector, for FACS version 1 or greater, and set the 32-bit one before suspend. http://bugzilla.kernel.org/show_bug.cgi?id=11368 Signed-off-by: Rafael J. Wysocki Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI suspend: Blacklist HP xw4600 Workstation for old code ordering

2008-10-25T21:32:41Z

commit 4fb507b6b764195bb7821cf2baa988f6eb677d30 upstream HP xw4600 Workstation is known to require the "old" (ie. compatible with ACPI 1.0) suspend code ordering, so blacklist it for this purpose. Signed-off-by: Rafael J. Wysocki Tested-by: John Brown Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI Suspend: Enable ACPI during resume if SCI_EN is not set

2008-10-25T21:32:41Z

commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 upstream. On some machines, like for example MSI Wind U100, the BIOS doesn't enable ACPI before returning control to the OS, which sometimes causes resume to fail. This is against the ACPI specification, which clearly states that "When the platform is waking from an S1, S2 or S3 state, OSPM assumes the hardware is already in the ACPI mode and will not issue an ACPI_ENABLE", but it won't hurt to check the SCI_EN bit and enable ACPI during resume from S3 if this bit is not set. Fortunately, we already have acpi_enable() for that, so use it in the resume code path, before executing _BFS, in analogy with the resume-from-hibernation code path. NOTE: We aren't supposed to set SCI_EN directly, because it's owned by the hardware. Signed-off-by: Rafael J. Wysocki Acked-by: Pavel Machek Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

hvc_console: Fix free_irq in spinlocked section

2008-10-25T21:32:41Z

commit eef2622a9fcfa964073333ea72c7c9cd20ad45e6 upstream hvc_console: Fix free_irq in spinlocked section commit 611e097d7707741a336a0677d9d69bec40f29f3d Author: Christian Borntraeger hvc_console: rework setup to replace irq functions with callbacks introduced a spinlock recursion problem. The notifier_del is called with a lock held, and in turns calls free_irq which then complains when manipulating procfs. This fixes it by moving the call to the notifier to outside of the locked section. Signed-off-by: Christian Borntraeger Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

anon_vma_prepare: properly lock even newly allocated entries

2008-10-25T21:32:41Z

commit d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6 upstream The anon_vma code is very subtle, and we end up doing optimistic lookups of anon_vmas under RCU in page_lock_anon_vma() with no locking. Other CPU's can also see the newly allocated entry immediately after we've exposed it by setting "vma->anon_vma" to the new value. We protect against the anon_vma being destroyed by having the SLAB marked as SLAB_DESTROY_BY_RCU, so the RCU lookup can depend on the allocation not being destroyed - but it might still be free'd and re-allocated here to a new vma. As a result, we should not do the anon_vma list ops on a newly allocated vma without proper locking. Acked-by: Nick Piggin Acked-by: Hugh Dickins Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman