On Tue, 7 Apr 2015, Mark Enstone wrote: > linux-usb, > > Apologies if I've come at this the wrong way, I've read MAINTAINERS > and usb-serial.txt to get your name. This is the right place. However, it would be nice for those of us using terminal-based email clients if your messages were wrapped after 72 columns or so. For this reply, I have wrapped them manually. > Kernel 3.15 added logic to usb_serial_generic_read_bulk_callback() to > resubmit read URBs in the general/default fail case (for failures > other than urb->status = ENOENT, ECONNRESET, ESHUTDOWN. Also EPIPE). Presumably in order to handle transient problems. > On Raspberry Pi, running a 3.18 kernel, I am seeing -EPROTO as the > urb->status �in usb_serial_generic_read_bulk_callback() �when the > last CP210X USB-UART device is removed from a hub (the hub remains > attached to the Raspberry Pi).� ((removing a non-last CP210X from the > hub, does not return EPROTO, does return one of the specifically > identified errnos)).� The URB is retried, which fails again with > EPROTO, is retried, fails in the same way again, etc. "forever". At some point, the RPi is supposed to realize that the device was unplugged from the hub. When (or if!) that happens, it will stop retrying. The real question then is why the unplug was never reported. Another question is why this happens only when the _last_ device is removed. Makes me think something funny is going on inside the hub. > I am not seeing this same behavior on a similarly configured Dell > Optiplex desktop.� Thus far, only on RPi. > > > Question: have you seen such behavior? Had you considered adding > EPROTO to the list of urb->status errnos failed rather than > retried?�� If I do fail, rather than retry, the -EPROTO-failed URB, I > get my expected results.� I do not know what the correct approach is, > hoped you could opine:� should I add EPROTO as a "fail" rather than > as a "retry" error in usb_serial_generic_read_bulk_callback() (this > seems to fix my problem)?� Or should I investigate why/where the > EPROTO is coming from vs. why it is not, say, ENOENT (it does not > seem unreasonable to retry an EPROTO IFF EPROTO is considered > transient, however my test case it seems to get "stuck at" EPROTO)?� EPROTO is a valid error code for an URB that was submitted to a device that is no longer plugged in, in which case retrying is pointless. However, it also is a valid error code for the case where a packet got no reply because it was corrupted (say by electromagnetic interference), in which case you probably _would_ want to retry. You're better off investigating why the unplug was never detected. The hub is supposed to report events of this sort within 1/4 second of the time they occur. For this kind of debugging, usbmon is your friend. Alan Stern -- 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
