Just FTR there has been a huge (100+KLOC) inclusion of AMD and AMD/ATi support code added in kernel version 4.15.x. It should be trivial, though a tad time-consuming depending on CPU, to use "make oldconfig" to build a new 4.15 kernel that keeps your present configuration while alerting you to the new code and allowing your choices. If I owned any AMD hardware, I'd do this without hesitation since it seems a rather important improvement. As long as you keep your old kernel and add 4.15 as an alternative in your bootloader there is no risk other than time.

It's only at RC3. I'm going to wait for it to get a few more RCs before I consider moving my system to it. However, the majority of the AMD code was towards AMDGPU improvements. As far as I can tell from the few blogs reporting on it, the major addition for Ryzen systems is support for the on-die CPU temperature sensor rather than using the motherboard temp sensor for the CPU. But hopefully they'll fix the instability that happens on Ryzen systems, but with the changes I documented above, my instability is gone. No freezes and no reboots since I enabled it. So, pushing to an early RC of 4.15 is not something I feel inclined to do.

@mfoley, I'd still highly recommend trying my suggestion as it seems like I had the same issue as you. With those changes, my system is now rock-solid.

OK, I did not do that. All I did was download the kernel source, create the package and install it, per my understanding of instructions in this thread. I've looked at that link you reference above, and it appears to be building a new kernel. However, in your 11-28-17, 12:58 PM (#26) posting, you wrote:
So, to un-confuse me, should I now build a new kernel? I'm willing to give this one more shot before tossing this machine out.

That's correct. The kernel-firmware package is just to update the firmware, which can include microcode updates for the CPU. I was hopeful it would solve your problem, but it didn't.

So the next step would be to create a custom kernel making the adjustments I linked to in that post. Then you would just pass a kernel option using your bootloader (lilo,elilo,grub,etc) of rcu_nocbs=0-15, adjusting that 15 to be the number of threads your CPU supports minus one. Mine is a Ryzen 7 1800x, so I support 16 threads, so I do 0-15. I don't remember seeing you mention your specific processor, but just know that the upper number should be the result of:

My elilo.conf entry for my 4.14.0 kernel looks like:

Getting ready to make the kernel mods per that link. Coupla questions first. The link is Unbuntu, did you do all the stuff:
or just go right to /usr/src/linux and 'make menuconfig'?

Do I need to do 'make oldconfig' first to get the settings of my current config or is that not necessary? (it's been a while since I've built a kernel).

For the most part, you should stick with Slackware kernel building procedures. I started with 55020's dusk 4.13 config as a starting point rather than starting with -current's 4.9, but you could also use Pat's 4.14 config in testing/ (that wasn't available when I switched to the 4.14 series). I've also attached the one I used to build my 4.14.0 kernel, which has the changes already applied, just move it to the root of your kernel source and save it as .config (or load it using the the load option in make menuconfig).

make oldconfig is used to convert an older config to work with the current kernel. If you're building a kernel using a kernel config from a previous series than yours, you should definitely use it (like if you use 55020's config), however, if it is from the same series (Pat's or my 4.14 configs), I don't believe it is necessary since kernel options don't normally change within the same series.

Once the kernel is built, you'll need to generate an initrd (I don't use the huge kernels on my machine), and then add the kernel and initrd to your bootloader's conf file and then add the append option for the rcu_nocbs. If you're using lilo, don't forget to run lilo to save it. If you're using elilo, there's no need to run anything to update it, just make sure /boot/efi/EFI/Slackware/elilo.conf shows the right entry. If it's something other than lilo/elilo, I'm not familiar enough with it to tell you how to make changes.

Attached Files

4.14-generic-config-bass.txt (175.5 KB, 20 views)

Under /usr/src I have linux-4.4.88 which is the 14.2 sources, not -current. Should I still use your 4.14 config or just go with what I have? Also, should I copy the kernel-firmware stuff I downloaded previously into the /usr/src hierarcy? Leave it alone? Or rebuild and re-install the kernel-firmware after building the kernel? Meanwhile, I'll experiment ...

I know they tested the issue with the 4.13 kernel and found that the kernel settings and kernel option at boot solved their issue. I had already moved on to the 4.14 kernel before I found that post, so I did it on there. I'm not sure if the 4.4.x series even has that option or if it does if it will have the same effect, so I'd try either the 4.13 or 4.14 series kernels (although, I'd go with the 4.14, since that is an LTS kernel and will be getting fixes for a long time). Once you download and extract the source, copy whatever config you decide to use into the root of that source tree as .config and then continue the steps from there.

As to where to store it... most will say to extract the kernel source into your home directory (including the kernel building page on SlackDocs), however, I always build mine in /usr/src/, but I've been doing that for 15+ years and it's a hard habit to break (read: I'm too lazy to change my habits).

The kernel-firmware package doesn't need to be touched in this process. The files are completely separate from kernel files and it doesn't need to be rebuilt/reinstalled.

I haven't built a non-stock kernel in years, but I'd expect kernel sources to be in /usr/src were I to look for them.

It's not as if the kernel belongs to user <X> after all.

I have linux-4.14.2.tar.xz I downloaded last month. I don't remember doing that, but it was certainly in the course of this thread. I also have two patches: patch-4.14.2.xz, patch-4.14.1-2.xz. Should I apply those? If so, before the config?

bassmadrigal's recommended 'Pats 4.14.config' is labeled config-generic. I assume that makes a generic kernel, yes?

Pending comments on the patches, here's what I'm proposing to do (based on bassmadrigal's referenced link https://docs.slackware.com/howtos:sl...rnelbuilding):

cd /usr/src
rm linux
ln -s linux-4.14.2 linux
cd linux
# Possibly apply patches
mv pats-generic-config .config
make oldconfig
make menuconfig
# make the RCU_NOCB mods as described in bassmadrigal's link http://blog.programster.org/ubuntu-1...rnel-for-ryzen
:
(finish menuconfig)

make bzImage modules # compile the kernel and the modules
make modules_install # installs the modules to /lib/modules/<kernelversion>
cp arch/x86/boot/bzImage /boot/vmlinuz-generic-4.14.2 # copy the new kernel file (is x86 still correct?)
cp System.map /boot/System.map-generic-4.4.2 # copy the System.map (optional)
cp .config /boot/config-generic-4.14.2

I'll forego re-linking the /boot/System.map and adding to lilo.conf until I'm ready to test, but up to that point, am I on the right track?

That's my train of thought as well, but apparently it isn't what most recommend. Greg Kroah-Hartman actually recommends building the kernel as a regular user in his book.

But, if you have a multi-user system, that prevents any other users from building something against that kernel. Plus, I like to be able to remove things at a whim on my user's directory, and I'd rather not have a huge source package remain in there.

Don't apply the patches unless you know what they're for. My guess is that they're a patch to go from 4.14.0 to 4.14.1 and then from 4.14.1 to 4.14.2. You should be fine with the source by itself, however, I'd probably recommend just grabbing the latest 4.14.x kernel (I think it is 4.14.6 right now).

Yes, I'd recommend the generic kernel as that is what Pat recommends. But you'll need to build an initrd once you've finished installing the modules. I'll cover that below.

I always skip the System.map as it is mainly geared towards kernel developers trying to debug the kernel (at least that's my understanding), but otherwise, you're steps look good. After you're done with all those steps, be sure to create a new initrd. I recommend using the mkinitrd_command_generator.sh script.

This will generate a mkinitrd command that will create an initrd for the 4.14.6 kernel called initrd-4.14.6.gz under /boot/. Just run the output of that and then ensure the initrd is also referenced in your /etc/lilo.conf before you run lilo.

Let me first state that I have considerable respect for bassmadrigal's experience and critical thought processes. He has helped me more than once. However I would like to offer a slight alternative to consider. Similarly, while it is impossible not to have even more respect for Greg Kroah-Hartman, he isn't exactly a Slackware kinda guy and being in the lofty position of Kernel Dev Wizardry for ALL Linux, not just SOHO Desktop, I have to say that I am happier with Alien Bob's methodology. Here's just two points.

Alien Bob recommends building kernels as root and has instructions for using "su -", or "sudo -i", or "sudo -s" specifically to literally become user with root privileges, rather just actual root with root's groupIDs both for the build and as part of a set of commands to allow root access to user DISPLAY. Additionally, and I think this is wise for anyone who is less than confidant about kernel building or for that matter making a substantial version leap, and that is using "make xconfig" in X instead of menuconfig from runlevel 3. There is value in having view of all 3 sets at once, including the Help section. At the very least it gives one a sense of "Big Picture" and here, please don't get me wrong, I have built kernels from runlevel 3 many dozens of times, so this has nothing to do with "fear of CLI". It's just useful and beneficial to many and has no downside. One can drop to runlevel 3 after config for final application.

Secondly, I see no good reason for people to add another step including any additional opportunity to fail, if it is not required. Most Desktops that do not use encrypted file systems only require boot file system support, commonly ext4, and a click on a single checkbox or a single press of the Space Bar is considerably simpler than building and applying an initrd.

Whatever one's preferences I think it can be worthwhile to consider Alien Bob's method even though it still addresses 2.6 kernel issues no longer required.

Here is the blog post --- --- Alien Bob's Kernel Building --- Make of it what you will but I built possibly 100 kernels before ever reading Eric's blog, and possibly another 40-50 since and it has never failed me.

1 members found this post helpful.

I usually build my kernels remotely (ssh in through my Windows laptop and build them on my desktop), so xconfig isn't an option for me. Since I frequently build my kernels remotely, I haven't tried going back to xconfig (I tried that back in the 2.4/2.6 kernel days and preferred menuconfig). You can still get the same info from menuconfig as xconfig, but you have to go click on "help" on that kernel option to view the extra info. For those looking to customize many aspects of their kernel, xconfig can be handy since it shows all that info on one screen. But I don't think there's anything wrong with using your preferred method of configuring the kernel

As for the initrd, I'll be honest, I'm not really sure why it's the recommended route. Pretty much every distro uses initrds. In a previous thread I asked if there was a benefit of using an initrd over building in the required modules (outside of the required uses like luks or lvm), but no one provided an answer to that question. I use an initrd because it is what Pat recommends (although, that recommendation is probably only related to using official Slackware kernels, and he recommends the generic kernel which requires an initrd) and I don't find it difficult to do, so it doesn't bother me to generate one.

Out of curiosity, is there a benefit of running the su/sudo commands over kdesu (assuming you have kde installed)?

Actually that is turning into a very good question. Firstly it is my understanding that kdesu (and on some distros, kdesudo) is recommended by KDE when launching graphic apps primarily to insure no permissions are inadvertently altered as there are subsytems that must be launched for KDE graphic compatibility. Very recently I've witnessed more than one distro that disallows kdesu and kdesudo and I'm not altogether sure why beyond security paranoia. Thankfully as simple as the graphics calls are for "make xconfig" kdesu is not needed. Alien Bob probably understands this better than I, but although I recall a few years ago making a bit of a permissions mess in KDE, it was not due to either "kdesu" or "xconfig" launched as Eric shows, and as an aside, the mess I created was way back on v3x and easily fixed.

Also, yes, I do have KDE installed as I always do Full Recommended Install and for the past 16 months have returned to fulltime KDE use (well...outside of sometimes dropping to runlevel 3). I was using Xfce for over a year but a few minor problems and, later with an Xfce update, a rather nasty problem in Xfce caused me to revisit KDE and I'm quite pleased with how v4.x has evolved. Eric's Plasma 5 on Live Slack seems decent, too, but I will reserve judgment on 5x until I have it in Slackware as a hdd install and work with it and customize it awhile.

This is actually what spurned my question about that. I've seen so many issues on this forum due to people running X-related apps just using normal su/sudo, which ends up causing permission issues in their home directories. I have no doubt that running xconfig as root using su/sudo won't cause those same issues (otherwise, why would Eric mention it), but I was curious is there was a reason for him mentioning those directly without mentioning kdesu. My only thought is that he is expecting some users to not install kde (or maybe kde3 didn't provide the same utility... I honestly don't remember -- it's been too long since I've run kde3), but that seems like a weak reason.