From owner-freebsd-current Tue Oct 2 16:47: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 4619937B406; Tue, 2 Oct 2001 16:46:55 -0700 (PDT) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.6/8.11.3) with ESMTP id f92Nuit03147; Tue, 2 Oct 2001 16:56:44 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200110022356.f92Nuit03147@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mitsuru IWASAKI Cc: sobomax@FreeBSD.org, ache@nagual.pp.ru, current@FreeBSD.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI: problem with fdc resource allocation In-reply-to: Your message of "Tue, 02 Oct 2001 11:10:45 +0900." <20011002.111045.78762705.iwasaki@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Oct 2001 16:56:44 -0700 From: Mike Smith 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 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. > 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