On Mon, Jul 07, 2014 at 11:24:42AM +0200, Johan Hovold wrote:
> 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 <gre...@linuxfoundation.org> 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?
No, it all seems to work for me. Here's my horrible "hack" I'm running
with on 3.16-rc.
I have seen some issues at times when the touchscreen stops working on
resume, but it just seems "dead". An unload/load of the xhci-hcd module
always fixes that :)
I'll work on making this a "real" patch this week, when I dig out from
my pending patch queue...
thanks,
greg k-h
------------------------
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 21b99b4b4082..7b4c16b408b6 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4456,6 +4456,7 @@ check_highspeed (struct usb_hub *hub, struct usb_device
*udev, int port1)
struct usb_qualifier_descriptor *qual;
int status;
+ return;
qual = kmalloc (sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 0c8a7fc4dad8..347c7231b802 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -644,7 +644,8 @@ int usb_get_descriptor(struct usb_device *dev, unsigned
char type,
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(type << 8) + index, 0, buf, size,
USB_CTRL_GET_TIMEOUT);
- if (result <= 0 && result != -ETIMEDOUT)
+ if (result == 0 || result == -EPIPE)
+// if (result <= 0 && result != -ETIMEDOUT)
continue;
if (result > 1 && ((u8 *)buf)[1] != type) {
result = -ENODATA;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
