Open vishwin opened 6 years ago
This seems to only happen when using x11-drivers/xf86-video-intel
; software rendering with the modesetting
driver hasn't resulted in a panic like this, yet.
If possible can you verify of glamorgl is enabled when using modesetting? In my experience modesetting+glamorgl tends to be pretty stable compared to the intel driver which is deprecated upstream by Xorg I believe.
For example, if I remove my pre-existing xorg.conf configuration X will autodetect things and setup modesetting+glamorgl correctly.
This is without any xorg.conf at all. glamoregl doesn't seem to load though:
[ 3180.216] (II) Loading sub module "glamoregl"
[ 3180.216] (II) LoadModule: "glamoregl"
[ 3180.217] (II) Loading /usr/local/lib/xorg/modules/libglamoregl.so
[ 3180.222] (II) Module glamoregl: vendor="X.Org Foundation"
[ 3180.222] compiled for 1.18.4, module version = 1.0.0
[ 3180.222] ABI class: X.Org ANSI C Emulation, version 0.4
[ 3180.222] (II) glamor: OpenGL accelerated X.org driver based.
[ 3180.233] (EE) modeset(0): eglInitialize() failed
[ 3180.233] (EE) modeset(0): glamor initialization failed
Further down the log:
[ 3181.703] (II) AIGLX: Screen 0 is not DRI2 capable
[ 3181.703] (EE) AIGLX: reverting to software rendering
[ 3181.731] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 3181.731] (II) AIGLX: Loaded and initialized swrast
[ 3181.731] (II) GLX: Initialized DRISWRAST GL provider for screen 0
hrm weird - dumb question, do you have the mesa-dri pkg installed?
Yes I do. Pulled in as a dependency of xorg-server actually.
Just somehow got GLX to work under modesetting
, and a few hours later under the same circumstances as the original, bam, kernel panic. No crash log this time; no other way into the system (like SSH) is available like every other kernel panic of this nature. I am sure the crash logs would be the same despite not using xf86-video-intel
this time.
Note that this is the tip of drm-next-4.10 as of this writing. I am sure drm-next is afflicted the same way.
Can you try regular drm-next? I frequently see a similar crash when using VAAPI that only affects drm-next-4.10.
I'll give it a whirl when drm-next gets resynced with -CURRENT. Haven't had a panic since my last comment, though. I can semi-reliably trigger it by rendering a video in Blender; the panic has occurred just over four hours in.
After using the workaround in #163 to allow use of i915kms at all on my machine, occasionally I will get random panics which first manifest as X and the rest of the operating system hanging for a few seconds, then an indefinite black screen. This tends to happen when I have the Intel chip under quite a bit of load, though again, this can happen at any time. I have not been able to get an automatic core dump until now.
Note that this is the tip of
drm-next-4.10
as of this writing. I am suredrm-next
is afflicted the same way.