FIX: 0.99L and timeouts

[Andrew Morton]

Bogdan Costescu wrote:
> 
> I think I've got it

Well done and thanks.

>From my reading, what must be happening is:

- vortex_start_xmit sees the ring is full and then tries
  to set tx_full()

- But in between these two things, vortex_interrupt gets
  run and sends some packets.

- vortex_start_xmit() gets control again and erroneously
  sets tx_full().

But the question is: why won't the next Tx interrupt clear tx_full?

Because the loop in vortex_interrupt emptied all rings!  There are no
packets queued up to send.  vortex_start_xmit() can't restart the
interrupt stream because it tests tx_full.

Eventually, vortex_tx_timeout() will be invoked by the higher layers and
will clear tx_full.  Is that what you're seeing?

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.

[ And I have a bad feeling that vortex_tx_timeout is racy wrt several
other functions.  Sigh ].

I've cut a patch for Linus's 2.2 driver which incorporates your change
as well as a few other things I've picked up.  I'll let this float
around for a week or so, see if Don has comments, let people test it.
I'll forward the announcement to linux-vortex.

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.

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