usbip: sometimes stalls at kernel_recvmsg()

Németh Márton nm127 at
Tue Dec 21 08:03:11 UTC 2010

Hello Max,
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
insmod /usr/src/linux/drivers/staging/usbip/usbip_common_mod.ko
insmod /usr/src/linux/drivers/staging/usbip/usbip.ko
usbip_bind_driver --list
usbip_bind_driver --usbip 3-2

On a second xterm window execute the following commands:
insmod /usr/src/linux/drivers/staging/usbip/vhci-hcd.ko
usbip --list localhost
usbip -a localhost 3-2
usbip -p
strace lsusb

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
>> here.
> Agreed, it doesn't seem like a TCP error is 
> causing the hang in this case.
> 	Max

More information about the devel mailing list