[SOLVED] Mint Cinnamon 20.3 reboot after resume Intel i5-10400

[chippywood]

I've just upgraded my Mint system to 20.3 on upgraded hardware (Intel i5-10400) and am experiencing occasional reboots after resuming from suspend. When it does happen, it's within a short time after resume, and seemingly only if I do nothing after typing the unlock password; that is, if I interact with the system - start something, stop something - it doesn't happen.

I found a similar report that was unresolved: viewtopic.php?t=348089. It may be relevant that the reporter was also running on relatively new, faster hardware.

System config:

Code: Select all

System:    Kernel: 5.4.0-121-generic x86_64 bits: 64 compiler: gcc v: 9.4.0 
           Desktop: Cinnamon 5.2.7 wm: muffin dm: LightDM Distro: Linux Mint 20.3 Una 
           base: Ubuntu 20.04 focal 
Machine:   Type: Desktop System: ASUS product: N/A v: N/A serial: <filter> 
           Mobo: ASUSTeK model: PRIME B460M-A v: Rev 1.xx serial: <filter> 
           UEFI: American Megatrends v: 1401 date: 07/27/2020 
CPU:       Topology: 6-Core model: Intel Core i5-10400 bits: 64 type: MT MCP arch: N/A 
           L2 cache: 12.0 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 69597 
           Speed: 4000 MHz min/max: 800/4300 MHz Core speeds (MHz): 1: 4000 2: 4000 3: 4000 
           4: 4000 5: 4000 6: 4000 7: 4003 8: 4002 9: 4003 10: 4000 11: 3999 12: 4001 
Graphics:  Device-1: Intel vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 
           chip ID: 8086:9bc5 
           Display: x11 server: X.Org 1.20.13 driver: modesetting unloaded: fbdev,vesa 
           resolution: 2560x1440~60Hz 
           OpenGL: renderer: Mesa Intel UHD Graphics 630 (CML GT2) v: 4.6 Mesa 21.2.6 
           direct render: Yes 
Audio:     Device-1: Intel vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           chip ID: 8086:a3f0 
           Sound Server: ALSA v: k5.4.0-121-generic 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK 
           driver: r8169 v: kernel port: 3000 bus ID: 04:00.0 chip ID: 10ec:8168 
           IF: enp4s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 912.89 GiB used: 41.10 GiB (4.5%) 
           ID-1: /dev/nvme0n1 vendor: Western Digital model: WD Blue SN570 500GB size: 465.76 GiB 
           speed: 31.6 Gb/s lanes: 4 serial: <filter> 
           ID-2: /dev/sda vendor: Crucial model: CT480BX500SSD1 size: 447.13 GiB speed: 6.0 Gb/s 
           serial: <filter> 
Partition: ID-1: / size: 456.96 GiB used: 41.10 GiB (9.0%) fs: ext4 dev: /dev/nvme0n1p2 
USB:       Hub: 1-0:1 info: Full speed (or root) Hub ports: 12 rev: 2.0 chip ID: 1d6b:0002 
           Device-1: 1-7:2 info: Logitech M-BJ58/M-BJ69 Optical Wheel Mouse type: Mouse 
           driver: hid-generic,usbhid rev: 2.0 chip ID: 046d:c00e 
           Device-2: 1-10:3 info: Alcor Micro Flash Card Reader/Writer type: Mass Storage 
           driver: usb-storage rev: 2.0 chip ID: 058f:6362 
           Hub: 2-0:1 info: Full speed (or root) Hub ports: 8 rev: 3.0 chip ID: 1d6b:0003 
Sensors:   System Temperatures: cpu: 27.8 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Repos:     No active apt repos in: /etc/apt/sources.list 
           Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
           1: deb https: //www.mirrorservice.org/sites/packages.linuxmint.com/packages una main upstream import backport
           2: deb http: //mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu focal main restricted universe multiverse
           3: deb http: //mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
           4: deb http: //mirror.ox.ac.uk/sites/archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
           5: deb http: //security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
           6: deb http: //archive.canonical.com/ubuntu/ focal partner
Info:      Processes: 310 Uptime: 4h 55m Memory: 15.48 GiB used: 2.60 GiB (16.8%) Init: systemd 
           v: 245 runlevel: 5 Compilers: gcc: 9.4.0 alt: 9 Client: Unknown python3.8 client 
           inxi: 3.0.38 

There are no crash reports. Immediately prior to at least some of the reboots there were screensaver msgs in syslog:

Code: Select all

Jun 22 12:17:25 Home cinnamon-screensaver-pam-helper: pam_ecryptfs: seteuid error
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Trying to connect to logind...
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Starting screensaver...
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Cinnamon Screensaver support not found in current theme - adding some...
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Successfully using logind
Jun 22 12:17:55 Home cinnamon-session[1079]: WARNING: t+5583.50151s: Detected that screensaver has left the bus
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Error in sys.excepthook:
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Original exception was:
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Error in sys.excepthook:
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Original exception was:
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Error in sys.excepthook:
Jun 22 12:17:55 Home org.cinnamon.ScreenSaver[15238]: Original exception was:

There's sometimes a corrupted log entry at this point (binary zeros). The "pam_ecryptfs: seteuid error" msg appears often, but not always with the "Error in sys.excepthook" msgs.

I could do with some advice for where best to find further information. I've looked in various logs (syslog, dmesg, boot) but can't pretend to know how to interpret their info, particularly as I'm confused by the sequence messages sometimes appear in.

Thanks,
Chris

[kato181]

With a newer system like yours I would try the edge.iso version of LM 20.3. It is Cinnamon.

[SMG]

I've just upgraded my Mint system to 20.3 on upgraded hardware (Intel i5-10400) and am experiencing occasional reboots after resuming from suspend.

The 5.4 kernel is too old for that CPU. Please upgrade to a newer kernel available in Update Manager.

Instructions for upgrading to the 5.13 kernel:

• Open Update Manager.
• Select View > Linux Kernels and click Continue.
• Make sure 5.13 is selected on the left panel and then click the top-most option on the right panel. An "Install" button will appear.
• Install the kernel and then reboot for it to become active.

Please also check to make sure you are running the most recent BIOS/UEFI available for your system.

I found a similar report that was unresolved: viewtopic.php?t=348089. It may be relevant that the reporter was also running on relatively new, faster hardware.

What is relevant is that person had different hardware and they had already upgraded to what was the newest kernel at that time (that topic is more than a year old).

[chippywood]

The 5.4 kernel is too old for that CPU. Please upgrade to a newer kernel available in Update Manager.
...
Please also check to make sure you are running the most recent BIOS/UEFI available for your system.

I did both and have not experienced any problems since.The BIOS/UEFI was fairly up to date but I upgraded it anyway. Many thanks for the advice.

With a newer system like yours I would try the edge.iso version of LM 20.3. It is Cinnamon.

Effectively the same kernel advice I guess. Thanks. I wasn't aware of edge.

[chippywood]

I marked this [Solved] - prematurely unfortunately. Not long after that, I resumed the system from suspend and didn't enter the unlock password immediately. After a minute or so, it rebooted. This is the first time it's misbehaved since I upgraded to kernel 5.13. I'll try upgrading to 5.15 - I see there are a number of references to comet lake in the changelog.

[SMG]

This is the first time it's misbehaved since I upgraded to kernel 5.13. I'll try upgrading to 5.15 - I see there are a number of references to comet lake in the changelog.

If that does not work, then checking the logs would be the next step.

[chippywood]

Still happening with kernel 5.15. It only happens within a couple of mins after restart, and seemingly independent of any activity. Again the cinnamon screensaver error msgs are shown, which may or may not be related:

Code: Select all

chris@Home:~$ uname -r
5.15.0-33-generic
chris@Home:~$ journalctl --list-boots
...
-1 ce355e27811b4b6ba23b728e983b1547 Sat 2022-07-02 12:50:08 BST—Tue 2022-07-05 18:01:22 BST
 0 b707eae3430c489ba73b5a9f76e79df0 Tue 2022-07-05 18:02:23 BST—Tue 2022-07-05 18:09:25 BST

chris@Home:~$ journalctl -b -1 -n 30
...
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Trying to connect to logind...
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Starting screensaver...
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Cinnamon Screensaver support not found in current theme - adding some...
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Successfully using logind
Jul 05 18:01:22 Home cinnamon-session[1147]: WARNING: t+48987.26649s: Detected that screensaver has left the bus
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Error in sys.excepthook:
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Original exception was:
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Error in sys.excepthook:
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Original exception was:
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Error in sys.excepthook:
Jul 05 18:01:22 Home org.cinnamon.ScreenSaver[107706]: Original exception was:

Advice on what I can do next would be appreciated. Thanks.

[SMG]

Still happening with kernel 5.15. It only happens within a couple of mins after restart, and seemingly independent of any activity.

You mean after resuming from suspend, correct? (not restarting the computer)

Advice on what I can do next would be appreciated. Thanks

Check the logs. You want to check what are the last lines before the system restarted. If there is nothing there (ie. the system just stops) then there is likely some type of power-related issue.

The following command prints the journal log information of the prior boot cycle in reverse order (so the reason for the problem should be at the top) and sends it to termbin.

Code: Select all

journalctl -rb -1 | nc termbin.com 9999

It will return with a url address that you should post in your next reply.

[chippywood]

You mean after resuming from suspend, correct? (not restarting the computer)

Correct. It only happens in the first few minutes after resume, and not very often.

Check the logs. You want to check what are the last lines before the system restarted. If there is nothing there (ie. the system just stops) then there is likely some type of power-related issue.

The last messages relate to the cinnamon screensaver, which seems a common feature although I can't say categorically that they've appeared every time. A power issue seems unlikely to me since the problem does not happen at random times.

It will return with a url address that you should post in your next reply.

https://termbin.com/hl4y

Thanks

[SMG]

It only happens in the first few minutes after resume, and not very often.

If it does not happen very often, then it is not happening all the time and thus it happens at random times. The randomness of it is why I suggested a possible power-related issue.

The first indication the computer will suspend is:

Code: Select all

Jul 06 18:34:40 Home ModemManager[836]: <info>  [sleep-monitor] system is about to suspend
Jul 06 18:34:40 Home NetworkManager[770]: <info>  [1657128880.0771] manager: sleep: sleep requested (sleeping: no  enabled: yes)

The computer woke at 7:45a.m. and then suspended again about hour later.

Code: Select all

Jul 07 07:44:51 Home kernel: PM: suspend entry (deep)
Jul 07 08:46:25 Home ModemManager[836]: <info>  [sleep-monitor] system is about to suspend

The computer then woke at 9:02a.m. and suspended a little over a half hour later.

Code: Select all

Jul 07 09:35:13 Home ModemManager[836]: <info>  [sleep-monitor] system is about to suspend

The computer woke at 10:29 a.m. and just after that was completed then sleep was requested again.

Code: Select all

Jul 07 10:30:07 Home NetworkManager[770]: <info>  [1657186207.4061] manager: sleep: sleep requested (sleeping: no  enabled: yes)

It woke at 11:55a.m. and went to suspend about 1.5 hours later.

Code: Select all

Jul 07 13:36:38 Home ModemManager[836]: <info>  [sleep-monitor] system is about to suspend

It woke at 16:26 and went into suspend at 16:58.
It then woke at 18:07 and went to sleep 50 minutes later.

Code: Select all

Jul 07 18:58:40 Home NetworkManager[770]: <info>  [1657216720.0247] manager: sleep: sleep requested (sleeping: no  enabled: yes)

It woke the next morning at Jul 08 06:56:52 and suspended about 1.5 hours later.

Code: Select all

Jul 08 08:36:00 Home NetworkManager[770]: <info>  [1657265760.0892] manager: sleep: sleep requested (sleeping: no  enabled: yes)

It woke at 09:28:40 and then the system abruptly stopped at 09:29:10. That type of situation usually indicates a hardware-related factor.

My eyes are going buggy from reading the same messages repeatedly. There are 8 suspends in that log and all resumed successfully.

On many (maybe all?) wake-ups, I noticed the below line, but it didn't seem to stop anything.

Code: Select all

Jul 07 07:45:27 Home org.cinnamon.ScreenSaver[5521]: Cinnamon Screensaver support not found in current theme - adding some...

The "conversation failed" message at the very end is in the log three times so it did not happen after every suspend, but I do not know specifically to what it relates.

This does not appear to be an issue with the operating system. I do not know how much hardware is new on your system so I can not offer any suggestions on where to focus efforts, but to me this seems related to hardware.

[chippywood]

If it does not happen very often, then it is not happening all the time and thus it happens at random times. The randomness of it is why I suggested a possible power-related issue.

I might disagree with your definition of random, but it's certainly unpredictable. I could try stopping using suspend and just use shutdown/reboot instead. If the problem went away, would this show anything useful?

This does not appear to be an issue with the operating system. I do not know how much hardware is new on your system so I can not offer any suggestions on where to focus efforts, but to me this seems related to hardware.

Basically it's all new (to me anyway - some is second-hand). The way it just drops could point to a power supply problem. I'm using a low power supply harvested from an older system. I've checked the power draw of this system and it should be within capacity but you never know. I have a (proven) high power spare, so I can try that.

I certainly appreciate your effort in looking at this. I hope your eyes have recovered

[SMG]

I could try stopping using suspend and just use shutdown/reboot instead. If the problem went away, would this show anything useful?

Other than a possible PSU-related issue, I do not have any guesses what is happening. Given how many times you were able to successfully resume from suspend, I do not think suspend is the issue.

The way it just drops could point to a power supply problem. I'm using a low power supply harvested from an older system. I've checked the power draw of this system and it should be within capacity but you never know. I have a (proven) high power spare, so I can try that.

The very first person I helped on this forum who was having his computer randomly reboot discovered the PSU he had bought was overall the right capacity, but apparently the power distribution to the individual rails was the issue. In his case the power to the rails varied just enough that periodically it would drop too low on the rail on to which his hard drive was attached. (He received that detailed info from someone on the the Dell forum who was very familiar with that specific PSU--his computer was a Dell.) That investigation lasted several months and that's when I learned that if the log just stops then it is likely a power issue. I was able to match it to one of my logs where the power unexpectedly went out in my building when I did not have my laptop's battery installed.

Let us know if the larger PSU addresses the issue.

[chippywood]

I replaced the PSU with a 500W one from my previous system, and which has worked flawlessly for years. No problems for days and I thought the issue was fixed, but it just happened again when bringing the computer out of suspend. journalctl shows nothing of interest. I'm wondering if purchasing my motherboard/processor combo from eBay was not such a good idea after all. Could it be a motherboard problem? I could ask the seller if he'd had similar problems but I'm not sure how much I would trust the answer.

If it is a motherboard problem, then maybe I just have to live with it. I did use suspend/resume on my previous setup because it was old and slow starting up. Boot up on this setup is lightning-fast and suspend is not so necessary, although being able to suspend mid-activity is so useful.

[SMG]

I'm wondering if purchasing my motherboard/processor combo from eBay was not such a good idea after all. Could it be a motherboard problem?

What is the model? The inxi info you posted earlier did not have that information, but that may be because it was too new for the 5.4 kernel.

Machine: Type: Desktop System: ASUS product: N/A v: N/A serial: <filter>
Mobo: ASUSTeK model: PRIME B460M-A v: Rev 1.xx serial: <filter>
UEFI: American Megatrends v: 1401 date: 07/27/2020

That is not the first time I have seen N/A's like that in output. It just means I can't search to see if others have mentioned any issues with it.

[chippywood]

That is not the first time I have seen N/A's like that in output. It just means I can't search to see if others have mentioned any issues with it.

I think this information relates to the computer system itself, and is something the manufacturer somehow adds. For example my Lenovo laptop has "IdeaPad S340" in the product field, and a version number in the v field. Since my system is a self build, it has nothing.

Currently:

Code: Select all

chris@Home:~$ sudo inxi -F     
System:    Host: Home Kernel: 5.15.0-41-generic x86_64 bits: 64 Desktop: Cinnamon 5.2.7 
           Distro: Linux Mint 20.3 Una 
Machine:   Type: Desktop System: ASUS product: N/A v: N/A serial: N/A 
           Mobo: ASUSTeK model: PRIME B460M-A v: Rev 1.xx serial: 210280886600896 
           UEFI: American Megatrends v: 1620 date: 07/09/2021 
CPU:       Topology: 6-Core model: Intel Core i5-10400 bits: 64 type: MT MCP L2 cache: 12.0 MiB 
           Speed: 2962 MHz min/max: 800/4300 MHz Core speeds (MHz): 1: 2692 2: 1627 3: 921 4: 800 
           5: 800 6: 800 7: 1647 8: 800 9: 801 10: 800 11: 1003 12: 800 
Graphics:  Device-1: Intel driver: i915 v: kernel 
           Display: server: X.Org 1.20.13 driver: modesetting unloaded: fbdev,vesa 
           resolution: 2560x1440~60Hz 
           OpenGL: renderer: Mesa Intel UHD Graphics 630 (CML GT2) v: 4.6 Mesa 21.2.6 
Audio:     Device-1: Intel driver: snd_hda_intel 
           Sound Server: ALSA v: k5.15.0-41-generic 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 
           IF: enp4s0 state: up speed: 100 Mbps duplex: full mac: fc:34:97:10:0d:d9 
Drives:    Local Storage: total: 912.89 GiB used: 209.06 GiB (22.9%) 
           ID-1: /dev/nvme0n1 vendor: Western Digital model: WD Blue SN570 500GB size: 465.76 GiB 
           ID-2: /dev/sda vendor: Crucial model: CT480BX500SSD1 size: 447.13 GiB 
Partition: ID-1: / size: 456.89 GiB used: 47.43 GiB (10.4%) fs: ext4 dev: /dev/nvme0n1p2 
Sensors:   System Temperatures: cpu: 30.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 324 Uptime: 11h 13m Memory: 15.48 GiB used: 5.36 GiB (34.6%) Shell: bash 
           inxi: 3.0.38

Regardless of this problem, I'm very pleased with the Linux Mint/i5 processor combination. Pretty zippy!

[chippywood]

I've been keeping a record of suspend/resume activity and timings, so I can get a better handle on this problem and make more sense of the logs (so I know what starts and ends where).

It confirms that when a reboot happens it is almost exactly 32 (+-2) secs after resume from suspend, and approx. 50% of the time. It happens regardless of whether I login and start work or just leave it at the login screen. I've left the computer running for days without issue (apart from the electricity bill ), the reboot problem is only connected with suspend.

Having said that, on perhaps 4 occasions (going back over a period of weeks) it rebooted again a few seconds after the first reboot reached the login screen, and on one of those it did this twice. This does muddy the water somewhat, but I'm assuming this is either another facet of the same problem, or a different problem. And this has only happened after an auto-reboot, not after a manual boot.

Given that it seems to be something that's happening after a 30 sec period, I've tried varying or disabling things that appears to be happening around that time, according to the logs:
- switching off the screensaver
- turning off computer lock options
- disabling Ethernet connection
- removing modules-load.d modules

all with no effect. I appreciate I'm just grasping and straws here as there's nothing obviously helpful in the logs (journalctl, dmesg, syslog). Is there some sort of kernel trace or debug options that I can enable to get more info?

One thing I don't fully understand: I believe there is a kernel ring buffer where the last system message are retrieved by the rebooting system. Is this right? How do I identify them? I see some messages in the start of the logs which might be these but they are timestamped within the reboot.

I still think this is a timing/race condition because it doesn't happen all the time, but when it does it's the same as previous times. It's definitely not random. I've found at least two similar sounding problems, one I mentioned in the original post, the other here, both with no resolution (I guess the timings in these reports are not comparable as they likely depend on the hardware involved).

I'm still hoping to get somewhere with this given that the problem is reproducible.

[deepakdeshp]

May be worth blowing away dust from the inner parts,check that all the fans are working.
Also to check the RAM with memtest from grub menu.

Check your disk too. https://help.ubuntu.com/community/Smartmontools

[chippywood]

May be worth blowing away dust from the inner parts,check that all the fans are working.
Also to check the RAM with memtest from grub menu.

Check your disk too. https://help.ubuntu.com/community/Smartmontools

Well, it's newly put together, so clean as a whistle. New m.2 drive. New RAM but still tested clean with Memtest86+. Fans working, CPU a very cool 31 deg so temp not an issue. The reproducibility says to me this is not a hardware failure.

[SMG]

It confirms that when a reboot happens it is almost exactly 32 (+-2) secs after resume from suspend, and approx. 50% of the time.

I still think this is a timing/race condition because it doesn't happen all the time, but when it does it's the same as previous times. It's definitely not random.

It's definitely not consistent or you would be able to predict when it happens.

The randomly rebooting after it reboots does not sound like something from the operating system. To me, that makes it even more likely this is a hardware issue.

I saw your post in the other topic where you mentioned about trying a newer kernel. Here are directions Mainline – Another Tool to Install Latest Kernel in Ubuntu / Linux Mint.

One thing I don't fully understand: I believe there is a kernel ring buffer where the last system message are retrieved by the rebooting system. Is this right? How do I identify them? I see some messages in the start of the logs which might be these but they are timestamped within the reboot.

I am not understanding your question. What do you mean by "messages retrieved by the rebooting system"? The dmesg command gives you the kernel messages. All the lines which have (kernel) in them in journalctl are also kernel messages.

Check /var/log/kern.log

[chippywood]

I am not understanding your question.

Fair enough. I wasn't sure it was even a sensible question, but I've now read more about logging and understand that indeed the kernel ring buffer is central to its logging. I was assuming that if the system suddenly stopped there could be unwritten messages left in the buffer, messages that could be retrieved by the rebooted system. I think this would mean that the buffer would have to be at a fixed location, which I now believe it isn't, so it's probably not possible anyway.

Re. my question about trace etc. The reboot problem is clearly (for me anyway) related to something that happens 30 secs after resume, not the cause maybe, but at least the trigger. Is there any way to find out what is happening at the time?

I saw your post in the other topic where you mentioned about trying a newer kernel. Here are directions ...

Thanks for that. I may give it a try.

I've successfully enabled hibernate so I can use it instead of suspend if all else fails.