[SOLVED] Fail to resume after suspend using lid and other issues

[majuamst]

I am a brand new user of Linux on a 10 year old laptop with a C-60 AMD GPU. Immediately upon booting, there is a brief message, "0.004051 Common interrupt 1.55 No IRQ handler for vector" that flashes for 10-15 seconds. The computer continues to boot into LinuxLite. I am a longtime Windows user and a brand new Linux user. I am learning to like LinuxLite and have set up this old laptop to do everything the way I want, but I have one very big problem. It will not wake up from suspend. It flashes "no IRQ handler for vector" on several lines of a black screen. The error message disappears too quickly for me to copy and post it accurately for you to see. After the error message, the screen stays blank and never loads my desktop. I have tried to use hibernate instead, but I get another error message indicating that hibernate is not possible. It appears that some IRQs are not being assigned upon boot and after suspend.

I did some internet research and found that this is a known issue with AMD processors. It has something to do with IOMMU. The suggestions include turning IOMMU off in the BIOS, but that option is not provided in the rudimentary BIOS screens of this ACER Aspire One 722. Apparently there is a Linux software solution as well, but they all suggest the BIOS change first.

Sorry for the long post, but I am wondering if someone has experienced this issue and knows how to fix it. I really want to learn Linux on this old laptop and have started tutorials to navigate my way around. As we get closer to Microsoft abandoning Windows 10, I would like to convert all of my networked computers to Linux, but not if I cannot solve these types of problems.

Thank you for being here for beginners like me.

[stevef]

I don't think the "no IRQ handler for vector" is the root of the problem with resuming from suspend.

I have an Acer Aspire One 722 running LL 7.0 with 4GByte RAM.
This unit displays this message for a few seconds on each boot and each shutdown but it is not something that causes any issue.

I put the Aspire into suspend mode and then attempted to resume.
As the unit goes into suspend and resumes, there are very brief (less half a second) views of a screen showing 3-4 instances of a message which could be the same message but the unit suspends and resumes as expected.

Can you confirm how much RAM your Aspire has ?
Open a terminal (press Ctrl, Alt and T together) and run this command

Code:

inxi

to show basic system information

When you get the blank screen after attempting to resume from suspend is the Aspire completely unresponsive ?

Are there any signs of activity at all - e.g.
Can you ping the IP address from another system.
Are the system LEDs active ?
If you attach a full size keyboard, do the Caps Lock and Number Lock indicators toggle ?
If you attach an external optical mouse, does the LED underneath light ?
If you press 'Alt' 'Ctrl' and 'F2' together does anything happen ?

At the blank screen, how do you restore operation ?

Next time you go through the process of suspend, attempt to resume and recovery, make a careful note of
a) the time you initiate the suspend
b) the time you initiate the resume
c) the time you begin to recover the system

When you get back into the system (by whatever means) run this command replacing hh:mm with the times you attempted the resume (b) and forced the recovery c.

Code:

journalctl --since hh:mm --until hh:mm

Press Q at the end
This will display any messages the system was able to log while resuming which may give a clue.

If there is anything of interest, you can pipe the output to a text file

Code:

journalctl --since hh:mm --until hh:mm | tee ~/aspireresumelog.txt

You can review the text file to remove any sensitive information and post the contents back here for review giving us a bit of context.

If there's nothing in the resume log you can check the logs made during the suspend operation (using the 'a' and 'b' times).  This will show what the system was able to log while suspending.
Again this may contain significant information and can be piped to a text file in a similar way.

[majuamst]

Thank you for the detailed response. It is incredibly helpful. I am still working on gathering information. I have 4GB RAM. It is good that you have the exact same PC, so you may be able to duplicate my issue. I can report so far that when on battery the computer suspends and awakens as it should after one minute and after 15 minutes. I used the power button to put it to sleep and the Enter key to awaken it. There was nothing in the resume log after the start time. There were two lines highlighted in red. Does that mean something abnormal?

Next, I suspended the PC by closing the lid and tried to resume after 30 minutes. After the IRQ lines, the screen went blank, and I could not get to the desktop. When I pressed Ctrl-Alt-F2 I received a text output (terminal, I guess), with the Ubuntu disclaimers and a Linux Lite welcome, with the date, memory usage, etc. The prompt was strange, myname diamond ~ diamond.

I ran the resume process as you suggested and found several errors at the time I tried to resume. I was able to create the txt file and will try to send it to you. I must be missing something because I cannot find any way to attach the file to this reply.

One thing to note, when I installed Linux Lite, I had no battery in the PC because the old one was completely dead. After the installation and when everything seemed OK, I bought a new battery and am now using it. Could the OS not be recognizing the power source correctly?

Also, I still get an error message when I try to hibernate instead of suspend. Hopefully the resume log file will provide some answers to that as well.

Thank you again. I will post another reply when I figure out how to upload the resume log.

[stevef]

I'm a bit confused.  Originally, you stated the laptop will not wake up from suspend, but in your second post you mention the computer suspends and wakes as it should using power button to sleep and enter to wake.

We need to be systematic and accurate to try to replicate your problem.
First off, I suggest you establish if the basic suspend and resume function is reliable.
Please follow this simple sequence.

With the system booted up and 'stable' (not running any applications or updating in the back ground)
Click 'Menu', then the 'Log Out...' icon, then select the 'Suspend' button.
Allow a minute or two, then press any key to wake the computer.

If the system suspends and wakes ok like this, repeat it a number of times until you are happy it works consistently.

If ok, we need to look more into the circumstances in which your system comes up with a blank screen when attempting to resume.
It is possible that problem with the suspend operation is stopping resume.

Is there a set of circumstances that consistently produce the blank screen when resuming from suspend ?

In order to try to reproduce your problem, we need to know the circumstances exactly.
This will include
All the settings in Power Manager.
The circumstances of battery/mains when entering suspend mode.
The method of entering suspend mode.
Any other relevant information like network shares etc
Given all the possible variables it may not be possible.
From the logs you posted, there's quite a bit going on networkwise.

It sounds from your post that pressing Ctrl,Alt,F2 at the blank screen may have taken you to a virtual terminal session using the whole screen.
Can you confirm please ?

If correct, the inference is that the system is functional at some level, but may be unable to open the Desktop.
This may be useful - much better than if it is completely unresponsive at the blank screen.

If you submit logs, providing more context will help us look through them, e.g. lid closed at hh:mm.

You didn't tell us how you recover from the blank screen when resuming.

Regarding the hibernate problem, we need much more information than 'I get an error message'

Running Power Manager and looking at the 'Devices' tab will show you if the system sees the new battery.

Regarding attachments do you have an 'Attachments' box under the posting window with the words 'Click or drop some files here to upload..'

Thank you.

[majuamst]

Thank you. I thought I answered most of those questions, but I guess I was not clear enough. First, there is no way to recover from the blank screen without shutting down with the power button and then restarting with the power button. During the blank screen, the USB ports are functioning and an external mouse lights up. While in the virtual terminal, I can run commands, and the PC functions appropriately. In fact, it was while in the virtual terminal that I created the resume log and piped it to the txt file. The terminal used the whole screen and the computer computed. It just did not resume into the desktop from suspend. I had to shut down with the power button to exit.

In the last reply, I was trying to demonstrate that the problem was time related. It resumed when the time suspended was less than 15 minutes or so, but it did not resume when I left it suspended for exactly 30 minutes. The method used to suspend made no difference. As you can see from the txt file, there was no activity between suspend and resume.

I have changed Power Manager (it sees the battery) every which way, and whether I manually suspend for 30 minutes (using any method) or the PC times out and suspends 30 minutes or more, it will not wake up to the desktop. When I try to use hibernate instead of suspend as the sleep option, nothing happens, but I receive this error message: "GDbus.Error.org.freedesktop.login1.SleepVerbNotSupported: Not running on EFI and resume= is not set". There is no available method to use hibernation, not lid, time out, nor power button. However, when I use your suggestion to logout, it does not try to hibernate but suspends instead. I guess it is bypassing Power Management. Finally, display power options under the Display tab in Power Management are all turned off to remove that as a variable.

As for the resume log, I was using battery only. I closed the lid at 14:25 to suspend, resumed by opening the lid at 14:55 and used 14:56 as the endpoint. I moved the mouse, pushed Enter, pushed (briefly) the power button, etc., but nothing happened until I pushed CTRL-ALT-F2 and got the terminal text screen. I was able to create the resume log and pipe it to the txt file while using the terminal, but I had to shut down with the power button and reboot; there was no other way to return to the desktop.

There is no network activity, other than a wireless connection to my router. I have not shared anything (I have yet to learn how!). As you can see from the log, the network connection is turned off when the PC suspends, and the PC receives an IP address from the router when it tries to resume. After a successful quick suspend/resume cycle, a message flashes on the desktop that the wireless connection is re-established.

Based on all of the above, I think you are correct that resume stalls when it has to restore the graphical desktop. It doesn't matter how suspend is initiated, but length of time is an issue. A quick suspend/resume cycle works as it should. A suspend for 30 minutes or longer does not resume. Hibernate does not work at all. Perhaps you could try to suspend your own Aspire PC for over 30 minutes and see if it resumes the way it should. The two computers seem to be identical.

I did not see an "Attachments" box when I replied in either the Quick Reply nor the New Reply.

Once again, thank you for your help.

[stevef]

Thanks for the more detailed explanation - having the context is so useful.

To summarise, the symptom is that a suspend of 30 minutes or longer initiated by any means always fails to resume as expected but returns a black screen.
Console access (Ctrl Alt F2) is possible from the black screen.

You mention being on battery only during the test.  Provided the RAM has power for the duration, the length of time spent in suspend should not make a difference.
If your RAM had lost power while suspended, I doubt the resume operation would be as 'good' as it is, but who knows.
Please can you confirm that you get the same problem with external power supplied throughout the suspend/resume cycle.

I will try similar on my system and report back.  If I can reproduce the time related problem with resuming the desktop it will be easier to work on.

As an aside, when you get the the terminal screen after the blank screen, forcing a power off may be detrimental.

Running this command

Code:

poweroff

should initiate an ordered shutdown.

Regarding the attachments. It seems the box appears after trying a preview of the post (which I do normally) - I'm still getting used to the new forum and hadn't noticed it wasn't there unless the preview had been done.  Very odd.

[majuamst]

Well, Steve F, you must love this. Thanks for the fast responses. Why Clueless? You are anything but!

So, I suspended for 45 minutes on mains, as you call it: lid down at 14:55, lid up and hit Enter at 15:40. Log is since 14:55 until 15:42. Black screen. I was able to open a console(?) with CTRL-ALT-F2. I ran a resume log and piped it. I will attach the txt file if I can. The actual journalctl file would be better to send to you, since it has multiple color-coded entries that suggest a firmware problem and repeatedly recommend to update. I wonder if that means a PC BIOS issue or an OS issue. I actually tried to find a BIOS update for the PC, but Acer seems to have removed all references to this computer from its web page. I was able to shutdown with the poweroff command. Thank you for that.

Next, while still on mains (I like using that term), I rebooted and logged on. I lowered the lid for about 30 seconds. When I raised it and hit Enter > black screen. Like before, I was able to get a console and poweroff. So, when on mains, time is not a factor. Wow.

I look forward to learning what happens on your Aspire.

By the way, this computer is not important for me. I am going to use it to learn Linux, so if we cannot get it to suspend, that's OK. Regardless, I guess it would be nice for your group to find out what is happening. I will stick with it as long as you are still interested.

[stevef]

Test conditions
System connected to external supply
USB mouse attached
Connected to network using wireless
Logged in to desktop
No applications open
OS Linux Lite version 7.0 updated/upgraded to current release
kernel 6.8.0-45

Entered suspend using 'Menu', click the 'Log Out...' icon, then select 'Suspend'
Wait 30 minutes
Resume by pressing 'H' on keyboard
System behaved as expected, going straight to working desktop, reconnecting to network etc..

If you can provide an example from your system using the same test conditions showing a failed cycle of suspend/resume I can compare logs directly or you can compare with the attached.
I've had a quick look through the example you provided earlier trying to guess the colour coded problems.

The log I made doesn't feature any examples of
dbus-daemon[831]: [system] Rejected send message....
gvfsd-network[4261]: Couldn't create directory monitor on wsdd.....
gvfsd-wsdd[5659]: Failed to spawn the wsdd daemon...
but I do see the ACPI Warning

gvfsd is related to mounting disks which is why I thought you might have had network shares - not sure why you are seeing these or if they are relevant.
The 'dbus-daemon Rejected send message' is possibly of interest because it refers to xfce4 power manager.
More research needed.


The system BIOS versions are
InsydeH20 Setup Utility  Rev 3.5
System BIOS version      V1.04
VGA BIOS                ATI VER012.036.000.029.041054

'Mains' is a term for grid utility services, commonly used in the UK, but maybe not so much elsewhere.
The Acer Aspire One 722 just about copes with the latest Linux Lite so I can use it as a test machine, but it is a bit sluggish in general use so I wouldn't recommend it for LL 7.x.  It runs Linux Lite 6.x fine.

[majuamst]

Thank you. If you want to skip the majority of this reply, read this first sentence: THE PROBLEM IS SUSPENDING BY CLOSING THE LID. EVERY OTHER WAY SEEMS TO WORK!!!

My BIOS is a later release than yours, V1.04 vs 1.05. Everything else is the same.

I updated all packets from 6.8.0-44 to 6.8.0-45.

I duplicated all of your conditions exactly. USB mouse, no applications open, etc., but I made a mistake and pressed Log Out from the box after pressing the Log Out icon, rather than pressing Suspend. I had logged back in with no problem.

This time I entered Suspend correctly in the box from the Log Out icon in the menu. After 30 minutes I resumed by pressing H. Wonder of wonders, the "System behaved as expected, going straight to working desktop, reconnecting to network etc.." (quoting you).

Next, I ran the same test, but this time I closed the lid to enter suspend. After 30 minutes I raised the lid, moved the mouse, pressed H, Enter, power button, etc., but the PC did not resume. CTRL-ALT-F2 brought me to the console. One interesting point is that every time I enter a console after an unsuccessful resume I have to login with my name and password. This is not how I have Power Manager set up. I do not have to login when the PC does resume properly. Should I have to log in again to use a console? Could the problem be related to the resume routine not recognizing the current user? Remember my initial mistake when I logged out then logged in again before I did the above test that worked.

Next, I tested user credentials after shutting down with a poweroff command and rebooting. I logged out and logged back in, the same as I did before the successful resume. I duplicated everything but suspended by closing the lid again instead of using Menu > Log Out > Suspend. Resume failed. User login does not seem to be the problem.

Next, as a double check, I duplicated the exact successful suspend described at the beginning of this reply, including the logout > login. After 30 minutes, I pushed H. It resumed properly again.

Next, to retest the resume process itself without a logout > login variable, I duplicated the same successful suspend, using the menu, not the lid. Resume worked perfectly again.

The last suspend I did was to allow Power Management to suspend after 30 minutes of inactivity. I left the lid open and let the PC timeout by itself. I resumed after two hours by pressing H. Resume worked perfectly.

So, all of these trials suggest that suspending by closing the lid is the problem, not the user, not the login, not inactivity. The actual suspend > resume cycle seems to work just as it should.

Power Manager during these trials was set to suspend when the lid closes - both battery and external power.

Is there a way to check what closing the lid does differently from the other methods? Do you want to try to duplicate the issue by suspending your Aspire 722 by closing the lid? While you are there, please check if your Aspire can hibernate.

I did not attach a new resume log with this reply.

Another interesting observation is that when I log out from the menu, there is a split-second message in red that begins with "Failed to start Casper..." It is too fast for me to read the whole thing. What is that about?

Thank you, again.

[stevef]

Try this.
Control Panel -> Xfce Screensaver
Screensaver tab 'Enable Screensaver' is disabled
Lock Screen tab 'Enable Lock Screen' is disabled
This will ensure your system doesn't try to go to a lock screen.
We can change this later.

Control Panel -> Keyboard
Application Shortcuts tab
Select a shortcut you don't use.
I chose onboard (Ctrl,Alt,O) the short cut to open the onscreen keyboard because onboard doesn't work properly, but you can choose any.
If you choose a different one modify the instructions below.

Click edit
In the 'command' box, type in

Code:

/usr/bin/xrandr --auto

Click ok
In the window that allows you to set the key combination, press Ctl,Alt and O together and then release them so the onboard command is replaced by the xrandr command
Close the settings window.

Close your lid and allow the system to suspend for a period
Open the lid
Press any key to resume and go to the black
Press Ctl, Alt, and O together.