Instead of reverting the kernel, why not use different flags/commands for 32bit and omitt for 64bit? The more we test the latest Kernel the more bugs we'll find and help squash them. Just a suggestion, take it with a grain of salt.

2 members found this post helpful.

Salt taken. There are already hundreds of differing options between the x86_64 and i686 kernel, and it's really not like I have a .config yet that results in a 32-bit 4.14 that's at all usable in a distribution. I'm working on it.

Meanwhile, there will still be 4.14 kernels in /testing. And I agree... some say I pulled the trigger on 4.14 too quickly, but it got tested that way, didn't it? It'll be coming to the main tree again eventually, so everyone is invited to help figure out the magic options.

6 members found this post helpful.

There I agree 101% ...

It is really a long time, Sir! since I accorded one hell of attention to the kernel.

Until reversing my network on using an "orthodox" router and dedicating that poor mini-PC just for playing with 4.14.x series ...

For the record, I had 4.14.3 x86_64 crash while building kernels, so it's not stable on either architecture with the .config files we are currently using. But the crashes on x86_64 are a lot less frequent.

2 members found this post helpful.

To be honest, I stayed with no crashes in 4.14.2 on other three computers, under X86_64 and AMD Phenom processors, since you added them on -current.

BUT, as you said already, not all computers are affected by those crashes...

I am about to roll over to the 4.14.2 kernel to but I have not had an issue with then 4.14 kernels on two of my machines. One laptop & one desktop...

Home System:

Laptop:
Guess I am lucky so far but I plan on staying with the 4.14 series to keep testing it..

Feel free to do it, as I understand that our BDFL will continue to ship the 4.14.x series, from /testing

Besides the Broadcom issue, I haven't had any other problems. I will stay on 4.14.2 as well. No retreating my system Kernel!!!

FYI, NONE of the 4.14.x series can boot on my HP Proliant DL385 G1. I get the panic just before the framebuffer stuff loads. I've tried compiling my own roll, based on Arn Exton's work as Pat's configurations started bombing my machine back in February. But for 4.14.x, NOTHING WORKS. I advise we all flush this kernel down the toilet and go back to one that works. 4.13.8 and 4.13.16 do alright, though I'm leaning toward going back to the 4.9.x series, as everything since August (4.12.x) has been destabilizing.

These old Opterons were made for a different world. I'm considering a BIOS upgrade, IFF I can get one without spending more than the whole kaboodle here is worth. I might also go modern, and try a Ryzen when I get $$ for that.

Be that as it may, 4.14.x is execrable.

1 members found this post helpful.

Easy, guys!

You (and me, to be honest) got both of the Two Worlds.

Our BDFL switched (back) the trees to the 4.9.66 and the 4.14.3 is alive and kicking in the /testing, if you lost it somehow.

Let's continue to keep this thread just for testing the 4.14.x series, but the operating system issue is no more. At least for me.

And lets say thanks to P.V. for all of his efforts! This one was a hard match ...

If your Bios is not updated, it could be part of the problem. The first thing I do on any computer is update the Bios + Ram + HDD/SSD. Max out everything to the fullest.

If you talk with me, you will be truly scared when you will see what devices I have just for updating off-line the BIOSes...

I have even external FLASH programmers, working in place, but also with chip extraction. To be honest, even the passion for ARM I got building a micro-PC special for flashing BIOSes.

And yes, that mini-PC is on its latest BIOS shipped by Fujitsu-Siemens, and it was this way even before to see the Slackware.

For now, i'll keep on 4.14.x since it's stable enough for me, both on x86 and x86_64 (desktop, workstation, laptop).
I never had any crash so far since i added the option to disable watchdog in sysctl.

1 members found this post helpful.

This is what I was aiming @. Could it be people are using outdated Bios, Firmware etc...? We need to investigate all variables when it comes to testing. Thanks willysr as you understood the point I was making.

Same here, on three AMD with x86_64, I got the 4.14.3 with not issues so far.

In fact, they never crashed with 4.14.x, and if matters they have: Phenom x4 9650, Phenom x4 9950 and a Phenom 2 N620 (this one is another mini-PC and the processor is dual core).

On the Intel based mini-PC, I tried several times the official 4.14.3 with a glorious fail, then I switched to 4.9.66, where it is very happy.