Cinnamon random lockups for 10-45 seconds

[spoo333]

That seems to be quite common nowadays.

yes unfortunately ...

There might be BIOS settings, but there are also kernel parameters one can tweak if having issues. Normally, one wants to run with as few kernel parameters as possible, so it is usually preferable to make the BIOS change if that change is appropriate to be made.

I believe there has been one person posting on the forum with what they refer to as micro-stutters, but the duration is much shorter than what you are seeing. I do not recall what cpu that was.

Thanks for the explanation. I'll check next time I can reboot.

From what I've read, that is only applicable if running from battery. Given the type of work you are doing, I would have thought the laptops would be plugged in.

Yes, almost all of the time they're plugged in. Just thought I'd mention it in case it could have an impact on sleep/wake states at all times. Good I can ignore it.

[motoryzen]

Yes, almost all of the time they're plugged in. Just thought I'd mention it in case it could have an impact on sleep/wake states at all times. Good I can ignore it.

Sorry if this seems incoherent or maybe even nosey, but if you know 99.99% of the time any laptops you are using are not being moved from a desk while being used...you should consider removing the battery when they are completely shut down, then power them on as needed while power cord is plugged in.

This ensures the overall longevity of that battery retaining a proper charge as well as how consistently it can recharge....lasts much longer.

[spoo333]

Sorry if this seems incoherent or maybe even nosey, but if you know 99.99% of the time any laptops you are using are not being moved from a desk while being used...you should consider removing the battery when they are completely shut down, then power them on as needed while power cord is plugged in.

This ensures the overall longevity of that battery retaining a proper charge as well as how consistently it can recharge....lasts much longer.

Yes I agree, that would be a good idea if removing the batteries didn't require major "laptop surgery", if you know what I mean

[motoryzen]

if removing the batteries didn't require major "laptop surgery", if you know what I mean

Ah..sorry you didn't post any inxi -Fxxxrz info so I didn't know any of those laptops's battery's weren't the normal easily removable ones. That sucks.

[SMG]

It's my understanding the surgically implanted batteries are supposed to have additional controls to minimize cycling effects which affected the life of older style batteries.

[spoo333]

When it becomes necessary, I'll get replacement batteries

It's my understanding the surgically implanted batteries are supposed to have additional controls to minimize cycling effects which affected the life of older style batteries.

Fingers crossed looking good so far

[spoo333]

Hello, just a quick update:

the generic kernel laptop has finally had a complete lockup/freeze too. I'm pretty certain now that generic/lowlatency kernel makes no difference.
The Ubuntu Cinnamon Remix 21.10 laptop with low-latency kernel laptop I've only 'managed' to do a partial freeze on so far, but it hasn't been used nearly as much as the other two.

Since the freezes on the desktop were getting more regular, I decided to throw caution in the wind and try the daily builds ppa. I know that by being in pre-release territory I can't be surprised if something plays up I don't have the feeling that overall system stability has changed much. This is obviously not a precise observation, but I get the feeling that with some unstable cinnamon builds, freeze/lockup regularity increases and with others it decreases. This could be purely coincidental of course.

One last thing: I wonder if I can remove Timeshift from the potential culprit list as well. If up to 3 freezes/lockups (that get resolved, like they all do!!) happen within an hour, then it seems unlikely to me that an hourly Timeshift snapshot could be responsible for all 3 of those lockups, within one hour.

Can you recommend another DE (other than Gnome) that I could try on Mint, ideally one that allows a user experience similarish to Cinnamon. Thanks

[SMG]

Since the freezes on the desktop were getting more regular, I decided to throw caution in the wind and try the daily builds ppa.

Daily PPA builds of what?

Can you recommend another DE (other than Gnome) that I could try on Mint, ideally one that allows a user experience similarish to Cinnamon. Thanks

Gnome is not a supported desktop for Mint. Mint has three supported desktops, Cinnamon, MATE, and Xfce.

[SMG]

Moderator note: davey's post can now be found here Random freezes. Freezes can be very dependant on the hardware used and davey has different hardware.

[spoo333]

Daily PPA builds of what?

Mint Daily Builds

Gnome is not a supported desktop for Mint. Mint has three supported desktops, Cinnamon, MATE, and Xfce.

I've installed MATE as a secondary DE to see if I get temporary freezes/lockups there too.

[SMG]

Mint Daily Builds

Why work to make a stable desktop when you can deliberately try to have one which might not be stable.

Have worked with several people who found making adjustments in BIOS to C-states have seemed to stabilize their installs. (Disabling the C states on a desktop.) However, those situations were slightly different than yours. I posted this snippet about C-states on one topic this morning. I do not know how that might effect the type of work you are doing.

[spoo333]

Why work to make a stable desktop when you can deliberately try to have one which might not be stable.

How did you guess??

Have worked with several people who found making adjustments in BIOS to C-states have seemed to stabilize their installs. (Disabling the C states on a desktop.) However, those situations were slightly different than yours. I posted this snippet about C-states on one topic this morning. I do not know how that might effect the type of work you are doing.

Thank you, I'll try BIOS modifications now

[spoo333]

I've disabled C-states on the desktop

[spoo333]

I've disabled C-states on the desktop

The lock-up/freeze lengths and regularities appear to have diminished with C-states off. Now the longest it takes to get control back is around twenty seconds, usually within five.

[SMG]

The lock-up/freeze lengths and regularities appear to have diminished with C-states off. Now the longest it takes to get control back is around twenty seconds, usually within five.

That is an interesting and positive development. Do you have a P-state or Turboboost options available? The below are in reference to servers, but they are what came up when I searched on "C-states, low latency kernels".

AWS: Processor state control for your EC2 instance has some interesting information.

C-states control the sleep levels that a core can enter when it is idle. C-states are numbered starting with C0 (the shallowest state where the core is totally awake and executing instructions) and go to C6 (the deepest idle state where a core is powered off). P-states control the desired performance (in CPU frequency) from a core. P-states are numbered starting from P0 (the highest performance setting where the core is allowed to use Intel Turbo Boost Technology to increase frequency if possible), and they go from P1 (the P-state that requests the maximum baseline frequency) to P15 (the lowest possible frequency).
...
C-states control the sleep levels that a core may enter when it is inactive. You may want to control C-states to tune your system for latency versus performance. Putting cores to sleep takes time, and although a sleeping core allows more headroom for another core to boost to a higher frequency, it takes time for that sleeping core to wake back up and perform work. For example, if a core that is assigned to handle network packet interrupts is asleep, there may be a delay in servicing that interrupt. You can configure the system to not use deeper C-states, which reduces the processor reaction latency, but that in turn also reduces the headroom available to other cores for Turbo Boost.
...
You can reduce the variability of processor frequency with P-states. P-states control the desired performance (in CPU frequency) from a core. Most workloads perform better in P0, which requests Turbo Boost. But you may want to tune your system for consistent performance rather than bursty performance that can happen when Turbo Boost frequencies are enabled.

And some older info Low Latency Performance Tuning for Red Hat Enterprise Linux 7 indicates:

Many server vendors have published BIOS configuration settings geared for low-latency
environments. Carefully follow these recommendations, which may include disabling logical
processors, frequency boost or hardware monitoring.

After implementing low latency tuning guidelines from the server vendor, verify CPU
frequencies (p-states) and idle states (c-states) using the turbostat utility (see example
below). Turbostat is included in the cpupowerutils package in Red Hat Enterprise Linux 6, or
the kernel-tools package in Red Hat Enterprise Linux 7.

Here is Debian Manpage for turbostat.

[spoo333]

That is an interesting and positive development. Do you have a P-state or Turboboost options available? The below are in reference to servers, but they are what came up when I searched on "C-states, low latency kernels".

Thanks, I'll check this

AWS: Processor state control for your EC2 instance has some interesting information.

C-states control the sleep levels that a core can enter when it is idle. C-states are numbered starting with C0 (the shallowest state where the core is totally awake and executing instructions) and go to C6 (the deepest idle state where a core is powered off). P-states control the desired performance (in CPU frequency) from a core. P-states are numbered starting from P0 (the highest performance setting where the core is allowed to use Intel Turbo Boost Technology to increase frequency if possible), and they go from P1 (the P-state that requests the maximum baseline frequency) to P15 (the lowest possible frequency).
...
C-states control the sleep levels that a core may enter when it is inactive. You may want to control C-states to tune your system for latency versus performance. Putting cores to sleep takes time, and although a sleeping core allows more headroom for another core to boost to a higher frequency, it takes time for that sleeping core to wake back up and perform work. For example, if a core that is assigned to handle network packet interrupts is asleep, there may be a delay in servicing that interrupt. You can configure the system to not use deeper C-states, which reduces the processor reaction latency, but that in turn also reduces the headroom available to other cores for Turbo Boost.
...
You can reduce the variability of processor frequency with P-states. P-states control the desired performance (in CPU frequency) from a core. Most workloads perform better in P0, which requests Turbo Boost. But you may want to tune your system for consistent performance rather than bursty performance that can happen when Turbo Boost frequencies are enabled.

And some older info Low Latency Performance Tuning for Red Hat Enterprise Linux 7 indicates:

Many server vendors have published BIOS configuration settings geared for low-latency
environments. Carefully follow these recommendations, which may include disabling logical
processors, frequency boost or hardware monitoring.

After implementing low latency tuning guidelines from the server vendor, verify CPU
frequencies (p-states) and idle states (c-states) using the turbostat utility (see example
below). Turbostat is included in the cpupowerutils package in Red Hat Enterprise Linux 6, or
the kernel-tools package in Red Hat Enterprise Linux 7.

Here is Debian Manpage for turbostat.

Thank you for the links. This https://www.golinuxhub.com/2018/06/what ... ore-linux/ could also prove useful. Sounds like the OS can ignore hardware C-state settings and specifies a way to limit c-states on boot. I haven't finished reading it yet and obviously not tried yet either.
Finding the volume of info that turbostat provides a little overwhelming turbostat --debug works better for my requirements? If I read the output correctly, most of the cpus are still in higher c-states according to the percentages given, despite the c-state limits set in the bios.

[spoo333]

The Ubuntu Cinnamon Remix 21.10 laptop with low-latency kernel laptop I've only 'managed' to do a partial freeze on so far, but it hasn't been used nearly as much as the other two.

update re the Ubuntu Cinnamon Remix 21.10 laptop. Have managed to produce a full lock-up/freeze on this one too. Meaning I can reinstall Linux Mint

[SMG]

Thank you for the links. This https://www.golinuxhub.com/2018/06/what ... ore-linux/ could also prove useful. Sounds like the OS can ignore hardware C-state settings and specifies a way to limit c-states on boot.

I've always assumed one would use kernel parameters to handle C-states changes because there were no options available to do it in the hardware (such as with many laptops), however, that could be an incorrect assumption on my part.

Finding the volume of info that turbostat provides a little overwhelming turbostat --debug works better for my requirements? If I read the output correctly, most of the cpus are still in higher c-states according to the percentages given, despite the c-state limits set in the bios.

I've helped a few people research those options, but so far only have feedback on disabling them in total. I do not know what other tweaks might be possible.

[spoo333]

I've always assumed one would use kernel parameters to handle C-states changes because there were no options available to do it in the hardware (such as with many laptops), however, that could be an incorrect assumption on my part.

No, quite the opposite, you are right - the only way to disable c-states is to disable them completely (which I haven't managed yet via the BIOS), and to do this via kernel parameters. I haven't had the time to figure out how to disable all c-states via kernel parameters. Once I have I'll try it on the laptop with the lowlatency kernel.

Update re generic/lowlatency kernel. Switched to generic kernel on the desktop and was greeted by the longest lock-up/freeze in quite a while

[SMG]

Update re generic/lowlatency kernel. Switched to generic kernel on the desktop and was greeted by the longest lock-up/freeze in quite a while

Your computers are laughing at our attempts to control them.

I am pretty much out of ideas of what might be happening. I'm sure there is a logical reason somewhere as to what is happening, but I don't have enough knowledge about the inner workings of the kernel to know what else might be a factor at this point.