Bug 249007
| Summary: | kernel-2.6.22.1-27.fc7 hangs at "ACPI: Using PIC for interrupt routing" | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James <james> | ||||||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||
| Severity: | high | Docs Contact: | |||||||||||||
| Priority: | low | ||||||||||||||
| Version: | 7 | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2007-08-22 08:24:11 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
James
2007-07-20 10:52:35 UTC
Does booting with the kernel option: initcall_debug give any additional information? I'm attaching photos of the screen at the time the notebook halts, both with and without the initcall_debug option. The machine locks solid in either case and must be forcibly powered down. This also happens with vanilla a 2.6.22.1 kernel. (I've also attached a "healthy" dmesg from the kernel I'm currently, based off vanilla, using for comparison.) Would you like me to e-mail the notebooks Smolt UUID? Created attachment 159693 [details]
Image of the screen at the time the kernel halts.
Created attachment 159694 [details]
Kernel halting with initcall_debug cmdline option.
Created attachment 159695 [details]
Healthy dmesg output from 2.6.21.5
(In reply to comment #2) > Would you like me to e-mail the notebooks Smolt > UUID? Yes, that might help. We might be lucky and alt-sysrq could be working by the time it hangs. Try booting with "sysrq_always_enabled" option and pressing alt-sysrq-p (hold down Alt and SysRq while pressing T.) This can be hard to do on notebooks where SysRq also requires the Fn key as well. Maybe trying it on a working kernel in runlevel 3 would help figuring out the exact sequence needed. Created attachment 159697 [details]
biosdecode output
Created attachment 159699 [details]
dmidecode output
[Re: comment #7] No response from any of the Magic SysRq combinations. I don't think it's caught in a loop, since the fan doesn't go berserk; it seems to just stop. Same thing happens with the latest, kernel-2.6.22.1-33.fc7. Still happens with kernel-2.6.22.1-41.fc7, stops at same place as before. Still no luck with kernel-2.6.22.2-57.fc7. Any idea on what's changed between 2.6.21.5 and 2.6.22? (In reply to comment #13) > Any idea on what's changed between > 2.6.21.5 and 2.6.22? ~550000 lines of code. There are some ACPI fixes in 2.6.23 that might apply to this problem, they got merged in CVS today. 2.6.22.3-59 is building -- it has some ACPI patches that might fix the problem. It will be available here when it finishes: http://koji.fedoraproject.org/koji/buildinfo?buildID=13845 Tried 2.6.22.3-59 (i686), same thing again. This is really bizarre, I'm sure this notebook has nothing exotic about it. Is there any way to get any more debug info out of it? (In reply to comment #16) > Tried 2.6.22.3-59 (i686), same thing again. This is really bizarre, I'm sure > this notebook has nothing exotic about it. Is there any way to get any more > debug info out of it? 2.6.22.3-61 is building with ACPI debugging enabled in the -debug kernels. http://koji.fedoraproject.org/koji/buildinfo?buildID=13938 Get the i686-debug kernel and play with the acpi.debug_layer and acpi.debug_level parameters. See /usr/share/doc/kernel-doc-2.6.22/Documentation/kernel-parameters.txt [from the kernel-doc RPM package.] Chuck, I've found out what was preventing the kernel from booting. I'd been booting previous kernels with acpi_serialize and ec_intr=0 since about 2.6.18 to acquiesce a bug where the interpreter would sometimes get stuck in an infinite loop. Removing these allows the kernel to boot. So I'll close this as NOTABUG for now and keep trying the latest builds in Koji to see if any of the troubles that necessitated the problematic cmdline options return. |