Description of problem: Version-Release number of selected component (if applicable): kernel-2.6.25.3-18.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot in any mode without acpi=off 2. Wait 35 seconds Actual results: Completely frozen, magic sysrq doesn't work (even with sysrq_always_enabled=1), nmi_watchdog=2 doesn't report anything. Expected results: Continue running after 35 seconds. Additional info: Tried: pci=noacpi nolapic noapic noapictimer nohz=off highres=off nosoftlockup clocksource=acpi_pm nohz=off highres=off Individually and at the same time, and got the same result. F8 did not exhibit this behavior, and the F9 install disc rescue mode, running the previous kernel, doesn't either. However, running the same kernel as the F9 installer (kernel-2.6.25-14.fc9.x86_64.rpm) DOES lock up. Which may indicate that a module loaded after install time is responsible for the lockup. The motherboard is an Asus A8N-SLI Deluxe, running BIOS version 1008. I was able to capture boot output with the serial console, and will attach it. There are unfortunately no additional messages printed to the serial console when the lockup occurs. I will also attach the output of lsmod running on the doomed session without acpi=off before the 35 second window expires, and lsmod output from rescue mode (where there is no acpi=off, but it doesn't lock up).
Created attachment 307327 [details] Serial console output during the boot of a session that locks up, in single user mode
Created attachment 307330 [details] lsmod output of a doomed single user mode session that locks up after 35 seconds
Created attachment 307331 [details] lsmod output of a rescue mode session that does not lock up without acpi=off
I will be happy to provide any additional information I can to resolve this issue.
Created attachment 308579 [details] list of modules missing in the rescue session You could try to figure out which of these modules causes the problem, if any. The eaiest way is to just rename them, e.g. rename soundcore.ko to soundcore.ko.disabled (and doing just that will disable all of the sound modules.)
I disabled every module listed in your attachment, including uchi-hcd (requiring zcat |cpio /boot/initrd, modify init to remove uchi-hcd, find |cpio |gzip >/boot/initrd...), and it still hangs after 35 seconds. Bummer. I wish it would have been easier to track down to a misbehaving module. Is there anything else I can provide? I think the next step involves git bisect, but it's odd that the rescue mode kernel (which is exactly the same kernel, bit for bit, that hangs) does not behave this way. The only difference in single-user mode that I can think of is running nash instead of anaconda from the initrd. Does nash do anything different during startup that anaconda does not?
You could try disabling the haldaemon service and then booting to console mode.
Over the weekend as a shot in the dark, I just reinstalled. I've been upgrading this machine since FC5. It magically started not freezing without acpi=off. So I'll chalk it up to some broken old dependency. I'll close this bug. I can't reproduce it any longer.