From owner-acpi-jp@jp.freebsd.org  Fri Oct 19 17:25:28 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id RAA60745;
	Fri, 19 Oct 2001 17:25:28 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from ipcard.iptcom.net (ipcard.iptcom.net [212.9.224.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id RAA60736;
	Fri, 19 Oct 2001 17:25:22 +0900 (JST)
	(envelope-from sobomax@FreeBSD.org)
Received: from vega.vega.com (h195.227.dialup.iptcom.net [212.9.227.195])
	by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id LAA78185;
	Fri, 19 Oct 2001 11:24:33 +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 f9J8O1U68002;
	Fri, 19 Oct 2001 11:24:01 +0300 (EEST)
	(envelope-from sobomax@FreeBSD.org)
Message-ID: <3BCFE398.51EA76F@FreeBSD.org>
Date: Fri, 19 Oct 2001 11:26:00 +0300
From: Maxim Sobolev <sobomax@FreeBSD.org>
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: Mike Smith <msmith@FreeBSD.org>, Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>,
        ache@nagual.pp.ru, current@FreeBSD.org, acpi-jp@jp.FreeBSD.org
References: <200110022356.f92Nuit03147@mass.dis.org> <3BBADCB7.456D51AD@FreeBSD.org>
Content-Type: text/plain; charset=x-user-defined
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 1355
Subject: [acpi-jp 1355] Re: ACPI: problem with fdc resource allocation
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: sobomax@FreeBSD.org

Maxim Sobolev wrote:
> 
> Mike Smith wrote:
> 
> > This just isn't going to work.  The _CRS data stream stops at byte 0x17,
> > and these extra items are simply mis-aimed.
> >
> > The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
> > this is a BIOS bug, and should be reported to the vendor.  (It should
> > also have failed the Microsoft ACPI validation suite...)
> >
> > The correct action should probably be to silently discard the write
> > operations outside of a defined buffer, and return Zeroes or Ones for a
> > read outside a buffer.
> 
> Do you have a patch to test this approach? While I understand that the best way to
> resolve the problem is to convince vendors to fix their ACPI implementations, but
> obviously this isn't going to happen any time soon, so appropriate workarround is
> really a must.

The problem is still here as of today's kernel. Please do
something about it.

-Maxim
