Another 2.2 version of 3c59x.c

Bogdan Costescu Bogdan.Costescu@IWR.Uni-Heidelberg.De
Wed Apr 26 12:40:27 2000


On Thu, 27 Apr 2000, Andrew Morton wrote:

> "Crash" how?  Do we know that it was driver-related?

That's the problem, I'm not sure. However with the same kernel and 0.99L
it does not appear, at least on the same time-scale. The crashes that I
experienced were with a flooding ping over the weekend (so I don't
really know when it happened) and with my parallel jobs where the time to
crash varies between several minutes and several hours.

> Spent most of the day working on the "tx timeout" problem.  It's being
> caused by 16 successive collisions.  You won't see it on switched
> ethernet, of course.
> 
> I fixed it by resetting the transmitter and fiddling with the DMA engine
> when it happens.  3Com assert that 'TxEnable' is enough to recover from
> maxCollisions, but it isn't so.  TxEnable works most of the time on a
> 905B and _never_ on a 575.

I see an error message related to this at the beginning of
vortex_tx_timeout, but I don't remember you saying that the error message
appears. However, vortex_tx_timeout is called only when tbusy is set which
is done based on the Tx ring and not on the hardware state, so this is
probably the explanation: you send only few packets which do not fill the
ring, but while sending the collisions occur. With the current
implementation, the packet which caused the collision is discarded (as
stated in the docs) and probably the upper levels (TCP) recover at a later
time if they care.
vortex_tx_timeout seems to recover from this situation by doing TxReset
and TxEnable which looks like what you described, but the packet is lost,
there is no attempt to resubmit it. However, resubmitting the packet seems
not like an easy job, because by the time you do this another packet might
be "on the wire" which means that you need to stop the transmitter and
anyway is there any insurance that you catch this event before the
transmission of the next packet is finished?

What do you mean by "TxEnable works _most_ of the time on a 905B" ?

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-request@beowulf.org