> > Here's what seems to be an interesting AML or AML parser bug.
> >
> > OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
> > Field(PSRG, DWordAcc, NoLock, Preserve) {
> > , 2,
> > PS2E, 1
> > }
> >
> > The field is marked for 32-bit access, but the region is only 1 byte
> > wide. What's the correct thing to do here? Expand the region to
> > accomodate the field's access requirements? Constrain the access size of
> > the field to that of the region?
>
> I thought read 32-bit, update target bits, write back whole 32-bit for
> updating. For reading value, read 32-bit and shift & mask bits as well.
> I hope I could understand description in Spec 15.2.3.3.1.9; "If desired,
> AccessType can be used to force minimum access width."
This is clarified in the 2.0 spec 16.2.3.3.1.11; the short answer is that
it's illegal. There is already a workaround in the ACPICA code that
truncates over-sized operation requests, but it didn't fix up the
granularity to match. I've added that support and will send it back to
Intel.
I'll also bug Intel about the BIOS in this machine (ISP1100), since this
is a real error. I doubt they'll do much about it though.
Regards,
--
... 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
