[SOLVED] Occasional system freeze after the latest update in Slackware64 --curent
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.
However, VirtualBox would not run. I tried several things per the VBox error message -- didn't work. I tried reinstalling VirtualBox -- didn't work. I tried installing ALL of the slackpkg updates, not just the kernel -- didn't work. Finally, I downloaded and installed the latest VirtualBox (6.1.22) and that finally worked.
I know you already figured your issue out, but with major kernel updates, if VirtualBox breaks, it is almost always because the version you're using doesn't support that kernel. Most of the time, simply updating to the latest version will fix it, but sometimes you might need to upgrade to their "testing" versions.
Quote:
Originally Posted by mfoley
Question: Should I put the PRIORITY config back the way it was or leave it with "testing" in the 2nd position. I'd rather keep more conservative with packages installed, even if the kernel version is later. Too late for that?
If you do, it will suggest you downgrade your kernel packages to the 5.10 series. The only other package in testing/ is mariadb. Since the kernel packages are more likely to see frequent updates than mariadb, if you want to keep the stock (not testing/) version, you could install that manually and then blacklist it. Then just pay attention to the changelog to see if it's updated at all.
Thanks! So, if I understand you correctly, everything that 'slackpkg update' downloaded with "testing" 2nd in priority was, in fact, normal stuff since only kernel and mariadb are actually in "testing". That means that even with "testing" in the last priority position, I'm going to get all those same updates to other packages anyway next time I upgrade, right?
So basically, I should just re-do the update from testing for the kernel, then blacklist the kernel until non-testing catches up, and put the testing priority back to last position.
Unless you/someone tells me I'm wrong with these assumptions, I try this tomorrow.
So basically, I should just re-do the update from testing for the kernel, then blacklist the kernel until non-testing catches up, and put the testing priority back to last position.
Unless you/someone tells me I'm wrong with these assumptions, I try this tomorrow.
I'd probably reverse that and keep testing in front and then blacklist mariadb (and revert it to the main package version instead of the testing/). This is because the kernel is likely to get many more updates than mariadb (unless you don't intend to install additional 5.12.x updates as Pat pushes them out).
So basically, I should just re-do the update from testing for the kernel, then blacklist the kernel until non-testing catches up, and put the testing priority back to last position.
Unless you/someone tells me I'm wrong with these assumptions, I try this tomorrow.
Quote:
Originally Posted by bassmadrigal
I'd probably reverse that and keep testing in front and then blacklist mariadb (and revert it to the main package version instead of the testing/). This is because the kernel is likely to get many more updates than mariadb (unless you don't intend to install additional 5.12.x updates as Pat pushes them out).
Agree with this. Keep testing before %PKGMAIN and blecklist mariadb after making sure the "stock" mariadb is installed vice the testing version.
I've never encountered any freezing on my Thinkpad T460. Today was the first time. I have Current Slack-64 with 5.10.34 and XFCE onboard.
I looked into the /var/log/syslog and found this:
Code:
May 11 11:31:16 darkstar kernel: x86/cpu: VMX (outside TXT) disabled by BIOS
May 11 11:31:16 darkstar kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
May 11 11:31:16 darkstar kernel: TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more details.
May 11 11:31:16 darkstar kernel: #3
May 11 11:31:16 darkstar kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
May 11 11:31:17 darkstar kernel: resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
May 11 11:31:17 darkstar kernel: caller snb_uncore_imc_init_box+0x78/0xc0 mapping multiple BARs
I can't speak to the rest of the output, but these two lines are to warn you that your CPU is vulnerable to Spectre and Meltdown:
Code:
May 11 11:31:16 darkstar kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
May 11 11:31:16 darkstar kernel: TAA CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html for more details.
The way to fix this properly is to disable HyperThreading.
@brodo: I was recently given an old laptop, an HP Pavilion dv6010 from 2011 with an Intel Core-i5 processor and I installed -current on it. It runs OK as-is, but when I inserted the intel-microcode to the initrd it began freezing.
The updated microcode supposedly helps mitigate some of the Spectre and Meltdown variants and that's why I'm using it on all of my other computers, these have processors Core 2 Duo, i3, i5, i7 and Celeron. None of them ever had any issues with the microcode (under various kernels).
I don't know how much this new issue depends on the kernel used, I didn't try running another kernel version on that device. I'm reporting it here in case you are in a similar situation.
Agree with this. Keep testing before %PKGMAIN and blecklist mariadb after making sure the "stock" mariadb is installed vice the testing version.
I just kept "testing" as the priority and didn't bother blacklisting mariadb as I don't use that on this machine anyway.
Nevertheless, the newer 5.12.2 kernel did not stop the KDE freezing. It's frozen 3 time in the past 3 days since installing 5.12.2, with a gap of more than two days between the first and the most recent. Interestingly, it seems to freeze when at the login screen (after auto-locking due to inactivity). The clock on the login screen shows the correct time right up until I start typing, then no characters in the password box and the clock freezes. The machine is still running. I can ssh in remotely and either init 3/init4 or reboot. Does this provide some clues? Unfortunately, I don't have any tell-tale messages in syslog as with brodo's "data leak" message.
I just kept "testing" as the priority and didn't bother blacklisting mariadb as I don't use that on this machine anyway.
Nevertheless, the newer 5.12.2 kernel did not stop the KDE freezing. It's frozen 3 time in the past 3 days since installing 5.12.2, with a gap of more than two days between the first and the most recent. Interestingly, it seems to freeze when at the login screen (after auto-locking due to inactivity). The clock on the login screen shows the correct time right up until I start typing, then no characters in the password box and the clock freezes. The machine is still running. I can ssh in remotely and either init 3/init4 or reboot. Does this provide some clues? Unfortunately, I don't have any tell-tale messages in syslog as with brodo's "data leak" message.
My freeze is a bit different. I boot to runlevel 3, the freeze only happens (occasionally, not all the time) after I log out. Instead of showing the messages you normally see after logging out it freezes with this.
Code:
startx
xauth: file /home/chris/.serverauth.10789 does not exist
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: Slackware 15.0 Slackware Linux Project
Current Operating System: Linux racermach.home.arpa 5.12.4 #1 SMP Fri May 14 13:18:43 CDT 2021 x86_64
Kernel command line: auto BOOT_IMAGE=Testing ro root=801
Build Date: 13 April 2021 12:31:51PM
Current version of pixman: 0.40.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat May 15 18:05:52 2021
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Keyboard, mouse do nothing. I can use the ON/OFF button to signal a shutdown. I can also login via ssh and shutdown or reboot. I've even ran slackpkg to process an update from the ssh session. You gave me the idea to try init and see what happens, next time this happens.
Last edited by chrisretusn; 05-15-2021 at 05:17 AM.
Reporting in on the KDE freeze. I upgraded my system to Slackware-Current 5.12.6 and KDE 5.21.5 four days ago and it is far worse than with 5.12.2. With 5.12.2 KDE would freeze up every few days, with 5.12.6 it freezes several times a day, regardless of whether I'm running VBox (which I now don't run unless I need to). I guess we're a long way from being able to move off of 14.2 for stable use!
I believe I have discovered the problem (not the solution) with KDE spontaneously hanging and sometimes restarting: KDE5! I finally got around to changing to XFCE as my desktop. I have been running that for nearly a week with the same kernel 5.12.6 as before and VirtualBox running continuously during that time. I've had no hangs/restarts of the desktop at all, whereas with KDE and the latest update I was hanging and/or restarting 3 and 4 times a day.
I do like the Windows7-like KDE desktop better than XFCE, which will take a bit of getting used to, but I generally spent very little time in the desktop itself other than to launch programs. However, it seems the hang/restart problem must be with KDE so I'll simply get used to XFCE.
I don't know if the Slackware developers monitor this thread, but in case this inspires some research, here's my setup: I have an ASRock 970M Pro3 motherboard with AMI P1.60 BIOS and 16G of memory, 8 of which is usually dedicated to the Virtual Machine. I have an AMD FX-8320E CPU. I have two GeForce GT 710 NVIDIA GK208B video cards, each with two monitors connected. On one monitor I run Firefox with about a dozen tabs open. On another I run typically 4 Konsole sessions. On the third I run Thunderbird. On the 4th I run VirtualBox with a Windows 10 guest. I also have Dolphin and Kate opened always, and I use the LibreOffice Write and Calc frequently.
I would be happy to do testing with KDE if asked.
Since I've "solved" my issue, I'll check back with this thread on occasion and possibly give KDE a shot periodically. Since I no longer get email notices of posts to LQ for some reason, even for my own threads, I'll just have to check back here every so often.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 932
Rep:
Quote:
Originally Posted by mfoley
I believe I have discovered the problem (not the solution) with KDE spontaneously hanging and sometimes restarting: KDE5!
Some
As a test, you could run Xfce with kwin as a compositor to see if it crashes too.
Boot from AlienBob's Plasma liveslak to see what happens (I'm seeing some "bugs" with my -current install,
but they don't happen in a virtual machine VBox fresh install).
What happens if you change the video driver? nouveau for NVidia and vice versa.
I changed my DE to KDE (I run Xfce) and it is running for some hours without problems.
I will run it for one day or two to see if it crashes.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
