Re: 2.1.131-ac3 3c509 no irq_save in the sender code

Alan Cox (alan@lxorguk.ukuu.org.uk)
Sat, 5 Dec 1998 18:24:45 +0000 (GMT)

> Are you sure you are not reinserting a bug? Using the irq_save spinlock
> would avoid that an irq handler start playing with the NIC while it was
> sending data (outsl(ioaddr + TX_FIFO, skb->data, (skb->len + 3) >>
> 2);) also in UP. I think this is the reason of the TX timeout errors under
> flood. So I think you should reverse the patch above (just done here ;).

Don't reverse it. That trashes your interrupt latency. An irq_save spinlock
isnt acceptable for an ISA bus block transfer, you might be 2mS with irqs
off.

If you look at the change, it does what Ingo suggested which is to disable
the receive interrupt during a transmit (tx is single threaded implicitly),
that way only the card suffers. This means the only irq locked off is the
3c509 one.

You still need a spinlock because another CPU could begin executing a transmit
during a receive. In which case we spin on the spinlock until the receive
irq completes (in actual fact I believe the disable_irq handles that), and
also because any CPU could execute a get_stats request.

So I believe the code to be correct.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/