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. thanks, greg k-h -- 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
