Bug#799948: Plasma desktop is unable to start (black screen - panic)

[Vladimir Stavrinov]

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)

[Luca Boccassi]

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)

[Andreas Beckmann]

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)

[Vladimir Stavrinov]

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)

[Vladimir Stavrinov]

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)

[Luca Boccassi]

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)

[Miguel A. Rojas]

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)

[Vladimir Stavrinov]

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)

[Miguel Angel Rojas]

>
>
> 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)

[Vladimir Stavrinov]

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)

[Vladimir Stavrinov]

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)

[Luca Boccassi]

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)

[Luca Boccassi]

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)

[Miguel Angel Rojas]

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 

Bug#799948: Plasma desktop is unable to start (black screen - panic)

[Luca Boccassi]

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)

[Luca Boccassi]

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)

[Luca Boccassi]

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)

[Luca Boccassi]

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#800938: Bug#799948: Plasma desktop is unable to start (black screen - panic)

[Miguel Angel Rojas]

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 

Bug#799948: Plasma desktop is unable to start (black screen - panic)

[Luca Boccassi]

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)

[Vladimir Stavrinov]

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 

Bug#799948: Plasma desktop is unable to start (black screen - panic)

[Vladimir Stavrinov]

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)

[Vladimir Stavrinov]

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)

[Miguel Angel Rojas]

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