Fri, 24 Nov 2000 15:29:54 +0100 (CET)
On Fri, 24 Nov 2000, Andrew Morton wrote:
> hmm.. dhinds has changed 3c575_cb.c so that it prints out the ASIC
> rev numbers. Cut, paste...
I wanted to suggest this too, but from what I've seen in the patch this is
just the info that also vortex-diag is printing. Tornado has at address
0x8 in the PCI configuration space a byte called RevisionId (page 65 and
70); this is supposed to show the ASIC revision. As the documentation is
quite scarce, I have no ideea about relations between the RevisionId, the
EEPROM data and the data written on the chip. Can both Berkan and Richard
take a look at the chip and tell us what the ID is ? (which should look
like 40-0574-xxx or 40-05772-xxx)
For Richard: what are the MII interfaces detected at module init ? is
mii-diag working for you without specifying '-p 24' ?
> > BTW: is there any way to make these waits non-busy?
> That's normally OK. It normally terminates within 0-2 PCI cycles.
> It's just these wierd cases where it can take a long time. As I recall,
> timeouts >2,000 PCI cycles occurred every ten minutes or so under
> absolutely wicked testing conditions.
> ...But what worries me is:
> 1: We also do RxReset from within the error handler. Possibly at
> interrupt time. What to do there?
> 2: Does it affect other commands?
> 3: We don't know what's going on.
I haven't checked with a debugger, but I suppose that the compiler is
generating the right code, as it works in most cases (it could optimize,
as the code inside the loop is only reading, not writting anything). If
the code is correct, the only possibility (AFAICS) is that the 'in'
operations finish much more quickly in some cases, which suggests some
kind of caching of PCI reads. But as this only seldomly happens, there
might be some PCI chipset's rules about when to start caching, like too
many reads from the same address in a certain time... Actually, I don't
find this too strange as last year Josip Loncaric posted a message on the
beowulf list with details about memory access throttling by the BX
If this is really the case, increasing the loop count will not generate
latency, as the reads will be much faster than normal; however, there is
no count that is guaranteed to work in all the cases 8-(
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868