Bug 449308

Summary: Hard lock up without acpi=off after exactly 35 seconds, even in single user mode
Product: [Fedora] Fedora Reporter: Bob Richmond <bob>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-09 18:38:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Serial console output during the boot of a session that locks up, in single user mode
none
lsmod output of a doomed single user mode session that locks up after 35 seconds
none
lsmod output of a rescue mode session that does not lock up without acpi=off
none
list of modules missing in the rescue session none

Description Bob Richmond 2008-06-02 04:41:36 UTC 
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).
Comment 1 Bob Richmond 2008-06-02 04:41:36 UTC 
Created attachment 307327 [details]
Serial console output during the boot of a session that locks up, in single user mode
Comment 2 Bob Richmond 2008-06-02 04:55:51 UTC 
Created attachment 307330 [details]
lsmod output of a doomed single user mode session that locks up after 35 seconds
Comment 3 Bob Richmond 2008-06-02 04:56:42 UTC 
Created attachment 307331 [details]
lsmod output of a rescue mode session that does not lock up without acpi=off
Comment 4 Bob Richmond 2008-06-02 05:01:01 UTC 
I will be happy to provide any additional information I can to resolve this issue.
Comment 5 Chuck Ebbert 2008-06-06 23:16:47 UTC 
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.)
Comment 6 Bob Richmond 2008-06-07 06:27:56 UTC 
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?
Comment 7 Chuck Ebbert 2008-06-09 06:21:52 UTC 
You could try disabling the haldaemon service and then booting to console mode.
Comment 8 Bob Richmond 2008-06-09 18:38:36 UTC 
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.