just a question: could it be that the inconsistent manner in which
drivers manipulate dev->tbusy flag is related to the problem?
(Some drivers use atomic bitops, others -- as well as the packet scheduler --
access it by plain C language constructs).
Could this result in certain race scenarios where a busy deviceīs
hard_start_xmit() is called during a tx_timeout condition, the device
cleans up and clears tbusy, but somehow tbusy finally remain set after
hard_start_xmit() returned? (I really donīt know anthing about
those atomic bitops implementation details and possible hidden gotchas,
thus, feel free to laugh at me if this is total nonsence :-)
Henner
-
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/