On Wed, Nov 27, 2013 at 11:51:29AM -0500, Alan Stern wrote:
> On Wed, 27 Nov 2013, Johan Hovold wrote:
>
> > > I am attaching the output that I am getting in the syslog. Note that I
> > > have
> > > two usb modems connected to that router and that's how I am able to debug
> > > it.
> > > 2-1 is an external USB2.0 hub, 2-1.2 is the ZTE modem, and 2-1.1 is a
> > > Huawei
> > > CDMA modem, which is working fine. The problem happens both with and
> > > without
> > > a hub.
> >
> > The transmissions are failing with -ENOENT (-2), and the "clear tt
> > buffer" are related to the hub.
> >
> > Can you get a log from when not using the hub?
> >
> > Could you try reproducing this on v3.12?
> >
> > Alan, what do you think of this?
>
> The -ENOENT means that the transfers were cancelled. Perhaps because
> of a timeout or perhaps for some other reason.
>
> The "clear tt buffer" lines are merely side effects of the cancelled
> transfers. Running the test without the external hub ought to
> eliminate them. It would simplify the test results, so it's worth
> doing.
>
> Also, it might be worthwhile to collect a usbmon trace during the test.
> The output might be meaningful to somebody who understands how this
> driver is supposed to work.
Dmitry, first you could try reproducing this with (dynamic) debugging
enabled, for example, echo the following to
/sys/kernel/debug/dynamic_debug/control:
module usbserial +p
func usb_serial_generic_read_bulk_callback -p
func usb_serial_generic_submit_read_urb -p
func usb_serial_debug_data -p
module zte_ev +p
The -ENOENT are likely from an ordinary close of the device. Wasn't
thinking clearly yesterday. :)
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
