On Mon, 29 Sep 2003 22:49:29 -0700
"David S. Miller" [off-list ref] wrote:

On Mon, 29 Sep 2003 14:36:42 -0700
Andrew Morton [off-list ref] wrote:

quoted

Oh, it's taking xmit_lock in a timer handler.  I give up.

I think e1000 should rethink what it is doing :-)

Sorry, in case it isn't painfully obvious, instead of hinting
at it let me state explicitly that ->xmit_lock is a BH disabling
lock not an IRQ disabling one.

Therefore, e1000's IRQ disabling when grabbing that lock is
buggy and need to be changed to BH disabling.

If it needs to disable IRQs for it's own internal locking, it
needs to do so such that such IRQ disabling internal locks
are not held while kfree_skb() is being invoked.

Calling kfree_skb() with IRQs disabled in the e1000 driver is
the cause of this bug.

Jeff, if you pushed these e1000 updates that make it grap
->xmit_lock() with disabling IRQs instead of BH into 2.4.x
trees too, beware!