PLEASE, could anyone who knows more about this card/chip and driver
spent a few minutes looking into this driver and check if this
can't be fixed easily with some more knowledge than I have...
there have been a number of reports at least for 3c905 (Boomerang) card owners
who get driver lockups for very high netloads (even one very fast host-to-host
transfer is sufficient) which result in lots of these kernel messages:
eth0: transmit timed out, tx_status 88 status e000.
eth0: Transmitter encountered 16 collisions -- network network cable problem?
Flags; bus-master 1, full 1; dirty 560482 current 560498.
Down list 07ffe940 vs. 07ffe920.
0: 07ffe920 length 8000002a status 8000002a
1: 07ffe930 length 80000052 status 80000052
2: 07ffe940 length 8000009e status 0000009e
3: 07ffe950 length 8000002a status 0000002a
4: 07ffe960 length 8000002a status 0000002a
and these messages repeat over and over until
ifconfig eth0 down
ifconfig eth0 up
up is used (routing tables ahave to be reset too).
this leads me to the conclusion that this is a problem where either
the card or the driver doesn't correctly try to reset and startup
again after this bug/message. obviously this
/* Issue TX_RESET and TX_START commands. */
outw(TxReset, ioaddr + EL3_CMD);
for (i = 20; i >= 0 ; i--)
if ( ! (inw(ioaddr + EL3_STATUS) & CmdInProgress))
break;
outw(TxEnable, ioaddr + EL3_CMD);
isn't enough (or too much, or just wrong?). I guess it couldn't be too
difficult either to do some more chip reset here or set a flag that
another part of the driver will initialize again or similar
(just call that small bit of code which is the important one
when using ifconfig down/up...)
btw: we're still using the "boomerang.c" driver v0.37 because this
was the last version which does not show these very bad receive
performace problems as v0.39 or 0.40 do now. but at least v0.39
showed the same problems and v0.40 would just disable Rx busmastering
here which is not a real option:
if (vp->full_bus_master_rx) {
printk(" Switching to non-bus-master receives.\n");
outw(SetStatusEnb | AdapterFailure|IntReq|StatsFull |
or should we just completely forget about these 3COM cards and return
them all and get other cards (perferably using DEC chip, e.g. TULIP) ?
and last not least:
could anyone plesae give some more details what's the real reason
for the driver message
Rx Pacing bug exists, disabling bus-master receives.
(aside from a bit in the configuration EEPROM not being set) ?
for which cards/board revisions could this happen ?
could this be fixed without returning cards ?
are there any 3c905 cards which don't have this bug ?
is busmastered receive really impossible ?
also the driver says
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
is this now 8 kByte RAM, or 8 kWord (giving 16 (or 32?) kbytes?) ?
if only 8kbytes, this would give
10 MByte/sec / 1500 bytes[MUT] ~= 6600 packets/sec
and only 2 packets would fit into the 3k Rx buffer then. so without
DMA support for receive, this card can only store one packet while
receiving the next one and the driver has to be called 6600 times per
second to copy/clean the receive buffer to avoid packet loss.
even this buffer is 8k 16bit-words, there are still at least 2200 calls/sec
needed to copy the 3 received packets while 4th packet is coming in...
pretty much in my eyes, isn't it? or what am I missing ?
thanks for any hint or help how this lockup in the driver
could be solved (or for any pointer that it's useless to
waste more time with these broken cards...)
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^