Page MenuHomeSolus

Latest mesalib v138 update cause black screen
Closed, ResolvedPublic

Assigned To
Authored By
natri23
Apr 13 2020, 2:51 AM
Referenced Files
F5796724: Screenshot from 2020-04-13 00:18:40.png
Apr 13 2020, 4:22 AM
F5796653: Xorg.0.log.old
Apr 13 2020, 3:36 AM
F5796640: dmesg
Apr 13 2020, 3:30 AM
F5796583: IMG_20200413_093228.jpg
Apr 13 2020, 2:51 AM

Description

After updated to latest Unstable mesalib and mesalib-32bit v138-1 package, I got black screen with blinking cursors and can't login.
I was able to rollback those two packages and logged in.

dmesg included below

Machine: Dell Vostro 1450
CPU: Intel Core i7-2620M bits: 64 type: MT MCP arch: Sandy Bridge
Graphics:  Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics vendor: Dell driver: i915
   v: kernel bus ID: 00:02.0 chip ID: 8086:0126
   Display: x11 server: X.Org 1.20.7 driver: intel unloaded: fbdev,modesetting,vesa
   compositor: budgie-wm resolution: 1366x768~60Hz
   OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile v: 3.3 Mesa 19.3.4 compat-v: 3.0
   direct render: Yes

Operation #349: takeback
Date: 2020-04-13 09:33

  • mesalib is downgraded from 19.3.4-138-1-x86_64 to 19.3.4-137-1-x86_64.
  • mesalib-32bit is downgraded from 19.3.4-138-1-x86_64 to 19.3.4-137-1-x86_64.

Event Timeline

I can't imagine why...it was only a rebuild.

Yeah, not sure but I tested it twice: upgrade the only two packages and reboot to black screen with blinking cursor.

P/S: updated full dmesg

Nothing jumping out to me in dmesg. Maybe check the Xorg log?

[ 6.100] (II) Initializing extension XVideo
[ 6.100] (II) Initializing extension XVideo-MotionCompensation
[ 6.100] (II) Initializing extension GLX
[ 6.101] (EE)
[ 6.101] (EE) Backtrace:
[ 6.101] (EE) 0: /usr/lib64/xorg-server/Xorg (OsLookupColor+0x138) [0x59cfb8]
[ 6.101] (EE) 1: /usr/lib/libpthread.so.0 (funlockfile+0x60) [0x7f6c422be1ff]
[ 6.101] (EE) 2: /usr/lib64/ld-linux-x86-64.so.2 (_dl_rtld_di_serinfo+0x2a29) [0x7f6c4290ae29]
[ 6.101] (EE) 3: /usr/lib64/ld-linux-x86-64.so.2 (_dl_find_dso_for_object+0xa7e) [0x7f6c42910e2e]
[ 6.102] (EE) 4: /usr/lib/libc.so.6 (_dl_catch_exception+0x88) [0x7f6c4221aa98]
[ 6.102] (EE) 5: /usr/lib64/ld-linux-x86-64.so.2 (_dl_find_dso_for_object+0x17a) [0x7f6c4290fe6a]
[ 6.102] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 6.102] (EE) 6: /usr/lib/libdl.so.2 (?+0x0) [0x7f6c428302f0]
[ 6.102] (EE) 7: /usr/lib/libc.so.6 (_dl_catch_exception+0x88) [0x7f6c4221aa98]
[ 6.102] (EE) 8: /usr/lib/libc.so.6 (_dl_catch_error+0x33) [0x7f6c4221ab63]
[ 6.102] (EE) 9: /usr/lib/libdl.so.2 (dlerror+0x319) [0x7f6c42830e09]
[ 6.102] (EE) 10: /usr/lib/libdl.so.2 (dlopen+0x4a) [0x7f6c428303da]
[ 6.103] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 6.103] (EE) 11: /usr/lib64/xorg/modules/extensions/libglx.so (?+0x0) [0x7f6c41a94fb0]
[ 6.103] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 6.103] (EE) 12: /usr/lib64/xorg/modules/extensions/libglx.so (?+0x0) [0x7f6c41a9cd70]
[ 6.103] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 6.103] (EE) 13: /usr/lib64/xorg/modules/extensions/libglx.so (?+0x0) [0x7f6c41a93a60]
[ 6.103] (EE) 14: /usr/lib64/xorg-server/Xorg (_CallCallbacks+0x34) [0x442f44]
[ 6.103] (EE) 15: /usr/lib64/xorg-server/Xorg (dri3_send_open_reply+0x107f) [0x56d7ef]
[ 6.103] (EE) 16: /usr/lib64/xorg-server/Xorg (InitExtensions+0x89) [0x4ac959]
[ 6.103] (EE) 17: /usr/lib64/xorg-server/Xorg (InitFonts+0x1e6) [0x441a06]
[ 6.103] (EE) 18: /usr/lib/libc.so.6 (__libc_start_main+0xf3) [0x7f6c420e10d3]
[ 6.103] (EE) 19: /usr/lib64/xorg-server/Xorg (_start+0x2a) [0x42b2ba]
[ 6.103] (EE)
[ 6.103] (EE) Segmentation fault at address 0x8
[ 6.104] (EE)
Fatal server error:
[ 6.104] (EE) Caught signal 11 (Segmentation fault). Server aborting

I also noticed Segmentation Fault happened right after updated when opening some app, without the need to reboot

So, weirdly, this doesn't happen with a local build, only on the build server, afaict. More digging needed.

looks like the file /usr/lib64/dri/i915_dri.so doesn't get build on the buildserver while local everything gets build, on the buildsever log 138 it complains about a corruption and its size to big, while log 137 is everything fine.

Inside the 32bit package, everything is fine as far as I can see

The file is definitely there in 138. meld was filtering it when I did the comparison earlier. I'll look at the log for 137 again. All of the DRI libraries are larger in 138 though.

 bryan  /  tmp  mesalib-138  install  file usr/lib64/dri/i915_dri.so
usr/lib64/dri/i915_dri.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=8139585f2617a9aff9f0cb5640df4a8f02fec6dc, stripped
 bryan  /  tmp  mesalib-138  install  file /usr/lib64/dri/i915_dri.so
/usr/lib64/dri/i915_dri.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=9b30f1c86ba289751d3f392b8470f2ffb81a69dd, stripped
 bryan  /  tmp  mesalib-138  install  ldd /usr/lib64/dri/i915_dri.so
	linux-vdso.so.1 (0x00007ffe11b38000)
	libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007f6bc0114000)
	libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007f6bc00fc000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f6bc00f6000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f6bc00c9000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f6bc00b0000)
	libdrm_intel.so.1 => /usr/lib/libdrm_intel.so.1 (0x00007f6bc0087000)
	libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0x00007f6bc0074000)
	libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0x00007f6bc0069000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6bbfe67000)
	libm.so.6 => /usr/lib/haswell/libm.so.6 (0x00007f6bbfd22000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f6bbfd07000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6bbfce4000)
	libc.so.6 => /usr/lib/haswell/libc.so.6 (0x00007f6bbfaf3000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007f6bc0edd000)
	libpciaccess.so.0 => /usr/lib/libpciaccess.so.0 (0x00007f6bbfae7000)
 bryan  /  tmp  mesalib-138  install  ldd usr/lib64/dri/i915_dri.so
	statically linked

Alrighty. Good chance of corruption there.

@natri23 can I ask you to please test the latest mesalib? I think it's fixed now.

@DataDrake Confirmed! Fixed with v139. Good jobs guys...

DataDrake claimed this task.