On Fri, Feb 14, 2025 at 08:50:00PM +0100, Matthieu Herrb wrote:
> On Thu, Feb 13, 2025 at 09:59:23PM +1100, Jonathan Gray wrote:
> > 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.
> >
> > Seems related to the set_par changes from a few years ago.
>
> Yes! that one works. Thanks
I wonder which invalidate call helped. Is this enough? If not, try
just the call in intel_fbdev_client_hotplug()
Index: sys/dev/pci/drm/i915/display/intel_fbdev.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_fbdev.c,v
diff -u -p -r1.14 intel_fbdev.c
--- sys/dev/pci/drm/i915/display/intel_fbdev.c 7 Feb 2025 03:03:29 -0000
1.14
+++ sys/dev/pci/drm/i915/display/intel_fbdev.c 14 Feb 2025 23:43:26 -0000
@@ -307,6 +307,7 @@ static int intelfb_create(struct drm_fb_
ri->ri_bpos = 0;
break;
}
+ intel_fbdev_invalidate(ifbdev);
}
return 0;
