LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   strange behavior with kernel-4.14.x (https://www.linuxquestions.org/questions/slackware-14/strange-behavior-with-kernel-4-14-x-4175618207/)

nobodino 11-23-2017 01:31 AM

strange behavior with kernel-4.14.x
 
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?

trollog 11-23-2017 01:44 AM

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

Darth Vader 11-23-2017 07:11 AM

Quote:

Originally Posted by nobodino (Post 5784191)
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?

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. ;)

RadicalDreamer 11-23-2017 09:08 AM

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.

volkerdi 11-23-2017 11:08 AM

Quote:

Originally Posted by nobodino (Post 5784191)
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.

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

willysr 11-23-2017 11:37 AM

Quote:

Originally Posted by volkerdi (Post 5784325)
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)

nobodino 11-23-2017 11:51 AM

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.

tazza 11-24-2017 04:24 AM

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.

willysr 11-25-2017 02:27 PM

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

Drakeo 11-25-2017 02:56 PM

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.

volkerdi 11-25-2017 03:05 PM

Quote:

Originally Posted by willysr (Post 5785144)
Good news. I found that 4.14.2 didn't have the strange behaviour anymore yay.....

My machine seems to be cured as well.

volkerdi 11-25-2017 03:09 PM

Quote:

Originally Posted by Drakeo (Post 5785147)
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.

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).

Darth Vader 11-25-2017 04:06 PM

Quote:

Originally Posted by volkerdi (Post 5785152)
My machine seems to be cured as well.

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... ;)

gmgf 11-25-2017 04:38 PM

No problem here 4.14.2 work.

Olek 11-25-2017 04:56 PM

4.14.2 on old machine not work
 
Quote:

I upgraded kernel to 4.14.2 (64bit) on my old machine with AMD Athlon 64 CPU.
After upgrade I can't boot to Slackware.
Just after lilo my screen is going blank immediately.
It doesn't matter which kernel to choose, both huge and generic kernel hangs my machine.
Now I can only boot by pendrive with 4.14.0 kernel and I am waiting for newer kernel to try.
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.


All times are GMT -5. The time now is 11:55 PM.