I also had a segfault the first time I booted 4.14.0, but no such thing occurred with 4.14.2. However, for me 4.14.x is the "back to sanity" kernel. With 4.13.x, I had boot segfaults/lockups probably due to gpio/irq initialization errors, but the weird thing was that these errors did not occur if I booted into 4.4.x first (the stock kernel). Probably 4.9.x or even 4.12 would be as good. I'm saying 4.4.x because I only had 4.4.x as a backup version to test.

I even filed a bugreport about this at kernel.org:

https://bugzilla.kernel.org/show_bug.cgi?id=197079

It was possible to boot into 4.13.x only right after 4.4.x (if I recall correctly even a Windows boot wouldn't fix it). It looked as if the 4.4.x initialization were "clearing up" some "leftover error" from 4.13.x.

Naturally when I first booted into 4.14.0, I assumed that the segfault that occurred was due to this "leftover" from the previous 4.13.x boots, but reading this thread, I now see it probably wasn't.

You run the x86_64 or i586 (32 bits) ? That's very important for us!

1 members found this post helpful.

x86_64.

Well, I am glad that 4.14.x series works better for you.

For me, it crashes in a particular Intel powered min-PC which is similar as hardware with a laptop. Under i586. I have no problems with my (other AMD) computers which runs the x86_64 variant.

The only series which show a real stability on my mini-PC under (standard) -current is the ol'good 4.9.x, at least until now ...

new test:

- eudev-3.1.5 with current SlackBuild + kernel-4.14.3: segfault when switch to 'multi user' mode : immediate infinite [printk] messages...
- no eudev version works with kernel-4.14.3

@nobodino

Like our BDFL said, also myself I do not think that is EUDEV the guilty one, after my experiments with the Kernel 4.14.3 ...

For example, disabling the bluetooth improved much the system stability, and it does not crash so often.

-------------------------------------------------------

At the end of day, I believe that there are a bunch of cranky modules which go nuts as their balls wants.

Most likely, most of the (Intel) developers paid much more attention to 64 bits architecture, or could be even a "planed obsolescence" of the 32 bits architecture (by Intel?).

Let's say: a suave way to suggest us to dump our computers to trash and buy something new.

Or they "discreetly try" to give us reasons to jump in the x86_64 bandwagon.

1 members found this post helpful.

On IMG_2 and IMG_3 I posted previously, you can read:
--------------------------------
BUG: unable to handle kernel paging request at 9b6bf61
IP: kmem_cache_alloc+0xa3/0x1f0
--------------------------------
Isn't it a kernel bug?

It is a freaking kernel bug, sized as a dragon. Just like I said, I think that they messed royally the 4.14.x until now.

Either they do not care, either the colossal amount of new code (around 500K new lines is bigger than the GTK) was too much for them to handle yet, either is with a reason.

I for one I think that around 4.14.25 we will see a really stable kernel. Too much code added in that poor series, like Torvalds menaced them there is no more LTS in the next years.

So, they dumped everything imaginable into.

I've been researching this issue, and here's what I've found (so far). I believe it is a kernel bug, and that it is triggered (heh) by "udevadm trigger --type=devices --action=change". It doesn't happen on every machine. I have an Intel Atom netbook running 32-bit -current (4.14.2-smp) that is absolutely stable. I've rebooted it two dozen times in a row without any issues. I've also put this into a loop:

This ran over a thousand times in a loop on the Atom machine with no ill effects.

The machine where I'm having issues is an AMD Phenom II X6. That machine, running in x86_64 mode with 4.14.2 is absolutely stable. In i686 mode it crashes during boot about every other time. If the boot succeeds, running "/sbin/udevadm trigger --type=devices --action=change" at the command line will Oops the kernel about every other time.

I built 4.14.3-smp for this machine based on the config-generic-smp-4.14.2-smp .config. I never did get that one to boot without crashing. Then, I played whack-a-mole with suspicious kernel options all day yesterday and didn't yield any improvement. I also built a kernel and modules from the latest kernel-i686-PAE.config from Fedora Rawhide. This also didn't help. I looked at how systemd handles udev, and it's exactly the same as what we do in rc.udev. I removed all of the kernel modules from the system and repeated the tests using our vmlinuz-huge-smp-4.14.2-smp. The udev trigger still killed the machine about half of the time.

Then I started with a brand new kernel config, initially using the options in arch/x86/configs/i386_defconfig. I made a few changes, making sure that SMP was enabled, and building modules for the hardware in the machine.

The resulting kernel was stable on the AMD box. I've not seen a crash there in 32-bit mode yet. I put it in a boot loop and booted the machine successfully 57 times in a row.

So, it's a probably a kernel bug, but it could be worked around by changing a kernel option (or options).

What now? My plan is to put -current back on a 4.9.x kernel, and move the 4.14.x kernels into /testing until we can work out a stable .config that works for a 32-bit 4.14.x kernel. Perhaps a newer 4.14.x kernel will end up working with a .config that's similar to what we use now, but meanwhile we should have working kernels in -current. Expect them soon.

15 members found this post helpful.

Would it be too much of a hassle to ship a 4.9.x for 32-bit and a 4.14.x for 64-bit, in case the 4.14.x 32bit can't settle soon enough to be shipped in Slackware 15.0? I ask assuming that most new hardware will be installed on 64-bit machines.

Wow !

Good catch volkerdi !

I really appreciate your tenacity and I am sure the Upstream Kernel Developers will too !

-- kjh

Thanks for all your efforts, Patrick!

I am pretty sure that the 4.14.x kernels will be tamed sooner or later, but, like yourself said, meantime a kernel on which we can rely would be greatly appreciated.

if can be useful here I noticed kernel panics also with my 32 bit qemu virtual machines, so I appended to the boot kernel parameters for the netconsole module or a console=ttyS0 to debug, but in these cases the vms didn't crash anymore! they started to crash again with no parameters.

3 members found this post helpful.

I don't think you need to be concerned that we're going to rush a Slackware 15.0 out the door any time soon. But yes, if we can't get 4.14.x stable on 32-bit we could consider that. I think we'll be able to make it stable there, though.

3 members found this post helpful.

Ponce, give me several minutes, and I will try right now your suggestion on the standard 4.14.2-smp, on my mini-PC.

Well, a successful boot with 4.14.2-smp, I will reboot several times, which usually is the perfect way for getting a crash.

So, three successful boot, then I enabled the bluetooth modules and got a crash in the next boot.

Overall, it behave similar with the previous existant bluetooth "hack", as stability. At least in my mini-PC.