8

I'm running lsusb several times, but it's taking a long time to return. Is there a reason why it won't finish or that it runs slowly?

I've tried killing their PIDs but that doesn't work. So I close the gnome terminal tab where one is running, and its tty becomes ?:

$ ps aux | grep -i lsusb
t        13845  0.0  0.0  40000  3788 pts/21   D    14:59   0:00 lsusb
t        14216  0.0  0.0  40000  3812 pts/21   D+   15:06   0:00 lsusb
t        14236  0.0  0.0  40000  3792 ?        D    15:06   0:00 lsusb

If I am correct, D means the process is being killed? Why is it still hanging?

dmesg kept saying

[384722.320066] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1 (repeated 77 times)

My internal wireless network adapter doesn't work, so I plug in an external one (which doesn't work either).

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Tim
  • 101,790

2 Answers2

6

If I am correct, D means the process is being killed?

Nope, it means the process is in an uninterruptible sleep. Sometimes this can be very problematic if the "sleep" is the kernel busy loop waiting on I/O; such processes can grind the system to a halt and there is not much that can be done, because you cannot kill them. However, it may also be relatively passive (although you still can't kill them).

The reason for this is a sort of compromise based on the fact that under normal circumstances this should never happen, or never happen for a significant period of time. It indicates either malfunctioning hardware, or possibly a kernel/driver bug. The "compromise" is that doing things this way makes the system less prone to error (under normal circumstances), and it is generally not a problem because an application, no matter how badly written, or a silly end user, no matter how hell bent on destruction, cannot create it. The only way it can happen is because of hardware failure or kernel bugs.

Put another way, making it possible to kill such a process in such circumstances would, as a consequence, create a greater risk of other problems during normal use. So the fact that you can't do anything about it when it does happen is a logical trade-off.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
  • Thanks. How can I kill the lsusb processes? – Tim Apr 20 '15 at 19:54
  • You can't unless they exit from the uninterpretable syscall which blocks them. This syscall is kernel code (or most probaly kernel object code, i.e. the EHCI driver, but it makes little difference really), and you can't terminate a part of the kernel. – Dmitry Grigoryev Apr 20 '15 at 20:05
  • Yeah, you can't. I've edited more of an explanation of why this "compromise" exists. – goldilocks Apr 20 '15 at 20:09
3

lsusb uses syscalls to read hardware information from the USB bus. If your USB bus is not configured correctly or there is a device which won't reply, the syscall will block until timeout. Perhaps you should plug one USB device at a time and issue lsusb command each time to find out which device (or combination of devices) is causing trouble.

Signals are blocked during uninterruptible syscalls that's why killing the process (sending SIGKILL) or closing its terminal (sending SIGHUP) does not terminate the process. If lsusb process blocks indefinitely in a non-interruptible syscall, there is effectively no way to kill it.

Dmitry Grigoryev
  • 7,313
  • 1
    Syscalls are not necessarily uninterruptable, but they may be. – goldilocks Apr 20 '15 at 19:39
  • Without in-depth analysis we can reasonably suppose there is at least one uninterpretable syscall that lsusb uses. The actual time lsusb takes to complete most probably depends on USB host driver implementation (how long does it wait for a reply, how many times it will retry etc.) – Dmitry Grigoryev Apr 20 '15 at 19:46
  • 2
    I was not trying to say you are wrong (+1) -- I'm also sure an uninterruptible syscall is the issue -- I was just trying to point out that the "Signals are blocked during syscalls" shouldn't be phrased so unequivocally, because many/most system calls are interruptible by signals. – goldilocks Apr 20 '15 at 19:49