You are not logged in.
This started happening pretty recently, I have had no hardware changes in so long.
When I leave my PC idle, the screen turns off automatically via powerdevil (i think that's what KDE plasma uses). sometimes when waking the screen up, the entire PC freezes, and the screen doesn't wake.
I know the PC freezes to some extent because caps lock does not toggle on my keyboard, but somehow audio that was playing can be paused/unpaused via controls on my headphone, so it's not a kernel panic.
the only solution so far is to heard power off and power on, i tried looking into sysrq so i could "gracefully" do this, but my keyboard doesn't have the keys for it, it seems.
initially it only happened on long idles, but today it happened after around 10 minutes when i tried to wake it. this doesn't happen always, but happens enough to be a problem.
the logs are as so (posted in more detail in the link since i didn't wanna dump on here):
.. powerdevil udev events ...
... many kde apps creating placeholder screen ...
... and then the main event: ...
```
kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x0000) - not-present page
```
the full logs (i didn't remove the discord and browser ones cuz that could be relevant somehow, idk): https://pastebin.com/CTypKM5a
workaround i've been doing for quite some time:
i've kind of been putting my PC to sleep everytime i leave it for long (during the night), and i've not faced this "bug" in a few weeks. but it still happened today unfortunately :<
edit:
i've tried disabling and enabling some things (ddc/ci, vrr), and it still happens. also tried lowering refresh rate to 120 (i use 180, which is max)
i've even tried the lts kernels (6.17, and then 6.12), didn't solve the problem
+ a little context might save some debugging time:
around a little over an year ago, i've used kde, and faced no such problems, later on I switched onto hyprland, using hypridle for the idling behaviour, and after linux 7.0, i didn't have this problem, after returning to kde, this happens, could be kde doing things more "completely" than hypridle or something like that. i've no clue, but that might be a crucial clue for someone who knows.
specs:
gpu: radeon hd 7950 running on amdgpu
monitor: asus VG249Q3A (cable: mini-dp to dp v1.4)
Last edited by zor (2026-08-04 23:24:13)
Offline
Aug 05 01:11:29 microboi dolphin[736254]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi krunner[1116750]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fce24bde720 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi polkit-kde-authentication-agent-1[1281]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fcc09bbbda0 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fcd649bd7a0 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi plasmashell[1206]: requesting unexisting screen available rect -1
Aug 05 01:11:29 microboi org_kde_powerdevil[1282]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi plasmashell[1206]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
Aug 05 01:11:29 microboi kernel: #PF: supervisor read access in kernel mode
Aug 05 01:11:29 microboi kernel: #PF: error_code(0x0000) - not-present page
zorvi@microboi ~ % >....
Aug 05 01:11:29 microboi org_kde_powerdevil[1282]: [1060909][441827.776793] prop_connector = 75 -> /dev/i2c-4
Aug 05 01:11:29 microboi org_kde_powerdevil[1282]: [1060909][441827.776793] prop_connector = 75 -> card1-DP-1
Aug 05 01:11:29 microboi org_kde_powerdevil[1282]: [1060909][441827.776813] (dw_watch_display_connections) Time since last return from sleep = 46212221286451 ns = 46212221 ms
Aug 05 01:11:29 microboi ksecretd[935]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi kded6[1195]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi kactivitymanagerd[1261]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen-bin[323279]: [Parent 323279, Main Thread] WARNING: Couldn't map window 0x7fce24bde720 as subsurface because its parent is not mapped.: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:200
Aug 05 01:11:29 microboi zen-bin[323279]: [Parent 323279, Main Thread] WARNING: Couldn't map window 0x7fcc09bbbda0 as subsurface because its parent is not mapped.: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:200
Aug 05 01:11:29 microboi kclockd[1501]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen-bin[323279]: [Parent 323279, Main Thread] WARNING: Couldn't map window 0x7fcd649bd7a0 as subsurface because its parent is not mapped.: 'glib warning', file toolkit/xre/nsSigHandlers.cpp:200
Aug 05 01:11:29 microboi kwalletd6[1780]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi baloorunner[4875]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi DiscoverNotifier[1508]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi kscreenlocker_greet[2163195]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi xdg-desktop-portal-kde[1590]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi dolphin[736254]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi krunner[1116750]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fce24bde720 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi polkit-kde-authentication-agent-1[1281]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fcc09bbbda0 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi zen[323279]: Couldn't map window 0x7fcd649bd7a0 as subsurface because its parent is not mapped.
Aug 05 01:11:29 microboi plasmashell[1206]: requesting unexisting screen available rect -1
Aug 05 01:11:29 microboi org_kde_powerdevil[1282]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi plasmashell[1206]: There are no outputs - creating placeholder screen
Aug 05 01:11:29 microboi kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028
Aug 05 01:11:29 microboi kernel: #PF: supervisor read access in kernel mode
Aug 05 01:11:29 microboi kernel: #PF: error_code(0x0000) - not-present pagePlease don't copy and paste out of a pager or the terminal window - redirect the journal to a file or pastebin service.
The most important part (the kernel stack trace) would come after the duplicated tail of the post.
If the journal actually ends there because of the hard reboot
i tried looking into sysrq so i could "gracefully" do this, but my keyboard doesn't have the keys for it, it seems.
sysrq is usually the same as the print key (even if modern cap stickers may no longer make that clear)
Obviously DP-1 unregisters in return to the DPMS state, your desktop becomes zero-sized and a lot of kde clients announce that they created a dummy screen as hail mary
But it's not clear why and where (in which module) this would result in a nullptr resolution in the kernel (ie. whether this is a direct result of the output loss or maybe induced by some userspace response to it)
The power settings of your monitor might help to avoid the trigger by keeping the output present.
Idk whether you can still tell KDE/wayland to ignore output changes ![]()
i've tried disabling and enabling some things (ddc/ci, vrr)
In KDE or the monitor OSD?
https://wiki.archlinux.org/title/KDE#Va … n_problems
Online
I'm sorry about the output, I got a new one with `journalctl -b -2 -n 300 --no-pager | wl-copy` https://pastebin.com/mj0qmmXs
> If the journal actually ends there because of the hard reboot
i came back to my PC at around 1:18, and THEN hard rebooted, so the journal was pretty much silent from after that until the hard reboot
> sysrq is usually the same as the print key
ik, i have a 75% keytboard that has neither
> But it's not clear why and where (in which module) this would result in a nullptr resolution in the kernel (ie. whether this is a direct result of the output loss or maybe induced by some userspace response to it)
ooh, here's one with -p 3, it shows more errors:
`journalctl -b -2 -n 300 -p 3 --no-pager | wl-copy` https://pastebin.com/FbAKSEfp
> The power settings of your monitor might help to avoid the trigger by keeping the output present.
i have not done anything with power settings, i don't know about monitor power settings :<
> In KDE or the monitor OSD?
ddc/ci from kde monitor settings, and vrr from the monitor osd
should I still try disabling ddcutil via the service? could that even be the problem? (from the new -p 3 logs)
Offline
The journal still ends before the stack trace - the hard reboot will prevent the journal from being synced to disk.
should I still try disabling ddcutil via the service?
it's worth a shot.
The other journal has a crash in some mozilla process and
Aug 04 17:37:06 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
Aug 04 17:37:06 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
Aug 04 17:37:06 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failed
Aug 04 20:41:18 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1123: core_link_write_dpcd (DP_DOWNSPREAD_CTRL) failed
Aug 04 20:41:18 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1128: core_link_write_dpcd (DP_LANE_COUNT_SET) failed
Aug 04 20:41:18 microboi kernel: amdgpu 0000:01:00.0: [drm] *ERROR* dpcd_set_link_settings:1156: core_link_write_dpcd (DP_LINK_BW_SET) failedbut those predate the nullptr deref by 3½ hours.
What model is your keyboard? Maybe print/sysrq is behind some Fn key?
Or do you maybe also have a grown up keyboard? ![]()
Online
hahaha, my keyboard is the Stelseries Apex 7 wired (not grown up at all)
> The journal still ends before the stack trace - the hard reboot will prevent the journal from being synced to disk.
oh. there's nothing i can about that then, right?
> The other journal has a crash in some mozilla process
that's probably zen browser, shouldn't be anywhere close to being the cause ig, right?
> but those predate the nullptr deref by 3½ hours.
maybe it's something that errors multiple times already in the background, but recovers on it's own? but in a specific case it doesn't and null pointer? (hence the unrecoverable state ig)
ill disable ddcutil via the service then, but the problem doesn't happen always, so it will be hard to know if that fixed the solution, next error might happen a month later FAIK
Last edited by zor (2026-08-05 15:18:38)
Offline
Gemini says SS+P is PrtScn - you can check that w/ "sudo evtest", look for KEY_SYSRQ
Online
`Event code 99 (KEY_SYSRQ)` but no idea on how to activate event code 99, i do have keyd for some shortcuts, so device name is "keyd virtual keyboard"
hmm, interesting, SS+P does nothing, maybe I can connect my keyboard to a windows VM and use steelseries to map SS+P to print
Offline
If SS+P prints KEY_SYSRQ you can use that as sysrq
https://wiki.archlinux.org/title/Keyboa … el_(SysRq)
Eg. Alt + SS+P,m will print memory information to the console (but nb. you'll have to explicitly enable the sysrq feature first)
Online
I alr enabled sysrq a little before.
I'll map my keyboard to have SS+P be print and it should be okay, atleast I won't have to hard reboot, but this is just a way to gracefully reboot. the main problem is still unkown, right?
Offline
Mapping anything w/ some userspace daemon won't work.
If you run evtest and SS+P produces "Event code 99 (KEY_SYSRQ)" there's absolutely nothing else you've to do.
SS+P *is* your print/sysrq key.
but this is just a way to gracefully reboot
Yes, hopefully that allows you to preserve more of the journal and notably the kernel backtrace.
Online
yes, i didn't mean mapping w a daemon, I meant on the keyboard itself by connecting it to a windows machine with the steelseries app
evtest shows code 99 in the available keys, not when i press ss+p, pressing ss+p outputs nothing
> Yes, hopefully that allows you to preserve more of the journal and notably the kernel backtrace.
Nice ![]()
Offline
Did you try restoring a kernel package from pacman cache which used to be fine in the past.
If audio control works, maybe the machine would let you ssh into it?
Offline
@mmy8x
> Did you try restoring a kernel package from pacman cache which used to be fine in the past.
nope, this is a new arch installation compared to what i used to use, but i did try the lts of that time (6.12) like I said in the original post
> If audio control works, maybe the machine would let you ssh into it?
this is my only machine ![]()
Offline
What model is your keyboard?
Offline
@Topi202 Please read the thread or atleast pass it through an LLM for an answer, it's literally in this thread
ps. it's the Steelseries Apex 7 (not pro)
Offline