Bug 9339
| Summary: | boot pause at "ACPI: PCI Root Bridge [PCI0] (0000:00)" unless "pci=nommconf" - Samsung R20 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Sahid Ferdjaoui (sahid) |
| Component: | Config-Other | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | acpi-bugzilla, akpm, andi-bz, antoine, lenb, mingo, protasnb, ryan.e.young, schneider, shaohua.li, slowbyte, tglx |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.22-2-686 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
dmesg with Linux 2.6.24-rc2-686
dmesg - with HPET enabled dmesg - with HPET disable dmesg - with acpi=off dmesg for 2.6.24 hang dmesg for 2.6.24 pci=nommconf lspci output try the debug patch acpidump with pci_debug patch dmesg with pci_debug patch lspci with pci_debug patch |
||
|
Description
Sahid Ferdjaoui
2007-11-09 09:39:46 UTC
Reply-To: akpm@linux-foundation.org umm, what's the bug? Does the kernel boot and run OK? What exactly is wrong? 2.6.22 is getting a bit old. If you can test <whatever it is> on 2.6.23 or 2.6.24-rc2 that would be good. oh sorry, the boot is very long the is ..MP-BIOS bug: 8254 timer not connected to IO-APIC but the boot stop at : ACPI: PCI Root Bridge [PCI0] (0000:00) (during 3 minutes, and boot continue) i have tested with noapic nolapic : PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0 [4294668.777000]PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0 i have tested with kernel 2.6.23 but i doesn't work. i will test with kernel 2.6.24-RC2 now (various people cc'ed) Guys, could we please have a routing decision on this one? I'm assuming acpi? Created attachment 13494 [details]
dmesg with Linux 2.6.24-rc2-686
i have tested with Linux 2.6.24-rc2-686 but doesn't work
Sahid, can you please try with acpi=off? Anso, when you use "noapic nolapic" does the system come up? Thanks. Does it still stop for 3 minutes at:
ACPI: PCI Root Bridge [PCI0] (0000:00)
???
Can you please turn on: CONFIG_PRINTK_TIME ?
Also your dmesg says:
ACPI: System BIOS is requesting _OSI(Linux)
ACPI: If "acpi_osi=Linux" works better, ....
Can you please try acpi_osi=Linux on the kernel command line ?
Thanks
tglx
Created attachment 13939 [details]
dmesg - with HPET enabled
Hi I appear to have the same bug on my Samsung R20. I am running Ubuntu 7.10. Firstly, some history: There was no problem with kernel 2.6.20. With Kernel 2.6.22, the boot process would temporarily freeze. This could be fixed with either by disabling acpi, or by turning off the HPET timer in the kernel config. Kernel 2.6.24-rc4: If the HPET timer is enabled, the computer is very unstable. dmesg shows that the CPU soft locks regularly. If the HPET timer is disabled, then this does not occur, but the boot process pauses for about a minute after "ACPI: PCI Root Bridge [PCI0] (0000:00)" - as above. noapic nolapic and acpi_osi=Linux do not appear to make any difference. If I use the acpi=off option, the problems all go away. I have added a few dmesg attachments to detail all of this. I hope they are self explanatory. Cheers Ryan Created attachment 13940 [details]
dmesg - with HPET disable
Created attachment 13941 [details]
dmesg - with acpi=off
I would recommend trying pci=routeirq, just to completeness. It appears ioapic is failing to register (looking into full trace from #4)...And Andrew is right - the bug needs to be routed to ACPI. On 2.6.20.21, the hang does not occur if pci=nommconf is specified. Going to test soon with other kernels. Hi, On Ubuntu Gutsy Gibbon, kernel 2.6.22-14, I noticed the following two things: 1. with fglrx installed, the boot time is very long. Actually, it is catalyst driver 7.12 installed using Envy. 2. removing fglrx and using radeonhd driver resolves the problem (radeonhd from git) If I can test anything for you, please feel free to ask! On 2.6.24-rc6, the hpet bug seems to be no more (no soft lockups when HPET is enabled). It still hangs after ACPI: PCI Root Bridge [PCI0] (0000:00). Adding pci=nommconf to the kernel command line fixes that. Created attachment 14206 [details]
dmesg for 2.6.24 hang
Useful part:
[ 25.143976] PCI: Scanning behind PCI bridge 0000:00:05.0, config 040200, pass 0
[ 25.144009] PCI: Scanning bus 0000:02
[ 90.623704] Device 0000:02:00.0 not responding
[ 90.623808] PCI: Fixups for bus 0000:02
[ 90.623815] PCI: Bus scan for 0000:02 returning with max=02
Created attachment 14207 [details]
dmesg for 2.6.24 pci=nommconf
Concise diff from previous dmesg:
-- dmesg-2.6.24-rc6.plain 2007-12-27 22:20:01.000000000 +0200
+++ dmesg-nommconf-2.6.24-rc6.plain 2007-12-27 22:19:53.000000000 +0200
@@ -73 +73 @@
-Kernel command line: root=/dev/sda3 ro single
+Kernel command line: root=/dev/sda3 ro pci=nommconf single
@@ -149 +149,2 @@
-PCI: Using MMCONFIG
+PCI: PCI BIOS revision 3.00 entry at 0xfddf6, last bus=10
+PCI: Using configuration type 1
@@ -194 +194,0 @@
-Device 0000:02:00.0 not responding
@@ -240,2 +239,0 @@
-Switched to high resolution mode on CPU 0
-Switched to high resolution mode on CPU 1
@@ -289,0 +288,2 @@
+Switched to high resolution mode on CPU 1
+Switched to high resolution mode on CPU 0
@@ -357 +356,0 @@
-Allocate Port Service[0000:00:05.0:pcie03]
@@ -361 +359,0 @@
-Allocate Port Service[0000:00:06.0:pcie03]
@@ -385 +383 @@
-Table [SSDT](id 00ED) - 6 Objects with 0 Devices 4 Methods 0 Regions
+Table [SSDT](id 00EA) - 6 Objects with 0 Devices 4 Methods 0 Regions
@@ -388 +386 @@
-Table [SSDT](id 00EE) - 14 Objects with 0 Devices 1 Methods 0 Regions
+Table [SSDT](id 00EB) - 14 Objects with 0 Devices 1 Methods 0 Regions
@@ -393 +391 @@
-Table [SSDT](id 00F7) - 4 Objects with 0 Devices 4 Methods 0 Regions
+Table [SSDT](id 00F4) - 4 Objects with 0 Devices 4 Methods 0 Regions
@@ -396 +394 @@
-Table [SSDT](id 00F8) - 1 Objects with 0 Devices 1 Methods 0 Regions
+Table [SSDT](id 00F5) - 1 Objects with 0 Devices 1 Methods 0 Regions
Created attachment 14210 [details]
lspci output
(do not know if this is useful or not)
Created attachment 14277 [details]
try the debug patch
Will you please use the attached patch and attach the output of acpidump , dmesg, lspci -vvxxx?
Thanks.
Created attachment 15543 [details]
acpidump with pci_debug patch
Created attachment 15544 [details]
dmesg with pci_debug patch
Created attachment 15545 [details]
lspci with pci_debug patch
hi, same problem here with a samsung r60+. The attachments above are the requested dmesg, lscpi and acpidump outputs with the pci_debug patch from ykzhao without hpet. I'll stand by if you need further informations. Re-assigning to ACPI now, to make sense out of it hopefully. Since this is marked as regression, can you please re-confirm which kernel was working. Could you please test latest git tree, I guess below commit already fixed the issue. commit ad7edfe0490877864dc0312e5f3315ea37fc4b3a Author: Linus Torvalds <torvalds@woody.linux-foundation.org> Date: Thu Dec 27 21:21:36 2007 -0800 [PCI] Do not enable CRS Software Visibility by default Hi, Jaen & Ruan
The main issue in the laptop is the boot hang (Device 0000:02:00.0 not responding).
As David in comment #24 mentioned, this issue can be fixed by the commit.
At the same time this issue is also related with "pci=mmcfg". And
the following commit also can fix this issue. It means that OS will always use conf1/conf2 to access the config space below 256bytes.
commit a0ca9909609470ad779b9b9cc68ce96e975afff7
Author: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
date: Mon Jan 14 17:31:09 2008 -0500
PCI x86: always use conf1 to access config space below 256 bytes
The boot hang works since 2.6.24. I thought this was the same issue because I had the same MP-BIOS bug and some soft lockups. I tried 2.6.25rc7 today and up to now it runs fine. I'm sorry for the confusion. so...what kernel is the most stable for this laptop? |