[SOLVED] Slackware workstation intermittently crashing

mfoley · 12-20-2017, 11:07 PM

Quote:

Originally Posted by bassmadrigal

Was this directed at me? ...

Settle down fellas - I doubt anything was directed at you. If anything at ME, I can appreciate Drakeo's fatigue. We're on the 6th page of this thread and I'm greatful to everyone, especially you two, for hanging in there and guiding me through the nuances. Frankly I'm surprised you've hung in there this long. So, back the topic ...

I did:

Code:

make mrproper  # per Drakeo's reccomendation and bassmadrigal's given that I did a previous build
cp pats-huge-config-4.14.4 .config    # I *did not* run 'make oldconfig', again per the tip that this used the config from /boot, not Pat's
make menuconfig  # did the RYZEN RCU_NOCB changes
make bzImage modules
make modules_install

And lo and behold! There is now a bzImage in /usr/src/linux/arch/x86/bzImage!!!

Something must have gone awry the 1st time. I checked my history and I did in fact do, "make bzImage modules". Perhaps the abort I did on a previous make messed something up since I only did 'make clean' not 'make mrproper', who knows. In any case, the lilo worked, no "too big" error. Now I simply need to try it which will be in the next day or two. I'll keep you posted.

THANKS!!

bassmadrigal · 12-20-2017, 11:39 PM

Quote:

Originally Posted by mfoley

And lo and behold! There is now a bzImage in /usr/src/linux/arch/x86/bzImage!!!

Something must have gone awry the 1st time. I checked my history and I did in fact do, "make bzImage modules". Perhaps the abort I did on a previous make messed something up since I only did 'make clean' not 'make mrproper', who knows. In any case, the lilo worked, no "too big" error. Now I simply need to try it which will be in the next day or two. I'll keep you posted.

THANKS!!

Good luck! Hopefully the rig will be rock solid like mine. If it is and I happen to find a kernel that has the issue resolved without modification, I'll try to remember to post here to give you the heads up.

mfoley · 12-21-2017, 10:57 PM

New 4.14.7 kernel booted about an ago. The machine came up and everything, including VM, seems to be running OK. If it stays up w/o halting for a month I'll consider this a success!

Final questions (hopefully). The Slackware instructions say,

Quote:

Other packages that contain kernel modules

Be aware that by installing and booting into your new kernel, you will no longer have these out-of-kernel modules available. You have to recompile their sources so that the resulting kernel modules match the version of your new kernel.

It goes on to show how to determine which modules are out-of-kernel. I did that and came up with only:

kernel-modules-4.4.88-x86_64-1

It then says, "If you rebuild a package containing a kernel module, use installpkg rather than upgradepkg to install this new package without removing the original version." Since the 4.14.7 kernel stuff is not in the slackpkg package list, how do I handle this? There are 328 3618 modules listed in the kernel-modules package not found in /lib/modules/4.14.7. I take it from the quote above that I have to find and recompile the kernel-modules source. That's a lotta sources! Some seem rather important like kernel/fs/ext4/ext4.ko.

Question 2: The Slackware instruction say,

Quote:

The kernel-headers package usually contains the headers taken from the source of the default Slackware kernel. These particular headers are used when the glibc package is built. ... As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.

Does this mean that I should blacklist all glibc packages as well as the kernel packages forever until Slackware 14.3 (or 15.0) or basically until Slackware uses the 4.14.7+ kernel?

bassmadrigal · 12-22-2017, 09:52 AM

Quote:

Originally Posted by mfoley

Final questions (hopefully). The Slackware instructions say,

It goes on to show how to determine which modules are out-of-kernel. I did that and came up with only:

kernel-modules-4.4.88-x86_64-1

It then says, "If you rebuild a package containing a kernel module, use installpkg rather than upgradepkg to install this new package without removing the original version." Since the 4.14.7 kernel stuff is not in the slackpkg package list, how do I handle this? There are 328 3618 modules listed in the kernel-modules package not found in /lib/modules/4.14.7. I take it from the quote above that I have to find and recompile the kernel-modules source. That's a lotta sources! Some seem rather important like kernel/fs/ext4/ext4.ko.

This is actually a non-issue right now. Modules are built against a specific kernel, so if you built modules against the 4.4.88 kernel, they would no longer be available when you boot a 4.14.7 kernel. You don't need to worry about the 4.4.88 kernel modules package, that warning was more for if you built 3rd-party packages like the nvidia driver, those modules would no longer be available to the new kernel so you'd need to reboot it.

All the modules in the kernel-modules package were rebuilt during the modules portion of make bzImage modules and they were installed when you ran make modules_install.

Quote:

Originally Posted by mfoley

Question 2: The Slackware instruction say,

Does this mean that I should blacklist all glibc packages as well as the kernel packages forever until Slackware 14.3 (or 15.0) or basically until Slackware uses the 4.14.7+ kernel?

No, you can ignore the kernel headers package. It will remain at 4.4.88 unless Pat pushes another update, which you are fine to upgrade. The files from that package won't conflict with the kernel headers from the 4.14.7 kernel (kernel-headers package files reside in /usr/include/, where your 4.14.7 header files reside in /usr/src/4.14.7/include/). glibc should also continue to be upgraded as Pat puts out patches. Packages are smart enough to know which kernel headers to build off of (99% of the time it will be the /usr/src/4.14.7/include/ headers).

enorbet · 12-22-2017, 11:06 AM

Two days ago I built a custom 4.14.7 kernel on an older secondary box, a single core AMD FX-57. I experienced a few odd quirks that I'd like to relate here in hopes it might help someone.

I downloaded the source from kernel.org and used the generic kernel config from Current and did "make oldconfig". Then I ran "make xconfig" to check it all out and make a few changes so I wouldn't require an initrd. The main change needed was for ext4 support needing to be "hard wired" but for some reason xconfig would not change to anything but as a module. So I manually edited .config (I know that's not supposed to be "kosher") and ran "make menuconfig". They were all marked "built in" at that point so I looked through a few other options to trim some fat and get a low-latency kernel.

After the kernel was built and first booted I ran the nVidia installer script and it informed me that "a driver is currently installed, do you want to replace it?" and I answered "Yes" but noticed it was the exact driver I'd installed on the stock Huge kernel. FWIW I used the "append version" feature and copied bzImage as /boot/vmlinuz-4.14.7-64 and the same for .config links to "/boot/.config-4.14.7-64". I confirmed that a new directory was created by "make modules_install" properly labeled as "4.14.7" Thankfully both those odd occurrences presented no problems as everything runs great. It was a head-scratcher for a minute though.

mfoley · 03-01-2018, 09:29 AM

This has been a long thread, but I think the problem with the intermittent crashing of the RYZEN processor is finally solved. I updated the kernel to 4.14.7 and did the RYZEN RCU_NOCB changes per bassmadrigal's instructions and link references. That was all as of December, 21st per my post #76. It's been running now for nearly 2 month (excluding a couple of week reversion to the old kernel) and there's been no machine halting. I think we've finally got it!

Thanks to all for your patience on this very thorny problem.

slac-in-the-box · 03-01-2018, 04:39 PM

I wanted to try this out, to see if it fixes crashing issues on an amd ideapad 310... I got as far as trying to download the 4.14.4 config in testing, as shared by bassmadrigal, here, but I got 404ed: https://mirror.slackbuilds.org/slack...ric-4.14.4.x64 , and now only efibootmgr is there. The 55020's dusk 4.13 config link still works, so I can start there. Just kind of wanted to start with the same config, since mfoley's results were successful. Does anyone have a 4.14 or 4.15 config to start from?

bassmadrigal · 03-01-2018, 05:08 PM

Quote:

Originally Posted by slac-in-the-box

I wanted to try this out, to see if it fixes crashing issues on an amd ideapad 310... I got as far as trying to download the 4.14.4 config in testing, as shared by bassmadrigal, here, but I got 404ed: https://mirror.slackbuilds.org/slack...ric-4.14.4.x64 , and now only efibootmgr is there. The 55020's dusk 4.13 config link still works, so I can start there. Just kind of wanted to start with the same config, since mfoley's results were successful. Does anyone have a 4.14 or 4.15 config to start from?

The 4.14 config was removed from testing/ because -current moved to 4.14 as the normal kernel (from the 4.9 that was there earlier). You can find the latest configs in the source directory under your favorite mirror.

https://mirror.slackbuilds.org/slack...rent/source/k/

@mfoley, I'm glad it's resolved for you as well. My machine is still rock solid with those changes.

slac-in-the-box · 03-08-2018, 05:22 AM

Took me a couple of days, because, I started, by basing my config off of config-huge-4.14.23, and the kernels that were resulting returned me to the elilo prompt instead of booting, in an infinite loop. The huge-4.14.23 kernel in current also gave me an elilo loop. However, when I built a 4.15.7 kernel, starting from config-generic-4.4.14, and not doing much to it, other than making sure the amd graphic drivers were checked, and the ideapad options were checked, and it resulted in a bootable kerenel/initrd combo. Better yet, after booting into the new kernel, and starting X11, it suspended and resumed without crashing multiple times!!!

I posted in this thread because, like the OP, I had an AMD issue that is fixed with a kernel upgrade. However, unlike the OP, this is no ryzen processor. I was thinking in reverse, and went completely low end, opting to lease cpu resources on cloud when I need intensive processing power. So I went with an ideapad 310, featuring AMD innards profiled by the following abbreviated /proc/cpuinfo:

Code:

darkstar% cat /proc/cpuinfo
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 101
model name	: AMD A12-9700P RADEON R7, 10 COMPUTE CORES 4C+6G
stepping	: 1
microcode	: 0x6006118
cpu MHz		: 1388.235
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 16
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov
bugs		: fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
bogomips	: 4990.21
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

I'm glad it's finally stable. Thanks SlackerLQ! Don't know what I'd do without you.

mfoley · 03-08-2018, 11:26 AM

Interesting. The AMD A12-9700P processor is also fairly new (Q2, 2016, still postdating the 4.4.xx kernel) and is listed as "7th Generation": https://products.amd.com/en-ca/searc...7-Graphics/195. So maybe, it shares some architecture with the RYZEN and thus shares the same problem which is also fixable with a recent kernel.

slac-in-the-box · 04-04-2018, 10:26 AM

I remade kernel again, with 4.15.15, because it was LTS, and I learned two things:
1.) When configuring kernel options for AMDGPU (Device Drivers --> Graphics support), if I check "Enable amdgpu support for SI parts" or "Enable amdgpu support for CIK parts," I got a black screen when starting X11--had to keep those unchecked for this ideapad to work, (while leaving checked and enabled, the option "always enable userptr write support)".
2.) The inifinite elilo loop that I was experiencing when starting from the huge-config, was the result of bzImage over 8MB, for which there is an elilo patch that can be applied to make elilo handle larger bzImages; however, when I start with generic-config, and fully-select my relevant file system (ext4) to be built-in instead of modules, I get bootable kernels under 8MB.

volkerdi · 04-04-2018, 12:06 PM

Quote:

Originally Posted by slac-in-the-box

I remade kernel again, with 4.15.15, because it was LTS, and I learned two things:
1.) When configuring kernel options for AMDGPU (Device Drivers --> Graphics support), if I check "Enable amdgpu support for SI parts" or "Enable amdgpu support for CIK parts," I got a black screen when starting X11--had to keep those unchecked for this ideapad to work, (while leaving checked and enabled, the option "always enable userptr write support)".

That's odd. According to the Kconfig help information, those shouldn't actually do anything unless you use kernel boot options to enable them.

slac-in-the-box · 04-04-2018, 06:13 PM

Quote:

That's odd. According to the Kconfig help information, those shouldn't actually do anything unless you use kernel boot options to enable them.

Well, that called for more trial and error; so I built another 4.15.15, with si parts, and cik parts enabled, and: it worked!

I test these kernels on an experimental partition that shares both the boot partition and the efi partition with my main luks+lvm parition / work environment. I should have had created a partition for /lib/modules as well, because I'm constantly copying the modules to the /lib/modules on the experimental partition; and sometimes in my haste and eagerness to test a kernel, I forget to, as must have been the case with that black screen -- black because it wasn't finding the module, not because of the kernel config. My bad. Glad to know I can leave the si parts and the cik parts checked, and it still works; and definitely glad to know that P.V. knows what he's talking about