SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,109
Original Poster
Rep:
The 4.14.4 kernel is running well here, but now there are other problems which seem to be the result of one package included in today's updates to -current; probably the new icu4c-60.1-x86_64-1.txz.
Last edited by cwizardone; 12-06-2017 at 03:56 PM.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,008
Rep:
Quote:
Originally Posted by cwizardone
The 4.14.4 kernel is running well here, but now there are other problems which seem to be the result of one package included in today's updates to -current; probably the new icu4c-60.1-x86_64-1.txz.
My understanding is that there are problems with linux 4.14.x either on intel 32bit or Ryzen?
Anyway, I have laptop with Haswell running 64bit so even though I started using 4.14.x as soon as it was first released by kernel.org I never had even single kernel crash. I do use my own config so kernel (I don't use initrd) is streamlined for specific hardware but I doubt that this helped. I assume that I am just lucky with hardware setup.
Regarding latest update: well after I rebooted, I ended up with system that did not recognize basic commands like installpkg or upgradepkg or removepkg. Of course GUI was gone. I am just happy that I never update main system before testing what interesting may happen by running update on virtual guest first, if this will go o.k. then I run update on the host. So this time it cost me just re-creating Slackware virtual guest..
The 4.14.4 kernel is running well here, but now there are other problems which seem to be the result of one package included in today's updates to -current; probably the new icu4c-60.1-x86_64-1.txz.
The 4.14.4 kernel is running well here, but now there are other problems which seem to be the result of one package included in today's updates to -current; probably the new icu4c-60.1-x86_64-1.txz.
Problems with custom packages, I suppose, not anything in base Slackware(?)
Quote:
Originally Posted by Aeterna
My understanding is that there are problems with linux 4.14.x either on intel 32bit or Ryzen? Anyway, I have laptop with Haswell running 64bit so even though I started using 4.14.x as soon as it was first released by kernel.org I never had even single kernel crash.
It was significantly more unstable in 32-bit indeed, but even on 64-bit there were some crashes encountered apparently, not sure about Ryzen. Ivy Bridge here, I never had any problem with 4.14 either.
I think that is likely to break the packages recompiled for the new icu4c in the same update. If you need to have things like that working again in a hurry, I'd advise to quickly point /etc/slackpkg/mirrors to a mirror that hasn't synced yet, and do a slackpkg upgrade-all to trigger downgrades. And consider not tracking -current too closely, or at all.
Example (at the time of posting, of course): https://ftp.heanet.ie/mirrors/ftp.sl...pub/slackware/
It was significantly more unstable in 32-bit indeed, but even on 64-bit there were some crashes encountered apparently, not sure about Ryzen. Ivy Bridge here, I never had any problem with 4.14 either.
I have a Ryzen and I'm having kernel issues, but it's not specific to the 4.14 kernel. It originally occurred when I tried the 4.13 (didn't try any earlier than that), so I moved to the RCs of 4.14 and it occurs there. But it isn't the same issues others have been reporting with their kernels from Pat. Mine has no problems booting and will typically run for several days until it just completely locks up. Sometimes it turns the monitor on and leave it in a frozen state on the desktop (when the monitor should be off based on the system blanking the display and putting it to sleep after the 20 or so minutes) and other times the monitors stay off.
I was able to solve my issues by enabling the expert options of RCU configuration and enabling the suboption of "Offload RCU callback processing from boot-selected CPUs". I also had to pass rcu_nocbs=0-15 to the kernel during boot (the 0-15 is based on how many threads your CPU supports, so a 12 thread system would be 0-11). But it sounds like the issues others are having are unrelated to the segfault on boot issue others are having. So, I don't think Ryzen is affected in that matter.
Fact is every time I had huge crashes it was after MariaDB it always broke samba unless I reinstalled it. Pat may know this been putting up with it for years freeze. but it is part of my circle now update reinstall.
I have not been able to make these crashes happen unless I upgrade kernel then reboot with grub vmlinuz-huge and a intrd from the previous kernel. Why would I do that because grub is a stupid problem wipes all my work. if you do not understand than do not worry. Wrong modules per kernel will not load and will not cause crash because they they never got entered. Cold start does not cause this problem for me.
Then hard power off then reboot do the same and it boots
this tells me the L2 instructions are stored and not cleared. So I wrote a script that updates the initrid.gz before rebooting with all modules.
If the ram on L2 is not cleared this problem started 18 months ago or more do not say you did not see it. Ok your blind to it.
why are they not cleared ask ask OLD bios. not new stuff.
It is pat's job to look for the bios issue not mine. How does Bios clear ROM. and the RAM.
I am sure there is a .config for the older stuff Hang in There Pat or Patch.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.