Re: kernel locks due to USB I/O

From: Alberto Sentieri <22t@tripolho.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org
Subject: Re: kernel locks due to USB I/O
Date: Thu, 19 Nov 2020 17:14:35 -0500	[thread overview]
Message-ID: <3c7ee33a-643b-0264-6317-d6c4fa70e9f6@tripolho.com> (raw)
In-Reply-To: <20201119194300.GA582614@rowland.harvard.edu>

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
>