On Thu, 2016-03-17 at 13:32 -0400, Alan Stern wrote: > In fact both logs show a loop of resets. I'll focus on just the > first reset. > > > No reset loop: > ... > > ffff880118636a80 189630599 S Bo:1:006:1 -115 31 = 55534243 1f000000 > 02000000 80010a51 00000000 00000002 00000000 000000 > > ffff880118636a80 189630639 C Bo:1:006:1 0 31 > > > ffff88003f99ea80 189630649 S Bi:1:006:1 -115 2 < > > ffff88003f99ea80 189635905 C Bi:1:006:1 -75 0 > > ffff880118636a80 189635966 S Bi:1:006:1 -115 13 < > > ffff880118636a80 189636263 C Bi:1:006:1 0 8 = 55534243 1f000000 > > ffff88003f99ea80 189636339 S Co:1:002:0 s 23 03 0004 0002 0000 0 > > ffff88003f99ea80 189636515 C Co:1:002:0 0 0 > > This shows a READ DISC INFORMATION command, asking the device to send > 2 > bytes (the first 2 bytes of the response indicate the total > information > length). The device tried to send back more than 2 bytes, violating > the Mass Storage protocol. This led the computer to do a reset. > After the reset (200 ms later) the computer tried sending the same > command, and the same thing happened. That's where your loop comes > from. > > There's no question about it -- your problem is caused by a buggy > device. This actually doesn't surprise me at all; I became suspicious when I saw that the serial number was 0123456789ABCDEF rather than something that looked more like a serial number. As far as I can tell, the device pretends to be a mass storage device for the purpose of installing drivers on Windows and OS X, in addition to being a networking device. The mass storage part of the device doesn't work under Linux because the device violates the protocol so badly; but nor is it particularly useful or the reason that you'd use the device in the first place. Meanwhile, its networking properties do work under Linux, and are useful, but aren't usable until/unless the device stops resetting. I've also verified that the device itself has the latest firmware; so the problem hasn't been fixed by the manufacturer yet. Do you feel that it's worth implementing some sort of workaround in the kernel? If not, I can either continue using my manual workaround of repeatedly connecting and disconnecting the device until the reset loops stop naturally, or perhaps trying to put pressure on the manufacturer to fix the problem with their device. -- ais523 -- 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
