FIX: 0.99L and timeouts

[Bogdan Costescu]

On Wed, 19 Apr 2000, Andrew Morton wrote:

> > As I wrote in my previous message, there are 2 cases (or races) depending
> > on which variable is updated/tested. In one case it's tx_full (which is
> > the one described by you), in the other case is cur_tx.
> 
> True.  The fix you proposed closes them both though?

Yes, they were both after the enabling of the interrupts in
boomerang_start_xmit and now are before the spinlock.
However, I do have a problem with your current driver: in start_xmit

	outw(DownUnstall, ioaddr + EL3_CMD)
	
is still before

	vp->cur_tx++;
	if (vp->curt_tx - vp->dirty_tx ....)

while my proposal (that's how my tests were done) was to move it along
with restore_flags/spin_unclock _after_ these lines.
With your driver, after less than 2 minutes of high load, I get an "Unable
to dereference pointer..." and the system locks; I moved the outw after
these lines (and even after spin_unlock_irqsave) and now I'm able to
finish my test without problems. I think this is another race: if you
unstall the downloading, the card can go on and produces another interrupt
which needs the vp->cur_tx to compute entry and prev_entry (at the
beginning, before spin_lock_irqsave) at about the same time as
vp->cur_tx++...

> > programming and not so much time... I'll come back with performance
> > impressions in few days.
> 
> Thanks.

I do have a first result, but it's about the same as what I got with
0.99L. I think that the communication is limited by the high TCP latency
and not by the driver... But I'll continue benchmarking.

> BTW, are you running full duplex?  I'm seeing a few reports about duplex
> negotiation problems and bad Tx performance when full duplex is forced.
> (I suspect this may be due to config problems at the other end of the
> wire though).

Yes, I'm running full duplex. However, I had to modify both 0.99L and your
driver to get this: set 3c905C as IS_CYCLONE|HAS_NWAY and then comment out
one line in vortex_probe1:

/*	if (vp->info1 & 0x8000)		*/
		vp->full_duplex = 1;

(this is documented in my post on vortex-bug from 24 Nov 1999). Please
note that I didn't put much thought on this, I didn't have the docs and I
just wanted the cards to work in full duplex (as I have 905B cards working
correctly with the unmodified driver and I know the switch supports full
duplex - BayNetworks 350-24T).
I never forced full duplex on the switch, as Mr. Becker suggested several
times on different driver lists. IMHO, if both the card and the switch
support standard auto-negotiation, they should do it.

> BTW2: if you're running half-duplex, what is 'ifconfig' saying about the
> collision count?  I'm seeing a _huge_ number of collisions running
> 10baseT half duplex.  Collisions are being reported at about 30% of the
> rate of tx packets.  This is something I've observed for 6 months on my
> machines at work (905C) and I assumed it was due to poor LAN design. 

AKAIK, you can have large numbers of collisions in half duplex (and
without flow-control) if you are using hubs (you didn't specify this) and
you have intense traffic.

> But it seems to be a driver problem.

How did you draw this conclusion?

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-bug-request@beowulf.org