Slackware 15 on Chromebox freezing occasionally and running out of memory
Hello...
I recently installed Slackware 15 on a converted Chromebox with updated firmware to coreboot (UEFI). It's been 14 years since I looked at Slackware and it is at once timely yet timeless--a classic. I installed and found the installation the same after all these years! Sadly, there are two big issues that I do not have an immediate answer for. First, The desktop will freeze. I can move the mouse and the caps lock works but nothing on the desktop will work or function correctly. I have to do a hard reset. And even the hard reset would reboot the machine but fail to start X. It complained about not being able to find the server and to check server logs. Secondly, I installed a Memory Usage widget on the desktop and the next time it froze, I noticed that memory usage consumed the whole 128GB of my hard drive! Needless to say, I had to reset again. The reset usually fixes this but is there something I can do to fix this? Sounds like a memory leak of some sort to me. Other distributions--notably, Arch and Debian--do not have these issues on the same machine. Thanks for your help. |
You will need to provide some information for us so we can help you.
Run the command lsblk -f and post the results. This will show your partition scheme and available space. Also, please post the output of inxi -bm. Paste the results between quote tags so the output is readable. |
lsblk -f and inxi -bm
lsblk -f:
"sda ├─sda1 │ vfat FAT32 C454-5328 482.5M 6% /boot/efi ├─sda2 │ swap 1 96cbbe3e-0c00-4802-8e5e-126b8aeffd32 [SWAP] ├─sda3 │ ext4 1.0 c938b745-293d-4bee-8459-0088a01b2233 35.4G 34% / └─sda4 ext4 1.0 3adb27be-f3fd-4f28-a05d-91d0ce577a90 44.8G 6% /home" inxi -bm: " Desktop: KDE Plasma 5.23.5 Distro: Slackware 15.0 Machine: Type: Desktop System: GOOGLE product: Panther v: 1.0 serial: <superuser required> Mobo: GOOGLE model: Panther v: 1.0 serial: <superuser required> UEFI: coreboot v: MrChromebox-4.20.0 date: 05/15/2023 Memory: RAM: total: 3.72 GiB used: 1.46 GiB (39.4%) RAM Report: permissions: Unable to run dmidecode. Root privileges required. CPU: Info: dual core Intel Celeron 2955U [MCP] speed (MHz): avg: 813 min/max: 800/1400 Graphics: Device-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel Display: x11 server: X.Org 1.20.14 driver: loaded: modesetting unloaded: vesa resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics (HSW GT1) v: 4.5 Mesa 21.3.5 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Device-2: Qualcomm Atheros AR9462 Wireless Network Adapter driver: ath9k Drives: Local Storage: total: 119.24 GiB used: 23.18 GiB (19.4%) Info: Processes: 197 Uptime: 3h 4m Shell: Bash inxi: 3.3.12" Thanks |
You did not use code tags, and have not captured all the information from the lsblk -f command.
Here is what it looks like when you get all the data, and use code tags. Quote:
Quote:
To use quote tags, look at the top left of the Quick Reply box, you will see some icons. Click the right most one, it will insert a pair of tags. Insert any data between them. If you go to Advanced mode, there are more options for pasting different types of data. Did you do a full install? |
results
I used quotes instead of the code tag. My fault. The memory usage widget showed 128gb of 128gb used when the desktop froze.
Then upon reboot complained that it could not connect with x server. Eventually it hooks up and boots normally. Again it seems like a memory leak of some kind. Arch and Debian have no issues. I always do the full installation. Any idea on what could be happening? |
This is not making sense. Your ram from inxi shows
Code:
RAM: total: 3.72 GiB used: 1.46 GiB (39.4%) Your HD is 128 gig and is not full. I have no idea why the memory usage would show 128 gig when you have 4 gig. Is your swap being used? Could you move the mouse pointer when the "freezing" happened? |
Think this through...
Think about it...
My computer freezes. I have a memory widget on the desktop that shows what % of ram I am using at any given moment. Now, if my computer freezes and this widget shows 128gb used, obviously there is an issue whether I have 4GB or not. It's frozen but may indicate the problem. I was asked to provide the output of several commands. Of course, it shows only a little bit of ram usage because I can only print the commands when the computer is NOT frozen. So, you're scratching your head wondering why it is only showing 1.6GB used? It shows that because I can only print the output when the system is running normally. This should be obvious. When the system freezes and locks, the memory widget showed 128GB--probably in error but that's what it showed nonetheless. I can only move the cursor but click on nothing to activate. You are puzzled by what you're seeing because I can't print a command from a frozen system. Then when you ask for the output of the command, it is when the system is under normal load and not frozen. Do you understand, now? |
(Part of the understandable confusion here is that your problem report initially said "the whole 128GB of my hard drive" was consumed. So you're getting requests for more information about your hard drive(s), how they are partitioned etc. But now you're saying the memory widget you installed reports RAM utilization, which is a different resource entirely.)
Something I'd probably do if I ran into a hanging problem that looks like a memory leak is keep a "sudo dmesg -W" running in a window somewhere, being careful not to cover it up. The thought here is that the last few kernel messages might still be visible in the window after the system hangs. One of the useful (but also annoying) things the Linux kernel does when RAM is overconsumed is try to intelligently identify the process that ate most of it, at which point it kills the process and logs messages about what happened. |
The widget stated that 128GB was used--which is the size of the hard drive. That's why I stated it that way.
|
What's disappointing is that no other distribution presents this problem. I thought Slackware was better than what I have experienced.
Just disappointing... |
Mark the thread closed.
|
Quote:
You have something filling ram, not your HD. I also understand you are running this on a chromebox. This may well be the source of your problems. Right now there is no clear indication this is a hardware failure of software failure. I also understand your frustration. Chrome devices are usually stripped of as much as possible, that is the strategy the makers use to get them out the door at the lowest price possible. Your choice if you want to give up. |
I have been running Linux for over 20 years. I have had chromeboxes running Linux for over 5 years. This is not a hardware issue. It is definitely a software issue as Arch and Debian run on these boxes just fine.
Close the thread, please. Thanks |
You are the only one that can close the thread.
|
Quote:
|
All times are GMT -5. The time now is 05:12 PM. |