On 21.03.19 16:19, Mathias Nyman wrote:
On 21.3.2019 13.05, Georg Chini wrote:
On 16.03.19 15:52, Georg Chini wrote:
On 15.03.19 17:04, Georg Chini wrote:
On 15.03.19 15:48, Mathias Nyman wrote:
On 14.3.2019 20.39, Georg Chini wrote:
On 14.03.19 15:00, Mathias Nyman wrote:
On 14.3.2019 14.38, Georg Chini wrote:
Hello,
I have a problem with multiple USB2 devices. After purchasing a
new motherboard,
some USB2 devices (specifically audio devices and bluetooth
dongles) do no longer
work when connected to a hub, even if they are the only device
on the hub. They do
work when they are directly connected to an USB (2.0 or 3.0)
port of the machine.
The error I am getting with the hub in between is "Not enough
bandwidth for new
device state". Here are example kernel messages for a bluetooth
dongle:
Mar 14 08:12:33 mini kernel: usb 1-4.1: new full-speed USB
device number 15 using xhci_hcd
Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device found,
idVendor=0a12, idProduct=0001, bcdDevice=31.64
Mar 14 08:12:33 mini kernel: usb 1-4.1: New USB device strings:
Mfr=0, Product=0, SerialNumber=0
Mar 14 08:12:33 mini kernel: usb 1-4.1: Not enough bandwidth
for new device state.
I have only one single USB controller:
00:15.0 USB controller: Intel Corporation Atom Processor C3000
Series USB 3.0 xHCI Controller (rev 11)
I am using kernel 5.0.
lsusb output:
Bus 002 Device 004: ID 05e3:0617 Genesys Logic, Inc.
Bus 002 Device 003: ID 05e3:0617 Genesys Logic, Inc.
Bus 002 Device 002: ID 05e3:0617 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 011: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 010: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 008: ID 046d:0994 Logitech, Inc. QuickCam
Orbit/Sphere AF
Bus 001 Device 016: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 009: ID 0557:2419 ATEN International Co., Ltd
Bus 001 Device 006: ID 0557:7000 ATEN International Co., Ltd Hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 003: ID 0d8c:0102 C-Media Electronics, Inc.
CM106 Like Sound Device
Bus 001 Device 002: ID 0b0e:0348 GN Netcom
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The C-Media sound device is directly connected to the machine
and is working.
The BT dongle is on a hub and does not work. If I connect the
C-Media device
to a hub, it will also produce the "not enough bandwidth"
error. Can anybody help
me to debug this problem further?
Logs and traces could help, also lsusb -v output.
logs:
mount -t debugfs none /sys/kernel/debug
echo -n 'module xhci_hcd =p' >
/sys/kernel/debug/dynamic_debug/control
echo -n 'module usbcore =p'
>/sys/kernel/debug/dynamic_debug/control
<connect failing usb devices>
send output of dmesg
traces:
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
<connect failing device>
send content of /sys/kernel/debug/tracing/trace
-Mathias
Thanks for your reply. Please find the output attached. What I did:
- I removed all USB devices from the machine, except one USB hub
- I plugged the C-Media sound device into the hub and collected
the data
- For reference I plugged the same device into a free USB 2.0
port on the
machine and collected the data.
As already said, direct connection to a port works while it does
not work
on the hub. The files with _working are from plugging into the
machine,
those with _failed are from plugging into the hub.
I also confirmed that the device is working when plugged directly
into
the USB 3.0 port and also that it does not work on an USB 2.0 hub
plugged
into an USB 2.0 port.
Hi,
According to lsusb your Genesys hub(s?) is(are) mess. Can you try
with a different hub?
As an example it shows you have three USB3 hubs connected, first
has 0 ports, and the other
two have 42 ports each. (not possible, or allowed)
The bandwidth error originates from xhci host. It's a 'Secondary
Bandwidth Error' message
generated when xHCI calculates that the external hub can't handle
the requested bandwidth
needed when enabling new endpoints on the connected device behind
the hub.
-Mathias
In my tests there was only a single 10-port hub connected to the
(only) USB 3.0 port. This hub
seems internally to consist of three 4-port hubs.
As already mentioned I tested all possible combinations, which
includes an USB 2.0 Hub
on an USB 2.0 port. Regardless which hub or which port I am using
(I tested two USB 2.0
and two USB 3.0 hubs on different ports), the result is always the
same. The device works
when connected to the port and throws an error when connected to a
hub.
Or do you want the debug information with another hub?
Regards
Georg
Some additional information: The problem seems to occur only with
bluetooth dongles
and USB sound cards. I tested various other devices: Scanner, web
cam, an USB 2.0
USB stick, an old DVB-T adapter and my Canon camera all work fine on
the USB 3.0
hub. Keyboard/mouse works when connected to an USB 2.0 hub.
I double checked that the issue also happens, when there is only one
4-port USB 2.0
hub plugged into an USB 2.0 port, so I would exclude the hub itself
as source of the
problem.
Regards
Georg
Is there any workaround I could try? Do you need additional information?
You could try disabling usb link power management (LPM) if it's enabled.
There are some indication that it impacts the xHC host bandwidth
allocation algorithm.
You mean setting XHCI_HW_LPM_DISABLE? That did not help.
From the logs we should be able to calculate if we really are close to
any bandwidth limit
by summing together bandwidth needed by each enabled periodic endpoint
behind the hub.
The issue happens when only a single hub and a single device is
connected to the
USB subsystem. On my previous board, I had two USB dongles and two sound
devices connected to the same hub and it worked without issues. So I
guess it
is not a real bandwidth limit. Somehow the hub seems to eat the bandwidth.
The available secondary bandwidth also depends on the hub type (single
or multi-TT).
The downstream facing ports of a single-TT hub creates a single
Secondary Bandwidth Domain,
whose bandwidth is shared across all Full- or Low-speed devices
attached to the hub.
-Mathias