何度も旅行に行きましたが、lsusb戻ってくるまでに時間がかかりました。完了していないか遅い実行される理由がありますか？
私はkill彼らのPIDを見ましたが、役に立ちませんでした。したがって、実行中のgnome端末タブを閉じると、対応するttyは次のようになります?。
$ 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
私が正しいとしたら、Dプロセスが終了しているという意味ですか？なぜまだぶら下がっているのですか？
dmesg続けて教えてください
[384722.320066] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1 (repeated 77 times)
内蔵Wi-Fiアダプタが機能していないため、外部Wi-Fiアダプタを接続しました（やはり機能しません）。
答え1
私が正しい場合、Dはプロセスが終了していることを意味しますか？
いいえ、これはプロセスが進行中であることを意味します。邪魔されない睡眠。時々、「スリープ」がI / Oを待つカーネルの忙しいループである場合、これは非常に問題になる可能性があります。これらのプロセスはシステムをひざまずかせることができ、これについて私たちができることはありません。なぜなら、あなたはそれらを殺すことができないからです。。しかし、比較的受動的かもしれません（まだ殺すことはできませんが）。
その理由は、通常の状況では、このような状況が決して発生しないか、または長い間発生しないという事実に基づく妥協によるものです。これは、ハードウェア障害またはカーネル/ドライバのバグを示します。 「妥協」が行われ、システムが少ないエラーが発生しやすく（通常の状況では）、通常は問題になりません。アプリケーションがどんなに間違って書かれたとしても、エンドユーザーがどれほど愚かなのか、どんなに破壊しようとしても、できないそれを作成しなさい。これただこれは、ハードウェア障害またはカーネルエラーが原因で発生します。
つまり、この状況でこれらのプロセスを終了すると、通常の使用中に他の問題が発生するリスクが高くなります。したがって、そのようなことが発生した場合、できることが何もないというのは論理的な妥協案です。
答え2
lsusbUSB バスからハードウェア情報を読み取るには、システムコールを使用します。 USBバスが正しく設定されていないか、デバイスが応答できない場合、システムコールはタイムアウトするまでブロックされます。 USBデバイスを一度に1つずつ接続し、lsusb毎回コマンドを実行して、どのデバイス（またはデバイスの組み合わせ）が問題を引き起こしているかを調べる必要があります。
中断のないシステムコール中はシグナルがブロックされるため、プロセスを終了（SIGKILL転送）したり、端末を閉じても（SIGHUP転送）プロセスは終了しません。中断できないシステムコールでプロセスが無期限にブロックされると、lsusb実際にプロセスを終了する方法はありません。