> we have written a linux network device driver with an ethernet interface,
>developed using the skeleton device driver. But now - with kernel 2.0.34 -
>we ran into a problem with the transmit handler. My question is: what should
>be done in the transmit handler if the device is not ready to transmit
>another packet?
> 1. Return a value != 0 and say "Hey kernel, requeue this packet! I can't
> send now!" ? The effect I saw then was that the machine locks up with
> interrupts disabled.
This is the correct action.
You should make certain that dev->tbusy is set if you return a non-zero
value.
Note: The queue layer might still occasionally try to send you a packet even
with 'tbusy' set. This is used to implement Tx-timeouts -- checking for
transmitter hangs. The historical reason for doing this was that no
dynamically allocated general-purpose timer routines were available in old
kernels. Why do Ethernet cards, especially old ethernet cards, hang? They
have to deal with synchronizing fast asynchronous subsystems -- something
theoretically impossible to do reliably, and empirically difficult circuits
to design.
> 2. Return 0 and say "Ok kernel, I sent this packet (no one knows it's a
lie)!" ? This works, but it seems not to be the perfect solution.
It's evil because it just drops the packet.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html