FIX: 0.99L and timeouts

[Andrew Morton]

Bogdan Costescu wrote:
> 
> On Sun, 16 Apr 2000, Andrew Morton wrote:
> 
> > >From my reading, what must be happening is: ...
> > Eventually, vortex_tx_timeout() will be invoked by the higher layers and
> > will clear tx_full.  Is that what you're seeing?
> 
> 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?

> > So it's an IRQ race, not an SMP race.  Could conceivably happen on
> > uniprocessor. Can only happen if max_interrupt_work is greater than
> > TX_RING_SIZE.
> 
> I was only able to reproduce it with SMP because the 2 pieces of code
> which deal with updating/testing the variables are executed simultaneously
> on different CPUs. The way you described it... well, I think it's possible
> even with UP.
> I don't quite agree with the max_interrupt_work statement: the Tx ring is
> emptied in a small 'while' loop on the DownComplete branch independent on
> the big 'do' loop which is there for RxComplete and counts for
> max_interrupt_work. You can go through the interrupt only once (so
> max_interrupt_work must be at least 1) and empty even a full Tx ring.

You're right.

> > [ And I have a bad feeling that vortex_tx_timeout is racy wrt several
> > other functions.  Sigh ].
> 
> I haven't looked into this, but if I don't get Tx timeouts anymore how can
> test the races? 8-)

mm..  It needs close inspection.  I doubt if we'd get a tx interrupt
within tx_timeout(!), and the rx path is pretty independent.  There may
be some assumptions about the current regiser window.

> > Note that my patch uses conventional spinlocking and removes the cli()
> > call from vortex_start_xmit().  cli() is a truly horrid thing on SMP. It
> > sends an interprocessor interrupt to all other CPUs, waits for them
> > _all_ to be lined up and listening and then issues commands to them.
> > This removal is a plus against the spinlocks' minus. If you can try out
> > my patched driver I'd be interested in hearing about any performance
> > impressions.
> 
> I thought of this too, but I have little experience with kernel
> programming and not so much time... I'll come back with performance
> impressions in few days.

Thanks.


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

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. 
But it seems to be a driver problem.


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