Some of you will know that my computer has a problem booting with recent kernels. There is a memory mapping glitch which causes a kernel panic at boot unless acpi is switched off. For Crux and LFS, which use self-built kernels, I patch the source to correct this. However in Debian Stretch, I use their stock LTS 4.9 binary kernel.

A couple of days ago, I did an update which included a new kernel image 4.9.0-8 (replacing 4.9.0-7). Today, when I tried to boot, I got a kernel panic! Booting with "acpi=off" corrected it, so it seems to be the same bug as before. The point is that I have never seen this behaviour before in a 4.9 kernel. In my hand-built kernels, it started with 4.14.

This makes me wonder if the problematic code has been backported into the Stretch kernel, perhaps as part of the meltdown/spectre protection. I understand that the hyphenated part of the version number in Debian kernels refers to the build number, but I always took this to mean a change in the configuration file, not in the source.

Could some more knowledgeable Debianistas enlighten me about the policy on this sort of thing?

PS: I've just checked my apt files. Both these kernels are builds of 4.9.110. Yet 4.9.0-7 boots and 4.9-08 doesn't.

Update: I downloaded the source. It still contains the lines (in the file arch/x86/mm/ioremap.c)that my machine needs to run acpi, so this isn't the same problem that I had before. So it's probably not a backport into the code that's causing this problem.

One other odd thing. If I do a diff between the new (build 8) and the previous (build 7) configuration files, I find "CONFIG_HOTPLUG_SMT=Y" in build 8. I would expect to find a line in the build 7 config reading "#CONFIG_HOTPLUG_SMT is not set". But it isn't there! Something weird is going on.

This may have been a false alarm. I booted Debian today, meaning to transcribe the panic messages for future reference, and I deliberately left the "quiet" option out of the kernel command line so that I could see whether it was an early or late panic. And whaddyaknow! It booted completely normally with acpi on.

I'm going to mark this tentatively as solved and we'll see if there are any further problems.