Re: Mouse works with eHCI, fails with xHCI - can't set config #1, error -110

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

 



On 10.04.2015 20:23, Alan Stern wrote:
> On Fri, 10 Apr 2015, Alistair Grant wrote:
> 
>>> Can you post the usbmon log for an EHCI controller?  Comparing the two
>>> logs may be helpful.
> 
> Here's the relevant part of the xHCI trace:
> 
>> ffff88017912d600 1598886123 S Ci:1:014:0 s 80 06 0302 0409 0002 2 <
>> ffff88017912d600 1598886469 C Ci:1:014:0 0 2 = 1803
> 
> When asked for the length of the Product string descriptor, the mouse
> says it is 24 bytes.
> 
>> ffff88017912d600 1598886486 S Ci:1:014:0 s 80 06 0302 0409 0018 24 <
>> ffff88017912d600 1598887112 C Ci:1:014:0 -32 0
> 
> When asked for the first 24 bytes of the string descriptor, there is no
> data and the endpoint is halted.
> 
>> ffff88017912d600 1598887121 S Ci:1:014:0 s 80 06 0302 0409 0018 24 <
>> ffff88017912d600 1603885049 C Ci:1:014:0 -2 0
> 
> When asked again, there is no reply at all and the transfer times out 
> after 5 seconds.  At this point it appears that the mouse's firmware 
> has crashed.
> 
> Here's the corresponding part of the EHCI trace:
> 
>> ffff88014a1bfd80 3642762459 S Ci:3:007:0 s 80 06 0302 0409 0002 2 <
>> ffff88014a1bfd80 3642763176 C Ci:3:007:0 0 2 = 1803
> 
> When asked for the length of the Product string descriptor, the mouse
> says it is 24 bytes.
> 
>> ffff88014a1bfd80 3642763195 S Ci:3:007:0 s 80 06 0302 0409 0018 24 <
>> ffff88014a1bfd80 3642763916 C Ci:3:007:0 -32 15 = 18034c00 61007300
>> 65007200 200030
> 
> When asked for the first 24 bytes of the string descriptor, the mouse
> sends only 15 bytes of data and then halts the endpoint.  That is most
> definitely a bug in the mouse.  The received data says "Laser 0", for
> whatever that's worth.
> 
>> ffff88014a1bfd80 3642763934 S Ci:3:007:0 s 80 06 0302 0409 0018 24 <
>> ffff88014a1bfd80 3642764917 C Ci:3:007:0 -32 15 = 18034c00 61007300
>> 65007200 200030
> 
> When asked again, the mouse gives the same response.  At least the 
> firmware didn't crash.
> 
> Comparing these two results suggests that the mouse did send 15 bytes
> of data to the xHCI controller, but for some reason the xhci-hcd driver
> did not report it.  Perhaps the controller then failed to complete the
> transfer somehow.  That may have confused the mouse's firmware and
> caused it to hang.
> 

The xhci_driver will bluntly set the length to 0 if we get a STALL on
anything else than the data stage of a control transfer. 

Does a change like this have any impact? (Should show the 15 bytes in the returned URB)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 73485fa..ac283a6 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1934,7 +1934,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct xhci_td *td,
                        td->urb->actual_length =
                                td->urb->transfer_buffer_length -
                                EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
-               else
+               else if (!td->urb_length_set)
                        td->urb->actual_length = 0;
 
                return finish_td(xhci, td, event_trb, event, ep, status, false);

Another difference between EHCI and xHCI iss that xHCI needs to reset (the host side)
of a control endpoint if it stalled.  

>From xHCI 1.0 4.8.3:

"A STALL detected on any stage (Setup, Data, or Status) of a Default Control Endpoint request
shall transition the Endpoint Context to the Halted state. A Default Control Endpoint STALL
condition is cleared by a Reset Endpoint Command which transitions the endpoint from the Halted
to the Stopped state. The Default Control Endpoint shall return to the Running state when the
Doorbell is rung for the next Setup Stage TD sent to the endpoint.
ection 8.5.3.4 of the USB2 spec and section 8.12.2.3 of the USB3 spec state of Control pipes,
“Unlike the case of a functional stall, protocol stall does not indicate an error with the device.” The
xHC treats a functional stall and protocol stall identically, by Halting the endpoint and requiring
software to clear the condition by issuing a Reset Endpoint Command."

-Mathias









--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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

  Powered by Linux