前回、初めてのマイニングリグを構築してみた。録画サーバで使うQSV機能に実績のあるZ170チップのマザーボードを選択したので、早速kickstartでCentOS7をインストールしてみる。kickstartの中で、自動でQSVパッチ済みのkernel4.4がインストールされる形になる。Z270チップのマザーボードだとkernel選択画面のあと、何の表示もないまま動作を停止してしまうという事態に陥った。こんな状態なので切り分けもほぼ出来ていないんだけど、他に思い当たるところもなく当たって砕けろ。
インストールが終わり、再起動されて、BIOSの表示、kernelの選択画面と続く。そして・・・無事起動！よかった。。。やはり現在のLinux用QSVパッチはZ270チップセットでは動かないのかもしれない。マザーボードは1つしか試していないので、ASUS ROG STRIX Z270Fそのものの問題の可能性もあるけど。ともあれ、どうしようもなかったOS起動不能問題を突破したので、やっと話を次に進められそうだ。Z170チップセットに関しては２種類のマザーボードで起動を確認しました。
続く問題がQSVとGeForceの共存。この構成を扱うのは随分久々なんだけど、以前ハードウェアエンコードの検証を行うときもGeForceを刺すと、QSVが動作しなかったような記憶がうっすらある。そのときはそれぞれを排他の選択肢で扱っていたので問題なかったが、今回は両者を共存させる必要がある。マイニングをやり出せばわかると思うんだけど、ビデオカードは出来る限りマイニングに時間を割きたいので、ハードウェアエンコーディングはCPU(QSV)に任せてしまいたい。
by パソコン(PC)通販のドスパラ |
QSVの機能が追加されたCentOS7にGeForceのビデオカードを刺してNVIDIAのドライバをインストールする。この段階ではvainfoお通るし、h264_qsvでのffmpegも出来る。しかし、再起動を行うとvainfoが通らなくなってしまう。QSV用のキャラクターデバイスが/dev/dri/renderD128でなければいけないのに、GeForceにそれを奪われて/dev/dri/renderD129になってしまうためだとわかる。キャラクターデバイスを明示指定してvainfo出来れば動きそうなんだけどね。
ダメ元でffmpegを動かすと、何とh264_qsvでのエンコードが出来てしまった。標準出力をよく見てみると、h264_qsvでのエンコードはキャラクターデバイスが見つからない場合にリトライして、次のキャラクターデバイスを参照してくれていた。つまり/dev/dri/renderD128でなければ/dev/dri/renderD129を試してくれるのだ。vainfoが通らないのもデバイス違いなだけなので、これで共存が問題ないことがわかった。6台までGeforceを増やしていったが、特に問題はなかった。
それから数日経過したある日、再起動作業後に突然ffmpegのh264_qsvが動かなくなってしまう。標準出力をよくよく見てみると、デバイス探索のリトライを3回で諦めてしまい、どうやらそれ以降にあるQSVのキャラクターデバイスに辿り着けないようだ。むしろ何故今まで動いていたのか不思議な状況。何となく動いていた今までが幸運なだけだったのかも。どうやらこのキャラクターデバイスの干渉は避けては通れない問題のようだ。
既に問題点ははっきりしている。とにかくQSV用のキャラクターデバイスがrenderD128になってくれればよい。NVIDIAのドライバをアンインストールすると、render128〜133が消えて、renderD134のみが残る。これがQSV用デバイスのようだ。この状態であればvainfoも通るし、h264_qsvのffmpegも可能。ドライバをインストールして再起動すると、また動かなくなってしまう。nvidiaというkernelモジュールをrmmodするとデバイスたちは消えてくれるが、insmodするとまた戻る。まあ、そうだよなあ。
![[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]](https://hbb.afl.rakuten.co.jp/hgb/0b76fcdf.2721b094.0b76fce0.430c1655/?me_id=1206032&item_id=11508859&m=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fjism%2Fcabinet%2F0584%2F4537694237390.jpg%3F_ex%3D80x80&pc=https%3A%2F%2Fthumbnail.image.rakuten.co.jp%2F%400_mall%2Fjism%2Fcabinet%2F0584%2F4537694237390.jpg%3F_ex%3D240x240&s=240x240&t=picttext "[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]")
ZT-P10800C-10P ZOTAC PCI-Express 3.0 x16対応 グラフィックスボードZOTAC GeForce GTX 1080 AMP Edition [ZTP10800C10P]【返品種別B】【送料無料】
|
udev辺りを使って任意のキャラクターデバイスへのマップを明示するか、あるいはkernel起動時にQSV用のi915モジュールを先に認識させるか。うん？kernelモジュールの読み込み順なら明示指定する方法があった気がするな。ぐぐってみるとrdloaddriverというパラメータを使って、kernelモジュールの読み込み順を明示指定できるらしい。よしよし。試しに『rdloaddriver=i915 rdloaddriver=nvidia』という設定をkernelパラメータに加えて再起動してみる。
vi /etc/default/grub
:
GRUB_CMDLINE_LINUX="rdloaddriver=i915 rdloaddriver=nvidia crashkernel=auto rhgb quiet"
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
これでQSVデバイスがrenderD128になった！素晴らしい！！当たり前だけど、vainfoも通るようになったし、h264_qsvのffmpegも実行可能。おっしゃあ。ZCashやEthereumのマイニングも問題なく動作したので、晴れて録画サーバとマイニングサーバの共存が出来るようになりました。録画サーバ上でのマイニングということでノイズが出たりしないかなと不安だったけど、それもまったく問題なし。がっつりマイニングしつつテレビ録画もこなしてくれます。やったね。