On Sun, Jun 01, 2014 at 10:43:21AM -0700, Greg Kroah-Hartman wrote: > On Sun, Jun 01, 2014 at 12:21:55PM -0400, Alan Stern wrote: > > On Sun, 1 Jun 2014, Bjørn Mork wrote: > > > > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > > > > > Ok, here's the dump for when the device keeps disconnecting itself from > > > > the bus (no call to check_highspeed() anymore). > > > > > > > > Things go better, but then the device just goes quiet, and resets. Any > > > > ideas? I'll dig further this evening... > > > > > > > > ffff8800d906a0c0 2610372685 S Ci:2:112:0 s 80 06 0100 0000 0012 18 < > > > > ffff8800d906a0c0 2610372929 C Ci:2:112:0 0 18 = 12010002 00000008 f3048900 1300040e 0001 > > > > ffff8801d684d540 2610372974 S Ci:2:112:0 s 80 06 0200 0000 0009 9 < > > > > ffff8801d684d540 2610373139 C Ci:2:112:0 0 9 = 09022900 010100e0 32 > > > > ffff8801d684d540 2610373167 S Ci:2:112:0 s 80 06 0200 0000 0029 41 < > > > > ffff8801d684d540 2610373479 C Ci:2:112:0 0 41 = 09022900 010100e0 32090400 00020300 00000921 10010001 229d0307 05810340 > > > > ffff8801d684dd80 2610373508 S Ci:2:112:0 s 80 06 0300 0000 00ff 255 < > > > > ffff8801d684dd80 2610373612 C Ci:2:112:0 0 4 = 04030904 > > > > ffff8801d684dd80 2610373636 S Ci:2:112:0 s 80 06 030e 0409 00ff 255 < > > > > ffff8801d684dd80 2610373895 C Ci:2:112:0 0 24 = 18035400 6f007500 63006800 73006300 72006500 65006e00 > > > > ffff8801d684dd80 2610373922 S Ci:2:112:0 s 80 06 0304 0409 00ff 255 < > > > > ffff8801d684dd80 2610374066 C Ci:2:112:0 0 10 = 0a034500 4c004100 4e00 > > > > ffff8800d906a9c0 2610374602 S Co:2:112:0 s 00 09 0001 0000 0000 0 > > > > ffff8800d906a9c0 2610374645 C Co:2:112:0 0 0 > > > > > > set config is successful, and then it looks like you are entering > > > usbhid_parse(), which is called during hid_add_device(): > > > > > > > ffff8800d906a780 2610374837 S Co:2:112:0 s 21 0a 0000 0000 0000 0 > > > > ffff8800d906a780 2610374940 C Co:2:112:0 0 0 > > > > > > hid_set_idle(dev, interface->desc.bInterfaceNumber, 0, 0); > > > > > > > ffff8801d684d0c0 2610374976 S Ci:2:112:0 s 81 06 2200 0000 039d 925 < > > > > ffff8801d684d0c0 2610379698 C Ci:2:112:0 0 925 = 050d0904 a1018501 0922a102 09421500 25017501 95018102 75018103 75060951 > > > > > > ret = hid_get_class_descriptor(dev, interface->desc.bInterfaceNumber, > > > HID_DT_REPORT, rdesc, rsize); > > > > > > > ffff8801d684d840 2610381285 S Ci:2:001:0 s a3 00 0000 0007 0004 4 < > > > > ffff8801d684d840 2610381303 C Ci:2:001:0 0 4 = 03010000 > > > > > > And there you lost the device? And me with it... > > > > Not there exactly. This is normal; the hub driver checks the hub's > > port status again after the device has been initialized and registered. > > > > The real problem happened a couple of seconds later: > > > > > ffff880211d106c0 2612480635 C Ii:2:001:1 0:2048 2 = 8000 > > > ffff880211d106c0 2612480649 S Ii:2:001:1 -115:2048 4 < > > > ffff8800739bd240 2612480693 S Ci:2:001:0 s a3 00 0000 0007 0004 4 < > > > ffff8800739bd240 2612480711 C Ci:2:001:0 0 4 = 00010100 > > > > This shows the device disconnected itself from the USB bus. No obvious > > reason why. As a wild guess, perhaps the device expected to receive > > some packets from the host and got confused when they didn't arrive. > > > > Notice that there was no activity from any HID driver. Once the report > > descriptor was fetched, nothing more happened. Did any driver bind to > > the HID device? What does the dmesg log say? > > > > > But if this device really isn't able to cope with the > > > USB_DT_DEVICE_QUALIFIER descriptor request, then it might not be > > > prepared for anything "out of the ordinary"? Is there any other possible > > > explanation for the sudden resets than a firmware crash due to > > > unexpected input? > > > > There was no unexpected input. In fact, there was no input at all > > after the kernel read the report descriptor. Not only was no data sent > > either way, there weren't even any URBs submitted for input or output. > > > > > The failure seems to happen before any of the known HID quirks have any > > > effect, so who knows what can be done differently here? Maybe you have > > > to dump the exact sequence used by Windows and recreate that somehow? > > > > > > Or just play with a userspace program to see what kind of requests you > > > can send to this device without making it crash (after temporarily > > > blacklisting usbhid to avoid the initial crash)? > > > > It doesn't look to me like a crash. It looks more like the driver is > > missing. > > Doh, I had based my kernel config on my desktop, and it didn't have the > hid multitouch driver enabled. > > Turning that on and, wow, it works! Thanks for pointing out my stupid > error. > > So, new quirk time, for a device that can't handle the check_highspeed > command. I'll do that late tonight after I go handle some household > responsibilities. I ended up getting the same laptop so now I'm facing the same problem with repeated disconnects (especially during resume, which is really annoying as it adds about a minute to resume time), even with a hard-coded check-high speed "quirk" and the multitouch driver loaded. Did you manage to fix the disconnect issue? Are you seeing something similar at resume? 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
