Bug 211027 - display standby not wakeable - AMD 2400G
Summary: display standby not wakeable - AMD 2400G
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
: 212057 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-01-04 10:34 UTC by Rev
Modified: 2021-03-21 16:26 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.10.4-051004-generic
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
lspci-vnvn.log (88.17 KB, text/plain)
2021-01-04 10:34 UTC, Rev
Details
PrrocCpuinfoMinimal.txt (1.37 KB, text/plain)
2021-01-04 10:36 UTC, Rev
Details
mainline (122.99 KB, image/png)
2021-03-12 08:01 UTC, Rev
Details

Description Rev 2021-01-04 10:34:42 UTC
Created attachment 294481 [details]
lspci-vnvn.log

Hello! And all the best for 2021.

I am quite new to this, so please excuse if I am not getting it right.

I am sleeping with music by night. Since I changed to kernel 5.10.4 my system cannot be "woken up" from display standby any more. I have a two minutes timer of inactivity to turn my display off. Everything works as expected when the display is in the standby state for a couple of hours. But when it is in this state for over 6 hours it cannot be woken up again. The screen stays black, the display stays in standby mode.

**update: It is related to turning off the physical display for the night AND the computer going into some energy saving state afterwards.

In the background it seems the system works fine. I can change the volume of the still running music, can even alt-F4 close the music player (Audacious).

I am running Ubuntu 20.04.1 LTS linux 5.10.4-051004-generic Kernel 5.10.4

Only some of the methods shown below this posts worked on my system for gathering more data, ubuntu-bug linux brought an error about a non existent package, cat /proc/version_sig... brought an error about file or folder not found.

lspci-vnvn.log is attached.

System specs:
AMD 2400G using APU for display output, mesa drivers libegl-mesa 21.0~git2012200730.f9ceab~oibaf~f
X370 chipset mainboard (biostar)
16GB RAM DDR4 2933

Please let me know if you need more data and how to gather it. Thank you!

Rev
Comment 1 Rev 2021-01-04 10:36:28 UTC
Created attachment 294483 [details]
PrrocCpuinfoMinimal.txt
Comment 2 Rev 2021-01-04 12:47:20 UTC
Please note the update and the difference from "6 hours" to "display powersave plus display turned off physically", as described

"But when it is in this state for over 6 hours it cannot be woken up again. The screen stays black, the display stays in standby mode.

**update: It is related to turning off the physical display for the night AND the computer going into some energy saving state afterwards."
Comment 3 Rev 2021-01-04 12:50:16 UTC
Last working kernel is either linux-image-unsigned-5.10.1-051001-generic or linux-image-unsigned-5.10.3-051003-generic. Sorry that I cannot specify which one it is, because I only have the uninstallations found in a log (Synaptic). On Ukuu logs I only found the last install log and then a big gap to July (for whatever reason).
Comment 4 Rev 2021-01-04 12:54:21 UTC
Update again, last working Kernel was linux-image-unsigned-5.10.3-051003-generic. I found the right logs. I was using this kernel from 2020-12-17 to 2020-12-31, then updated to 5.10.4 where I encountered the reproducable problem.
Comment 5 Rev 2021-01-06 12:40:40 UTC
Next update: it seems that turning off the display physically BEFORE the display enters the standby state triggered from the OS is the reason for this bug. I also found out that I can re-wake the system by pressing CTRL-ALT-3 and then switch back to the logged in userspace by pressing CTRL-ALT-2 again. Only issue with that "workaround" is, that there is a smaller mouse-pointer on the screen now, a little smaller than the usable mouse-pointer. And this dead mouse-pointer stays on the screen whatever I do, even on video playback surfaces.
Comment 6 Rev 2021-01-06 12:43:21 UTC
Note: updating the mesa drivers brought no change. The issue stays reproducable with the kernel.
Comment 7 Rev 2021-01-09 11:51:24 UTC
update: the bug can be prevented with the following steps. I hope this helps in finding out where it comes from.

1) wait for the (2 minutes) timer for display-turn-off
2) wait for the physical display to get into deep standby (power-led-blinking-slowly)
3) turn off physical display afterwards
4) after a longer period of standby, do NOT move the mouse or press any key to wake the OS
5) turn on the physical display, wait until it recognizes the standby state
6) now move the mouse or press any key to wake the OS and the display.
Comment 8 Rev 2021-01-09 11:55:11 UTC
The display is connected by HDMI btw.
Comment 9 Rev 2021-01-10 12:10:54 UTC
I am switching to kernel 5.10.6 right now and check if the unwanted behaviour persists.
Comment 10 Rev 2021-01-17 11:47:19 UTC
The issue did not survive the kernel change to 5.10.6. So it is still unclear what caused the issue nor what got changed for the issue to just disappear.
Comment 11 Rev 2021-02-19 22:19:36 UTC
I can report that on all later 5.10 official kernels the problem was gone.

I updated to 5.11 and voila, the problem is there again.

Just asking, is anyone reading this?
Comment 12 Lauri Jakku 2021-03-07 16:49:08 UTC
I got same issue,

00:02.0 VGA compatible controller: Intel Corporation Device 9bca (rev 04)
Comment 13 Zhang Rui 2021-03-09 06:47:09 UTC
This seems like a graphics issue, please file a issue to the graphics people instead.
Comment 14 Rev 2021-03-09 09:09:45 UTC
(In reply to Zhang Rui from comment #13)
> This seems like a graphics issue, please file a issue to the graphics people
> instead.

Hello Zhang Rui,

I thought so first too and switched graphics drivers with no effort. And as you can see on Lauri Jakku's comment, he/she has a very different hardware setup and the bug is there.

So NO, it is not a GPU drivers issue. Stop shifting blame please.
Comment 15 Lauri Jakku 2021-03-09 11:19:53 UTC
i think the problem is that the display is powere down, but not up whe system supposed to wake up.
Comment 16 Lauri Jakku 2021-03-09 11:20:37 UTC
I got HDMI also.
Comment 17 Zhang Rui 2021-03-09 15:02:48 UTC
(In reply to Rev from comment #14)
> (In reply to Zhang Rui from comment #13)
> > This seems like a graphics issue, please file a issue to the graphics
> people
> > instead.
> 
> Hello Zhang Rui,
> 
> I thought so first too and switched graphics drivers with no effort

what do you mean by "switched graphics drivers"?

>. And as
> you can see on Lauri Jakku's comment, he/she has a very different hardware
> setup and the bug is there.

First of all, I'm not sure if you have run into exactly the same problem or not. 

@Rev, according to your comments, the problem
1. does not exist in 5.10.3
2. exists in 5.10.4
3. does not exist in 5.10.6 and later
4. exists in 5.11
is that true? And it is strange to see that the problem is fixed in stable tree, but not in upstream kernel. Can you please confirm if the problem still exist in vanilla 5.12-rc2 kernel? If it is a known issue and fixed somewhere, then there is a good chance this should be fixed in latest upstream as well, but let's see.

@Lauri Jakku, can you please confirm the kernel versions above?
I just want to make sure you have run into exactly the same problem.
If no, please file a separate bug report.

> So NO, it is not a GPU drivers issue. Stop shifting blame please.
Well, maybe, and I'm not shifting blame.
"In the background it seems the system works fine. I can change the volume of the still running music, can even alt-F4 close the music player (Audacious)."
This suggests that the system resumes back successfully, but with a broken screen/display.
Comment 18 Lauri Jakku 2021-03-09 16:01:31 UTC
hmm, i got to make custom kernels (r8169 fixup) and then to try..

I'm building the kernel versions with this patch i've done:

https://lja.fi/lja/wordpress/index.php/linux-kernel-r8169-network-driver-fixup/
Comment 19 Rev 2021-03-10 10:45:14 UTC
> what do you mean by "switched graphics drivers"?

I use these graphics drivers and they get updated regularly: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+packages

To test the issue I took the time to revert to default drivers (MESA), but the described problem persisted.

I switched kernel to 5.11.5 today, lets see how that works out. Testing it later this day. (Sorry for not being on the board this often)

What ever I wrote about the issue being there or not in the kernel versions is / was a fact on my machine. Why would I lie about it and then use my valuable time and effort here to post about it? With my (non-)knowledge about what is causing it I can only report what I found out trying to resolve the issue by myself, with relations on changes I tried. That is, of course, not a laboratory test environment where you lock all chances of change, change one thing and then try again. It is a user system where ubuntu updates and graphics drivers updates and kernel updates are at least weekly performed. So I can only state what I observed and what updates I did or did not do to report that observations.

IMO, I gave you the info, I have no power to help in the process, I just wanted someone to know what is going on. And since it is a severe bug right now, where I can crash my system by unpowering my display at any time. So yeah, I am bothered by it and wondering why no one else stumbled on the issue, but I can live with it if you decide your job is doing nothing or pushing it in a direction that does not concern or bother you.

So I will report my last findings with the installed 5.11.5 kernel today and then consider myself out.
Comment 20 Rev 2021-03-10 13:47:04 UTC
OK, the bug is gone again.

Either changes to 5.11.5 or changes to yesterdays graphics drivers. I really do not know right now.

I am still willing to help and provide information, but since on newer releases of the 5.10 and 5.11 kernel had the bug and it was gone on some later releases I still have no clue myself what causes it.
Comment 21 Zhang Rui 2021-03-10 14:26:00 UTC
(In reply to Rev from comment #19)
> > what do you mean by "switched graphics drivers"?
> 
> I use these graphics drivers and they get updated regularly:
> https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/+packages
> 
> To test the issue I took the time to revert to default drivers (MESA), but
> the described problem persisted.
> 
> I switched kernel to 5.11.5 today, lets see how that works out. Testing it
> later this day. (Sorry for not being on the board this often)
> 
> What ever I wrote about the issue being there or not in the kernel versions
> is / was a fact on my machine. Why would I lie about it and then use my
> valuable time and effort here to post about it?

Sorry to bring the confusion, for the following words
"And it is strange to see that the problem is fixed in stable tree, but not in upstream kernel."
I didn't doubt your test result, but I mean the symptom is weird, because usually, if a problem is fixed in stable tree, it means it is a known issue, and it should also be fixed in the latest upstream kernel.

And if the problem has already been fixed with latest code, then why we need to spend our time to debug it from scratch?

> With my (non-)knowledge
> about what is causing it I can only report what I found out trying to
> resolve the issue by myself, with relations on changes I tried. That is, of
> course, not a laboratory test environment where you lock all chances of
> change, change one thing and then try again. It is a user system where
> ubuntu updates and graphics drivers updates and kernel updates are at least
> weekly performed. So I can only state what I observed and what updates I did
> or did not do to report that observations.

Again, I didn't doubt your result, that is why I asked your to try latest upstream kernel, rather than reconfirm the stable kernels you have already reported.

> 
> IMO, I gave you the info, I have no power to help in the process, I just
> wanted someone to know what is going on. And since it is a severe bug right
> now, where I can crash my system by unpowering my display at any time. So
> yeah, I am bothered by it and wondering why no one else stumbled on the
> issue, but I can live with it if you decide your job is doing nothing or
> pushing it in a direction that does not concern or bother you.

Well, I'm pushing this bug in a direction that has a good chance to get it rootcaused/fixed.
Please refer to bug #212003.

Usually, for issues like this (out of my scope), I would re-assign the problem to the proper owners directly, but unfortunately the graphics people don't use kernel bugzilla.
Comment 22 Zhang Rui 2021-03-10 14:27:58 UTC
(In reply to Rev from comment #20)
> OK, the bug is gone again.
> 
> Either changes to 5.11.5 or changes to yesterdays graphics drivers. I really
> do not know right now.
> 
> I am still willing to help and provide information, but since on newer
> releases of the 5.10 and 5.11 kernel had the bug and it was gone on some
> later releases I still have no clue myself what causes it.

Good to know this, thanks for the update.
Still I wish I can see the result on latest upstream kernel, say 5.12-rc2, because this is critical to make sure the problem won't happen again on some later releases.
Comment 23 Rev 2021-03-10 16:26:31 UTC
5.12-rc2 does not show this issue when I test it for a short time (1 min display sleep timer, turn off display physically, wait >1 minute, turn on display physically, move mouse). 

I will test it over night and tell you the results afterwards.

And also: sorry for catching some of my frustration earlier! Thank you for doing what you do and thank you for trying to help me!
Comment 24 Rev 2021-03-11 08:37:24 UTC
OK, I tested it over night and 5.12-rc2 kernel does not have the issue.
Comment 25 Zhang Rui 2021-03-11 13:17:21 UTC
Thanks for the confirmation, Rev.
I think we can close this bug as the problem is gone in latest 5.10 stable, 5.11 stable, and 5.12-rc kernel.

@Rev, that's okay. I re-checked my words in comment #13, and that was really a short comment with no background, thus it is possible to cause some confusion. I will pay more attention to my words next time.

And thanks again for your timely update for this issue.
Comment 26 Zhang Rui 2021-03-11 13:20:10 UTC
Jakku,
please also confirm the problem is gone on your system.
If no, that should be a different problem, and please file a bug report, with detailed description of the symptom you run into.
If the symptom is exactly the same to this bug report, please file a bug to freedesktop directly.
Comment 27 Rev 2021-03-11 14:05:41 UTC
Thank you! Can you close the https://bugzilla.kernel.org/show_bug.cgi?id=212057 then please too, after confirmation from Jakku?

All the best to you! Bye!
Comment 28 Lauri Jakku 2021-03-11 14:12:29 UTC
The confirmation takes some time cause i've got to compile kernels with my network patch, so i get network online.


Just to be clear, the last digit of version nro is rcXX ?

1. does not exist in 5.10.3
2. exists in 5.10.4
3. does not exist in 5.10.6 and later
4. exists in 5.11
Comment 29 Lauri Jakku 2021-03-11 18:00:30 UTC
I'm running on variation of 5.11 now, and i do confirm that issue is there.

I'm build just now the latest mainline build from GIT, the hot stuff, 5.12.0-rc2
Comment 30 Lauri Jakku 2021-03-12 06:24:02 UTC
Something came up, i don't have time for this now.
Comment 31 Rev 2021-03-12 08:00:09 UTC
(In reply to Lauri Jakku from comment #28)
> The confirmation takes some time cause i've got to compile kernels with my
> network patch, so i get network online.
> 
> 
> Just to be clear, the last digit of version nro is rcXX ?
> 
> 1. does not exist in 5.10.3
> 2. exists in 5.10.4
> 3. does not exist in 5.10.6 and later
> 4. exists in 5.11

Hi Lauri Jakku,

No, the last number is no rcXX, it is from the mainline kernel releases.
Comment 32 Rev 2021-03-12 08:01:35 UTC
Created attachment 295807 [details]
mainline

Mainline, not rcXX
Comment 33 Zhang Rui 2021-03-21 16:26:13 UTC
*** Bug 212057 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.