Screen keeps modesetting on high refresh rate

CLiPPY · 2026-01-18 05:11:15

I have a 6600 xt, and when I set my refresh rate to something higher than 60 (like 180) it keeps randomly going black for a second (modesetting I guess?) it happens a lot.

I had this problem with arch at first, but I had the itch to distrohop anyway so I ignored it and installed cachyos, then it also happened the same way. I'm back on vanilla arch now.

I’ve seen a post ( https://discuss.cachyos.org/t/high-refr … creen/5884 ) on cachyos forum where downgrading cachyos-headers worked, but I rolled back the kernel and the headers to the version when it was working but it didn’t

I have an HDMI cable, which another post suggested it was the solution to get a DP cable, but like this works fine on windows, and worked also fine in linux for several months

this is driving me crazy fr!

NOTES:
1- this doesn’t seem to be a kernel problem, on cachyos I tried latest cachyos, and the previous one that already worked, linux-lqx, and cachyos lts.. NONE WORKED! also on arch I tried both vanilla linux and linux-lqx.
2- VRR is off, I'm on niri rn (but this also happened on KDE and every other desktop, both X11 and wayland)
3- no updates at all happened the day before the problem happens, the same configuration and setup is the same one working fine yesterday, but not today
4- I've been trying to record the dates when this problem occurs, as because of it's randomness I think this is just like a bug with a driver making it not work on this exact date for some reason, unfortunately I had the idea to record occurrences lately so I only have 2 dates: 11-1-2026 / 18-1-2026

# EDIT 1:
5- This also happens on live ISO's (I tried NixOS for gnome, EndeavourOS for kde, and mint for cinnamon)
6- forgot to mention that setting the refresh rate to 60 makes the problem disappear, but I bought a 180hz monitor and I want to use it all XD

Last edited by CLiPPY (2026-01-18 05:56:12)

V1del · 2026-01-18 13:09:55

What resolution? Generally speaking you only get up to HDMI 2.0 and not HDMI 2.1 on linux due to licensing disputes with the HDMI forum. So DP will generally work better. If it's as intermittent as it seems to be, could also be the cable (slight bend somewhere or so) in general which leads to unstable behaviour when it pushes more data through, you could also test a different HDMI cable.

Do you get any logs in the journal or so when this happens? You can filter the journal to exact timestamps: https://wiki.archlinux.org/title/System … ing_output

CLiPPY · 2026-01-18 19:06:16

1920x1080
again.. it worked for months before this problem started happening randomly, I kinda believe it is a bug in the amdgpu driver.

seth · 2026-01-18 21:19:18

1080p@180Hz is within the HDMI 2.0 specs - also afaiu the output generally works at 180Hz and just sometimes flickers, it's not that you try to set a 180Hz mode and get a flicker show until you settle for 60Hz?

I kinda believe it is a bug in the amdgpu driver.

Ahem…

I had this problem with arch at first, but I had the itch to distrohop anyway so I ignored it and installed cachyos, then it also happened the same way. I'm back on vanilla arch now.

no updates at all happened the day before the problem happens, the same configuration and setup is the same one working fine yesterday, but not today

5- This also happens on live ISO's (I tried NixOS for gnome, EndeavourOS for kde, and mint for cinnamon)

Please post your complete system journal for a boot after this happend

sudo journalctl -b | curl -F 'file=@-' 0x0.st

BUT:
Do you have other HDMI cables?

CLiPPY · 2026-01-19 02:45:51

https://0x0.st/PK_4.txt
here is my journalctl log
btw I'm so sorry but I'm travelling today so I can't really test it or do anything. this only happens on my main computer. but I have to travel unfortunately.

seth · 2026-01-19 09:51:03

The boot is only 2 minutes, there're no driver errors but

Jan 19 05:43:05 battlestation niri[937]: 2026-01-19T02:43:05.267300Z  WARN niri::backend::tty: output "HDMI-A-1": configured mode 1920x1080@180.03 could not be found, falling back to preferred
Jan 19 05:43:05 battlestation niri[937]: 2026-01-19T02:43:05.267309Z DEBUG niri::backend::tty: output "HDMI-A-1": picking mode: Mode { name: "1920x1080", clock: 148500, size: (1920, 1080), hsync: (2008, 2052, 2200), vsync: (1084, 1089, 1125), hskew: 0, vscan: 0, vrefresh: 60, mode_type: ModeTypeFlags(PREFERRED | DRIVER) }

If this covered some flicker start an X11 session and post the output of

xrandr --verbose

Edit: ffwi,

Jan 19 05:43:18 battlestation niri[937]: 2026-01-19T02:43:18.778784Z DEBUG niri::backend::tty: output "HDMI-A-1": picking mode: Mode { name: "1920x1080", clock: 415590, size: (1920, 1080), hsync: (1968, 2032, 2080), vsync: (1083, 1088, 1110), hskew: 0, vscan: 0, vrefresh: 180, mode_type: ModeTypeFlags(DRIVER) }

and *before* starting any graphical target

Jan 19 05:42:28 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
Jan 19 05:42:28 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
Jan 19 05:42:28 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
Jan 19 05:42:29 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
Jan 19 05:42:29 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND

but not afterwards.

415590 would be lower than cvt1.2 reduced blanking (424.08 MHz)

Last edited by seth (2026-01-19 09:55:51)

CLiPPY · 2026-01-19 11:07:47

Dumb me, I sent a journalctl of the time I still haven't configured it right, so I booted with 60, then changed it to 180.03 (which is wrong), then 180.003 which is right, so ignore that error.

And I didn't understand anything afterwards, sorry!

seth · 2026-01-19 15:07:43

Ok
1. did the flicker happen in the minute after setting the 180Hz mode and before dumping the journal?
2. please post a journal that covers the flicker and the xrandr --verbose output (from an X11 session, the xrandr output under wayland is meaningless)
3. https://en.wikipedia.org/wiki/Coordinated_Video_Timings but monitors can and frequently do operate on other modes (the xrandr ouput will conveniently contain the edid to look at )

CLiPPY · 2026-01-19 15:24:08

Q1. Yes, it happened
For the others, I'm sorry but I'm aboard, and I believe when I come back the problem will be magically gone.

I've got the idea of changing the date of the system and doing a reboot. As I believe it is somehow related to the date and it has a pattern in a way or in another, so after like 3 days I'll post an update hopefully when I'm back home.

CLiPPY · 2026-01-23 05:55:56

btw here is a better journalctl:
https://0x0.st/PPy7.txt
it is weird, but although I haven't expected it to happen now, it is happening?

seth · 2026-01-23 15:03:45

Still

Jan 23 08:50:37 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
Jan 23 08:50:38 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
Jan 23 08:50:38 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
Jan 23 08:50:38 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
Jan 23 08:50:39 battlestation kernel: workqueue: drm_fb_helper_damage_work [drm_kms_helper] hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND

but only ahead of the actual GUI processes.

We're lacking the xrandr output, there're no indications of a kernel layer problem.
Either niri uses the wrong mode or

V1del and later on seth wrote:

a different HDMI cable

Btw

this works fine on windows

did you confirm in the monitor OSD that you're actually running at 180Hz at this point?

CLiPPY · 2026-01-23 15:14:05

Niri uses the right mode, I'm sure because it worked earlier in niri, KDE, cinnamon, and it fails in all of them even in live ISOs.
The cable is also fine for sure, as, again, it already worked on all linux desktops and it works rn in windows.

I'm really sorry about the xrandr output, I will do it asap, I just forgot, and thanks for trying hard to help an unhelpful person like me , really appreciate it!

seth · 2026-01-23 15:50:24

So everything is doing everything right and it used to work but now doesn't work anywhere.

It's the cable and windows is probably lying about the active mode.

CLiPPY · 2026-01-23 19:41:59

https://pastebin.com/01N4qN6d
Here is the xrandr verbose output on linux mint iso.
And no, although I like to say that windows is lying, it is not this time and the monitor's OSD is showing 180

seth · 2026-01-23 20:30:09

    DTD:  1920x1080  180.002599 Hz  16:9    199.803 kHz    415.590000 MHz (aspect 16:9, no 3D stereo)
      Modeline "1920x1080_180.00" 415.590  1920 1968 2032 2080  1080 1083 1088 1110  +HSync +VSync

That's what niri is using.
Interestingly

	vrr_capable: 1 
		range: (0, 1)

though I don't really see that based in the EDID

But

  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2

and

	vrr_capable: 1 
		range: (0, 1)
	Colorspace: Default 
		supported: Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC
	content type: No Data 
		supported: No Data, Graphics, Photo, Cinema, Game
	max bpc: 16 
		range: (8, 16)

If windows is running the output at YCbCr 4:2:2 (that's not what you want) you'd get away w/ 340MHz

Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General and ideally from arch, not mint.

CLiPPY · 2026-01-24 16:02:40

Well, I'm sorry, but this is why I'm actually so annoyed by this problem.
it existed today in the morning, but now in the evening... NOPE!!! this makes it really frustrating because I have been sooooo careful not to change any variable throughout all of this time. always has been the same packages, hardware, nothing changed except for time... and it is FULLY GONE NOW!!!!!

Once this problem comes again (which usually happens every week or sometimes even less) I will post an update.

Oh and btw I will try to change my date and time of the system to see if time is actually somehow the cause of this problem?

seth · 2026-01-24 16:07:20

There's a golden rule in that's been valid throughout history and passed from one engineer to another ever since the construction of the great Pyramids and maybe Noah's ark and that you will now please repeat after me:
It. Is. The. Cable.

CLiPPY · 2026-01-24 16:23:02

well I tried to change the hardware and system time but the problem was not there.
however because I've had my OSD on and forgot to turn it back off I noticed something when it is running well, the fps counter is spiking every while and then in a pattern that kinda matches the problem when it was happening. so although it usually says 180 it spikes down to 153 or smth like that for literal moments and then goes back up to 180.

Note that VRR is off, here is `niri msg outputs`: https://0x0.st/PZ20.txt
see it says disabled, and this also happens in mint and others.

Don't worry I will buy a DP cable but until I do, I will keep researching this problem because I still think... It. Is. Not. The. Cable.

CLiPPY · Yesterday 13:49:27

Well, after a long time without facing it, it is back, again..

it is the same error, unfortunately I didn't replace the cable for a DP one yet. (Because I thought the problem got patched or something).
there is no new information to be honest, just, perhaps.. The date (15/2/2026)

CLiPPY · Yesterday 13:50:54

CLiPPY wrote:

however because I've had my OSD on and forgot to turn it back off I noticed something when it is running well, the fps counter is spiking every while and then in a pattern that kinda matches the problem when it was happening. so although it usually says 180 it spikes down to 153 or smth like that for literal moments and then goes back up to 180.

Note that I believe this is the most valuable piece of information I collected yet...

seth · Yesterday 14:08:16

There're 165Hz and 144Hz modes, if the OSD suggests 153Hz you're running VRR, can you disable that in the monitor OSD?

CLiPPY · Yesterday 15:43:28

Disable what?
Also I'm pretty sure I'm on 180 Hz, and VRR is off on Niri / the DE I'm on.
But it was spiking down to 153 randomly for moments, then return to 180.

seth · Yesterday 15:46:46

VRR in the monitor settings (of the monitor, their OSDs typically allow that)

But it was spiking down to 153 randomly for moments, then return to 180.

Tbc, that information from the monitor, not some FPS counter merely indicating that something could not quite render at 180fps?

CLiPPY · Yesterday 15:51:14

Yes, this is the monitor OSD showing that fps number. I'll search for VRR setting in the monitor right now

CLiPPY · Yesterday 16:57:49

Ughhh...
This problem is driving me crazy for real, I've been playing around with the settings of my monitor for a while, but there is no clear answer, I tried to limit it to 1 variable, but even on the same configuration of the monitor the problem disappears for a while and after logging out and back in it is back there, I just don't really get what is Happening.
https://ibb.co/album/YD0xKs
here are the full settings my monitor (Acer VG240Y M3)

Arch Linux

#1 2026-01-18 05:11:15

Screen keeps modesetting on high refresh rate

#2 2026-01-18 13:09:55

Re: Screen keeps modesetting on high refresh rate

#3 2026-01-18 19:06:16

Re: Screen keeps modesetting on high refresh rate

#4 2026-01-18 21:19:18

Re: Screen keeps modesetting on high refresh rate

#5 2026-01-19 02:45:51

Re: Screen keeps modesetting on high refresh rate

#6 2026-01-19 09:51:03

Re: Screen keeps modesetting on high refresh rate

#7 2026-01-19 11:07:47

Re: Screen keeps modesetting on high refresh rate

#8 2026-01-19 15:07:43

Re: Screen keeps modesetting on high refresh rate

#9 2026-01-19 15:24:08

Re: Screen keeps modesetting on high refresh rate

#10 2026-01-23 05:55:56

Re: Screen keeps modesetting on high refresh rate

#11 2026-01-23 15:03:45

Re: Screen keeps modesetting on high refresh rate

#12 2026-01-23 15:14:05

Re: Screen keeps modesetting on high refresh rate

#13 2026-01-23 15:50:24

Re: Screen keeps modesetting on high refresh rate

#14 2026-01-23 19:41:59

Re: Screen keeps modesetting on high refresh rate

#15 2026-01-23 20:30:09

Re: Screen keeps modesetting on high refresh rate

#16 2026-01-24 16:02:40

Re: Screen keeps modesetting on high refresh rate

#17 2026-01-24 16:07:20

Re: Screen keeps modesetting on high refresh rate

#18 2026-01-24 16:23:02

Re: Screen keeps modesetting on high refresh rate

#19 Yesterday 13:49:27

Re: Screen keeps modesetting on high refresh rate

#20 Yesterday 13:50:54

Re: Screen keeps modesetting on high refresh rate

#21 Yesterday 14:08:16

Re: Screen keeps modesetting on high refresh rate

#22 Yesterday 15:43:28

Re: Screen keeps modesetting on high refresh rate

#23 Yesterday 15:46:46

Re: Screen keeps modesetting on high refresh rate

#24 Yesterday 15:51:14

Re: Screen keeps modesetting on high refresh rate

#25 Yesterday 16:57:49

Re: Screen keeps modesetting on high refresh rate

Board footer