Usb_rndis stops working after a while

[pulkomandy]

I get this error from xhci:

link descriptor for pipe: max transfers count exceeded

This seems a bit strange, if tqe driver works as I think; there should be only one read und only one write transfer happening at any time? Is there some case where the transfers are not properly finished?

[waddlesplash]

If there are no other errors in the syslog preceding this one, then this is probably an issue with the usb_rndis driver. The error means that too many transfers are queued at once; so are you really sure only one is happening at a time?

At any rate, it should be possible to recover from this error using cancel_queued_transfers.

[waddlesplash]

Probably we should change this error message to indicate what pipe/endpoint the maximum transfers count has been exceeded on, though.

[waddlesplash]

I'm not sure what the upper layers of the stack do, but is it possible Write() is called multiple times concurrently?

[pulkomandy]

I kept trying to debug this today and yes, it seems Write is called from multiple threads. The code is certainly not designed to handle that, but it is similar to other USB ethernet drivers, so I'm wondering how these other drivers manage to work.

I have tried to use send_message/receive_message instead of a semaphore, to allow handling the notifications to multiple threads cleanly. It solved the xhci error messages, but things still seem to lock up. I expected I could schedule multiple transfers in the USB stack and let it handle them and call the callbacks. Is that supposed to work? Or should I add some locking to make sure there is only one transfer "in flight" at a time?

[waddlesplash]

Fix merged in hrev57161.