Kernel Bug Tracker – Bug 6028
AML interpretation in 32-bit slack mode becomes unstable after some exceptions
Last modified: 2006-09-28 13:18:39 UTC
Most recent kernel where this bug did not occur:
The Linux kernel ACPI interpreter fails the following
AML test when it is compiled into a simulator. So if an
OEM BIOS includes this code, Linux would fail.
Steps to reproduce:
Run interpreter with the .asl demo code attached below.
Created attachment 7271 [details]
ASL code to reproduce bug.
'Error #' message reports bug.
Created attachment 7272 [details]
The bug appeared as an unpredictable behaviour
of AML interpretation after some exceptions in
"32-bit slack mode".
For some unsuccessfully completed operations the
ResultObj object nevertheless had been initialized
with the pointer to the internal object as if ResultObj
referred the valid object; moreover, just after that,
the object referred by the pointer was damaged by
INTERNAL BUG NUMBER:
No value is assigned to ResultObj when operation failed.
The update was tested by the ASLTS test suite runs
(all the test cases) on the following systems:
- CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin
- Linux 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386
for the following (all) modes supported by the ASLTS test suite:
- 32-bit norm mode
- 64-bit norm mode
- 32-bit slack mode
- 64-bit slack mode
The tests were run (on the systems described above) before update,
then the tests were run on those systems after update. Then results
of two runs were compared. All is Ok (the relevant error fixed, no
I think that the philosophy (through most of the ACPICA code) is that if an
exception is returned, the return value is undefined; Perhaps the real problem
is that a caller is assuming that the return value is NULL in the error case?
Patch integrated into version 20060310
ACPICA 20060608 shipped in Linux-2.6.17-git9, closed.