Re: USB 3.0 and xHCI Host-Controller
Thanks Alan. On Fri, Jan 16, 2015 at 1:27 PM, Alan Stern wrote: > On Fri, 16 Jan 2015, Mathias Nyman wrote: > >> also usbmon traces can be helpful, at least for others, I'm myself horribly >> slow at deciphering those > > Attached is my usbmon "cheat sheet". It's a big help in deciphering > common control transfers. > > I wrote it before USB-3 came out, and I never included the USB-3 hub > commands and status bits. If you feel like adding those on to the > cheat sheet, please post the final result. > > 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: USB 3.0 and xHCI Host-Controller
Hi Mathias, On Fri, Jan 16, 2015 at 1:14 PM, Mathias Nyman wrote: > Hi > > Sorry about not answering earlier, many new things piled up during my > vacation and needed attention. No problem. > 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 I'll try to get these new treces and let you know the results. Many Thanks. Gustavo -- 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: USB 3.0 and xHCI Host-Controller
On 16.01.2015 17:27, Alan Stern wrote: > On Fri, 16 Jan 2015, Mathias Nyman wrote: > >> also usbmon traces can be helpful, at least for others, I'm myself horribly >> slow at deciphering those > > Attached is my usbmon "cheat sheet". It's a big help in deciphering > common control transfers. > > I wrote it before USB-3 came out, and I never included the USB-3 hub > commands and status bits. If you feel like adding those on to the > cheat sheet, please post the final result. > > Alan Stern > Thanks, this helps a lot. -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
Re: USB 3.0 and xHCI Host-Controller
On Fri, 16 Jan 2015, Mathias Nyman wrote:
> also usbmon traces can be helpful, at least for others, I'm myself horribly
> slow at deciphering those
Attached is my usbmon "cheat sheet". It's a big help in deciphering
common control transfers.
I wrote it before USB-3 came out, and I never included the USB-3 hub
commands and status bits. If you feel like adding those on to the
cheat sheet, please post the final result.
Alan Stern
Standard device requests
RQtype Req Value Index Length
--
0 1 dev-feat0 0 Clear device feature
0 3 dev-feat0 0 Set device feature
0 5 address 0 0 Set device address
0 9 config-value0 0 Set configuration
1 b altsetting intf0 Set interface
1 1 intf-feat intf0 Clear interface feature
1 3 intf-feat intf0 Set interface feature
2 1 ep-feat ep 0 Clear endpoint feature
2 3 ep-feat ep 0 Set endpoint feature
80 0 0 0 2 Get device status
80 6 descr-type/ 0/ len Get descriptor
index lang-ID
80 8 0 0 1 Get configuration
81 0 0 intf2 Get interface status
81 a 0 intf1 Get interface (altsetting)
82 0 0 ep 2 Get endpoint status
Device features:0 = self-powered, 1 = remote wakeup
Interface features: None
Endpoint features: 0 = halt
Descriptor types: 1 = device, 2 = config, 3 = string, (4 = interface,
5 = endpoint), 6 = device qualifier, 7 = other-speed config
Hub class requests
RQtype Req Value Index Length
--
20 1 hub-feat0 0 Clear hub feature
20 3 hub-feat0 0 Set hub feature
23 1 port-feat sel/0 Clear port feature
port
23 3 port-feat sel/0 Set port feature
port
a0 0 0 0 4 Get hub status
a0 6 29000 len Get hub descriptor
a3 0 0 port4 Get port status
Hub features: 0 = hub local power, 1 = hub over current,
10 = ch hub local power, 11 = ch hub over current
Port features: 0 = connect, 1 = enable, 2 = suspend, 3 = over current,
4 = reset, 8 = power, 9 = low speed, a = high speed,
b = test mode, c = indicator,
10 = ch connect, 11 = ch enable, 12 = ch suspend,
13 = ch over current, 14 = ch reset
Selector is used for port indicators
HID class requests
RQtype Req Value Index Length
--
21 9 report-type/ID intflen Set report
21 a duration/ID intf0 Set idle
21 b proto intf0 Set protocol
81 6 descr-type/set intflen Get class descriptor
a1 1 report-type/ID intflen Get report
a1 2 0/IDintf1 Get idle
a1 3 0 intf1 Get protocol
Report type:1 = input, 2 = output, 3 = feature
Descriptor type:21 = HID, 22 = Report, 23 = Physical
Protocol: 0 = boot, 1 = report
Re: USB 3.0 and xHCI Host-Controller
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 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 >> Date: Tue, Jan 6, 2015 at 10:46 AM >> Subject: Re: USB 3.0 and xHCI Host-Controller >> To: Mathias Nyman >> 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 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 >>> 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 >>>&g
Re: USB 3.0 and xHCI Host-Controller
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Jan 16, 2015 at 12:57:34PM -0200, Gustavo Duarte wrote: > Greg and all, > > Something more to try on this ? You said you were going to respond back with the answers to the questions, did I miss that response? thanks, greg k-h -- 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: USB 3.0 and xHCI Host-Controller
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 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
> Date: Tue, Jan 6, 2015 at 10:46 AM
> Subject: Re: USB 3.0 and xHCI Host-Controller
> To: Mathias Nyman
> 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 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
>> 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
Re: USB 3.0 and xHCI Host-Controller
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
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
Re: USB 3.0 and xHCI Host-Controller
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
Re: USB 3.0 and xHCI Host-Controller
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 ? Another things that i can do after that, is obtain the messages of the communication with the brick on a PC where all work fine, and compare both. I don't know if this would be useful because, the driver used is ehci-pci. Thanks in advance. Gustavo. On Tue, Dec 16, 2014 at 9:34 AM, Gustavo Duarte wrote: > Ahh, good tip, I'll try it, and let you know the output. > > Thanks. > > On Tue, Dec 16, 2014 at 8:49 AM, Mathias Nyman > wrote: >> Hi >> >> On 16.12.2014 00:53, Gustavo Duarte wrote: >>> Hi Guys, >>> >>> >>> I'm having troubles for communication between a NXT - Lego Brick >>> device (http://www.lego.com/) and a Notebook with USB 3.0. >>> >>> kernel version: >>> >>> $ uname -r >>> 3.13.0-36-generic >>> $lspci -vvv >>> >>> 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host >>> * >>> Questions >>> * >>> >>> 1) Do you think this issue could be caused by kernel/xhci_hcd module ? >>> >> >> It's possible Can you upgrade to a more recent kernel and see if it helps? >> There are a lot of xhci changes since 3.13. Current is 3.18 >> >>> 2) I know that without the brick device, replicate this tests for you >>> isn't possible. >>> >>> So i would like to ask you, a guide to debug this problem, what kind >>> of things I can do to try find out, the problem. >>> >> >> what does dmesg say? any xhci related errors? >> >> You can enable more verbose xhci debugging with: >> echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control >> >> then start communicating with your device, and show the output of dmesg. >> >> Requires dynamic debug support and debugfs mounted, I think many >> distributions have them as default. >> >> -Mathias >> brick-boot.log Description: Binary data upload.log Description: Binary data
Re: USB 3.0 and xHCI Host-Controller
Ahh, good tip, I'll try it, and let you know the output. Thanks. On Tue, Dec 16, 2014 at 8:49 AM, Mathias Nyman wrote: > Hi > > On 16.12.2014 00:53, Gustavo Duarte wrote: >> Hi Guys, >> >> >> I'm having troubles for communication between a NXT - Lego Brick >> device (http://www.lego.com/) and a Notebook with USB 3.0. >> >> kernel version: >> >> $ uname -r >> 3.13.0-36-generic >> $lspci -vvv >> >> 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host >> * >> Questions >> * >> >> 1) Do you think this issue could be caused by kernel/xhci_hcd module ? >> > > It's possible Can you upgrade to a more recent kernel and see if it helps? > There are a lot of xhci changes since 3.13. Current is 3.18 > >> 2) I know that without the brick device, replicate this tests for you >> isn't possible. >> >> So i would like to ask you, a guide to debug this problem, what kind >> of things I can do to try find out, the problem. >> > > what does dmesg say? any xhci related errors? > > You can enable more verbose xhci debugging with: > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > > then start communicating with your device, and show the output of dmesg. > > Requires dynamic debug support and debugfs mounted, I think many > distributions have them as default. > > -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
Re: USB 3.0 and xHCI Host-Controller
Hi On 16.12.2014 00:53, Gustavo Duarte wrote: > Hi Guys, > > > I'm having troubles for communication between a NXT - Lego Brick > device (http://www.lego.com/) and a Notebook with USB 3.0. > > kernel version: > > $ uname -r > 3.13.0-36-generic > $lspci -vvv > > 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host > * > Questions > * > > 1) Do you think this issue could be caused by kernel/xhci_hcd module ? > It's possible Can you upgrade to a more recent kernel and see if it helps? There are a lot of xhci changes since 3.13. Current is 3.18 > 2) I know that without the brick device, replicate this tests for you > isn't possible. > > So i would like to ask you, a guide to debug this problem, what kind > of things I can do to try find out, the problem. > what does dmesg say? any xhci related errors? You can enable more verbose xhci debugging with: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control then start communicating with your device, and show the output of dmesg. Requires dynamic debug support and debugfs mounted, I think many distributions have them as default. -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
USB 3.0 and xHCI Host-Controller
Hi Guys, * Issue description * I'm having troubles for communication between a NXT - Lego Brick device (http://www.lego.com/) and a Notebook with USB 3.0. I'm using a Java development SDK, to build apps and flash the Brick: http://www.lejos.org We are working with two very similar models of Notebooks: a) Called Positivo-1: Has 3 USB 2.0 ports, b) Called Positivo-2: Has 2 USB 2.0 and 1 USB 3.0 port. The name of positivo comes from: (making a reference to the brand name:http://www.positivobgh.com.ar/hogar/spa/productos/c-501) On Postivo-1 all work fine, but on the Positivo-2 the communication with the brick isn't working. I did some tests, getting some treces, on a Notebook where all work fine and on the other one. Both notebook are running Ubuntu 12.04 with 64 bits. Positivo-1, has 3 physical interfaces USB 2.0 Positivo-2, has 2 physical interfaces USB 2.0 y one USB 3.0 On Positivo-1, as it has USB 2.0, linux attach to this hardware the driver "ehci-pci" On Positivo-2, as it has one USB 3.0, linux attach to the 3 ports the driver, "xhci_hcd". On Positivo-1 all work, fine, I make a HelloWorld example, following http://www.lejos.org/nxt/nxj/tutorial/Preliminaries/FirstProgram.htm Tutorial, and i could upload the app to the brick without any problem. But on Positivo-2, I couldn't, because the upload procedure is hangup, like is mentioned on the http://www.lejos.org/forum/viewtopic.php?f=7&t=4307&hilit=linux Topic. Making a research to try find out, what is the problem, i added printf to the library JNI code, which is used to send/receive message to/from the Brick. I modified the file: main_jlibnxt.c. With these printf I can see what messages are sent, when the PC try to open the communication with the BRICK and what is the response. I created two traces files during uploading a HelloWorld app, once for Positivo-1 and other one on Positivo-2 (USB 3.0) Here is the JNI code i modified, and whole traces, https://github.com/gusDuarte/enchanting-usb3 * Traces * POSITIVO-1: = Found NXT: NXT 001653105DC5 * starting FIND ... ** Created dev(139821856403248), addr: USB0::0x0694::0x0002::001653105DC5::RAW * ending FIND ... start OPEN ** Created dev(139821856403248), addr: USB0::0x0694::0x0002::001653105DC5::RAW end OPEN === SEND> 01:9B:12:D0:2A:7F:00:00 READ< 02:9B:00:4E:58:54:00:00 start OPEN ** Created dev(139821856403248), addr: USB0::0x0694::0x0002::001653105DC5::RAW end OPEN === SEND> 01:FF:00:00:00:00:00:00 READ< 02:FF:FD:00:00:00:00:00 SEND> 01:81:48:65:6C:6C:6F:57 READ< 02:81:00:00:00:00:00:00 . . more messages . . POSITIVO-2: = Found NXT: NXT 001653105DC5 * starting FIND ... ** Created dev(139675089352512), addr: USB0::0x0694::0x0002::001653105DC5::RAW * ending FIND ... start OPEN ** Created dev(139675089352512), addr: USB0::0x0694::0x0002::001653105DC5::RAW end OPEN === SEND> 01:9B:15:A4:08:7F:00:00 READ< 02:9B:00:4E:58:54:00:00 start OPEN ** Created dev(139675089352512), addr: USB0::0x0694::0x0002::001653105DC5::RAW end OPEN === SEND> 01:FF:00:00:00:00:00:00 READ< invalid data len: -110 Here the communication hangs. * Notebooks System information * PC POSITIVO-1 = Kernel version: $ uname -r 3.8.0-33-generic Libusb: ceibal@ceibal:~$ dpkg -l | grep libusb ii libusb-0.1-4 2:0.1.12-20 userspace USB programming library ii libusb-1.0-0 2:1.0.9~rc3-2ubuntu1 userspace USB programming library ic libusb-1.0-0:i386 2:1.0.9~rc3-2ubuntu1 userspace USB programming library ii libusb-dev2:0.1.12-20 userspace USB programming library development files ii libusbmuxd1 $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 04f2:b340 Chicony Electronics Co., Ltd $lspci -vvv 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: CLEVO/KAPOK Computer Device 3110 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci PC POSITIVO-2 kernel version: $ una
