Re: hid_ntrig prevents suspend from working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 13 Oct 2010, Florian Echtler wrote:

> On Wed, 2010-10-13 at 10:07 -0400, Alan Stern wrote: 
> > On Wed, 13 Oct 2010, Florian Echtler wrote:
> > > > It would be good to start by finding out where the -EIO error comes
> > > > from.  One likely candidate is where
> > > > drivers/hid/usbhid/hid-core.c:hid_suspend() calls usbhid_wait_io().  Is 
> > > > that the source of the error?  Does the wait_event_timeout() call 
> > > > actually time out?  Since the posted dmesg log was made without 
> > > > CONFIG_PRINTK_TIME, we can't see if there really was a 10-second delay.
> > > Sorry, my mistake:
> > > 
> > > [  226.288305] usbhid 2-1.8:1.1: suspend error -5
> > > [  226.288316] pm_op(): usb_dev_suspend+0x0/0x20 returns -5
> > > [  226.288321] PM: Device 2-1.8 failed to suspend async: error -5
> > > [  226.288426] PM: Some devices failed to suspend
> > > 
> > > So no noticeable delay here.
> > 
> > If there was a delay, it would occur just prior to the first line 
> > above.  So you can't tell from this extract whether or not the timeout 
> > expired.
> I see - wasn't aware of that: 
> 
> [  216.802499] PM: suspend of drv:HDA Intel dev:0000:00:1b.0 complete
> after 239.563 msecs
> [  226.288305] usbhid 2-1.8:1.1: suspend error -5
> [  226.288316] pm_op(): usb_dev_suspend+0x0/0x20 returns -5
> [  226.288321] PM: Device 2-1.8 failed to suspend async: error -5
> [  226.288426] PM: Some devices failed to suspend
> 
> Obviously, the problem is at the location you pointed out earlier.

Yeah, but it remains to be seen why the I/O-wait timed out.  You should 
also check to see which flag usbhid_wait_io is waiting for: 
HID_CTRL_RUNNING or HID_OUT_RUNNING.

> > > Interestingly, however, there's a
> > > significant delay when loading the driver:
> > > 
> > > [  895.253903] ntrig 0003:1B96:0001.0003: hidraw2: USB HID v1.10 Device
> > > [N-trig DuoSense] on usb-0000:00:1d.0-1.8/input0
> > > [  895.254142] ntrig 0003:1B96:0001.0003: Firmware version: 4.8.15.20.7
> > > (2108 8fe2)
> > > [  895.255956] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c:
> > > submitting ctrl urb: Get_Report wValue=0x0101 wIndex=0x0001 wLength=10
> > > [  905.228517] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c:
> > > timeout waiting for ctrl or out queue to clear
> > > [  905.228719] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c:
> > > submitting ctrl urb: Get_Report wValue=0x0103 wIndex=0x0001 wLength=94
> > > [  905.228732] /build/buildd/linux-2.6.35/drivers/hid/usbhid/hid-core.c:
> > > usb_submit_urb(ctrl) failed
> > > [  905.228754] ntrig 0003:1B96:0001.0004: timeout initializing reports
> > Just guessing, this may indicate that the device needs to have the
> > HID_QUIRK_NOGET quirk.
> I've tried "options usbhid quirks=0x1b96:0x0001:0x0008", but without any
> noticeable effect... 

Perhaps this is caused by the following lines near the end of
ntrig_probe(), added by Stephane (commit 6549981bc):

	/* This is needed for devices with more recent firmware versions */
	report = hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0x0a];
	if (report)
		usbhid_submit_report(hdev, report, USB_DIR_OUT);

You can see that this doesn't check for the NOGET quirk.

usbmon might provide some helpful information.  For example, why does
the usb_submit_urb(ctrl) failure occur?

Alan Stern

--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux