04:18 <dramforever> Hi, I'm currently using a "custom" built NixOS kernel and I'm trying to figure out what i'm doing wrong. I'm on an "Apple MacBook Pro (14-inch, M1 Pro, 2021)" and asahi-6.14.8-1, and on boot, if I have a monitor plugged into HDMI, there's a chance that it hangs around where graphical interface should be starting with only a cursor on the top left on the laptop screen and nothing on HDMI. At this point the system is responsive to sysrq but

04:18 <dramforever> otherwise hung...

04:19 <dramforever> sysrq "w" tells me dcp_hotplug is blocked and in the stack trace it looks like it's calling apple_crtc_atomic_disable then dcp_poweroff then it tries to mutex_lock which just blocks, so it looks like a deadlock? Is there anything known like that?

04:20 <dramforever> (I'm currently trying to copy down the whole stack trace from my photo...)

04:26 <chadmed> wayland or x11?

04:26 <dramforever> wayland, sddm in fact

04:26 <chadmed> is sddm being launched in kwin_wayland? iirc it still doesnt do this by default

04:27 <dramforever> oh, it might be weston not kwin_wayland, let me check

04:28 <dramforever> no it's kwin_wayland

04:28 <chadmed> hmm

04:28 <dramforever> i configured it to do that

04:28 <chadmed> we did have issues at some point with something similar but i thought the issue was fixed

04:28 <chadmed> that was related to planes though and wasnt an issue with crtc ops

04:28 <dramforever> this seems to be highly dependent on the timing of loading of a few kernel modules

04:29 <chadmed> likely a race or deadlock then

04:34 <dramforever> Stack trace is like this https://fars.ee/AH-SPBD-9uv6NFYlpJTSXvT7YzBr

04:34 <dramforever> I hope I copied everything down right

04:36 <dramforever> is this... supposed to happen? I see drm_client_dev_hotplug twice but I don't know if they're for the same dev

08:27 <dramforever> just for the record i'm going back to asahi-6.14.6-1 for now and see for sure if it's just the new update, and then possibly crawl through the git log and see if anything looks like it could be responsible

08:43 <dramforever> ... nope same thing in 6.14.6-1

09:03 <jannau> dramforever: can ssh in and restart sddm?

09:03 <dramforever> i can't believe i've never tried that, but honestly i don't expect it to work with the drm thing just locked

09:05 <jannau> if it does work, I can reproduce it. Since restarting sddm worked I never blamed it on the driver

10:24 <chadmed> lmfao i spent almost all day chasing an off-by-one

10:25 <chadmed> (of my own making of course)

10:25 <dramforever> jannau: it does not work :(

10:25 <dramforever> on restart sddm asks systemd-logind to open the gpu for it, and then logind joins the team of blocked processes

10:26 <chadmed> that sounds like something very wrong with your system. sddm should not need to ask to open the gpu

10:27 <dramforever> i'm not sure about the logind part but i'm fairly certain that's how systemd works

10:28 <chadmed> oh yes i misunderstood

10:29 <chadmed> i thought logind was asking _you_ for permission to open the gpu

10:29 <jannau> I assume gpu means the display controllers drm device. not sure if it is sddm itself or if that's deferred to kwin though

10:29 <dramforever> yeah sorry, some drm device

10:30 <dramforever> the thing i'm seeing is systemd-logind blocked in an open syscall on some drm stuff

10:31 <dramforever> i also bpftrace'd drm_client_dev_hotplug and it's definitely the same device both time, so it's recursing and just deadlocking on itself

11:21 <dramforever> New observation: I can get this (suspected) deadlock without even starting SDDM. It occurs at the module loading stage. Starting SDDM at the right time actually *prevents* the deadlock

11:29 <chadmed> is it _only_ with a second monitor plugged in?

11:32 <dramforever> yes, if by "second monitor" you're counting the internal display as the first

12:06 <dramforever> so i reverted this and it obviously solves my problem but that doesn't really explain anything https://github.com/AsahiLinux/linux/commit/794a1166e09f0b836b95c13fc7f999c5a08a6260

12:07 <dramforever> (obviously, as in, disconnected_hpd_event which calls drm_kms_helper_connector_hotplug_event deadlocks, so i just removed disconnected_hpd_event)

12:34 <dramforever> okay this is the "full" stack trace https://fars.ee/DkfT i get when the deadlock happens

12:37 <dramforever> since this happens just with few kernel modules, i could theoretically try to reproduce it with a "clean" kernel and a busybox initramfs but i'm not doing that today...