Andreas Böhler <news@xxxxxxxxxxx> writes: > On 19/09/17 14:25, Bjørn Mork wrote: >> Bjørn Mork <bjorn@xxxxxxx> writes: >> >> What happens if you kill the mbim-proxy process? Are you then able to >> use the modem again without resetting it? > > I was unable to test that: It can only be killed using SIGKILL, any new > mbim-proxy processes are then unable to open the device. > >> >> 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) > > Well, this looks very promising: Although the error messages persist > every now and then, the device now works! > > I'll make the new module the default and I'll test it more thouroughly > during the next few days. > > Are you planning on adding a more "proper" fix, i.e. without ignoring > the error? Or is this something that should be "fixed" in libmbim? If I only knew what the proper fix was... Ignoring the "error" as such should not be a big problem. It's really just a signal from the firmware that there is no data available to read. There are many similar examples in the Linux USB code. For example from the core code in drivers/usb/core/message.c: static int usb_get_string(struct usb_device *dev, unsigned short langid, unsigned char index, void *buf, int size) { int i; int result; for (i = 0; i < 3; ++i) { /* retry on length 0 or stall; some devices are flakey */ result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, (USB_DT_STRING << 8) + index, langid, buf, size, USB_CTRL_GET_TIMEOUT); if (result == 0 || result == -EPIPE) continue; if (result > 1 && ((u8 *) buf)[1] != USB_DT_STRING) { result = -ENODATA; continue; } break; } return result; } We cannot do the same looping since we are using async requests of course. We could add a counter to catch repeated errors, but I feel that is overkill. Ignoring will do. 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