Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Oliver Neukum]

On Mon, 2016-03-21 at 11:46 -0400, Alan Stern wrote:
> On Mon, 21 Mar 2016, Oliver Neukum wrote:
> 
> > On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> > 
> > Almost. In case of reset_resume() it makes no sense to still
> > clear a halt or execute a reset that had been ordered. The
> > corresponding flags should be cleared.
> 
> hid_post_reset() already clears the HID_RESET_PENDING flag.  It also
> needs to clear the HID_CLEAR_HALT flag; I'll add that in.
> 
> > And now that I think of it, if while restarting IO an
> > old error condition is detected shouldn't the restart wait for
> > the error to be handled?
> 
> Yes; we should avoid starting I/O if a reset is pending and we should
> avoid starting the interrupt-IN URB if a clear-halt is pending.  How
> does this patch look?

Perfect.

Regards
Oliver



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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 21 Mar 2016, Oliver Neukum wrote:

> On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:
> 
> > @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
> >  static int hid_reset_resume(struct usb_interface *intf)
> >  {
> > struct hid_device *hid = usb_get_intfdata(intf);
> > -   struct usbhid_device *usbhid = hid->driver_data;
> > int status;
> >  
> > -   clear_bit(HID_SUSPENDED, >iofl);
> > status = hid_post_reset(intf);
> > if (status >= 0 && hid->driver && hid->driver->reset_resume) {
> > int ret = hid->driver->reset_resume(hid);
> 
> Almost. In case of reset_resume() it makes no sense to still
> clear a halt or execute a reset that had been ordered. The
> corresponding flags should be cleared.

hid_post_reset() already clears the HID_RESET_PENDING flag.  It also
needs to clear the HID_CLEAR_HALT flag; I'll add that in.

> And now that I think of it, if while restarting IO an
> old error condition is detected shouldn't the restart wait for
> the error to be handled?

Yes; we should avoid starting I/O if a reset is pending and we should
avoid starting the interrupt-IN URB if a clear-halt is pending.  How
does this patch look?

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -951,14 +951,6 @@ static int usbhid_output_report(struct h
return ret;
 }
 
-static void usbhid_restart_queues(struct usbhid_device *usbhid)
-{
-   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
-   usbhid_restart_out_queue(usbhid);
-   if (!test_bit(HID_CTRL_RUNNING, >iofl))
-   usbhid_restart_ctrl_queue(usbhid);
-}
-
 static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
 {
struct usbhid_device *usbhid = hid->driver_data;
@@ -1404,6 +1396,37 @@ static void hid_cease_io(struct usbhid_d
usb_kill_urb(usbhid->urbout);
 }
 
+static void hid_restart_io(struct hid_device *hid)
+{
+   struct usbhid_device *usbhid = hid->driver_data;
+   int clear_halt = test_bit(HID_CLEAR_HALT, >iofl);
+   int reset_pending = test_bit(HID_RESET_PENDING, >iofl);
+
+   spin_lock_irq(>lock);
+   clear_bit(HID_SUSPENDED, >iofl);
+   usbhid_mark_busy(usbhid);
+
+   if (clear_halt || reset_pending)
+   schedule_work(>reset_work);
+   usbhid->retry_delay = 0;
+   spin_unlock_irq(>lock);
+
+   if (reset_pending || !test_bit(HID_STARTED, >iofl))
+   return;
+
+   if (!clear_halt) {
+   if (hid_start_in(hid) < 0)
+   hid_io_error(hid);
+   }
+
+   spin_lock_irq(>lock);
+   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
+   usbhid_restart_out_queue(usbhid);
+   if (!test_bit(HID_CTRL_RUNNING, >iofl))
+   usbhid_restart_ctrl_queue(usbhid);
+   spin_unlock_irq(>lock);
+}
+
 /* Treat USB reset pretty much the same as suspend/resume */
 static int hid_pre_reset(struct usb_interface *intf)
 {
@@ -1453,14 +1476,14 @@ static int hid_post_reset(struct usb_int
return 1;
}
 
+   /* No need to do another reset or clear a halted endpoint */
spin_lock_irq(>lock);
clear_bit(HID_RESET_PENDING, >iofl);
+   clear_bit(HID_CLEAR_HALT, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
-   usbhid_restart_queues(usbhid);
+
+   hid_restart_io(hid);
 
return 0;
 }
@@ -1483,25 +1506,9 @@ void usbhid_put_power(struct hid_device
 #ifdef CONFIG_PM
 static int hid_resume_common(struct hid_device *hid, bool driver_suspended)
 {
-   struct usbhid_device *usbhid = hid->driver_data;
-   int status;
-
-   spin_lock_irq(>lock);
-   clear_bit(HID_SUSPENDED, >iofl);
-   usbhid_mark_busy(usbhid);
-
-   if (test_bit(HID_CLEAR_HALT, >iofl) ||
-   test_bit(HID_RESET_PENDING, >iofl))
-   schedule_work(>reset_work);
-   usbhid->retry_delay = 0;
-
-   usbhid_restart_queues(usbhid);
-   spin_unlock_irq(>lock);
-
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
+   int status = 0;
 
+   hid_restart_io(hid);
if (driver_suspended && hid->driver && hid->driver->resume)
status = hid->driver->resume(hid);
return status;
@@ -1570,12 +1577,8 @@ static int hid_suspend(struct usb_interf
 static int hid_resume(struct usb_interface *intf)
 {
struct hid_device *hid = usb_get_intfdata (intf);
-   struct usbhid_device *usbhid = hid->driver_data;
int status;
 
-   if (!test_bit(HID_STARTED, >iofl))
-   return 0;
-
status = hid_resume_common(hid, true);
  

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Oliver Neukum]

On Fri, 2016-03-18 at 12:36 -0400, Alan Stern wrote:

> @@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
>  static int hid_reset_resume(struct usb_interface *intf)
>  {
>   struct hid_device *hid = usb_get_intfdata(intf);
> - struct usbhid_device *usbhid = hid->driver_data;
>   int status;
>  
> - clear_bit(HID_SUSPENDED, >iofl);
>   status = hid_post_reset(intf);
>   if (status >= 0 && hid->driver && hid->driver->reset_resume) {
>   int ret = hid->driver->reset_resume(hid);

Almost. In case of reset_resume() it makes no sense to still
clear a halt or execute a reset that had been ordered. The
corresponding flags should be cleared.

And now that I think of it, if while restarting IO an
old error condition is detected shouldn't the restart wait for
the error to be handled?

Regards
Oliver



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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Fri, 18 Mar 2016 12:36:42 -0400 (EDT)
Alan Stern  wrote:

> All right, I have taken Oliver's suggestion.  The patch below refactors 
> the code to consolidate the common activities in a new function, 
> hid_restart_io().
> 
> Daniel, can you please test this patch?

Alan, this patch works perfectly ;) Thanks.

-- 
Linux 4.5.0-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 14 Mar 2016, Oliver Neukum wrote:

> On Mon, 2016-03-14 at 11:03 -0400, Alan Stern wrote:
> > On Mon, 14 Mar 2016, Oliver Neukum wrote:
> 
> > > It seems to me that hid_resume_common() needs to be split into three
> > > parts
> > > 
> > > a) doing the stuff for pending resets
> > > b) conditionally restarting IO
> > > c) reset the flag 
> > 
> > Daniel's problem involved hid_post_reset(), not hid_resume_common().  
> > Is that what you meant?  Maybe I'm wrong, but it looks like 
> > hid_post_reset() just needs to check whether I/O should be started 
> > before trying to restart it.
> 
> Yes. That means that all that hid_post_reset() does before calling
> hid_start_in() must be left unchanged and we can put the change into
> a common code path.
> 
> > (It also looks like hid_resume() needs to clear the HID_SUSPENDED flag 
> > even when HID_STARTED isn't set.)
> 
> Exactly. Thus hid_resume_common() needs to be split. The code paths
> for reset_resume(), post_reset() and resume() diverge too much. You will
> see that they can be easily be reused if you split them into
> those three parts.

All right, I have taken Oliver's suggestion.  The patch below refactors 
the code to consolidate the common activities in a new function, 
hid_restart_io().

Daniel, can you please test this patch?

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -951,14 +951,6 @@ static int usbhid_output_report(struct h
return ret;
 }
 
-static void usbhid_restart_queues(struct usbhid_device *usbhid)
-{
-   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
-   usbhid_restart_out_queue(usbhid);
-   if (!test_bit(HID_CTRL_RUNNING, >iofl))
-   usbhid_restart_ctrl_queue(usbhid);
-}
-
 static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
 {
struct usbhid_device *usbhid = hid->driver_data;
@@ -1404,6 +1396,33 @@ static void hid_cease_io(struct usbhid_d
usb_kill_urb(usbhid->urbout);
 }
 
+static void hid_restart_io(struct hid_device *hid)
+{
+   struct usbhid_device *usbhid = hid->driver_data;
+
+   spin_lock_irq(>lock);
+   clear_bit(HID_SUSPENDED, >iofl);
+   usbhid_mark_busy(usbhid);
+
+   if (test_bit(HID_CLEAR_HALT, >iofl) ||
+   test_bit(HID_RESET_PENDING, >iofl))
+   schedule_work(>reset_work);
+   usbhid->retry_delay = 0;
+   spin_unlock_irq(>lock);
+
+   if (test_bit(HID_STARTED, >iofl)) {
+   if (hid_start_in(hid) < 0)
+   hid_io_error(hid);
+
+   spin_lock_irq(>lock);
+   if (usbhid->urbout && !test_bit(HID_OUT_RUNNING, >iofl))
+   usbhid_restart_out_queue(usbhid);
+   if (!test_bit(HID_CTRL_RUNNING, >iofl))
+   usbhid_restart_ctrl_queue(usbhid);
+   spin_unlock_irq(>lock);
+   }
+}
+
 /* Treat USB reset pretty much the same as suspend/resume */
 static int hid_pre_reset(struct usb_interface *intf)
 {
@@ -1457,10 +1476,8 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
-   usbhid_restart_queues(usbhid);
+
+   hid_restart_io(hid);
 
return 0;
 }
@@ -1483,25 +1500,9 @@ void usbhid_put_power(struct hid_device
 #ifdef CONFIG_PM
 static int hid_resume_common(struct hid_device *hid, bool driver_suspended)
 {
-   struct usbhid_device *usbhid = hid->driver_data;
-   int status;
-
-   spin_lock_irq(>lock);
-   clear_bit(HID_SUSPENDED, >iofl);
-   usbhid_mark_busy(usbhid);
-
-   if (test_bit(HID_CLEAR_HALT, >iofl) ||
-   test_bit(HID_RESET_PENDING, >iofl))
-   schedule_work(>reset_work);
-   usbhid->retry_delay = 0;
-
-   usbhid_restart_queues(usbhid);
-   spin_unlock_irq(>lock);
-
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
+   int status = 0;
 
+   hid_restart_io(hid);
if (driver_suspended && hid->driver && hid->driver->resume)
status = hid->driver->resume(hid);
return status;
@@ -1570,12 +1571,8 @@ static int hid_suspend(struct usb_interf
 static int hid_resume(struct usb_interface *intf)
 {
struct hid_device *hid = usb_get_intfdata (intf);
-   struct usbhid_device *usbhid = hid->driver_data;
int status;
 
-   if (!test_bit(HID_STARTED, >iofl))
-   return 0;
-
status = hid_resume_common(hid, true);
dev_dbg(>dev, "resume status %d\n", status);
return 0;
@@ -1584,10 +1581,8 @@ static int hid_resume(struct usb_interfa
 static 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Oliver Neukum]

On Mon, 2016-03-14 at 11:03 -0400, Alan Stern wrote:
> On Mon, 14 Mar 2016, Oliver Neukum wrote:

> > It seems to me that hid_resume_common() needs to be split into three
> > parts
> > 
> > a) doing the stuff for pending resets
> > b) conditionally restarting IO
> > c) reset the flag 
> 
> Daniel's problem involved hid_post_reset(), not hid_resume_common().  
> Is that what you meant?  Maybe I'm wrong, but it looks like 
> hid_post_reset() just needs to check whether I/O should be started 
> before trying to restart it.

Yes. That means that all that hid_post_reset() does before calling
hid_start_in() must be left unchanged and we can put the change into
a common code path.

> (It also looks like hid_resume() needs to clear the HID_SUSPENDED flag 
> even when HID_STARTED isn't set.)

Exactly. Thus hid_resume_common() needs to be split. The code paths
for reset_resume(), post_reset() and resume() diverge too much. You will
see that they can be easily be reused if you split them into
those three parts.

Regards
Oliver



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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 14 Mar 2016, Oliver Neukum wrote:

> On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:
> 
> > Perhaps I didn't do a good job of addressing the real underlying
> > problem.  That's why I asked if this was the right approach.
> > 
> > In Daniel's case, usbhid_start() never got called.  Perhaps that's the
> > real problem?  Anyway, this meant that usbhid->urbin never got set, and
> > consequently hid_start_in() returned an error when it was called by
> > hid_post_reset().
> > 
> > Does it make sense for usbhid_start() not to be called?
> 
> If it depends on other modules, we can hardly guarantee it
> being called.

Okay.

> > It stands out that hid_resume() checks the HID_STARTED bit before
> > calling hid_start_in() but hid_post_reset() doesn't.  That is
> 
> I think the assumption is that resets are caused by the operation
> of the HID interface. In practice this is almost invariably true,

Not at all.  For one thing, a reset may be started by a driver for
another interface on the same device.  For another, a reset-resume can
occur at any time, if the device is attached through a host controller
that loses power during suspend (which is what happened to Daniel).

> but strictly speaking both methods must check the flag.

So that does need to be added.

> It seems to me that hid_resume_common() needs to be split into three
> parts
> 
> a) doing the stuff for pending resets
> b) conditionally restarting IO
> c) reset the flag 

Daniel's problem involved hid_post_reset(), not hid_resume_common().  
Is that what you meant?  Maybe I'm wrong, but it looks like 
hid_post_reset() just needs to check whether I/O should be started 
before trying to restart it.

(It also looks like hid_resume() needs to clear the HID_SUSPENDED flag 
even when HID_STARTED isn't set.)

Alan Stern

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Oliver Neukum]

On Fri, 2016-03-11 at 11:54 -0500, Alan Stern wrote:

> Perhaps I didn't do a good job of addressing the real underlying
> problem.  That's why I asked if this was the right approach.
> 
> In Daniel's case, usbhid_start() never got called.  Perhaps that's the
> real problem?  Anyway, this meant that usbhid->urbin never got set, and
> consequently hid_start_in() returned an error when it was called by
> hid_post_reset().
> 
> Does it make sense for usbhid_start() not to be called?

If it depends on other modules, we can hardly guarantee it
being called.

> It stands out that hid_resume() checks the HID_STARTED bit before
> calling hid_start_in() but hid_post_reset() doesn't.  That is

I think the assumption is that resets are caused by the operation
of the HID interface. In practice this is almost invariably true,
but strictly speaking both methods must check the flag.

> inconsistent; the check should be done in both places or in neither,
> but I don't know which.  Is it possible for one of usbhid's devices to
> be suspended or reset before usbhid_start() or after usbhid_stop()?  If 
> it is then both places need to check -- my patch adds the missing 
> check.
> 
> Finally, isn't it possible for an HID device not to have an 
> interrupt-IN endpoint?  In which case usbhid->urbin will always be

That would violate chapter 4.4 of the HID spec.

> NULL, so hid_start_in() will always return an error unless it 
> specifically checks -- and my patch adds such a check.
> 
> As you can see, it's a complicated and confusing situation.  Maybe 
> you'd like to explore it in greater depth with Daniel to understand it 
> better.

It seems to me that hid_resume_common() needs to be split into three
parts

a) doing the stuff for pending resets
b) conditionally restarting IO
c) reset the flag 

Regards
Oliver



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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Fri, 11 Mar 2016, Jiri Kosina wrote:

> On Wed, 2 Mar 2016, Alan Stern wrote:
> 
> [ ... snip ... ]
> > The patch that fixed Daniel's problem is repeated below for your 
> > convenience.  Is this the right approach?  If you think it is, I'll 
> > submit it officially.
> 
> I've been thinking about this, and while I don't really like such bandaids 
> being added to the generic code, I haven't been able to come up with 
> anything better.
> 
> So the aproach is fine with me ... perhaps a short comment before testing 
> HID_STARTED wouldn't hurt as well, as it has a potential of making code 
> reader's head spin.

Perhaps I didn't do a good job of addressing the real underlying
problem.  That's why I asked if this was the right approach.

In Daniel's case, usbhid_start() never got called.  Perhaps that's the
real problem?  Anyway, this meant that usbhid->urbin never got set, and
consequently hid_start_in() returned an error when it was called by
hid_post_reset().

Does it make sense for usbhid_start() not to be called?

It stands out that hid_resume() checks the HID_STARTED bit before
calling hid_start_in() but hid_post_reset() doesn't.  That is
inconsistent; the check should be done in both places or in neither,
but I don't know which.  Is it possible for one of usbhid's devices to
be suspended or reset before usbhid_start() or after usbhid_stop()?  If 
it is then both places need to check -- my patch adds the missing 
check.

Finally, isn't it possible for an HID device not to have an 
interrupt-IN endpoint?  In which case usbhid->urbin will always be 
NULL, so hid_start_in() will always return an error unless it 
specifically checks -- and my patch adds such a check.

As you can see, it's a complicated and confusing situation.  Maybe 
you'd like to explore it in greater depth with Daniel to understand it 
better.

What do you suggest?

Alan Stern

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Jiri Kosina]

On Wed, 2 Mar 2016, Alan Stern wrote:

[ ... snip ... ]
> The patch that fixed Daniel's problem is repeated below for your 
> convenience.  Is this the right approach?  If you think it is, I'll 
> submit it officially.

I've been thinking about this, and while I don't really like such bandaids 
being added to the generic code, I haven't been able to come up with 
anything better.

So the aproach is fine with me ... perhaps a short comment before testing 
HID_STARTED wouldn't hurt as well, as it has a potential of making code 
reader's head spin.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 1 Mar 2016, Daniel Fraga wrote:

> On Tue, 1 Mar 2016 17:15:56 -0500 (EST)
> Alan Stern  wrote:
> 
> > Don't worry about the Elan driver.  Instead, let's see if this patch 
> > fixes the problem.
> 
>   Yes, this patch fixed the problem. I can suspend and resume
> without those repeated "reset" messages ;)
> 
>   It appears just 1 time and that's it:
> 
> [  644.691934] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
> 
>   Now it's fine :) But if you still need more tests, just ask.

That patch fixed the problem, but I'm not sure it's the best solution.  
Time to ask the usbhid maintainers.

Jiri and Benjamin: Daniel's problem boils down to this: He's got an
Elan touchscreen that he doesn't use.  The touchscreen driver isn't
even loaded.  As a result, the kernel never calls usbhid_start() and
usbhid->urbin never gets allocated.

That would be okay, except that hid_post_reset() unconditionally 
hid_start_in() and then reports an error because there is no input URB 
to start!  Looking through the code, it appears that HID_STARTED isn't 
checked consistently.  It does get checked in the hid_resume() path but 
not in the hid_reset_resume() or hid_post_reset() paths.

And even then, it's not clear that the check in hid_resume() is in the
right spot.  If HID_STARTED isn't set then the code skips calling
hid_resume_common(), which means the HID_SUSPENDED bit doesn't get
cleared.  Overall, the use of the flag bits in these callback routines
could use some auditing.

One more thing: usbhid_start() carefully looks for an IN endpoint and
uses it for usbhid_urbin.  But there's no check for devices that don't
have any IN endpoints (such as a device that relies entirely on polling
over the control endpoint, or a device that is output-only).  Is this
supposed to be an error?  If it isn't, then does hid_start_in() need to
check that usbhid->urbin isn't NULL before trying to submit it?

The patch that fixed Daniel's problem is repeated below for your 
convenience.  Is this the right approach?  If you think it is, I'll 
submit it officially.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -83,6 +83,7 @@ static int hid_start_in(struct hid_devic
 
spin_lock_irqsave(>lock, flags);
if ((hid->open > 0 || hid->quirks & HID_QUIRK_ALWAYS_POLL) &&
+   usbhid->urbin &&
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
@@ -1457,10 +1458,13 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
-   usbhid_restart_queues(usbhid);
+
+   if (test_bit(HID_STARTED, >iofl)) {
+   status = hid_start_in(hid);
+   if (status < 0)
+   hid_io_error(hid);
+   usbhid_restart_queues(usbhid);
+   }
 
return 0;
 }

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 17:15:56 -0500 (EST)
Alan Stern  wrote:

> Don't worry about the Elan driver.  Instead, let's see if this patch 
> fixes the problem.

Yes, this patch fixed the problem. I can suspend and resume
without those repeated "reset" messages ;)

It appears just 1 time and that's it:

[  644.691934] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci

Now it's fine :) But if you still need more tests, just ask.

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 1 Mar 2016, Daniel Fraga wrote:

> On Tue, 1 Mar 2016 15:55:00 -0500 (EST)
> Alan Stern  wrote:
> 
> > No messages about "usbhid_start urb" or "no input endpoint!" or 
> > "usbhid_start fail urb"?  That means usbhid_start() isn't getting 
> > called.  Which means the device in question probably isn't being used 
> > at all.
> > Do you know what this device is?  What does 
> > /sys/kernel/debug/usb/devices show?
> 
>   I attached the output of /sys/kernel/debug/usb/devices.
> 
>   It's probably this one:
> 
> T:  Bus=03 Lev=02 Prnt=02 Port=05 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
> D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=04f3 ProdID=0034 Rev= 0.12
> S:  Manufacturer=ELAN
> S:  Product=Touchscreen
> C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
> E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
> E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=10ms

Yes, that's right.

>   In fact this seems to be the touchscreen "Elan" on the display,
> but since I'm using this laptop with an external monitor, I didn't even
> mind to use it (since I don't even use touchscreen at all).
> 
>   Do you want me to load the module for the Elan driver or is it
> irrelevant?

For now it's irrelevant.  Try loading it if you want; it might make the 
problem disappear.  But we still have to fix the problem.

> > Let's make sure this is really what's happening.  Please try this 
> > patch.
> 
>   Ok, with this patch I got before suspend:
> 
> [3.558767] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
> [3.651808] usbhid 3-1.6:1.0: usbhid_probe -> 0

Okay, as I thought -- usbhid_start() isn't getting called.

>   As far as I know, this shouldn't happen even if the Elan driver module 
> isn't loaded, 
> right? But if you ask me to load the Elan driver module, ok, I can do it and 
> test with the
> driver loaded...

Don't worry about the Elan driver.  Instead, let's see if this patch 
fixes the problem.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -83,6 +83,7 @@ static int hid_start_in(struct hid_devic
 
spin_lock_irqsave(>lock, flags);
if ((hid->open > 0 || hid->quirks & HID_QUIRK_ALWAYS_POLL) &&
+   usbhid->urbin &&
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
@@ -1457,10 +1458,13 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
-   if (status < 0)
-   hid_io_error(hid);
-   usbhid_restart_queues(usbhid);
+
+   if (test_bit(HID_STARTED, >iofl)) {
+   status = hid_start_in(hid);
+   if (status < 0)
+   hid_io_error(hid);
+   usbhid_restart_queues(usbhid);
+   }
 
return 0;
 }

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 15:55:00 -0500 (EST)
Alan Stern  wrote:

> No messages about "usbhid_start urb" or "no input endpoint!" or 
> "usbhid_start fail urb"?  That means usbhid_start() isn't getting 
> called.  Which means the device in question probably isn't being used 
> at all.
> Do you know what this device is?  What does 
> /sys/kernel/debug/usb/devices show?

I attached the output of /sys/kernel/debug/usb/devices.

It's probably this one:

T:  Bus=03 Lev=02 Prnt=02 Port=05 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04f3 ProdID=0034 Rev= 0.12
S:  Manufacturer=ELAN
S:  Product=Touchscreen
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=03(Int.) MxPS=  32 Ivl=10ms

In fact this seems to be the touchscreen "Elan" on the display,
but since I'm using this laptop with an external monitor, I didn't even
mind to use it (since I don't even use touchscreen at all).

Do you want me to load the module for the Elan driver or is it
irrelevant?

> Let's make sure this is really what's happening.  Please try this 
> patch.

Ok, with this patch I got before suspend:

[3.558767] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
[3.651808] usbhid 3-1.6:1.0: usbhid_probe -> 0

After suspend:

[  444.460573] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  444.613578] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  445.792493] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci
[  445.945473] usb 3-1.6: reset full-speed USB device number 6 using ehci-pci

and after removing and loading ehci-pci module (to interrupt those 
repeated messages):

[  447.533614] usb 3-1.6: USB disconnect, device number 0
[  447.907325] usb 3-1.6: device not accepting address 6, error -22
[  447.907414] usbhid 3-1.6:1.0: usbhid_probe -> -19
[  449.295221] usb 3-1.6: new full-speed USB device number 6 using ehci-pci
[  449.387835] usbhid 3-1.6:1.0: usbhid_probe -> 0

***

As far as I know, this shouldn't happen even if the Elan driver module 
isn't loaded, 
right? But if you ask me to load the Elan driver module, ok, I can do it and 
test with the
driver loaded...

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 2
B:  Alloc=  4/800 us ( 1%), #Int=  4, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 4.04
S:  Manufacturer=Linux 4.4.3-dirty ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 8
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=8000 Rev= 0.04
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=03 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  3 Spd=1.5  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c316 Rev=28.00
S:  Manufacturer=Logitech
S:  Product=Logitech USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms

T:  Bus=03 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#=  4 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1532 ProdID=0016 Rev= 1.00
S:  Manufacturer=Razer
S:  Product=Razer DeathAdder
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=1ms

T:  Bus=03 Lev=02 Prnt=02 Port=04 Cnt=03 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=0036 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 1 Mar 2016, Daniel Fraga wrote:

> On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
> Alan Stern  wrote:
> 
> > Now we're making progress!  That shows a problem right there; we ought 
> > to have more stuff about 3-1.6 between those two lines.
> > 
> > The next patch adds some more debugging output.  For this test you 
> > don't even have to suspend the system; all I need to see is the output 
> > for 3-1.6 during boot-up and shortly thereafter.
> 
>   No new messages during boot-up (I tried to reboot 3 times). I just got 
> the following:
> 
> Mar  1 16:33:55 tux kernel: [3.558535] usb 3-1.6: new full-speed USB 
> device number 6 using ehci-pci

No messages about "usbhid_start urb" or "no input endpoint!" or 
"usbhid_start fail urb"?  That means usbhid_start() isn't getting 
called.  Which means the device in question probably isn't being used 
at all.

Do you know what this device is?  What does 
/sys/kernel/debug/usb/devices show?

Let's make sure this is really what's happening.  Please try this 
patch.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1159,6 +1159,7 @@ static int usbhid_start(struct hid_devic
usbhid_set_leds(hid);
device_set_wakeup_enable(>dev, 1);
}
+   dev_info(>intf->dev, "usbhid_start -> 0, %p\n", usbhid->urbin);
return 0;
 
 fail:
@@ -1169,6 +1170,7 @@ fail:
usbhid->urbout = NULL;
usbhid->urbctrl = NULL;
hid_free_buffers(dev, hid);
+   dev_info(>intf->dev, "usbhid_start -> %d\n", ret);
return ret;
 }
 
@@ -1178,6 +1180,7 @@ static void usbhid_stop(struct hid_devic
 
if (WARN_ON(!usbhid))
return;
+   dev_info(>intf->dev, "usbhid_stop\n");
 
if (hid->quirks & HID_QUIRK_ALWAYS_POLL)
usbhid->intf->needs_remote_wakeup = 0;
@@ -1366,11 +1369,13 @@ static int usbhid_probe(struct usb_inter
goto err_free;
}
 
+   dev_info(>dev, "usbhid_probe -> %d\n", 0);
return 0;
 err_free:
kfree(usbhid);
 err:
hid_destroy_device(hid);
+   dev_info(>dev, "usbhid_probe -> %d\n", ret);
return ret;
 }
 

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern  wrote:

> Now we're making progress!  That shows a problem right there; we ought 
> to have more stuff about 3-1.6 between those two lines.
> 
> The next patch adds some more debugging output.  For this test you 
> don't even have to suspend the system; all I need to see is the output 
> for 3-1.6 during boot-up and shortly thereafter.

Unless you want all the USB related lines (but as you can see, no line 
related 
to 3-1.6 device):

[2.409541] usbcore: registered new interface driver usbhid
[2.409544] usbhid: USB HID core driver
[4.978957] usbhid 1-1:1.0: usbhid_start urb 8802550c89c0
[6.063118] usbhid 3-1.3:1.0: usbhid_start urb 8802553de900
[6.113703] usbhid 3-1.3:1.1: usbhid_start urb 8802553de0c0
[6.165616] usbhid 3-1.4:1.0: usbhid_start urb 880253e82540
[   27.760614] usbhid 1-1:1.0: usbhid_stop urb 8802550c89c0
[   31.181268] usbhid 3-1.4:1.0: usbhid_stop urb 880253e82540
[   31.184302] usbhid 3-1.4:1.0: usbhid_start urb 8802551e3840
[   31.249291] usbhid 3-1.4:1.0: usbhid_stop urb 8802551e3840
[   32.185425] usbhid 3-1.4:1.0: usbhid_start urb 88009474a540
[   32.250251] usbhid 3-1.4:1.0: usbhid_stop urb 88009474a540
[   33.186774] usbhid 3-1.4:1.0: usbhid_start urb 880253f593c0
[   87.237292] usbhid 3-1.3:1.0: usbhid_stop urb 8802553de900
[   87.252257] usbhid 3-1.3:1.1: usbhid_stop urb 8802553de0c0
[   87.276263] usbhid 3-1.4:1.0: usbhid_stop urb 880253f593c0
[   88.310249] usbhid 3-1.3:1.0: usbhid_start urb 880252287900
[   88.368040] usbhid 3-1.3:1.1: usbhid_start urb 880253f2a900
[   88.584825] usbhid 3-1.4:1.0: usbhid_start urb 88009474a000

After the suspend test:

[  425.327979] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  425.327993] usbhid 3-1.4:1.0: hid_cease_io urb 88009474a000
[  425.328001] usbhid 3-1.3:1.1: hid_cease_io urb 880253f2a900
[  425.330161] usbhid 3-1.3:1.0: hid_cease_io urb 880252287900
[  427.165478] usbhid 3-1.3:1.0: hid_start_in: urbin 880252287900
[  427.165500] usbhid 3-1.3:1.0: post reset hid_start_in -> 0
[  427.171082] usbhid 3-1.3:1.1: hid_start_in: urbin 880253f2a900
[  427.171089] usbhid 3-1.3:1.1: post reset hid_start_in -> 0
[  427.486326] usbhid 3-1.4:1.0: post reset hid_start_in -> 0
[  427.638818] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  427.638822] usbhid 3-1.6:1.0: start failed: -22
[  427.638824] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.500552] usbhid 1-1:1.0: usbhid_start urb 88008704f0c0
[  428.665256] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  428.828684] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  428.828688] usbhid 3-1.6:1.0: start failed: -22
[  428.828690] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.828696] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  428.981809] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)
[  428.981814] usbhid 3-1.6:1.0: start failed: -22
[  428.981816] usbhid 3-1.6:1.0: post reset hid_start_in -> -22
[  428.981823] usbhid 3-1.6:1.0: hid_cease_io urb   (null)
[  429.134398] usbhid 3-1.6:1.0: hid_start_in: urbin   (null)

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 1 Mar 2016 10:25:30 -0500 (EST)
Alan Stern  wrote:

> Now we're making progress!  That shows a problem right there; we ought 
> to have more stuff about 3-1.6 between those two lines.
> 
> The next patch adds some more debugging output.  For this test you 
> don't even have to suspend the system; all I need to see is the output 
> for 3-1.6 during boot-up and shortly thereafter.

No new messages during boot-up (I tried to reboot 3 times). I just got 
the following:

Mar  1 16:33:55 tux kernel: [3.558535] usb 3-1.6: new full-speed USB device 
number 6 using ehci-pci

So I did another suspend test:

Mar  1 16:41:19 tux kernel: [  479.374488] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:19 tux kernel: [  479.465138] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:19 tux kernel: [  479.465143] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:20 tux kernel: [  479.465145] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:20 tux kernel: [  479.465151] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Mar  1 16:41:20 tux kernel: [  479.527491] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:20 tux kernel: [  479.618014] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:20 tux kernel: [  479.618018] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:20 tux kernel: [  479.618020] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:20 tux kernel: [  480.644543] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Mar  1 16:41:20 tux kernel: [  480.717528] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Mar  1 16:41:20 tux kernel: [  480.807595] usbhid 3-1.6:1.0: hid_start_in: 
urbin   (null)
Mar  1 16:41:21 tux kernel: [  480.807598] usbhid 3-1.6:1.0: start failed: -22
Mar  1 16:41:21 tux kernel: [  480.807599] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Mar  1 16:41:21 tux kernel: [  480.807603] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)

-- 
Linux 4.4.3-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 29 Feb 2016, Daniel Fraga wrote:

> On Mon, 29 Feb 2016 16:28:40 -0500 (EST)
> Alan Stern  wrote:
> 
> > Okay, that's what I had guessed.  Somehow usbhid->urbin is getting set 
> > to NULL.  Maybe the patch below will indicate why.  When you post the 
> > log, include everything that mentions the 3-1.6 device -- even if they 
> > precede the suspend test.
> 
>   Ok, before the suspend test:
> 
> Feb 29 18:40:47 tux kernel: [3.512861] usb 3-1.6: new full-speed USB 
> device number 6 using ehci-pci
> Feb 29 18:41:55 tux kernel: [  118.890031] usbhid 3-1.6:1.0: hid_cease_io urb 
>   (null)

Now we're making progress!  That shows a problem right there; we ought 
to have more stuff about 3-1.6 between those two lines.

The next patch adds some more debugging output.  For this test you 
don't even have to suspend the system; all I need to see is the output 
for 3-1.6 during boot-up and shortly thereafter.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -75,7 +75,7 @@ static int hid_submit_ctrl(struct hid_de
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid);
 
 /* Start up the input URB */
-static int hid_start_in(struct hid_device *hid)
+static int hid_start_in(struct hid_device *hid, int alantest)
 {
unsigned long flags;
int rc = 0;
@@ -86,8 +86,12 @@ static int hid_start_in(struct hid_devic
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
+   if (alantest)
+   dev_info(>intf->dev, "hid_start_in: urbin 
%p\n", usbhid->urbin);
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
+   if (alantest)
+   dev_info(>intf->dev, "start failed: 
%d\n", rc);
clear_bit(HID_IN_RUNNING, >iofl);
if (rc == -ENOSPC)
set_bit(HID_NO_BANDWIDTH, >iofl);
@@ -106,7 +110,7 @@ static void hid_retry_timeout(unsigned l
struct usbhid_device *usbhid = hid->driver_data;
 
dev_dbg(>intf->dev, "retrying intr urb\n");
-   if (hid_start_in(hid))
+   if (hid_start_in(hid, 0))
hid_io_error(hid);
 }
 
@@ -123,7 +127,7 @@ static void hid_reset(struct work_struct
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
if (rc == 0) {
-   hid_start_in(hid);
+   hid_start_in(hid, 0);
} else {
dev_dbg(>intf->dev,
"clear-halt failed: %d\n", rc);
@@ -690,7 +694,7 @@ int usbhid_open(struct hid_device *hid)
}
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, >iofl);
-   res = hid_start_in(hid);
+   res = hid_start_in(hid, 0);
if (res) {
if (res != -ENOSPC) {
hid_io_error(hid);
@@ -1100,6 +1104,7 @@ static int usbhid_start(struct hid_devic
continue;
if (!(usbhid->urbin = usb_alloc_urb(0, GFP_KERNEL)))
goto fail;
+   dev_info(>dev, "usbhid_start urb %p\n", 
usbhid->urbin);
pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
usb_fill_int_urb(usbhid->urbin, dev, pipe, 
usbhid->inbuf, insize,
 hid_irq_in, hid, interval);
@@ -1117,6 +1122,8 @@ static int usbhid_start(struct hid_devic
usbhid->urbout->transfer_flags |= 
URB_NO_TRANSFER_DMA_MAP;
}
}
+   if (!usbhid->urbin)
+   dev_info(>dev, "no input endpoint!\n");
 
usbhid->urbctrl = usb_alloc_urb(0, GFP_KERNEL);
if (!usbhid->urbctrl) {
@@ -1139,7 +1146,7 @@ static int usbhid_start(struct hid_devic
if (ret)
goto fail;
usbhid->intf->needs_remote_wakeup = 1;
-   ret = hid_start_in(hid);
+   ret = hid_start_in(hid, 1);
if (ret) {
dev_err(>dev,
"failed to start in urb: %d\n", ret);
@@ -1162,6 +1169,7 @@ static int usbhid_start(struct hid_devic
return 0;
 
 fail:
+   dev_info(>dev, "usbhid_start fail urb %p\n", usbhid->urbin);
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbout);
usb_free_urb(usbhid->urbctrl);
@@ -1194,6 +1202,7 @@ static void usbhid_stop(struct 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Mon, 29 Feb 2016 16:28:40 -0500 (EST)
Alan Stern  wrote:

> Okay, that's what I had guessed.  Somehow usbhid->urbin is getting set 
> to NULL.  Maybe the patch below will indicate why.  When you post the 
> log, include everything that mentions the 3-1.6 device -- even if they 
> precede the suspend test.

Ok, before the suspend test:

Feb 29 18:40:47 tux kernel: [3.512861] usb 3-1.6: new full-speed USB device 
number 6 using ehci-pci
Feb 29 18:41:55 tux kernel: [  118.890031] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Feb 29 18:41:55 tux kernel: [  118.890072] usbhid 3-1.4:1.0: hid_cease_io urb 
880096618d80
Feb 29 18:41:55 tux kernel: [  118.890122] usbhid 3-1.3:1.1: hid_cease_io urb 
880253a46300
Feb 29 18:41:55 tux kernel: [  118.891350] sd 0:0:0:0: [sda] Synchronizing SCSI 
cache
Feb 29 18:41:55 tux kernel: [  118.891432] sd 0:0:0:0: [sda] Stopping disk
Feb 29 18:41:55 tux kernel: [  118.894505] usbhid 3-1.3:1.0: hid_cease_io urb 
880253a46b40
Feb 29 18:41:55 tux kernel: [  119.941526] PM: suspend of devices complete 
after 1051.699 msecs
Feb 29 18:41:55 tux kernel: [  119.954412] PM: late suspend of devices complete 
after 12.875 msecs

After the suspend test (I included more lines because of the 
"hid_start_in", just in case...):

Feb 29 18:41:59 tux kernel: [  120.359026] usb 1-2: reset high-speed USB device 
number 3 using xhci_hcd
Feb 29 18:41:59 tux kernel: [  120.449789] usb 3-1.3: reset low-speed USB 
device number 3 using ehci-pci
Feb 29 18:41:59 tux kernel: [  120.721912] hid_start_in: urbin 880253a46b40
Feb 29 18:41:59 tux kernel: [  120.721919] usbhid 3-1.3:1.0: post reset 
hid_start_in -> 0
Feb 29 18:41:59 tux kernel: [  120.727400] hid_start_in: urbin 880253a46300
Feb 29 18:41:59 tux kernel: [  120.727404] usbhid 3-1.3:1.1: post reset 
hid_start_in -> 0
Feb 29 18:41:59 tux kernel: [  120.788774] usb 3-1.8: reset high-speed USB 
device number 8 using ehci-pci
Feb 29 18:41:59 tux kernel: [  120.798981] usb 1-2.1: reset high-speed USB 
device number 4 using xhci_hcd
Feb 29 18:41:59 tux kernel: [  120.948776] usb 3-1.4: reset full-speed USB 
device number 4 using ehci-pci
Feb 29 18:41:59 tux kernel: [  121.044883] hid_start_in: urbin 880096618d80
Feb 29 18:41:59 tux kernel: [  121.044894] usbhid 3-1.4:1.0: post reset 
hid_start_in -> 0
Feb 29 18:41:59 tux kernel: [  121.106740] usb 3-1.5: reset full-speed USB 
device number 5 using ehci-pci
Feb 29 18:42:00 tux kernel: [  121.158940] usb 1-2.1.1: reset high-speed USB 
device number 5 using xhci_hcd
Feb 29 18:42:00 tux kernel: [  121.264744] usb 3-1.7: reset high-speed USB 
device number 7 using ehci-pci
Feb 29 18:42:00 tux kernel: [  121.327937] usb 1-2.1.3: reset high-speed USB 
device number 6 using xhci_hcd
Feb 29 18:42:00 tux kernel: [  121.422724] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 29 18:42:00 tux kernel: [  121.513214] hid_start_in: urbin   (null)
Feb 29 18:42:00 tux kernel: [  121.513219] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 29 18:42:00 tux kernel: [  121.561517] PM: resume of devices complete after 
1518.176 msecs
Feb 29 18:42:00 tux kernel: [  121.561672] Restarting tasks ... 
Feb 29 18:42:00 tux kernel: [  121.561742] usb 1-1: USB disconnect, device 
number 2
Feb 29 18:42:00 tux kernel: [  121.562267] done.
Feb 29 18:42:00 tux kernel: [  121.818689] usb 1-1: new low-speed USB device 
number 7 using xhci_hcd
Feb 29 18:42:00 tux kernel: [  121.992765] usb 1-1: ep 0x81 - rounding interval 
to 512 microframes, ep desc says 800 microframes
Feb 29 18:42:00 tux kernel: [  122.054094] usbhid 1-1:1.0: usbhid_start urb 
8802551dca80
Feb 29 18:42:00 tux kernel: [  122.398636] ata1: SATA link up 6.0 Gbps (SStatus 
133 SControl 300)
Feb 29 18:42:00 tux kernel: [  122.45] ata1.00: configured for UDMA/133
Feb 29 18:42:00 tux kernel: [  122.539666] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Feb 29 18:42:00 tux kernel: [  122.612665] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 29 18:42:00 tux kernel: [  122.703411] hid_start_in: urbin   (null)
Feb 29 18:42:00 tux kernel: [  122.703429] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 29 18:42:00 tux kernel: [  122.703437] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Feb 29 18:42:01 tux kernel: [  122.766681] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 29 18:42:01 tux kernel: [  122.857149] hid_start_in: urbin   (null)
Feb 29 18:42:01 tux kernel: [  122.857166] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 29 18:42:01 tux kernel: [  122.857174] usbhid 3-1.6:1.0: hid_cease_io urb   
(null)
Feb 29 18:42:01 tux kernel: [  122.919664] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 29 18:42:01 tux kernel: [  123.010097] hid_start_in: urbin   (null)

and it keeps repeating the last 3 lines forever...

-- 
Linux 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Wed, 24 Feb 2016, Daniel Fraga wrote:

> On Wed, 24 Feb 2016 14:24:44 -0500 (EST)
> Alan Stern  wrote:
> 
> > I intended the patch not to cause any call traces, but it did anyway.  
> > So let's drop the questionable code and try something that will be
> > completely safe.
> 
>   Ok, here's what I got:
> 
> Feb 24 19:16:41 tux kernel: [  717.316048] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb 24 19:16:41 tux kernel: [  717.406163] hid_start_in: urbin   
> (null)

Okay, that's what I had guessed.  Somehow usbhid->urbin is getting set 
to NULL.  Maybe the patch below will indicate why.  When you post the 
log, include everything that mentions the 3-1.6 device -- even if they 
precede the suspend test.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -75,7 +75,7 @@ static int hid_submit_ctrl(struct hid_de
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid);
 
 /* Start up the input URB */
-static int hid_start_in(struct hid_device *hid)
+static int hid_start_in(struct hid_device *hid, int alantest)
 {
unsigned long flags;
int rc = 0;
@@ -86,6 +86,9 @@ static int hid_start_in(struct hid_devic
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
+   if (alantest) {
+   pr_info("hid_start_in: urbin %p\n", usbhid->urbin);
+   }
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
clear_bit(HID_IN_RUNNING, >iofl);
@@ -106,7 +109,7 @@ static void hid_retry_timeout(unsigned l
struct usbhid_device *usbhid = hid->driver_data;
 
dev_dbg(>intf->dev, "retrying intr urb\n");
-   if (hid_start_in(hid))
+   if (hid_start_in(hid, 0))
hid_io_error(hid);
 }
 
@@ -123,7 +126,7 @@ static void hid_reset(struct work_struct
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
if (rc == 0) {
-   hid_start_in(hid);
+   hid_start_in(hid, 0);
} else {
dev_dbg(>intf->dev,
"clear-halt failed: %d\n", rc);
@@ -690,7 +693,7 @@ int usbhid_open(struct hid_device *hid)
}
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, >iofl);
-   res = hid_start_in(hid);
+   res = hid_start_in(hid, 0);
if (res) {
if (res != -ENOSPC) {
hid_io_error(hid);
@@ -1100,6 +1103,7 @@ static int usbhid_start(struct hid_devic
continue;
if (!(usbhid->urbin = usb_alloc_urb(0, GFP_KERNEL)))
goto fail;
+   dev_info(>dev, "usbhid_start urb %p\n", 
usbhid->urbin);
pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
usb_fill_int_urb(usbhid->urbin, dev, pipe, 
usbhid->inbuf, insize,
 hid_irq_in, hid, interval);
@@ -1139,7 +1143,7 @@ static int usbhid_start(struct hid_devic
if (ret)
goto fail;
usbhid->intf->needs_remote_wakeup = 1;
-   ret = hid_start_in(hid);
+   ret = hid_start_in(hid, 0);
if (ret) {
dev_err(>dev,
"failed to start in urb: %d\n", ret);
@@ -1162,6 +1166,7 @@ static int usbhid_start(struct hid_devic
return 0;
 
 fail:
+   dev_info(>dev, "usbhid_start fail urb %p\n", usbhid->urbin);
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbout);
usb_free_urb(usbhid->urbctrl);
@@ -1194,6 +1199,7 @@ static void usbhid_stop(struct hid_devic
 
hid->claimed = 0;
 
+   dev_info(>intf->dev, "usbhid_stop urb %p\n", usbhid->urbin);
usb_free_urb(usbhid->urbin);
usb_free_urb(usbhid->urbctrl);
usb_free_urb(usbhid->urbout);
@@ -1399,6 +1405,7 @@ static void hid_cancel_delayed_stuff(str
 static void hid_cease_io(struct usbhid_device *usbhid)
 {
del_timer_sync(>io_retry);
+   dev_info(>intf->dev, "hid_cease_io urb %p\n", usbhid->urbin);
usb_kill_urb(usbhid->urbin);
usb_kill_urb(usbhid->urbctrl);
usb_kill_urb(usbhid->urbout);
@@ -1457,7 +1464,8 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Wed, 24 Feb 2016 14:24:44 -0500 (EST)
Alan Stern  wrote:

> I intended the patch not to cause any call traces, but it did anyway.  
> So let's drop the questionable code and try something that will be
> completely safe.

Ok, here's what I got:

Feb 24 19:16:41 tux kernel: [  717.316048] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 24 19:16:41 tux kernel: [  717.406163] hid_start_in: urbin   (null)
Feb 24 19:16:41 tux kernel: [  717.406171] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 24 19:16:41 tux kernel: [  717.468988] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 24 19:16:41 tux kernel: [  717.559668] hid_start_in: urbin   (null)
Feb 24 19:16:42 tux kernel: [  717.559672] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 24 19:16:42 tux kernel: [  718.647957] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 24 19:16:42 tux kernel: [  718.738631] hid_start_in: urbin   (null)
Feb 24 19:16:42 tux kernel: [  718.738639] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 24 19:16:42 tux kernel: [  718.800906] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 24 19:16:42 tux kernel: [  718.891666] hid_start_in: urbin   (null)
Feb 24 19:16:42 tux kernel: [  718.891683] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22

(...)

-- 
Linux 4.4.2-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 23 Feb 2016, Daniel Fraga wrote:

> On Tue, 23 Feb 2016 11:48:51 -0500 (EST)
> Alan Stern  wrote:
> 
> > I don't see any crash in that photo.
> 
>   Sorry. By "crash" I mean "unable to use the keyboard". Maybe I
> used the wrong term.
> 
> > Also, it looks like the log results in this run were different from 
> > what you posted before.  Earlier you had "usbhid 3-1.6:1.0: post reset
> > hid_start_in -> -22" but the photo shows "usbhid 3-1.3:1.1: post reset
> > hid_start_in -> 0" (I think -- the photo is hard to read).
> > 
> > So either the mouse is plugged into a different port and is behaving 
> > differently, or else the photo shows the results for a different 
> > device, which isn't very useful.
> 
>   Maybe is the mobile phone I left plugged for transferring
> photos. I'll remove it completely when doing the tests.
> 
> > Let's forget about trying to trace into the USB core and instead trace
> > just the usbhid driver.
> 
>   Ok, another Call Trace. These are the best pictures I took (just
> the second is not so good) and this is the maximum I can go back in
> the scroll buffer. I hope it's clear enough. You can click on the
> thumbnail to expand the picture.

I intended the patch not to cause any call traces, but it did anyway.  
So let's drop the questionable code and try something that will be
completely safe.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -75,7 +75,7 @@ static int hid_submit_ctrl(struct hid_de
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid);
 
 /* Start up the input URB */
-static int hid_start_in(struct hid_device *hid)
+static int hid_start_in(struct hid_device *hid, int alantest)
 {
unsigned long flags;
int rc = 0;
@@ -86,6 +86,9 @@ static int hid_start_in(struct hid_devic
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
+   if (alantest) {
+   pr_info("hid_start_in: urbin %p\n", usbhid->urbin);
+   }
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
clear_bit(HID_IN_RUNNING, >iofl);
@@ -106,7 +109,7 @@ static void hid_retry_timeout(unsigned l
struct usbhid_device *usbhid = hid->driver_data;
 
dev_dbg(>intf->dev, "retrying intr urb\n");
-   if (hid_start_in(hid))
+   if (hid_start_in(hid, 0))
hid_io_error(hid);
 }
 
@@ -123,7 +126,7 @@ static void hid_reset(struct work_struct
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
if (rc == 0) {
-   hid_start_in(hid);
+   hid_start_in(hid, 0);
} else {
dev_dbg(>intf->dev,
"clear-halt failed: %d\n", rc);
@@ -690,7 +693,7 @@ int usbhid_open(struct hid_device *hid)
}
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, >iofl);
-   res = hid_start_in(hid);
+   res = hid_start_in(hid, 0);
if (res) {
if (res != -ENOSPC) {
hid_io_error(hid);
@@ -1139,7 +1142,7 @@ static int usbhid_start(struct hid_devic
if (ret)
goto fail;
usbhid->intf->needs_remote_wakeup = 1;
-   ret = hid_start_in(hid);
+   ret = hid_start_in(hid, 0);
if (ret) {
dev_err(>dev,
"failed to start in urb: %d\n", ret);
@@ -1457,7 +1460,8 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
+   status = hid_start_in(hid, 1);
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
@@ -1498,7 +1502,7 @@ static int hid_resume_common(struct hid_
usbhid_restart_queues(usbhid);
spin_unlock_irq(>lock);
 
-   status = hid_start_in(hid);
+   status = hid_start_in(hid, 0);
if (status < 0)
hid_io_error(hid);
 

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 23 Feb 2016 11:48:51 -0500 (EST)
Alan Stern  wrote:

> I don't see any crash in that photo.

Sorry. By "crash" I mean "unable to use the keyboard". Maybe I
used the wrong term.

> Also, it looks like the log results in this run were different from 
> what you posted before.  Earlier you had "usbhid 3-1.6:1.0: post reset
> hid_start_in -> -22" but the photo shows "usbhid 3-1.3:1.1: post reset
> hid_start_in -> 0" (I think -- the photo is hard to read).
> 
> So either the mouse is plugged into a different port and is behaving 
> differently, or else the photo shows the results for a different 
> device, which isn't very useful.

Maybe is the mobile phone I left plugged for transferring
photos. I'll remove it completely when doing the tests.

> Let's forget about trying to trace into the USB core and instead trace
> just the usbhid driver.

Ok, another Call Trace. These are the best pictures I took (just
the second is not so good) and this is the maximum I can go back in
the scroll buffer. I hope it's clear enough. You can click on the
thumbnail to expand the picture.

1) http://imgur.com/4c5rkex

2) http://imgur.com/vu6xet2

3) http://imgur.com/84aX3IE

4) http://imgur.com/i0p6Uaf

5) http://imgur.com/CnVbGmn

-- 
Linux 4.4.2-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 23 Feb 2016, Daniel Fraga wrote:

> On Tue, 23 Feb 2016 10:19:30 -0500 (EST)
> Alan Stern  wrote:
> 
> > All right; let's try a slightly different approach that shouldn't cause 
> > any crashes at all.
> 
>   Unfortunately it still crashed with this new patch. I took a
> picture:
> 
> http://imgur.com/OJCB129

I don't see any crash in that photo.

Also, it looks like the log results in this run were different from 
what you posted before.  Earlier you had "usbhid 3-1.6:1.0: post reset
hid_start_in -> -22" but the photo shows "usbhid 3-1.3:1.1: post reset
hid_start_in -> 0" (I think -- the photo is hard to read).

So either the mouse is plugged into a different port and is behaving 
differently, or else the photo shows the results for a different 
device, which isn't very useful.

Let's forget about trying to trace into the USB core and instead trace
just the usbhid driver.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -75,7 +75,7 @@ static int hid_submit_ctrl(struct hid_de
 static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid);
 
 /* Start up the input URB */
-static int hid_start_in(struct hid_device *hid)
+static int hid_start_in(struct hid_device *hid, int alantest)
 {
unsigned long flags;
int rc = 0;
@@ -86,6 +86,11 @@ static int hid_start_in(struct hid_devic
!test_bit(HID_DISCONNECTED, >iofl) &&
!test_bit(HID_SUSPENDED, >iofl) &&
!test_and_set_bit(HID_IN_RUNNING, >iofl)) {
+   if (alantest) {
+   pr_info("hid_start_in: urbin %p\n", usbhid->urbin);
+   mdelay(5000);
+   pr_info("hid_start_in: dev %p\n", usbhid->urbin->dev);
+   }
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
clear_bit(HID_IN_RUNNING, >iofl);
@@ -106,7 +111,7 @@ static void hid_retry_timeout(unsigned l
struct usbhid_device *usbhid = hid->driver_data;
 
dev_dbg(>intf->dev, "retrying intr urb\n");
-   if (hid_start_in(hid))
+   if (hid_start_in(hid, 0))
hid_io_error(hid);
 }
 
@@ -123,7 +128,7 @@ static void hid_reset(struct work_struct
rc = usb_clear_halt(hid_to_usb_dev(hid), usbhid->urbin->pipe);
clear_bit(HID_CLEAR_HALT, >iofl);
if (rc == 0) {
-   hid_start_in(hid);
+   hid_start_in(hid, 0);
} else {
dev_dbg(>intf->dev,
"clear-halt failed: %d\n", rc);
@@ -690,7 +695,7 @@ int usbhid_open(struct hid_device *hid)
}
usbhid->intf->needs_remote_wakeup = 1;
set_bit(HID_RESUME_RUNNING, >iofl);
-   res = hid_start_in(hid);
+   res = hid_start_in(hid, 0);
if (res) {
if (res != -ENOSPC) {
hid_io_error(hid);
@@ -1139,7 +1144,7 @@ static int usbhid_start(struct hid_devic
if (ret)
goto fail;
usbhid->intf->needs_remote_wakeup = 1;
-   ret = hid_start_in(hid);
+   ret = hid_start_in(hid, 0);
if (ret) {
dev_err(>dev,
"failed to start in urb: %d\n", ret);
@@ -1457,7 +1462,8 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
-   status = hid_start_in(hid);
+   status = hid_start_in(hid, 1);
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
@@ -1498,7 +1504,7 @@ static int hid_resume_common(struct hid_
usbhid_restart_queues(usbhid);
spin_unlock_irq(>lock);
 
-   status = hid_start_in(hid);
+   status = hid_start_in(hid, 0);
if (status < 0)
hid_io_error(hid);
 


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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Tue, 23 Feb 2016 10:19:30 -0500 (EST)
Alan Stern  wrote:

> All right; let's try a slightly different approach that shouldn't cause 
> any crashes at all.

Unfortunately it still crashed with this new patch. I took a
picture:

http://imgur.com/OJCB129

-- 
Linux 4.4.2-dirty: Blurry Fish Butt
http://exchangewar.info
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 22 Feb 2016, Daniel Fraga wrote:

> On Mon, 22 Feb 2016 16:22:59 -0500 (EST)
> Alan Stern  wrote:
> 
> > Unfortunately I really need to see the stuff that shows up before the 
> > first couple of pictures.  Is there any way you can use a serial 
> > console or network console to capture the log data?
> 
>   Unfortunately no :(
> 
> > Failing that, the patch below does the same thing as the previous patch 
> > but it adds a 5-second delay after each line is sent to the log.  Maybe 
> > you'll be able to photograph something useful during those delays.
> 
>   Ok, the following picture shows more lines at the beginning,
> but it missed some lines (I tried to shoot as fast as I could):
> 
> http://imgur.com/Pri9dso
> 
>   And this one shows lines from your patch:
> 
> http://imgur.com/fv3X2hE
> 
>   Unfortunately I couldn't use "shift+PgUp" because it would
> return those lines instead of going back at the screen buffer.
> 
>   And the behaviour is not constant. I mean, sometimes it shows
> these errors. Sometimes, it returns with a blank screen.

All right; let's try a slightly different approach that shouldn't cause 
any crashes at all.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+   extern int alantest;
 
/* Fetch and examine the HID report descriptor. If this
 * has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+   alantest = 1;
status = hid_start_in(hid);
+   alantest = 0;
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
 
 /*---*/
 
+int alantest;
+EXPORT_SYMBOL(alantest);
+
 /**
  * usb_submit_urb - issue an asynchronous transfer request for an endpoint
  * @urb: pointer to the urb describing the request
@@ -332,8 +335,14 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
 
+   if (alantest) {
+   pr_info("alantest: urb %p\n", urb);
+   pr_info("alantest: udev %p\n", urb->dev);
+   }
+   if (alantest)  pr_info("submit A\n");
if (!urb || !urb->complete)
return -EINVAL;
+   if (alantest)  pr_info("submit B\n");
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +404,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 * but drivers only control those sizes for ISO.
 * while we're checking, initialize return status.
 */
+   if (alantest)  pr_info("submit C\n");
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
 
@@ -433,6 +443,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+   if (alantest)  pr_info("submit D\n");
 
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +498,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+   if (alantest)  pr_info("submit E\n");
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +509,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+   if (alantest)  pr_info("submit F\n");
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER:   /* units are 125us */
@@ -532,6 +545,7 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
+   if (alantest)  pr_info("submit G\n");
if (dev->speed != USB_SPEED_WIRELESS) {
/* Round down to a power of 2, no more than max */
  

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Mon, 22 Feb 2016 16:22:59 -0500 (EST)
Alan Stern  wrote:

> Unfortunately I really need to see the stuff that shows up before the 
> first couple of pictures.  Is there any way you can use a serial 
> console or network console to capture the log data?

Unfortunately no :(

> Failing that, the patch below does the same thing as the previous patch 
> but it adds a 5-second delay after each line is sent to the log.  Maybe 
> you'll be able to photograph something useful during those delays.

Ok, the following picture shows more lines at the beginning,
but it missed some lines (I tried to shoot as fast as I could):

http://imgur.com/Pri9dso

And this one shows lines from your patch:

http://imgur.com/fv3X2hE

Unfortunately I couldn't use "shift+PgUp" because it would
return those lines instead of going back at the screen buffer.

And the behaviour is not constant. I mean, sometimes it shows
these errors. Sometimes, it returns with a blank screen.

-- 
Linux 4.4.2-dirty: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Mon, 22 Feb 2016, Daniel Fraga wrote:

> On Mon, 22 Feb 2016 14:30:32 -0500 (EST)
> Alan Stern  wrote:
> 
> > Well, I'm still puzzled.  I tried running that patch on my system
> > (under 4.5-rc2) and it worked perfectly.
> > 
> > So let's try for a little more detail.  Please apply this patch instead
> > of the earlier one.  Also, add no_console_suspend to the boot command
> > line, do
> > 
> > echo 7 >/proc/sys/kernel/printk
> > 
> > and start the suspend from a VT console rather than a GUI.
> 
>   Ok Alan, here's what I got (I took 6 pictures of the screen
> because there's no way to use the keyboard):
> 
> 1) http://imgur.com/7bpA2i4
> 
> 2) http://imgur.com/2kmLaJb
> 
> 3) http://imgur.com/6wYPZZK
> 
> 4) http://imgur.com/S42nV4Q
> 
> 5) http://imgur.com/VHNl6My
> 
> 6) http://imgur.com/dYCdqWn

Unfortunately I really need to see the stuff that shows up before the 
first couple of pictures.  Is there any way you can use a serial 
console or network console to capture the log data?

Failing that, the patch below does the same thing as the previous patch 
but it adds a 5-second delay after each line is sent to the log.  Maybe 
you'll be able to photograph something useful during those delays.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+   extern int alantest;
 
/* Fetch and examine the HID report descriptor. If this
 * has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+   alantest = 1;
status = hid_start_in(hid);
+   alantest = 0;
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
 
 /*---*/
 
+int alantest;
+EXPORT_SYMBOL(alantest);
+
 /**
  * usb_submit_urb - issue an asynchronous transfer request for an endpoint
  * @urb: pointer to the urb describing the request
@@ -332,8 +335,16 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
 
+   if (alantest) {
+   pr_info("alantest: urb %p\n", urb);
+   mdelay(5000);
+   pr_info("alantest: udev %p\n", urb->dev);
+   mdelay(5000);
+   }
+   if (alantest) { dev_info(>dev->dev, "submit A\n"); mdelay(5000); }
if (!urb || !urb->complete)
return -EINVAL;
+   if (alantest) { dev_info(>dev->dev, "submit B\n"); mdelay(5000); }
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +406,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 * but drivers only control those sizes for ISO.
 * while we're checking, initialize return status.
 */
+   if (alantest) { dev_info(>dev->dev, "submit C\n"); mdelay(5000); }
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
 
@@ -433,6 +445,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+   if (alantest) { dev_info(>dev->dev, "submit D\n"); mdelay(5000); }
 
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +500,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+   if (alantest) { dev_info(>dev->dev, "submit E\n"); mdelay(5000); }
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +511,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+   if (alantest) { dev_info(>dev->dev, "submit F\n"); mdelay(5000); }
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER:   /* units are 125us */
@@ -532,6 +547,7 @@ int usb_submit_urb(struct urb *urb, gfp_

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Mon, 22 Feb 2016 14:30:32 -0500 (EST)
Alan Stern  wrote:

> Well, I'm still puzzled.  I tried running that patch on my system
> (under 4.5-rc2) and it worked perfectly.
> 
> So let's try for a little more detail.  Please apply this patch instead
> of the earlier one.  Also, add no_console_suspend to the boot command
> line, do
> 
>   echo 7 >/proc/sys/kernel/printk
> 
> and start the suspend from a VT console rather than a GUI.

Ok Alan, here's what I got (I took 6 pictures of the screen
because there's no way to use the keyboard):

1) http://imgur.com/7bpA2i4

2) http://imgur.com/2kmLaJb

3) http://imgur.com/6wYPZZK

4) http://imgur.com/S42nV4Q

5) http://imgur.com/VHNl6My

6) http://imgur.com/dYCdqWn

Thank you.

-- 
Linux 4.4.2-dirty: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Fri, 19 Feb 2016, Alan Stern wrote:

> On Fri, 19 Feb 2016, Daniel Fraga wrote:
> 
> > On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
> > Alan Stern  wrote:
> > 
> > > -22 is -EINVAL, so we need to figure out which of the many possible
> > > EINVAL errors you're getting.  Try the patch below.
> > 
> > I applied your patch, but when it wakes up from S3, the system
> > is stalled: nothing works. No keyboard, no mouse... 
> > 
> > And nothing in the log.
> 
> Probably something about the patch causes a runtime error and that 
> causes the resume to fail.  I'll try some testing on my machine and get 
> back to you next week...

Well, I'm still puzzled.  I tried running that patch on my system
(under 4.5-rc2) and it worked perfectly.

So let's try for a little more detail.  Please apply this patch instead
of the earlier one.  Also, add no_console_suspend to the boot command
line, do

echo 7 >/proc/sys/kernel/printk

and start the suspend from a VT console rather than a GUI.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+   extern int alantest;
 
/* Fetch and examine the HID report descriptor. If this
 * has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+   alantest = 1;
status = hid_start_in(hid);
+   alantest = 0;
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
 
 /*---*/
 
+int alantest;
+EXPORT_SYMBOL(alantest);
+
 /**
  * usb_submit_urb - issue an asynchronous transfer request for an endpoint
  * @urb: pointer to the urb describing the request
@@ -332,8 +335,14 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
 
+   if (alantest) {
+   pr_info("alantest: urb %p\n", urb);
+   pr_info("alantest: udev %p\n", urb->dev);
+   }
+   if (alantest)  dev_info(>dev->dev, "submit A\n");
if (!urb || !urb->complete)
return -EINVAL;
+   if (alantest)  dev_info(>dev->dev, "submit B\n");
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +404,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 * but drivers only control those sizes for ISO.
 * while we're checking, initialize return status.
 */
+   if (alantest)  dev_info(>dev->dev, "submit C\n");
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
 
@@ -433,6 +443,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit D\n");
 
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +498,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+   if (alantest)  dev_info(>dev->dev, "submit E\n");
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +509,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+   if (alantest)  dev_info(>dev->dev, "submit F\n");
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER:   /* units are 125us */
@@ -532,6 +545,7 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit G\n");
if (dev->speed != USB_SPEED_WIRELESS) {
/* Round down to a power of 2, no more than max */
urb->interval = min(max, 1 << ilog2(urb->interval));

--
To unsubscribe from this list: 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Fri, 19 Feb 2016, Daniel Fraga wrote:

> On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
> Alan Stern  wrote:
> 
> > -22 is -EINVAL, so we need to figure out which of the many possible
> > EINVAL errors you're getting.  Try the patch below.
> 
>   I applied your patch, but when it wakes up from S3, the system
> is stalled: nothing works. No keyboard, no mouse... 
> 
>   And nothing in the log.

Probably something about the patch causes a runtime error and that 
causes the resume to fail.  I'll try some testing on my machine and get 
back to you next week...

Alan Stern

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Fri, 19 Feb 2016 14:13:25 -0500 (EST)
Alan Stern  wrote:

> -22 is -EINVAL, so we need to figure out which of the many possible
> EINVAL errors you're getting.  Try the patch below.

I applied your patch, but when it wakes up from S3, the system
is stalled: nothing works. No keyboard, no mouse... 

And nothing in the log.

-- 
Linux 4.4.1-dirty: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Thu, 18 Feb 2016, Daniel Fraga wrote:

> On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
> Alan Stern  wrote:
> 
> > Something like the patch below (untested).
> 
> > +   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
> 
>   Ok, so I got the following:
> 
> Feb 18 19:22:26 tux kernel: [  258.693120] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb 18 19:22:26 tux kernel: [  258.783654] usbhid 3-1.6:1.0: post reset 
> hid_start_in -> -22

>   If you need more tests, just ask.

-22 is -EINVAL, so we need to figure out which of the many possible
EINVAL errors you're getting.  Try the patch below.

Alan Stern



Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1427,6 +1427,7 @@ static int hid_post_reset(struct usb_int
struct usb_host_interface *interface = intf->cur_altsetting;
int status;
char *rdesc;
+   extern int alantest;
 
/* Fetch and examine the HID report descriptor. If this
 * has changed, then rebind. Since usbcore's check of the
@@ -1457,7 +1458,10 @@ static int hid_post_reset(struct usb_int
clear_bit(HID_RESET_PENDING, >iofl);
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
+   alantest = 1;
status = hid_start_in(hid);
+   alantest = 0;
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);
Index: usb-4.4/drivers/usb/core/urb.c
===
--- usb-4.4.orig/drivers/usb/core/urb.c
+++ usb-4.4/drivers/usb/core/urb.c
@@ -184,6 +184,9 @@ EXPORT_SYMBOL_GPL(usb_unanchor_urb);
 
 /*---*/
 
+int alantest;
+EXPORT_SYMBOL(alantest);
+
 /**
  * usb_submit_urb - issue an asynchronous transfer request for an endpoint
  * @urb: pointer to the urb describing the request
@@ -332,8 +335,10 @@ int usb_submit_urb(struct urb *urb, gfp_
int is_out;
unsigned intallowed;
 
+   if (alantest)  dev_info(>dev->dev, "submit A\n");
if (!urb || !urb->complete)
return -EINVAL;
+   if (alantest)  dev_info(>dev->dev, "submit B\n");
if (urb->hcpriv) {
WARN_ONCE(1, "URB %p submitted while active\n", urb);
return -EBUSY;
@@ -395,6 +400,7 @@ int usb_submit_urb(struct urb *urb, gfp_
 * but drivers only control those sizes for ISO.
 * while we're checking, initialize return status.
 */
+   if (alantest)  dev_info(>dev->dev, "submit C\n");
if (xfertype == USB_ENDPOINT_XFER_ISOC) {
int n, len;
 
@@ -433,6 +439,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (sg->length % max)
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit D\n");
 
/* the I/O buffer must be mapped/unmapped, except when length=0 */
if (urb->transfer_buffer_length > INT_MAX)
@@ -487,6 +494,7 @@ int usb_submit_urb(struct urb *urb, gfp_
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* too small? */
+   if (alantest)  dev_info(>dev->dev, "submit E\n");
switch (dev->speed) {
case USB_SPEED_WIRELESS:
if ((urb->interval < 6)
@@ -497,6 +505,7 @@ int usb_submit_urb(struct urb *urb, gfp_
return -EINVAL;
break;
}
+   if (alantest)  dev_info(>dev->dev, "submit F\n");
/* too big? */
switch (dev->speed) {
case USB_SPEED_SUPER:   /* units are 125us */
@@ -532,6 +541,7 @@ int usb_submit_urb(struct urb *urb, gfp_
default:
return -EINVAL;
}
+   if (alantest)  dev_info(>dev->dev, "submit G\n");
if (dev->speed != USB_SPEED_WIRELESS) {
/* Round down to a power of 2, no more than max */
urb->interval = min(max, 1 << ilog2(urb->interval));

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Thu, 18 Feb 2016 15:23:00 -0500 (EST)
Alan Stern  wrote:

> Something like the patch below (untested).

> + dev_info(>dev, "post reset hid_start_in -> %d\n", status);

Ok, so I got the following:

Feb 18 19:22:26 tux kernel: [  258.693120] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 18 19:22:26 tux kernel: [  258.783654] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 18 19:22:26 tux kernel: [  259.883071] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 18 19:22:27 tux kernel: [  259.973529] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 18 19:22:27 tux kernel: [  260.036047] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 18 19:22:27 tux kernel: [  260.126642] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 18 19:22:28 tux kernel: [  260.188998] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 18 19:22:28 tux kernel: [  260.279629] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22
Feb 18 19:22:28 tux kernel: [  260.342019] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb 18 19:22:28 tux kernel: [  260.432742] usbhid 3-1.6:1.0: post reset 
hid_start_in -> -22

(...)

And usbmon shows the following:

88024568da80 1732564945 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568da80 1732565020 C Ci:3:002:0 0 4 = 1101
88024568da80 1732575950 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568da80 1732576021 C Ci:3:002:0 0 4 = 03011000
88024568da80 1732576035 S Co:3:002:0 s 23 01 0014 0006  0
88024568da80 1732576154 C Co:3:002:0 0 0
88024568d540 1732626948 S Co:3:000:0 s 00 05 0006   0
88024568d540 1732627022 C Co:3:000:0 0 0
88024568d540 1732638972 S Ci:3:006:0 s 80 06 0100  0012 18 <
88024568d540 1732639272 C Ci:3:006:0 0 18 = 12010002 0008 f3043400 
1200040e 0001
88024568d540 1732639292 S Ci:3:006:0 s 80 06 0200  0029 41 <
88024568d540 1732639519 C Ci:3:006:0 0 41 = 09022900 010100e0 32090400 
00020300 0921 10010001 22b70307 05810340
88024568d540 1732639533 S Co:3:006:0 s 00 09 0001   0
88024568d540 1732639644 C Co:3:006:0 0 0
88024568d540 1732639671 S Ci:3:006:0 s 81 06 2200  03b7 951 <
88024568d540 1732644165 C Ci:3:006:0 0 951 = 050d0904 a1018501 0922a102 
09421500 25017501 95018102 75018103 75060951
88024568d540 1732644193 S Co:3:006:0 s 21 0a    0
88024568d540 1732644269 C Co:3:006:0 0 0
88024568da80 1732644989 S Co:3:002:0 s 23 03 0004 0006  0
88024568da80 1732645146 C Co:3:002:0 0 0
88024568d480 1732655954 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568d480 1732656023 C Ci:3:002:0 0 4 = 1101
88024568da80 1732666962 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568da80 1732667024 C Ci:3:002:0 0 4 = 03011000
88024568da80 1732667029 S Co:3:002:0 s 23 01 0014 0006  0
88024568da80 1732667144 C Co:3:002:0 0 0
88024568d780 1732717984 S Ci:3:000:0 s 80 06 0100  0040 64 <
88024568d780 1732718148 C Ci:3:000:0 0 8 = 12010002 0008
88024568d780 1732718168 S Co:3:002:0 s 23 03 0004 0006  0
88024568d780 1732718271 C Co:3:002:0 0 0
88024568d780 1732728982 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568d780 1732729059 C Ci:3:002:0 0 4 = 1101
88024568d780 1732739957 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568d780 1732740022 C Ci:3:002:0 0 4 = 03011000
88024568d780 1732740030 S Co:3:002:0 s 23 01 0014 0006  0
88024568d780 1732740146 C Co:3:002:0 0 0
88024568d780 1732790980 S Co:3:000:0 s 00 05 0006   0
88024568d780 1732791149 C Co:3:000:0 0 0
88024568d9c0 1732802963 S Ci:3:006:0 s 80 06 0100  0012 18 <
88024568d9c0 1732803282 C Ci:3:006:0 0 18 = 12010002 0008 f3043400 
1200040e 0001
88024568d9c0 1732803305 S Ci:3:006:0 s 80 06 0200  0029 41 <
88024568d9c0 1732803667 C Ci:3:006:0 0 41 = 09022900 010100e0 32090400 
00020300 0921 10010001 22b70307 05810340
88024568d9c0 1732803675 S Co:3:006:0 s 00 09 0001   0
88024568d9c0 1732803770 C Co:3:006:0 0 0
88024568d9c0 1732803797 S Ci:3:006:0 s 81 06 2200  03b7 951 <
88024568d9c0 1732808292 C Ci:3:006:0 0 951 = 050d0904 a1018501 0922a102 
09421500 25017501 95018102 75018103 75060951
88024568d9c0 1732808300 S Co:3:006:0 s 21 0a    0
88024568d9c0 1732808398 C Co:3:006:0 0 0
88024568d780 1732809002 S Co:3:002:0 s 23 03 0004 0006  0
88024568d780 1732809146 C Co:3:002:0 0 0
88024568d780 1732819951 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568d780 1732820023 C Ci:3:002:0 0 4 = 1101
88024568d9c0 1732830954 S Ci:3:002:0 s a3 00  0006 0004 4 <
88024568d9c0 1732831033 C Ci:3:002:0 0 4 = 03011000
88024568d9c0 1732831053 S Co:3:002:0 s 23 01 0014 0006  0
88024568d9c0 1732831147 C Co:3:002:0 0 0
88024568d0c0 1732881971 S Ci:3:000:0 s 80 06 

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Thu, 18 Feb 2016, Daniel Fraga wrote:

> On Thu, 18 Feb 2016 14:30:15 -0500 (EST)
> Alan Stern  wrote:
> 
> > It looks like there's some problem in the usbhid driver.  Apparently
> > hid_start_in() gets some sort of error when it submits the input URB, 
> > because that URB doesn't show up in the usbmon output.
> > 
> > Can you add a debugging line near the end of hid_post_reset() in
> > drivers/hid/usbhid/hid-core.c to find out what the return value from
> > hid_start_in() is?
> 
>   Yes, can you provide the patch (or the specific line you need)
> so I can recompile it?

Something like the patch below (untested).

Alan Stern


Index: usb-4.4/drivers/hid/usbhid/hid-core.c
===
--- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
+++ usb-4.4/drivers/hid/usbhid/hid-core.c
@@ -1458,6 +1458,7 @@ static int hid_post_reset(struct usb_int
spin_unlock_irq(>lock);
hid_set_idle(dev, intf->cur_altsetting->desc.bInterfaceNumber, 0, 0);
status = hid_start_in(hid);
+   dev_info(>dev, "post reset hid_start_in -> %d\n", status);
if (status < 0)
hid_io_error(hid);
usbhid_restart_queues(usbhid);

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Thu, 18 Feb 2016 14:30:15 -0500 (EST)
Alan Stern  wrote:

> It looks like there's some problem in the usbhid driver.  Apparently
> hid_start_in() gets some sort of error when it submits the input URB, 
> because that URB doesn't show up in the usbmon output.
> 
> Can you add a debugging line near the end of hid_post_reset() in
> drivers/hid/usbhid/hid-core.c to find out what the return value from
> hid_start_in() is?

Yes, can you provide the patch (or the specific line you need)
so I can recompile it?

Thanks.

-- 
Linux 4.4.1: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL
--
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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Thu, 18 Feb 2016, Daniel Fraga wrote:

> On Thu, 18 Feb 2016 11:18:37 -0500 (EST)
> Alan Stern  wrote:
> 
> > No idea.  Can you collect a usbmon trace for bus 3, starting before the 
> > suspend and showing the problems?
> 
>   Ok Alan, I attached the requested usbmon output for bus 3 (before and 
> after S3).

It looks like there's some problem in the usbhid driver.  Apparently
hid_start_in() gets some sort of error when it submits the input URB, 
because that URB doesn't show up in the usbmon output.

Can you add a debugging line near the end of hid_post_reset() in
drivers/hid/usbhid/hid-core.c to find out what the return value from
hid_start_in() is?

Alan Stern

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

Re: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Alan Stern]

On Tue, 9 Feb 2016, Dâniel Fraga wrote:

>   I'm using Linux 4.4.1 kernel on a Dell Inspiron 15R 5537 and
> everytime I wake up from S3 sleep, the syslog is full of the following
> message:
> 
> Feb  9 17:19:05 tux kernel: [19196.253206] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:05 tux kernel: [19196.406206] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:05 tux kernel: [19196.559239] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:06 tux kernel: [19197.738267] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:06 tux kernel: [19197.891218] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:07 tux kernel: [19198.044243] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:07 tux kernel: [19198.198231] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:08 tux kernel: [19199.388295] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:08 tux kernel: [19199.541307] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:08 tux kernel: [19199.694319] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:08 tux kernel: [19199.847338] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> Feb  9 17:19:09 tux kernel: [19201.026362] usb 3-1.6: reset full-speed USB 
> device number 6 using ehci-pci
> 
>   And it doesn't stop. The only way to stop it is to reload the ehci-pci 
> kernel module:
> 
> sudo modprobe -r ehci-pci; sudo modprobe ehci-pci
> 
>   lsusb returns:
> 
> Bus 003 Device 008: ID 064e:812e Suyin Corp. 
> Bus 003 Device 007: ID 0bda:0129 Realtek Semiconductor Corp. 
> Bus 003 Device 006: ID 04f3:0034 Elan Microelectronics Corp. 
> Bus 003 Device 005: ID 0cf3:0036 Atheros Communications, Inc. 
> Bus 003 Device 004: ID 1532:0016 Razer USA, Ltd 
> Bus 003 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard
> Bus 003 Device 002: ID 8087:8000  
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 006: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
> Bus 001 Device 005: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card 
> Reader
> Bus 001 Device 004: ID 0424:2602 Standard Microsystems Corp. 
> Bus 001 Device 003: ID 0424:2512 Standard Microsystems Corp. 
> Bus 001 Device 007: ID 051d:0002 American Power Conversion Uninterruptible 
> Power Supply
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
>   So, any hints on what's going on?

No idea.  Can you collect a usbmon trace for bus 3, starting before the 
suspend and showing the problems?

Alan Stern

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

"reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Dâniel Fraga]

I'm using Linux 4.4.1 kernel on a Dell Inspiron 15R 5537 and
everytime I wake up from S3 sleep, the syslog is full of the following
message:

Feb  9 17:19:05 tux kernel: [19196.253206] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:05 tux kernel: [19196.406206] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:05 tux kernel: [19196.559239] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:06 tux kernel: [19197.738267] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:06 tux kernel: [19197.891218] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:07 tux kernel: [19198.044243] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:07 tux kernel: [19198.198231] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:08 tux kernel: [19199.388295] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:08 tux kernel: [19199.541307] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:08 tux kernel: [19199.694319] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:08 tux kernel: [19199.847338] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci
Feb  9 17:19:09 tux kernel: [19201.026362] usb 3-1.6: reset full-speed USB 
device number 6 using ehci-pci

And it doesn't stop. The only way to stop it is to reload the ehci-pci 
kernel module:

sudo modprobe -r ehci-pci; sudo modprobe ehci-pci

lsusb returns:

Bus 003 Device 008: ID 064e:812e Suyin Corp. 
Bus 003 Device 007: ID 0bda:0129 Realtek Semiconductor Corp. 
Bus 003 Device 006: ID 04f3:0034 Elan Microelectronics Corp. 
Bus 003 Device 005: ID 0cf3:0036 Atheros Communications, Inc. 
Bus 003 Device 004: ID 1532:0016 Razer USA, Ltd 
Bus 003 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard
Bus 003 Device 002: ID 8087:8000  
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
Bus 001 Device 005: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 001 Device 004: ID 0424:2602 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2512 Standard Microsystems Corp. 
Bus 001 Device 007: ID 051d:0002 American Power Conversion Uninterruptible 
Power Supply
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So, any hints on what's going on?

Thanks.

-- 
Linux 4.4.1: Blurry Fish Butt
http://www.youtube.com/DanielFragaBR
http://exchangewar.info
Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL


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