Delayed enumeration of USB 3.0 hubs (Level 1 and Level 2) on the Google chromebook pixel's Type-C port
Reported by
vinay.mh...@gmail.com,
Apr 6 2016
|
|||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0 Platform: 7647.84.0 (Official Build) stablechannel Steps to reproduce the problem: Following are the details of the Cypress PD Dock: --------------------------------------------------- The dock is capable of doing the following- 1. Powered using an external power brick (20V, 4.5A) connected to the Dock's barrel jack 2. Charge the chromebook pixel on the Dock's upstream Type-C port (5V/12V/20V) 3. Provide DisplayPort and HDMI ports (Supports 4K resolution at 60Hz) 4. Provide Downstream Type-A USB 3.0 ports (1 port from first level hub, 2 ports from second level hub) 5. Provide Type-C downstream port (USB 3.0) (1 port from first level hub) 6. USB to Audio converter (3.5mm audio jack) Steps to replicate the issue: ----------------------------- 1. Power up the Dock. 2. Setup USB 3.0 analyzers on the upstream Type-C and one of the downstream Type-A ports of the Dock. 3. Connect an external bus powered USB 3.0 harddisk to the Type-A port of the Dock to which the USB 3.0 analyzer is connected. 4. Start recording USB 3.0 traffic on the upstream and downstream USB 3.0 ports of the Dock. 5. Connect the Dock's upstream to one of the Type-C downstream ports of the chromebook pixel through the USB 3.0 analyzer using a C to C cable. 6. Notice that the chromebook indicates charging 7. Check the enumerated devices in 'lsusb' section in the 'chrome://system' page by frequently refreshing the page. 8. Once the downstream harddisk enumerates, notice the pop up that comes on the screen indicating the same. Note the time taken for enumeration. This duration varies from 6 seconds (time computed from the instant the Dock's upstream is connected to the chromebook) to 60+ seconds. Some times, the enumeration may not happen at all. 9. Repeat steps 1 through 8 multiple times to see different enumeration times. At times, the chromebook pixel crashes as well while doing this experiment. What is the expected behavior? The devices connected to the chromebook pixel should enumerate with in 10 to 15 seconds upon connection of the Cypress PD Dock to the chromebook pixel while the Dock is charging the chromebook pixel. This issue is not seen with other Type-C hosts (Macbook, Dell XPS 13) where the devices enumerate under 10 seconds with charging and display in operation. What went wrong? We at Cypress Semiconductors have an externally powered PD Capable Dock solution which we are testing against the Chromebook Pixel. Based on our testing, we have found that the chromebook pixel is slow in enumerating two level USB hubs connected to its Type-C port when the chromebook pixel is also charging from the same port.The enumeration delay ranges from 25 seconds to 60 seconds and at times may not enumerate at all. Did this work before? N/A Chrome version: 48.0.2564.116 Channel: stable OS Version: 48.0.2564.116 (Official Build) (64bit) Flash Version: 20.0.0.306r2 Notes and additional experiments performed: ------------------------------------------- 1. The same experiment performed on MacBook, Dell XPS 13 yields consistent enumeration time on repeating the experiment (6 to 10 seconds) 2. Signal quality tests have been performed on the Dock board (USB 3.0, USB 2.0 HS, FS, LS) and are known to pass with sufficient margin. 3. In the delayed enumeration case USB 3.0 traces captured from the experiment indicate that there is nothing wrong with the Hubs, device. The USB 3.0 traffic is as expected. The host seems to be communicating to the first level hub initially and the hub goes to U0 state with in 2 seconds of connection. Beyond this, the host is expected to send setup data packet and configure the hub which is delayed. This delay results in delayed enumeration of downstream devices. 4. This issue is also seen if the Dock functionality is altered to disable the USB 3.0 part of the hub (USB 2.0 only) 5. This issue is not seen if the Dock functionality is altered to act as a sink (UFP) on its upstream port. 6. This issue is not seen if the Dock is connected to the Type-A port of the chromebook using 'Type-A plug to Type-C plug' cable. 7. This issue is not seen if the Dock is altered to disconnect the second level hub
,
May 9 2016
,
May 9 2016
Is this still observed with newer chromeos builds(M-49 and M-50)?
,
May 13 2016
Hi Harpreet, Should I be checking with the latest developer build of the chromeOS? Thanks for the help, Vinay
,
May 13 2016
I see that the latest developer build of the chrome OS is 52.0.2717.5 (official build) dev (64-bit). Is this what I need to check against?
,
May 13 2016
I tested the behavior on chromebook pixel (chrome OS is 52.0.2717.5 (official build) dev (64-bit)) and still see the issue. Device enumeration is delayed; most of the times the device tree does not enumerate at all second connect onwards(first connect{charging OK - device enumeration OK} > Disconnect > Re-connect{charging OK but devices do not enumerate}). Chromebook freezes after multiple tries; power button had to be held pressed to perform a hard re-boot.
,
May 15 2016
Thanks Vinay. I have added some other people on the chrome os team who may be interested in the interoperability issues here. Could you please provide the output of the kernel dmesg when the system is affected by this issue? Also, please provide the output of lsusb as well when all devices are enumerated. Please help document and identify each device that is on the bus as well for our information. Also, regarding the external hard drive in question, do you have the same problem when you directly connect this device to Chromebook Pixel 2015's Type-C port or Type-A port? Thanks, Benson
,
May 16 2016
Hi Benson,
1. Attached .zip file (16_May_2016.zip) containing the following files:
a.(About System.mhtml) Log generated by opening 'chrome://system' when the dock is connected to the chromebook pixel and all the functionality is working as expected (charging, USB 3.0 mass storage enumeration). The mass storage connected consist of the following devices:
1. ASMEDIA ATZ11Z SATA to USB bridge (USB Known Good Device) + Kingston SSD Now 100 (64GB) to downstream port of first level USB 3.0 hub
2. TI KGD SATA to USB Bridge (USB KGD) + Kingston SSD Now uv300 (128GB) to downstream port of second level USB 3.0 hub
This problem is replaceable with any two mass storage devices
Below is the lsusb listing for the devices with details on the devices:
Bus 002 Device 006: ID 174c:55aa ASMedia Technology Inc. ASM1051 SATA 3Gb/s bridge << Mass storage device 1
Bus 002 Device 005: ID 04b4:3610 Cypress Semiconductor Corp. << Cypress GX3 USB 3.0 to Ethernet IC on the Dock
Bus 001 Device 007: ID 08bb:2912 Texas Instruments << USB to Analog Audio IC on the Dock
Bus 002 Device 004: ID 0451:9260 Texas Instruments, Inc. << Mass storage device 2
Bus 002 Device 003: ID 04b4:6508 Cypress Semiconductor Corp. << Level-2 USB 3.0 hub on the Dock
Bus 001 Device 006: ID 04b4:5217 Cypress Semiconductor Corp. << Cypress Billboard IC on the Dock
Bus 001 Device 005: ID 04b4:650a Cypress Semiconductor Corp. << Level-2 USB 2.0 hub on the Dock
Bus 002 Device 002: ID 04b4:6508 Cypress Semiconductor Corp. << Level-1 USB 3.0 hub on the Dock
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:07dc Intel Corp.
Bus 001 Device 003: ID 2232:6001 Silicon Motion
Bus 001 Device 002: ID 04b4:650a Cypress Semiconductor Corp. << Level-1 USB 2.0 hub on the Dock
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
b.(About System_no_enum.mhtml) Log generated by opening 'chrome://system' when the dock is connected to the chromebook pixel and the mass storage devices have not enumerated (but charging is ok). Note that the 'dmesg' and 'lsusb' logs do not come up in this log when the issue happens.
2. This issue is not seen when the drives are connected either to the Type-C port or the Type-A port of the Chromebook pixel directly. This issue is only seen when the following conditions are true:
a. Chromebook is being charged by the Dock
b. The dock consists of two USB 3.0 hubs; level-1 and level-2 (one below the other)
c. There are mass storage devices connected under the hubs
If the chromebook pixel is not being charged by the Dock, this issue is not seen.
,
May 16 2016
Vinay : Do you have this Chromebook system in Dev mode? Here's instructions on how to put it into dev mode. https://www.chromium.org/chromium-os/poking-around-your-chrome-os-device#TOC-Putting-your-Chrome-OS-Device-into-Developer-Mode Better yet, could you put your system into dev mode and use an image that you have built for test? That way, it should be simpler to run diagnostics on this system. Furthermore, it may be best for us to communicate off bug just for logistics. I'll email you separately about how we can acquire the hub in question for interop testing.
,
May 16 2016
,
May 16 2016
Hi Benson, Attached is a zip file (16_May_2016_CC_trace.zip) containing the complete flow of operations (CC_trace_with_sequence_of_operations.xlsx) as a time line of CC operations along with the actual observation noted in the 'comments' row. The zip file contains the log taken from the command 'chrome://system' at different points of time during the test flow. Thanks, Vinay
,
May 16 2016
Hi Benson, I just read Comment 9. I will check and put the chromebook in dev mode. Thanks, Vinay
,
May 16 2016
,
May 16 2016
,
May 16 2016
Where was CC_trace_with_sequence_of_operations.xlsx actually captured ? I'm seeing SOP' communication over there while none of our devices actually talk/answer SOP' messages.
,
May 17 2016
SOP' communication is between the dock and the cable which is e-marked. From Chromebook's perspective, these messages should be ignored by it if it does not initiate out respond to sop' messages. In the context of the issue being tracked here, sop' messages need o to be ignored. I have written down comments besides the transfers that are of importance for this issue.
,
May 24 2016
I've helped Vinay set up his Chromebook Pixel 2 (Samus) with a test image. He provided a lot of extra information about this failure. Copied from his email : Attached are the logs (23_May_2016.zip) consisting of lsusb, dmesg and /var/log/messages output captured during the test. Following test was performed: 1. Connect 4 Mass storage devices to the Dock and power it up. Connect a mass storage device to the Type-A port of the Chromebook pixel to store the captured logs. 2. Connect the upstream port of the Dock (Type-C) to one of the Type-C ports of the Chromebook pixel. 3. Collect the logs by executing the following commands in shell every time the Dock is connected to the Chromebook pixel: lsusb dmesg copy of /var/log/messages The logs have been named in the following format: <number>_<command>_<status>.txt Where, 1. number : indicates the ‘N’th time the Dock was connected to the Chromebook. For example, the first connect would have a prefix of 001, second connect would have 002 and so on. 2. command : Indicates the command used to generate the log 3. status : pass or fail. Pass indicates that the devices enumerated as expected. Fail indicates that some devices did not enumerate at all. 4. Disconnect the Dock from the chromebook 5. Re-connect the Dock to the chromebook and repeat the steps 3, 4 multiple times. 6. Following is the description of the devices connected during the test: Bus 002 Device 009: ID 0bc2:231b Seagate RSS LLC << Mass Storage connected to Level 2 Hub Bus 002 Device 010: ID 0411:0289 BUFFALO INC. (formerly MelCo., Inc.) << Mass Storage connected to Level 2 Hub Bus 002 Device 008: ID 04b4:3610 Cypress Semiconductor Corp. << USB 3.0 to Ethernet IC Bus 001 Device 039: ID 08bb:2912 Texas Instruments << Audio IC Bus 002 Device 007: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. << << Mass Storage connected to Level 1 Hub Bus 002 Device 006: ID 1005:c010 Apacer Technology, Inc. << Mass Storage connected to Level 1 Hub Bus 002 Device 005: ID 04b4:6508 Cypress Semiconductor Corp. << Level 2 USB 3.0 hub Bus 001 Device 038: ID 04b4:5217 Cypress Semiconductor Corp. << Billboard IC Bus 001 Device 037: ID 04b4:650a Cypress Semiconductor Corp. << Level 2 USB 2.0 hub Bus 002 Device 004: ID 04b4:6508 Cypress Semiconductor Corp. << Level 1 USB 3.0 hub Bus 002 Device 012: ID 0781:5580 SanDisk Corp. SDCZ80 Flash Drive << Mass Storage for collecting logs Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 8087:07dc Intel Corp. Bus 001 Device 004: ID 2232:6001 Silicon Motion Bus 001 Device 036: ID 04b4:650a Cypress Semiconductor Corp. << Level 1 USB 2.0 hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 7. The test setup is as shown in the attached photograph.
,
May 24 2016
,
May 24 2016
Hi Vinay, I've examined the results. Fascinating. The high-speed hub at 1-3:1.0 always seems to fail. This corresponds to the level 2 USB 2.0 hub, if I follow the enumeration order and hierarchy correctly. Here is an example failure case : [ 7744.634388] hub 1-3:1.0: USB hub found [ 7744.634502] hub 1-3:1.0: 4 ports detected [ 7744.897543] usb 1-3.1: new high-speed USB device number 52 using xhci_hcd [ 7744.971200] usb 1-3.1: New USB device found, idVendor=04b4, idProduct=650a [ 7744.971223] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7744.971241] usb 1-3.1: Product: CY-HX3 HUB [ 7744.971253] usb 1-3.1: Manufacturer: 2014 Cypress Semiconductor [ 7744.971267] usb 1-3.1: SerialNumber: 0000000001 [ 7744.972079] hub 1-3.1:1.0: USB hub found [ 7744.972138] hub 1-3.1:1.0: 4 ports detected [ 7745.034761] usb 1-3.3: new full-speed USB device number 53 using xhci_hcd [ 7745.109180] usb 1-3.3: No LPM exit latency info found. Power management will be impacted. [ 7745.111112] usb 1-3.3: New USB device found, idVendor=04b4, idProduct=5217 [ 7745.111135] usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7745.111152] usb 1-3.3: Product: Billboard Device [ 7745.111165] usb 1-3.3: Manufacturer: Cypress Semiconductor [ 7745.111178] usb 1-3.3: SerialNumber: 0001 [ 7745.111492] usb 1-3.3: ep 0x81 - rounding interval to 1024 microframes, ep desc says 2040 microframes [ 7745.115980] hid-generic 0003:04B4:5217.000D: hiddev0,hidraw0: USB HID v1.11 Device [Cypress Semiconductor Billboard Device] on usb-0000:00:14.0-3.3/input1 [ 7745.178831] usb 1-3.4: new high-speed USB device number 54 using xhci_hcd [ 7745.251773] usb 1-3.1.2: new full-speed USB device number 55 using xhci_hcd [ 7750.332308] usb 1-3.1.2: device descriptor read/all, error -110 [ 7751.333115] hub 1-3.1:1.0: cannot disable port 2 (err = -110) [ 7752.008534] PDLOG 2016/05/23 14:18:47.121 P0 Disconnected [ 7752.014725] PDLOG 2016/05/23 14:18:52.483 P0 SNK (not charging) Charger VBUS 5000mV max 5000mV / 500mA [ 7752.020920] PDLOG 2016/05/23 14:18:52.501 P0 Disconnected [ 7752.026948] PDLOG 2016/05/23 14:18:53.084 P0 SNK (not charging) Charger VBUS 5000mV max 5000mV / 500mA [ 7752.033213] PDLOG 2016/05/23 14:18:53.093 P0 SNK (not charging) Charger Type-C 5000mV max 5000mV / 3000mA [ 7752.039221] PDLOG 2016/05/23 14:18:53.157 P0 SNK (not charging) Charger Type-C 5000mV max 5000mV / 1500mA [ 7752.045438] PDLOG 2016/05/23 14:18:53.163 P0 SNK Charger ??? 5266mV max 12000mV / 3000mA [ 7752.051711] PDLOG 2016/05/23 14:18:56.162 P0 SNK Charger PD 12012mV max 12000mV / 3000mA [ 7752.334114] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7753.335122] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7754.336122] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7755.336978] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7756.338126] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7756.338147] hub 1-3.1:1.0: Cannot enable port 2. Maybe the USB cable is bad? [ 7757.338980] hub 1-3.1:1.0: cannot disable port 2 (err = -110) [ 7758.340124] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7759.341129] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7760.342136] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7761.342961] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7762.344142] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7762.344163] hub 1-3.1:1.0: Cannot enable port 2. Maybe the USB cable is bad? [ 7763.344928] hub 1-3.1:1.0: cannot disable port 2 (err = -110) [ 7764.345926] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7765.346959] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7766.347961] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7767.348981] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7768.349966] hub 1-3.1:1.0: cannot reset port 2 (err = -110) [ 7768.349987] hub 1-3.1:1.0: Cannot enable port 2. Maybe the USB cable is bad? [ 7769.350969] hub 1-3.1:1.0: cannot disable port 2 (err = -110) [ 7769.351020] hub 1-3.1:1.0: unable to enumerate USB device on port 2 [ 7770.351972] hub 1-3.1:1.0: cannot disable port 2 (err = -110) [ 7775.357987] hub 1-3.1:1.0: hub_port_status failed (err = -110) [ 7780.362975] hub 1-3:1.0: hub_port_status failed (err = -110) A couple things to note. The PDLOG output is coincidental, and doesn't indicate that is when the PD events occur. Those are batched and outputted on some interval. Secondly, it always seems to be port 2 on the 2nd level hub. Moreover, on every failure case I've seen so far, bad stuff seems to happen after this device starts enumerating : usb 1-3.1.2: new full-speed USB device number 95 using xhci_hcd Sometimes, but not always, we get an -ETIMEDOUT on descriptor read/all : [ 7750.332308] usb 1-3.1.2: device descriptor read/all, error -110 On a "pass" case, this device appears to be the USB to Analog Audio IC. [ 6445.854292] usb 1-3.1.2: new full-speed USB device number 21 using xhci_hcd [ 6445.929787] usb 1-3.1.2: New USB device found, idVendor=08bb, idProduct=2912 [ 6445.929814] usb 1-3.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 6445.929836] usb 1-3.1.2: Product: USB audio CODEC [ 6445.929852] usb 1-3.1.2: Manufacturer: Burr-Brown from TI Vinay : Is it possible to disconnect the audio codec from port 2 (assuming that's where it's connected) to see if this problem goes away? Also, I've copied +dgreid@, who has worked on USB audio on similar USB docking stations to see if he's seen anything like this before.
,
May 24 2016
I haven't seen that. But I don't think our other tested docks had two level USB hubs.
,
May 24 2016
Is there a way to gather scope shots of power into the failing USB device (audio codec)? I realize dock is externally powered but curious with everything hanging on it if there's some power issue at the point of enumeration failure that eventually subsides allowing for enumeration to succeed. Do things change if samus is fully charged or charging is disabled? Might be interesting to see how much power is being drawn at source via twinkie as well.
,
May 25 2016
Hi Benson, I disabled the downstream port 2 of the Level 2 hub so that the TI Audio Codec IC does not show up. I still see the delayed enumeration issue and failed enumeration. Attached are the logs. I don’t think that this is directly related to the Audio Codec IC. Few observations from an experiment that I had performed when this defect was logged: 1. This issue can be replicated by using discreet USB 3.0 hubs as well (not only the Dock on which we are debugging). To replicate the issue, the following can be done: a. Use a CCG1 Client board available here: http://www.cypress.com/documentation/development-kitsboards/cy4501-ccg1-development-kit?source=search&cat=software_tools This board, along with a 20V power adapter, acts as a DRP port and charges the chromebook when connected to it b. Connect a level 1 USB 3.0 hub under the CCG1 client board (to its Type-A port) c. Connect level 2 USB 3.0 hub under the first hub d. Connect one or more Mass storage devices under the level 1 hub and one or more mass storage devices under Level 2 hub e. Now, connect the CCG1 Client board’s Type-C port to the chromebook’s type-C port f. Wait for the devices to enumerate – note the delayed enumeration. g. Disconnect the setup from the chromebook h. Repeat steps e, f and g multiple times to notice the issue Thanks, Vinay
,
May 25 2016
Thanks for the further investigation Vinay. It seems that perhaps there is a more general issue with two levels hubs and the system when using PD. Could you help test tbroch@'s questions above in comment #21? Specifically could you retest when the laptop is fully charged, or when charging is disabled? 1. Fully charged is self explanatory. Charge to 100% and retest. 2. Charging disabled : This can be achieved by plugging in Pixel 2's charger on the other port. Based on your picture, plug the Pixel 2's charger into the right port. Then retest. When you plug in your test board, Pixel 2 will still negotiate PD with the Cypress docking station, but it will not choose higher voltage or start drawing power from the hub because it only charges from one port at a time and it will prefer the Pixel 2 charger because it can supply 60W. In that case, the Vbus on the left port should just be at 5V. You can verify the state of charging on the system by running the following command on Pixel : ectool --dev 1 usbpdpower Play with a bunch of combinations. The output of this tool tells you the state of both Type-C ports. 3. Todd's suggested using Twinkie (https://www.chromium.org/chromium-os/twinkie), or some other interposer USB PD sniffer that has current and voltage measurement capability. It's possible Cypress has something similar.
,
May 26 2016
Hi Benson, Attached zip file contains the following folders: 001_PA_Connected : Logs and CC trace taken when PA connected on the right side Type-C port of the chromebook 002_PA_Removed : Logs and CC trace taken when PA is not connected 003_Connect_to_TypeAPort : Dock is connected to the Type-A port of Chromebook (Dock does not charge the chromebook) Chromebook was charged to 100% when the tests were performed. Where ever applicable, CC traffic between the Dock and the chromebook was captured and VBUS voltage and current monitored using Cypress's internal tool for CC line data and voltage monitoring (.csv files in the zip file). In all the three cases, I could see delayed enumeration; some times the enumeration failed for the Mass storage devices. For the '001_PA_Connected' case, Chromebook always negotiated 5V contract (Dock being the source) and drew almost 0A current. Also, ectool could not be run; I get a "command not found" message. I took the charger information from the "chrome://system" instead to confirm that the PA is charging the chromebook. Thanks, Vinay
,
Feb 17 2017
,
Mar 18 2017
Activating. Please assign to the right owner and the appropriate priority.
,
May 1 2017
Is this still an issue? If so, what are the next steps?
,
May 1 2017
This is no longer an issue
,
May 1 2017
Thanks for the update! |
|||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||
Comment 1 by harpreet@chromium.org
, Apr 25 2016Components: OS>Kernel