Downgraded EUDEV to 3.2.2, like our friend nobodino suggested, on the pure blood Slackware-current with 4.14.2 kernel, latest pull. Of course, on my Intel based mini-PC.

Guess what? It works. Resisted at 8-10 reboots with no laments.

So, now I have three winner combinations:

1. Latest current with the kernel 4.9.65 (smp, generic)
2. Latest current with the EUDEV downgraded to 3.2.2
3. Latest current with SystemD replacing the init system and EUDEV hack.

Could be that we hit a double issue, as in: the latest EUDEV crashes in certain/particular conditions, then drag the kernel after it, because a particular kernel liability?

So, when the Kernel guys do their job, we will obtain plain and simple: a crashing EUDEV?

You don't have to replace the init system. systemd's udev-235 will live peaceably with slackware's current sysvinit, and works OK with the current kernel.

4.14.3 should be out very soon.

https://marc.info/?l=linux-kernel&m=151186941914449&w=2

I tested 4.14.3-rc1 and it runs fine on an Intel 64-bit machine and an AMD 64-bit machine. (4.14.2 works fine for me too on 64-bit machines.)

If you are curious and like building kernels, then install the current source (4.14.2), apply this patch -p1 and build it.

http://kernel.org/pub/linux/kernel/v...-4.14.3-rc1.gz

Then you can test 4.14.3-rc1 too.

I'm still getting occasional boot failures with 4.14.2-smp (32-bit).

IMPORTANT:
Has ANYONE seen a failure with 4.14.2 on x86_64? I haven't, and would like to hear about it if anyone has.

We knew that already.

I am getting failures at the same rate on 32-bit with eudev-3.2.2 or eudev-3.2.5. With the older one, I have to add the /lib/modprobe.d/edac.conf file from the newer one, or my machine will oops every single time.

In case you aren't aware, eudev is the same udev that's used in systemd with a few changes to allow it to build standalone. But eudev is a hack, and systemd less so?

Give it a rest.

I have my doubts that systemd would be any more stable than -current with eudev-3.2.2 that was promised to be one of your "winner combinations."

If the kernel crashes, it's a kernel bug. It's really that simple. If there's *anything* you can run in userspace that can crash the kernel, you have uncovered a kernel bug.

At this point, I seriously doubt based on my testing that eudev has anything to do with this. If eudev was to blame, you'd think it would crash a kernel earlier than 4.14.x.

I think it'll take a bit of patience, but we'll get there with this kernel series. It's an LTS kernel series, so the developers have a lot of motivation to make it stable. We're not the only ones who will be using it.

6 members found this post helpful.

x86_64 is working fine here on all of my machines, and so does x86 on my desktop
I added kernel.nmi_watchdog=0 in /etc/sysctl.d/50-watchdog.conf though. I'm not sure that helps.

It is the freaking Bluetooth who bite, at least in my particular case!

My mini-PC has Bluetooth on-board, at least internally. Damn, I do not treated it with (great) attention, because I never used it on this particular PC.

BUT, disabling/blacklisting the Bluetooth module(s), starting with bluetooth and btintel, makes my mini-PC perfectly stable and it works with no crashes, using the clean latest current.

Same here.

I am 101% confident that in several kernel releases we will go back to a stable solution, as I said (in this very thread) from beginning.

All my experiments are made just to try to identify the guilty things, then eventually to report back consistent facts, for the greater good. Personally, I considered my own problem solved after rolling back with success to 4.9.65.

And I think that I have something for you: follow the bluetooth stack.

PS. I have ZERO crashes on another three machines running also 32 bits, but having AMD Phenom processors.

PS2. The Bluetooth from my mini-PC looks being an USB thingie, even it is internal:

"And if evidence was not what it seemed?"

We may suppose now that the problem relies on the interaction between eudev and the kernel, because some combinations work and others not.

eudev may act as a 'trigger' or a 'catalyzer' on a kernel module?

Four questions to try to solve the problem:

-1/ Is it be possible to 'catch' what happens when we switch from 'single user' mode to 'multi user' mode?
-2/ Is there a sort of 'database' or configuration 'file' updated between the first boot and the second boot? --> /etc/udev/hdwd.bin ?
-3/ Is it possible to disable udevd from running in 'multi user' mode, and modprobe every single module to see which one segfaults the system if a kernel module is the 'culprit'?
-4/ Could It be a problem with kernel-firmware ?

While upgrading, we've always upgraded the kernel and the firmware, and we focused on kernel, not on its 'close friend'?

@nobodino

A suggestion: just disable (remove the executable bit) the /etc/rc.d/rc.udev, reboot and manually load every module from your known list.

BTW, I for one, I would like to ensure that the essential modules for your FS, also keyboard and mouse, are loaded via initrd.

PS. Ensure that your /dev devices are proper created in some way.

PS2. Would be nice in this particular case to have a way to blacklist everything. This way we can keep the (E)UDEV ability to create device files.

Maybe our BDFL knows a way for blacklisting all modules, with no mercy.

I will test this evening the first suggestion.
I rebuild SFS with eudev-3.2.3 this time, and tonight it should be finished.

I know you're after failures rather than lack therof, but for what it's worth it's running fine on i5-7600k with 8 gig Geil DDR4 on an MSI MB that I haven't bothered upgrading the bios for since day dot.

I mention it because 4.14.0 hung on first boot, but then worked afterwards. No probs whatsoever on 4.14.2 and no downtime since install.

1 members found this post helpful.

BIOS is up to date.

I don't understand how this contributes anything. I only mentioned my situation. My core 2 quad with latest bios dates from years back was fine. In short it's not a bios issue. I was just pointing out I was slack on my 7600K (if it aint broke don't fix it).

The 4.14.3 is there.

Preparing the popcorn while waiting for our BDFL to pull the fresh Kernel packages into -current ...

results: not what we could have expected

- eudev-3.2.5 + kernel-4.14.3 segfaults on third reboot (IMG_1)
- eudev-3.2.3 + kernel-4.14.3 sefaults on first boot
- eudev-3.2.2 + kernel-4.14.3: how to say it? Disturbing!
- it boots normally in single user mode
- when switching to multi user mode: something segfaults but no hardlock,I had access to the console : ls and so on (IMG_2)
- then I typed 'reboot', and complete lock-up! (IMG_3)

Attached Thumbnails

     

Same here.

Not even EUDEV 3.2.2 was not prone this time for crashing with 4.14.3. I hope to see better news with the official / Patrick's Kernel packages.

Long story short, I tucked the tail in a gracious way and ran back on the 4.9.65 safe heaven. Now building the 4.9.66 in that mini-PC.

PS. That blacklisting/disabling the bluetooth sadly just improved visible the stability, but still crashes appear. Not so often, but they appear.