ある日の環境構築

まとめ

　linuxで，Radeon(HD5850)+xf86-video-atiでKMSが有効な状態でstartxを実行すると画面が真っ暗になって落ちる，そういうときは，カーネルパラメータにradeon.dpm=0を指定すると解決する場合がある．

ポエム

　ある日のこと，メインの開発機のArchでyaourt -Syuでアップデートを行った後，dlangで書いている自前のプロジェクトのビルドを終え，実行したところ以下のエラーが出た．

GLまわりのエラーのようなので，とりあえず可能性として以下の原因が思い浮かんだ．

  • グラフィックドライバまわりのエラー
  • glfwのライブラリのリンクまわりの不具合

　出力の前半にDRIまわりの警告があったため，まず，グラフィックドライバについて調べた．この環境では，プロプライエタリのcatalyst-testをドライバとして使用している．導入の際，要求される他のパッケージやデーモンの設定等で苦労した記憶があるため，このあたりが怪しいと判断した．そこで，オープンソースドライバであるxf86-video-atiによるcatalyst-testの置き換えを試みたが，パッケージの依存性の解決が難しそうだったため，予備として用意していた，グラフィックドライバやxorgを導入する前まで設定を済ませておいた別のパーティションのArchlinuxで，オープンソースドライバのxf86-video-atiを用いた新しい環境を立ち上げることにした．

　ところで，今回問題が発生したメインの環境でcatalyst-testを使用していたのは，最初の環境構築の際に，他のドライバの，catalyst，xf86-video-atiでは上手くRadeon HD5850が動作しなかったためであり，また，今のcatalyst-testの導入後に何度か他のドライバでの動作を試みたが全て失敗していた．そのため，今回の試みも正直ダメな予感がしていた．

　さて，さっそく新しい環境を整える．まずは，arch wikiにある通り，カーネルパラメータにnomodesetを設定してKMSを無効化，xf86-video-atiを入れる．ここまでは順調だが，その後，KMSを有効にした状態でstartxによりXWindowを立ち上げると，スクリーンに何も表示されなくなる（情弱感）．また，キーボードのcaps lockのランプも，普段は切り替えを行うと点滅するのだが，その反応もなくなってしまう．これまで何度か試みた際もこの挙動が原因でドライバの導入を諦めており，フォーラムを覗いても同様の症状のスレッドはxorg.cfgまわりに原因があるものばかりで，XWindowまわりが怪しいんだろうなーと予想していた．ところが，生成されたXorg.0.logを眺めていると，どうやらnomodesetでKMSが無効になった状態で起動を試みていることを示すメッセージを見つけた．これはnomodesetが指定されていた時に誤ってstartxを実行してしまった時のログであり，タイムスタンプを確認すると，KMSが有効な状態での起動に失敗する以前のものだった．つまり，それが上書きされずに残っている，ということは，startxのログが生成される以前で何らかの障害が発生している，あるいは，startxの処理の中でエラーログが生成されないような派手な落ち方をしている，この2つに原因を絞り込むことができる．そもそも，linuxではシステムがいきなり停止するような場合，ハードウェアに原因があることが多く，また，上で書いたcaps lockのランプが反応しなくなるのも，システムがコケていることを示し，startx後に画面に何も表示されなくなった際にハードに近い部分が不具合を引き起こしている説を補強する．

　そこで，カーネルパラメータまわりについてフォーラムを検索したところ，radeon.dpmについて設定すると上手く起動する，とのポストを見つけた．このオプションは，"Dynamic Power Management"と呼ばれるGPUの使用率にあわせて動的に周波数と電圧を変更する機能についてのもので，radeon.dpm=0を設定するとあっさり動いた．最初にxf86-video-atiの導入を試してから2年近くが経過していており，正直なんともいえない気持ちになった．あと，余談だが最新のcatalystでcatalyst-testを置き換えるのも依存が大変なことになったが成功した．ただ，プロプラなので更新が遅く，さらに最近のオープンソースドライバも熟成してきたので，個人的にはxf86-video-atiの方に分があると思う．

　無事に念願のドライバが導入できたところで，そもそもの今回の環境構築のきっかけを思い出したい．それは，自前のプロジェクトが実行時にグラフィック回りの警告とエラーが出た，というものであった．この新しい環境でコンパイラや依存ライブラリを整え，実行すると，警告は消えたが同じエラーが表示された．どうやら，グラフィックドライバとは別の，もうひとつの可能性であるglfwまわりについても考えねばならないらしい．ところが，こちらはドライバの問題よりずっとスムーズに解決したので，事の顛末は以下のツイートをもって代えさせていただきたい．

これと同様の対応を元々の環境で行ったが，エラーは表示されず上手く動いた．早急にこのPRがmergeされることを祈る．

結局のところ，問題を解決するために新規に開発環境を立ち上げる必要は無かった，という話です．