• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 7164 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/TUSB8041: U1/U2 fail, can't read hub descriptor, Cannot set link state.

Dallas Chen
Prodigy 60 points
Part Number: TUSB8041

Tool/software: Linux

Dear TI,

We have two X86 INTEL Denverton platform project, which used 2 TUSB8041 on board design.
Recently, both of the two project  find some MB will take a lot of time when boot into REDHAT LINUX(7.5/7.4/7.3).
After check dmesg, there is some key word as below:
==============
usb 2-4: Set SEL for device-initiated U1 failed.
usb 2-4: Set SEL for device-initiated U2 failed.
hub 2-3:1.0: config failed, can't read hub descriptor (err -22)
usb 2-3: Disable of device-initiated U1 failed.
usb 2-3: Disable of device-initiated U2 failed. 
hub 2-3:1.0: config failed, can't get hub status (err -71)
xhci_hcd 0000:00:15.0: Cannot set link state
==============
we have do some experiment for your reference:
1. Force AC shutdown & 4S shutdown then power on, the symtom will gone, only OS shutdown will fail.
2. UBUNTU/Windows got similar symptom, not only happen in REDHAT
3. Cut the USB3.0 signal from SOC to TUSB8041 upstream, the symptom will gone and USB2.0 still work fine.

We have measured the sequence looks good 3.3V==>1.1V==RESET
And the sequence after AC/4S/OS shutdown then power on is the same.

Could you advise if any possible design defect in our project?

  • 0
    TI__Intellectual 1350 points

    Hello Dallas,

    From first look it sounds like a USB3.0 signal integrity issue, and we would have to review the layout to confirm for sure.

    Best,
    Gerasimos

  • 0
    Prodigy 60 points

    Hi Gerasimos,

    Thanks for your quick response.

    I don't think this is SI issue, because different shutdown behavior got opposite testing result.

    And for sure the MB has passed our internal SI team verification followed USB ORG.

    BTW, I'll still sent you the BRD file for your review.

    Could you give me you Email.

  • 0 in reply to Dallas Chen
    TI__Guru 60870 points

    Hi Dallas,

    It sounds like either the host / hub link is going to compliance mode or the hub is still in U3 / while the host is in rx.detect.  In both cases, the host can clear out the condition with a warm reset.

    What is the state of VBUS to the hub during this test?  Does it go low?  Is it possible to read the port status of the host to determine if it has entered compliance mode?

    Thanks,

    JMMN

  • 0 in reply to JMMN
    Prodigy 60 points
    Hi JMMN,
    VBUS always keep high level after power on, we feed it from ATX P5V.
    I will check with our SW people is it going to compliance mode or not, and feedback here.
    tks.
  • 0 in reply to JMMN
    Prodigy 60 points

    Hi JMMN,

    We take your suggestion and LET BIOS issues a S/W reset after S5 resume could fixed this fail symptom.

    Although still not finding out the rootcause, but it resolve our problem for the production.

    I'll keep update once we digger out the rootcause is from HUB or HOST side.

    Many thanks.

  • 0 in reply to Dallas Chen
    TI__Guru 60870 points
    Hi Dallas,

    Ok, please update when you have root cause. If USB_VBUS to the hub is staying on during the cycle, it is likely a case where the host and the hub get out of sync (hub in U3, host in rx.detet/polling). If USB_VBUS is toggled low, it may be a case where the host or the hub detects the other's receiver terminations early and times out of polling and enters compliance mode.

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 60 points

    Dear JMMN,

    1. Although the workaround BIOS going well around 4-5 days on/off stress test, we might missing the defect part sorting from production and then deliver to our end customer if this is a HUB issue, right?

    2. When fail how could I proof  HUB is in U3 state or not?

    3. In your experiment & opinion, this is HOST platform issue or HUB defect issue?

    tks.

  • 0 in reply to Dallas Chen
    TI__Guru 60870 points
    Hi Dallas,

    This issue isn't a part defect, it is a system set-up issue between the host and the hub.

    If VBUS to the USB_VBUS input of the hub is always on during OS shutdown the problem is likely a U3 issue.
    If VBUS to the USB_VBUS input of the hub is cycled low during the OS shutdown the problem is likely an entrance to compliance mode.

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 60 points

    Hi JMMN,

    I would like update the information to you:

    After we removed the workaround (SW reset) then update the INTEL SPS FW in BIOS, the fail boards all pass our test in thousand loop.

    So, although we do not know what has been modified in that FW (there is no change note about XHCI controller).

    I belived it's what you have ever mentioned HUB stock in U3 state but host can't wake it from U2 U1 then U0

    Your response is a big hint for our debugging.

    Thank you very  much!