kernel-2.6.9-34.ELsmp Errors show up in dmesg regarding the DSDT: Jun 1 14:19:35 test01 kernel: ACPI-1133: *** Error: Method execution failed[\_SB_.PCI0._OSC] (Node f7ffec00), AE_AML_UNINITIALIZED_ARG Jun 1 14:19:35 test01 kernel: pciehp: Both _OSC and OSHP methods do not exist Jun 1 14:19:35 test01 kernel: hw_random: RNG not detected Jun 1 14:19:35 test01 kernel: ACPI-1133: *** Error: Method execution failed[\_SB_.PCI0._OSC] (Node f7ffec00), AE_AML_UNINITIALIZED_ARG Jun 1 14:19:35 test01 kernel: pciehp: Both _OSC and OSHP methods do not exist Jun 1 14:19:35 test01 kernel: ACPI-1133: *** Error: Method execution failed[\_SB_.PCI0._OSC] (Node f7ffec00), AE_AML_UNINITIALIZED_ARG Jun 1 14:19:35 test01 kernel: pciehp: Both _OSC and OSHP methods do not exist Jun 1 14:19:35 test01 rc: Starting lm_sensors: succeeded Jun 1 14:19:35 test01 kernel: ACPI-1133: *** Error: Method execution failed[\_SB_.PCI0._OSC] (Node f7ffec00), AE_AML_UNINITIALIZED_ARG Jun 1 14:19:35 test01 kernel: pciehp: Both _OSC and OSHP methods do not exist Jun 1 14:19:35 test01 kernel: ACPI-1133: *** Error: Method execution failed[\_SB_.PCI0._OSC] (Node f7ffec00), AE_AML_UNINITIALIZED_ARG Jun 1 14:19:35 test01 kernel: pciehp: Both _OSC and OSHP methods do not exist The BIOS for this machine is the latest (1.31). Those errors don't seem to be causing problems other than aesthetic ones. Attached is the disassembled DSDT.
Created attachment 132005 [details] dsdt.dsl
Chris, Do you have in Beaverton a 206m with the same BIOS revision and with this problem?
Konrad, yes we have access to a x206m with BIOS v1.31. The system is currently being used by someone else, so I can't currently check whether the RHEL4 U3/U4 pci express hot plug driver is generating the same errors.
Chris, Please do. Thanks!
I have a patch for another issue (expected to make U5) that lets you load the DSDT from a file during init (as a workaround for a whole bunch of ACPI DSDT breakage on various systems). This issue might be solved with this patch if the issue is a broken DSDT table. On the other hand, this could be genuine ACPI breakage that should be fixed. Does this hardware have any known issues?
Brian, sorry for the delay. Dropped the ball here. Don't know of any known issues. I'll have someone run the Linux-ready Firmware Developer Kit on this hardware and see what ACPI errors we come up with. Konrad, (sort of, system's been unavailable) dropped the ball on verifying whether our x206m see similar ACPI errors. I'll have someone check that out too and report the results here.
The "someone" to which Chris referred to in the previous comment is me. Our x206m had BIOS 1.35 where `modprobe pciehp` from the RHEL4 U4 also left the following in dmesg. ACPI-1134: *** Error: Method execution failed [\_SB_.PCI0._OSC] (Node 0000010037e00c40), AE_AML_UNINITIALIZED_ARG Evaluate _OSC Set fails. Status = 0x3008 pciehp: Both _OSC and OSHP methods do not exist I got the same result after updating to the latest BIOS 1.36. I will attach the Linux-ready Firmware Developer Kit results which does contain some _OSC complaints.
Created attachment 137275 [details] Linux-ready Firmware Development Kit results for BIOS 1.36
The Linux-ready Firmware Development Kit complains about the quantity of arguments for the _OSC method: "Reserved method has too many arguments (_OSC requires 4) in _SB.PCI0._OSC" Both the attached disassembled DSDT from BIOS 1.31 and the disassembled DSDT from BIOS 1.36 show 5 instead of 4 arguments for _OSC: "Method (_OSC, 5, NotSerialized)" Paragraph 2.6.9 of the ACPI 3.0 Specification shows only 4 _OSC arguments. It appears likely that the AE_AML_UNINITIALIZED_ARG error is due to DSDT showing the incorrect number of arguments for _OSC. I will report this to our BIOS folks.
(In reply to comment #6) > I have a patch for another issue (expected to make U5) that lets you load the > DSDT from a file during init (as a workaround for a whole bunch of ACPI DSDT > breakage on various systems). This issue might be solved with this patch if the > issue is a broken DSDT table. Brian, Would you mind attaching this patch? It would be interesting to use it to confirm that the problem disappears when the _OSC argument quantity is corrected.
Created attachment 137406 [details] patch to use external DSDT file This patch allows the use of an external DSDT table (loaded from a file at boot). It is usefull in cases where a vendors DSDT table is broken.
can you provide some feedback regarding the patch? it hasnt received much testing yet. thanks
Thanks, Brian. The patch works good. I've been stuffing revised DSDTs into the initrd and exactly the same bits have been showing up in /proc/acpi/dsdt. I changed the DSDT reducing the argument count from 5 to 4 which also required that I hack the method code to get it to compile without errors. I'm still getting the following error when 'pciehp' tries to load but the AE_AML_UNINITIALIZED_ARG error disappeared. Evaluate _OSC Set fails. Status = 0x000b pciehp: Both _OSC and OSHP methods do not exist Not sure if this is due to my bad hacking or bad code that I started with. In any case, the BIOS is still the prime suspect.
thanks for testing this patch.... I will propose this patch as a candidate for inclusion in RHEL4.5. I will post the patch as a fix for this issue (assuming we can verify that these error messages are due to bad BIOS). Question: Does the upstream kernel throw the same errors? Just trying to confirm that there is no upstream fix available for backporting to RHEL4 that might resolve this problem.
(In reply to comment #16) > thanks for testing this patch.... I will propose this patch > as a candidate for inclusion in RHEL4.5. Sounds good. > I will post the patch as a fix for this issue (assuming we > can verify that these error messages are due to bad BIOS). I think it would be best to just get the BIOS fixed. It seems like the patch provides a great debugging tool and way of providing last resort or temporary workarounds but I believe we need to get the BIOS to export correct tables. > > Question: Does the upstream kernel throw the same errors? Yes. Sorry, I forgot to mention that I reproduced the problem with 2.6.18-git9 last week. > Just trying to confirm > that there is no upstream fix available for backporting to > RHEL4 that might resolve this problem. Good question. Thanks.
IBM folks can reference CMVC defect 344205 which reports the BIOS issue.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
No response from the BIOS folks yet so I just followed up.
QE ack for 4.5.
(In reply to comment #15) > thanks for testing this patch.... I will propose this patch as a candidate for > inclusion in RHEL4.5. I will post the patch as a fix for this issue (assuming we > can verify that these error messages are due to bad BIOS). I think this got NACK-ed?
the patch that was posted was NAKed (due to business reasons). from a technical standpoint the patch was acceptable.
(In reply to comment #24) > the patch that was posted was NAKed (due to business reasons). from a technical > standpoint the patch was acceptable. This patch does not address the problem reported in this bug but IMO would have been very useful tool for debugging problems where the BIOS could be exporting bad ACPI data. It would also be useful for providing temporary workarounds for BIOS problems until the repaired BIOS is available. I hope it sees sunlight in the future. With respect to the specific problem reported in this bug I finally received a test BIOS this week. A revision to the _OSC method has eliminated the ACPI-1133 error but it was replaced with a "Evaluate _OSC returns wrong type" message which I believe is due to an incorrect BIOS fix. I have reported this to the BIOS team.
Does the current upstream kernel work any better? ACPI has changed quite a bit since the 2.6.9 kernel, so its possible a backport of some new ACPI features from upstream to RHEL might be appropriate.
Brian, see https://bugzilla.redhat.com/bugzilla/show_activity.cgi?id=197809