Hi
On 18.12.2014 13:49, Gustavo Duarte wrote:
> Mathias /Guys,
>
> I got the debug log of the xhci_hcd module, during the communication
> with the robot kit (Lego brick).
>
> Attached are two files:
>
> brick-boot.log:
> The brick is connected to USB port, and press switch ON button.
>
> upload.log:
> The brick is already ON, and start the uploading of an application
> code from PC -> Brick, the uploading procedure never finished.
>
> I don't know so much about usb communications, but seeing these file
> logs, I didn't see any estrange message.
>
> What do you think, can you see some clue there ?
Looks like it first finds a mismatch in max packet size after device is
addressed, xhci tries to re-configure the endpoint to match the new
maxpacket size. It says it succeeds but immediately after that halts the
endpoint. After this we see most of the usb transfers cancelled.
Things to try:
- use old style enumeration, before pluging in your device do:
'echo y > /sys/module/usbcore/parameters/old_scheme_first'
- use 3.18 kernel, it has fixes for misbehaving halted control endpoints
- hack the xhci code and remove setting the new maxpacket size, and see if
it makes a difference.
Do a codechange like this, (copy-pasted diff), and rebuild:
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5be1bff..2778c37 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1370,7 +1370,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flags)
/* Check to see if the max packet size for the default control
* endpoint changed during FS device enumeration
*/
- if (urb->dev->speed == USB_SPEED_FULL) {
+ if (urb->dev->speed == USB_SPEED_FULL && 0) {
ret = xhci_check_maxpacket(xhci, slot_id,
ep_index, urb);
if (ret < 0) {
I'll be away until 5. Jan on vacation, trying not to read emails
-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
