On 2014-12-19 12:01, Ilya Anfimov wrote: > After investigation, it looks partially true: nvidia_drv.so > symlink in /usr/lib/xorg/modules/drivers is made by hand, as
but that link alone is not sufficient ... > update-alternatives --set glx /usr/lib/mesa-diverted > > removes this symlink. > Hoever, while README states that this configuration is official- > ly unsupported (which is sad), the bug also could be triggered by > connecting to the nvidia-driven X-server from machine with mesa > or ATI libGL drivers. Can you run the X-server machine with the supported configuration from update-alternatives --set glx /usr/lib/nvidia also /usr/lib/xorg/modules/extensions/libglx.so, libnvglx.so are manual symlinks, get rid of them, too reinstall xserver-xorg-core to get back the xorg libglx.so and maybe try a minimal xorg.conf as describd in the README.Debian >> * some 340.xx driver packages are installed, but that does not support >> your card, remove them > > OK, I'll try that on fresh debian this weekend (when I could > boot it from usb flash for experiments). > However, I think that nvidia-alternative is exactly for keeping > both versions on one machine. Correct, but with all the cruft around previously I want to rule out any potential error source. > There really was libnvidia-wfb.so* . Removing it and starting X > server with buggy glx driver doesn't change anything. > Also, I had attached ls -l on all those directories, just in > case you'll want to see it. More cruft: > + ls -l /usr/lib/xorg/modules/extensions > -rw-r--r-- 1 root root 2502561 Mar 7 2007 libGLcore.so > -rw-r--r-- 1 root root 421696 Sep 23 2009 libglx.so-xorg >> In the end you probably loaded a mix of incompatible versions resulting >> in your failures. > > Server version is definitely 304.123 -- nvidia driver and nvidia > glx module are linked to specific libraries, and they scream when > they are of diffirent versions or when kernel module is different > version. Attached mmap of X-server, proving that. please update to 304.125 > Client is Mesa (without any dri installed), it should not take > any touch of nvidia libraries. So X is tunneled (via ssh)? This increases the fun ... :-) Are things working *locally*? > Also, I've taken some experiments, and found that nvidia > libGL.so.1 works fine. It works in both direct and indirect mode. > It also works fine with -340 version of client library (only > indirect mode, of course). > Wireshark view of indirect mode traffic shows, that in nvidia > glx library glXSwapIntervalSGI is made by some NV-GLX extension > requests, undecoded as there is no NV-GLX decode support in wire- > shark. I don't know simple ways to disable usage of NV-GLX, so I > don't know what this client library will do when it will not find > NV-GLX extension on server. > ATI's libgl1-fglrx-glx libGL.so.1 library fails, nearly the > same way as MESA one. Need to think more about this ... Andreas PS: I'll be mostly offline over the holidays -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
