Failure enumerating USB devices through a Hub - device descriptor read/64, error -71

[malacalypse]

On 4.14.71+ if I plug a device in through the hub:

Sep 21 19:40:22 alchemist kernel: [   76.581569] usb 1-1.1.3.1: new full-speed USB device number 21 using dwc_otg
Sep 21 19:40:22 alchemist kernel: [   76.691573] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:40:22 alchemist kernel: [   76.921575] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:40:22 alchemist kernel: [   77.151575] usb 1-1.1.3.1: new full-speed USB device number 22 using dwc_otg
Sep 21 19:40:22 alchemist kernel: [   77.261578] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:40:23 alchemist kernel: [   77.491581] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:40:23 alchemist kernel: [   77.611690] usb 1-1.1.3-port1: attempt power cycle
Sep 21 19:40:23 alchemist kernel: [   78.291587] usb 1-1.1.3.1: new full-speed USB device number 23 using dwc_otg
Sep 21 19:40:24 alchemist kernel: [   78.741596] usb 1-1.1.3.1: device not accepting address 23, error -71
Sep 21 19:40:24 alchemist kernel: [   78.851598] usb 1-1.1.3.1: new full-speed USB device number 24 using dwc_otg
Sep 21 19:40:24 alchemist kernel: [   79.291602] usb 1-1.1.3.1: device not accepting address 24, error -71
Sep 21 19:40:24 alchemist kernel: [   79.291819] usb 1-1.1.3-port1: unable to enumerate USB device

Whereas if I plug the same device in directly:

Sep 21 19:40:35 alchemist kernel: [   89.741673] usb 1-1.2: new full-speed USB device number 25 using dwc_otg
Sep 21 19:40:35 alchemist kernel: [   89.955317] usb 1-1.2: New USB device found, idVendor=1b12, idProduct=0015
Sep 21 19:40:35 alchemist kernel: [   89.955325] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 21 19:40:35 alchemist kernel: [   89.955329] usb 1-1.2: Product: H9 Pedal
Sep 21 19:40:35 alchemist kernel: [   89.955334] usb 1-1.2: Manufacturer: Eventide (www.eventide.com)
Sep 21 19:40:35 alchemist kernel: [   89.955338] usb 1-1.2: SerialNumber: *****Obscured*****
Sep 21 19:40:35 alchemist mtp-probe: checking bus 1, device 25: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2"
Sep 21 19:40:35 alchemist mtp-probe: bus: 1, device: 25 was not an MTP device

Here is another device, plugged in through the hub:

Sep 21 19:43:08 alchemist kernel: [  242.463224] usb 1-1.1.3.1: new full-speed USB device number 26 using dwc_otg
Sep 21 19:43:08 alchemist kernel: [  242.573224] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:43:08 alchemist kernel: [  242.803221] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:43:08 alchemist kernel: [  243.033221] usb 1-1.1.3.1: new full-speed USB device number 27 using dwc_otg
Sep 21 19:43:08 alchemist kernel: [  243.143230] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:43:08 alchemist kernel: [  243.373222] usb 1-1.1.3.1: device descriptor read/64, error -71
Sep 21 19:43:09 alchemist kernel: [  243.493372] usb 1-1.1.3-port1: attempt power cycle
Sep 21 19:43:09 alchemist kernel: [  244.173227] usb 1-1.1.3.1: new full-speed USB device number 28 using dwc_otg
Sep 21 19:43:10 alchemist kernel: [  244.613231] usb 1-1.1.3.1: device not accepting address 28, error -71
Sep 21 19:43:10 alchemist kernel: [  244.723233] usb 1-1.1.3.1: new full-speed USB device number 29 using dwc_otg
Sep 21 19:43:10 alchemist kernel: [  245.163240] usb 1-1.1.3.1: device not accepting address 29, error -71
Sep 21 19:43:10 alchemist kernel: [  245.163431] usb 1-1.1.3-port1: unable to enumerate USB device

And plugged in directly to the pi:

Sep 21 19:43:20 alchemist kernel: [  255.113284] usb 1-1.3: new full-speed USB device number 30 using dwc_otg
Sep 21 19:43:20 alchemist kernel: [  255.246816] usb 1-1.3: New USB device found, idVendor=1c75, idProduct=0288
Sep 21 19:43:20 alchemist kernel: [  255.246823] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Sep 21 19:43:20 alchemist kernel: [  255.246828] usb 1-1.3: Product: Arturia KeyStep 32
Sep 21 19:43:20 alchemist kernel: [  255.246832] usb 1-1.3: Manufacturer: Arturia
Sep 21 19:43:20 alchemist kernel: [  255.246836] usb 1-1.3: SerialNumber: 00000000001A
Sep 21 19:43:20 alchemist mtp-probe: checking bus 1, device 30: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3"
Sep 21 19:43:20 alchemist mtp-probe: bus: 1, device: 30 was not an MTP device

Both devices work fine with this hub on other systems.

[mypiandrew]

Hi,

With reference #2408

I'm seeing the same basic problem still, just don't see the intr:68 error messages anymore :

https://gist.github.com/mypiandrew/f99dc51884ee7575bfbfbf078036d2e6
https://gist.github.com/mypiandrew/99e5384f7dfd4142a73c35f0e8a18192
https://gist.github.com/mypiandrew/d10e98d0d166533e1da21a0656f1f989

Again it appears to me the problem is related to non-usb 2.0 (480M) devices

[P33M]

Does the behaviour change at all if you add dwc_otg.fiq_fsm_mask=0x0 to /boot/cmdline.txt? If so, then can you test 0x1, 0x2, 0x4, 0x8, 0x10 in turn and see which bit causes the difference?

[mypiandrew]

Hi,

Yes adding dwc_otg.fiq_fsm_mask=0x0 appears to improve things

Did some basic reboot testing that's usually caused the problem to eventually appear before

https://gist.github.com/mypiandrew/f928f459a6b9372e0fc4fa9a0d727947

Will do 10-in-a-row reboots and power ups to check before continuing

Is there one of the values that you have a hunch on or is it just a case of test/repeat x 10 for each setting?

[P33M]

My suspicion is that one of these bits (which each enable different FIQ optimisations) will cause a definite recurrence of the issue. I'd say 10 reboots with one particular setting should be enough to confirm that the bit is "ok".

[mypiandrew]

This is still with dwc_otg.fiq_fsm_mask=0x0

See last one, maybe spoke too soon ?

https://gist.github.com/mypiandrew/cb8f8fee74f08b3b12202ec41a82ac6c

Do you want me to still try others?

[mypiandrew]

Oh dear, I created a spreadsheet to keep track of the settings and 0x0 failed on first power up this time

https://gist.github.com/mypiandrew/f97f7186742cfb8ddf4a5e287b215c17

Will plough on and see how far I get on each of the other ones

[mypiandrew]

Right then have done the same test schedule checks on each setting.

Start cold boot then 10 soft reboots then 4 power off/on/off cycles finally then 3 soft reboots.

If a setup gives enumeration or device descriptor error that test run is ended

0x0, 0x1, 0x4 & 0x08 fail either straight away or v.quickly

0x2 is much better only failing three times on odd errors

[ 5.173805] rtc rtc0: __rtc_set_alarm: err=-22

[ 5.017155] ftdi_sio ttyUSB3: Unable to write latency timer: -71

[ 3.929411] usb 1-1.4: New USB device found, idVendor=1199, idProduct=6832
[ 3.929422] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.929429] usb 1-1.4: Product: Mini Card
[ 3.929945] usb 1-1.4: can't set config #1, error -32

0x10 is the clear winner, I've not been able to "break" the setup at all using that one

I do occasionally see this message at the end but it's not red so I can't say if it's a fault

[ 16.750450] random: crng init done
[ 16.750463] random: 7 urandom warning(s) missed due to ratelimiting

Does that help at all?

EDIT : Dropped back in the office this morning to pick something up, noticed I'd forgotten to to 0x08 so retested.

On first power up with setup still on 0x10 saw this error

[ 3.475621] usb 1-1.4: string descriptor 0 read error: -32
[ 3.475635] usb 1-1.4: New USB device found, idVendor=1199, idProduct=6832
[ 3.475644] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.505822] usb 1-1.4: can't set config #1, error -32

So I don't have anything 100% working, but 0x10 appears the best of the bunch

FWIW I don't think this prioblem is the same as OPs

[malacalypse]

I have done all of the settings, 0,1,2,4,8,10. All of them failed immediately.
dmesg with 0x0
dmesg with 0x1
dmesg with 0x2
dmesg with 0x4
dmesg with 0x8
dmesg with 0x10

[Fri 28 Sep 2018 23:23:27 GMT]$ uname -a
Linux alchemist 4.14.72-v7+ #1146 SMP Wed Sep 26 16:58:28 BST 2018 armv7l GNU/Linux

[6by9]

@malacalypse Just to check:

• did these devices work on the Pi with this hub prior to 4.14.71?
• is the hub active or passive?
• are you powering the Eventide and Arturia KeyStep 32 from the USB, or using external power supplies?
• have you tried other hubs?

Going through a passive hub will incur a voltage drop which will increase with load, so I just wanted to confirm it's not a simple power issue.

[malacalypse]

None of these devices have ever worked on the pi through the hub but I only started at version 4.14.70. I have no reference for past versions. They work fine without the hub and they work fine through the hub on all my other devices.

The hub is active, fully powered, and none of these devices pull significant current.

Only the Arturia is USB powered and it draws only 100mA or so. I have also tried with it external power. It does not matter. The others are externally powered. Note that the Arturia is a USB 1.1 device and all of my problems (there are many other devices that exhibit the same problem - some externally powered) are with USB 1.1 devices. Power source makes no difference.

I have tried a 3 port unpowered hub as well with similar negative results on the pi and positive results with other equipment.

[malacalypse]

Ok, new data point: after rebooting with the 3 port hub, it works: lsusb -v dmesg

Still does not work on the 7 port hub, regardless of combination of ports plugged into or other devices plugged into the ports.

And what's REALLY odd is that of two different kinds of devices which reliably don't work, one of them (the Eventide pedals) is USB 1.1 (12M) explicitly. The other (Arturia Keystep) reports a bcdUSB of 2.0, but shows up in lsusb as a 12M device.

[mypiandrew]

This morning we have been testing the setup without any of the dwc_otg.fiq_fsm_mask settings to try and find a reliable combination that triggers the fault

I have been able to reproduce the error using 2 x FTDI 230XS USB 1.1 (12M) parts attached to the GL850 (STT) Hub

That should be pretty reproducible from a hardware perspective

This shows the fault

https://gist.github.com/mypiandrew/6058fc1e76f5b9d7a0e8f4dcfc1962bf

We also used the same setup on a board fitted with a GL852 (MTT) USB hub part rather than an GL850 part, which appears a bit better but still eventually fails with errors

https://gist.github.com/mypiandrew/189102fb48e83eeb11dcfb468154d9bd

Next we tested the GL850 (STT) setup with only one of the 12M FTDI devices attached. which also failed pretty quickly.

https://gist.github.com/mypiandrew/256c138ab9fe48a0f21375cb81d4fd44

[P33M]

The fact that the issue's still there with the FIQ effectively disabled, and that control transfers are failing (which are the first transfers used to probe the device) suggests something more fundamental is broken.

@mypiandrew Is there a way you can reset the on-board hub externally after the CM has booted? I.e. keep the electrical connections the same but force a hub reset.

[mypiandrew]

@P33M I can solder a flying wire to the chip's reset pin and then touch it to 0V temporarily after the system booted if you think that helps you?

I don't know of a software command that will reset the chip

EDIT: I remember we did test on the original bug report that resetting one of the attached devices that failed at boot caused the device to be re-detected OK

https://gist.github.com/mypiandrew/5e0f5bf0f029c86214c79aef7fe699c4

[P33M]

Yes, I was thinking hardware reset.

[mypiandrew]

A bit of trial and error later

https://gist.github.com/mypiandrew/1bb543ae5d70483c66ec76774bdd1ff1

[P33M]

This looks like a hardware initialisation issue to me. Key suspects for this sort of thing are stable voltages and stable clocks - given that you can blip the reset and it magically starts working (or reboot the Pi with the hub connected).

It could be several things - the hub could either be in a bad state and not performing downstream traffic correctly, or downstream devices could be in a bad state if the hub's reporting connect events before the downstream ports have settled.

Can you repeat the test by booting with the hub connected and holding the downstream FTDI device in reset for ~10 seconds, while still connected to Vbus and DP/DN?

[mypiandrew]

@P33M

It is strange I'll give you that..

But I can't immediately see why it would be a HW problem as this has only appeared since the change 4.14.

This issue doesn't appear with 4.9.80, and 4.1.x and 4,4.x before that

There was this problem #1633 (with 4.4,x early on) which appeared to sort it's self out, but I can't say if this is related.

In case it's of interest we've also been using SuSE SLES 15 (which runs with 4.12.14) recently which seems stable and can't fault that.

I have to get another job out this afternoon, but I'll look into that FTDI test later on and post the results.

I'll also double check it's not a 4.14+Jessie issue (not that I think that matters).

[P33M]

With major version changes in the kernel, we have found in the past that there is enough code churn to cause significant timing differences. This typically manifests as e.g. some driver now being faster to initialise itself and probe a device, but the device isn't ready yet.

rpi-update firmwares are reasonably bisectable - You could start with the last version that shipped a 4.9 kernel from https://github.com/hexxeh/rpi-firmware and step forward until the first broken one. If it's just due to the 4.14 bump, then I'd start to look more closely at timing between the two versions.

[mypiandrew]

Hi

Yes I recall we have historically always seen a bumpy road when a new major kernel revision is released (4.1 =>4.4 =>4.9)

These things are usually resolved ultimately, I try to imagine it akin to moving house.

What you say about timing makes sense.

Running Raspbian Stretch

5c80565c5c0c7f820258c792a98b56f22db2dd03 (4.9.80 = Good)
696d7cc2d33acff340fb2ad924d29b9e9f52989d ( 4.14.18 = Bad)

4.14.18 also gives int:68 error incase that's interesting.

[    2.761440] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    2.881496] WARN::dwc_otg_handle_mode_mismatch_intr:68: Mode Mismatch Interrupt: currently in Host mode
[    3.044780] systemd[1]: System time before build time, advancing clock.
[    3.151869] usb 1-1.2: device descriptor read/all, error -32
[    3.185242] NET: Registered protocol family 10
[    3.198256] Segment Routing with IPv6
[    3.218095] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.252123] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[    3.286707] systemd[1]: Detected architecture arm.
[    3.291405] usb 1-1.1.1: new high-speed USB device number 5 using dwc_otg
[    3.340970] systemd[1]: Set hostname to <raspberrypi>.
[    3.412002] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=ec00
[    3.428374] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    3.448462] smsc95xx v1.0.6
[    3.551474] usb 1-1.2: new full-speed USB device number 6 using dwc_otg
[    3.570110] smsc95xx 1-1.1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:73:63:02
[    3.701482] WARN::dwc_otg_handle_mode_mismatch_intr:68: Mode Mismatch Interrupt: currently in Host mode
[    3.734370] usb 1-1.2: unable to read config index 0 descriptor/start: -32
[    3.749804] usb 1-1.2: chopping to 0 config(s)
[    3.763355] usb 1-1.2: string descriptor 0 read error: -32

[P33M]

This is going to be hard to debug if this is a custom board that does not have a breakout between the SoC USB lines and the hub chip in question. Is there a reference board available that you can plug into a CMIO board?

[malacalypse]

FYI switching to a different STT hub with a different (non-VIA) chipset completely resolved the issue. Devices enumerate correctly. Both of my VIA VL812 chipset hubs have this problem.

[P33M]

Ah. VIA labs usb hubs are incompatible with the Pi. They violate the USB2.0 spec for inter-packet gap acceptance (Pi generates an inter-packet gap that is larger than PC, but still acceptable).

[mypiandrew]

FWIW...

BRANCH=next rpi-update
uname -a
Linux raspberrypi 4.19.0-v7+ #1157 SMP Tue Oct 23 18:10:04 BST 2018 armv7l GNU/Linux

Appears to have fixed the issue we were seeing with 4.14.

Will keep an eye on it for now..just wanted to update this with our findings

[yoyojacky]

I have the same issure too, when i plug my raspberry pi pico, it does not show /dev/ttyACM0 even though I have already uploaded micropython firmware.
it shows :

pi@raspberrypi:~ $ sudo lsusb -v

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         3
  bMaxPacketSize0         9
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0003 3.0 root hub
  bcdDevice            5.10
  iManufacturer           3 Linux 5.10.17-v7l+ xhci-hcd
  iProduct                2 xHCI Host Controller
  iSerial                 1 0000:01:00.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x001f
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
        bMaxBurst               0
Hub Descriptor:
  bLength              12
  bDescriptorType      42
  nNbrPorts             4
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  bHubDecLat          0.0 micro seconds
  wHubDelay             0 nano seconds
  DeviceRemovable    0x00
 Hub Port Status:
   Port 1: 0000.02a0 5Gbps power Rx.Detect
   Port 2: 0000.02a0 5Gbps power Rx.Detect
   Port 3: 0000.02a0 5Gbps power Rx.Detect
   Port 4: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x000f
  bNumDeviceCaps          1
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x02
      Latency Tolerance Messages (LTM) Supported
    wSpeedsSupported   0x0008
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           4 micro seconds
    bU2DevExitLat         231 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x2109 VIA Labs, Inc.
  idProduct          0x3431 Hub
  bcdDevice            4.21
  iManufacturer           0
  iProduct                1 USB2.0 Hub
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0019
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x00e0
    Ganged power switching
    Ganged overcurrent protection
    TT think time 32 FS bits
    Port indicators
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent    100 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0101 power connect
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x002a
  bNumDeviceCaps          3
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat           4 micro seconds
    bU2DevExitLat         231 micro seconds
  Container ID Device Capability:
    bLength                20
    bDescriptorType        16
    bDevCapabilityType      4
    bReserved               0
    ContainerID             {30eef35c-07d5-2549-b001-802d79434c30}
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            5.10
  iManufacturer           3 Linux 5.10.17-v7l+ xhci-hcd
  iProduct                2 xHCI Host Controller
  iSerial                 1 0000:01:00.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0019
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x02
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0507 highspeed power suspend enable connect
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered
pi@raspberrypi:~ $

and my OS:

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7l+ #1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux
pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster
pi@raspberrypi:~ $

and when i use this command to show the device :

sudo lsusb 

pi@raspberrypi:~ $ sudo lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

nothing show up .

/dev/ttyAMA0
pi@raspberrypi:~ $

no /dev/ttyACM0 show up.

when i use dmesg to get device message, it shows:

[   56.543916] usb 1-1.2: new full-speed USB device number 3 using xhci_hcd
[   71.775357] usb 1-1.2: device descriptor read/64, error -110
[   87.760886] xhci_hcd 0000:01:00.0: ERROR: unexpected setup address command completion code 0x24.
[   88.590760] xhci_hcd 0000:01:00.0: ERROR: unexpected setup address command completion code 0x24.
[   88.802422] usb 1-1.2: device not accepting address 3, error -22
[   88.902447] usb 1-1.2: new full-speed USB device number 4 using xhci_hcd
[  104.104977] usb 1-1.2: device descriptor read/64, error -110

How can i solve this problem ? My other Pico works fine in same Raspberry Pi 4B

[pelwell]

https://www.raspberrypi.org/forums/viewtopic.php?t=302359