From owner-freebsd-current Wed Oct 3 2:38:56 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 E1C6D37B403; Wed, 3 Oct 2001 02:38:42 -0700 (PDT) Received: from vega.vega.com (h231.229.dialup.iptcom.net [212.9.229.231]) by ipcard.iptcom.net (8.9.3/8.9.3) with ESMTP id MAA05012; Wed, 3 Oct 2001 12:37:45 +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 f939bEA78778; Wed, 3 Oct 2001 12:37:14 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3BBADCB7.456D51AD@FreeBSD.org> Date: Wed, 03 Oct 2001 12:39:03 +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: Mike Smith Cc: Mitsuru IWASAKI , ache@nagual.pp.ru, current@FreeBSD.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI: problem with fdc resource allocation References: <200110022356.f92Nuit03147@mass.dis.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 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. -Maxim > > Hi, I've just made a workaround for this. Intel folks, could you review > > it as always? > > > > > The problem is here, right? > > > > can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT > > > > > > I'm sure _SB_.PCI0.ISA_.FDC0._CRS (Current Resource Settings) have some > > > problems (not sure in BIOS or ACPICA yet). I could reproduce the problem > > > which you reported. Trace attached in this mail. > > [snip] > > > dsopcode-0677 [09] DsEvalBufferFieldOpera: Field size 208 exceeds Buffer si > > ze 192 (bits) > > > PsExecute: method failed - \_SB_.PCI0.ISA_.FDC0._CRS (0x8098fa8) > > > Execution of \_SB_.PCI0.ISA_.FDC0._CRS failed with status AE_AML_BUFFER_LIM > > IT > > > > 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). > > I couldn't find how AML interprepter treat this in ACPI Spec. so I'm > > not sure wether AWRDACPI violates the Spec. or ACPICA can have a workaround > > for this. > > Anyway, I made a patch to reallocate a large enough buffer for the > > requested operation. > > > > Thanks > > > > Index: dsopcode.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/contrib/dev/acpica/dsopcode.c,v > > retrieving revision 1.1.1.10 > > diff -u -r1.1.1.10 dsopcode.c > > --- dsopcode.c 7 Sep 2001 01:22:24 -0000 1.1.1.10 > > +++ dsopcode.c 1 Oct 2001 18:58:41 -0000 > > @@ -615,11 +615,24 @@ > > if ((BitOffset + BitCount) > > > (8 * (UINT32) SrcDesc->Buffer.Length)) > > { > > + UINT32 Length; > > + UINT8 *Pointer; > > + > > ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, > > "Field size %d exceeds Buffer size %d (bits)\n", > > BitOffset + BitCount, 8 * (UINT32) SrcDesc->Buffer.Length)) > > ; > > - Status = AE_AML_BUFFER_LIMIT; > > - goto Cleanup; > > + Length = ((BitOffset + BitCount) / 8) + > > + (((BitOffset + BitCount) % 8) ? 1 : 0); > > + Pointer = ACPI_MEM_CALLOCATE (Length); > > + if (!Pointer) > > + { > > + Status = AE_NO_MEMORY; > > + goto Cleanup; > > + } > > + MEMCPY (Pointer, SrcDesc->Buffer.Pointer, SrcDesc->Buffer.Length > > ); > > + ACPI_MEM_FREE (SrcDesc->Buffer.Pointer); > > + SrcDesc->Buffer.Pointer = Pointer; > > + SrcDesc->Buffer.Length = Length; > > } > > > > > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message