Bug 211027

Created attachment 294483 [details]
PrrocCpuinfoMinimal.txt

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."

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).

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.

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.

Note: updating the mesa drivers brought no change. The issue stays reproducable with the kernel.

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.

The display is connected by HDMI btw.

I am switching to kernel 5.10.6 right now and check if the unwanted behaviour persists.

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.

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?

I got same issue,

00:02.0 VGA compatible controller: Intel Corporation Device 9bca (rev 04)

This seems like a graphics issue, please file a issue to the graphics people instead.

(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.

i think the problem is that the display is powere down, but not up whe system supposed to wake up.

I got HDMI also.

(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.

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/

> 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.

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.

(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.

(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.

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!

OK, I tested it over night and 5.12-rc2 kernel does not have the issue.

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.

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.

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!

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

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

Something came up, i don't have time for this now.

(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.

Created attachment 295807 [details]
mainline

Mainline, not rcXX

*** Bug 212057 has been marked as a duplicate of this bug. ***