Re: How 'fast' can you issue PCI BIOS calls?

["David O'Shea" <daveo@corollary.com>]

>mek@sco.com wrote:
>> 
>> Chasing down a problem in some code that is effectively doing:
>> 
>>         for (i = 0; i < 256; i++)
>>                 READ CONFIG BYTE(bus, devfun, i, result[i])
>> 
>> bus and devfun are found by an earlier config space scan (much earlier)
>> and might be 'active' devices. What is happening is that after the above
>> loop is run, some PCI devices (some PCI SCSI HBA's) start timing out.
>> 
>> One theory is that the above is flooding the implementor of the config
>> cycle (the bus). But, it's going through BIOS with some mutexes around
>> the BIOS calls, so the 'series' of READ CONFIG BYTE calls do not overlap.
>> But, perhaps the bridge implementing the call can't keep up? Should the
>> BIOS call be wrappered with some delays to prevent overload?
>> 
>> config cycles *are* safe to do at any time, aren't they? Or is this only
>> the case for type 1 config access mechanism? That is, type 2 might be
>> hitting a deadlock due to the use of C000-CFFF (some other system activity
>> causing access to these I/O registers?)

The problem is not with the speed of the calls.  You just can't do what
you are doing at any speed.  It is not allowed to read all of a devices
configuration space blind like that.  Devices are allowed to place any
types of registers they want in the configuration space after the standard
header (which ends at 39h, ie. 40h starts vendor defined registers).

Some vendors (many vendors) put registers which have side effects in
them when read.  For instance, reading a interrupt condition register
may also clear it.   So, unless you know what you are reading, you can't
just read all of the configuration space of a device like that.  You can
only read the header blindly (0-39h).   

Reading above 40h is never a safe practice, but if the device is actually
operating, then it is doubly unsafe, since any side effects from reading
vendor specific configuration space registers would interact with other device
status and operations from the legitimate actions of a BIOS or device driver.
Some vendors have some of their control registers aliased in all of
I/O space, memory space, and configuration space.   For instance, SOME of
the Adpatec 2940 registers appear in all threee spaces.  If any of these
has a read side effect, you could have problems.  

I mention the overloading because you could say, "...but we don't see any
other configuration cycles besides ours...."   Well, the device driver could
be doing I/O or Mem cycles that are interacting with your configuration 
cycles to the same device.

Bottom line is:  You can't just blindly read VENDOR SPECIFIC configuration
registers EVER!!!!   It is NOT OK.   Confine your scans to below 40h, i.e.
the standard PCI header.   If drivers want to get more information, then
they can call some support routine to go read the configuration space and
get the data themselves.  The device driver obviously knows WHAT is safe
to read and WHAT is not, it also knows WHEN things are safe to read and
WHEN not.

David O'Shea
daveo@corollary.com