Opened 9 months ago
Last modified 8 months ago
#18886 new bug
Anker ten port USB hub model AH231 is incompatible
Reported by: | WildKeccak | Owned by: | waddlesplash |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/USB/XHCI | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
It is incompatible while booting of of Samsung Flash Fit 256 GB USB 3.1.
It is incompatible when the the system is running. No hard drives, flash drives or network adapters are detected.
This bug is present in the newest version of Haiku (hrev 56737) and the oldest I can find.
This is an HP Stream 11 2023 edition.
Attachments (8)
Change History (19)
by , 9 months ago
comment:1 by , 9 months ago
Component: | - General → Drivers/USB/XHCI |
---|---|
Owner: | changed from | to
comment:2 by , 8 months ago
This bug is present in the newest version of Haiku (hrev 56737) and the oldest I can find.
That version is from January 2023 and is hardly recent. Most of the errors displayed in the syslog are not even printed on the latest XHCI driver. So, please test with a newer version.
(You may need to run "pkgman full-sync" to upgrade; it's possible you are stuck on an older version because some packages actually need to be uninstalled.)
comment:3 by , 8 months ago
I will attach three Syslogs, syslogA, which is the system before I plug in the hub after removing the network, syslogB, which is the system after I plug in the hub and try to get back on the network, and syslogC where I get back on the network by plugging in the ethernet adapter.
by , 8 months ago
by , 8 months ago
by , 8 months ago
comment:5 by , 8 months ago
KERN: usb hub 65: port 0: new device connected KERN: usb error xhci 0: unsuccessful command 11, error USB transaction (4) KERN: usb error xhci 0: KERN: unable to set address: I/O error KERN: usb xhci 0: transfer error on slot 6 endpoint 1: Stall KERN: usb error control pipe 66: timeout waiting for queued request to complete KERN: usb error xhci 0: KERN: cancel queued transfers: halted endpoint, reset! KERN: usb error hub 65: error updating port status KERN: usb error hub 65: KERN: debouncing port 0 failed: General system error
It's the "set address" command that's failing, it appears, and we get stuck in a loop from it.
comment:6 by , 8 months ago
Can you get a verbose "lsusb" of this device from Linux (or some other OS)?
comment:7 by , 8 months ago
From Slackware64-Puppy 15 20240420
# lsusb
Bus 002 Device 003: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 002 Device 006: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 005: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 004: ID 2357:0601 TP-Link UE300 10/100/1000 LAN (ethernet mode) [Realtek RTL8153]
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0408:5365 Quanta Computer, Inc. HP TrueVision HD Camera
Bus 001 Device 003: ID 0bda:b00b Realtek Semiconductor Corp. Realtek Bluetooth 4.2 Adapter
Bus 001 Device 006: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
comment:9 by , 8 months ago
There is a case to be made that this might be a broken or defective device. I don't always get a satisfying blue light by the USB ports on the device. Especially the light by the port that has the "battery" symbol. But sometimes others. This is a good anomaly. But not such a good bug.
Not reproducible at present moment. I should consider it suspect. I believe one of those blue light moments was one of the first four ports on system power up. I trust the Fit Plus drive more than I trust this device.
by , 8 months ago
Attachment: | typescript.before added |
---|
by , 8 months ago
Attachment: | typescript.after added |
---|
comment:11 by , 8 months ago
I guess it must be those Realtek hubs, but they look like 2.0 devices. Maybe we are incorrectly treating it as a 3.0 device and that's what's going wrong here?
A syslog