https://bugzilla.kernel.org/show_bug.cgi?id=213839 --- Comment #10 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- So far I have only looked at the Linux trace. It shows two unusual things I don't understand. One is that some process (I don't know which) re-reads the hub's device and configuration descriptors while the second device is being initialized, and apparently as a result of this the process decides to reset the hub. Why does this happen? The second is that when the descriptors are re-read, the hub's config descriptor has changed! The original bmAttributes value is 0xe0, as shown in the lsusb output above. But the bmAttributes value in the trace is 0xc0; the changed bit is the flag for Wakeup support. Most likely this is a bug in the hub's firmware. Perhaps additional debugging information will help. You can enable dynamic debugging and snooping for USB by doing: echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control echo 1 >/sys/module/usbcore/parameters/usbfs_snoop Clear the kernel log buffer by doing: dmesg -C Then plug in the hub and and plug in a device to one of the non-working ports. Let's see what the dmesg log shows after that. Another unusual thing shows up clearly in the trace: The autosuspend_delay_ms time is set to a very low value; it looks like 20 ms. You might get better results leaving the delay set to its default value of 2 seconds. Or turn USB autosuspend off entirely by doing: echo -1 >/sys/module/usbcore/parameters/autosuspend before plugging in the hub. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
