Re: acpi is broken since about 2004/12/01

Following up on my previous posting:

[Quoting Ted Lindgreen, on Dec 14, 17:02, in "acpi is broken since ..."]
> Maksim Yevmenkin reported the problem already on Mon Dec 6 15:15:28 in
> "help! acpi kills my laptop", and also Andrey Chernovache reported
> it on Thu Dec 9 09:13:58 in "Lots of ACPI warnings with recent -current".

This ACPI problem is caused by an update on 2004/12/01 called:
  "Vendor import of Intel ACPI-CA 20041119"

The wlan_wep problem, which I encountered at the same time, appeared
to be unrelated and fixed shortly after my previous posting.

The new ACPI version no longer works around broken DSDT info, in
which "implicit returns" are used. If the vendor of your hardware
does not provide a new bios with fixed DSDT info (like Toshiba for
instance) you have this problem.

The workaround I found was to dump the DSDT (using an older kernel)
into a file with acpidump(8). Then edit the .asl file to fix all
the implicit returns. This means for instance:

--- foo.asl	Thu Dec 23 10:20:00 2004
+++ new.asl	Thu Dec 23 15:15:23 2004
_at__at_ -102,17 +102,17 _at__at_
             Name (_UID, 0x01)
             Method (_STA, 0, NotSerialized)
             {
-                STAL (0x60)
+                Return (STAL (0x60))
             }
 
             Method (_PRS, 0, NotSerialized)
             {
-                PRSL (0x60)
+                Return (PRSL (0x60))
             }
 
             Method (_CRS, 0, NotSerialized)
             {
-                CRSL (0x60)
+                Return (CRSL (0x60))
             }

Etcetera, etcetera...

You can easily find these errors by compiling the .asl file with:
  iasl foo.asl
iasl(8) flags the problems with warnings (in contrast to the
new ACPI code in the kernel, which now stumbles on them, causing
the bootprocess to hang).

When the new.asl file is warning-free, move the result of iasl
to /boot:
 mv DSDT.aml /boot/acpi_dsdt.aml
and tell the loader to use this instead of the bios:
 echo 'acpi_dsdt_load="YES"' >> /boot/loader.conf

I sure hope that the workaround as present in the previous
Intel ACPI-CA versions will return again,
Regards,
-- ted