Too many acronyms for one simple issue - blank screen acpi monitors and things

Operating Systems & Open Source Linux
, ,
1

Sup everyone, it’s been too long! and of course I come back with a big heaping pile of shit that should be working but isn’t

So, I’ve had this issue on multiple installs, for whatever reason the latest ubuntu release worked (until gdm game up the gun or something, nothing but a cursor and blank screen but bleh) but the issue is after a certain amount of inactivity my monitors will turn off, and after pressing a button or moving the mouse the monitors start and then nothing.

No courser, no ctl+alt+fx ttys, no nothing. Just extreme sadness and never leaving anything important running when I get out of my chair

So I’m back to arch, no real issues there. Trying openbox+tint2 and absolutely loving it. Never used such a stripped down DE (it’s not even really a DE and it’s just so damn good.)

Now, I’m that kind of fucked up that I actually really enjoy arch. Nothing user side of the kernel is getting in the way, and since I don’t have konsole or whatever gnome uses learning to configure urxterm has been a treat. All around damn lovely.

But something is turning off my monitors and then not bringing the desktop back to me.

I am running Systemd, systemctl suspend works. Suspend to ram is set to auto (auto or disabled) in eufi, and everything else acpi in eufi is set to be controlled by OS and allowed keyboard inputs to wake up.

So my number one suspect is dpms, or Display Power Managment Signaling. Back in the day you could just disable KMS and have an xorg.conf and shit, but none of that is relevant since all the latest drivers (and any driver with good performance) uses kms by default and requires it.

I found a command xset dpms 0 0 0 && xset s noblank && xset s off that is supposed to set dpms off. I just tried it, we shall see if it works, but I though I already disabled it already, still b

Be aware, I am rubberducking with this post. I may figure it out and find that the noblank option works great, and I can work on setting up an automated sys suspend.

I’m a bit frazzled, gonna go find someone’s openbox configs and steal them while I wait for the abyss to come back, if something is unclear just make a reply and I’ll try to be as verbose as possible.

xset dpms 0 0 0 && xset s noblank && xset s off did the trick. Just have to setup something else now.

1 Like
2

I made a script to run at the start with that line for xset, and the problem is still there. bah.

but xset q tells me that dpms is on. So it’s likely still my issue.

After setting dpms off my monitors never turn off, but eventually everything freezes after inactivity.

dpms is not the issue.

1 Like
3

What is your GPU? And does it still happen if you stop X and leave the system inactive?

4

Never checked without X running. GPU is Vega 64.

I’m wondering at this point if the screen saver is compounding the issue. I’m gonna sleep on it again, after running the command, and see if my session is still alive when I wake up,

I know there’s some logging I can run that I need to configure, but I don’t have the acuity or the time at the moment.

Suffice to say I have run xset -dpms multiple times at this point and it did not fix the issue.

I’m running the previous command xset dpms 0 0 0 && xset s noblank && xset s off and seeing if it keeps my session… I want to run systemctl suspend and see what happens in the morn, but I’m worried whatever setting is nuking my current session is going to fuck with it. At this point I don’t think it’s dpms, but something else for sure is messing it up.

When I get the time I’ll try updating the firmware on my mobo but I don’t imagine that the current revision is going to make an issue,

5

I have the same GPU and see the exact same behaviour, I ended up just turning off DPMI/powersave which solved it for me. I don’t see full system lockups though as I am running with the VEGA in a VM.

6

Problem for me is that I love that fact that amdgpu is foss and part of the kernel ostensibly, and have assigned myself to run that as my GPU for my linux installs. While I sve my pennies to get a used 1080/1080 ti for VMs and gpu passthrough/looking glass.

Do you remember how you set power saving off? if that worked for you maybe I can make a script to run systemctl suspend after a certain amount of time to get the same effect. Because I know that works. Despite what anyone might say about systemd. It works best for my use case.

7

I simply used xset -dpms as a startup commend for i3.

8

See, even doing that and confirming dpms is off fails to keep my system from freezing. If Xscreensaver doesn’t have predefined config maybe it’s that, but as far as I can tell it’s just something about the power management.

I remember reading a while bac about s states and something about a s1-s3 state, dommer in the telegram jogged my memory, but that’s as far as I got.

9

Check the GPU temps, as in, put your hand on the top edge of the card, I found mine gets VERY hot even idle, so I manually push the default fan speed up via the /sys file.

10

Mines fairly hot on idel, 50c, but even when setting the fan faster, nothing changes. Through an echo to the fan speed, or through something like radeon-profile.

11

So DPMS is on, and xscreensaver was installed, but it wasn’t running. I’ve started it. We’ll see what happens.

It works. We did it. run your screensavers kids.

Nope.

12 
[drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:636

So this is the culprit so far. Popping me to many bugzilla links for people with the same issue. People seem to have fewer issues running with X than Wayland, but I’m running X with no difference.

I’m going to experiment with just turning off all power saving options for the screens with nothing running and see what I return to after work.

13

What kernel version are you on? I’m on the latest 4.19 rc7 with linux-mainline-vfio package from AUR, I also have a Vega 64, albeit under water, and I have found 4.19 to have the least issues so far. Missing that ck patch but it will come in time, rather have fewer issues with the GPU driver. Still some niggles, like one of my monitors doesn’t show the 75 Hz option, but that’s been broken since 4.18 and not a big deal for its use case.

14

I actually don’t have any issues with refresh rates still, even on the 1440p 144hz.

I’m on 4.18-something. I’ll check the aur for a amdnext kernel, or just build 4.19.

15

It’s probably because I have 4 of them but yea try the linux-mainline package, doesn’t hurt to try. Certainly some amdgpu driver improvements in there.