On Tue, Apr 07, 2015 at 06:57:09PM +0000, 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.
>
> 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).
>
> 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".
>
> 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?
Yes, I just debugged a related issue where using large unaligned buffers
could prevent the hub driver from processing the disconnect event. This
could also be triggered by enabling debugging, which would print the
-EPROTO error message to my slow serial console.
I just realised that this debug message used to be an error before 3.19,
and could therefore trigger the bug you're experiencing on systems with
a slow console.
Could you try updating to 3.19 (or later) or to cherry pick aa8e22128b40
("usb: serial: silence all non-critical read errors") and see if that
helps?
We should backport that one to stable either way.
Thanks,
Johan
--
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
