From owner-acpi-jp@jp.freebsd.org  Wed Oct 24 22:12:10 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id WAA85018;
	Wed, 24 Oct 2001 22:12:10 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id WAA85013
	for <acpi-jp@jp.freebsd.org>; Wed, 24 Oct 2001 22:12:09 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	(authenticated as iwa with CRAM-MD5)
	by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare/smtpfeed 1.14) with ESMTP/inet id f9ODC3m66586;
	Wed, 24 Oct 2001 22:12:03 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Date: Wed, 24 Oct 2001 22:12:00 +0900 (JST)
Message-Id: <20011024.221200.104029670.iwasaki@jp.FreeBSD.org>
To: acpi-jp@jp.freebsd.org, sobomax@FreeBSD.ORG
Cc: msmith@FreeBSD.ORG, ache@nagual.pp.ru, current@FreeBSD.ORG
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
In-Reply-To: <200110240837.f9O8bAV99173@vega.vega.com>
References: <no.id>
	<200110240837.f9O8bAV99173@vega.vega.com>
X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: acpi-jp 1364
Subject: [acpi-jp 1364] Re: ACPI: problem with fdc resource allocation
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

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).

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 })
