[EMAIL PROTECTED] wrote:
The system ACPI BIOS is attempting to access PCI configuration space
directly rather than using the correct PCI Config space operation regions.
This is unsafe - directly accessing config space like this is non-atomic.
The OSL implementation blocks these accesses.
Perhaps, Dana, you can give us some AML recipes on how to fix this?
I'm more inclined to add an additional acpi-user-options bit
to permit users to relax the I/O permission checks. Legacy
acpi_intp had no permission check and I don't recall any
bugs filed, though any problem resulting from non-atomic access
to PCI config space is likely to be pretty mysterious.
I have an old ASUS CUV4X which has the same problem, it defines an
operating region:
OperationRegion (PCIC, SystemIO, 0x0CF8, 0x08)
Field (PCIC, DWordAcc, NoLock, Preserve)
{
PIND, 32,
PDAT, 32
Heavens. This is a non-trivial bit of work.
First of all, you'd need to figure which PCI device's config space is
being accessed; you'll need to work the 0xCF8 access backwards,
and this is pretty helpful:
http://thorkildsen.no/faqsys/docs/pci.txt
And the uses the following _STA method for the FDC0 (floppy device):
Method (_STA, 0, NotSerialized)
{
Store (0x80002084, PIND) <-- bad
So I think this is an access to Bus #0, Device#4, offset 0x84
Store (PDAT, Local0) <-- bad
and this is a read of the device config space.
So now you need to locate/create a PCI device object underneath
the correct PCI bridge device and create a PCI_Config operation
region underneath it:
Device (FLOPPYTHING)
{
Name (_ADR, 0x00040000)
OperationRegion (FTCFS, PCI_Config, 0x84, 0x01)
Field (FTCFS, ByteAcc, NoLock, Preserve)
{
FTSTA, 8
}
And you could then access this field with:
Store(\_SB.<table-dependent-PCI-device-path-here>.FLOPPYTHING.FTSTA,
Local0);
A couple of notes; only the 'host' (peer) PCI bridge devices
have _BBN objects which (if they're not broken) identify which
PCI bus the bridge hosts. Child buses need to be found by
relating the _ADR() objects of the children to the PCI config
space of the system.
It's non-trivial.
Now if I could rewrite the AML to do the proper thing and install the
replacement
ACPICA table (just as I fixed the Ferrari 4000 batter), such a recipe might
help some to see what the exact problem is.
Sure.
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
Dan (Mick) pushed out a useful version on playground at:
ftp://playground.sun.com/pub/dmick/iasl
and, at some point, we'll see about including it in the WOS.
Dana
_______________________________________________
opensolaris-discuss mailing list
[email protected]
