Mitsuru IWASAKI wrote:
> 
> Hi, Maxim.  Thanks for reporting and reminding us.
> 
> I think this is very difficult to fix, because;
>  1. Basically, this is a bug in BIOS, should be reported to vendor.
>  2. ACPI CA is developed by Intel.  We'd like to have less local
>     workaround changes as possible.
>  3. I'm not sure whether suggested patches (buffer size dynamicaly expanding)
>     in [acpi-jp 1315] is correct fix, maybe not.  Probably another approach
>     can be considered (e.g. just ignore AE_AML_BUFFER_LIMIT and continue
>     interpreter execution).

Thank you very much for pointing me into the right
direction! Finally I've properly fixed the bug, though I
took slightly different approach, which I will describe
below in the case when somebody else has the same or similar
problem:

1. First of all, I dumped the ASL DSDT code using
acpidump(8) utility available from ports/devel/acpicatools.
For some reason output of the similar utility in the base
system (fresh 5-CURRENT) appears to be incompatible with
iasl compiler, so if anybody else will follow these steps
please make sure that you are using a right acpidump(8).

2. After that I have compiled ASL code back into AML using
iasl and saved resulting AML under different name DSDT_old.

3. Then I've patched ASL file to fix the problem - as Mike
suggested changed 0x19 to 0x11 and 0x1c to 0x14 and compiled
fixed ASL into DSDT_new file. With this message I am
attaching appropriate patch, perhaps it is a good idea to
put it somehow into the repository.

4. Next I've compared output of `hexdump -C' of both files
(DSDT_old and DSDT_new), noted the differencies - as I
expected only three bytes were different - checksum in the
header and two bytes in the code itself.

5. Then I've extracted ACPI table from BIOS image using
AWARD's CBROM.EXE utility, fired my favourite hex editor,
found those two bytes in the extracted file and changed them
accordingly (0x19-->0x11, 0x1c-->0x14). Also I've increased
checksum in the DSDT header by the difference of the
checksums in the DSDT_old and DSDT_new (0x10 in this
particular case).

6. And finally I've put back corrected ACPI table back into
BIOS image using CBROM.EXE, flashed resulting BIOS image and
voila - the ACPI problem gone. :)

If anybody else needs it, I could provide "fixed" BIOS image
for Tyan-S1590 (Trinity 100AT) mobo, just drop me a note.

Thanks to all who helped!

-Maxim

> 
> I'll describe again the problem.  This method is like this;
>                 Method(_CRS) {
>                     Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3,
>                                0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0,
>                                0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x79, 0x0 })
>                     CreateByteField(BUF0, 0x2, IOLO)
>                     CreateByteField(BUF0, 0x3, IOHI)
>                     CreateByteField(BUF0, 0x4, IORL)
>                     CreateByteField(BUF0, 0x5, IORH)
>                     CreateByteField(BUF0, 0x19, IRQL)
>                     CreateByteField(BUF0, 0x1c, DMAV)
>                     Return(BUF0)
>                 }
> 
> The problem is that this AML is trying to create a field at exceeded
> position (0x19) of the Buffer (size is 0x18).
> And strangely, this method just return the buffer w/o any changes
> after CreateByteField operations. I guess that BIOS writer forgotten to
> delete CreateByteField statements, or change the buffer size.
> 
> Now that we have DSDT override patches;
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1347
> or
> http://home.jp.freebsd.org/cgi-bin/showmail/acpi-jp/1349
> 
> and AML disassembler (acpidump), and ASL compiler (iasl) in
> ports/devel/acpicatools/.
> 
> Maxim, could you apply the following patches and try DSDT overriding?
> 
> Thanks
> 
> --- Tyan-S1590.asl.org  Wed Oct 24 22:00:44 2001
> +++ Tyan-S1590.asl      Wed Oct 24 22:02:09 2001
> @@ -884,12 +884,14 @@
>                  }
>                  Method(_CRS) {
>                      Name(BUF0, Buffer(0x18) {0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0, 
>0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 
>0x79, 0x0 })
> +/*
>                      CreateByteField(BUF0, 0x2, IOLO)
>                      CreateByteField(BUF0, 0x3, IOHI)
>                      CreateByteField(BUF0, 0x4, IORL)
>                      CreateByteField(BUF0, 0x5, IORH)
>                      CreateByteField(BUF0, 0x19, IRQL)
>                      CreateByteField(BUF0, 0x1c, DMAV)
> +*/
>                      Return(BUF0)
>                  }
>                  Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 
>0x0, 0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 
>0x38, 0x79, 0x0 })
--- Tyan-S1590.asl      2001/10/25 11:00:43     1.1
+++ Tyan-S1590.asl      2001/10/25 11:07:17     1.2
@@ -868,8 +868,8 @@
                     CreateByteField(BUF0, 0x3, IOHI)
                     CreateByteField(BUF0, 0x4, IORL)
                     CreateByteField(BUF0, 0x5, IORH)
-                    CreateByteField(BUF0, 0x19, IRQL)
-                    CreateByteField(BUF0, 0x1c, DMAV)
+                    CreateByteField(BUF0, 0x11, IRQL)
+                    CreateByteField(BUF0, 0x14, DMAV)
                     Return(BUF0)
                 }
                 Name(_PRS, Buffer(0x1a) {0x30, 0x47, 0x1, 0xf2, 0x3, 0xf2, 0x3, 0x0, 
0x4, 0x47, 0x1, 0xf7, 0x3, 0xf7, 0x3, 0x0, 0x1, 0x22, 0x40, 0x0, 0x2a, 0x4, 0x0, 0x38, 
0x79, 0x0 })

Reply via email to