Each time I update a system with kernel from 4.14.x series, the kernel segfaults the first time it boots.
Then I reboot a second time, it boots normally.
It's the same problem, if I build myself the kernel for slackware from scratch.
Nothing of that kind happens with 4.4.x, 4.9.x or 4.13.x kernels.

What's wrong with that kernel?

I've also gotten a lot of odd behaviour out of this kernel

And happens to have an Intel processor?

I have a small PC, model Fujitsu Esprimo Q5030, which have hardware similar with a laptop, with CPU: Intel Core2 Duo P8400, but in a small desktop, and it have same behavior.

Something is wrong with (some of) the Intel CPUs on our current kernel.

I experienced that behavior a couple of times in an earlier kernel series. I'm not sure if it was the later 4.4.0 series or early 4.9.0 series where I experienced it. My computer feels more responsive with this kernel.

32-bit? I've seen it a few times here, but never with x86_64.

Yes, it seems to happen with my machine as well (32 bit)

My machine is rather new: INTEL with i7-6700, no RYZEN.
I'll test on x86_64 to see if the behavior is the same.
update: I updated a partition with Slackware-current x86_64, it booted normally. Seems to be limited to 32-bit systems.

Mines done the exact same thing on a number of earlier kernels, but interestingly enough it didn't happen on 4.14. Weird. Seems to be no rhyme or reason to it.

Good news. I found that 4.14.2 didn't have the strange behaviour anymore yay.....

None of them have had issues for me on 7 machines. Latest 4.14 kernels piss off virtualbox but hey patched it myself.
I always build an initrd.gz for the new kernel before I reboot to the new kernel image. then boot vmlinuz-generic. This may be a huge or huge-smp thing.

My machine seems to be cured as well.

The issues I had here were with kernel-generic + initrd. To be honest, I'd like to get rid of the huge kernels. They're a hack that was developed back before we had anything like udev, and if initrd generation could be added to the installer there would be no good reason to keep the huge kernels. Either way, there's no advantage to using a huge kernel. And there are a few things that the huge kernel does not do as well - some of the modules don't load properly into a huge kernel, and having the huge kernel has forced a few things to be built into kernel-generic that really shouldn't be (in the interest in keeping the module tree mostly compatible with both kernels).

16 members found this post helpful.

My Intel based Esprimo Q5030 still do the crash thing. And the single strange thing in that mini-PC is a dual Ethernet on mini-PCIE, instead of WIFI card, something like this:

https://www.amazon.com/IO-Crest-SI-M.../dp/B01N9HNXBB

Because I replaced also the DVD drive with a caddy for a second (internal) hard-disk, I had the possibility to speculate the space to mount those Ethernet ports in the case, and I use that mini-PC as a router for a 1Gbps down connection, while it ran also a LAMP stack, as a (home) web server.

The good news for me is that this little thingie does not is rebooted often, so the issue does not disturb me too much.

Also, my modding make it a bit non-standard, so my laments are with half of mouth...

No problem here 4.14.2 work.

I run lilo with additional Luks encrypted disk which get /dev/sda name.
Since I had boot=/dev/sda in my lilo.conf my appropriate BIOS boot disk wan't overwritten.
Now I put to lilo.conf boot=/dev/disk/by-id/... and everything is OK.