On Mon, Feb 10, 2025 at 07:27:28AM +0100, Matthieu Herrb wrote:
> Hi,
>
> sorry to not having being able to test the drm upgrade on this machine
> earlier, but the new drm code hangs on boot shorly after attachine
> drm, clearing the screen and displaying:
>
> wsdisplay0 at inteldrm0 mux1: console (std, vt100, emulation), using
> wskbd1
>
> It's not a hard hang (the capslock led still toggles, and the CPU
> don't seem to go full speed, power use stays uner 1A at 19V), but I
> can't enter DDB nor do a Ctl+Alt+Del to trigger a reboot.
> I've the latest BIOS for this machine.
I had another report like this today. Machine could still change
virtual terminals. It was also Alder Lake.
Unfortunately it isn't something I see on my Alder Lake or
Meteor Lake machines.
Perhaps it involves some kind or deferred fbdev or hotplug.
Do either of these printfs show?
Index: sys/dev/pci/drm/drm_fb_helper.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/drm_fb_helper.c,v
diff -u -p -r1.41 drm_fb_helper.c
--- sys/dev/pci/drm/drm_fb_helper.c 7 Feb 2025 03:03:08 -0000 1.41
+++ sys/dev/pci/drm/drm_fb_helper.c 10 Feb 2025 06:46:09 -0000
@@ -224,8 +224,10 @@ __drm_fb_helper_restore_fbdev_mode_unloc
if (!drm_fbdev_emulation || !fb_helper)
return -ENODEV;
- if (READ_ONCE(fb_helper->deferred_setup))
+ if (READ_ONCE(fb_helper->deferred_setup)) {
+printf("%s deferred_setup\n", __func__);
return 0;
+ }
#ifdef __OpenBSD__
force = true;
@@ -248,8 +250,10 @@ __drm_fb_helper_restore_fbdev_mode_unloc
fb_helper->delayed_hotplug = false;
mutex_unlock(&fb_helper->lock);
- if (do_delayed)
+ if (do_delayed) {
+printf("%s do_delayed\n", __func__);
drm_fb_helper_hotplug_event(fb_helper);
+ }
return ret;
}
