[ I tried the tulip mailing list, but didn't get any responses. ]
I'm seeing some RX lock-up problems on a DS21143 when pushing large amounts of small-packet one-way traffic to the system. What happens is that the RX count on the interface stops incrementing, the dropped count is incrementing, TX works (can see the packets arriving at another system), but no RX packets are received. Hardware flow-control is not configured.
What appears to be happening is that at some point the driver determines that too much work has been done in the interrupt and triggers the interrupt mitigation procedure. This sets CSR11 so that the host is interrupted only when 4 packets have been received, and then it clears all interrupts. What appears to be happening is that between the time that it finishes processing the RX chain and sets CSR11 and clears all interrupts, the RX chain fills up (or almost fills up) with new packets. The interrupts are then all cleared, but because there are no free slots for new packets, the device goes into suspended mode, dropping all new packets, and thus not generating any new Rx or NoBuf interrupts. The driver thus never checks for any new packets even if it is interrupted for some other reason.
There appear to be a number of ways of addressing this issue, although I'm not 100 percent certain that I've diagnosed it correctly. The fix I'm currently testing is not clearing the Rx/Tx NoBuf interrupt when mitigation occurs (which appears to work), although I could imagine only clearing the Rx/Tx interrupt instead of all interrupts, or even ensuring that there is a least one available rx buffer after clearing all interrupts.
-- Ben Gamsa ben@xxxxxxxxxxxxxxxx SOMA Networks, Inc. 312 Adelaide St. W. Suite 600 Toronto, Ontario, M5V1R2
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
