Re: kernel locks due to USB I/O

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/19/20 2:43 PM, Alan Stern wrote:
On Thu, Nov 19, 2020 at 02:21:47PM -0500, Alberto Sentieri wrote:
lsusb -t in a similar configuration I use for development (it has just 6
device, and not 36):

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
     |__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/7p, 480M
         |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/2p, 480M
             |__ Port 1: Dev 8, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
         |__ Port 2: Dev 7, If 0, Class=Hub, Driver=hub/2p, 480M
             |__ Port 1: Dev 10, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
         |__ Port 4: Dev 9, If 0, Class=Hub, Driver=hub/2p, 480M
             |__ Port 1: Dev 12, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
         |__ Port 5: Dev 11, If 0, Class=Hub, Driver=hub/7p, 480M
         |__ Port 6: Dev 13, If 0, Class=Hub, Driver=hub/7p, 480M
             |__ Port 6: Dev 15, If 0, Class=Hub, Driver=hub/2p, 480M
                 |__ Port 1: Dev 17, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
             |__ Port 7: Dev 16, If 0, Class=Hub, Driver=hub/2p, 480M
                 |__ Port 1: Dev 18, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
         |__ Port 7: Dev 14, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
Previously you said that each HID microcontroller is connected to port 1
of a two-port hub.  But that clearly isn't true for device 14 in the
listing above.  What happened there?
The program never talks to that device. It does not try to open it. The program has a list of valid interfaces, and if one is not in the list it will not be part of the game. Really I sent you a list of 5 devices, because one was disconnect when I ran lsusb.

This would be the list with the 6 devices:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
    |__ Port 3: Dev 53, If 0, Class=Hub, Driver=hub/7p, 480M
        |__ Port 1: Dev 54, If 0, Class=Hub, Driver=hub/2p, 480M
            |__ Port 1: Dev 56, If 0, Class=Human Interface Device, Driver=, 12M
        |__ Port 2: Dev 55, If 0, Class=Hub, Driver=hub/2p, 480M
            |__ Port 1: Dev 58, If 0, Class=Human Interface Device, Driver=, 12M
        |__ Port 3: Dev 57, If 0, Class=Hub, Driver=hub/2p, 480M
            |__ Port 1: Dev 60, If 0, Class=Human Interface Device, Driver=, 12M
        |__ Port 4: Dev 59, If 0, Class=Hub, Driver=hub/2p, 480M
            |__ Port 1: Dev 62, If 0, Class=Human Interface Device, Driver=, 12M
        |__ Port 5: Dev 61, If 0, Class=Hub, Driver=hub/7p, 480M
        |__ Port 6: Dev 63, If 0, Class=Hub, Driver=hub/7p, 480M
            |__ Port 6: Dev 69, If 0, Class=Hub, Driver=hub/2p, 480M
                |__ Port 1: Dev 70, If 0, Class=Human Interface Device, Driver=, 12M
            |__ Port 7: Dev 66, If 0, Class=Hub, Driver=hub/2p, 480M
                |__ Port 1: Dev 68, If 0, Class=Human Interface Device, Driver=, 12M         |__ Port 7: Dev 64, If 0, Class=Human Interface Device, Driver=usbhid, 12M

Again, device 64 (previous device 14) is not part of the game.

I compiled kernel 5.9.8, which is running, and have other kernels as well. I will try to reproduce the problem in my lab. I will let you know as soon as I have more information. If I were able to reproduce the problem, I will try to use a Beagle USB analyzer at the same time the problem occurs.

Thanks,

Alberto
Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux