Thank you very much, this appears to work. > The driver is still a POMS but it seems better now.
I notice that the vendor-supplied driver doesn't have these bugs. Now, it does have a bug in that it doesn't have an "is this interrupt for me?" test at all (and always returns "I handled it"), but the bypass and its locking screwups are a later addition. The same with the sp->rx_current bugs. The original loop which used rx_current as the loop iteration variable wasn't great style, precisely because it hides the interaction that someone's "optimization" broke, but I don't want to blame the vendor for things they didn't do. Would you be interested in some cleanup patches? In particular, I think I can get rid of tx->lock entirely, or at least take it off the fast path. All it's protecting is the write to sp->tx_current, and a few judicious memory barriers can deal with that. (Oh, another BUG: the sp->ResetCurrentTFD logic in hard_start_xmit is just plain broken. It writes the new data to entry 0, then increments sp->tx_current just like usual. THAT isn't in the vendor driver that I see, either.) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
