VirtualBox 6.0.14のdkmsがLinux kernel 5.4の仕様変更でbuildできない (VBox 6.1で対応)

*** update ***

2020-01-21更新: Linux kernel 5.4.13 (1/21現在5.4.x系列の最新版)を試している。既にVBox側で対応済みなため、特に問題なくkernel modulesをbuild、使用できている。

*** updateここまで ***


Linux kernel 5.4からset_pages_x()とset_pages_nx()というfunctionsが削除された。

Debian unstableに入っているVirtualBox 6.0.14はこの変更に対応しておらず、現状ではkernel moduleがbuildできずにerrorになる。

VBoxのdevelopersは既に対応するpatchを作製済みで、6.1RC1としてreleaseしている (cf. [#18945 (Linux 5.4: no more arbitrary executable pages and more changes) – Oracle VM VirtualBox](https://www.virtualbox.org/ticket/18945))。

何れDebian unstableかexperimentalに入るだろう。 2020-01-21現在sidに6.1が入っている。

Linux kernel 5.4 seriesにはi915でgpu resetがtimeoutしてin-flight renderingが止まる問題もあるので、当面は5.3で運用する予定。 2020-01-21現在、5.4.13で特に問題がなさそうなのでこのまま移行できそう。

Linux kernel 5.4.1でgpu resetがtimeoutしてXの画面が止まる (1/22: 5.4.13でも発生 → 1/24: 5.5-rc7で解決か)

*** update ***

2020-01-21追記: 5.3系列がEOLっぽいので5.4.13を試してみているが、rebootから2hrsぐらい経過して特に問題なく使えている。少なくとも"Resetting rcs0"は出ていない。

2020-01-22追記: 気付いたら止まっていた……5.5-rc7をテスト中。

2020-01-24追記: 2日以上安定して使えているので5.5-rc7に移行する。

*** updateここまで ***


5.3.10の時点で既に出ていた症状だが、5.4.1にversionが上がって改善されるかなと思いきや、freezeしたまま延々とerror messageがsyslogに吐かれている状況で寧ろ悪化している？

syslogに残っていたerror messagesはこんな感じ (この時のkernelは5.4.0):

Dec  1 00:00:06 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:08 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:10 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:12 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:14 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:16 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Dec  1 00:00:18 kernel: i915 0000:00:02.0: GPU recovery timed out, cancelling all in-flight rendering.
Dec  1 00:00:18 kernel: i915 0000:00:02.0: Resetting chip for hang on rcs0

中途半端に止まったり (resetによって)動いたりを繰り返すよりは、いっそ止まって使えないというはっきりした状態の方がマシという考え方もあるが。

5.4.0では普通に使えているので取り敢えず様子見。
5.4.0でも止まったので、5.3.14に戻して暫く使ってみる。Debian unstableのVirtualBox (6.0.14-dsfg-3)だとkernelの仕様変更で5.4に対応できていないのもあるので。

(12/4追記) 5.3.14でも時々画面のrenderingが止まるが、数秒後に回復する。その時のsyslog:

Dec  4 03:16:10 kernel: i915 0000:00:02.0: Resetting rcs0 for hang on rcs0

resetが掛かった後5.3だと復帰するけど、5.4では復帰できずにin-flight renderingが停止する。5.4で変更された中に何かあるようだ。

Linux kernel 5.0がrelaseされたのでupgrade

Linux kernel 4.20.13 → 5.0へupgrade。

Phronixが行っているbenchmark testによれば、Linux 5.0は4.20.x比で性能が低下しているとのこと。Spectre/Meltdown対策が主な要因のようだ。そう言えば最近SPOILERなんて新顔も報告されている。

cf. [Linux 5.0 Kernel Performance Is Sliding In The Wrong Direction - Phoronix](https://www.phoronix.com/scan.php?page=article&item=linux-50-sliding&num=1)

なお、最新のLTSは4.19.x series (ちなみにRaspbianも最新版は4.14.x seriesから4.19.xに移っている)。

cf. [LKML: Linus Torvalds: Linux 5.0](https://lkml.org/lkml/2019/3/3/236)

Linux kernel 4.16.5でRealtekのUSB SD/MMC card readerを使う

以前は普通に使えていた気がするのだが、いつの間にやらSD cardを挿入しても認識しなくなっていた (`/dev/mmcblk0p1`のようなdevice fileが作られない)ので、原因を調べてみた。

結論から言うと、必要なdevice driversが組み込まれていなかったのが原因だった。

環境

* ASUS X200LA
* Debian GNU/Linux (amd64, sid)
* Linux kernel 4.16.5
* Realtek RTS5129 card reader controller

実際の手順

何を探せばいい？

`lsusb`を使うと実際に使えるかどうかは別として接続されている (認識している？)devicesを表示してくれるので、それを元にしてkernelに組み込むべきdevice driver(s)を探せばいい。

今回の場合は:

% lsusb
...
Realtek Semiconductor Corp. RTS5129 Card Reader Controller
...

RealtekのRTS5129というdeviceに対するdriverを探す。

対応しているdriverやmoduleは？

kernelを自前でbuildしているので、取り敢えず`make menuconfig`を使い、それっぽいoptionがないかを探してみる。"realtek"で検索してみたところ、それっぽいoptionが見付かった:

`MMC_REALTEK_USB` ("Device Drivers" → "MMC/SD/SDIO card support" → "Realtek USB SD/MMC Card Interface Driver") = `rtsx_usb_sdmmc`

そのまんまな名前だ。helpにもそれっぽいことが書かれているので試してみる価値はあると思ったのだが、なぜかmenuに表示されておらず、故にy/mで選択もできない。その原因は依存関係が満たされていないためだった:

`MISC_RTSX_USB` ("Device Drivers" → "Misc devices" → "Realtek USB card reader") = `rtsx_usb`

このoptionをy/m何れかに設定すると、`MMC_REALTEK_USB`を選択する項目が表示されこちらもy/m何れか選択できるようになる。

動作確認

Kernelをrebuildしてinstall、rebootした後に、SD cardを差し込んで認識されることを確認。`lsmod`でも見てみる:

% lsmod | rg mmc
mmc_block
rtsx_usb_sdmmc
mmc_core
rtsx_usb

Debian sid/experimentalのgcc-6/gcc-7でLinux kernelがbuildできない問題とその対応

Linux kernel 4.10.1がreleaseされたのでbuildしようとしたら……

>   LD      vmlinux
> kernel/built-in.o: In function `update_wall_time':
> (.text+0x5fa0a): undefined reference to `____ilog2_NaN'
> Makefile:969: recipe for target 'vmlinux' failed
> make[1]: *** [vmlinux] Error 1

つい数日前 (2/20)はbuildできた4.10.0もダメだった (@gcc-6, gcc-7)。

`/var/log/aptitude`を確認してみた所、Sidのgcc-6 (6.3.0-8)を2/22に、experimentalのgcc-7 (7-20170221-1)を2/24にそれぞれ更新していた。

"linux ____ilog2_nan"でGoogle検索したら、次のpageを発見:

詳しくはよく分からないが、Linux kernel内部で利用されている`ilog2()`をcompileする際にGCCのtree-optimizationで問題が発生している模様 (cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785)。どうやらkernel側のbugっぽい。

既にworkaroundがあり`include/linux/log2.h`へのpatch (cf. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/462224.html)を当てた所buildできた。

Debian unstableのgcc-6 6.2.0-7以降でLinux kernelなどのbuildができない件への対処 (2016-12-03更新)

Debian unstableのgcc-6は、6.2.0-7から--enable-default-pieというflag付きでbuildされており、これがあちこちで問題を引き起こしている。

cf. https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=gcc-6

影響を受けているのはLinux kernelやSeaBIOSなど。

今の所backoutされる予定はなさそうなので、upstream (kernel側)で対応する迄は以下のworkaroundで我慢するか、自前でgcc-6 (6.2.0-6)をbuildするしかない。

Linux kernelのbuild

(2016-12-03追記)

Linux kernel 4.8.11でDebianのGCCで行われた変更に対応した。よって、それ以降のversionを利用する場合以下のworkaroundは不要。

stack protectorをenableにしていると:

> -fstack-protector not supported by compiler

と出てbuildが止まったり、そうでなくても:

> error: code model kernel does not support PIC mode

と出てbuildが止まったりする。

何れも、KCPPFLAGS=-fno-picをmake-kpkgあたりに渡してbuildするというworkaroundが紹介されている (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841533)。

著者の環境ではworkaroundによりmake-kpkgでkernelがbuildできた。

ccache userへ

FirefoxやEmacsのbuildにも影響が出た。

一旦、ccache -C -zでcacheを破棄してrebuildすると良い。

ZoL (ZFS on Linux)

(2016-10-28追記)

ZoLはkernel modulesとしてbuildする関係から、もろにこの変更の影響を受ける。しかも、KCPPFLAGS=-fno-picを渡しても./configure scriptが途中でコケる。

(2016-12-03追記)

SPLもZFSも正常にbuildできるようになった。

それがGCC側の変更なのか、kernel sourceのupgradeの結果なのかは切り分けられなかった。