FedoraではkernelのテストイベントとかGnome 3.34 Test Day、I18N Test Day などのテストイベントがちょくちょくあります。 今回はKernel 5.3 Test Weekの備忘録です。ちなみに、この手のイベントはfedora MAGAZINEで紹介されることがあります。
今回の参加結果の最終成果はこちらです。
参加ε≡≡ﾍ( ´Д`)ﾉ
今回のtest weekは開催時期が９月末から10月の最初の週でちょうどfedora 31のリリースが近かったころです。当時のfedora 29と30はカーネルは5.2系が使われていて、fedora 31が5.3系って感じでした。メインラインは5.4のrc1が出てた辺りです。それでfedora 31もそろそろ出るし、ベータとかrcのテストも参加してなかったし、メインラインのカーネルも最近使ってないなーなんてことでテストに参加しとくかーって感じで参加したわけです。
バグ発見／(^o^)＼
テストに使うカーネルのrpmをデスクトップ環境のfedora 30マシンにインストールして再起動すると、本来GDMのログイン画面がでるところでスクリーンがブリンクし続ける状態でした。一応メインラインのカーネル（5.4-rc1）も試してみたけど結果は同じでした。ここまでで5.3〜で症状が出るらしいってことは確定。というわけでここまでの内容で一旦bugzillaにバグレポートしました。
1758831 – GDM login screen doesn't show up on kernel 5.3.2
その後ですが、じゃあ、fedora 31ならどうよ？と思ってテスト用にビルドされたライブデスクトップのisoイメージを使ってみたところこちらも同様の現象。ただブートメニューからTroubleshooting" -> "Start kernel in basic graphic mode"を選ぶと問題なし。間違いなくGPU関連のバグですねって感じです。この情報もbugzillaに追記しました。
debug🐝
一応ここまででバグを見つけた人として一応のことはしたのですが、自分のPCで新しいカーネルが使えないのは最高に困るのでここからはbisectして原因を探りました。バグに当たっている人がテスト時点では自分くらいしかいなかったし、他のディストリビューションを見てもArch Linuxで同じような現象の人が1人くらいいたかなーって感じでした。そうするとバグは機種依存っぽいし自分でデバッグしたほうが良さげだったんですね。
ということでbisectを開始したわけですがバグが実機じゃないと再現できないのでダラダラやりつつ土曜日の朝から夕方まで使った気がします。そして、first bad commitは36a0f92020dc8794d3aa69b7fb4c5d2bf99b0099というのがわかりました。ちなみにこのpatchは一連のシリーズの中の一つなのと、このコミット以降でリファクタリングされていてファイルのパスやヘルパー関数が追加されています。さて、差分ですがpatchだけ見るとわかりにくいので自分の環境で動かなくなった原因のsanitize_aux_ch()より主要部分のbefore/afterを示すとこうなります。
before
const struct ddi_vbt_port_info *info = &dev_priv->vbt.ddi_port_info[port]; for (p = PORT_A; p < I915_MAX_PORTS; p++) { struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p]; if (p == port || !i->present || info->alternate_aux_channel != i->alternate_aux_channel) continue; i->supports_dp = false; i->alternate_aux_channel = 0; }
after
struct ddi_vbt_port_info *info = &dev_priv->vbt.ddi_port_info[port]; for (p = PORT_A; p < I915_MAX_PORTS; p++) { struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p]; if (p == port || !i->present || info->alternate_aux_channel != i->alternate_aux_channel) continue; info->supports_dp = false; info->alternate_aux_channel = 0; }
大きな違いはfor文中のif文でcontinueしなかった場合に使用している変数です。変更前は配列のp番目の要素をiにセットしてその変数の構造体のデータに値を設定していますが、変更後の方は最初にinfoに設定した値をそのまま使っていてp番目の要素に対する変更は行っていません。そんなわけで、変更前と同様の挙動にしたらどう？と思って作ったのが以下の修正です。
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c index efb39f350b19..c886dae82aa7 100644 --- a/drivers/gpu/drm/i915/display/intel_bios.c +++ b/drivers/gpu/drm/i915/display/intel_bios.c @@ -1313,6 +1313,8 @@ static void sanitize_aux_ch(struct drm_i915_private *dev_priv, p = get_port_by_aux_ch(dev_priv, info->alternate_aux_channel); if (p != PORT_NONE) { + info = &dev_priv->vbt.ddi_port_info[p]; + DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as port %c, " "disabling port %c DP support\n", port_name(port), info->alternate_aux_channel, @@ -1330,6 +1332,7 @@ static void sanitize_aux_ch(struct drm_i915_private *dev_priv, info->supports_dp = false; info->alternate_aux_channel = 0; } + } static const u8 cnp_ddc_pin_map[] = {
このpatchをstableの5.3.2に当てたところちゃんと動くようになりましたﾜｰｲヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉﾜｰｲ これでとりあえず自分の環境では新しいカーネルでもなんとか動くようになったわけですが、ローカルパッチを当て続けるとかあり得ないですね。なので次はupstreamへの報告となります。
36a0f92020dc8794d3aa69b7fb4c5d2bf99b0099を見るとsanitize_ddc_pin()も同じような変更が入ってるのですが、こちらは自分の環境では影響出てなかったです。GPUわからん😨
freedesktop.orgのbugzillaに苦戦😭
upstreamにバグ報告と言っても報告先として考えられるのはlkml、サブシステムのメーリングリスト、kernelのbugzilla、またはそれ以外とあります。GPU(i915)のバグ報告先をさがしたところ↓が見つかりました。ここにレポートの仕方が書かれていたのでまずはそれに従います。drm-tipツリーをcloneしてきてこのツリーの最新コードを試したり。。
バグのレポートはfreedesktop.orgのbugzillaを使うということだったのでアカウントを作りました。そしていざレポートってところで色々書いてsubmitボタンを押すと空白ページになるだけでバグが登録できません😨 たまたまバグったのかな？と思ってもう一度試してもダメ、じゃあ時間を置いてと思って次の日に試してもダメ。。。バグ報告したいのにバグ報告できないというバグにハマったわけです＼(^o^)／ｵﾜﾀ こんなのわからんよと思ってbugzillaについて聞けるところはないかな？と探したところircで聞けるというのがわかったのでircクライアントをインストールし、freenodeにある#freedesktopに入って状況説明したところ中の人がログを確認したりデバッグを手伝ってくれました。このときのバグレポートはfedoraと同じ感じで書いていたのでタイトルにloginという単語が入っていたのですが、これがバグの原因というのがわかりました。だいたい2時間位色々と試したんじゃないかな。。 ちなみにLoginだと大丈夫で小文字のloginという文字列がバグレポートの新規作成時に入っているとダメという状況でした。既存のバグレポートの編集時だと大丈夫という謎。 それはともかく、手伝ってくれた方には感謝しかありません👃
upstreamへの報告
なんだかんだで無事に報告できました。タイトルについてるbisectedというのはbisect結果を貼ったあとに変更されました。ちゃんと見てくれてますね(￣ー￣)ｂｸﾞｯ!
111966 – [bisected] GDM Login screen doesn't show up on kernel 5.3 or later
まず普通にバグの報告したあとでbisectの結果やquick hackなパッチをレポートしました。その後、同じような現象の人が現れ、この方も自分が作ったパッチでバグが直ったという報告をしてくれました👃 その後のちゃんとしたパッチの作成までは結構速く進み、コミット36a0f92020dc8794d3aa69b7fb4c5d2bf99b0099の設定方法だとダメな機種があるということでコメント等適切に直したパッチが作成されました。自分ともう一人の方はこのパッチをテストして動くのを確認しました。
修正方法は自分がやった方法と同じなので自分のパッチも暫定修正とはいえ正しい修正方法にたどり着けててエライって感じです😃
サブシステムへの取り込み -> mainlineへの取り込み -> stable treeへの取り込み待ち
修正パッチがサブシステムのメーリングリストに投げられたのであとは次の3個の待ちとなります。とくに自分がすることはありません。
- サブシステムのtreeへの取り込み
- mainlineへの取り込み
- stable treeへの取り込み
3のときに Patch "drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin" has been added to the 5.3-stable tree ってメールが届いて5.3.8（5.3.7はすでにリリースされてたので次は5.3.8のときだった）にパッチが入るんだなーってのがわかりました。
freedesktop.orgのbugzillaは1か2のタイミングでcloseされたと思います。
fedoraへの取り込み待ち
新しいstable releaseが出れば fedoraのカーネルが最新のstable releaseに追従したときにfedoraのカーネルでもバグが直ります。なのでこちらも待ちです(-_-)zzz fedoraのパッケージは最初updates-testingというリポジトリにアップロードされます。そこで人間がテストするか一定期間経てばupdatesリポジトリにパッケージが入ります。で、fedoraにカーネル5.3.8のパッケージがアップロードされたので早速テストして結果を書きました。
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0e85bbd15b
あと、fedoraのbugzillaのほうにも5.3.8のカーネルパッケージで直ったという報告を書いておきました。で、こちらもクローズとなりました。
終わり
というわけでkernel test weekへの参加とバグ発見、bisectとローカルパッチの作成、upstreamへの報告とupstreamへの協力、fedoraでの修正確認ということを最近しました( ´ー｀)ﾌｩｰ．．． 今回一番難しかったのはbugzillaでバグ報告できない問題でしたね。自分の環境で動かせられないし／(^o^)＼
超例解Linuxカーネルプログラミング~最先端Linuxカーネルの修正コードから学ぶソフトウェア品質~
- 作者: 平田豊
- 出版社/メーカー: シーアンドアールケンキュウジョ
- 発売日: 2019/07/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
