SRU: Hardy LP Bug #214814 - PCI/ACPI: "BUG: soft lockup - CPU#0 stuck for 61s!"
Stefan Bader
stefan.bader at canonical.com
Fri Aug 15 12:36:44 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Gardner wrote:
> TJ wrote:
>> This cherry-pick will fix the issue described in LP Bug #214814 "BUG:
>> soft lockup - CPU#0 stuck for 61s!". The bug has previously been tagged
>> for SRU but missed the 8.04.1 milestone. The upstream report is:
>>
>> http://bugzilla.kernel.org/show_bug.cgi?id=10124
>>
>> That patch has been tested and confirmed working.
>>
>> ---
>> commit b87e81e5c6e64ae0eae3b4f61bf07bfeec856184
>> Author: yakui.zhao at intel.com <yakui.zhao at intel.com>
>> Date: Tue Apr 15 14:34:49 2008 -0700
>>
>> acpi: unneccessary to scan the PCI bus already scanned
>> ---
>>
>> Systems based on the Intel 450NX chipset may experience issues where
>> devices aren't recognised that lead to drivers failing, unhandled IRQs,
>> and other serious boot failures. The issue is caused because this
>> chipset has 3 PCI root buses.
>> When it was first released some operating systems (read: Windows NT)
>> didn't always correctly discover the 2nd and 3rd PCI buses. As a result
>> the PCI BIOS tables were 'hacked' to have a fake bridge device on PCI
>> bus 0 that points to the same bus number as the 1st bus so they would be
>> scanned correctly by the OS.
>>
>> As a result, in a well-behaved OS the 2nd and 3rd PCI buses would be
>> scanned twice. Once as secondaries of the 1st bus, and then as root
>> buses in their own right. This caused problems with devices being
>> discovered twice.
>>
>> Unfortunately, the user's kernel-log report is misleading since the bus
>> has already been found to be registered and therefore ignored. The
>> situation can be worked around by booting with "pci=noacpi".
>>
>> A fix-up for all i450N chipsets was introduced in
>> arch/i386/pci/fixups.c::pci_fixup_i450nx(). Note: arch/i386 was
>> refactored to arch/x86/ subsequently. The fix-up checks the PCI config
>> for the subsidiary buses and if it finds them scans them. This adds them
>> to the root_pci_bus list. Later in the boot process the ACPI/PCI code
>> reads the ACPI DSDT table, finds the PCI bus entries (PNP0A03) and tries
>> to scan them again, leading to the kernel BUG.
>>
>> This patch ensures that buses already scanned are recognised rather than
>> ignored.
>>
>> TJ.
>> Ubuntu Kernel ACPI Team.
>>
>>
>
> Applied. LP: #258143
>
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=4469fffe7db317faf023fa24fe87a900af0c3524
>
> Note - I mistakenly created a new bug report, but I should have used the
> existing #214814 (which I've now marked as a duplicate). Sigh, need to
> postpone SRU processing in the morning until after I've had more coffee.
> Thats twice this week.
>
>
ACK
- --
When all other means of communication fail, try words!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIpXhbP+TjRTJVqvQRAr6xAKDFfJvnbbLT6PKIGNadFI3X25UY1wCfZ3Kr
Nq/G6+15pqkFb+9n35hjHFE=
=9skO
-----END PGP SIGNATURE-----
More information about the kernel-team
mailing list