Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Wed, Oct 21, 2015 at 05:34:32PM +0100, Luca Boccassi wrote: > default by upstream (and by udev) with 666 permissions, so world I hate such gys. They want more: 777. They say: "give me 777 and everything will work. They don't need any other user than root. This is microsoft heritage in mind. No users, no task no network - this is the best OS where everything work. > With the upload Andreas just did (340.93-6) the video group workaround > won't be needed, but device nodes go back to 666. May be this is even worse solution. I have recently joked, but may be this is true: it is better to notify about need to include user in video group. You can do this with banner while installation or via email after that. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On 21 October 2015 at 17:15, Vladimir Stavrinov wrote: > OK, but what happened recently with 0.6.x version? Do You want to > say, that ordinary user always had had write access to nvidia device? Yes. That is what we were trying to fix: device nodes are created by default by upstream (and by udev) with 666 permissions, so world readable and writable. We tried to fix it back to 660, but that caused all these regressions and required the users to be in the video group as a workaround. With the upload Andreas just did (340.93-6) the video group workaround won't be needed, but device nodes go back to 666. Kind regards, Luca Boccassi
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Wed, Oct 21, 2015 at 05:50:22PM +0200, Andreas Beckmann wrote: > The driver is a non-free blob. I have no clue how it works :-) Kicks nvidia ass. Non-free blob is always headache. Will it be sensitive for nvida if all Linux user will boycott them not buying their hardware? OK, but what happened recently with 0.6.x version? Do You want to say, that ordinary user always had had write access to nvidia device? ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On 2015-10-21 17:39, Vladimir Stavrinov wrote: > explains nothing about this. There are no answer to the question: > what for glx requires write access to video device for normal live > user? This is something new in world fashion. Why only glx require > this? How do other video works without such requirements? The driver is a non-free blob. I have no clue how it works :-) Andreas
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Tue, Oct 20, 2015 at 11:31:05PM +0100, Luca Boccassi wrote: > Could you please make sure that both your user and your DM user (sddm I > believe?) are in the video group and try again and report the result? Yes, this solves the problem, but it is ridiculous. First of all it is security issue. The "video" group is system group that provide write access to video device. It is using not only for nvidia. For example I am using special system user "webcam" for streaming from my web camera to RTMP server. To do this I've added it to video group. So normal non-system user should not be included into this group. Second, tell us please how do You make sure the normal user being included into video group? For example, if You add new user with useradd utility? Yes, You can do this with something like hook or trigger, but this is not only way to create new user - there are unlimited number of ways to do this. Or may be You are going notify all sysadmins about this? No. This is really crazy idea to provide non-system ordinary user with write access to video device in order to provide access to glx library. And Andreas Beckmann's post: http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2015-October/011948.html explains nothing about this. There are no answer to the question: what for glx requires write access to video device for normal live user? This is something new in world fashion. Why only glx require this? How do other video works without such requirements? ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Oct 21, 2015 08:54, "Miguel A. Rojas" wrote: > > On 10/21/2015 12:22 AM, Luca Boccassi wrote: >>> >>> Hi Miguel, >>> >>> The reason I'm asking is because I can't reproduce any problems on GDM, >>> with any software that uses GLX or other libraries, after adding the >>> workaround. >>> >>> But I noticed something looking again at the system info you forwarded, >>> the only user in the "video" group is sddm: >>> >>> video:x:44:sddm >>> >>> I verified yesterday that even on GDM both the DM-manager user (in my >>> case Debian-gdm) AND my user MUST be in the video group, otherwise the >>> problem occurs. >>> >>> Could you please try to add your user to the video group and see if that >>> helps? > > And it seems that works like a charm! It seems KDE only needs sddm and your user to be included in the video group. No more panics or black screens. > > Good shot! Happy to hear that. Now we now that not only gdm, but also kde has that requirement when the device nodes have restrictive permissions. >> We are still discussing and investigating that. It is not a new upstream >> requirement but a fix to the device nodes permissions that we are trying >> out, but it seems to be causing way too much grief. Please see this >> message by Andreas [1] for more details about the background. >> >> Kind regards, >> Luca Boccassi > > I am sorry, I don't see the message from Andreas your are referring to. That's because I forgot to paste the URL :-) http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/2015-October/011948.html Kind regards, Luca Boccassi
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On 10/21/2015 12:22 AM, Luca Boccassi wrote: Hi Miguel, The reason I'm asking is because I can't reproduce any problems on GDM, with any software that uses GLX or other libraries, after adding the workaround. But I noticed something looking again at the system info you forwarded, the only user in the "video" group is sddm: video:x:44:sddm I verified yesterday that even on GDM both the DM-manager user (in my case Debian-gdm) AND my user MUST be in the video group, otherwise the problem occurs. Could you please try to add your user to the video group and see if that helps? And it seems that works like a charm! It seems KDE only needs sddm and your user to be included in the video group. No more panics or black screens. Good shot! We are still discussing and investigating that. It is not a new upstream requirement but a fix to the device nodes permissions that we are trying out, but it seems to be causing way too much grief. Please see this message by Andreas [1] for more details about the background. Kind regards, Luca Boccassi I am sorry, I don't see the message from Andreas your are referring to. Thanks!
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Tue, 2015-10-20 at 12:16 +0300, Vladimir Stavrinov wrote: > On Mon, Oct 19, 2015 at 10:11:45PM +0100, Luca Boccassi wrote: > > > Maybe there's some context I'm missing. Forgive me for asking, but are > > you sure this is due to the Nvidia driver packages or glx-alternatives? > > Absolutely. This is Nvidia driver problem. Few days ago I conducted > specific experiment. After upgrading to latest version of all nvidia > and glx packages, I've downgraded only kernel module and after > reloading module the glx got working. But after rebooting system the > problem returned again. So not only kernel module is problem, but it > is main. That is most likely because the permissions on the device nodes are different when you load the module manually vs when udev does it at boot. > > Andreas, you use KDE if I'm not mistaken. Are you seeing any issues? Do > > How many times again: this is not problem of KDE, plasma, kodi or any > other software using glx. This is problem of glx in nvidia driver. > > I am using xlock from very old package xlockmore-gl not included in > any of today's debian distributions. But it has two options > "-modelist allgl" and "-modelist all-allgl". First is for include glx > modes, second - to exclude ones. This is very good for testing glx, > because it explicitly points to glx as the source of problem when it > works with second option and doesn't work with the first one. > > So it is certainly clear, that the source of our problems is glx > feature of nvdia driver. But the fact that You can't reproduce the > problem (if You can't, because You never mentioned this) may mean, > that problem is somehow hardware specific. In this case there are no > way to debug it as to ask us to do for You some experiments of Your > choice. > > Here is my hardware: > > lspci | grep -i nvidia > 01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 635] > (rev a1) > 01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev > a1) > > If this guess is not true and the problem is not hardware specific, then You > should try number of different software using glx to reproduce the > problem. > > And finally it is possible, that at some point of investigation You > will understand necessity to escalate the problem to upstream. The reason I'm asking about which DM this is happening on is because, after applying the video group workaround I am not experiencing any issues with any software that uses GLX or any other library provided by the nvidia drivers. So, I was just trying to narrow it down and get the full picture of the environment. As I wrote earlier, yesterday I noticed that it is not enough for the desktop-manager user (sddm or Debian-gdm) to be in the video group, the user also MUST be part of it, otherwise GDM breaks due to the device nodes permissions problem. Could you please make sure that both your user and your DM user (sddm I believe?) are in the video group and try again and report the result? Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Tue, 2015-10-20 at 11:56 +0200, Miguel Angel Rojas wrote: > > I must first say that I am absolutely not familiar with KDE, > the QT > environment and how it works. But the thread that raises the > abort > doesn't look like it's in the GL libraries code: > > Maybe there's some context I'm missing. Forgive me for asking, > but are > you sure this is due to the Nvidia driver packages or > glx-alternatives? > > > > Hi Luca, > > > But indeed, it is! I conducted the same experiments as Vladimir did > with the same result. Something is wrong with the glx beyond 0.6.x > (bad packaging, new API, new behavior? I don't know). I would > recommend to reproduce as it is very easy to do it and you will see > what we are talking about. Hi Miguel, The reason I'm asking is because I can't reproduce any problems on GDM, with any software that uses GLX or other libraries, after adding the workaround. But I noticed something looking again at the system info you forwarded, the only user in the "video" group is sddm: video:x:44:sddm I verified yesterday that even on GDM both the DM-manager user (in my case Debian-gdm) AND my user MUST be in the video group, otherwise the problem occurs. Could you please try to add your user to the video group and see if that helps? > Talking about Bug #799948, is there a reason why sddm user should be > included in video? (because it seems to be the workaround) If so, > someone should notify sddm guys that is somehow required due to new > upstream requirement in nvidia glx packages. We don't have a clear > explanation about it. We are still discussing and investigating that. It is not a new upstream requirement but a fix to the device nodes permissions that we are trying out, but it seems to be causing way too much grief. Please see this message by Andreas [1] for more details about the background. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#799948: Plasma desktop is unable to start (black screen - panic)
> > > I must first say that I am absolutely not familiar with KDE, the QT > environment and how it works. But the thread that raises the abort > doesn't look like it's in the GL libraries code: > > Maybe there's some context I'm missing. Forgive me for asking, but are > you sure this is due to the Nvidia driver packages or glx-alternatives? > > Hi Luca, But indeed, it is! I conducted the same experiments as Vladimir did with the same result. Something is wrong with the glx beyond 0.6.x (bad packaging, new API, new behavior? I don't know). I would recommend to reproduce as it is very easy to do it and you will see what we are talking about. Talking about Bug #799948, is there a reason why sddm user should be included in video? (because it seems to be the workaround) If so, someone should notify sddm guys that is somehow required due to new upstream requirement in nvidia glx packages. We don't have a clear explanation about it. Regards
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Mon, Oct 19, 2015 at 10:11:45PM +0100, Luca Boccassi wrote: > Maybe there's some context I'm missing. Forgive me for asking, but are > you sure this is due to the Nvidia driver packages or glx-alternatives? Absolutely. This is Nvidia driver problem. Few days ago I conducted specific experiment. After upgrading to latest version of all nvidia and glx packages, I've downgraded only kernel module and after reloading module the glx got working. But after rebooting system the problem returned again. So not only kernel module is problem, but it is main. > Andreas, you use KDE if I'm not mistaken. Are you seeing any issues? Do How many times again: this is not problem of KDE, plasma, kodi or any other software using glx. This is problem of glx in nvidia driver. I am using xlock from very old package xlockmore-gl not included in any of today's debian distributions. But it has two options "-modelist allgl" and "-modelist all-allgl". First is for include glx modes, second - to exclude ones. This is very good for testing glx, because it explicitly points to glx as the source of problem when it works with second option and doesn't work with the first one. So it is certainly clear, that the source of our problems is glx feature of nvdia driver. But the fact that You can't reproduce the problem (if You can't, because You never mentioned this) may mean, that problem is somehow hardware specific. In this case there are no way to debug it as to ask us to do for You some experiments of Your choice. Here is my hardware: lspci | grep -i nvidia 01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 635] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK208 HDMI/DP Audio Controller (rev a1) If this guess is not true and the problem is not hardware specific, then You should try number of different software using glx to reproduce the problem. And finally it is possible, that at some point of investigation You will understand necessity to escalate the problem to upstream. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Tue, Oct 20, 2015 at 09:25:16AM +0300, Vladimir Stavrinov wrote: > what I am doing to get it working: > > dpkg -P nvidia-kernel-support > dpkg -i glx-alternative-mesa_0.5.1_amd64.deb > glx-alternative-nvidia_0.5.1_amd64.deb glx-diversions_0.5.1_amd64.deb > libegl1-nvidia_340.93-1_amd64.deb libgl1-nvidia-glx-i386_340.93-1_i386.deb > libgl1-nvidia-glx_340.93-1_amd64.deb libgl1-nvidia-glx_340.93-1_i386.deb > libgles1-nvidia_340.93-1_amd64.deb libgles2-nvidia_340.93-1_amd64.deb > libnvidia-eglcore_340.93-1_amd64.deb libnvidia-ml1_340.93-1_amd64.deb > nvidia-alternative_340.93-1_amd64.deb nvidia-driver-bin_340.93-1_amd64.deb > nvidia-driver_340.93-1_amd64.deb nvidia-kernel-dkms_340.93-1_amd64.deb > nvidia-vdpau-driver_340.93-1_amd64.deb > xserver-xorg-video-nvidia_340.93-1_amd64.deb > In reverse order or do it twice to resolve dependency issue. > And nothing else. Then reboot. P.S. 0.6.92 doesn't help again. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Mon, Oct 19, 2015 at 10:05:12PM +0100, Luca Boccassi wrote: > In your case it looks like it certainly is. Your glx alternative is No, it is not. I never touched setup. As I wrote before more then once, the problem arises after upgrade, not as result of setup changing. > configured to Mesa instead of Nvidia: > > diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by > glx-diversions > diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by > glx-diversions > diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by > glx-diversions > diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 > by glx-diversions You are wrong: it is about divert and not about alternative. > Please run: > > sudo update-alternatives --set glx /usr/lib/nvidia > sudo dpkg-reconfigure glx-alternative-nvidia This does not helps and can't help, because again and again: it is not setup problem, it is upgrade result. Downgrade helps. That is what I am doing to get it working: dpkg -P nvidia-kernel-support dpkg -i glx-alternative-mesa_0.5.1_amd64.deb glx-alternative-nvidia_0.5.1_amd64.deb glx-diversions_0.5.1_amd64.deb libegl1-nvidia_340.93-1_amd64.deb libgl1-nvidia-glx-i386_340.93-1_i386.deb libgl1-nvidia-glx_340.93-1_amd64.deb libgl1-nvidia-glx_340.93-1_i386.deb libgles1-nvidia_340.93-1_amd64.deb libgles2-nvidia_340.93-1_amd64.deb libnvidia-eglcore_340.93-1_amd64.deb libnvidia-ml1_340.93-1_amd64.deb nvidia-alternative_340.93-1_amd64.deb nvidia-driver-bin_340.93-1_amd64.deb nvidia-driver_340.93-1_amd64.deb nvidia-kernel-dkms_340.93-1_amd64.deb nvidia-vdpau-driver_340.93-1_amd64.deb xserver-xorg-video-nvidia_340.93-1_amd64.deb And nothing else. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On 19 October 2015 at 23:42, Andreas Beckmann wrote: > On 2015-10-19 23:05, Luca Boccassi wrote: >> In your case it looks like it certainly is. Your glx alternative is >> configured to Mesa instead of Nvidia: >> >> diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by >> glx-diversions >> diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by >> glx-diversions >> diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by >> glx-diversions >> diversion of /usr/lib/libGL.so.1.2.0 to >> /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions > > copy+paste error? that's the diversion, not the alternative Agh, grep'ed for the wrong thing. Sorry. One should not read through long logs in a hurry :-) The diversion looks fine then. Andreas, do you have any issues with KDE? Kind regards, Luca Boccassi
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Mon, 2015-10-19 at 11:38 +0200, Miguel Angel Rojas wrote: > Hi Luca, > > > Here you have the report you asked about the plasmashell. I do not > know if it could be related to a configuration issue, but again very > easy to reproduce. Here you have 2 reports (same error in 2 > consecutive log on sessions). > > > These crashes are related to the plasmashell (I manually fixed the > workaround by adding the sddm user to the video group) but if you > remove it, sddm is the one who crashes. Hi Miguel, Thanks for the backtraces. I must first say that I am absolutely not familiar with KDE, the QT environment and how it works. But the thread that raises the abort doesn't look like it's in the GL libraries code: Thread 1 (Thread 0x7fb33d8ec940 (LWP 2396)): [KCrash Handler] #6 0x7fb337fca107 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x7fb337fcb4e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x7fb338748c28 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fb33b972ee1 in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #10 0x7fb33b97aee4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #11 0x7fb33b97b30b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #12 0x7fb338c657f5 in QWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #13 0x7fb33b9ab9a3 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #14 0x0043e8f6 in DesktopView::event(QEvent*) () #15 0x7fb339418b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #16 0x7fb33941e230 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x7fb33893aa8b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x7fb338c5e366 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #19 0x7fb338c5f0ad in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #20 0x7fb338c44628 in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #21 0x7fb328d88af0 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so #22 0x7fb334e31fe7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x7fb334e32240 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7fb334e322ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x7fb338991e2f in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x7fb3389382ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #27 0x7fb33893fe3c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x004322c3 in main () Maybe there's some context I'm missing. Forgive me for asking, but are you sure this is due to the Nvidia driver packages or glx-alternatives? Andreas, you use KDE if I'm not mistaken. Are you seeing any issues? Do you need your user in any group to fix the root:video 660 problem on the device nodes? Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Mon, 2015-10-19 at 08:24 +0300, Vladimir Stavrinov wrote: > On Sun, Oct 18, 2015 at 11:03:35PM +0100, Luca Boccassi wrote: > > > Nothing seems wrong in the setup. > > The problem is not about setup. Hi Vladimir, In your case it looks like it certainly is. Your glx alternative is configured to Mesa instead of Nvidia: diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions Please run: sudo update-alternatives --set glx /usr/lib/nvidia sudo dpkg-reconfigure glx-alternative-nvidia That will set Nvidia as the provider of all the GL libraries. Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi Luca, Here you have the report you asked about the plasmashell. I do not know if it could be related to a configuration issue, but again very easy to reproduce. Here you have 2 reports (same error in 2 consecutive log on sessions). These crashes are related to the plasmashell (I manually fixed the workaround by adding the sddm user to the video group) but if you remove it, sddm is the one who crashes. Hope it helps. Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f972f7dc940 (LWP 1799))] Thread 7 (Thread 0x7f9718aeb700 (LWP 1801)): #0 0x7f9729f6252d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f972dfb2252 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7f972dfb3ddf in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7f971ac4c2f9 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so #4 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 6 (Thread 0x7f971220c700 (LWP 1806)): #0 0x7f972a881391 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #1 0x7f9726d2176d in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f9726d2210b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #8 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7f9709f46700 (LWP 1810)): #0 0x7f97297717fc in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f972976d4d4 in _L_lock_986 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f972976d336 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x7f972614de90 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #4 0x7f972615141e in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #5 0x7f972615181b in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1 #6 0x7f97226fafc0 in ?? () from /usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.340.93 #7 0x7f9726d654d0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #8 0x7f9726d21cc4 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #9 0x7f9726d22180 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #10 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #14 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #15 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #17 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7f97035c8700 (LWP 1814)): #0 0x7f9726d221c2 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7f9726d222ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7f972a881e4b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #3 0x7f972a8282ca in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7f972a646374 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7f972ce7b055 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 #6 0x7f972a64b25e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7f972976b0a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7f9729f6b06d in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7f9701d32700 (LWP 1815)): #0 0x7f972976f08f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f972f222144 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #2 0x7f972f222189 in ?? () from /usr/lib/x86_6
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Sun, Oct 18, 2015 at 11:03:35PM +0100, Luca Boccassi wrote: > Nothing seems wrong in the setup. The problem is not about setup. > What is the exact error you get with plasma? The problem is not about "exact error". The problem is about GLX, that doesn't works with any software. Errors may be differ. But segfault is common. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Sun, Oct 18, 2015 at 08:43:50PM +0100, Luca Boccassi wrote: > Could you please attach the output of: > > reportbug --template glx-alternative-nvidia > reportbug --template nvidia-driver *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Vladmimir Stavrinov ' as your from address. Getting status for glx-alternative-nvidia... Will send report to Debian (per lsb_release). Maintainer for glx-alternative-nvidia is 'Debian NVIDIA Maintainers '. Looking up dependencies of glx-alternative-nvidia... Getting status for related package glx-diversions... Looking up 'depends' of related package glx-diversions... Looking up 'recommends' of related package glx-diversions... Getting status for related package nvidia-glx... Getting status for related package fglrx-driver... Looking up status of additional packages... Rewriting subject to 'glx-alternative-nvidia: none' Gathering additional data, this may take a while... Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Vladmimir Stavrinov To: Debian Bug Tracking System Subject: glx-alternative-nvidia: none Package: glx-alternative-nvidia Version: 0.6.91 Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/li
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On 18 October 2015 at 22:23, Miguel Angel Rojas wrote: > Hi Luca, > > Thanks for the quick answer! > > Here you have both report you asked for. Hopefully it will help us to know > where the issue is. Nothing seems wrong in the setup. What is the exact error you get with plasma? Kind regards, Luca Boccassi
Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi Luca, Thanks for the quick answer! Here you have both report you asked for. Hopefully it will help us to know where the issue is. Regards On Sun, Oct 18, 2015 at 9:43 PM, Luca Boccassi wrote: > On Sun, 2015-10-18 at 20:16 +0200, Miguel Angel Rojas wrote: > > Hi all, > > > > > > Vladimir is right, same issue here. Indeed, It is weird to me not so > > many people is currently reporting on it, but it is affecting a lot of > > programs. Something happens when upgrading to version 0.6.x (I agree > > at this point) > > > > > > plasma-desktop is also unable to start and panic (black screen).If you > > update-alternative glx fall back to mesa, the desktop runs just fine > > (of course, without the nvidia drivers) > > > > > > I though it was solved by bug 799948 (ssdm panic too), but again, it > > is not. At least you can "adduser sddm video" and make ssdm-greater > > works as a workaround, but plasma-desktop panics still panics after > > you try to log on. > > > > > > > > It is very easy to check it. Just install a fresh installation of KDE > > and nvidia drivers and you will see a beautiful black screen. Let me > > know if you need additional information but it is quite easy to > > reproduce > > Hi, > > Could you please attach the output of: > > reportbug --template glx-alternative-nvidia > reportbug --template nvidia-driver > > Kind regards, > Luca Boccassi > > -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/libGLESv2.so.2.0.0 to /usr/lib/mesa-di
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Sun, 2015-10-18 at 20:16 +0200, Miguel Angel Rojas wrote: > Hi all, > > > Vladimir is right, same issue here. Indeed, It is weird to me not so > many people is currently reporting on it, but it is affecting a lot of > programs. Something happens when upgrading to version 0.6.x (I agree > at this point) > > > plasma-desktop is also unable to start and panic (black screen).If you > update-alternative glx fall back to mesa, the desktop runs just fine > (of course, without the nvidia drivers) > > > I though it was solved by bug 799948 (ssdm panic too), but again, it > is not. At least you can "adduser sddm video" and make ssdm-greater > works as a workaround, but plasma-desktop panics still panics after > you try to log on. > > > > It is very easy to check it. Just install a fresh installation of KDE > and nvidia drivers and you will see a beautiful black screen. Let me > know if you need additional information but it is quite easy to > reproduce Hi, Could you please attach the output of: reportbug --template glx-alternative-nvidia reportbug --template nvidia-driver Kind regards, Luca Boccassi
Bug#799948: Plasma desktop is unable to start (black screen - panic)
On Sun, Oct 18, 2015 at 08:16:39PM +0200, Miguel Angel Rojas wrote: >Vladimir is right, same issue here. Indeed, It is weird to me not so >many people is currently reporting on it, but it is affecting a lot of And even more weird is practice to close an issue without confirmation from users who reported the problem, that it has been solved. ### Vladimir Stavrinov ###
Bug#799948: Plasma desktop is unable to start (black screen - panic)
Hi all, Vladimir is right, same issue here. Indeed, It is weird to me not so many people is currently reporting on it, but it is affecting a lot of programs. Something happens when upgrading to version 0.6.x (I agree at this point) plasma-desktop is also unable to start and panic (black screen).If you update-alternative glx fall back to mesa, the desktop runs just fine (of course, without the nvidia drivers) I though it was solved by bug 799948 (ssdm panic too), but again, it is not. At least you can "adduser sddm video" and make ssdm-greater works as a workaround, but plasma-desktop panics still panics after you try to log on. It is very easy to check it. Just install a fresh installation of KDE and nvidia drivers and you will see a beautiful black screen. Let me know if you need additional information but it is quite easy to reproduce Regards