[TLDR: adding this regression to regzbot; most of this mail is compiled from a few templates paragraphs some of you might have seen already.] Hi, this is your Linux kernel regression tracker speaking. Adding the regression mailing list to the list of recipients, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html Also adding the authors and reviewers of the culprit and two appropriate mailing lists. On 07.12.21 01:21, Brandon Nielsen wrote: > Monitors no longer sleep properly on my system (dual monitor connected > via DP->DVI, amdgpu, x86_64). The monitors slept properly on 5.14, but > stopped during the 5.15 series. I have also filed this bug on the kernel > bugzilla[0] and downstream[1]. > > I have performed a bisect, first "bad" commit to master is > 55285e21f04517939480966164a33898c34b2af2[1], the same change made it > into the 5.15 branch as e3b39825ed0813f787cb3ebdc5ecaa5131623647. TWIMC: That was for 5.15.3 > I have > verified the issue exists in latest master > (a51e3ac43ddbad891c2b1a4f3aa52371d6939570). > > Steps to reproduce: > > 1. Boot system (Fedora Workstation 35 in this case) > 2. Log in > 3. Lock screen (after a few seconds, monitors will enter power save > "sleep" state with backlight off) > 4. Wait (usually no more than 30 seconds, sometimes up to a few minutes) > 5. Observe monitor leaving "sleep" state (backlight comes back on), > but nothing is displayed > > [0] - https://bugzilla.kernel.org/show_bug.cgi?id=215203 > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2028613 To be sure this issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 55285e21f04517939480966164a33898c34b2af2 #regzbot title fbdev/efifb: Monitors no longer sleep (amdgpu dual monitor setup) #regzbot ignore-activity Reminder: when fixing the issue, please add a 'Link:' tag with the URL to the report (the parent of this mail), then regzbot will automatically mark the regression as resolved once the fix lands in the appropriate tree. For more details about regzbot see footer. Sending this to everyone that got the initial report, to make all aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then. Don't worry, I'll send further messages wrt to this regression just to the lists (with a tag in the subject so people can filter them away), as long as they are intended just for regzbot. With a bit of luck no such messages will be needed anyway. Ciao, Thorsten, your Linux kernel regression tracker. P.S.: As a Linux kernel regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them. Unfortunately therefore I sometimes will get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me about it in a public reply. That's in everyone's interest, as what I wrote above might be misleading to everyone reading this; any suggestion I gave they thus might sent someone reading this down the wrong rabbit hole, which none of us wants. BTW, I have no personal interest in this issue, which is tracked using regzbot, my Linux kernel regression tracking bot (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting this mail to get things rolling again and hence don't need to be CC on all further activities wrt to this regression.
