先日買ったLogitecのHDDケース(ビデオ用)が僕のPCや別の外付けHDD(バックアップ用)と相性が悪いようで、USB3では まともに繋げられないことが分かった。もちろん、そもそも、ビデオは観ないので気にする必要はなく、そのまま「そういうものだ」と目をつぶって忘却の彼方に放り出せばいいのだが、それはできない相談だw 随分試行錯誤して、原因に関係ありそうなことが分かって対処ができ、今は無事USB3で繋がるようになった。

環境

  • マザーボード: ASUS P8H67-V
    • USB3のコントローラ: ASMedia ASM1042
  • HDDケース
    • Logitec LGB-EKU3 (= LHR-EKWU3BK)
    • センチュリー 裸族のインテリジェントビル5Bay CRIB535EU3
  • OS: Linux Mint 20 Xfce

現象

  • LogitecのHDDケースに入れたHDDとセンチュリーのケースに入れたHDDをASMediaのUSB3ポートに繋いで同時に電源を入れると、片方(ほとんどはLogitec)が認識されないことが多い。
    • 認識されない場合、Logitecの電源はoff(ランプが消灯)になる。
    • 片方ずつ電源を入れた場合はほとんど問題ない。
      • ただし、センチュリーのケースはタイミングによっては起動しないことがある(offにした直後にonすると、まず駄目)。
      • Logitecもたまに駄目なことがある。
  • 認識されなかった場合、lsusbコマンドでも表示されない。
  • 認識されなかった場合でも、問題のドライブのUSBコネクタを抜き挿しすれば直る。

原因に関係ありそうなこと

  • ドライブを接続した場合、システムのログ(syslog)には、USBのconfig error(詳細は不明)が出ることが多い。
  • センチュリーのケースは一旦High Speedで認識され、すぐに切断されてSuper Speedになることが多い。
    • ただし、上の2つの現象が起こっても正常に認識されることもある。
  • 以下は推測
    • センチュリーのケースの電源が経年劣化で弱くなっていて、電源投入直後の動作が不安定。
      • 仕様上は電源の容量は足りている(HDDの起動時の消費電流を概算で確認した)。
    • Logitecのケースの自動電源オフ機能がせっかち過ぎて、アイドル(USBプロトコル的に非接続)状態だとすぐにoffになってしまう。
      • この状態になると、PCに繋がっていないのと同じなので、電源off/onや抜き挿しする以外は何もできない。
    • ASM1042が古く、USB3対応が怪しい。
    • 同様に、マザーボードも古く、BIOSのUSB3対応が怪しい。
    • 同様に、LinuxのASM1042ドライバが怪しい。

関係なかったこと・試さなかったこと

  • UAS(USB Attached SCSI)が問題になるという情報があったが、どうもASM1042(またはLinuxのドライバ)は対応していないようで(ログに非対応というメッセージ("usb 4-2: USB controller 0000:05:00.0 does not support streams, which are required by the UAS driver.")が出る)、UASを有効にしても無効にしても、現象には関係なかった。また、速度も変わらなかった。
    • ただ、非対応と出るので、念のために無効にしている。
    • 古い情報(2014)だが、LinuxではASM1042のUASはうまく動かないために、無効にするパッチが出ていたようだ。それが今はどうなっているかは不明(無効にはなっておらず、致命的な問題もないが、うまくも動かない)。
  • ドライブやケースが冷えていることは関係なかった(寒い朝に起動しても問題は起こらなかった)。逆に熱いほうが関係しているのだろうか? あるいは、純粋にタイミング的な問題で、温度には無関係なのかも知れない。
    • 今日の昼の比較的暖かい時に試したら問題なかったので、温度は関係なさそうだ。 (12/15 16:50)
  • BIOSのUSB関係の設定はいくら変えても関係なかった。
    • 意味が分からないものがほとんどで、マニュアルにも書いてないものがあり、手探りで試した。
  • 以下は試さず。
    • BIOSのファームウェアは最新なので、更新しようがなかった。
    • ASM1042のファームウェアは公式に配布されていないので、更新しようがなかった。
    • どちらかのドライブをUSB3のハブを介して接続すれば、あるいは、別のUSB3インタフェースボードを使えば直りそうな気がしたが、どちらも手持ちはないからお金が掛かるし、わざわざ古いPCに追加するのは馬鹿らしいので止めた。
    • センチュリーのケースの電源を交換したかったが、やっぱり手持ちはないので、壊れてからにすることにした。
    • 書いたあとで気になったが、どちらかあるいは両方のケーブルが悪いということはあるだろうか? まずないとは思うが、そういうオチもあるから怖い。

対処

  • 問題のドライブ(のUSBコネクタ)をソフト的に抜き挿ししてみたら、うまい具合に両方のHDDが認識されたので、処理を自動化するプログラムを作った(次項を参照)。
    • 検索したら いくつかの方法が見付かったが、USBコントローラを無効にしてから有効にするのが効果があった。 (→ 参照)
      • 具体的には、LinuxのUSBコントローラのunbindとbindという制御ファイルにコントローラのデバイスID(Linuxのデバイス関係にはいろいろな名前があるので、正しい呼び方は分からない)を書き込む。
        • 例(super userで実行):
          • dev_id="0000:05:00.0" (/sys/bus/pci/drivers/xhci_hcdの下にIDの名前のディレクトリがあるので、対象のものを探す)
          • 無効化: echo $dev_id > /sys/bus/pci/drivers/xhci_hcd/disable
          • 有効化: echo $dev_id > /sys/bus/pci/drivers/xhci_hcd/enable
      • この方法だと、そのコントローラに繋がっているすべてのデバイスが切り離されてしまうので、多くのデバイスを使っている場合は余り便利でない。(別のコントローラに繋がっているデバイスは全く問題ない)
    • 念のため、抜く前に、認識されてマウントされているディスクをumountすることにした。

ソフト

  • 問題発生の検出と対処を自動化するスクリプト(chk-usb3-mf.sh)を作った。
  • chk-usb3-mf.shは以下の処理を行う。 (概要)
    1. システムのログ(/var/log/syslog)にメッセージが記録されるたびにチェックし、問題に関係のあるイベント(下記)を抽出して、それぞれに対応する処理を行う。
      • USB config error (例: "usb usb4-port1: config error"): 処理に必要ではなく、参考のために抽出している。
      • Super Speedデバイスの認識 (例: "usb 4-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd"): それほど重要ではなく、参考のために抽出している。
      • High Speedデバイスの認識 (例: "usb 3-1: new high-speed USB device number 2 using xhci_hcd"): 処理に必要ではなく、参考のために抽出している。
      • SCSIデバイスの接続 (例: "sd 6:0:0:0: Attached scsi generic sg3 type 0")
        • なぜか、ディスクIDの先頭は"sd"の場合と"scsi"の場合があった。
      • ディスクのマウント (例: "Mounted /dev/sdd1 at /media/XXXX/VOLUME on behalf of uid YYYY"): 上のattachと比べてマウントには時間が掛かるので、今は参考程度にしか使っていない。
      • 周期タイマー(ログのイベントではない): タイムアウト処理のため、一定時間(2秒)ごとに起動する。
    2. SCSIデバイスが接続されたら、ディスク数を+1する。
    3. ディスク数が想定値(2)になったらOK(= 問題は起こらなかった)なので、タイマを停めて内部状態をリセットする。
    4. そうでない場合はタイマを起動する。
    5. タイマがタイムアウトした(前回のSuper Speedデバイスの認識から規定時間(6秒)以内にディスク数が想定値(2)にならなかった)場合、問題が発生したので、USBの再スキャン(USBコントローラの無効・有効化)処理を行う。
      1. 再スキャンを行うかのダイアログを出す。
      2. 回答が「行う」の場合は、以下を実行する。
        1. Super userの権限が必要なので、以下の処理をpkexecを使って行う。
        2. 認識されたディスクがマウントされていたらumountする。
          • タイミングによっては、問題を検出したときはドライブを認識だけしていて、この処理の直前にマウントされる場合があるので、ドライブのデバイス名が分かる場合は、エラーになってもいいのでumountするようにした。
        3. そのディスクのUSBコントローラ(= ASM1042)を無効にする。
        4. 少し(1秒)待つ。
        5. 無効にしたUSBコントローラを有効にする。
        6. 少し(1秒)待つ。: 不要と思われるが、念のために入れた。
      3. 内部状態をリセットする。

結果

  • 成功: おそらく10回以上試したが、問題の発生を確実に検出できてダイアログを表示し、そこで指定することでUSBデバイスの再スキャンを行って両方のドライブを認識できるようになった。

その他

  • 電源投入直後に比べ、コントローラの無効・有効後のドライブの認識はすごく速い。これが何か関係あるのかも知れない。
    • 単に、HDDなので電源on後に回転数が上がるのを待つ時間があるだけなのか?
  • ASM1042のSuper SpeedとHigh Speedは、仮想的に別のポートとして扱われている(LinuxではデバイスIDが異なる)。
  • 一度、ファイルマネージャ(Thunar)の動作がおかしくなった。Thunarのボリューム管理と本プログラムのumount処理が競合したと思われる。
  • 想定した数のドライブが接続されていることを前提にしているので、本当にドライブが少ない場合でも問題が起こったと認識してダイアログが出るのが今ひとつ。
    • ドライブが認識されていない状態ではドライブが繋がっているかどうかは分からないので、ドライブ数を自動で判別するのは難しい。
  • イベントのチェックや再スキャン処理の実行はもっとスマートな方法(udevを使う?)があると思うが、udevはなかなか手ごわいので、今回は見送った。
  • 本当はダイアログを出さずに自動的に再スキャンしたいが、無限に再スキャンし続けることがありそうなので、今は止めている。

 

これでめでたくLogitecのHDDケースもUSB3で繋げられるようになった。USB3になった効果としては、転送速度が約2倍(80MB/s前後)になった。とはいえ、何度も書いているように、このHDDを使うことはほとんどないので、あくまでも自己満足の世界であるw

ただ、USBポートのソフト的な抜き挿しは以前からやりたかった(何度も失敗していた)ので、用途は限定的ながらもその方法が分かったのは、収穫だ。

 

そして、(前に書いたが、)Logitecのケースについては、この処理に加えて、定期的にアクセスすることで自動電源オフ機能を実質無効化できたのと電源・アクセスランプを前面に付けたので、ようやくまったく普通に使えるようになった。いやぁ、全く面倒な奴だ・・・w

 

PS. デバッグや動作確認で何度もoff/onすると、いつかセンチュリーの電源が壊れそうで ひやひやしていたが、今はまだ大丈夫そうだ。でも、古いもの(2011年に購入)なので いつかは壊れる気がする。

  •  0
  •  0

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL