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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
