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

[SMG]

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.

Once the system stops, anything which might have been in the buffer is gone. Only if it is written before the system stopped would one have the possibility of retrieving it.

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?

Considering the problem only happens ~50% of the time, on those times it does not happen perhaps checking what (if anything) is recorded at the 30 second mark in the logs is the only idea I have. That might give ideas for further investigation.

[BeyondLies_MintForum]

Mint 21 contains various fixes for the Mint screenlocker thingy. (Unless those fixes have been released already. I don't think they have been.) It is possible that those fixes will solve your problem.

(Mint 21 came out today. One cannot yet upgrade to it (as against doing a fresh install). But upgrade instructions will appear within a few days or so.)

[chippywood]

Considering the problem only happens ~50% of the time, on those times it does not happen perhaps checking what (if anything) is recorded at the 30 second mark in the logs is the only idea I have. That might give ideas for further investigation.

Duh, why didn't I think of that

Every 13 successful resumes I've recorded have these same messages 31 +-1 secs after hitting the keyboard to exit suspend:

Code: Select all

Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Trying to connect to logind...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Starting screensaver...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Cinnamon Screensaver support not found in current theme - adding some...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Successfully using logind
Jul 27 18:32:31 Home cinnamon-session[1154]: WARNING: t+73.88770s: Detected that screensaver has left the bus

So I guess the Cinnamon screensaver could be the culprit (as I sort of speculated in my original post). Is there anything I can do to get more information? There's nothing here that I can report a bug with.

Mint 21 contains various fixes for the Mint screenlocker thingy. (Unless those fixes have been released already. I don't think they have been.) It is possible that those fixes will solve your problem.

Any idea where the list of fixes is? I can't find it. I'm not sure I'm ready to dive into Mint 21 just yet just to see if there is a possible fix.

[SMG]

Duh, why didn't I think of that

Because you say the problem is consistent and I say it is random.

Every 13 successful resumes I've recorded have these same messages 31 +-1 secs after hitting the keyboard to exit suspend:

Code: Select all

Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Trying to connect to logind...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Starting screensaver...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Cinnamon Screensaver support not found in current theme - adding some...
Jul 27 18:32:31 Home org.cinnamon.ScreenSaver[1962]: Successfully using logind
Jul 27 18:32:31 Home cinnamon-session[1154]: WARNING: t+73.88770s: Detected that screensaver has left the bus

So I guess the Cinnamon screensaver could be the culprit (as I sort of speculated in my original post). Is there anything I can do to get more information? There's nothing here that I can report a bug with.

Those messages seem to indicate you typed in your password. You indicated in your initial post the problem seemed to happen after the password was entered which would mean something after these items might be the issue?

[BeyondLies_MintForum]

@chippywood

See here.

[chippywood]

Because you say the problem is consistent and I say it is random.

Actually I said it was inconsistent . But the real reason is because your rating is stratospheric and mine is still in the basement

Those messages seem to indicate you typed in your password. You indicated in your initial post the problem seemed to happen after the password was entered which would mean something after these items might be the issue?

I indicated earlier that I'd played with the screensaver settings (delay, lock settings), with no effect. I left the "Lock the computer when put to sleep" setting off so I didn't have to keep entering the password during all this testing. So having hit the Ctrl key to come out of suspend, I make no other interaction before failure happens, or after 40 secs passes which always means success.

These message appear (and at the same time) regardless of the screensaver settings. I've looked at trying to disable the screensaver completely but this doesn't seem possible without messing up other functionality. It seems that the screensaver has its fingers in many pies.

Nothing else is logged within 10 secs either side of these messages, so if there is something else of note happening at the time, it's not recorded.

I've not asked, but speculating for a minute that this is software related, how can the system fail so suddenly without a crash or other failure detection being recorded?

@chippywood
See here.

Thanks. * Rework screensaver refreshing during suspend, lock, user-switch activities. looks promising. I'm still thinking about Mint 21.

[SMG]

Nothing else is logged within 10 secs either side of these messages, so if there is something else of note happening at the time, it's not recorded.

For me, that is one of the clues the issue is likely hardware related.

Usually, if something is triggered by software, there is some type of message which is written somewhere. Rebooting the operating system is a pretty major event. If you reboot the computer (you tell it to reboot), that is recorded in the logs.

It just seems very unlikely software is causing this to happen and not recording that is being done.

[chippywood]

It just seems very unlikely software is causing this to happen and not recording that is being done.

OK, I am getting the impression that you think this is a hardware problem . Can you speculate what it could be?

I really want to pinpoint exactly where it fails. Are there any kernel options I can switch on, any debug version of modules (such as the screensaver) I can load, etc? Anything?

[SMG]

OK, I am getting the impression that you think this is a hardware problem . Can you speculate what it could be?

I have nothing new to add from why I originally mentioned in this post.

I really want to pinpoint exactly where it fails. Are there any kernel options I can switch on, any debug version of modules (such as the screensaver) I can load, etc? Anything?

I am not aware of any operating system programs that could check the voltage drop across the rails on a motherboard or check a PSU, but I make no claims about knowing all possible available options.

[chippywood]

I am not aware of any operating system programs that could check the voltage drop across the rails on a motherboard or check a PSU

You know that wasn't what I was asking for. Not helpful. Identifying the exact point of failure in the software is valid and useful debugging regardless of the cause.

Here's what I've done to eliminate the possibility of a hardware cause:

1. switched the PSU for a known trusted one - no effect
2. replaced all memory with brand new - no effect
3. switched m.2 slot (m.2 card is brand new) - no effect
4. disconnected all SATA devices, ethernet, all unnecessary USB devices - no effect
5. switched display from DisplayPort to HDMI - no effect

Apart from keyboard and mouse (unlikely candidates I feel), that just leaves the motherboard and processor, for which swapping out is not an option. In reality this just leaves the motherboard as the culprit, which is effectively game over. I just wonder if ASUS would accept it was faulty on the basis of this evidence.

I've installed Mint 21 on a spare HDD and am testing that. In progress.

[SMG]

I am not aware of any operating system programs that could check the voltage drop across the rails on a motherboard or check a PSU

You know that wasn't what I was asking for. Not helpful. Identifying the exact point of failure in the software is valid and useful debugging regardless of the cause.

No, I didn't know that wasn't what you were asking for. People here ask for software to check their hardware on a regular basis so that's what I though you were asking.

One can only identify a point of failure in the software if the software is failing. At this point, I do not see any messages or indications the software is failing. If you do, please let us know what it is. I do not claim to know everything about Linux Mint and am always open to learning something new.

[ron69]

You never mentioned your RAM...
How much is it, and are they the same?
Can you try to work with just one bank?
Are the banksettings made automatic ?

[chippywood]

You never mentioned your RAM...
How much is it, and are they the same?
Can you try to work with just one bank?
Are the banksettings made automatic ?

I mentioned that some while ago:

New RAM but still tested clean with Memtest86+.

I don't think it's a RAM issue, but I've been wrong before.

[chippywood]

No, I didn't know that wasn't what you were asking for. People here ask for software to check their hardware on a regular basis so that's what I though you were asking.

If so, apologies.

The same problem eventually showed up on the Mint 21 Cinnamon system. To eliminate Cinnamon, I installed the MATE version - different timings but same again. What was new was that one time it happened when the boot GRUB screen was showing ie. not a continuation of the boot-up, but black screen and reboot. I guess I'm finally accepting that this is not a software issue .

What I can say is that it only ever happens with a minute or two of coming out of sleep state, not every time, but definitely at no other time. It's definitely connected to the use of the sleep state, and makes me think that it could be BIOS/UEFI related. I've searched around the Internet looking for something similar with my hardware and found nothing that helps me, but there are definitely many problems reported relating to exiting from sleep mode.

I did find this relating to ACPI in general:

It's suppose to be a standard that any operating system can properly implement. However, in typical Microsoft fashion, MS operating systems do not follow or properly implement the ACPI standard. Instead, MS gives motherboard manufacturers their own improperly implemented ACPI code for inclusion in the motherboard BIOS/UEFI. The code runs fine with MS windows but all for other operating systems like linux there can be problems. Because of MS's market dominance, the faulty ACPI implementation from MS has become the de facto industry standard. As a result, linux and other non-MS operating systems have to reverse engineer the faulty ACPI implementation from MS. That's why you can see problems in linux with ACPI related functionality like suspend to ram, hibernate, etc.

This might make me feel better, but doesn't help solve my problem. So I guess it's the end of the road unless something unforeseen turns up. For me, suspend is out, hibernate is in.

[SMG]

Keep an eye on any ASUS BIOS/UEFI updates. ASUS is usually pretty skimpy with words in describing what they change, but many a "improve performance" or "improve system stability" have helped people with issues on Linux Mint when they upgraded to the latest firmware.

[chippywood]

I managed to get ASUS support interested (or at least, not immediately dismissive) in the issue, probably because the board is still under warranty. They predictably responded that Linux is not supported, but at least wavered when I said that the black screen and reboot happened during the boot process before the Linux kernel was loaded, and so it looked independent of the OS. This was based on my belief that hibernate fully powered the computer down, so resuming from it was a normal power-up boot. I now realize that this isn't so (even though it still works if it that does happen), and that hibernate uses sleep state S4, as opposed to suspend that uses state S3.

This means that in hibernate, like suspend, the system is resuming from a sleep state under the control of ACPI, which I'm increasingly suspecting is where the issue is. If so, I guess it lies somewhere between the non-standard ASUS implementations of ACPI, and the Linux code that struggles to support it. ASUS won't be interested if this is the case.

More comment here of the issue of ACPI problems:

Hardware? Asus motherboards are prone to this, as they did their own implementation of ACPI. While Microsoft compliant, not to standard.

Perhaps a reason to avoid ASUS motherboards next time.

[chippywood]

It turned out to be a faulty motherboard.

It's often stated that Linux can have issues with suspend/hibernate because of the non-standard mobo ACPI implementation, and I was happy to focus on that as a possibility. But I have to admit that in hindsight it's hard to believe that a mobo manufacturer could produce something that had such a glaring bug in it. And my personal experience with previous ASUS mobos is that they work well with Linux suspend/hibernate.

Anyhow, with a replacement board, all is well. ASUS eventually accepted that it was a faulty motherboard, but wouldn't honour the warranty because I couldn't produce the original invoice. Not impressed.

[SMG]

Anyhow, with a replacement board, all is well. ASUS eventually accepted that it was a faulty motherboard, but wouldn't honour the warranty because I couldn't produce the original invoice. Not impressed.

Sorry about the warranty issue, but glad to hear you now have a working system.