Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-17 10:10, Andreas Beckmann wrote:
> I did dig further. An easier target for debugging is glxinfo. Which can be
> further minimized to
>
> #include
> #include
> #include
> int main()
> {
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&mutex);
> pthread_mutex_unlock(&mutex);
>
> Display * dpy ;
> dpy = XOpenDisplay ( NULL ) ;
>
> pthread_mutex_lock(&mutex);
> pthread_mutex_unlock(&mutex);
>
>int fbAttribSingle[] = {
> GLX_RENDER_TYPE, GLX_RGBA_BIT,
> GLX_RED_SIZE, 1,
> GLX_GREEN_SIZE,1,
> GLX_BLUE_SIZE, 1,
> GLX_DOUBLEBUFFER, False,
> None };
> GLXFBConfig * configs ;
> int nConfigs ;
> configs = glXChooseFBConfig ( dpy , 0 , fbAttribSingle , & nConfigs )
> ;
>
> pthread_mutex_lock(&mutex);
> pthread_mutex_unlock(&mutex);
> }
>
> (link with -lGL -lX11)
>
> that dies at some point in pthread_mutex_lock after several
> calls succeeded:
>
> (gdb) bt
> #0 0x7754b1d4 in pthread_mutex_lock (mutex=0x77001180
> ) at forward.c:192
> #1 0x76dab007 in LockDispatch () at
> ../../../src/GLdispatch/GLdispatch.c:144
> #2 __glDispatchNewVendorID () at ../../../src/GLdispatch/GLdispatch.c:198
> #3 0x7702c3c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
> #4 0x7702d1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
> #5 0x77026251 in glXChooseFBConfig () from
> /usr/lib/x86_64-linux-gnu/libGLX.so.0
> #6 0x4964 in main () at mwe.c:25
> (gdb) info shared
> FromTo Syms Read Shared Object Library
> 0x77dd9aa0 0x77df5340 Yes
> /lib64/ld-linux-x86-64.so.2
> 0x77b745d0 0x77b78c1b Yes (*)
> /usr/lib/x86_64-linux-gnu/libGL.so.1
> 0x77812da0 0x7789a434 Yes (*)
> /usr/lib/x86_64-linux-gnu/libX11.so.6
> 0x77475910 0x7759f403 Yes
> /lib/x86_64-linux-gnu/libc.so.6
> 0x77252d80 0x7725394e Yes
> /lib/x86_64-linux-gnu/libdl.so.2
> 0x77024a20 0x7702ef9d Yes (*)
> /usr/lib/x86_64-linux-gnu/libGLX.so.0
> 0x76daabb0 0x76dada37 Yes
> /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
> 0x76b4fb40 0x76b619f5 Yes (*)
> /usr/lib/x86_64-linux-gnu/libxcb.so.1
> 0x76935700 0x7693f49f Yes (*)
> /usr/lib/x86_64-linux-gnu/libXext.so.6
> 0x7672f010 0x7672fc8c Yes (*)
> /usr/lib/x86_64-linux-gnu/libXau.so.6
> 0x76529340 0x7652ac48 Yes (*)
> /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
> 0x763153d0 0x763225df Yes (*)
> /lib/x86_64-linux-gnu/libbsd.so.0
> 0x7610c0e0 0x7610eecf Yes
> /lib/x86_64-linux-gnu/librt.so.1
> 0x75ef2ab0 0x75eff811 Yes
> /lib/x86_64-linux-gnu/libpthread.so.0
> 0x75c00f00 0x75c76291 Yes (*)
> /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
> 0x759ab810 0x759ad5a3 Yes (*)
> /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82
> 0x73ed7600 0x74fbac77 Yes (*)
> /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
> 0x738d7680 0x739438da Yes
> /lib/x86_64-linux-gnu/libm.so.6
> (gdb) disassemble
> Dump of assembler code for function pthread_mutex_lock:
>0x7754b1b0 <+0>: mov0x2a957a(%rip),%eax#
> 0x777f4730 <__libc_pthread_functions_init>
>0x7754b1b6 <+6>: test %eax,%eax
>0x7754b1b8 <+8>: jne0x7754b1c0
>0x7754b1ba <+10>:xor%eax,%eax
>0x7754b1bc <+12>:retq
>0x7754b1bd <+13>:nopl (%rax)
>0x7754b1c0 <+16>:mov0x2a94c1(%rip),%rax#
> 0x777f4688 <__libc_pthread_functions+264>
>0x7754b1c7 <+23>:ror$0x11,%rax
>0x7754b1cb <+27>:xor%fs:0x30,%rax
> => 0x7754b1d4 <+36>:jmpq *%rax
>
> After finally understanding that the fs segment is used for TLS storage
> addressing, I actually saw the difference in the linked libraries:
> /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82 vs.
> /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.375.82
Oh, it's strange this library didn't show up in the ldd tests that
appear earlier in this bug report. I guess it is (indirectly) dlopened.
> From the documentation:
>
> The nvidia-tls libraries (/usr/lib/libnvidia-tls.so.384.98 and
> /usr/lib/tls/libnvidia-tls.so.384.98); these files provide thread local
> storage support for the NVIDIA OpenGL libraries (libGL, libnvidia-glcore, and
> libglx). Each nvidia-tls library provides support for a particular thread
> local storage model (such as ELF TLS), and the one appropriate for your
> system will be loaded at run time.
>
> and fr
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
I did dig further. An easier target for debugging is glxinfo. Which can be
further minimized to
#include
#include
#include
int main()
{
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&mutex);
pthread_mutex_unlock(&mutex);
Display * dpy ;
dpy = XOpenDisplay ( NULL ) ;
pthread_mutex_lock(&mutex);
pthread_mutex_unlock(&mutex);
int fbAttribSingle[] = {
GLX_RENDER_TYPE, GLX_RGBA_BIT,
GLX_RED_SIZE, 1,
GLX_GREEN_SIZE,1,
GLX_BLUE_SIZE, 1,
GLX_DOUBLEBUFFER, False,
None };
GLXFBConfig * configs ;
int nConfigs ;
configs = glXChooseFBConfig ( dpy , 0 , fbAttribSingle , & nConfigs ) ;
pthread_mutex_lock(&mutex);
pthread_mutex_unlock(&mutex);
}
(link with -lGL -lX11)
that dies at some point in pthread_mutex_lock after several
calls succeeded:
(gdb) bt
#0 0x7754b1d4 in pthread_mutex_lock (mutex=0x77001180
) at forward.c:192
#1 0x76dab007 in LockDispatch () at
../../../src/GLdispatch/GLdispatch.c:144
#2 __glDispatchNewVendorID () at ../../../src/GLdispatch/GLdispatch.c:198
#3 0x7702c3c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
#4 0x7702d1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0
#5 0x77026251 in glXChooseFBConfig () from
/usr/lib/x86_64-linux-gnu/libGLX.so.0
#6 0x4964 in main () at mwe.c:25
(gdb) info shared
>FromTo Syms Read Shared Object Library
0x77dd9aa0 0x77df5340 Yes /lib64/ld-linux-x86-64.so.2
0x77b745d0 0x77b78c1b Yes (*)
/usr/lib/x86_64-linux-gnu/libGL.so.1
0x77812da0 0x7789a434 Yes (*)
/usr/lib/x86_64-linux-gnu/libX11.so.6
0x77475910 0x7759f403 Yes
/lib/x86_64-linux-gnu/libc.so.6
0x77252d80 0x7725394e Yes
/lib/x86_64-linux-gnu/libdl.so.2
0x77024a20 0x7702ef9d Yes (*)
/usr/lib/x86_64-linux-gnu/libGLX.so.0
0x76daabb0 0x76dada37 Yes
/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
0x76b4fb40 0x76b619f5 Yes (*)
/usr/lib/x86_64-linux-gnu/libxcb.so.1
0x76935700 0x7693f49f Yes (*)
/usr/lib/x86_64-linux-gnu/libXext.so.6
0x7672f010 0x7672fc8c Yes (*)
/usr/lib/x86_64-linux-gnu/libXau.so.6
0x76529340 0x7652ac48 Yes (*)
/usr/lib/x86_64-linux-gnu/libXdmcp.so.6
0x763153d0 0x763225df Yes (*)
/lib/x86_64-linux-gnu/libbsd.so.0
0x7610c0e0 0x7610eecf Yes
/lib/x86_64-linux-gnu/librt.so.1
0x75ef2ab0 0x75eff811 Yes
/lib/x86_64-linux-gnu/libpthread.so.0
0x75c00f00 0x75c76291 Yes (*)
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
0x759ab810 0x759ad5a3 Yes (*)
/usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82
0x73ed7600 0x74fbac77 Yes (*)
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
0x738d7680 0x739438da Yes
/lib/x86_64-linux-gnu/libm.so.6
(gdb) disassemble
Dump of assembler code for function pthread_mutex_lock:
0x7754b1b0 <+0>: mov0x2a957a(%rip),%eax#
0x777f4730 <__libc_pthread_functions_init>
0x7754b1b6 <+6>: test %eax,%eax
0x7754b1b8 <+8>: jne0x7754b1c0
0x7754b1ba <+10>:xor%eax,%eax
0x7754b1bc <+12>:retq
0x7754b1bd <+13>:nopl (%rax)
0x7754b1c0 <+16>:mov0x2a94c1(%rip),%rax#
0x777f4688 <__libc_pthread_functions+264>
0x7754b1c7 <+23>:ror$0x11,%rax
0x7754b1cb <+27>:xor%fs:0x30,%rax
=> 0x7754b1d4 <+36>:jmpq *%rax
After finally understanding that the fs segment is used for TLS storage
addressing, I actually saw the difference in the linked libraries:
/usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82 vs.
/usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.375.82
>From the documentation:
The nvidia-tls libraries (/usr/lib/libnvidia-tls.so.384.98 and
/usr/lib/tls/libnvidia-tls.so.384.98); these files provide thread local storage
support for the NVIDIA OpenGL libraries (libGL, libnvidia-glcore, and libglx).
Each nvidia-tls library provides support for a particular thread local storage
model (such as ELF TLS), and the one appropriate for your system will be loaded
at run time.
and from the source code of nvidia-installer (which we don't use):
"NVIDIA's OpenGL libraries are compiled with one of two "
"different thread local storage (TLS) mechanisms: 'classic tls' "
"which is used on systems with glibc 2.2 or older, and 'new tls' "
"which is used on systems with tls-enabled glibc 2.3 or newer. "
So we probably shouldn't ship the classic ones at all and move the new
one
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Le 17 déc. 2017 05:18, "Andreas Beckmann" a écrit : Hi Aurelien, I can reproduce the problem in glxgears using nvidia driver 375.82-9~bpo9+1 and libc6 2.24-11+deb9u1 in a mostly stretch system: I ran glxgears in gdb and it died here: (gdb) bt #0 0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at genops.c:102 #1 0x76a13fa2 in _IO_new_file_init_internal (fp=fp@entry=0x557b2510) at fileops.c:151 #2 0x76a08573 in __fopen_internal (filename=0x557b2450 "/home/beckmann/.Xauthority", mode=0x73e04cb7 "rb", is32=1) at iofopen.c:82 #3 0x73e04477 in XauGetBestAuthByAddr () from /usr/lib/x86_64-linux-gnu/libXau.so.6 #4 0x74017070 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #5 0x740171ed in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #6 0x74016d1b in xcb_connect_to_display_with_auth_info () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #7 0x76f93e8a in _XConnectXCB () from /usr/lib/x86_64-linux-gnu/ libX11.so.6 #8 0x76f84bc2 in XOpenDisplay () from /usr/lib/x86_64-linux-gnu/ libX11.so.6 #9 0x63f4 in main (argc=, argv=) at glxgears.c:762 0x76a15360 <+512>: callq *%rax (gdb) print /x $rax $8 = 0xb08ebdf3733b6f74 (gdb) info shared >FromTo Syms Read Shared Object Library 0x77dd9aa0 0x77df5340 Yes /lib64/ld-linux-x86-64.so.2 0x77b8dcc0 0x77bb6100 Yes (*) /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 0x778d96d0 0x7792bb13 Yes (*) /usr/lib/x86_64-linux-gnu/libGLU.so.1 0x775e8f00 0x7765e291 Yes (*) /usr/lib/x86_64-linux-gnu/libGL.so.1 0x77297680 0x773038da Yes /lib/x86_64-linux-gnu/libm.so.6 0x76f6fda0 0x76ff7434 Yes (*) /usr/lib/x86_64-linux-gnu/libX11.so.6 0x76d43700 0x76d4d49f Yes (*) /usr/lib/x86_64-linux-gnu/libXext.so.6 0x769c0910 0x76aea403 Yes /lib/x86_64-linux-gnu/libc.so.6 0x766ae090 0x76756b69 Yes /usr/lib/x86_64-linux-gnu/libstdc++.so.6 0x7640dac0 0x7641dde5 Yes /lib/x86_64-linux-gnu/libgcc_s.so.1 0x76208810 0x7620a5a3 Yes (*) /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82 0x74734600 0x75817c77 Yes (*) /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82 0x7422fd80 0x7423094e Yes /lib/x86_64-linux-gnu/libdl.so.2 0x74012b40 0x740249f5 Yes (*) /usr/lib/x86_64-linux-gnu/libxcb.so.1 0x73e04010 0x73e04c8c Yes (*) /usr/lib/x86_64-linux-gnu/libXau.so.6 0x73bfe340 0x73bffc48 Yes (*) /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 0x739ea3d0 0x739f75df Yes (*) /lib/x86_64-linux-gnu/libbsd.so.0 0x737e10e0 0x737e3ecf Yes /lib/x86_64-linux-gnu/librt.so.1 0x735c7ab0 0x735d4811 Yes /lib/x86_64-linux-gnu/ libpthread.so.0 Since I wanted to know where that invalid pointer came from, I stopped a few instructions earlier: (gdb) break *__GI__IO_link_in+480 Breakpoint 3 at 0x76a15340: file genops.c, line 102. (gdb) disassemble Dump of assembler code for function __GI__IO_link_in: 0x76a15160 <+0>: mov(%rdi),%eax ... => 0x76a15340 <+480>: mov0x32a3a9(%rip),%rax# 0x76d3f6f0 <__libc_pthread_functions+368> 0x76a15347 <+487>: mov%rsp,%rdi 0x76a1534a <+490>: xor%edx,%edx 0x76a1534c <+492>: ror$0x11,%rax 0x76a15350 <+496>: xor%fs:0x30,%rax 0x76a15359 <+505>: lea-0x580(%rip),%rsi# 0x76a14de0 0x76a15360 <+512>: callq *%rax ... (gdb) print /x $rax $1 = 0xfbad248c (gdb) stepi 0x76a15347 102 in genops.c (gdb) print /x $rax $2 = 0xd14c4c80fe79611d (gdb) print &__libc_pthread_functions.ptr__pthread_cleanup_push_defer $3 = (void (**)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 0x76d3f6f0 <__libc_pthread_functions+368> (gdb) print __libc_pthread_functions.ptr__pthread_cleanup_push_defer $4 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 0xd14c4c80fe79611d (gdb) stepi 0x76a1534a 102 in genops.c (gdb) stepi 0x76a1534c 102 in genops.c (gdb) print /x $rax $5 = 0xd14c4c80fe79611d (gdb) stepi 0x76a15350 102 in genops.c (gdb) print /x $rax $6 = 0xb08ee8a626407f3c (gdb) stepi 0x76a15359 102 in genops.c (gdb) print /x $rax $7 = 0xb08ebdf3733b6f74 (gdb) stepi 0x76a15360 102 in genops.c (gdb) print /x $rax $8 = 0xb08ebdf3733b6f74 (gdb) stepi Program received signal SIGSEGV, Segmentation fault. 0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at genops.c:102 102 in genops.c (gdb) print &_pthread_cleanup_push_defer $9 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 0x735d1ac
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Hi Aurelien, I can reproduce the problem in glxgears using nvidia driver 375.82-9~bpo9+1 and libc6 2.24-11+deb9u1 in a mostly stretch system: I ran glxgears in gdb and it died here: (gdb) bt #0 0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at genops.c:102 #1 0x76a13fa2 in _IO_new_file_init_internal (fp=fp@entry=0x557b2510) at fileops.c:151 #2 0x76a08573 in __fopen_internal (filename=0x557b2450 "/home/beckmann/.Xauthority", mode=0x73e04cb7 "rb", is32=1) at iofopen.c:82 #3 0x73e04477 in XauGetBestAuthByAddr () from /usr/lib/x86_64-linux-gnu/libXau.so.6 #4 0x74017070 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #5 0x740171ed in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #6 0x74016d1b in xcb_connect_to_display_with_auth_info () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #7 0x76f93e8a in _XConnectXCB () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x76f84bc2 in XOpenDisplay () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x63f4 in main (argc=, argv=) at glxgears.c:762 0x76a15360 <+512>: callq *%rax (gdb) print /x $rax $8 = 0xb08ebdf3733b6f74 (gdb) info shared >FromTo Syms Read Shared Object Library 0x77dd9aa0 0x77df5340 Yes /lib64/ld-linux-x86-64.so.2 0x77b8dcc0 0x77bb6100 Yes (*) /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 0x778d96d0 0x7792bb13 Yes (*) /usr/lib/x86_64-linux-gnu/libGLU.so.1 0x775e8f00 0x7765e291 Yes (*) /usr/lib/x86_64-linux-gnu/libGL.so.1 0x77297680 0x773038da Yes /lib/x86_64-linux-gnu/libm.so.6 0x76f6fda0 0x76ff7434 Yes (*) /usr/lib/x86_64-linux-gnu/libX11.so.6 0x76d43700 0x76d4d49f Yes (*) /usr/lib/x86_64-linux-gnu/libXext.so.6 0x769c0910 0x76aea403 Yes /lib/x86_64-linux-gnu/libc.so.6 0x766ae090 0x76756b69 Yes /usr/lib/x86_64-linux-gnu/libstdc++.so.6 0x7640dac0 0x7641dde5 Yes /lib/x86_64-linux-gnu/libgcc_s.so.1 0x76208810 0x7620a5a3 Yes (*) /usr/lib/x86_64-linux-gnu/libnvidia-tls.so.375.82 0x74734600 0x75817c77 Yes (*) /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82 0x7422fd80 0x7423094e Yes /lib/x86_64-linux-gnu/libdl.so.2 0x74012b40 0x740249f5 Yes (*) /usr/lib/x86_64-linux-gnu/libxcb.so.1 0x73e04010 0x73e04c8c Yes (*) /usr/lib/x86_64-linux-gnu/libXau.so.6 0x73bfe340 0x73bffc48 Yes (*) /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 0x739ea3d0 0x739f75df Yes (*) /lib/x86_64-linux-gnu/libbsd.so.0 0x737e10e0 0x737e3ecf Yes /lib/x86_64-linux-gnu/librt.so.1 0x735c7ab0 0x735d4811 Yes /lib/x86_64-linux-gnu/libpthread.so.0 Since I wanted to know where that invalid pointer came from, I stopped a few instructions earlier: (gdb) break *__GI__IO_link_in+480 Breakpoint 3 at 0x76a15340: file genops.c, line 102. (gdb) disassemble Dump of assembler code for function __GI__IO_link_in: 0x76a15160 <+0>: mov(%rdi),%eax ... => 0x76a15340 <+480>: mov0x32a3a9(%rip),%rax# 0x76d3f6f0 <__libc_pthread_functions+368> 0x76a15347 <+487>: mov%rsp,%rdi 0x76a1534a <+490>: xor%edx,%edx 0x76a1534c <+492>: ror$0x11,%rax 0x76a15350 <+496>: xor%fs:0x30,%rax 0x76a15359 <+505>: lea-0x580(%rip),%rsi# 0x76a14de0 0x76a15360 <+512>: callq *%rax ... (gdb) print /x $rax $1 = 0xfbad248c (gdb) stepi 0x76a15347 102 in genops.c (gdb) print /x $rax $2 = 0xd14c4c80fe79611d (gdb) print &__libc_pthread_functions.ptr__pthread_cleanup_push_defer $3 = (void (**)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 0x76d3f6f0 <__libc_pthread_functions+368> (gdb) print __libc_pthread_functions.ptr__pthread_cleanup_push_defer $4 = (void (*)(struct _pthread_cleanup_buffer *, void (*)(void *), void *)) 0xd14c4c80fe79611d (gdb) stepi 0x76a1534a 102 in genops.c (gdb) stepi 0x76a1534c 102 in genops.c (gdb) print /x $rax $5 = 0xd14c4c80fe79611d (gdb) stepi 0x76a15350 102 in genops.c (gdb) print /x $rax $6 = 0xb08ee8a626407f3c (gdb) stepi 0x76a15359 102 in genops.c (gdb) print /x $rax $7 = 0xb08ebdf3733b6f74 (gdb) stepi 0x76a15360 102 in genops.c (gdb) print /x $rax $8 = 0xb08ebdf3733b6f74 (gdb) stepi Program received signal SIGSEGV, Segmentation fault. 0x76a15360 in __GI__IO_link_in (fp=fp@entry=0x557b2510) at genops.c:102 102 in genops.c (gdb) print &_pthread_cleanup_push_defer $9 = (void (*)(struct _pthread_
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-11 21:34, Luca Boccassi wrote: > BTW I've been running the packages built from 384-stretch-backports on > my desktop and I haven't encountered issues. Thanks for testing :-) I think I'll wait until 384 is in testing for a good week and update stretch-backports to 384 thereafter, unless some new issues show up. Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote: > On 2017-12-06 10:53, Julien Aubin wrote: > > Okay I will try it. Could you please provide me the build guide and > > install > > guide ? > > From README.source: > > Building "bleeding edge" from SVN for users > > As new upstream versions of the proprietary driver are released, > upload > might not happen immediately. This might be for various reasons, > including > waiting for new binary packages to clear the NEW queue. > Users wishing to try to build new version locally can follow the > instructions on the Debian wiki: > > https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele > ases_from_SVN > > WARNING: these will most likely be work in progress, and the > final upload > may be different and may not support clean upgrades from/to the > versions > uploaded in the archive. > > > In your case, it is branches/384-stretch-backports. > > Please let us know about any issues you encounter with these > instructions. > > > Andreas BTW I've been running the packages built from 384-stretch-backports on my desktop and I haven't encountered issues. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
2017-12-07 22:11 GMT+01:00 Aurelien Jarno : > On 2017-12-07 18:33, Julien Aubin wrote: > > Hi, > > > > Ldd with file /etc/ld.so.nohwcap : > > julien@pccorei7-4770:~$ ldd $(which glxgears) > >linux-vdso.so.1 (0x7ffcc49c5000) > >libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 > > (0x7f9327cc6000) > >libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 > > (0x7f9327a57000) > >libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 > > (0x7f93277b3000) > >libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f93274af000) > >libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 > > (0x7f932716f000) > >libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 > > (0x7f9326f5d000) > >libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9326bbe000) > >libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > (0x7f932683c000) > >libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > > (0x7f9326625000) > >libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > (0x7f9326421000) > >libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 > > (0x7f93261f1000) > >libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/ > libGLdispatch.so.0 > > (0x7f9325f23000) > >/lib64/ld-linux-x86-64.so.2 (0x7f9328161000) > >libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 > > (0x7f9325cfb000) > >libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > > (0x7f9325af7000) > >libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > > (0x7f93258f1000) > >libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 > > (0x7f93256db000) > >librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > (0x7f93254d3000) > >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > > (0x7f93252b6000) > > > > Ldd without file /etc/ld.so.nohwcap : > > julien@pccorei7-4770:~$ ldd $(which glxgears) > >linux-vdso.so.1 (0x7ffce55b) > >libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 > > (0x7f90c7a69000) > >libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 > > (0x7f90c77fa000) > >libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 > > (0x7f90c7556000) > >libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f90c7252000) > >libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 > > (0x7f90c6f12000) > >libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 > > (0x7f90c6d0) > >libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f90c6961000) > >libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > > (0x7f90c65df000) > >libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > > (0x7f90c63c8000) > >libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 > (0x7f90c61c4000) > >libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 > > (0x7f90c5f94000) > >libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/ > libGLdispatch.so.0 > > (0x7f90c5cc6000) > >/lib64/ld-linux-x86-64.so.2 (0x7f90c7f04000) > >libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 > > (0x7f90c5a9e000) > >libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > > (0x7f90c589a000) > >libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > > (0x7f90c5694000) > >libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 > > (0x7f90c547e000) > >librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 > (0x7f90c5276000) > >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > > (0x7f90c5059000) > > > > I remark the addresses of libraries are not the same but it is probably > due > > to ASLR. > > It's normal that the addresses are not the same, that said, I was > expecting the path to be different. The only thing that > /etc/ld.so.nohwcap is supposed to change the libraries that are loaded. > That said, there is are path for optimized libraries on amd64, so I am > not really surprised. I still don't understand the bug... > @Andreas and/or Luca : could you please try as well the same thing as I did, I mean : 1/ Create file /etc/ld.so.nohwcap 2/ Launch glxgears 3/ Remove the file 4/ Launch glxgears And then communicate the results ? > > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-07 18:33, Julien Aubin wrote: > Hi, > > Ldd with file /etc/ld.so.nohwcap : > julien@pccorei7-4770:~$ ldd $(which glxgears) >linux-vdso.so.1 (0x7ffcc49c5000) >libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 > (0x7f9327cc6000) >libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 > (0x7f9327a57000) >libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 > (0x7f93277b3000) >libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f93274af000) >libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 > (0x7f932716f000) >libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 > (0x7f9326f5d000) >libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9326bbe000) >libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f932683c000) >libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f9326625000) >libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9326421000) >libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 > (0x7f93261f1000) >libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 > (0x7f9325f23000) >/lib64/ld-linux-x86-64.so.2 (0x7f9328161000) >libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 > (0x7f9325cfb000) >libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > (0x7f9325af7000) >libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > (0x7f93258f1000) >libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 > (0x7f93256db000) >librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f93254d3000) >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f93252b6000) > > Ldd without file /etc/ld.so.nohwcap : > julien@pccorei7-4770:~$ ldd $(which glxgears) >linux-vdso.so.1 (0x7ffce55b) >libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 > (0x7f90c7a69000) >libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 > (0x7f90c77fa000) >libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 > (0x7f90c7556000) >libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f90c7252000) >libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 > (0x7f90c6f12000) >libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 > (0x7f90c6d0) >libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f90c6961000) >libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 > (0x7f90c65df000) >libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f90c63c8000) >libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f90c61c4000) >libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 > (0x7f90c5f94000) >libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 > (0x7f90c5cc6000) >/lib64/ld-linux-x86-64.so.2 (0x7f90c7f04000) >libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 > (0x7f90c5a9e000) >libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 > (0x7f90c589a000) >libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 > (0x7f90c5694000) >libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 > (0x7f90c547e000) >librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f90c5276000) >libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f90c5059000) > > I remark the addresses of libraries are not the same but it is probably due > to ASLR. It's normal that the addresses are not the same, that said, I was expecting the path to be different. The only thing that /etc/ld.so.nohwcap is supposed to change the libraries that are loaded. That said, there is are path for optimized libraries on amd64, so I am not really surprised. I still don't understand the bug... Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Hi, Ldd with file /etc/ld.so.nohwcap : julien@pccorei7-4770:~$ ldd $(which glxgears) linux-vdso.so.1 (0x7ffcc49c5000) libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 (0x7f9327cc6000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x7f9327a57000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f93277b3000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f93274af000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f932716f000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f9326f5d000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9326bbe000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f932683c000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f9326625000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9326421000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f93261f1000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x7f9325f23000) /lib64/ld-linux-x86-64.so.2 (0x7f9328161000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f9325cfb000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f9325af7000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f93258f1000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f93256db000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f93254d3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f93252b6000) Ldd without file /etc/ld.so.nohwcap : julien@pccorei7-4770:~$ ldd $(which glxgears) linux-vdso.so.1 (0x7ffce55b) libGLEW.so.2.0 => /usr/lib/x86_64-linux-gnu/libGLEW.so.2.0 (0x7f90c7a69000) libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x7f90c77fa000) libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x7f90c7556000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f90c7252000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f90c6f12000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f90c6d0) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f90c6961000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f90c65df000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f90c63c8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f90c61c4000) libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x7f90c5f94000) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x7f90c5cc6000) /lib64/ld-linux-x86-64.so.2 (0x7f90c7f04000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f90c5a9e000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f90c589a000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7f90c5694000) libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x7f90c547e000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f90c5276000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f90c5059000) I remark the addresses of libraries are not the same but it is probably due to ASLR. Another thing I was thinking of : if the issue is related to code paths, maybe we should try on some other CPUs w/ the NVidia blob, because it might be a Haswell hardware bug. What do you think of this ? We should try on some Intel non-Haswell CPU w/ and w/o the file. Rgds, 2017-12-07 10:06 GMT+01:00 Aurelien Jarno : > control: reopen -1 > control: tag -1 - unreproducible > control: retitle -1 nvidia-driver: crashes with /etc/ld.so.nohwcap > > On 2017-12-07 05:43, Julien Aubin wrote: > > 2017-12-06 21:50 GMT+01:00 Aurelien Jarno : > > > > > On 2017-12-06 19:39, Julien Aubin wrote: > > > > Weird... this time I re-upgraded libc6 and things work fine... looks > like > > > > something wrong went during the install. And I cannot reproduce the > issue > > > > anymore... :'( WTF ??? > > > > > > Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which > in > > > some conditions leave the /etc/ld.so.nohwcap file instead of removing > it > > > just after the upgrade (see bug#883394). One of the condition is to > have > > > libc6-i686 installed (while it can be safely removed), which seems to > be > > > your case. > > > > > > I consider this bug harmless as it should not deactivate anything now > > > that the default libc is already i686 optimized. Also I don't see how > it > > > could trigger the issue you described. Anyway better be safe than > sorry, > > > could you please try to create this file with "touch > /etc/ld.so.nohwcap" > > > as root and see if it makes the issue to reappear? Once the test is > done > > > you can then remove it. > > > > > > Thanks, > > > Aurelien > > > > > > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
control: reopen -1 control: tag -1 - unreproducible control: retitle -1 nvidia-driver: crashes with /etc/ld.so.nohwcap On 2017-12-07 05:43, Julien Aubin wrote: > 2017-12-06 21:50 GMT+01:00 Aurelien Jarno : > > > On 2017-12-06 19:39, Julien Aubin wrote: > > > Weird... this time I re-upgraded libc6 and things work fine... looks like > > > something wrong went during the install. And I cannot reproduce the issue > > > anymore... :'( WTF ??? > > > > Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in > > some conditions leave the /etc/ld.so.nohwcap file instead of removing it > > just after the upgrade (see bug#883394). One of the condition is to have > > libc6-i686 installed (while it can be safely removed), which seems to be > > your case. > > > > I consider this bug harmless as it should not deactivate anything now > > that the default libc is already i686 optimized. Also I don't see how it > > could trigger the issue you described. Anyway better be safe than sorry, > > could you please try to create this file with "touch /etc/ld.so.nohwcap" > > as root and see if it makes the issue to reappear? Once the test is done > > you can then remove it. > > > > Thanks, > > Aurelien > > > > > Bingo ! It was exactly this ! > > If I re-create the file for example it crashes glxgears. When I remove it > glxgears works fine. > > With GDB, the stack trace for when I run glxgears : > > 0 0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at > forward.c:192 > #1 0x75de1308 in __glDispatchNewVendorID () from > /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 > #2 0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #3 0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #4 0x76073170 in glXChooseVisual () from > /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #5 0x779f in ?? () > #6 0x5ae7 in ?? () > #7 0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1, > argv=0x7fffe638, init=, >fini=, rtld_fini=, > stack_end=0x7fffe628) at ../csu/libc-start.c:291 > #8 0x646a in ?? () > The libc6 package version 2.24-11+deb9u2 won't be in the next point release so this issue won't trigger. That said there is clearly an issue on the nvidia package, it should behave the same with and without /etc/ld.so.nohwcap. I am therefore reopening this bug. One of the first step to debug this issue would be to run ldd /usr/bin/glxgears with and without /etc/ld.so.nohwcap and compare the difference. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#883705: Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
control: reopen 883705 control: forcemerge 883705 883394 control: retitle 883705 libc6: keep /etc/ld.so.nohwcap after upgrade, breaking Nvidia GLX On 2017-12-07 05:43, Julien Aubin wrote: > 2017-12-06 21:50 GMT+01:00 Aurelien Jarno : > > > On 2017-12-06 19:39, Julien Aubin wrote: > > > Weird... this time I re-upgraded libc6 and things work fine... looks like > > > something wrong went during the install. And I cannot reproduce the issue > > > anymore... :'( WTF ??? > > > > Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in > > some conditions leave the /etc/ld.so.nohwcap file instead of removing it > > just after the upgrade (see bug#883394). One of the condition is to have > > libc6-i686 installed (while it can be safely removed), which seems to be > > your case. > > > > I consider this bug harmless as it should not deactivate anything now > > that the default libc is already i686 optimized. Also I don't see how it > > could trigger the issue you described. Anyway better be safe than sorry, > > could you please try to create this file with "touch /etc/ld.so.nohwcap" > > as root and see if it makes the issue to reappear? Once the test is done > > you can then remove it. > > > > Thanks, > > Aurelien > > > > > Bingo ! It was exactly this ! > > If I re-create the file for example it crashes glxgears. When I remove it > glxgears works fine. > > With GDB, the stack trace for when I run glxgears : > > 0 0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at > forward.c:192 > #1 0x75de1308 in __glDispatchNewVendorID () from > /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 > #2 0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #3 0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #4 0x76073170 in glXChooseVisual () from > /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #5 0x779f in ?? () > #6 0x5ae7 in ?? () > #7 0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1, > argv=0x7fffe638, init=, >fini=, rtld_fini=, > stack_end=0x7fffe628) at ../csu/libc-start.c:291 > #8 0x646a in ?? () I don't fully get the issue given that with /etc/ld.so.nohwcap the system should use less optimized libraries, given that such libraries does not exist on amd64 and have been removed on i386. To try to understand the issue, could you please run the command "ldd /usr/bin/glxgears" with and without /etc/ld.so.nohwcap and send me the output? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
2017-12-07 5:43 GMT+01:00 Julien Aubin : > > 2017-12-06 21:50 GMT+01:00 Aurelien Jarno : > >> On 2017-12-06 19:39, Julien Aubin wrote: >> > Weird... this time I re-upgraded libc6 and things work fine... looks >> like >> > something wrong went during the install. And I cannot reproduce the >> issue >> > anymore... :'( WTF ??? >> >> Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in >> some conditions leave the /etc/ld.so.nohwcap file instead of removing it >> just after the upgrade (see bug#883394). One of the condition is to have >> libc6-i686 installed (while it can be safely removed), which seems to be >> your case. >> >> I consider this bug harmless as it should not deactivate anything now >> that the default libc is already i686 optimized. Also I don't see how it >> could trigger the issue you described. Anyway better be safe than sorry, >> could you please try to create this file with "touch /etc/ld.so.nohwcap" >> as root and see if it makes the issue to reappear? Once the test is done >> you can then remove it. >> >> Thanks, >> Aurelien >> > > > Bingo ! It was exactly this ! > > If I re-create the file for example it crashes glxgears. When I remove it > glxgears works fine. > > With GDB, the stack trace for when I run glxgears : > > 0 0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at > forward.c:192 > #1 0x75de1308 in __glDispatchNewVendorID () from > /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 > #2 0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > > #3 0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 > > #4 0x76073170 in glXChooseVisual () from > /usr/lib/x86_64-linux-gnu/libGLX.so.0 > #5 0x779f in ?? () > #6 0x5ae7 in ?? () > #7 0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1, > argv=0x7fffe638, init=, >fini=, rtld_fini=, > stack_end=0x7fffe628) at ../csu/libc-start.c:291 > #8 0x646a in ?? () > > > To be clear it looks like this file also affects libc6-amd64 behaviour... > >> -- >> Aurelien Jarno GPG: 4096R/1DDD8C9B >> aurel...@aurel32.net http://www.aurel32.net >> > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
2017-12-06 21:50 GMT+01:00 Aurelien Jarno : > On 2017-12-06 19:39, Julien Aubin wrote: > > Weird... this time I re-upgraded libc6 and things work fine... looks like > > something wrong went during the install. And I cannot reproduce the issue > > anymore... :'( WTF ??? > > Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in > some conditions leave the /etc/ld.so.nohwcap file instead of removing it > just after the upgrade (see bug#883394). One of the condition is to have > libc6-i686 installed (while it can be safely removed), which seems to be > your case. > > I consider this bug harmless as it should not deactivate anything now > that the default libc is already i686 optimized. Also I don't see how it > could trigger the issue you described. Anyway better be safe than sorry, > could you please try to create this file with "touch /etc/ld.so.nohwcap" > as root and see if it makes the issue to reappear? Once the test is done > you can then remove it. > > Thanks, > Aurelien > Bingo ! It was exactly this ! If I re-create the file for example it crashes glxgears. When I remove it glxgears works fine. With GDB, the stack trace for when I run glxgears : 0 0x76b311a4 in pthread_mutex_lock (mutex=0x7604e8c0) at forward.c:192 #1 0x75de1308 in __glDispatchNewVendorID () from /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 #2 0x760793c2 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 #3 0x7607a1ac in ?? () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 #4 0x76073170 in glXChooseVisual () from /usr/lib/x86_64-linux-gnu/libGLX.so.0 #5 0x779f in ?? () #6 0x5ae7 in ?? () #7 0x76a5c2e1 in __libc_start_main (main=0x5970, argc=1, argv=0x7fffe638, init=, fini=, rtld_fini=, stack_end=0x7fffe628) at ../csu/libc-start.c:291 #8 0x646a in ?? () > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-06 19:39, Julien Aubin wrote: > Weird... this time I re-upgraded libc6 and things work fine... looks like > something wrong went during the install. And I cannot reproduce the issue > anymore... :'( WTF ??? Hmm, a bug has been introduced in libc6 version 2.24-11+deb9u2, which in some conditions leave the /etc/ld.so.nohwcap file instead of removing it just after the upgrade (see bug#883394). One of the condition is to have libc6-i686 installed (while it can be safely removed), which seems to be your case. I consider this bug harmless as it should not deactivate anything now that the default libc is already i686 optimized. Also I don't see how it could trigger the issue you described. Anyway better be safe than sorry, could you please try to create this file with "touch /etc/ld.so.nohwcap" as root and see if it makes the issue to reappear? Once the test is done you can then remove it. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Thanks a lot and sorry for the inconvenience. 2017-12-06 19:45 GMT+01:00 Andreas Beckmann : > Control: tag -1 unreproducible > Control: close -1 > > On 2017-12-06 19:39, Julien Aubin wrote: > > Weird... this time I re-upgraded libc6 and things work fine... looks like > > something wrong went during the install. And I cannot reproduce the issue > > anymore... :'( WTF ??? > > OK, I'm closing the two bugs as unreproducible. > > > Andreas >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Control: tag -1 unreproducible Control: close -1 On 2017-12-06 19:39, Julien Aubin wrote: > Weird... this time I re-upgraded libc6 and things work fine... looks like > something wrong went during the install. And I cannot reproduce the issue > anymore... :'( WTF ??? OK, I'm closing the two bugs as unreproducible. Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Weird... this time I re-upgraded libc6 and things work fine... looks like something wrong went during the install. And I cannot reproduce the issue anymore... :'( WTF ??? 2017-12-06 19:24 GMT+01:00 Andreas Beckmann : > Please install the -dbg/-dbgsym packages for all packages involved in > the backtrace, this should give a bit more information. > > That would probably include xserver-xorg-core-dbgsym (you will have to > enable the debian-debug package source for that, see > https://wiki.debian.org/HowToGetABacktrace) and libc6-dbg. > > > Andreas >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Try to build and run this program, it could be a reproducer for your
problem:
#include
#include
int main()
{
const char *s = "001 GLX";
char *p;
long int l = strtol(s, &p, 10);
long long ll = strtoll(s, &p, 10);
printf("%ld %lld\n", l, ll);
}
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Hi, 2017-12-06 19:18 GMT+01:00 Andreas Beckmann : > On 2017-12-06 18:39, Julien Aubin wrote: > > Raised issue #883705 as it is actually a libc6 regression (it may affect > > other apps actually). > > I tried to set a title for that bug (it had none), but maybe you can > describe it even better? > The title I've set is : libc6: 2.24-11+deb9u2 breaks Nvidia's GLX X module on Pascal GPU https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883705 > > Just to verify: if you downgrade libc6 to 2.24-11+deb9u1 everything is > working properly again? > Yup I confirm that if you downgrade all is working properly again. > > My guess is that it is not related to the nvidia driver at all (except > for utilizing a certain code path in glibc), but to your CPU and the > optimized glibc routines used for it ... > > So try touching the file /etc/ld.so.nohwcap - hopefully glibc will stop > using any optimized code for your cpu. If this works (and the glx module > works agian afterwards), we are moving into the right direction. > I guess the same, some optimization introduced in the makefile which triggers a different compilation path. > > > Andreas >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-06 18:39, Julien Aubin wrote: > Raised issue #883705 as it is actually a libc6 regression (it may affect > other apps actually). I tried to set a title for that bug (it had none), but maybe you can describe it even better? Just to verify: if you downgrade libc6 to 2.24-11+deb9u1 everything is working properly again? My guess is that it is not related to the nvidia driver at all (except for utilizing a certain code path in glibc), but to your CPU and the optimized glibc routines used for it ... So try touching the file /etc/ld.so.nohwcap - hopefully glibc will stop using any optimized code for your cpu. If this works (and the glx module works agian afterwards), we are moving into the right direction. Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Please install the -dbg/-dbgsym packages for all packages involved in the backtrace, this should give a bit more information. That would probably include xserver-xorg-core-dbgsym (you will have to enable the debian-debug package source for that, see https://wiki.debian.org/HowToGetABacktrace) and libc6-dbg. Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Raised issue #883705 as it is actually a libc6 regression (it may affect other apps actually). I think you can close this one if you wish. 2017-12-06 18:11 GMT+01:00 Julien Aubin : > Okay found the culprit : libc6 > > Issue appears with the one from 9.3 but not 9.2 > > 2017-12-06 11:56 GMT+01:00 Julien Aubin : > >> >> >> Le 6 déc. 2017 11:51, "Luca Boccassi" a écrit : >> >> On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote: >> > On 2017-12-06 10:53, Julien Aubin wrote: >> > > Okay I will try it. Could you please provide me the build guide and >> > > install >> > > guide ? >> > >> > From README.source: >> > >> > Building "bleeding edge" from SVN for users >> > >> > As new upstream versions of the proprietary driver are released, >> > upload >> > might not happen immediately. This might be for various reasons, >> > including >> > waiting for new binary packages to clear the NEW queue. >> > Users wishing to try to build new version locally can follow the >> > instructions on the Debian wiki: >> > >> > https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele >> > ases_from_SVN >> > >> > WARNING: these will most likely be work in progress, and the >> > final upload >> > may be different and may not support clean upgrades from/to the >> > versions >> > uploaded in the archive. >> > >> > >> > In your case, it is branches/384-stretch-backports. >> > >> > Please let us know about any issues you encounter with these >> > instructions. >> > >> > >> > Andreas >> >> 375.82 has been in sid/buster for months now, it's very strange that it >> wasn't reported before - a GLX crash is not a subtle problem that might >> get overlooked >> >> >> Yup but not sure people use a Pascal GPU. What is granted is that the >> issue appeared after last update to stretch-proposed-updates, but only on >> my box with a Pascal GPU. >> >> I suspect the code paths used are not the same per GPU... >> >> If you wish I can send you my sources.list, my /etc and the list of >> installed packages. I do not have weird things, only additional repos for >> marginal packages like deb-multimedia or virtualbox. >> >> >> -- >> Kind regards, >> Luca Boccassi >> >> >> >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Okay found the culprit : libc6 Issue appears with the one from 9.3 but not 9.2 2017-12-06 11:56 GMT+01:00 Julien Aubin : > > > Le 6 déc. 2017 11:51, "Luca Boccassi" a écrit : > > On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote: > > On 2017-12-06 10:53, Julien Aubin wrote: > > > Okay I will try it. Could you please provide me the build guide and > > > install > > > guide ? > > > > From README.source: > > > > Building "bleeding edge" from SVN for users > > > > As new upstream versions of the proprietary driver are released, > > upload > > might not happen immediately. This might be for various reasons, > > including > > waiting for new binary packages to clear the NEW queue. > > Users wishing to try to build new version locally can follow the > > instructions on the Debian wiki: > > > > https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele > > ases_from_SVN > > > > WARNING: these will most likely be work in progress, and the > > final upload > > may be different and may not support clean upgrades from/to the > > versions > > uploaded in the archive. > > > > > > In your case, it is branches/384-stretch-backports. > > > > Please let us know about any issues you encounter with these > > instructions. > > > > > > Andreas > > 375.82 has been in sid/buster for months now, it's very strange that it > wasn't reported before - a GLX crash is not a subtle problem that might > get overlooked > > > Yup but not sure people use a Pascal GPU. What is granted is that the > issue appeared after last update to stretch-proposed-updates, but only on > my box with a Pascal GPU. > > I suspect the code paths used are not the same per GPU... > > If you wish I can send you my sources.list, my /etc and the list of > installed packages. I do not have weird things, only additional repos for > marginal packages like deb-multimedia or virtualbox. > > > -- > Kind regards, > Luca Boccassi > > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Le 6 déc. 2017 11:51, "Luca Boccassi" a écrit : On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote: > On 2017-12-06 10:53, Julien Aubin wrote: > > Okay I will try it. Could you please provide me the build guide and > > install > > guide ? > > From README.source: > > Building "bleeding edge" from SVN for users > > As new upstream versions of the proprietary driver are released, > upload > might not happen immediately. This might be for various reasons, > including > waiting for new binary packages to clear the NEW queue. > Users wishing to try to build new version locally can follow the > instructions on the Debian wiki: > > https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele > ases_from_SVN > > WARNING: these will most likely be work in progress, and the > final upload > may be different and may not support clean upgrades from/to the > versions > uploaded in the archive. > > > In your case, it is branches/384-stretch-backports. > > Please let us know about any issues you encounter with these > instructions. > > > Andreas 375.82 has been in sid/buster for months now, it's very strange that it wasn't reported before - a GLX crash is not a subtle problem that might get overlooked Yup but not sure people use a Pascal GPU. What is granted is that the issue appeared after last update to stretch-proposed-updates, but only on my box with a Pascal GPU. I suspect the code paths used are not the same per GPU... If you wish I can send you my sources.list, my /etc and the list of installed packages. I do not have weird things, only additional repos for marginal packages like deb-multimedia or virtualbox. -- Kind regards, Luca Boccassi
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On Wed, 2017-12-06 at 11:37 +0100, Andreas Beckmann wrote: > On 2017-12-06 10:53, Julien Aubin wrote: > > Okay I will try it. Could you please provide me the build guide and > > install > > guide ? > > From README.source: > > Building "bleeding edge" from SVN for users > > As new upstream versions of the proprietary driver are released, > upload > might not happen immediately. This might be for various reasons, > including > waiting for new binary packages to clear the NEW queue. > Users wishing to try to build new version locally can follow the > instructions on the Debian wiki: > > https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_rele > ases_from_SVN > > WARNING: these will most likely be work in progress, and the > final upload > may be different and may not support clean upgrades from/to the > versions > uploaded in the archive. > > > In your case, it is branches/384-stretch-backports. > > Please let us know about any issues you encounter with these > instructions. > > > Andreas 375.82 has been in sid/buster for months now, it's very strange that it wasn't reported before - a GLX crash is not a subtle problem that might get overlooked -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-06 10:53, Julien Aubin wrote: > Okay I will try it. Could you please provide me the build guide and install > guide ? >From README.source: Building "bleeding edge" from SVN for users As new upstream versions of the proprietary driver are released, upload might not happen immediately. This might be for various reasons, including waiting for new binary packages to clear the NEW queue. Users wishing to try to build new version locally can follow the instructions on the Debian wiki: https://wiki.debian.org/NvidiaGraphicsDrivers#Building_newer_releases_from_SVN WARNING: these will most likely be work in progress, and the final upload may be different and may not support clean upgrades from/to the versions uploaded in the archive. In your case, it is branches/384-stretch-backports. Please let us know about any issues you encounter with these instructions. Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Okay I will try it. Could you please provide me the build guide and install guide ? I've also seen that the crash actually occurs in libc6 in strtol_l.c. I will try to downgrade it. I keep you informed for the both options. Le 6 déc. 2017 10:50, "Andreas Beckmann" a écrit : On 2017-12-05 22:23, Julien Aubin wrote: > To help debugging, could you provide me please some link to a newer NVidia > driver release built for stretch please (and some notice to install it) ? Can you build the packages from SVN? I've prepared a (completely untested) backport for stretch in branches/384-stretch-backports Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On 2017-12-05 22:23, Julien Aubin wrote: > To help debugging, could you provide me please some link to a newer NVidia > driver release built for stretch please (and some notice to install it) ? Can you build the packages from SVN? I've prepared a (completely untested) backport for stretch in branches/384-stretch-backports Andreas
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Le 6 déc. 2017 07:24, "Julien Aubin" a écrit : 2017-12-06 7:07 GMT+01:00 Julien Aubin : > > > 2017-12-06 3:34 GMT+01:00 Julien Aubin : > >> >> >> Le 5 déc. 2017 23:08, "Luca Boccassi" a écrit : >> >> On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote: >> > To help debugging, could you provide me please some link to a newer >> > NVidia >> > driver release built for stretch please (and some notice to install >> > it) ? >> >> Unfortunately I don't think we have anything that can be used in >> Stretch - IIRC both 384 and 387 dependencies are structured for the >> glvnd transition, so they can't be installed on Stretch. >> >> > Thus : >> > - If I disable from a custom xorg.conf file module glx everything >> > loads >> > fine (as long as I use lightdm as a login manager) >> > >> > Thanks a lot. >> >> Could you clarify what this means? You are manually blacklisting glx? >> >> >> > The fact driver 38x cannot be installed on Stretch is very bad as it > prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia > MX1** are already impacted. > > FYI here's what I get in kern.log when enabling glx in xorg : > > ec 6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:39 pccorei7-4770 kernel: [ 3917.300914] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-124
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
2017-12-06 7:07 GMT+01:00 Julien Aubin : > > > 2017-12-06 3:34 GMT+01:00 Julien Aubin : > >> >> >> Le 5 déc. 2017 23:08, "Luca Boccassi" a écrit : >> >> On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote: >> > To help debugging, could you provide me please some link to a newer >> > NVidia >> > driver release built for stretch please (and some notice to install >> > it) ? >> >> Unfortunately I don't think we have anything that can be used in >> Stretch - IIRC both 384 and 387 dependencies are structured for the >> glvnd transition, so they can't be installed on Stretch. >> >> > Thus : >> > - If I disable from a custom xorg.conf file module glx everything >> > loads >> > fine (as long as I use lightdm as a login manager) >> > >> > Thanks a lot. >> >> Could you clarify what this means? You are manually blacklisting glx? >> >> >> > The fact driver 38x cannot be installed on Stretch is very bad as it > prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia > MX1** are already impacted. > > FYI here's what I get in kern.log when enabling glx in xorg : > > ec 6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed > GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > Dec 6 07:03:39 pccorei7-4770 kernel: [ 3917.300914] nvidia-modeset: > Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ > PCI::01:00.0 > Dec 6 07:03
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
2017-12-06 3:34 GMT+01:00 Julien Aubin : > > > Le 5 déc. 2017 23:08, "Luca Boccassi" a écrit : > > On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote: > > To help debugging, could you provide me please some link to a newer > > NVidia > > driver release built for stretch please (and some notice to install > > it) ? > > Unfortunately I don't think we have anything that can be used in > Stretch - IIRC both 384 and 387 dependencies are structured for the > glvnd transition, so they can't be installed on Stretch. > > > Thus : > > - If I disable from a custom xorg.conf file module glx everything > > loads > > fine (as long as I use lightdm as a login manager) > > > > Thanks a lot. > > Could you clarify what this means? You are manually blacklisting glx? > > > The fact driver 38x cannot be installed on Stretch is very bad as it prevents newer GPUs from working w/ Debian stable. Newer low-end NVidia MX1** are already impacted. FYI here's what I get in kern.log when enabling glx in xorg : ec 6 06:59:44 pccorei7-4770 kernel: [ 3682.820990] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.431679] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:53 pccorei7-4770 kernel: [ 3691.753169] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.545921] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:54 pccorei7-4770 kernel: [ 3692.866820] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.542921] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:55 pccorei7-4770 kernel: [ 3693.864460] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.539028] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:56 pccorei7-4770 kernel: [ 3694.860824] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.536803] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 06:59:57 pccorei7-4770 kernel: [ 3695.876240] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.365928] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:55 pccorei7-4770 kernel: [ 3873.706339] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.563884] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:56 pccorei7-4770 kernel: [ 3874.885761] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.562088] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:57 pccorei7-4770 kernel: [ 3875.901835] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:58 pccorei7-4770 kernel: [ 3876.809216] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:58 pccorei7-4770 kernel: [ 3877.130778] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:59 pccorei7-4770 kernel: [ 3877.807965] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:02:59 pccorei7-4770 kernel: [ 3878.144767] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.290650] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:37 pccorei7-4770 kernel: [ 3915.611177] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.320719] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:38 pccorei7-4770 kernel: [ 3916.641984] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:39 pccorei7-4770 kernel: [ 3917.300914] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:39 pccorei7-4770 kernel: [ 3917.621818] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Dec 6 07:03:40 pccorei7-4770 kernel: [ 3918.315331] nvidia-modeset: Allocated GPU:0
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Le 5 déc. 2017 23:08, "Luca Boccassi" a écrit : On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote: > To help debugging, could you provide me please some link to a newer > NVidia > driver release built for stretch please (and some notice to install > it) ? Unfortunately I don't think we have anything that can be used in Stretch - IIRC both 384 and 387 dependencies are structured for the glvnd transition, so they can't be installed on Stretch. > Thus : > - If I disable from a custom xorg.conf file module glx everything > loads > fine (as long as I use lightdm as a login manager) > > Thanks a lot. Could you clarify what this means? You are manually blacklisting glx? Hi Yes I used nvidia-xconfig to generate an xorg.conf file and in it I disabled the glx module > 2017-12-05 22:14 GMT+01:00 Julien Aubin : > > > GLX crashes here : > > > > #0 0x7588ad01 in __GI_strtol_l_internal > > (nptr=0x7fffe2b1 > > "001 GLX", endptr=0x7fffe2a8, base=10, group=, > > loc=0x55ad3620) at ../stdlib/strtol_l.c:293 > > #1 0x555cd0cb in ?? () > > #2 0x555bbeb0 in AddExtension () > > #3 0x7381d7b2 in ?? () from > > /usr/lib/xorg/modules/linux/libglx.so > > > > #4 0x555bc040 in ?? () > > #5 0x001d in ?? () > > #6 0x0200 in ?? () > > #7 0x in ?? () > > > > > > 2017-12-05 21:47 GMT+01:00 Julien Aubin : > > > > > Hi, > > > > > > I reinstalled NVidia driver several times and the problem is > > > still the > > > same. Trying your method still results in the same issue. > > > > > > Now if I fully blacklist the nvidia driver I get a "better" black > > > screen > > > w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log > > > does not > > > hang on the GLX stuff. > > > > > > Looks like this issue targets GeForce 10xx GPUs (as my 970 does > > > seem > > > unaffected as well). > > > > > > Rgds > > > > > > > > > > > > 2017-12-05 21:13 GMT+01:00 Luca Boccassi : > > > > > > > On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: > > > > > Looks like the culprit is NVidia modeset. Thus the issue does > > > > > not > > > > > happen w/ > > > > > a Maxwell GPU. > > > > > > > > > > [ 542.167979] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > > > > > > > > > > > [ 542.490521] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 544.081034] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 544.385426] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 546.079744] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 546.399641] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 548.091421] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 548.395724] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 550.088731] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 550.392898] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > > > > Didn't see any issue with my 780 (Kepler?). > > > > > > > > Are you sure the kernel modules is correctly rebuilt? I've seen > > > > that > > > > there was a kernel point release, and not all ABI changes are > > > > reverted. > > > > Which means DKMS won't rebuild the modules automatically. > > > > > > > > Try to remove it and rebuild it with: > > > > > > > > sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 > > > > sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 > > > > > 2017-12-05 20:51 GMT+01:00 Julien Aubin > > > > om>: > > > > > > > > > > > Driver hangs just here : > > > > > > ---> > > > > > > [32.680] (II) Initializing extension GLX > > > > > > [32.680] (II) Indirect GLX disabled. > > > > > > > > > > > > > > > > > > > Normally I should get then [34.659] (II) config/udev: > > > > > > Adding > > > > > > input > > > > > > device Power Button (/dev/input/event5) > > > > > > > > > > > > But here it crashes without log. > > > > > > > > > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < > > > > > > ow...@bugs.debian.org>: > > > > > > > > > > > > > Thank you for filing a new Bug report with Debian. > > > > > > > > > > > > > > You can follow progress on this Bug here: 883615: > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. > > > > > > > > > > > > > > This is an automatically generated reply to let you know > > > > > > > your > > > > > > > message > > > > > > > has been receiv
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On Tue, 2017-12-05 at 22:23 +0100, Julien Aubin wrote: > To help debugging, could you provide me please some link to a newer > NVidia > driver release built for stretch please (and some notice to install > it) ? Unfortunately I don't think we have anything that can be used in Stretch - IIRC both 384 and 387 dependencies are structured for the glvnd transition, so they can't be installed on Stretch. > Thus : > - If I disable from a custom xorg.conf file module glx everything > loads > fine (as long as I use lightdm as a login manager) > > Thanks a lot. Could you clarify what this means? You are manually blacklisting glx? > 2017-12-05 22:14 GMT+01:00 Julien Aubin : > > > GLX crashes here : > > > > #0 0x7588ad01 in __GI_strtol_l_internal > > (nptr=0x7fffe2b1 > > "001 GLX", endptr=0x7fffe2a8, base=10, group=, > > loc=0x55ad3620) at ../stdlib/strtol_l.c:293 > > #1 0x555cd0cb in ?? () > > #2 0x555bbeb0 in AddExtension () > > #3 0x7381d7b2 in ?? () from > > /usr/lib/xorg/modules/linux/libglx.so > > > > #4 0x555bc040 in ?? () > > #5 0x001d in ?? () > > #6 0x0200 in ?? () > > #7 0x in ?? () > > > > > > 2017-12-05 21:47 GMT+01:00 Julien Aubin : > > > > > Hi, > > > > > > I reinstalled NVidia driver several times and the problem is > > > still the > > > same. Trying your method still results in the same issue. > > > > > > Now if I fully blacklist the nvidia driver I get a "better" black > > > screen > > > w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log > > > does not > > > hang on the GLX stuff. > > > > > > Looks like this issue targets GeForce 10xx GPUs (as my 970 does > > > seem > > > unaffected as well). > > > > > > Rgds > > > > > > > > > > > > 2017-12-05 21:13 GMT+01:00 Luca Boccassi : > > > > > > > On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: > > > > > Looks like the culprit is NVidia modeset. Thus the issue does > > > > > not > > > > > happen w/ > > > > > a Maxwell GPU. > > > > > > > > > > [ 542.167979] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > > > > > > > > > > > [ 542.490521] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 544.081034] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 544.385426] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 546.079744] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 546.399641] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 548.091421] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 548.395724] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 550.088731] nvidia-modeset: Allocated GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > [ 550.392898] nvidia-modeset: Freed GPU:0 > > > > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > > > > Didn't see any issue with my 780 (Kepler?). > > > > > > > > Are you sure the kernel modules is correctly rebuilt? I've seen > > > > that > > > > there was a kernel point release, and not all ABI changes are > > > > reverted. > > > > Which means DKMS won't rebuild the modules automatically. > > > > > > > > Try to remove it and rebuild it with: > > > > > > > > sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 > > > > sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 > > > > > 2017-12-05 20:51 GMT+01:00 Julien Aubin > > > > om>: > > > > > > > > > > > Driver hangs just here : > > > > > > ---> > > > > > > [32.680] (II) Initializing extension GLX > > > > > > [32.680] (II) Indirect GLX disabled. > > > > > > > > > > > > > > > > > > > Normally I should get then [34.659] (II) config/udev: > > > > > > Adding > > > > > > input > > > > > > device Power Button (/dev/input/event5) > > > > > > > > > > > > But here it crashes without log. > > > > > > > > > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < > > > > > > ow...@bugs.debian.org>: > > > > > > > > > > > > > Thank you for filing a new Bug report with Debian. > > > > > > > > > > > > > > You can follow progress on this Bug here: 883615: > > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. > > > > > > > > > > > > > > This is an automatically generated reply to let you know > > > > > > > your > > > > > > > message > > > > > > > has been received. > > > > > > > > > > > > > > Your message is being forwarded to the package > > > > > > > maintainers and > > > > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
To help debugging, could you provide me please some link to a newer NVidia driver release built for stretch please (and some notice to install it) ? Thus : - If I disable from a custom xorg.conf file module glx everything loads fine (as long as I use lightdm as a login manager) Thanks a lot. 2017-12-05 22:14 GMT+01:00 Julien Aubin : > GLX crashes here : > > #0 0x7588ad01 in __GI_strtol_l_internal (nptr=0x7fffe2b1 > "001 GLX", endptr=0x7fffe2a8, base=10, group=, > loc=0x55ad3620) at ../stdlib/strtol_l.c:293 > #1 0x555cd0cb in ?? () > #2 0x555bbeb0 in AddExtension () > #3 0x7381d7b2 in ?? () from /usr/lib/xorg/modules/linux/libglx.so > > #4 0x555bc040 in ?? () > #5 0x001d in ?? () > #6 0x0200 in ?? () > #7 0x in ?? () > > > 2017-12-05 21:47 GMT+01:00 Julien Aubin : > >> Hi, >> >> I reinstalled NVidia driver several times and the problem is still the >> same. Trying your method still results in the same issue. >> >> Now if I fully blacklist the nvidia driver I get a "better" black screen >> w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not >> hang on the GLX stuff. >> >> Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem >> unaffected as well). >> >> Rgds >> >> >> >> 2017-12-05 21:13 GMT+01:00 Luca Boccassi : >> >>> On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: >>> > Looks like the culprit is NVidia modeset. Thus the issue does not >>> > happen w/ >>> > a Maxwell GPU. >>> > >>> > [ 542.167979] nvidia-modeset: Allocated GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > >>> > >>> > [ 542.490521] nvidia-modeset: Freed GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 544.081034] nvidia-modeset: Allocated GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 544.385426] nvidia-modeset: Freed GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 546.079744] nvidia-modeset: Allocated GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 546.399641] nvidia-modeset: Freed GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 548.091421] nvidia-modeset: Allocated GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 548.395724] nvidia-modeset: Freed GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 550.088731] nvidia-modeset: Allocated GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> > [ 550.392898] nvidia-modeset: Freed GPU:0 >>> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >>> >>> Didn't see any issue with my 780 (Kepler?). >>> >>> Are you sure the kernel modules is correctly rebuilt? I've seen that >>> there was a kernel point release, and not all ABI changes are reverted. >>> Which means DKMS won't rebuild the modules automatically. >>> >>> Try to remove it and rebuild it with: >>> >>> sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 >>> sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 >>> > 2017-12-05 20:51 GMT+01:00 Julien Aubin : >>> > >>> > > Driver hangs just here : >>> > > ---> >>> > > [32.680] (II) Initializing extension GLX >>> > > [32.680] (II) Indirect GLX disabled. >>> > > > >>> > > >>> > > Normally I should get then [34.659] (II) config/udev: Adding >>> > > input >>> > > device Power Button (/dev/input/event5) >>> > > >>> > > But here it crashes without log. >>> > > >>> > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < >>> > > ow...@bugs.debian.org>: >>> > > >>> > > > Thank you for filing a new Bug report with Debian. >>> > > > >>> > > > You can follow progress on this Bug here: 883615: >>> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. >>> > > > >>> > > > This is an automatically generated reply to let you know your >>> > > > message >>> > > > has been received. >>> > > > >>> > > > Your message is being forwarded to the package maintainers and >>> > > > other >>> > > > interested parties for their attention; they will reply in due >>> > > > course. >>> > > > >>> > > > Your message has been sent to the package maintainer(s): >>> > > > Debian NVIDIA Maintainers >> > > > org> >>> > > > >>> > > > If you wish to submit further information on this problem, please >>> > > > send it to 883...@bugs.debian.org. >>> > > > >>> > > > Please do not send mail to ow...@bugs.debian.org unless you wish >>> > > > to report a problem with the Bug-tracking system. >>> > > > >>> > > > -- >>> > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 >>> > > > Debian Bug Tracking System >>> > > > Contact ow...@bugs.debian.org with problems >>> > > > >>> > > >>> > > >>> > >>> > ___ >>> > pkg-nvidia-devel mailing list >>> > pkg-nvidi
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
GLX crashes here : #0 0x7588ad01 in __GI_strtol_l_internal (nptr=0x7fffe2b1 "001 GLX", endptr=0x7fffe2a8, base=10, group=, loc=0x55ad3620) at ../stdlib/strtol_l.c:293 #1 0x555cd0cb in ?? () #2 0x555bbeb0 in AddExtension () #3 0x7381d7b2 in ?? () from /usr/lib/xorg/modules/linux/libglx.so #4 0x555bc040 in ?? () #5 0x001d in ?? () #6 0x0200 in ?? () #7 0x in ?? () 2017-12-05 21:47 GMT+01:00 Julien Aubin : > Hi, > > I reinstalled NVidia driver several times and the problem is still the > same. Trying your method still results in the same issue. > > Now if I fully blacklist the nvidia driver I get a "better" black screen > w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not > hang on the GLX stuff. > > Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem > unaffected as well). > > Rgds > > > > 2017-12-05 21:13 GMT+01:00 Luca Boccassi : > >> On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: >> > Looks like the culprit is NVidia modeset. Thus the issue does not >> > happen w/ >> > a Maxwell GPU. >> > >> > [ 542.167979] nvidia-modeset: Allocated GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > >> > >> > [ 542.490521] nvidia-modeset: Freed GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 544.081034] nvidia-modeset: Allocated GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 544.385426] nvidia-modeset: Freed GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 546.079744] nvidia-modeset: Allocated GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 546.399641] nvidia-modeset: Freed GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 548.091421] nvidia-modeset: Allocated GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 548.395724] nvidia-modeset: Freed GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 550.088731] nvidia-modeset: Allocated GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> > [ 550.392898] nvidia-modeset: Freed GPU:0 >> > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 >> >> Didn't see any issue with my 780 (Kepler?). >> >> Are you sure the kernel modules is correctly rebuilt? I've seen that >> there was a kernel point release, and not all ABI changes are reverted. >> Which means DKMS won't rebuild the modules automatically. >> >> Try to remove it and rebuild it with: >> >> sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 >> sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 >> > 2017-12-05 20:51 GMT+01:00 Julien Aubin : >> > >> > > Driver hangs just here : >> > > ---> >> > > [32.680] (II) Initializing extension GLX >> > > [32.680] (II) Indirect GLX disabled. >> > > > >> > > >> > > Normally I should get then [34.659] (II) config/udev: Adding >> > > input >> > > device Power Button (/dev/input/event5) >> > > >> > > But here it crashes without log. >> > > >> > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < >> > > ow...@bugs.debian.org>: >> > > >> > > > Thank you for filing a new Bug report with Debian. >> > > > >> > > > You can follow progress on this Bug here: 883615: >> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. >> > > > >> > > > This is an automatically generated reply to let you know your >> > > > message >> > > > has been received. >> > > > >> > > > Your message is being forwarded to the package maintainers and >> > > > other >> > > > interested parties for their attention; they will reply in due >> > > > course. >> > > > >> > > > Your message has been sent to the package maintainer(s): >> > > > Debian NVIDIA Maintainers > > > > org> >> > > > >> > > > If you wish to submit further information on this problem, please >> > > > send it to 883...@bugs.debian.org. >> > > > >> > > > Please do not send mail to ow...@bugs.debian.org unless you wish >> > > > to report a problem with the Bug-tracking system. >> > > > >> > > > -- >> > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 >> > > > Debian Bug Tracking System >> > > > Contact ow...@bugs.debian.org with problems >> > > > >> > > >> > > >> > >> > ___ >> > pkg-nvidia-devel mailing list >> > pkg-nvidia-de...@lists.alioth.debian.org >> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de >> > vel > > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Hi, I reinstalled NVidia driver several times and the problem is still the same. Trying your method still results in the same issue. Now if I fully blacklist the nvidia driver I get a "better" black screen w/ Nouveau, in the sense that keyboard answers. Thus Xorg.0.log does not hang on the GLX stuff. Looks like this issue targets GeForce 10xx GPUs (as my 970 does seem unaffected as well). Rgds 2017-12-05 21:13 GMT+01:00 Luca Boccassi : > On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: > > Looks like the culprit is NVidia modeset. Thus the issue does not > > happen w/ > > a Maxwell GPU. > > > > [ 542.167979] nvidia-modeset: Allocated GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > > > > [ 542.490521] nvidia-modeset: Freed GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 544.081034] nvidia-modeset: Allocated GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 544.385426] nvidia-modeset: Freed GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 546.079744] nvidia-modeset: Allocated GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 546.399641] nvidia-modeset: Freed GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 548.091421] nvidia-modeset: Allocated GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 548.395724] nvidia-modeset: Freed GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 550.088731] nvidia-modeset: Allocated GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > [ 550.392898] nvidia-modeset: Freed GPU:0 > > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > Didn't see any issue with my 780 (Kepler?). > > Are you sure the kernel modules is correctly rebuilt? I've seen that > there was a kernel point release, and not all ABI changes are reverted. > Which means DKMS won't rebuild the modules automatically. > > Try to remove it and rebuild it with: > > sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 > sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 > > 2017-12-05 20:51 GMT+01:00 Julien Aubin : > > > > > Driver hangs just here : > > > ---> > > > [32.680] (II) Initializing extension GLX > > > [32.680] (II) Indirect GLX disabled. > > > > > > > > > > Normally I should get then [34.659] (II) config/udev: Adding > > > input > > > device Power Button (/dev/input/event5) > > > > > > But here it crashes without log. > > > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < > > > ow...@bugs.debian.org>: > > > > > > > Thank you for filing a new Bug report with Debian. > > > > > > > > You can follow progress on this Bug here: 883615: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. > > > > > > > > This is an automatically generated reply to let you know your > > > > message > > > > has been received. > > > > > > > > Your message is being forwarded to the package maintainers and > > > > other > > > > interested parties for their attention; they will reply in due > > > > course. > > > > > > > > Your message has been sent to the package maintainer(s): > > > > Debian NVIDIA Maintainers > > > org> > > > > > > > > If you wish to submit further information on this problem, please > > > > send it to 883...@bugs.debian.org. > > > > > > > > Please do not send mail to ow...@bugs.debian.org unless you wish > > > > to report a problem with the Bug-tracking system. > > > > > > > > -- > > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 > > > > Debian Bug Tracking System > > > > Contact ow...@bugs.debian.org with problems > > > > > > > > > > > > > > ___ > > pkg-nvidia-devel mailing list > > pkg-nvidia-de...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de > > vel
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
On Tue, 2017-12-05 at 20:55 +0100, Julien Aubin wrote: > Looks like the culprit is NVidia modeset. Thus the issue does not > happen w/ > a Maxwell GPU. > > [ 542.167979] nvidia-modeset: Allocated GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > > > [ 542.490521] nvidia-modeset: Freed GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 544.081034] nvidia-modeset: Allocated GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 544.385426] nvidia-modeset: Freed GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 546.079744] nvidia-modeset: Allocated GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 546.399641] nvidia-modeset: Freed GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 548.091421] nvidia-modeset: Allocated GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 548.395724] nvidia-modeset: Freed GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 550.088731] nvidia-modeset: Allocated GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 > [ 550.392898] nvidia-modeset: Freed GPU:0 > (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 Didn't see any issue with my 780 (Kepler?). Are you sure the kernel modules is correctly rebuilt? I've seen that there was a kernel point release, and not all ABI changes are reverted. Which means DKMS won't rebuild the modules automatically. Try to remove it and rebuild it with: sudo dkms uninstall nvidia-current/375.82 -k 4.9.0-4-amd64 sudo dkms install nvidia-current/375.82 -k 4.9.0-4-amd64 > 2017-12-05 20:51 GMT+01:00 Julien Aubin : > > > Driver hangs just here : > > ---> > > [32.680] (II) Initializing extension GLX > > [32.680] (II) Indirect GLX disabled. > > > > > > > Normally I should get then [34.659] (II) config/udev: Adding > > input > > device Power Button (/dev/input/event5) > > > > But here it crashes without log. > > > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < > > ow...@bugs.debian.org>: > > > > > Thank you for filing a new Bug report with Debian. > > > > > > You can follow progress on this Bug here: 883615: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. > > > > > > This is an automatically generated reply to let you know your > > > message > > > has been received. > > > > > > Your message is being forwarded to the package maintainers and > > > other > > > interested parties for their attention; they will reply in due > > > course. > > > > > > Your message has been sent to the package maintainer(s): > > > Debian NVIDIA Maintainers > > org> > > > > > > If you wish to submit further information on this problem, please > > > send it to 883...@bugs.debian.org. > > > > > > Please do not send mail to ow...@bugs.debian.org unless you wish > > > to report a problem with the Bug-tracking system. > > > > > > -- > > > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 > > > Debian Bug Tracking System > > > Contact ow...@bugs.debian.org with problems > > > > > > > > > ___ > pkg-nvidia-devel mailing list > pkg-nvidia-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-nvidia-de > vel signature.asc Description: This is a digitally signed message part
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Looks like the culprit is NVidia modeset. Thus the issue does not happen w/ a Maxwell GPU. [ 542.167979] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 542.490521] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 544.081034] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 544.385426] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 546.079744] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 546.399641] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 548.091421] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 548.395724] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 550.088731] nvidia-modeset: Allocated GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 [ 550.392898] nvidia-modeset: Freed GPU:0 (GPU-c9899079-b539-164e-1242-191c547d3276) @ PCI::01:00.0 2017-12-05 20:51 GMT+01:00 Julien Aubin : > Driver hangs just here : > ---> > [32.680] (II) Initializing extension GLX > [32.680] (II) Indirect GLX disabled. > > > > Normally I should get then [34.659] (II) config/udev: Adding input > device Power Button (/dev/input/event5) > > But here it crashes without log. > > 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System < > ow...@bugs.debian.org>: > >> Thank you for filing a new Bug report with Debian. >> >> You can follow progress on this Bug here: 883615: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. >> >> This is an automatically generated reply to let you know your message >> has been received. >> >> Your message is being forwarded to the package maintainers and other >> interested parties for their attention; they will reply in due course. >> >> Your message has been sent to the package maintainer(s): >> Debian NVIDIA Maintainers >> >> If you wish to submit further information on this problem, please >> send it to 883...@bugs.debian.org. >> >> Please do not send mail to ow...@bugs.debian.org unless you wish >> to report a problem with the Bug-tracking system. >> >> -- >> 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 >> Debian Bug Tracking System >> Contact ow...@bugs.debian.org with problems >> > >
Bug#883615: Acknowledgement ([CRITICAL] Stretch p-u 9.3 breaks NVidia driver and X.org)
Driver hangs just here : ---> [32.680] (II) Initializing extension GLX [32.680] (II) Indirect GLX disabled. > Normally I should get then [34.659] (II) config/udev: Adding input device Power Button (/dev/input/event5) But here it crashes without log. 2017-12-05 20:09 GMT+01:00 Debian Bug Tracking System : > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 883615: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian NVIDIA Maintainers > > If you wish to submit further information on this problem, please > send it to 883...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 883615: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883615 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
