[Bug 295625] graphics/drm-612-kmod hangs on Alder Lake-S GT1 [UHD Graphics 770]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295625

--- Comment #8 from Darren Mulligan <[email protected]> ---
I was also experiencing the very frequent gpu hangs under all conditions
(couldn’t make it more than 1 hour without it happening). This seems to have
been completely fixed for me as of the drm-612-kmod update last week.

I do still experience the graphical freeze under heavy cpu load (system still
is still accessible and running normally via ssh), however this isn’t new to
drm-612. I experienced this under drm-66 as well.

A workaround that works very well for me is to restrict the cpu use via cpuset.
Setting my user and port building jail to leave a single efficiency core free.
This leaves the core with 0.2%-0.5% “system” activity under top -P and
seemingly solves the problem for me.

Changing the default set instead does not seem to help, with hangs continuing
even with 2 cores reserved. (last tested on drm-66 approximately a year ago). I
speculate this is because the kernel itself avoids using the core if the
default set is changed, but changing the set belonging to all user processes
allows the kernel/driver to keep using the spare core.

vgapci0@pci0:0:2:0:     class=0x030000 rev=0x0c hdr=0x00 vendor=0x8086
device=0x4680 subvendor=0x1462 subdevice=0x7e06
    vendor     = 'Intel Corporation'
    device     = 'Alder Lake-S GT1 [UHD Graphics 770]'
    class      = display
    subclass   = VGA

drmn0: [drm] GPU HANG: ecode 12:1:85dfffff, in MainThread [100188]
drmn0: [drm] Resetting rcs0 for preemption time out
drmn0: [drm] Xorg[100188] context reset due to GPU hang
drmn0: [drm] GPU HANG: ecode 12:1:85dfbfff, in MainThread [100188]
drmn0: [drm] Resetting rcs0 for preemption time out
drmn0: [drm] MainThread[100188] context reset due to GPU hang
drmn0: [drm] GPU HANG: ecode 12:1:85dfbfff, in MainThread [100188]
drmn0: [drm] Resetting rcs0 for preemption time out
drmn0: [drm] MainThread[100188] context reset due to GPU hang

The cpuset workaround is not 100.0% effective, but it changes hangs from being
almost guaranteed if you build or compress something, to once a month or even
less.

-- 
You are receiving this mail because:
You are the assignee for the bug.