Bug 455253
| Summary: | [4.7] /proc/acpi/dsdt: No such device | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Qian Cai <qcai> | ||||
| Component: | kernel | Assignee: | Prarit Bhargava <prarit> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 4.7 | CC: | achiang, dchapman, duck, tcamuso, vgoyal | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | ia64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-05-18 19:37:16 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: | 461304 | ||||||
| Attachments: |
|
||||||
|
Description
Qian Cai
2008-07-14 13:59:07 UTC
What appears to be happening is that the ACPI code attempts to reserve 128K+ memory for the dsdt table. a) I don't know if the calculation for the dsdt is correct in RHEL4, and b) I'm going to load RHEL5 (which works) to see if the same size reservation is made. I asked lwoodman (in private email) about this and he did say that the upper limit of kmalloc in RHEL4 is 128K. P. >a) I don't know if the calculation for the dsdt is correct in RHEL4, and b) I'm
>going to load RHEL5 (which works) to see if the same size reservation is made.
dsdt size is 0x226a5 on both RHEL4 & RHEL5. The problem here is that RHEL4 has
a 128K limit on kmalloc. The code in question should use alloc_pages() to avoid
this bug.
P.
After thinking about this, I'm curious as to why the dsdt size is 0x226a5. Maybe that's a BIOS/ACPI Table error? To make matters worse, it is alloc'd many times during a 'cat /proc/acpi/dsdt' ... P. Doug -- comment #3? P. Created attachment 312765 [details]
ia64 workaround for this issue
Adding Alex and Tony -- HP engineers. Do you know if the dsdt is supposed to be that large on these systems? P. Taking out of NEEDINFO. I downloaded acpidump, compiled, and ran it on matterhorn1. AFAICT, it looks like the table is valid. P. Prarit, Can you find the DSDT in the ACPI dump? If so, bytes 7:4 give the length of the table. That is the amount of space that should be allocated. Hi Tony, yup I found that using the acpidump utility. The amount there corresponds to what is being allocated -- and the table looks fine, IMO. So I posted the patch to RHKL. P. Prarit, Since you've posted the patch, I assume that this problem has been solved and we can close this BZ. Correct? Hi Tony, This BZ is in POST -- where it should be for now. dzickus will move it into MODIFIED, and eventually it will be CLOSED NEXTRELEASE. ie) leave it in POST. P. Thanks, Prarit. Just doing a little housekeeping. :) Updating PM score. It might be interesting to check this bug, bug 464406 - [4.7.z] SGI Altix ACPI Problem . https://bugzilla.redhat.com/show_bug.cgi?id=464406 The machine hp-rx8640-03.rhts.bos.redhat.com is also affected. Committed in 78.29.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/ An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1024.html |