Found this thread while looking for another issue but I think I know what was going on, even if I'm several years late to the party. I don't care whatsoever about "necroing" threads like this: if they come up in google searches and don't have a clear resolution, I consider them fair game bc it might actually *help* someone else, even if it's too late for OP.
That said, I had similar issues to this on another PC (it was an older
ASRock htcore mini pc) that also had integrated Intel graphics. I still happened to have the debug notes for that pc as well as the solution I used so I will post them here to avoid the
relevant xkcd.
Code: Select all
$ inxi -F
System:
Host: htpc Kernel: 5.3.0-28-generic x86_64 bits: 64
Desktop: Cinnamon 4.4.8 Distro: Linux Mint 19.3 Tricia
Machine:
Type: Desktop Mobo: ASRock model: HM65-HT serial: <root required>
BIOS: American Megatrends v: P1.10 date: 08/22/2011
CPU:
Topology: Dual Core model: Intel Core i5-2520M bits: 64 type: MT MCP
L2 cache: 3072 KiB
Speed: 798 MHz min/max: 800/3200 MHz Core speeds (MHz): 1: 880 2: 1032
3: 842 4: 865
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel
Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa
resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile v: 3.3 Mesa 19.2.8
Audio:
Device-1: Intel 6 Series/C200 Series Family High Definition Audio
driver: snd_hda_intel
Sound Server: ALSA v: k5.3.0-28-generic
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169
IF: enp2s0 state: down mac: <redacted>
Device-2: Qualcomm Atheros AR9287 Wireless Network Adapter driver: ath9k
IF: wlp5s0 state: down mac: <redacted>
Device-3: ASIX AX88179 Gigabit Ethernet type: USB driver: ax88179_178a
IF: enx00249b16b185 state: up speed: 1000 Mbps duplex: full
mac: <redacted>
IF-ID-1: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A
Drives:
Local Storage: total: 1.36 TiB used: 867.19 GiB (62.1%)
ID-1: /dev/sda vendor: Western Digital model: <redacted>
size: 465.76 GiB
ID-2: /dev/sdb vendor: Western Digital model: <redacted>
size: 931.51 GiB
Partition:
ID-1: / size: 453.78 GiB used: 35.73 GiB (7.9%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 3.72 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda3
Sensors:
System Temperatures: cpu: 48.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 200 Uptime: 38m Memory: 3.57 GiB used: 1.64 GiB (45.9%)
Shell: bash inxi: 3.0.32
In my case, it was related to the Intel CPU idle state (e.g. how the kernel managed my specific hardware - and this applied on other distros as well. I know for certain I had the issue under several major versions of Mint as well as under Fedora. I think I also encountered it under a Manjaro livedisc too).
Confirming:
If you have an older Intel cpu targeted at smaller builds or laptops and are getting random freezes, check your c-state with
cat /sys/module/intel_idle/parameters/max_cstate. If you have 6 or 9 or really anything higher than 1, then it might be worth trying the solution to see if it works (you can always use the same steps to revert it if it does not solve your crashes). Do note that since it is changing cpu idle state, you will probably incur higher battery usage but IMO this is better than random freezes, especially if you generally use it while connected to a power outlet.
Solution:
Make a backup of your grub file with
sudo cp -a /etc/default/grub /etc/default/grub.$(date +'%Y-%m-%d_%H%M%S').bak just in case. Then you will need to open the file as root with some kind of text editor and modify the
GRUB_CMDLINE_LINUX line as shown and save the file. If you are not comfortable using vi or nano with sudo, then you can open Nemo ("Files" in the "start" menu) and browse to "File system" > /etc > then right-click on the "default" folder and choose "Open as root". In the root instance of Nemo, make sure you are in /etc/default then right-click on the "grub" file and choose Open with > Text editor. This should open it in the xed text-editor unless you have changed preferences to use something else.
If
GRUB_CMDLINE_LINUX is empty then just replace the line with
GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1" and save. If you have some value in there already, first make sure there is no
intel_idle.max_cstate=<some number>, if there is, then replace it with
intel_idle.max_cstate=1. Otherwise, just add the new argument in front of the other arguments like so:
GRUB_CMDLINE_LINUX="intel_idle.max_cstate=1 <old arguments>".
SAVE THE FILE then re-open it and confirm that your changes are there and they are correct (if you mess up Grub your system can become unbootable or at least very difficult to boot so it's worth spending a minute to
CAREFULLY check that it has everything and there are no errors / typos).
Finally, you will need to have grub regenerate its config files (then reboot) for the changes to take effect. Most systems these days use UEFI instead of legacy BIOS mode for booting. But on older systems you might be more likely to find legacy BIOS mode. In many distros, the mode your OS is running in effects which command you need to run to regenerate grub. But for Ubuntu/Mint (maybe Debian also?), there is an "update-grub" command which simplifies this. I'm mentioning it bc on Fedora and some other distros this command does not exist and despite the forum, I prefer to give distro-agnostic solutions when possible.
On Mint, you can run: `sudo update-grub` then reboot the PC.
On
NON-Mint/NON-Ubuntu-based distros (e.g. Fedora, OpenSUSE, Manjaro, etc), you'll first need to check if you are using BIOS or UEFI mode. If you have the folder
/sys/firmware/efi then you are using UEFI mode; otherwise, you're probably using BIOS mode. For regenerating your Grub config under BIOS mode, the command will probably look something like this (I recommend googling "<your distro> regenerate grub <uefi or bios>" first to make sure):
sudo grub2-mkconfig -o /boot/grub2/grub.cfg. Under UEFI, it might vary. My notes say I used
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg when I was on Fedora with UEFI but obviously that path is distro-specific; like with the BIOS command, you'll want to google for your distro specifically. Same as with Mint, once this command completes, reboot the pc.
Anyway, when the PC comes back up from reboot and you log in, you can confirm the change worked by rerunning
cat /sys/module/intel_idle/parameters/max_cstate and checking that your idle state is now 1.
Sources:
