Most recent kernel where this bug did *NOT* occur: N/A
Distribution: Fedora Core 6.92 (Rawhide)
Hardware Environment: Acer Veriton 6900 Pro, Intel Pentium D dual-core
Software Environment: Linux 126.96.36.199
The system will hang while the kernel is initializing if the option acpi=off is
not specified on the kernel command line. After the hang occurs, the Num Lock
key on the keyboard no longer turns Num Lock on or off.
This is an Acer Veriton 6900 Pro system, Intel Pentium D dual-core CPU,
Steps to reproduce:
Boot kernel without acpi=off option
Created attachment 11086 [details]
Kernel messages with options: ro root=LABEL=/ console=ttyS0 acpi_dbg_layer=1 acpi_dbg_level=1 apic=debug debug
Created attachment 11087 [details]
Kernel messages with options: ro root=LABEL=/ console=ttyS0 acpi=ht acpi_dbg_layer=1 acpi_dbg_level=1 apic=debug debug
Created attachment 11088 [details]
Kernel messages with options: ro root=LABEL=/ console=ttyS0 acpi=off acpi_dbg_layer=1 acpi_dbg_level=1 apic=debug debug
What is the most recent kernel that worked properly without any
Does the latest upstream kernel (2.6.21-rc6) work any better?
any luck with "pci=nommconf" or with "noapic"?
I will have access to this machine on Apr. 13. It is a new machine and I have
not tried a kernel earlier than 2.6.18 (Fedora version). I plan on trying
kernel.org versions of 2.6.21-rc6, 188.8.131.52, and 184.108.40.206 with and without the
suggested options. Are there any other versions that would be good baselines to
try (e.g. before major ACPI changes)?
I tried kernel 2.6.21-rc6 tonight. With just pci=nommconf, the kernel prints an
irq 19: nobody cared message, suggests trying irqpoll, and gets stuck trying to
detect the CD-ROM drive. It is not a complete hang as SysRq combinations still
With both the pci=nommconf and irqpoll options, the kernel boots and runs fine.
please attach the dmesg and acpidump output with pci=nommconf. mmconf is known
broken in a lot systems. irqpoll suggests there is a irq mis-routing.
Will you please upload the acpidump after the system is booted with option acpi=off ?
Here is an update: pci=nommconf with no other options is working (most of the time, see paragraph below) as of 220.127.116.11-91.fc7 and I am attaching dmesg output and the requested acpidump. I am using the output from a Fedora kernel, if that is not OK, I can compile one from kernel.org.
I do still have problems with intermittent hangs on bootup even when using pci=nommconf. The kernel prints a detailed "oops" style error message and prints another error message every 5 seconds. This is not consistently reproducible can sometimes be fixed by disconnecting all USB devices and rebooting. I can try to capture the kernel output if I can get it to happen again.
Created attachment 13061 [details]
Kernel messages with options: ro root=LABEL=/ pci=nommconf
Created attachment 13062 [details]
acpidump with options: ro root=LABEL=/ pci=nommconf
Created attachment 13064 [details]
Kernel messages for intermittent hang with pci=nommconf
Created attachment 13065 [details]
Kernel messages for intermittent hang with pci=nommconf pci=routeirq
Created attachment 13066 [details]
Kernel messages for successful boot with pci=nommconf pci=routeirq
This was literally just a few minutes after attempting to boot with pci=nommconf pci=routeirq and getting the errors in attachment 13065 [details]. After attachment 13065 [details] I rebooted the system and one of the BIOS screens that flashed by showed "Update Successful", so I suspect that the BIOS is changing something in ACPI/ESCD/whatever in between the boot attempts.
could you please check to see if http://bugzilla.kernel.org/show_bug.cgi?id=8833#c12 can fix your problem?
Using the patch at http://marc.info/?l=linux-kernel&m=118809338631160&w=2 against 18.104.22.168 the hang appears to be resolved.
great! mark it as dup then.
*** This bug has been marked as a duplicate of bug 8838 ***
Should that have been bug 8833 and not bug 8838?
*** This bug has been marked as a duplicate of bug 8833 ***