[colord] [PATCH] xhci: Don't warn on empty ring for suspended devices.

[Stephen Hemminger]

On Thu, 21 Mar 2013 13:53:34 -0700
Sarah Sharp <sarah.a.sharp at linux.intel.com> wrote:

> On Mon, Mar 18, 2013 at 05:03:07PM -0700, Stephen Hemminger wrote:
> > On Mon, 18 Mar 2013 15:37:30 -0700
> > Sarah Sharp <sarah.a.sharp at linux.intel.com> wrote:
> > 
> > > On Mon, Mar 18, 2013 at 02:26:39PM -0700, Stephen Hemminger wrote:
> > > > The xHCI warnings go away, but using 3.9-rc3 gives a new warning from USB.
> > > > Not sure what colord is doing, I have not color controlled devices on USB, is it
> > > > searching for a scanner (there is none)?
> > > 
> > > Possibly?  It looks like the USB device was suspended, and then woken up
> > > so that colord could send it a message.  The device never responds to
> > > the control transfer, and the request to cancel the URB never completes.
> > > Not good all around.
> > > 
> > > Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING, and
> > > send me the dmesg from boot?  I know it will be a pretty big file, but
> > > I'd like to figure out what the heck colord is doing, and why URBs
> > > aren't being canceled properly.
> > 
> > Ok, see attached.
> 
> Hmm, I don't see any lockdep warnings in dmesg you sent me, so I can't
> really tell what's going on.  If you can get the lockdep to trigger with
> the additional debugging, please email the log to me.  In the meantime,
> I'll queue the patch that makes the suspend resume warnings go away.
> 
> On a side note, it's really aggravating that some userspace program like
> colord is continually polling your USB devices, which is making the bus
> come out of suspend.  The only reason to poll like that should be for
> USB mass storage devices, to detect medium change.  It would certainly
> improve your power management if we could get colord to stop polling USB
> devices continually.
> 
> Sarah Sharp

I may go out on a limb and look at colord internals.