From owner-freebsd-current Wed Oct 24 7:30:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5]) by hub.freebsd.org (Postfix) with ESMTP id F331F37B405; Wed, 24 Oct 2001 07:30:26 -0700 (PDT) Received: from vega.vega.com (root@h164.229.dialup.iptcom.net [212.9.229.164]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id RAA63246; Wed, 24 Oct 2001 17:30:17 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.6/8.11.3) with ESMTP id f9OEUFU01211; Wed, 24 Oct 2001 17:30:15 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3BD6D0F6.6E642FF4@FreeBSD.org> Date: Wed, 24 Oct 2001 17:32:22 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Mitsuru IWASAKI Cc: acpi-jp@jp.freebsd.org, msmith@FreeBSD.org, ache@nagual.pp.ru, current@FreeBSD.org Subject: Re: [acpi-jp 1363] Re: ACPI: problem with fdc resource allocation References: <200110240837.f9O8bAV99173@vega.vega.com> <20011024.221200.104029670.iwasaki@jp.FreeBSD.org> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. I understood that, but it is a discontinued model, so it is unlikely that they will bother to provide updated BIOS just to satisfy those strange that want to run FreeBSD on it. :(( > 2. ACPI CA is developed by Intel. We'd like to have less local > workaround changes as possible. Ok, I see. > 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? Looks like a way to go. I'll test them tomorrow and let you know then. Big thanks! -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message