From: Greg Kroah-Hartman Date: Sun, 8 Feb 2009 20:27:33 +0000 (-0800) Subject: start .28 patches X-Git-Tag: v2.6.27.16~20 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f9e59d949cc4ba6f361cf6231f79513148f194ff;p=thirdparty%2Fkernel%2Fstable-queue.git start .28 patches --- diff --git a/queue-2.6.28/acpi-dock-don-t-eval-_sta-on-every-show_docked-sysfs-read.patch b/queue-2.6.28/acpi-dock-don-t-eval-_sta-on-every-show_docked-sysfs-read.patch new file mode 100644 index 00000000000..61a0463cfcf --- /dev/null +++ b/queue-2.6.28/acpi-dock-don-t-eval-_sta-on-every-show_docked-sysfs-read.patch @@ -0,0 +1,47 @@ +From fc5a9f8841ee87d93376ada5d73117d4d6a373ea Mon Sep 17 00:00:00 2001 +From: Holger Macht +Date: Tue, 20 Jan 2009 12:18:24 +0100 +Subject: ACPI: dock: Don't eval _STA on every show_docked sysfs read + +From: Holger Macht + +commit fc5a9f8841ee87d93376ada5d73117d4d6a373ea upstream. + +Some devices trigger a DEVICE_CHECK on every evalutation of _STA. This +can also be seen in commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db +(ACPI: dock: avoid check _STA method). If an undock is processed, the +dock driver sends a uevent and userspace might read the show_docked +property in sysfs. This causes an evaluation of _STA of the particular +device which causes the dock driver to immediately dock again. + +In any case, evaluation of _STA (show_docked) does not necessarily mean +that we are docked, so check with the internal device structure. + +http://bugzilla.kernel.org/show_bug.cgi?id=12360 + +Signed-off-by: Holger Macht +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/dock.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/dock.c ++++ b/drivers/acpi/dock.c +@@ -855,10 +855,14 @@ fdd_out: + static ssize_t show_docked(struct device *dev, + struct device_attribute *attr, char *buf) + { ++ struct acpi_device *tmp; ++ + struct dock_station *dock_station = *((struct dock_station **) + dev->platform_data); +- return snprintf(buf, PAGE_SIZE, "%d\n", dock_present(dock_station)); + ++ if (ACPI_SUCCESS(acpi_bus_get_device(dock_station->handle, &tmp))) ++ return snprintf(buf, PAGE_SIZE, "1\n"); ++ return snprintf(buf, PAGE_SIZE, "0\n"); + } + static DEVICE_ATTR(docked, S_IRUGO, show_docked, NULL); + diff --git a/queue-2.6.28/acpi-enable-bit-11-in-_pdc-to-advertise-hw-coord.patch b/queue-2.6.28/acpi-enable-bit-11-in-_pdc-to-advertise-hw-coord.patch new file mode 100644 index 00000000000..2589cdae130 --- /dev/null +++ b/queue-2.6.28/acpi-enable-bit-11-in-_pdc-to-advertise-hw-coord.patch @@ -0,0 +1,44 @@ +From d96f94c604453f87fe24154b87e1e9a3a72511f8 Mon Sep 17 00:00:00 2001 +From: Pallipadi, Venkatesh +Date: Mon, 2 Feb 2009 11:57:18 -0800 +Subject: ACPI: Enable bit 11 in _PDC to advertise hw coord + +From: Pallipadi, Venkatesh + +commit d96f94c604453f87fe24154b87e1e9a3a72511f8 upstream. + +Bit 11 in intel PDC definitions is meant for OS capability to handle +hardware coordination of P-states. In Linux we have always supported +hwardware coordination of P-states. Just let the BIOSes know that we +support it, by setting this bit. + +Some BIOSes use this bit to choose between hardware or software coordination +and without this change below, BIOSes switch to software coordination, which +is not very optimal in terms of power consumption and extra wakeups from idle. + +Signed-off-by: Venkatesh Pallipadi +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + include/acpi/pdc_intel.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/include/acpi/pdc_intel.h ++++ b/include/acpi/pdc_intel.h +@@ -14,6 +14,7 @@ + #define ACPI_PDC_SMP_T_SWCOORD (0x0080) + #define ACPI_PDC_C_C1_FFH (0x0100) + #define ACPI_PDC_C_C2C3_FFH (0x0200) ++#define ACPI_PDC_SMP_P_HWCOORD (0x0800) + + #define ACPI_PDC_EST_CAPABILITY_SMP (ACPI_PDC_SMP_C1PT | \ + ACPI_PDC_C_C1_HALT | \ +@@ -22,6 +23,7 @@ + #define ACPI_PDC_EST_CAPABILITY_SWSMP (ACPI_PDC_SMP_C1PT | \ + ACPI_PDC_C_C1_HALT | \ + ACPI_PDC_SMP_P_SWCOORD | \ ++ ACPI_PDC_SMP_P_HWCOORD | \ + ACPI_PDC_P_FFH) + + #define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \ diff --git a/queue-2.6.28/agp-intel-add-support-for-g41-chipset.patch b/queue-2.6.28/agp-intel-add-support-for-g41-chipset.patch new file mode 100644 index 00000000000..bb9e90cf7ae --- /dev/null +++ b/queue-2.6.28/agp-intel-add-support-for-g41-chipset.patch @@ -0,0 +1,64 @@ +From a50ccc6c6623ab0e64f2109881e07c176b2d876f Mon Sep 17 00:00:00 2001 +From: Zhenyu Wang +Date: Mon, 17 Nov 2008 14:39:00 +0800 +Subject: agp/intel: add support for G41 chipset + +From: Zhenyu Wang + +commit a50ccc6c6623ab0e64f2109881e07c176b2d876f upstream. + +Signed-off-by: Zhenyu Wang +Signed-off-by: Eric Anholt +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/agp/intel-agp.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/char/agp/intel-agp.c ++++ b/drivers/char/agp/intel-agp.c +@@ -40,6 +40,8 @@ + #define PCI_DEVICE_ID_INTEL_Q45_IG 0x2E12 + #define PCI_DEVICE_ID_INTEL_G45_HB 0x2E20 + #define PCI_DEVICE_ID_INTEL_G45_IG 0x2E22 ++#define PCI_DEVICE_ID_INTEL_G41_HB 0x2E30 ++#define PCI_DEVICE_ID_INTEL_G41_IG 0x2E32 + + /* cover 915 and 945 variants */ + #define IS_I915 (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_E7221_HB || \ +@@ -63,7 +65,8 @@ + #define IS_G4X (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_IGD_E_HB || \ + agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_Q45_HB || \ + agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G45_HB || \ +- agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_GM45_HB) ++ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_GM45_HB || \ ++ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_G41_HB) + + extern int agp_memory_reserved; + +@@ -1196,6 +1199,7 @@ static void intel_i965_get_gtt_range(int + case PCI_DEVICE_ID_INTEL_IGD_E_HB: + case PCI_DEVICE_ID_INTEL_Q45_HB: + case PCI_DEVICE_ID_INTEL_G45_HB: ++ case PCI_DEVICE_ID_INTEL_G41_HB: + *gtt_offset = *gtt_size = MB(2); + break; + default: +@@ -2163,6 +2167,8 @@ static const struct intel_driver_descrip + "Q45/Q43", NULL, &intel_i965_driver }, + { PCI_DEVICE_ID_INTEL_G45_HB, PCI_DEVICE_ID_INTEL_G45_IG, 0, + "G45/G43", NULL, &intel_i965_driver }, ++ { PCI_DEVICE_ID_INTEL_G41_HB, PCI_DEVICE_ID_INTEL_G41_IG, 0, ++ "G41", NULL, &intel_i965_driver }, + { 0, 0, 0, NULL, NULL, NULL } + }; + +@@ -2360,6 +2366,7 @@ static struct pci_device_id agp_intel_pc + ID(PCI_DEVICE_ID_INTEL_IGD_E_HB), + ID(PCI_DEVICE_ID_INTEL_Q45_HB), + ID(PCI_DEVICE_ID_INTEL_G45_HB), ++ ID(PCI_DEVICE_ID_INTEL_G41_HB), + { } + }; + diff --git a/queue-2.6.28/agp-intel-fix-broken-symbol-in-device-name.patch b/queue-2.6.28/agp-intel-fix-broken-symbol-in-device-name.patch new file mode 100644 index 00000000000..fc30cae27b6 --- /dev/null +++ b/queue-2.6.28/agp-intel-fix-broken-symbol-in-device-name.patch @@ -0,0 +1,31 @@ +From b854b2ab959e8175d75e01cf8ed452ed2624d0c8 Mon Sep 17 00:00:00 2001 +From: Eric Anholt +Date: Mon, 22 Dec 2008 18:56:27 -0800 +Subject: agp/intel: Fix broken ® symbol in device name. +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 8bit + +From: Eric Anholt + +commit b854b2ab959e8175d75e01cf8ed452ed2624d0c8 upstream. + +Signed-off-by: Eric Anholt +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/agp/intel-agp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/char/agp/intel-agp.c ++++ b/drivers/char/agp/intel-agp.c +@@ -2160,7 +2160,7 @@ static const struct intel_driver_descrip + { PCI_DEVICE_ID_INTEL_Q33_HB, PCI_DEVICE_ID_INTEL_Q33_IG, 0, "Q33", + NULL, &intel_g33_driver }, + { PCI_DEVICE_ID_INTEL_GM45_HB, PCI_DEVICE_ID_INTEL_GM45_IG, 0, +- "Mobile Intel? GM45 Express", NULL, &intel_i965_driver }, ++ "Mobile Intel® GM45 Express", NULL, &intel_i965_driver }, + { PCI_DEVICE_ID_INTEL_IGD_E_HB, PCI_DEVICE_ID_INTEL_IGD_E_IG, 0, + "Intel Integrated Graphics Device", NULL, &intel_i965_driver }, + { PCI_DEVICE_ID_INTEL_Q45_HB, PCI_DEVICE_ID_INTEL_Q45_IG, 0, diff --git a/queue-2.6.28/do_wp_page-fix-regression-with-execute-in-place.patch b/queue-2.6.28/do_wp_page-fix-regression-with-execute-in-place.patch new file mode 100644 index 00000000000..3c7b132dcd3 --- /dev/null +++ b/queue-2.6.28/do_wp_page-fix-regression-with-execute-in-place.patch @@ -0,0 +1,45 @@ +From ab92661d5d9514647346047f30f67a7f35ffea67 Mon Sep 17 00:00:00 2001 +From: Carsten Otte +Date: Wed, 4 Feb 2009 15:12:16 -0800 +Subject: do_wp_page: fix regression with execute in place + +From: Carsten Otte + +commit ab92661d5d9514647346047f30f67a7f35ffea67 upstream. + +Fix do_wp_page for VM_MIXEDMAP mappings. + +In the case where pfn_valid returns 0 for a pfn at the beginning of +do_wp_page and the mapping is not shared writable, the code branches to +label `gotten:' with old_page == NULL. + +In case the vma is locked (vma->vm_flags & VM_LOCKED), lock_page, +clear_page_mlock, and unlock_page try to access the old_page. + +This patch checks whether old_page is valid before it is dereferenced. + +The regression was introduced by "mlock: mlocked pages are unevictable" +(commit b291f000393f5a0b679012b39d79fbc85c018233). + +Signed-off-by: Carsten Otte +Cc: Nick Piggin +Cc: Heiko Carstens +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -1881,7 +1881,7 @@ gotten: + * Don't let another task, with possibly unlocked vma, + * keep the mlocked page. + */ +- if (vma->vm_flags & VM_LOCKED) { ++ if ((vma->vm_flags & VM_LOCKED) && old_page) { + lock_page(old_page); /* for LRU manipulation */ + clear_page_mlock(old_page); + unlock_page(old_page); diff --git a/queue-2.6.28/e1000-fix-bug-with-shared-interrupt-during-reset.patch b/queue-2.6.28/e1000-fix-bug-with-shared-interrupt-during-reset.patch new file mode 100644 index 00000000000..b8849def930 --- /dev/null +++ b/queue-2.6.28/e1000-fix-bug-with-shared-interrupt-during-reset.patch @@ -0,0 +1,40 @@ +From 15b2bee22a0390d951301b53e83df88d0350c499 Mon Sep 17 00:00:00 2001 +From: Jesse Brandeburg +Date: Tue, 27 Jan 2009 16:41:58 -0800 +Subject: e1000: fix bug with shared interrupt during reset + +From: Jesse Brandeburg + +commit 15b2bee22a0390d951301b53e83df88d0350c499 upstream. + +A nasty bug was found where an MTU change (or anything else that caused a +reset) could race with the interrupt code. The interrupt code was entered +by a shared interrupt during the MTU change. + +This change prevents the interrupt code from running while the driver is in +the middle of its reset path. + +Signed-off-by: Jesse Brandeburg +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- a/drivers/net/e1000/e1000_main.c ++++ b/drivers/net/e1000/e1000_main.c +@@ -31,7 +31,7 @@ + + char e1000_driver_name[] = "e1000"; + static char e1000_driver_string[] = "Intel(R) PRO/1000 Network Driver"; +-#define DRV_VERSION "7.3.20-k3-NAPI" ++#define DRV_VERSION "7.3.21-k3-NAPI" + const char e1000_driver_version[] = DRV_VERSION; + static const char e1000_copyright[] = "Copyright (c) 1999-2006 Intel Corporation."; + +@@ -3712,7 +3712,7 @@ static irqreturn_t e1000_intr(int irq, void *data) + struct e1000_hw *hw = &adapter->hw; + u32 rctl, icr = er32(ICR); + +- if (unlikely(!icr)) ++ if (unlikely((!icr) || test_bit(__E1000_RESETTING, &adapter->flags))) + return IRQ_NONE; /* Not our interrupt */ + + /* IMS will not auto-mask if INT_ASSERTED is not set, and if it is diff --git a/queue-2.6.28/e1000-fix-pci-enable-to-honor-the-need_ioport-flag.patch b/queue-2.6.28/e1000-fix-pci-enable-to-honor-the-need_ioport-flag.patch new file mode 100644 index 00000000000..d6458cb6fad --- /dev/null +++ b/queue-2.6.28/e1000-fix-pci-enable-to-honor-the-need_ioport-flag.patch @@ -0,0 +1,32 @@ +From 4d7155b932b8129c72e2f2714890e20b2a05e0b7 Mon Sep 17 00:00:00 2001 +From: Karsten Keil +Date: Tue, 3 Feb 2009 15:18:01 -0800 +Subject: e1000: Fix PCI enable to honor the need_ioport flag + +From: Karsten Keil + +commit 4d7155b932b8129c72e2f2714890e20b2a05e0b7 upstream. + +On machine were no IO ports are assigned the call +to pci_enable_device() will fail, even if need_ioport +is false, we need to use pci_enable_device_mem() here. + +Signed-off-by: Karsten Keil +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/e1000/e1000_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/e1000/e1000_main.c ++++ b/drivers/net/e1000/e1000_main.c +@@ -921,7 +921,7 @@ static int __devinit e1000_probe(struct + err = pci_enable_device(pdev); + } else { + bars = pci_select_bars(pdev, IORESOURCE_MEM); +- err = pci_enable_device(pdev); ++ err = pci_enable_device_mem(pdev); + } + if (err) + return err; diff --git a/queue-2.6.28/eeepc-laptop-add-support-for-extended-hotkeys.patch b/queue-2.6.28/eeepc-laptop-add-support-for-extended-hotkeys.patch new file mode 100644 index 00000000000..3ec3c121fd5 --- /dev/null +++ b/queue-2.6.28/eeepc-laptop-add-support-for-extended-hotkeys.patch @@ -0,0 +1,34 @@ +From b5f6f26550700445dcc125bbf75b9104e779d353 Mon Sep 17 00:00:00 2001 +From: Matthew Garrett +Date: Tue, 20 Jan 2009 16:17:46 +0100 +Subject: eeepc-laptop: Add support for extended hotkeys + +From: Matthew Garrett + +commit b5f6f26550700445dcc125bbf75b9104e779d353 upstream. + +Newer Eees have extra hotkeys above the function keys. This patch adds support +for sending them through the input layer. + +Signed-off-by: Matthew Garrett +Signed-off-by: Corentin Chary +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/eeepc-laptop.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/misc/eeepc-laptop.c ++++ b/drivers/misc/eeepc-laptop.c +@@ -161,6 +161,10 @@ static struct key_entry eeepc_keymap[] = + {KE_KEY, 0x13, KEY_MUTE }, + {KE_KEY, 0x14, KEY_VOLUMEDOWN }, + {KE_KEY, 0x15, KEY_VOLUMEUP }, ++ {KE_KEY, 0x1a, KEY_COFFEE }, ++ {KE_KEY, 0x1b, KEY_ZOOM }, ++ {KE_KEY, 0x1c, KEY_PROG2 }, ++ {KE_KEY, 0x1d, KEY_PROG3 }, + {KE_KEY, 0x30, KEY_SWITCHVIDEOMODE }, + {KE_KEY, 0x31, KEY_SWITCHVIDEOMODE }, + {KE_KEY, 0x32, KEY_SWITCHVIDEOMODE }, diff --git a/queue-2.6.28/eeepc-laptop-fix-oops-when-changing-backlight-brightness-during-eeepc-laptop-init.patch b/queue-2.6.28/eeepc-laptop-fix-oops-when-changing-backlight-brightness-during-eeepc-laptop-init.patch new file mode 100644 index 00000000000..7653bb260d1 --- /dev/null +++ b/queue-2.6.28/eeepc-laptop-fix-oops-when-changing-backlight-brightness-during-eeepc-laptop-init.patch @@ -0,0 +1,65 @@ +From 7695fb04aca62e2d8a7ca6ede50f6211e1d71e53 Mon Sep 17 00:00:00 2001 +From: Darren Salt +Date: Sat, 7 Feb 2009 01:02:07 -0500 +Subject: eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init + +From: Darren Salt + +commit 7695fb04aca62e2d8a7ca6ede50f6211e1d71e53 upstream. + +I got the following oops while changing the backlight brightness during +startup. When it happens, it prevents use of the hotkeys, Fn-Fx, and the +lid button. + +It's a clear use-before-init, as I verified by testing with an +appropriately-placed "else printk". + +BUG: unable to handle kernel NULL pointer dereference at 00000000 +*pde = 00000000 +Oops: 0002 [#1] PREEMPT SMP +Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901 +EIP: 0060:[] [] eeepc_hotk_notify+26/da +EFLAGS: 00010246 CPU: 1 +Using defaults from ksymoops -t elf32-i386 -a i386 +EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64 +ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80 + DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 + f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f + f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80 + c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091 +Call Trace: + [] ? acpi_ev_notify_dispatch+4c/55 + [] ? acpi_os_execute_deferred+1d/25 + [] ? run_workqueue+71/f1 + [] ? worker_thread+0/bf + [] ? worker_thread+b4/bf + [] ? autoremove_wake_function+0/2b + [] ? worker_thread+0/bf + [] ? kthread+38/5f + [] ? kthread+0/5f + [] ? kernel_thread_helper+7/10 +Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42 +e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c +50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01 + +Signed-off-by: Darren Salt +Signed-off-by: Andrew Morton +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/eeepc-laptop.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/misc/eeepc-laptop.c ++++ b/drivers/misc/eeepc-laptop.c +@@ -510,7 +510,8 @@ static int eeepc_hotk_check(void) + static void notify_brn(void) + { + struct backlight_device *bd = eeepc_backlight_device; +- bd->props.brightness = read_brightness(bd); ++ if (bd) ++ bd->props.brightness = read_brightness(bd); + } + + static void eeepc_hotk_notify(acpi_handle handle, u32 event, void *data) diff --git a/queue-2.6.28/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch b/queue-2.6.28/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch new file mode 100644 index 00000000000..560752be2a7 --- /dev/null +++ b/queue-2.6.28/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch @@ -0,0 +1,54 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 11:54:50 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:04:09 +0100 (CET) +Subject: firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + +From: Stefan Richter + +Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream. + +Camcorders have a tendency to fail read requests to their config ROM and +write request to their FCP command register with ack_busy_X. This has +become a problem with newer kernels and especially Panasonic camcorders, +causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently +logs "send oops"; kino reports loss of AV/C control. I suspect that +lower CPU scheduling latencies in newer kernels made this issue more +prominent now. + +According to +https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 +this can be fixed by configuring the FireWire controller for more +hardware retries for request transmission; these retries are evidently +more successful than libavc1394's own retry loop (typically 3 tries on +top of hardware retries). + +Presumably the same issue has been reported at +https://bugzilla.redhat.com/show_bug.cgi?id=449252 and +https://bugzilla.redhat.com/show_bug.cgi?id=477279 . + +In a quick test with a JVC camcorder (which didn't malfunction like the +reported camcorders), this change decreased the number of ack_busy_X +from 16 in three runs of dvgrab to 4 in three runs of the same capture +duration. + +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-ohci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/firewire/fw-ohci.c ++++ b/drivers/firewire/fw-ohci.c +@@ -226,7 +226,7 @@ static inline struct fw_ohci *fw_ohci(st + #define CONTEXT_DEAD 0x0800 + #define CONTEXT_ACTIVE 0x0400 + +-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2 ++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf + #define OHCI1394_MAX_AT_RESP_RETRIES 0x2 + #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8 + diff --git a/queue-2.6.28/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch b/queue-2.6.28/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch new file mode 100644 index 00000000000..f6e001464e0 --- /dev/null +++ b/queue-2.6.28/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch @@ -0,0 +1,63 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 11:56:04 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:05:25 +0100 (CET) +Subject: firewire: sbp2: add workarounds for 2nd and 3rd generation iPods +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + +From: Stefan Richter + +Commit c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 upstream. + +According to https://bugs.launchpad.net/bugs/294391 + - 3rd generation iPods need the "fix capacity" workaround after all + (apparently they crash after the last sector was accessed), + - 2nd generation iPods need the "128 kB maximum request size" + workaround. + +Alas both iPod generations feature the same model ID in the config ROM, +hence we can only define a shared quirks list entry for them. Luckily +the fix capacity workaround did not show a negative effect in Jarod's +tests with 2nd gen. iPod. + +A side note: Apple computers in target mode (or at least an x86 Mac +mini) don't have firmware_version and model_id, hence none of the iPod +quirks list entries is active for them. + +Tested-by: Jarod Wilson +Acked-by: Jarod Wilson +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-sbp2.c | 16 +++++++++------- + 1 file changed, 9 insertions(+), 7 deletions(-) + +--- a/drivers/firewire/fw-sbp2.c ++++ b/drivers/firewire/fw-sbp2.c +@@ -357,15 +357,17 @@ static const struct { + .model = ~0, + .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS, + }, +- + /* +- * There are iPods (2nd gen, 3rd gen) with model_id == 0, but +- * these iPods do not feature the read_capacity bug according +- * to one report. Read_capacity behaviour as well as model_id +- * could change due to Apple-supplied firmware updates though. ++ * iPod 2nd generation: needs 128k max transfer size workaround ++ * iPod 3rd generation: needs fix capacity workaround + */ +- +- /* iPod 4th generation. */ { ++ { ++ .firmware_revision = 0x0a2700, ++ .model = 0x000000, ++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS | ++ SBP2_WORKAROUND_FIX_CAPACITY, ++ }, ++ /* iPod 4th generation */ { + .firmware_revision = 0x0a2700, + .model = 0x000021, + .workarounds = SBP2_WORKAROUND_FIX_CAPACITY, diff --git a/queue-2.6.28/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch b/queue-2.6.28/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch new file mode 100644 index 00000000000..adfd00444f5 --- /dev/null +++ b/queue-2.6.28/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch @@ -0,0 +1,72 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 11:55:20 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:04:45 +0100 (CET) +Subject: firewire: sbp2: fix DMA mapping leak on the failure path +To: stable@kernel.org +Message-ID: + +From: Stefan Richter + +Commit 5e2125677fd72d36396cc537466e07ffcbbd4b2b upstream. + +Reported-by: FUJITA Tomonori +who also provided a first version of the fix. + +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-sbp2.c | 27 +++++++++++++++++---------- + 1 file changed, 17 insertions(+), 10 deletions(-) + +--- a/drivers/firewire/fw-sbp2.c ++++ b/drivers/firewire/fw-sbp2.c +@@ -1282,6 +1282,19 @@ static struct fw_driver sbp2_driver = { + .id_table = sbp2_id_table, + }; + ++static void sbp2_unmap_scatterlist(struct device *card_device, ++ struct sbp2_command_orb *orb) ++{ ++ if (scsi_sg_count(orb->cmd)) ++ dma_unmap_sg(card_device, scsi_sglist(orb->cmd), ++ scsi_sg_count(orb->cmd), ++ orb->cmd->sc_data_direction); ++ ++ if (orb->request.misc & cpu_to_be32(COMMAND_ORB_PAGE_TABLE_PRESENT)) ++ dma_unmap_single(card_device, orb->page_table_bus, ++ sizeof(orb->page_table), DMA_TO_DEVICE); ++} ++ + static unsigned int + sbp2_status_to_sense_data(u8 *sbp2_status, u8 *sense_data) + { +@@ -1361,15 +1374,7 @@ complete_command_orb(struct sbp2_orb *ba + + dma_unmap_single(device->card->device, orb->base.request_bus, + sizeof(orb->request), DMA_TO_DEVICE); +- +- if (scsi_sg_count(orb->cmd) > 0) +- dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd), +- scsi_sg_count(orb->cmd), +- orb->cmd->sc_data_direction); +- +- if (orb->page_table_bus != 0) +- dma_unmap_single(device->card->device, orb->page_table_bus, +- sizeof(orb->page_table), DMA_TO_DEVICE); ++ sbp2_unmap_scatterlist(device->card->device, orb); + + orb->cmd->result = result; + orb->done(orb->cmd); +@@ -1500,8 +1505,10 @@ static int sbp2_scsi_queuecommand(struct + orb->base.request_bus = + dma_map_single(device->card->device, &orb->request, + sizeof(orb->request), DMA_TO_DEVICE); +- if (dma_mapping_error(device->card->device, orb->base.request_bus)) ++ if (dma_mapping_error(device->card->device, orb->base.request_bus)) { ++ sbp2_unmap_scatterlist(device->card->device, orb); + goto out; ++ } + + sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, generation, + lu->command_block_agent_address + SBP2_ORB_POINTER); diff --git a/queue-2.6.28/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch b/queue-2.6.28/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch new file mode 100644 index 00000000000..8a67cf36090 --- /dev/null +++ b/queue-2.6.28/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch @@ -0,0 +1,51 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 11:54:08 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:03:22 +0100 (CET) +Subject: ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + + +From: Stefan Richter + +Commit 64c634ef83991b390ec0503e61f16efb0ba3c60b upstream. + +Camcorders have a tendency to fail read requests to their config ROM and +write request to their FCP command register with ack_busy_X. This has +become a problem with newer kernels and especially Panasonic camcorders, +causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently +logs "send oops"; kino reports loss of AV/C control. I suspect that +lower CPU scheduling latencies in newer kernels made this issue more +prominent now. + +According to +https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 +this can be fixed by configuring the FireWire controller for more +hardware retries for request transmission; these retries are evidently +more successful than libavc1394's own retry loop (typically 3 tries on +top of hardware retries). + +Presumably the same issue has been reported at +https://bugzilla.redhat.com/show_bug.cgi?id=449252 and +https://bugzilla.redhat.com/show_bug.cgi?id=477279 . + +Tested-by: Mathias Beilstein +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ieee1394/ohci1394.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ieee1394/ohci1394.h ++++ b/drivers/ieee1394/ohci1394.h +@@ -26,7 +26,7 @@ + + #define OHCI1394_DRIVER_NAME "ohci1394" + +-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2 ++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf + #define OHCI1394_MAX_AT_RESP_RETRIES 0x2 + #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8 + #define OHCI1394_MAX_SELF_ID_ERRORS 16 diff --git a/queue-2.6.28/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch b/queue-2.6.28/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch new file mode 100644 index 00000000000..63971341658 --- /dev/null +++ b/queue-2.6.28/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch @@ -0,0 +1,44 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 11:56:31 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:06:06 +0100 (CET) +Subject: ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + +From: Stefan Richter + +Commit 1448d7c6a2ff96d3b52ecae49e2d0f046a097fe0 upstream. + +As per https://bugs.launchpad.net/bugs/294391. These got one sample of +each iPod generation going. However there still occurred I/O stalls +with the 3rd generation iPod which remain undiagnosed at the time of +this writing. + +Acked-by: Jarod Wilson +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ieee1394/sbp2.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/ieee1394/sbp2.c ++++ b/drivers/ieee1394/sbp2.c +@@ -395,6 +395,16 @@ static const struct { + .model_id = SBP2_ROM_VALUE_WILDCARD, + .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS, + }, ++ /* ++ * iPod 2nd generation: needs 128k max transfer size workaround ++ * iPod 3rd generation: needs fix capacity workaround ++ */ ++ { ++ .firmware_revision = 0x0a2700, ++ .model_id = 0x000000, ++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS | ++ SBP2_WORKAROUND_FIX_CAPACITY, ++ }, + /* iPod 4th generation */ { + .firmware_revision = 0x0a2700, + .model_id = 0x000021, diff --git a/queue-2.6.28/md-ensure-an-md-array-never-has-too-many-devices.patch b/queue-2.6.28/md-ensure-an-md-array-never-has-too-many-devices.patch new file mode 100644 index 00000000000..4ec15f58e7f --- /dev/null +++ b/queue-2.6.28/md-ensure-an-md-array-never-has-too-many-devices.patch @@ -0,0 +1,88 @@ +From de01dfadf25bf83cfe3d85c163005c4320532658 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 6 Feb 2009 18:02:46 +1100 +Subject: md: Ensure an md array never has too many devices. + +From: NeilBrown + +commit de01dfadf25bf83cfe3d85c163005c4320532658 upstream. + +Each different metadata format supported by md supports a +different maximum number of devices. +We really should be enforcing this maximum in the kernel, but +we aren't quite doing that properly. + +We currently only enforce it at the 'hot_add' point, which is an +older interface which is not used by current userspace. + +We need to also enforce it at 'add_new_disk' time for active arrays +and at 'do_md_run' time when starting a new array. + +So move the test from 'hot_add' into 'bind_rdev_to_array' which is +called from both 'hot_add' and 'add_new_disk, and add a new +test in 'analyse_sbs' which is called from 'do_md_run'. + +This bug (or missing feature) has been around "forever" and so +the patch is suitable for any -stable that is currently maintained. + +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/md.c | 24 ++++++++++++++---------- + 1 file changed, 14 insertions(+), 10 deletions(-) + +--- a/drivers/md/md.c ++++ b/drivers/md/md.c +@@ -1447,6 +1447,11 @@ static int bind_rdev_to_array(mdk_rdev_t + if (find_rdev_nr(mddev, rdev->desc_nr)) + return -EBUSY; + } ++ if (mddev->max_disks && rdev->desc_nr >= mddev->max_disks) { ++ printk(KERN_WARNING "md: %s: array is limited to %d devices\n", ++ mdname(mddev), mddev->max_disks); ++ return -EBUSY; ++ } + bdevname(rdev->bdev,b); + while ( (s=strchr(b, '/')) != NULL) + *s = '!'; +@@ -2355,6 +2360,15 @@ static void analyze_sbs(mddev_t * mddev) + + i = 0; + rdev_for_each(rdev, tmp, mddev) { ++ if (rdev->desc_nr >= mddev->max_disks || ++ i > mddev->max_disks) { ++ printk(KERN_WARNING ++ "md: %s: %s: only %d devices permitted\n", ++ mdname(mddev), bdevname(rdev->bdev, b), ++ mddev->max_disks); ++ kick_rdev_from_array(rdev); ++ continue; ++ } + if (rdev != freshest) + if (super_types[mddev->major_version]. + validate_super(mddev, rdev)) { +@@ -4448,13 +4462,6 @@ static int hot_add_disk(mddev_t * mddev, + * noticed in interrupt contexts ... + */ + +- if (rdev->desc_nr == mddev->max_disks) { +- printk(KERN_WARNING "%s: can not hot-add to full array!\n", +- mdname(mddev)); +- err = -EBUSY; +- goto abort_unbind_export; +- } +- + rdev->raid_disk = -1; + + md_update_sb(mddev, 1); +@@ -4468,9 +4475,6 @@ static int hot_add_disk(mddev_t * mddev, + md_new_event(mddev); + return 0; + +-abort_unbind_export: +- unbind_rdev_from_array(rdev); +- + abort_export: + export_rdev(rdev); + return err; diff --git a/queue-2.6.28/md-fix-a-bug-in-linear.c-causing-which_dev-to-return-the-wrong-device.patch b/queue-2.6.28/md-fix-a-bug-in-linear.c-causing-which_dev-to-return-the-wrong-device.patch new file mode 100644 index 00000000000..0eb19a24a10 --- /dev/null +++ b/queue-2.6.28/md-fix-a-bug-in-linear.c-causing-which_dev-to-return-the-wrong-device.patch @@ -0,0 +1,60 @@ +From 852c8bf484a0e17ee27f413ef26e87f522af5607 Mon Sep 17 00:00:00 2001 +From: Andre Noll +Date: Fri, 6 Feb 2009 15:10:52 +1100 +Subject: md: Fix a bug in linear.c causing which_dev() to return the wrong device. + +From: Andre Noll + +commit 852c8bf484a0e17ee27f413ef26e87f522af5607 upstream. + +ab5bd5cbc8d4b868378d062eed3d4240930fbb86 introduced the following +bug in linear software raid for large arrays on 32 bit machines: + +which_dev() computes the device holding a given sector by shifting +down the sector number to a 32 bit range, dividing by the array +spacing and looking up the resulting index in the hash table of +the array. + +Because the computed index might be slightly too small, a loop at +the end of which_dev() increases the index until the given sector +actually falls into the range of the device associated with that index. + +The changes of the above mentioned commit caused this loop to check +whether the _index_ rather than the sector number is small enough, +effectively bypassing the loop and thus possibly returning the wrong +device. + +As reported by Simon Kirby, this leads to errors such as + + linear_make_request: Sector 2340486136 out of bounds on dev sdi: 156301312 sectors, offset 2109870464 + +Fix this bug by introducing a local variable for the index so that +the variable containing the passed sector is left unchanged. + +Signed-off-by: Andre Noll +Signed-off-by: NeilBrown +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/linear.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/md/linear.c ++++ b/drivers/md/linear.c +@@ -25,13 +25,13 @@ static inline dev_info_t *which_dev(mdde + { + dev_info_t *hash; + linear_conf_t *conf = mddev_to_conf(mddev); ++ sector_t idx = sector >> conf->sector_shift; + + /* + * sector_div(a,b) returns the remainer and sets a to a/b + */ +- sector >>= conf->sector_shift; +- (void)sector_div(sector, conf->spacing); +- hash = conf->hash_table[sector]; ++ (void)sector_div(idx, conf->spacing); ++ hash = conf->hash_table[idx]; + + while (sector >= hash->num_sectors + hash->start_sector) + hash++; diff --git a/queue-2.6.28/module-remove-over-zealous-check-in-__module_get.patch b/queue-2.6.28/module-remove-over-zealous-check-in-__module_get.patch new file mode 100644 index 00000000000..47412e3964a --- /dev/null +++ b/queue-2.6.28/module-remove-over-zealous-check-in-__module_get.patch @@ -0,0 +1,37 @@ +From 7f9a50a5b89b87f8e754f59ae9968da28be618a5 Mon Sep 17 00:00:00 2001 +From: Rusty Russell +Date: Sat, 7 Feb 2009 18:15:56 +1030 +Subject: module: remove over-zealous check in __module_get() + +From: Rusty Russell + +commit 7f9a50a5b89b87f8e754f59ae9968da28be618a5 upstream. + +Impact: fix spurious BUG_ON() triggered under load + +module_refcount() isn't reliable outside stop_machine(), as demonstrated +by Karsten Keil , networking can trigger it under load +(an inc on one cpu and dec on another while module_refcount() is tallying + can give false results, for example). + +Almost noone should be using __module_get, but that's another issue. + +Cc: Karsten Keil +Signed-off-by: Rusty Russell +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/module.h | 1 - + 1 file changed, 1 deletion(-) + +--- a/include/linux/module.h ++++ b/include/linux/module.h +@@ -391,7 +391,6 @@ void symbol_put_addr(void *addr); + static inline void __module_get(struct module *module) + { + if (module) { +- BUG_ON(module_refcount(module) == 0); + local_inc(&module->ref[get_cpu()].count); + put_cpu(); + } diff --git a/queue-2.6.28/prevent-kprobes-from-catching-spurious-page-faults.patch b/queue-2.6.28/prevent-kprobes-from-catching-spurious-page-faults.patch new file mode 100644 index 00000000000..11622294519 --- /dev/null +++ b/queue-2.6.28/prevent-kprobes-from-catching-spurious-page-faults.patch @@ -0,0 +1,51 @@ +From 9be260a646bf76fa418ee519afa10196b3164681 Mon Sep 17 00:00:00 2001 +From: Masami Hiramatsu +Date: Thu, 5 Feb 2009 17:12:39 -0500 +Subject: prevent kprobes from catching spurious page faults + +From: Masami Hiramatsu + +commit 9be260a646bf76fa418ee519afa10196b3164681 upstream. + +Prevent kprobes from catching spurious faults which will cause infinite +recursive page-fault and memory corruption by stack overflow. + +Signed-off-by: Masami Hiramatsu +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/mm/fault.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/arch/x86/mm/fault.c ++++ b/arch/x86/mm/fault.c +@@ -601,8 +601,6 @@ void __kprobes do_page_fault(struct pt_r + + si_code = SEGV_MAPERR; + +- if (notify_page_fault(regs)) +- return; + if (unlikely(kmmio_fault(regs, address))) + return; + +@@ -632,6 +630,9 @@ void __kprobes do_page_fault(struct pt_r + if (spurious_fault(address, error_code)) + return; + ++ /* kprobes don't want to hook the spurious faults. */ ++ if (notify_page_fault(regs)) ++ return; + /* + * Don't take the mm semaphore here. If we fixup a prefetch + * fault we could otherwise deadlock. +@@ -639,6 +640,9 @@ void __kprobes do_page_fault(struct pt_r + goto bad_area_nosemaphore; + } + ++ /* kprobes don't want to hook the spurious faults. */ ++ if (notify_page_fault(regs)) ++ return; + + /* + * It's safe to allow irq's after cr2 has been saved and the diff --git a/queue-2.6.28/revert-rlimit-permit-setting-rlimit_nofile-to-rlim_infinity.patch b/queue-2.6.28/revert-rlimit-permit-setting-rlimit_nofile-to-rlim_infinity.patch new file mode 100644 index 00000000000..ce78e3c2d79 --- /dev/null +++ b/queue-2.6.28/revert-rlimit-permit-setting-rlimit_nofile-to-rlim_infinity.patch @@ -0,0 +1,102 @@ +From 60fd760fb9ff7034360bab7137c917c0330628c2 Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Wed, 4 Feb 2009 15:12:06 -0800 +Subject: revert "rlimit: permit setting RLIMIT_NOFILE to RLIM_INFINITY" + +From: Andrew Morton + +commit 60fd760fb9ff7034360bab7137c917c0330628c2 upstream. + +Revert commit 0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f because it causes +(arguably poorly designed) existing userspace to spend interminable +periods closing billions of not-open file descriptors. + +We could bring this back, with some sort of opt-in tunable in /proc, which +defaults to "off". + +Peter's alanysis follows: + +: I spent several hours trying to get to the bottom of a serious +: performance issue that appeared on one of our servers after upgrading to +: 2.6.28. In the end it's what could be considered a userspace bug that +: was triggered by a change in 2.6.28. Since this might also affect other +: people I figured I'd at least document what I found here, and maybe we +: can even do something about it: +: +: +: So, I upgraded some of debian.org's machines to 2.6.28.1 and immediately +: the team maintaining our ftp archive complained that one of their +: scripts that previously ran in a few minutes still hadn't even come +: close to being done after an hour or so. Downgrading to 2.6.27 fixed +: that. +: +: Turns out that script is forking a lot and something in it or python or +: whereever closes all the file descriptors it doesn't want to pass on. +: That is, it starts at zero and goes up to ulimit -n/RLIMIT_NOFILE and +: closes them all with a few exceptions. +: +: Turns out that takes a long time when your limit -n is now 2^20 (1048576). +: +: With 2.6.27.* the ulimit -n was the standard 1024, but with 2.6.28 it is +: now a thousand times that. +: +: 2.6.28 included a patch titled "rlimit: permit setting RLIMIT_NOFILE to +: RLIM_INFINITY" (0c2d64fb6cae9aae480f6a46cfe79f8d7d48b59f)[1] that +: allows, as the title implies, to set the limit for number of files to +: infinity. +: +: Closer investigation showed that the broken default ulimit did not apply +: to "system" processes (like stuff started from init). In the end I +: could establish that all processes that passed through pam_limit at one +: point had the bad resource limit. +: +: Apparently the pam library in Debian etch (4.0) initializes the limits +: to some default values when it doesn't have any settings in limit.conf +: to override them. Turns out that for nofiles this is RLIM_INFINITY. +: Commenting out "case RLIMIT_NOFILE" in pam_limit.c:267 of our pam +: package version 0.79-5 fixes that - tho I'm not sure what side effects +: that has. +: +: Debian lenny (the upcoming 5.0 version) doesn't have this issue as it +: uses a different pam (version). + +Reported-by: Peter Palfrader +Cc: Adam Tkac +Cc: Michael Kerrisk +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sys.c | 16 ++++------------ + 1 file changed, 4 insertions(+), 12 deletions(-) + +--- a/kernel/sys.c ++++ b/kernel/sys.c +@@ -1447,22 +1447,14 @@ SYSCALL_DEFINE2(setrlimit, unsigned int, + return -EINVAL; + if (copy_from_user(&new_rlim, rlim, sizeof(*rlim))) + return -EFAULT; ++ if (new_rlim.rlim_cur > new_rlim.rlim_max) ++ return -EINVAL; + old_rlim = current->signal->rlim + resource; + if ((new_rlim.rlim_max > old_rlim->rlim_max) && + !capable(CAP_SYS_RESOURCE)) + return -EPERM; +- +- if (resource == RLIMIT_NOFILE) { +- if (new_rlim.rlim_max == RLIM_INFINITY) +- new_rlim.rlim_max = sysctl_nr_open; +- if (new_rlim.rlim_cur == RLIM_INFINITY) +- new_rlim.rlim_cur = sysctl_nr_open; +- if (new_rlim.rlim_max > sysctl_nr_open) +- return -EPERM; +- } +- +- if (new_rlim.rlim_cur > new_rlim.rlim_max) +- return -EINVAL; ++ if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open) ++ return -EPERM; + + retval = security_task_setrlimit(resource, &new_rlim); + if (retval) diff --git a/queue-2.6.28/serial-rs485-ioctl-structure-uses-__u32-include-linux-types.h.patch b/queue-2.6.28/serial-rs485-ioctl-structure-uses-__u32-include-linux-types.h.patch new file mode 100644 index 00000000000..dd0e293294e --- /dev/null +++ b/queue-2.6.28/serial-rs485-ioctl-structure-uses-__u32-include-linux-types.h.patch @@ -0,0 +1,58 @@ +From 60c20fb8c00a2b23308ae4517f145383bc66d291 Mon Sep 17 00:00:00 2001 +From: Andy Whitcroft +Date: Fri, 2 Jan 2009 13:49:04 +0000 +Subject: serial: RS485 ioctl structure uses __u32 include linux/types.h +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 8bit + +From: Andy Whitcroft + +commit 60c20fb8c00a2b23308ae4517f145383bc66d291 upstream. + +In the commit below a new struct serial_rs485 was introduced for a new +ioctl: + + commit c26c56c0f40e200e61d1390629c806f6adaffbcc + Author: Alan Cox + Date: Mon Oct 13 10:37:48 2008 +0100 + + tty: Cris has a nice RS485 ioctl so we should steal it + +This structure uses the __u32 types for some of its members, which leads +to the following compile error: + + $ cc -I.../include -c X.c + In file included from X.c:2: .../include/linux/serial.h:185: + error: expected specifier-qualifier-list before ‘__u32’ + $ + +It seems that these types are appropriate for this structure as it is +to be exposed to userspace. These types are available via linux/types.h +so move the include of that outside the __KERNEL__ section. + +Signed-off-by: Andy Whitcroft +Signed-off-by: Andrew Morton +Signed-off-by: Alan Cox +Signed-off-by: Linus Torvalds +Cc: Matthew Burgess +Signed-off-by: Greg Kroah-Hartman + + +--- + include/linux/serial.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/include/linux/serial.h ++++ b/include/linux/serial.h +@@ -10,8 +10,9 @@ + #ifndef _LINUX_SERIAL_H + #define _LINUX_SERIAL_H + +-#ifdef __KERNEL__ + #include ++ ++#ifdef __KERNEL__ + #include + + /* diff --git a/queue-2.6.28/series b/queue-2.6.28/series new file mode 100644 index 00000000000..c97da793564 --- /dev/null +++ b/queue-2.6.28/series @@ -0,0 +1,25 @@ +sgi-xp-fix-writing-past-the-end-of-kzalloc-d-space.patch +do_wp_page-fix-regression-with-execute-in-place.patch +wait-prevent-exclusive-waiter-starvation.patch +shm-fix-shmctl-lockup-with-config_shmem.patch +revert-rlimit-permit-setting-rlimit_nofile-to-rlim_infinity.patch +prevent-kprobes-from-catching-spurious-page-faults.patch +sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch +md-ensure-an-md-array-never-has-too-many-devices.patch +md-fix-a-bug-in-linear.c-causing-which_dev-to-return-the-wrong-device.patch +acpi-enable-bit-11-in-_pdc-to-advertise-hw-coord.patch +acpi-dock-don-t-eval-_sta-on-every-show_docked-sysfs-read.patch +ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch +firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch +firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch +firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch +ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch +module-remove-over-zealous-check-in-__module_get.patch +serial-rs485-ioctl-structure-uses-__u32-include-linux-types.h.patch +x86-apic-enable-workaround-on-amd-fam10h-cpus.patch +eeepc-laptop-fix-oops-when-changing-backlight-brightness-during-eeepc-laptop-init.patch +eeepc-laptop-add-support-for-extended-hotkeys.patch +e1000-fix-bug-with-shared-interrupt-during-reset.patch +e1000-fix-pci-enable-to-honor-the-need_ioport-flag.patch +agp-intel-add-support-for-g41-chipset.patch +agp-intel-fix-broken-symbol-in-device-name.patch diff --git a/queue-2.6.28/sgi-xp-fix-writing-past-the-end-of-kzalloc-d-space.patch b/queue-2.6.28/sgi-xp-fix-writing-past-the-end-of-kzalloc-d-space.patch new file mode 100644 index 00000000000..e7358278fb2 --- /dev/null +++ b/queue-2.6.28/sgi-xp-fix-writing-past-the-end-of-kzalloc-d-space.patch @@ -0,0 +1,79 @@ +From 361916a943cd9dbda1c0b00879d0225cc919d868 Mon Sep 17 00:00:00 2001 +From: Dean Nelson +Date: Wed, 4 Feb 2009 15:12:24 -0800 +Subject: sgi-xp: fix writing past the end of kzalloc()'d space + +From: Dean Nelson + +commit 361916a943cd9dbda1c0b00879d0225cc919d868 upstream. + +A missing type cast results in writing way beyond the end of a kzalloc()'d +memory segment resulting in slab corruption. But it seems like the better +solution is to define ->recv_msg_slots as a 'void *' rather than a +'struct xpc_notify_mq_msg_uv *' and add the type cast. + +Signed-off-by: Dean Nelson +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/sgi-xp/xpc.h | 5 +++-- + drivers/misc/sgi-xp/xpc_uv.c | 11 +++++------ + 2 files changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/misc/sgi-xp/xpc.h ++++ b/drivers/misc/sgi-xp/xpc.h +@@ -3,7 +3,7 @@ + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * +- * Copyright (c) 2004-2008 Silicon Graphics, Inc. All Rights Reserved. ++ * Copyright (c) 2004-2009 Silicon Graphics, Inc. All Rights Reserved. + */ + + /* +@@ -502,7 +502,8 @@ struct xpc_channel_uv { + /* partition's notify mq */ + + struct xpc_send_msg_slot_uv *send_msg_slots; +- struct xpc_notify_mq_msg_uv *recv_msg_slots; ++ void *recv_msg_slots; /* each slot will hold a xpc_notify_mq_msg_uv */ ++ /* structure plus the user's payload */ + + struct xpc_fifo_head_uv msg_slot_free_list; + struct xpc_fifo_head_uv recv_msg_list; /* deliverable payloads */ +--- a/drivers/misc/sgi-xp/xpc_uv.c ++++ b/drivers/misc/sgi-xp/xpc_uv.c +@@ -3,7 +3,7 @@ + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * +- * Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved. ++ * Copyright (c) 2008-2009 Silicon Graphics, Inc. All Rights Reserved. + */ + + /* +@@ -825,8 +825,8 @@ xpc_allocate_recv_msg_slot_uv(struct xpc + continue; + + for (entry = 0; entry < nentries; entry++) { +- msg_slot = ch_uv->recv_msg_slots + entry * +- ch->entry_size; ++ msg_slot = ch_uv->recv_msg_slots + ++ entry * ch->entry_size; + + msg_slot->hdr.msg_slot_number = entry; + } +@@ -1123,9 +1123,8 @@ xpc_handle_notify_mq_msg_uv(struct xpc_p + /* we're dealing with a normal message sent via the notify_mq */ + ch_uv = &ch->sn.uv; + +- msg_slot = (struct xpc_notify_mq_msg_uv *)((u64)ch_uv->recv_msg_slots + +- (msg->hdr.msg_slot_number % ch->remote_nentries) * +- ch->entry_size); ++ msg_slot = ch_uv->recv_msg_slots + ++ (msg->hdr.msg_slot_number % ch->remote_nentries) * ch->entry_size; + + BUG_ON(msg->hdr.msg_slot_number != msg_slot->hdr.msg_slot_number); + BUG_ON(msg_slot->hdr.size != 0); diff --git a/queue-2.6.28/shm-fix-shmctl-lockup-with-config_shmem.patch b/queue-2.6.28/shm-fix-shmctl-lockup-with-config_shmem.patch new file mode 100644 index 00000000000..be496f6bcde --- /dev/null +++ b/queue-2.6.28/shm-fix-shmctl-lockup-with-config_shmem.patch @@ -0,0 +1,50 @@ +From a68e61e8ff2d46327a37b69056998b47745db6fa Mon Sep 17 00:00:00 2001 +From: Tony Battersby +Date: Wed, 4 Feb 2009 15:12:04 -0800 +Subject: shm: fix shmctl(SHM_INFO) lockup with !CONFIG_SHMEM + +From: Tony Battersby + +commit a68e61e8ff2d46327a37b69056998b47745db6fa upstream. + +shm_get_stat() assumes that the inode is a "struct shmem_inode_info", +which is incorrect for !CONFIG_SHMEM (see fs/ramfs/inode.c: +ramfs_get_inode() vs. mm/shmem.c: shmem_get_inode()). + +This bad assumption can cause shmctl(SHM_INFO) to lockup when +shm_get_stat() tries to spin_lock(&info->lock). Users of !CONFIG_SHMEM +may encounter this lockup simply by invoking the 'ipcs' command. + +Reported by Jiri Olsa back in February 2008: +http://lkml.org/lkml/2008/2/29/74 + +Signed-off-by: Tony Battersby +Cc: Jiri Kosina +Reported-by: Jiri Olsa +Cc: Hugh Dickins +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + ipc/shm.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/ipc/shm.c ++++ b/ipc/shm.c +@@ -565,11 +565,15 @@ static void shm_get_stat(struct ipc_name + struct hstate *h = hstate_file(shp->shm_file); + *rss += pages_per_huge_page(h) * mapping->nrpages; + } else { ++#ifdef CONFIG_SHMEM + struct shmem_inode_info *info = SHMEM_I(inode); + spin_lock(&info->lock); + *rss += inode->i_mapping->nrpages; + *swp += info->swapped; + spin_unlock(&info->lock); ++#else ++ *rss += inode->i_mapping->nrpages; ++#endif + } + + total++; diff --git a/queue-2.6.28/sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch b/queue-2.6.28/sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch new file mode 100644 index 00000000000..e64e4efbd8b --- /dev/null +++ b/queue-2.6.28/sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch @@ -0,0 +1,33 @@ +From 894dcd78782842924527598b0b764c9b4e679e21 Mon Sep 17 00:00:00 2001 +From: Clemens Ladisch +Date: Fri, 6 Feb 2009 08:13:07 +0100 +Subject: sound: usb-audio: handle wMaxPacketSize for FIXED_ENDPOINT devices + +From: Clemens Ladisch + +commit 894dcd78782842924527598b0b764c9b4e679e21 upstream. + +For audio devices that do not have proper audio descriptors (e.g., +Edirol UA-20), we use hardcoded parameters from our quirks list. +However, we must still read the maximum packet size from the standard +endpoint descriptor; otherwise, we might use packets that are too big +and therefore rejected by the USB core. + +Signed-off-by: Clemens Ladisch +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/usb/usbaudio.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/usb/usbaudio.c ++++ b/sound/usb/usbaudio.c +@@ -2966,6 +2966,7 @@ static int create_fixed_stream_quirk(str + return -EINVAL; + } + alts = &iface->altsetting[fp->altset_idx]; ++ fp->maxpacksize = le16_to_cpu(get_endpoint(alts, 0)->wMaxPacketSize); + usb_set_interface(chip->dev, fp->iface, 0); + init_usb_pitch(chip->dev, fp->iface, alts, fp); + init_usb_sample_rate(chip->dev, fp->iface, alts, fp, fp->rate_max); diff --git a/queue-2.6.28/wait-prevent-exclusive-waiter-starvation.patch b/queue-2.6.28/wait-prevent-exclusive-waiter-starvation.patch new file mode 100644 index 00000000000..f449b9d1c24 --- /dev/null +++ b/queue-2.6.28/wait-prevent-exclusive-waiter-starvation.patch @@ -0,0 +1,193 @@ +From 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 Mon Sep 17 00:00:00 2001 +From: Johannes Weiner +Date: Wed, 4 Feb 2009 15:12:14 -0800 +Subject: wait: prevent exclusive waiter starvation + +From: Johannes Weiner + +commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 upstream. + +With exclusive waiters, every process woken up through the wait queue must +ensure that the next waiter down the line is woken when it has finished. + +Interruptible waiters don't do that when aborting due to a signal. And if +an aborting waiter is concurrently woken up through the waitqueue, noone +will ever wake up the next waiter. + +This has been observed with __wait_on_bit_lock() used by +lock_page_killable(): the first contender on the queue was aborting when +the actual lock holder woke it up concurrently. The aborted contender +didn't acquire the lock and therefor never did an unlock followed by +waking up the next waiter. + +Add abort_exclusive_wait() which removes the process' wait descriptor from +the waitqueue, iff still queued, or wakes up the next waiter otherwise. +It does so under the waitqueue lock. Racing with a wake up means the +aborting process is either already woken (removed from the queue) and will +wake up the next waiter, or it will remove itself from the queue and the +concurrent wake up will apply to the next waiter after it. + +Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and +__wait_on_bit_lock() when they were interrupted by other means than a wake +up through the queue. + +[akpm@linux-foundation.org: coding-style fixes] +Reported-by: Chris Mason +Signed-off-by: Johannes Weiner +Mentored-by: Oleg Nesterov +Cc: Peter Zijlstra +Cc: Matthew Wilcox +Cc: Chuck Lever +Cc: Nick Piggin +Cc: Ingo Molnar +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/wait.h | 11 +++++++-- + kernel/sched.c | 4 +-- + kernel/wait.c | 59 ++++++++++++++++++++++++++++++++++++++++++++------- + 3 files changed, 63 insertions(+), 11 deletions(-) + +--- a/include/linux/wait.h ++++ b/include/linux/wait.h +@@ -132,6 +132,8 @@ static inline void __remove_wait_queue(w + list_del(&old->task_list); + } + ++void __wake_up_common(wait_queue_head_t *q, unsigned int mode, ++ int nr_exclusive, int sync, void *key); + void __wake_up(wait_queue_head_t *q, unsigned int mode, int nr, void *key); + extern void __wake_up_locked(wait_queue_head_t *q, unsigned int mode); + extern void __wake_up_sync(wait_queue_head_t *q, unsigned int mode, int nr); +@@ -333,16 +335,19 @@ do { \ + for (;;) { \ + prepare_to_wait_exclusive(&wq, &__wait, \ + TASK_INTERRUPTIBLE); \ +- if (condition) \ ++ if (condition) { \ ++ finish_wait(&wq, &__wait); \ + break; \ ++ } \ + if (!signal_pending(current)) { \ + schedule(); \ + continue; \ + } \ + ret = -ERESTARTSYS; \ ++ abort_exclusive_wait(&wq, &__wait, \ ++ TASK_INTERRUPTIBLE, NULL); \ + break; \ + } \ +- finish_wait(&wq, &__wait); \ + } while (0) + + #define wait_event_interruptible_exclusive(wq, condition) \ +@@ -431,6 +436,8 @@ extern long interruptible_sleep_on_timeo + void prepare_to_wait(wait_queue_head_t *q, wait_queue_t *wait, int state); + void prepare_to_wait_exclusive(wait_queue_head_t *q, wait_queue_t *wait, int state); + void finish_wait(wait_queue_head_t *q, wait_queue_t *wait); ++void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait, ++ unsigned int mode, void *key); + int autoremove_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key); + int wake_bit_function(wait_queue_t *wait, unsigned mode, int sync, void *key); + +--- a/kernel/sched.c ++++ b/kernel/sched.c +@@ -4586,8 +4586,8 @@ EXPORT_SYMBOL(default_wake_function); + * started to run but is not in state TASK_RUNNING. try_to_wake_up() returns + * zero in this (rare) case, and we handle it by continuing to scan the queue. + */ +-static void __wake_up_common(wait_queue_head_t *q, unsigned int mode, +- int nr_exclusive, int sync, void *key) ++void __wake_up_common(wait_queue_head_t *q, unsigned int mode, ++ int nr_exclusive, int sync, void *key) + { + wait_queue_t *curr, *next; + +--- a/kernel/wait.c ++++ b/kernel/wait.c +@@ -91,6 +91,15 @@ prepare_to_wait_exclusive(wait_queue_hea + } + EXPORT_SYMBOL(prepare_to_wait_exclusive); + ++/* ++ * finish_wait - clean up after waiting in a queue ++ * @q: waitqueue waited on ++ * @wait: wait descriptor ++ * ++ * Sets current thread back to running state and removes ++ * the wait descriptor from the given waitqueue if still ++ * queued. ++ */ + void finish_wait(wait_queue_head_t *q, wait_queue_t *wait) + { + unsigned long flags; +@@ -117,6 +126,39 @@ void finish_wait(wait_queue_head_t *q, w + } + EXPORT_SYMBOL(finish_wait); + ++/* ++ * abort_exclusive_wait - abort exclusive waiting in a queue ++ * @q: waitqueue waited on ++ * @wait: wait descriptor ++ * @state: runstate of the waiter to be woken ++ * @key: key to identify a wait bit queue or %NULL ++ * ++ * Sets current thread back to running state and removes ++ * the wait descriptor from the given waitqueue if still ++ * queued. ++ * ++ * Wakes up the next waiter if the caller is concurrently ++ * woken up through the queue. ++ * ++ * This prevents waiter starvation where an exclusive waiter ++ * aborts and is woken up concurrently and noone wakes up ++ * the next waiter. ++ */ ++void abort_exclusive_wait(wait_queue_head_t *q, wait_queue_t *wait, ++ unsigned int mode, void *key) ++{ ++ unsigned long flags; ++ ++ __set_current_state(TASK_RUNNING); ++ spin_lock_irqsave(&q->lock, flags); ++ if (!list_empty(&wait->task_list)) ++ list_del_init(&wait->task_list); ++ else if (waitqueue_active(q)) ++ __wake_up_common(q, mode, 1, 0, key); ++ spin_unlock_irqrestore(&q->lock, flags); ++} ++EXPORT_SYMBOL(abort_exclusive_wait); ++ + int autoremove_wake_function(wait_queue_t *wait, unsigned mode, int sync, void *key) + { + int ret = default_wake_function(wait, mode, sync, key); +@@ -177,17 +219,20 @@ int __sched + __wait_on_bit_lock(wait_queue_head_t *wq, struct wait_bit_queue *q, + int (*action)(void *), unsigned mode) + { +- int ret = 0; +- + do { ++ int ret; ++ + prepare_to_wait_exclusive(wq, &q->wait, mode); +- if (test_bit(q->key.bit_nr, q->key.flags)) { +- if ((ret = (*action)(q->key.flags))) +- break; +- } ++ if (!test_bit(q->key.bit_nr, q->key.flags)) ++ continue; ++ ret = action(q->key.flags); ++ if (!ret) ++ continue; ++ abort_exclusive_wait(wq, &q->wait, mode, &q->key); ++ return ret; + } while (test_and_set_bit(q->key.bit_nr, q->key.flags)); + finish_wait(wq, &q->wait); +- return ret; ++ return 0; + } + EXPORT_SYMBOL(__wait_on_bit_lock); + diff --git a/queue-2.6.28/x86-apic-enable-workaround-on-amd-fam10h-cpus.patch b/queue-2.6.28/x86-apic-enable-workaround-on-amd-fam10h-cpus.patch new file mode 100644 index 00000000000..3c17aa5ccb7 --- /dev/null +++ b/queue-2.6.28/x86-apic-enable-workaround-on-amd-fam10h-cpus.patch @@ -0,0 +1,37 @@ +From 858770619debfb9269add63e4ba8b7c6b5538dd1 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Tue, 3 Feb 2009 16:24:22 +0100 +Subject: x86: APIC: enable workaround on AMD Fam10h CPUs + +From: Borislav Petkov + +commit 858770619debfb9269add63e4ba8b7c6b5538dd1 upstream. + +Impact: fix to enable APIC for AMD Fam10h on chipsets with a missing/b0rked + ACPI MP table (MADT) + +Booting a 32bit kernel on an AMD Fam10h CPU running on chipsets with +missing/b0rked MP table leads to a hang pretty early in the boot process +due to the APIC not being initialized. Fix that by falling back to the +default APIC base address in 32bit code, as it is done in the 64bit +codepath. + +Signed-off-by: Borislav Petkov +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/apic.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/apic.c ++++ b/arch/x86/kernel/apic.c +@@ -1451,7 +1451,7 @@ static int __init detect_init_APIC(void) + switch (boot_cpu_data.x86_vendor) { + case X86_VENDOR_AMD: + if ((boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model > 1) || +- (boot_cpu_data.x86 == 15)) ++ (boot_cpu_data.x86 >= 15)) + break; + goto no_apic; + case X86_VENDOR_INTEL: