USB3 problems

[Wim Vervoorn]

Hello,

I am running into issues when using USB3 sticks in a system (on an XHCI controller).

When I am using a single USB3 stick it gets detected properly. When I am using 2 USB3 sticks only one is detected. When using one USB3 and a USB2 stick it depends on the slots. In one case both are detected in the other case only the USB2 stick.

I was first blaming this on the XHCI controller initialization but I have now reproduced this same issue on two completely different systems. One base on AMD Steppe Eagle and the other on an Intel Braswell.

Does this sound familiar? Has anyone run into this before. (I am using two ADAT CI03 sticks)

The SeaBIOS version I am using is 9efbc0f43d0b50a0f314cff98c3b612e5dfb3ed5

Best Regards,
Wim Vervoorn

[Kevin O'Connor]

On Wed, Nov 04, 2015 at 03:30:52PM +0000, Wim Vervoorn wrote:
> Hello,
>
> I am running into issues when using USB3 sticks in a system (on an XHCI controller).
>
> When I am using a single USB3 stick it gets detected properly. When I am using 2 USB3 sticks only one is detected. When using one USB3 and a USB2 stick it depends on the slots. In one case both are detected in the other case only the USB2 stick.

I haven't seen a report like that in the past.  In order to diagnose,
we need access to a copy of the full debug log.  Please see:
http://www.seabios.org/Debugging

If you have a situation where a device sometimes works and sometimes
does not, it would help to provide a log of a working example along
with a log of a failed example.

Thanks,
-Kevin

P.S. when posting to the list it is preferable to use text only (no
html).

[Wim Vervoorn]

Hello Kevin,

I am sorry for posting in HTML, I overlooked that.

Thanks for getting back. I have tried to get logging at level 8 but if I do that the USB3 stick is failing anyhow for some reason. I guess this indicates some timing issue.

What I did is getting a couple of logs at level 7 as well.

The names of the logs speak for themselves I hope. The ADATA is the superspeed stick and the Kingston is a high speed version.

Please let me know if there is anything else I can do to help.

Best regards,

Wim

[Kevin O'Connor]

On Thu, Nov 05, 2015 at 09:23:59AM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I am sorry for posting in HTML, I overlooked that.
>
> Thanks for getting back. I have tried to get logging at level 8 but if I do that the USB3 stick is failing anyhow for some reason. I guess this indicates some timing issue.
>
> What I did is getting a couple of logs at level 7 as well.
>
> The names of the logs speak for themselves I hope. The ADATA is the superspeed stick and the Kingston is a high speed version.
>
> Please let me know if there is anything else I can do to help.

Thanks.  It looks like you have a few modifications to the source code
- that's fine, but it makes it hard to line up the debug messages to
the code I have - can you obtain the same logs using the latest
seabios from the master branch of the seabios git repo?  ( git clone
git://git.seabios.org/seabios.git )

Also, can you provide the output of "lspci" and "lsusb -v" in the
working setup and the output of "lsusb -t" in both the working and
non-working setup?

My initial reaction is that it seems similar to previous xhci reports
of devices renegotiating to super speed after initially being detected
as high speed.  Can you also test with the patch at:

http://www.seabios.org/pipermail/seabios/2015-August/009693.html

-Kevin

[Wim Vervoorn]

Hello Kevin,

Just a quick first reaction. This log is already including the patch you are referring to.

I will be looking into the other items as well and provide a response as soon as I have this information.

Best regards, Wim

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Thursday, November 5, 2015 2:38 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] USB3 problems

On Thu, Nov 05, 2015 at 09:23:59AM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I am sorry for posting in HTML, I overlooked that.
>
> Thanks for getting back. I have tried to get logging at level 8 but if I do that the USB3 stick is failing anyhow for some reason. I guess this indicates some timing issue.
>
> What I did is getting a couple of logs at level 7 as well.
>
> The names of the logs speak for themselves I hope. The ADATA is the superspeed stick and the Kingston is a high speed version.
>
> Please let me know if there is anything else I can do to help.

Thanks.  It looks like you have a few modifications to the source code
- that's fine, but it makes it hard to line up the debug messages to the code I have - can you obtain the same logs using the latest seabios from the master branch of the seabios git repo?  ( git clone git://git.seabios.org/seabios.git )

Also, can you provide the output of "lspci" and "lsusb -v" in the working setup and the output of "lsusb -t" in both the working and non-working setup?

My initial reaction is that it seems similar to previous xhci reports of devices renegotiating to super speed after initially being detected as high speed.  Can you also test with the patch at:

http://www.seabios.org/pipermail/seabios/2015-August/009693.html

-Kevin

[Kevin O'Connor]

On Thu, Nov 05, 2015 at 01:43:13PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> Just a quick first reaction. This log is already including the patch you are referring to.
>
> I will be looking into the other items as well and provide a response as soon as I have this information.

Does it always fail if that patch is not applied?

This looks like an XHCI issue, so logs at level 5 (instead of 7 or 8)
should be fine.

-Kevin

[Wim Vervoorn]

Hello Kevin,

On the AMD system it is always failing without the patch. The Braswell doesn't require it.

BR Wim

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Thursday, November 5, 2015 2:49 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] USB3 problems

On Thu, Nov 05, 2015 at 01:43:13PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> Just a quick first reaction. This log is already including the patch you are referring to.
>
> I will be looking into the other items as well and provide a response as soon as I have this information.

Does it always fail if that patch is not applied?

This looks like an XHCI issue, so logs at level 5 (instead of 7 or 8) should be fine.

-Kevin

[Kevin O'Connor]

On Thu, Nov 05, 2015 at 01:55:43PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> On the AMD system it is always failing without the patch. The Braswell doesn't require it.

Thanks.  If you can provide a success and failure log from the
Braswell machine (unmodified upstream seabios), that would help as
well.

-Kevin

[Kevin O'Connor]

On Wed, Nov 04, 2015 at 03:30:52PM +0000, Wim Vervoorn wrote:
> Hello,
>
> I am running into issues when using USB3 sticks in a system (on an XHCI controller).
>
> When I am using a single USB3 stick it gets detected properly. When I am using 2 USB3 sticks only one is detected. When using one USB3 and a USB2 stick it depends on the slots. In one case both are detected in the other case only the USB2 stick.
>
> I was first blaming this on the XHCI controller initialization but I have now reproduced this same issue on two completely different systems. One base on AMD Steppe Eagle and the other on an Intel Braswell.
>
> Does this sound familiar? Has anyone run into this before. (I am using two ADAT CI03 sticks)

To summarize some off-list exchange of debug logs, it looks like this
issue can be worked around by both applying the "msleep(20)" patch and
by increasing USB_TIME_SIGATT to 500.

I think making a new config file (eg, "etc/usb-time-sigatt") to allow
USB_TIME_SIGATT to be configured without patching the code would make
sense.  I'll send a patch.

I don't have a good solution for the msleep() issue right now.

-Kevin

[Kevin O'Connor]

On Mon, Nov 09, 2015 at 08:49:12AM -0500, Kevin O'Connor wrote:
> On Wed, Nov 04, 2015 at 03:30:52PM +0000, Wim Vervoorn wrote:
> > Hello,
> >
> > I am running into issues when using USB3 sticks in a system (on an XHCI controller).
> >
> > When I am using a single USB3 stick it gets detected properly. When I am using 2 USB3 sticks only one is detected. When using one USB3 and a USB2 stick it depends on the slots. In one case both are detected in the other case only the USB2 stick.
> >
> > I was first blaming this on the XHCI controller initialization but I have now reproduced this same issue on two completely different systems. One base on AMD Steppe Eagle and the other on an Intel Braswell.
> >
> > Does this sound familiar? Has anyone run into this before. (I am using two ADAT CI03 sticks)
>
> To summarize some off-list exchange of debug logs, it looks like this
> issue can be worked around by both applying the "msleep(20)" patch and
> by increasing USB_TIME_SIGATT to 500.
>
> I think making a new config file (eg, "etc/usb-time-sigatt") to allow
> USB_TIME_SIGATT to be configured without patching the code would make
> sense.  I'll send a patch.
>
> I don't have a good solution for the msleep() issue right now.

Can you try reverting the msleep and sigatt changes and only apply the
patch below?

-Kevin

commit d331c611e5572270419406e1e0057cd17e502edd
Author: Kevin O'Connor 
Date:   Tue Nov 10 08:50:52 2015 -0500

xhci: Check for device disconnects during USB2 reset polling

Some XHCI controllers register super-speed devices on high-speed ports
    and then disconnect them when the super-speed detection completes.
    Make sure to recognize these disconnect events during the reset
    process.

Signed-off-by: Kevin O'Connor

diff --git a/src/hw/usb-xhci.c b/src/hw/usb-xhci.c
index 173dff1..945b462 100644
--- a/src/hw/usb-xhci.c
+++ b/src/hw/usb-xhci.c
@@ -351,6 +351,9 @@ xhci_hub_reset(struct usbhub_s *hub, u32 port)
     struct usb_xhci_s *xhci = container_of(hub->cntl, struct usb_xhci_s, usb);
     u32 portsc = readl(&xhci->pr[port].portsc);
     int rc;
+    if (!(portsc & XHCI_PORTSC_CCS))
+        // Device no longer connected?!
+        return -1;

switch (xhci_get_field(portsc, XHCI_PORTSC_PLS)) {
     case PLS_U0:
@@ -360,11 +363,22 @@ xhci_hub_reset(struct usbhub_s *hub, u32 port)
     case PLS_POLLING:
         // A USB2 port - perform device reset and wait for completion
         xhci_print_port_state(3, __func__, port, portsc);
-        portsc |= XHCI_PORTSC_PR;
-        writel(&xhci->pr[port].portsc, portsc);
-        if (wait_bit(&xhci->pr[port].portsc, XHCI_PORTSC_PED, XHCI_PORTSC_PED, 100) != 0)
-            return -1;
-        portsc = readl(&xhci->pr[port].portsc);
+        writel(&xhci->pr[port].portsc, portsc | XHCI_PORTSC_PR);
+        u32 end = timer_calc(100);
+        for (;;) {
+            portsc = readl(&xhci->pr[port].portsc);
+            if (!(portsc & XHCI_PORTSC_CCS))
+                // Device disconnected during reset
+                return -1;
+            if (portsc & XHCI_PORTSC_PED)
+                // Reset complete
+                break;
+            if (timer_check(end)) {
+                warn_timeout();
+                return -1;
+            }
+            yield();
+        }
         rc = speed_from_xhci[xhci_get_field(portsc, XHCI_PORTSC_SPEED)];
         break;
     default:

[Kevin O'Connor]

On Tue, Nov 10, 2015 at 08:57:57AM -0500, Kevin O'Connor wrote:
> commit d331c611e5572270419406e1e0057cd17e502edd
> Author: Kevin O'Connor 
> Date:   Tue Nov 10 08:50:52 2015 -0500
> xhci: Check for device disconnects during USB2 reset polling
>
> Some XHCI controllers register super-speed devices on high-speed ports
> and then disconnect them when the super-speed detection completes.
> Make sure to recognize these disconnect events during the reset
> process.
>
> Signed-off-by: Kevin O'Connor <[e-mail]>

FYI, I committed this patch.

-Kevin

[Wim Vervoorn]

Hello Kevin,

I am sorry for my late response. I was occupied with other items. Thanks for notifying.

Best Regards,

Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : [phone]
E : [e-mail]
W : http://www.eltan.com

"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE [phone] OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Thursday, November 19, 2015 2:59 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] USB3 problems

On Tue, Nov 10, 2015 at 08:57:57AM -0500, Kevin O'Connor wrote:
> commit d331c611e5572270419406e1e0057cd17e502edd
> Author: Kevin O'Connor 
> Date:   Tue Nov 10 08:50:52 2015 -0500
> xhci: Check for device disconnects during USB2 reset polling
>
> Some XHCI controllers register super-speed devices on high-speed ports
> and then disconnect them when the super-speed detection completes.
> Make sure to recognize these disconnect events during the reset
> process.
>
> Signed-off-by: Kevin O'Connor <[e-mail]>

FYI, I committed this patch.

-Kevin