I was recently corrected in this... for modern drivers it's really a
bug (see drivers/net/tg3.c::tg3_start_xmit). The queue should be
managed such that it is awake only when there is room for more packets.
For example, one code path (not the default one) in dev_queue_xmit will
just drop the skb, not requeue it for later.
>>tx_timeout() method
>>=================
>>
>>there is no way to return an error in the tx_timeout method. what should I
>>do when an error occurs in that function (e.g. I'm unable to reset the
>>controller)? panic? that seems a bit excessive...
>
>
> Try again ? If that fails I guess you initiate the self destruct
> sequence for just that driver.
The typical method is to reset the NIC hardware, and either requeue
waiting packets or drop all the packets you have waiting on the floor.
tx_timeout is a generic catch-all that normally happens when the NIC is
wedged.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/