Date: Tue, 02 Oct 2001 16:56:44 -0700 From: Mike Smith <msmith@freebsd.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: sobomax@FreeBSD.org, ache@nagual.pp.ru, current@FreeBSD.org, acpi-jp@jp.FreeBSD.org Subject: Re: ACPI: problem with fdc resource allocation Message-ID: <200110022356.f92Nuit03147@mass.dis.org> In-Reply-To: Your message of "Tue, 02 Oct 2001 11:10:45 %2B0900." <20011002.111045.78762705.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110022356.f92Nuit03147>