動作環境
システム概要
- ホストOS: Debian GNU/Linux 12 (Bookworm)
- カーネルバージョン: 6.8.12-11-pve
ハードウェア詳細
- CPU: AMD Ryzen 7 4700U with Radeon Graphics
- メモリ: 16 GB
- ストレージ: Samsung MZALQ512HALU-000L2 (NVMe SSD)
- NIC: Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet (tp-link UE300)
問題の概要
https://qiita.com/shota0711tane/items/2c4f040ed1ef30a9f3a3 にて説明している通り、中古PCを用いて自宅にProxmox VEが動くサーバー環境を作っている。導入にあたって、初期設定までは難なく進めた。
しかし、仮想マシンのためのISOをProxmox上にダウンロードするところで毎回接続が遮断され、再起動するまで接続ができなくなるという問題が起きていた。具体的には、ISOのダウンロード処理中にGUI上にError '0' occured while receiving the doumentというポップアップが出現し、Proxmox側では以下に記載しているようなログが見られた。
......
r8152 2-2:1.0 enx00e04c133180: NETDEV WATCHDOG: CPU: 7: transmit queue 0 timed out 5008 ms
r8152 2-2:1.0 enx00e04c133180: NETDEV WATCHDOG: CPU: 7: transmit queue 0 timed out 5253 ms
r8152 2-2:1.0 enx00e04c133180: Tx timeout
r8152-cfgselector 2-2: Failed to reset
xhci_hcd 0000:04:00.0: Error: Failed finding new dequeue state
xhci_hcd 0000:04:00.0: Failed to clear cancelled cached URB 00000000e6611b7b
usb 2-2: device descriptor read/8, error -110
r8152-cfgselector 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
r8152 2-2:1.0 enx00e04c133180: NETDEV WATCHDOG: CPU: 7: transmit queue 0 timed out 16045 ms
r8152 2-2:1.0 enx00e04c133180: Tx timeout
......
暫定対処 (ワークアラウンド)
本事象に対する暫定対処として、下記の記述を/etc/default/grubに追加することを採用した。
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.autosuspend=-1"
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT usbcore.quirks=0bda:8153:k"
/etc/default/grubはGRUBブートローダーに関する設定ファイルであり、GRUB_CMDLINE_LINUX_DEFAULTに設定された値はカーネルパラメーターとして起動時に渡される。
ここでautosuspendをグローバルに禁止する値と、今回通信に使用しているUSB NIC (0bda:8153:k) のLPMを禁止する値を渡している。この設定をしたのちに、Proxmoxを再起動すると、正しくISOのダウンロードが成功し、通信も安定化した。
autosuspendについて https://www.kernel.org/doc/Documentation/usb/power-management.txt では、USBデバイスがアイドル状態 (使用されていないとカーネルが判断した状態) になったときに、カーネルが自動的にデバイスを低電力状態 (非機能的なサスペンド状態、あるいは完全に電源が切れた状態) にするプロセスであると説明されている。LPMとはUSBポート間の接続を表すリンクの電源状態をU0-U3を用いて管理する仕組みのこと。USBの稼働状態を検知し管理することで、大幅な電力の節約を目指すものである (参考: https://learn.microsoft.com/ja-jp/windows-hardware/drivers/usbcon/usb-3-0-lpm-mechanism-) 。
このような解決方法については様々なコミュニティやissueで言及されているものであり、自身もそれらを参考にした。
- https://askubuntu.com/questions/1044127/usb-ethernet-adapter-realtek-r8153-keeps-disconnecting#:~:text=While%20writing%20the%20question%20I,and%20is%20done%20like%20so
- https://portal.cloudunboxed.net/knowledgebase/55/How-to-fix-Realtek-USB-NIC-TX-timeout-issues.html
問題の原因と解決方法の関係について
本件に関して同じ状況と言える問題についての議論が https://bugzilla.kernel.org/show_bug.cgi?id=198931 にて展開されていた。ここでの議論によると、Realtek RTL8152/RTL8153 ベースの USB Ethernet アダプターに関する問題の根本原因は、ドライバーのデータ競合、ファームウェアの不具合、または特定の USB ホストコントローラー (特に USB 3.0 以降) との非互換性が影響しているとのこと。
その中でワークアラウンドとしてautosuspendやLPMを無効化させる方法について言及がされているが、なぜこれらが有効かについては詳しく述べられていない。一方で、 USB NIC Scatter/Gather (SG) を無効化すること (ethtool -K enx... sg off) でも対応できたとの言及もある (ちなみに、自分の場合は効果がなかった) 。https://www.bilibili.com/opus/1022228673452834819?utm_source=chatgpt.com ではこのことについて、USBバス伝送の特殊性とr8152の実装により、SGを有効にしてしまうと高トラフィック時にドライバーのバグを誘発しやすくなってしまうと説明している。しかし、この記載も経験的な知識をもとにしたものであり、具体的な根拠やソースは記載されていなかった。
個人的には電源管理の問題とSGの問題がそれぞれ別個に同じ問題を引き起こしているというよりは、何かしら他に潜在的な問題があって、その問題に強く関係性のある2つの因子が電源管理とSGであり、どちらが潜在的な問題に対してより影響力のある因子になるのかは各々の動作環境に依存したものである......とかなんじゃないかなという感想を持っている。
まとめ
自身の環境において発生していたRTL8153＋r8152ドライバで発生するTx timeoutの問題は、autosuspendとUSBのLPMを無効化することによって対処できた。しかし、なぜこれらが有効なのかということについての根本的原因の詳細は未だ明らかになっていない (ご存知の方がいらっしゃればコメントなどで指摘していただけると幸いです) 。ただ、このような問題を根本的に解決するのであれば、USB NICは使用せずに、オンボードのNICなどを使用する方が好ましいと考えられる (自身は中古PCにWLANのNICしか搭載されておらず、ProxmoxではWLANは非推奨であったことから今回のような問題に頭を悩ますことになってしまったのだが) 。本問題の根本的な原因が明らかになることを待ちたい。
余談
これは余談なのだが、実は解決の糸口が見えず適当に試行錯誤をしているときに、該当のNICのmtuをデフォルトの1,500から9,000にしてみたら、ISOのダウンロードでは同問題が起きなくなり、全体的に通信も安定化した。これも結局のところなぜ効果があったのかよく分からないのだが、ジャンボフレームを有効化することによりUSB NIC側のオフロード機能によるフレーム処理の負担が軽減された可能性があったりしないかな......と思っており (上で紹介したSGを無効化する話とも関係しそうだし) 、これがまた別途潜在的な問題を対処する方法になり得たのかなという感想も持った (ネットワークあまり詳しくなくてよく分からないので現在は1,500に戻したが) 。ちなみに、この感想は https://internet.watch.impress.co.jp/docs/column/nettech/1088812.html を参考にした。