Hi Sorry about not answering earlier, many new things piled up during my vacation and needed attention.
If I can find some spare time I'll try to take another look, but don't let any bigger project pend on this alone. In addition to digging into the code yourself, the best thing I can recommend is taking new logs with the latest 3.19-rc kernel with both xhci and usb core verbose debugging: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control also usbmon traces can be helpful, at least for others, I'm myself horribly slow at deciphering those -Mathias On 16.01.2015 16:57, Gustavo Duarte wrote: > Greg and all, > > Something more to try on this ? > > Greg do you have time to take look on this ? > > Thanks in advance. > > > Gustavo. > > On Wed, Jan 14, 2015 at 7:46 PM, Gustavo Duarte <gus.dua...@gmail.com> wrote: >> My response, sent on Jan 7. I don't understand why I can't found it on >> the mail list archives. May be because linux-usb@vger.kernel.org >> address is CC ? >> >> >> >> ---------- Forwarded message ---------- >> From: Gustavo Duarte <gus.dua...@gmail.com> >> Date: Tue, Jan 6, 2015 at 10:46 AM >> Subject: Re: USB 3.0 and xHCI Host-Controller >> To: Mathias Nyman <mathias.ny...@linux.intel.com> >> Cc: linux-usb@vger.kernel.org >> >> >> Mathias/all >> >> I tried your three suggestions: >> >> 1) use old style enumeration, before pluging in your device do: >> 'echo y > /sys/module/usbcore/parameters/old_scheme_first' >> >> *****The same behaviour. >> >> 2) use 3.18 kernel, it has fixes for misbehaving halted control endpoints >> >> *****The same behaviour. >> >> >> 3) 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: >> >> Results: >> >> I did the hack on one of the latest branches of Ubuntu source kernel >> 3.18, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=summary >> >> After did the changes on xhci code, and rebuild the kernel. >> >> a) Connect the brick to the PC >> b) Switch on, and the device was detected as usb device. (logs lines >> were recorded) >> c) Run fw uploading, and the device isn't longer detected by the >> communication library. >> >> After this hack seem like the behaviour become worst. >> >> I attached a fragment of /var/logs/syslog related. >> >> Something else to try ? >> >> Thanks in advance. >> >> Gustavo. >> >> On Thu, Dec 18, 2014 at 4:42 PM, Gustavo Duarte <gus.dua...@gmail.com> wrote: >>> Thanks Mathis for these suggestions, i'm going to try it, and let you >>> know the results. >>> >>> i hope you have a nice rest. >>> >>> Gustavo. >>> >>> >>> On Thu, Dec 18, 2014 at 2:12 PM, Mathias Nyman >>> <mathias.ny...@linux.intel.com> wrote: >>>> 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
