usbip: sometimes stalls at kernel_recvmsg()
nm127 at freemail.hu
Tue Dec 21 08:03:11 UTC 2010
Max Vozeler wrote:
> Hi Németh,
> On 17.12.2010 06:45, Németh Márton wrote:
>>>> Németh Márton wrote:
>>>>> I'm working with usbip and I sometimes see a stall when I run
>>>>> the "lsusb" command from the userspace.
>>> Does it eventually recover?
>> No, it doesn't. After 120 seconds messages are printed in dmesg
>> that the "lsusb" process is blocked more than 120 seconds.
> Can you describe the sequence of events which
> happened before the hang?
Boot EeePC 901. Attach hama AC-150 webcam. Execute the following
commands as root:
echo 0 >/sys/devices/platform/eeepc/camera
usbip_bind_driver --usbip 3-2
On a second xterm window execute the following commands:
usbip --list localhost
usbip -a localhost 3-2
Note that the hama AC-150 webcam has a snapshot button on it which
uses the interrupt endpoint. The interrupt URB is sent in when the
gspca_sonixj driver activates in order to catch the button events.
The hang maybe related, I don't know.
> Was the device detached before or during lsusb?
> Perhaps try echo t > /proc/sysrq-trigger to see
> where exactly lsusb gets stuck.
> I found processes can get stuck in usb_kill_urb
> if they tried to unlink an URB, but the unlink
> request was not answered before detach.
> Perhaps this is related. I am attaching a patch
> which fixes that bug for me, perhaps you could
> try if it makes a difference?
I'll try your patch later, thanks.
>>>>> I added some debug messages
>>>>> and it seems that the kernel_recvmsg() in
>>>>> This is the only place I could find where the TCP messages are arriving in
>>>>> the usbip code.
>>>>> What happens if a message does not arrive? Does it stall forever?
>>> Yes, it will block until detached or until a TCP
>>> timeout or error closes the connection.
>>> The TCP timeout can take several minutes.
>> What I don't really understand is that how is it possible that
>> a packet from TCP communication is lost? TCP resends the lost
>> packets automatically. In my case I run both the usbip server
>> and client on the same machine using the host name "localhost".
>> So I assume that there might be a protocol handshake problem
> Agreed, it doesn't seem like a TCP error is
> causing the hang in this case.
More information about the devel