Another 2.2 version of 3c59x.c

[Andrew Morton]

Bogdan Costescu wrote:
> 
> 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.

Good point.

> 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').

mm..  Seems harmless for revs B and C though.

> 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...

Heck, I think you're right.

I believe these are both run from bottom half queues.  I also believe
that under 2.2 there is a single BH queue, so this may protect us.  But
under 2.3 I believe these functions could run in parallel.  I'll check
this.

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

No figures I can see.  But unstall is instantaneous.

I am finding that on a very collisiony LAN, DownStall is exceeding the
2000-loop counter on a 500MHz CPU.  I upped it to 4,000 in the 2.3
driver and the problem went away.  The whole aproach is pretty ugly, but
without some hardware timer which we can spin on, and with recent
breakage in the semantics of the 'loops-per-sec' variable there's no
obvious rework here.
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-request@beowulf.org