[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How 'fast' can you issue PCI BIOS calls?
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Re: How 'fast' can you issue PCI BIOS calls?
- From: Dave New <den@aisinc.com>
- Date: Fri, 04 Apr 1997 13:41:10 -0500
- Cc: pci-sig@znyx.com
- Organization: Applied Intelligent Systems
- References: <3344188e0.6c42@snowtown.newjersey.sco.com>
- Resent-Date: Fri, 04 Apr 1997 13:41:10 -0500
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"cSF3-2.0.IT1.7VLHp"@dart>
- Resent-Sender: pci-sig-request@znyx.com
- Sender: den@aisinc.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?)
>
> Thanks. I'm thinking of seeing what the config cycle mechanis'T
> M@RM/:CG>`?Y(^)";R8=00NL-@LLH1-])C-<]:_=#ME@%<4D'=$GZF@8?!9ZC
> M=*0WNJ03>W7O95STP6^@CH9A.&I_^
My theory would be that just blindly reading all the configuration
space bytes from something other than the device driver which is
currently in charge of the device may be triggering something on
the HBA that has a 'side effect'. In other words, reading one
or more of the config bytes is changing the state of the HBA, and
getting it out of sync with the device driver. Whatever code
that you are running to dump out these values really doesn't *own*
the devices in question any more. The device drivers that the OS
loaded do. Maybe having side effects in config space reads is
a nasty, but implementers can pull just about any stunt these
days 8-).
BTW, it appears that the end of your message, as copied above,
was garbled somewhere along the way.
Cheers,
-- DaveN
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave New, den@aisinc.com | Machine vision?
Applied Intelligent Systems | I'm glad *they* can see the future...
3980 Ranchero Drive |
Ann Arbor, MI 48108 | Opinions expressed are mine. | PGP 2.6
(313) 332-7010 | 08 12 9F AF 5B 3E B2 9B 6F DC 66 5A 41 0B AB 29
(313) 332-7077 FAX
ˆ u