lwn.git/arch/x86, branch v2.6.31.9

ACPI: Use the ARB_DISABLE for the CPU which model id is less than 0x0f.

2009-12-18T21:44:14+00:00

commit 03a05ed1152944000151d57b71000de287a1eb02 upstream. Currently, ARB_DISABLE is a NOP on all of the recent Intel platforms. For such platforms, reduce contention on c3_lock by skipping the fake ARB_DISABLE. The cpu model id on one laptop is 14. If we disable ARB_DISABLE on this box, the box can't be booted correctly. But if we still enable ARB_DISABLE on this box, the box can be booted correctly. So we still use the ARB_DISABLE for the cpu which mode id is less than 0x0f. http://bugzilla.kernel.org/show_bug.cgi?id=14700 Signed-off-by: Zhao Yakui Acked-by: Venkatesh Pallipadi Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value

2009-12-18T21:44:12+00:00

Upstream commit a2202aa29289db64ca7988b12343158b67b27f10. On platforms where bios handles the thermal monitor interrupt, APIC_LVTTHMR on each logical CPU is programmed to generate a SMI and OS can't touch it. Unfortunately AP bringup sequence using INIT-SIPI-SIPI clear all the LVT entries except the mask bit. Essentially this results in all LVT entries including the thermal monitoring interrupt set to masked (clearing the bios programmed value for APIC_LVTTHMR). And this leads to kernel take over the thermal monitoring interrupt on AP's but not on BSP (leaving the bios programmed value only on BSP). As a result of this, we have seen system hangs when the thermal monitoring interrupt is generated. Fix this by reading the initial value of thermal LVT entry on BSP and if bios has taken over the control, then program the same value on all AP's and leave the thermal monitoring interrupt control on all the logical cpu's to the bios. Signed-off-by: Yong Wang Reviewed-by: Suresh Siddha Cc: Borislav Petkov Cc: Arjan van de Ven LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86/mce: Set up timer unconditionally

2009-12-18T21:44:10+00:00

commit bc09effabf0c5c6c7021e5ef9af15a23579b32a8 upstream. mce_timer must be passed to setup_timer() in all cases, no matter whether it is going to be actually used. Otherwise, when the CPU gets brought down, its call to del_timer_sync() will never return, as the timer won't have a base associated, and hence lock_timer_base() will loop infinitely. Signed-off-by: Jan Beulich Signed-off-by: Hidetoshi Seto LKML-Reference: <4B1DB831.2030801@jp.fujitsu.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: GART: pci-gart_64.c: Use correct length in strncmp

2009-12-18T21:43:43+00:00

commit 41855b77547fa18d90ed6a5d322983d3fdab1959 upstream. Signed-off-by: Joe Perches LKML-Reference: <1257818330.12852.72.camel@Joe-Laptop.home> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: Fix typo in Intel CPU cache size descriptor

2009-12-18T21:43:43+00:00

commit e02e0e1a130b9ca37c5186d38ad4b3aaf58bb149 upstream. I double-checked the datasheet. One of the existing descriptors has a typo: it should be 2MB not 2038 KB. Signed-off-by: Dave Jones LKML-Reference: <20091110200120.GA27090@redhat.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: Fix iommu=nodac parameter handling

2009-12-18T21:43:42+00:00

commit 2ae8bb75db1f3de422eb5898f2a063c46c36dba8 upstream. iommu=nodac should forbid dac instead of enabling it. Fix it. Signed-off-by: Tejun Heo Acked-by: FUJITA Tomonori Cc: Matteo Frigo LKML-Reference: <4AE5B52A.4050408@kernel.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree

2009-12-18T21:43:41+00:00

commit 4528752f49c1f4025473d12bc5fa9181085c3f22 upstream. On a multi-node x3950M2 system, there's a slight oddity in the PCI device tree for all secondary nodes: 30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) ...as compared to the primary node: 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) 03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04) In both nodes, the LSI RAID controller hangs off a CalIOC2 device, but on the secondary nodes, the BIOS hides the VGA device and substitutes the device tree ending with the disk controller. It would seem that Calgary devices don't necessarily appear at the top of the PCI tree, which means that the current code to find the Calgary IOMMU that goes with a particular device is buggy. Rather than walk all the way to the top of the PCI device tree and try to match bus number with Calgary descriptor, the code needs to examine each parent of the particular device; if it encounters a Calgary with a matching bus number, simply use that. Otherwise, we BUG() when the bus number of the Calgary doesn't match the bus number of whatever's at the top of the device tree. Extra note: This patch appears to work correctly for the x3950 that came before the x3950 M2. Signed-off-by: Darrick J. Wong Acked-by: Muli Ben-Yehuda Cc: FUJITA Tomonori Cc: Joerg Roedel Cc: Yinghai Lu Cc: Jon D. Mason Cc: Corinna Schultz LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: ASUS P4S800 reboot=bios quirk

2009-12-18T21:43:40+00:00

commit 4832ddda2ec4df96ea1eed334ae2dbd65fc1f541 upstream. Bug reporter noted their system with an ASUS P4S800 motherboard would hang when rebooting unless reboot=b was specified. Their dmidecode didn't contain descriptive System Information for Manufacturer or Product Name, so I used their Base Board Information to create a reboot quirk patch. The bug reporter confirmed this patch resolves the reboot hang. Handle 0x0001, DMI type 1, 25 bytes System Information Manufacturer: System Manufacturer Product Name: System Name Version: System Version Serial Number: SYS-1234567890 UUID: E0BFCD8B-7948-D911-A953-E486B4EEB67F Wake-up Type: Power Switch Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: P4S800 Version: REV 1.xx Serial Number: xxxxxxxxxxx BugLink: http://bugs.launchpad.net/bugs/366682 ASUS P4S800 will hang when rebooting unless reboot=b is specified. Add a quirk to reboot through the bios. Signed-off-by: Leann Ogasawara LKML-Reference: <1259972107.4629.275.camel@emiko> Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman

x86, apic: Enable lapic nmi watchdog on AMD Family 11h

2009-12-18T21:43:39+00:00

commit 7d1849aff6687a135a8da3a75e32a00e3137a5e2 upstream. The x86 lapic nmi watchdog does not recognize AMD Family 11h, resulting in: NMI watchdog: CPU not supported As far as I can see from available documentation (the BKDM), family 11h looks identical to family 10h as far as the PMU is concerned. Extending the check to accept family 11h results in: Testing NMI watchdog ... OK. I've been running with this change on a Turion X2 Ultra ZM-82 laptop for a couple of weeks now without problems. Signed-off-by: Mikael Pettersson Cc: Andreas Herrmann Cc: Joerg Roedel LKML-Reference: <19223.53436.931768.278021@pilspetsen.it.uu.se> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: un__init iommu_setup_msi

2009-12-18T21:43:38+00:00

commit 9f800de38b05d84809e89f16671d636a140eede7 upstream. This function may be called on the resume path and can not be dropped after booting. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman