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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
