On Mon, Feb 10, 2025 at 02:17:33PM +0100, Matthieu Herrb wrote:
> On Mon, Feb 10, 2025 at 11:40:25PM +1100, Jonathan Gray wrote:
> > On Mon, Feb 10, 2025 at 12:06:58PM +0100, Matthieu Herrb wrote:
> > > On Mon, Feb 10, 2025 at 09:10:26PM +1100, Jonathan Gray wrote:
> > > > On Mon, Feb 10, 2025 at 08:29:34AM +0100, Matthieu Herrb wrote:
> > > > > On Mon, Feb 10, 2025 at 08:20:05AM +0100, Matthieu Herrb wrote:
> > > > > > On Mon, Feb 10, 2025 at 05:49:37PM +1100, Jonathan Gray wrote:
> > > > > > > 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.
> > > > > >
> > > > > > Hmm intersting, switching VT inedeed works and cause a screen
> > > > > > refresh.
> > > > > > So in text mode I can log in and run commands blindly. Switching to
> > > > > > anothr VT and back will display the result.
> > > > > >
> > > > > > Also now I access the machine through the net. In my previous
> > > > > > attempt
> > > > > > I couldn't, probably because I did enter DDB after hitting
> > > > > > Ctrl+Alt+ESC, but without output on the screen I thought it failed.
> > > > > >
> > > > > > None of the printfs show up, but here's a full dmesg with DRMDEBUG
> > > > > > (and a few VT switches that add more lines at the end)
> > > > > >
> > > > >
> > > > > Another data point: X or Wayland work normally if I start them from
> > > > > these VT switches. So it's just wsdisplat that doesnt't refresh. (And
> > > > > if I had xenodm started by rc.conf.local, I probably wouldn't notice
> > > > > the issue).
> > > >
> > > > does forcing a switch help?
> > >
> > > No unfortunatly it does not.
> >
> > going back to intel_fbdev_restore_mode() ?
>
> Unfortunatly no luck either. It looks more like some cache or buffer
> flush missing after basic rasops updates (putchar and so).
> I've tried to follow the function pointers from wsdisplay -> rasos ->
> rasos_vcons ... but got lost.
the recent commits or the following?
Index: sys/dev/pci/drm/i915/i915_driver.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_driver.c,v
diff -u -p -r1.20 i915_driver.c
--- sys/dev/pci/drm/i915/i915_driver.c 7 Feb 2025 03:03:28 -0000 1.20
+++ sys/dev/pci/drm/i915/i915_driver.c 11 Feb 2025 13:20:19 -0000
@@ -2452,6 +2452,12 @@ inteldrm_attachhook(struct device *self)
config_found_sm(self, &aa, wsemuldisplaydevprint,
wsemuldisplaydevsubmatch);
+{
+ struct drm_device *dev = &dev_priv->drm;
+ struct drm_fb_helper *helper = dev->fb_helper;
+ struct fb_info *fbi = helper->info;
+ fbi->fbops->fb_set_par(fbi);
+}
return;
fail:
