Bug 102501
| Summary: | (ACPI) Yet another ACPI hang at boot | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | Chris Kloiber <ckloiber> | ||||||||||||
| Component: | kernel | Assignee: | Jeff Garzik <jgarzik> | ||||||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | beta1 | CC: | acpi-bugzilla, jgarzik, peterm, riel | ||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | i386 | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2003-10-21 20:22:17 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: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 100643 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Chris Kloiber
2003-08-16 00:14:13 UTC
Created attachment 93676 [details]
sysreport output
Created attachment 93677 [details]
Screenshot (via camera)
Please attach the output of 'acpidmp' as well. (Hm, perhaps acpidmp should be added to sysreport?) Any chance to get dmesg through serial port? If I can scare up a null-modem, sure. Should have one around here someplace. Created attachment 93991 [details]
Booting the installer with serial capture.
Here you go.
Created attachment 93992 [details]
Same machine with acpi=off
For comparison sake, serial capture of -BOOT kernel with acpi=off
If you really need the acpidmp, let me know, as the machine currently is the
box I use day to day with Taroon installed.
Created attachment 94020 [details]
acpidmp output
I found another box to run Taroon, here's the acpidmp from the W8000.
ACPI-0183: *** Error: Looking up [\_SB_.PCI0.LPC_.ECP0] in namespace, AE_NOT_FOUND ACPI-1121: *** Error: , AE_NOT_FOUND but in fact, '\_SB_.PCI0.LPC_.ECP0' is defined in a SSDT. I investigated the SSDTs of the issue, and found that one SSDT has dependence with other SSDT. This could be the root reason. According to ACPI spec(p114), the dependence is wrong, but we can solve it. In fact, I found kernel 2.4.22- rc2 has already such resolution(the resolution can only solve the situation that A is depend on B when B is loaded prior to A, it can't work for other situations) for the problem. can you try the kernel 2.4.22-rc2? well, DSDT defined '\_SB_.PCI0.LPC', but SSDTs use '\_SB_.PCI0.LPC_'. maybe we also need to fix the DSDT. The latest beta kernel-2.4.22-20.1.2024.2.36.nptlsmp boots without adding acpi=off. Hurrah! yes,kernel-2.4.22-20.1.2024.2.36.nptlsmp includes what I have said. But I still think It's not the best solution. If SSDT A depends on SSDT B and B depends on A, though it's invalid to ACPI spec, what should we do? Sorry, I can't help you there. I am the reporter of the original problem, and do not understand the inner workings of ACPI. I do thank you for your assistance, however. |