Bjørn Mork <bjorn@xxxxxxx> writes:
> Thanks a lot. These are very useful. The thing is that I really cannot
> see anything going wrong there. The "failed" capture just ends with a
> sequence of successful MBIM indications being read from the firmware.
>
> So whatever goes wrong looks like something entirely local to the
> driver. I'll try to poke around some more.
I am wondering if Robert added a hint for us here:
if (desc->rerr) {
/*
* Since there was an error, userspace may decide to not read
* any data after poll'ing.
* We should respond to further attempts from the device to send
* data, so that we can get unstuck.
*/
service_outstanding_interrupt(desc);
}
This might solve only half the problem. The driver does not stop
reading from the firmware as we can see in your pcaps. But if userspace
decided to not read any more data from the driver, then that doesn't
help much, does it?
What happens if you kill the mbim-proxy process? Are you then able to
use the modem again without resetting it?
Maybe we should simply ignore stalls completely? They should not happen
with any real WDM device anyway.
What happens if you e.g. change the if-test here:
/*
* only set a new error if there is no previous error.
* Errors are only cleared during read/open
*/
if (desc->rerr == 0)
desc->rerr = status;
to
if (desc->rerr == 0 && status != -EPIPE)
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
