Another 2.2 version of 3c59x.c

[Bogdan Costescu]

On Thu, 27 Apr 2000, Andrew Morton wrote:

> Nasty.  Did you try patching up the kernel?  2.2.15, perhaps?

I'm now up to 2.2.15pre20 which should transform (AFAIK) to 2.2.15.
Testing so far (6h) didn't experience any problem.

> The idea is to prevent vortex_tx_timeout() from being called at all.
> 
> I did this by recovering from maxCollisions within vortex_error() (as
> soon as the hardware detects the problem), rather than 0.4 seconds
> later, in vortex_tx_timeout().
> 
> The issue was that maxCollisions was stopping the transmitter,
> vortex_error() was not recovering and we were later hitting tx_timeout
> for the recovery.

Sorry, I was thinking that the transmitter is not stalled when
maxCollisions is set which led me to believe that the
download/transmission process continues. I somehow feel that tx_timeout
was a clean-up routine more than vortex_error...

> The 90x spec says that you can recover from maxCollisions simply by
> reenabling the transmitter with TxEnable.  On my 905B this usually
> works, but occasionally TxEnable fails to restart the transmitter and we
> twiddle thumbs until timeout expiry.  On the 575 this happens all the
> time.

Both B and C rev. docs talk about txUnderrun (less probable) and txJabber
- transmitting for too long - (more probable) which need TxReset; these
are indicated by bits 4 and 5 in TxStatus.

The docs also suggest using TxPktId for recovering from collisions, which
can be set to the packet's index in the Tx ring, but will limit
TX_RING_SIZE to 256 (8 bit register). Actually this can also be
implemented as a way to avoid repeatedly reading DownListPtr in
vortex_interrupt on the DownComplete branch.

Talking about txUnderrun, I discovered that the driver is doing something
superfluous for B and C rev. The TxFreeThresh register (offset 2f, page
110 in B docs) exists only on 90x, but not on 90xB and 90xC; on 90x it is
necessary to set it (resetting the card sets it to a value which disable
transmission). The current driver uses it twice: in vortex_open and in
vortex_tx_timeout (calling it 'TxFreeThreshold').

And another thing that IMHO is not done right: in vortex_timer, the driver
selects different windows. vortex_tx_timeout selects window 7 at the end
and can happen async WRT vortex_timer (it's called from start_xmit without
any protection). This is only theoretical, I don't have anything to prove
it...

Finally, a question: is there any figure about how much the
DownStall/DownUnstall operations should take?

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