Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Sun, 2018-06-24 at 11:49 +0200, floris wrote: > > > > What about the following > > /etc/nvidia/current/nvidia-drm-outputclass.conf > > > > --- > > Section "Files" > > ModulePath "/usr/lib/xorg/modules/linux" > > ModulePath "/usr/lib/xorg/modules" > > EndSection > > > > Section "OutputClass" > > Identifier "nvidia" > > MatchDriver"nvidia-drm" > > Driver "nvidia" > > EndSection > > --- > > > > That seems to work for stable ... what about sid? > > > > > > Andreas > > Hmmm, this should work, but the NVidia glx module will always be > loaded > for all screens by the xserver. This will break a multiseat system > with > multiple gpu vendors and maybe other glvnd dispatch goodness. Tried this with nonglvnd + optimus + bumblebee and it works fine as far as I can see > Is the following situation a possibility? > > Stable -> nvidia-driver (up to version 390.xx in backports), > compatible > with all versions of the xserver > This version is shipped with a separate Files section in > nvidia-drm-outputclass.conf > If xserver 1.20 is in backports, this version can be upgraded to > match > the new Testing/Sid version > > Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 > -> nvidia-driver (version > 396.xx), xserver > 1.20 > These versions will have the ModulePath option in the OutputClass > section. (and we can drop the glx-alternative system) > --- > Floris -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Andreas Beckmann schreef op 2018-06-25 17:38: On 2018-06-24 11:49, floris wrote: What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" EndSection --- That seems to work for stable ... what about sid? Andreas Hmmm, this should work, but the NVidia glx module will always be loaded for all screens by the xserver. This will break a multiseat system with multiple gpu vendors and maybe other glvnd dispatch goodness. Is the following situation a possibility? We can consider such fancy setup for 396.xx and newer, since that will change a lot anyway. For 390.xx I want to have a version in sid that can be uploaded with minimal changes to stretch once the next CVE arrives ... I understand you ideally want one nvidia package for all Debian versions. Stable -> nvidia-driver (up to version 390.xx in backports), compatible with all versions of the xserver This version is shipped with a separate Files section in nvidia-drm-outputclass.conf If xserver 1.20 is in backports, this version can be upgraded to match the new Testing/Sid version Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 -> nvidia-driver (version > 396.xx), xserver > 1.20 These versions will have the ModulePath option in the OutputClass section. (and we can drop the glx-alternative system) Nope, we have to keep glx-alternatives around as long as 340xx is still in the game. Sorry, I forgot 340xx doesn't support glvnd --- Floris
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On 2018-06-24 11:49, floris wrote: >> >> What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf >> >> --- >> Section "Files" >> ModulePath "/usr/lib/xorg/modules/linux" >> ModulePath "/usr/lib/xorg/modules" >> EndSection >> >> Section "OutputClass" >> Identifier "nvidia" >> MatchDriver "nvidia-drm" >> Driver "nvidia" >> EndSection >> --- >> >> That seems to work for stable ... what about sid? >> >> >> Andreas > > Hmmm, this should work, but the NVidia glx module will always be loaded > for all screens by the xserver. This will break a multiseat system with > multiple gpu vendors and maybe other glvnd dispatch goodness. > > Is the following situation a possibility? We can consider such fancy setup for 396.xx and newer, since that will change a lot anyway. For 390.xx I want to have a version in sid that can be uploaded with minimal changes to stretch once the next CVE arrives ... > Stable -> nvidia-driver (up to version 390.xx in backports), compatible > with all versions of the xserver > This version is shipped with a separate Files section in > nvidia-drm-outputclass.conf > If xserver 1.20 is in backports, this version can be upgraded to match > the new Testing/Sid version > > Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 > -> nvidia-driver (version > 396.xx), xserver > 1.20 > These versions will have the ModulePath option in the OutputClass > section. (and we can drop the glx-alternative system) Nope, we have to keep glx-alternatives around as long as 340xx is still in the game. Andreas
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" EndSection --- That seems to work for stable ... what about sid? Andreas Hmmm, this should work, but the NVidia glx module will always be loaded for all screens by the xserver. This will break a multiseat system with multiple gpu vendors and maybe other glvnd dispatch goodness. Is the following situation a possibility? Stable -> nvidia-driver (up to version 390.xx in backports), compatible with all versions of the xserver This version is shipped with a separate Files section in nvidia-drm-outputclass.conf If xserver 1.20 is in backports, this version can be upgraded to match the new Testing/Sid version Testing and Sid -> nvidia-legacy-390xx-driver, xserver > 1.20 -> nvidia-driver (version > 396.xx), xserver > 1.20 These versions will have the ModulePath option in the OutputClass section. (and we can drop the glx-alternative system) --- Floris
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Well---I'm still picking up the pieces here. Not sure what happened, but that did not work for me & for some reason, I can't revert it back or boot the older 4.16-1. everything just hangs. I'm in my backup system, looking at the kernel logs. Last entry starts: Jun 23 21:22:52 debian kernel: [0.00] Linux version 4.16.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22) Jun 23 21:22:52 debian kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-2-amd64 root=UUID=c18c39f1-0e2c-4c89-a534-e3c8414bb273 ro cgroup_enable=memory swapaccount=1 elevator=noop nvidia-current.NVreg_EnablePCIeGen3=1 slab_common.usercopy_fallback=y Normal boot until GDM "should" come up, then I get: Jun 23 21:23:00 debian kernel: [ 28.992343] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 242 Jun 23 21:23:00 debian kernel: [ 29.383969] resource sanity check: requesting [mem 0x000c-0x000f], which spans more than PCI Bus :00 [mem 0x000c-0x000d window] Jun 23 21:23:00 debian kernel: [ 29.384003] caller _nv001169rm+0xe3/0x1d0 [nvidia] mapping multiple BARs Jun 23 21:23:02 debian kernel: [ 30.747951] show_signal_msg: 14 callbacks suppressed Jun 23 21:23:02 debian kernel: [ 30.747953] gnome-shell[1370]: segfault at 20 ip 7f2ee7714aed sp 7fff4654cb00 error 4 in libmutter-2.so.0.0.0[7f2ee7617000+165000] Last line repeats about 50 times with slightly different addresses [7f2ee7617000+165000] is a typical example--the 165000 stays constant. There is also a note about updating runlevels during this period. I get the same result with my older 4.16-1 kernel now...no combination of workaround(s) seem to have any effect. Thoughts welcome.
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Hi Dean, On 2018-06-24 01:34, Dean Loros wrote: > I can also confirm that: slab_common.usercopy_fallback=y works for > 4-16-2. I have: > > /etc/nvidia/current/nvidia-drm-outputclass.conf > with this content: > > Section "OutputClass" > Identifier "nvidia" > MatchDriver"nvidia-drm" > Driver "nvidia" > ModulePath "/usr/lib/xorg/modules/linux" > EndSection Could you try this nvidia-drm-outputclass.conf instead? It should do the same, but in a way compatible with both Xserver >= 1.20 and Xserver < 1.20. --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" EndSection --- Thanks Andreas
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
I can also confirm that: slab_common.usercopy_fallback=y works for 4-16-2. I have: /etc/nvidia/current/nvidia-drm-outputclass.conf with this content: Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" ModulePath "/usr/lib/xorg/modules/linux" EndSection also set in my system. I have looked at the nVidia bug report & it "seems" that according to one user: It seems to be fixed on 396.24. [1.040981] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 396.24 Thu Apr 26 00:10:09 PDT 2018 (using threaded interrupts) [1.041976] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 396.24 Wed Apr 25 23:54:18 PDT 2018 [1.049701] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 243 [1.050203] Linux agpgart interface v0.103 [1.058829] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver Kernel 4.16.8-1
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Am 22.06.2018 um 23:29 schrieb Luca Boccassi: On Fri, 2018-06-22 at 21:37 +0200, Andreas Beckmann wrote: On 2018-06-22 12:58, Holger Schröder wrote: The changes in /etc/nvidia/current/nvidia-drm-outputclass.conf solve the Problem and works. But after Kernelupdate to linux-image-4.16.0-2-amd64 (4.16.16-1) boot into a black Screen, 4.16.12-1 workd fine. Unrelated problem, just nasty to have two big ones at the same time. It might be possible to patch the module for the usercopy stack issue, but it's quite tricky, the folks at gr security seem to be patching the driver with the needed change: https://www.grsecurity.net/~paxguy1/nvidia-drivers-387.12-pax.patch But given the workaround seems to work fine I wouldn't bother and I'd let Nvidia sort it out. The workaround is to add to the cmdline: slab_common.usercopy_fallback=y Thanks, it works
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Fri, 2018-06-22 at 21:37 +0200, Andreas Beckmann wrote: > On 2018-06-22 12:58, Holger Schröder wrote: > > The changes in /etc/nvidia/current/nvidia-drm-outputclass.conf > > solve the > > Problem and works. > > > > But after Kernelupdate to linux-image-4.16.0-2-amd64 (4.16.16-1) > > boot > > into a black Screen, 4.16.12-1 workd fine. > > Unrelated problem, just nasty to have two big ones at the same time. It might be possible to patch the module for the usercopy stack issue, but it's quite tricky, the folks at gr security seem to be patching the driver with the needed change: https://www.grsecurity.net/~paxguy1/nvidia-drivers-387.12-pax.patch But given the workaround seems to work fine I wouldn't bother and I'd let Nvidia sort it out. The workaround is to add to the cmdline: slab_common.usercopy_fallback=y > On 2018-06-22 16:27, floris wrote: > > I don't expect this will work with a xserver less then 1.20, > > because the > > ModulePath option in an OutpuClass section is an unknown option. > > Confirmed. > > What about the following /etc/nvidia/current/nvidia-drm- > outputclass.conf > > --- > Section "Files" > ModulePath "/usr/lib/xorg/modules/linux" > ModulePath "/usr/lib/xorg/modules" > EndSection > > Section "OutputClass" > Identifier "nvidia" > MatchDriver"nvidia-drm" > Driver "nvidia" > EndSection > --- > > That seems to work for stable ... what about sid? > > > Andreas Tried on Sid and at least it doesn't break it - but note that I can't reproduce the original problem, so I can't be sure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On 2018-06-22 12:58, Holger Schröder wrote: > The changes in /etc/nvidia/current/nvidia-drm-outputclass.conf solve the > Problem and works. > > But after Kernelupdate to linux-image-4.16.0-2-amd64 (4.16.16-1) boot > into a black Screen, 4.16.12-1 workd fine. Unrelated problem, just nasty to have two big ones at the same time. On 2018-06-22 16:27, floris wrote: > I don't expect this will work with a xserver less then 1.20, because the > ModulePath option in an OutpuClass section is an unknown option. Confirmed. What about the following /etc/nvidia/current/nvidia-drm-outputclass.conf --- Section "Files" ModulePath "/usr/lib/xorg/modules/linux" ModulePath "/usr/lib/xorg/modules" EndSection Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" EndSection --- That seems to work for stable ... what about sid? Andreas
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
The changes in /etc/nvidia/current/nvidia-drm-outputclass.conf solve the Problem and works. But after Kernelupdate to linux-image-4.16.0-2-amd64 (4.16.16-1) boot into a black Screen, 4.16.12-1 workd fine. Same Problem like this Bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901932 Holger...
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On 2018-05-31 11:12, Luca Boccassi wrote: > On Thu, 2018-05-31 at 11:07 +0200, Peter De Wachter wrote: >>> Fortunately another user reported a possible alternative, if you >>> have >>> time could you please try to drop a nvidia.conf in >>> /usr/share/X11/xorg.conf.d with the following content: >>> >>> Section "OutputClass" >>> Identifier "Nvidia Modules" >>> MatchDriver "nvidia-drm" >>> Driver "nvidia" >>> Option "AllowEmptyInitialConfiguration" "true" >>> ModulePath "/usr/lib/nvidia" >>> EndSection Given that we already have /etc/nvidia/current/nvidia-drm-outputclass.conf with this content: Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" EndSection Does changing this to Section "OutputClass" Identifier "nvidia" MatchDriver"nvidia-drm" Driver "nvidia" ModulePath "/usr/lib/xorg/modules/linux" EndSection (and reverting any other workarounds applied to the module) fix the issue? (that should be the minimal amount of changes ...) Does this work with the xorg in stretch, too? (as in "it does not break the driver/xorg in stretch") (such that we hopefully don't have to handle stretch+buster differently) Andreas
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Thu, 2018-05-31 at 11:07 +0200, Peter De Wachter wrote: > > Fortunately another user reported a possible alternative, if you > > have > > time could you please try to drop a nvidia.conf in > > /usr/share/X11/xorg.conf.d with the following content: > > > > Section "OutputClass" > > Identifier "Nvidia Modules" > > MatchDriver "nvidia-drm" > > Driver "nvidia" > > Option "AllowEmptyInitialConfiguration" "true" > > ModulePath "/usr/lib/nvidia" > > EndSection > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900428 > > > > As before also restore the original libglx.so in modules/extension, > > and > > remove the Nvidia symlink altogether. > > Yes, that works. > > I noted that there was already a similar config file, > nvidia-drm-outputclass.conf, that also has a MatchDriver "nvidia-drm" > line. I don't know how X handles that: were they merged, or was one > of > them ignored? Not sure, I'll have a look > Also it looks like /usr/lib/nvidia might contain multiple > incompatible > libglx.so files: > xserver-xorg-video-nvidia: /usr/lib/nvidia/current/libglx.so > xserver-xorg-video-nvidia-legacy-304xx: /usr/lib/nvidia/legacy- > 304xx/libglx.so > xserver-xorg-video-nvidia-legacy-340xx: /usr/lib/nvidia/legacy- > 340xx/libglx.so > > I don't know if these packages can be installed together. If they > can, > there will be random failures again. > > Best regards,usual > Peter Yes, same problem with the recursive search - each series will point to its directory instead of /usr/lib/nvidia, to avoid that problem. Andreas, does adding this xorg file and removing the libglx.so registration sound like a good plan to you? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
> Fortunately another user reported a possible alternative, if you have > time could you please try to drop a nvidia.conf in > /usr/share/X11/xorg.conf.d with the following content: > > Section "OutputClass" > Identifier "Nvidia Modules" > MatchDriver "nvidia-drm" > Driver "nvidia" > Option "AllowEmptyInitialConfiguration" "true" > ModulePath "/usr/lib/nvidia" > EndSection > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900428 > > As before also restore the original libglx.so in modules/extension, and > remove the Nvidia symlink altogether. Yes, that works. I noted that there was already a similar config file, nvidia-drm-outputclass.conf, that also has a MatchDriver "nvidia-drm" line. I don't know how X handles that: were they merged, or was one of them ignored? Also it looks like /usr/lib/nvidia might contain multiple incompatible libglx.so files: xserver-xorg-video-nvidia: /usr/lib/nvidia/current/libglx.so xserver-xorg-video-nvidia-legacy-304xx: /usr/lib/nvidia/legacy-304xx/libglx.so xserver-xorg-video-nvidia-legacy-340xx: /usr/lib/nvidia/legacy-340xx/libglx.so I don't know if these packages can be installed together. If they can, there will be random failures again. Best regards, Peter
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Control: reassign -1 nvidia-driver
On Thu, 2018-05-31 at 00:12 +0200, Peter De Wachter wrote:
> On Wed, May 30, 2018 at 10:54 PM, Luca Boccassi
> wrote:
> > Given there have been multiple reports, I'll upload a new version
> > of
> > glx-alternatives that moves the module redirection from
> > modules/linux
> > to modules/drivers (where there is no clash).
> >
> > Before I do that, given you had the issue and moving the module
> > fixes
> > it, could you please double check that moving the symlink from
> > modules/linux to modules/drivers (NOT modules/extensions, and
> > putting
> > back what was there) doesn't cause more problems?
> >
> > Still not sure why my Sid installation was working just fine...
>
> No, that doesn't work for me.
>
> Check xorg-server-1.20.0/hw/xfree86/loader/loadmod.c. It's some very
> confused code. There's a friendly-looking array:
>
> /* Standard set of module subdirectories to search, in order of
> preference */
> static const char *stdSubdirs[] = {
> "",
> "input/",
> "drivers/",
> "extensions/",
> NULL
> };
>
> But that comment is a lie. The FindModulesInSubDir() function
> recurses
> in subdirectories! So the loader will start with the first entry of
> that array, but it will search recursively and find either
> extensions/libglx.so or linux/libglx.so depending on readdir()
> order... This is why this bug occurred only on some systems and not
> on
> others. It also means that your proposed fix won't work.
>
> In xserver 1.19, the linux/ subdir was _prepended_ to the subdir
> list,
> so there the nvidia libglx.so was reliably selected.
>
> I don't know how to fix this without patching the xserver code. Maybe
> it's possible to manipulate the search path with an xorg.conf
> fragment?
>
> Best regards,
> Peter
..lol - all of this did sound strangely familiar. I went rummaging in
my git directory, and look what I've found...
https://patchwork.freedesktop.org/patch/86051/
Of course that was duly ignored.
I don't expect they'll give a damn this time around either, despite the
obvious regression, so I won't even try - and we can't ask the
overworked Xorg maintainers to keep out of tree patches just for non-
free drivers.
Fortunately another user reported a possible alternative, if you have
time could you please try to drop a nvidia.conf in
/usr/share/X11/xorg.conf.d with the following content:
Section "OutputClass"
Identifier "Nvidia Modules"
MatchDriver "nvidia-drm"
Driver "nvidia"
Option "AllowEmptyInitialConfiguration" "true"
ModulePath "/usr/lib/nvidia"
EndSection
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900428
As before also restore the original libglx.so in modules/extension, and
remove the Nvidia symlink altogether.
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Processed: Re: Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Processing control commands: > reassign -1 nvidia-driver Bug #900248 [glx-alternative-nvidia] nvidia-driver: update to 390.59 breaks direct rendering Bug #900264 [glx-alternative-nvidia] bzflag is slow since nvidia-graphics-drivers 390.59-1 Bug #900378 [glx-alternative-nvidia] glx-alternative-nvidia: Fails to enable proprietary accelerated OpenGL and does not report the problem Bug reassigned from package 'glx-alternative-nvidia' to 'nvidia-driver'. Bug reassigned from package 'glx-alternative-nvidia' to 'nvidia-driver'. Bug reassigned from package 'glx-alternative-nvidia' to 'nvidia-driver'. Ignoring request to alter found versions of bug #900248 to the same values previously set Ignoring request to alter found versions of bug #900264 to the same values previously set Ignoring request to alter found versions of bug #900378 to the same values previously set Ignoring request to alter fixed versions of bug #900248 to the same values previously set Ignoring request to alter fixed versions of bug #900264 to the same values previously set Ignoring request to alter fixed versions of bug #900378 to the same values previously set -- 900248: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900248 900264: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900264 900378: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900378 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Wed, May 30, 2018 at 10:54 PM, Luca Boccassi wrote:
> Given there have been multiple reports, I'll upload a new version of
> glx-alternatives that moves the module redirection from modules/linux
> to modules/drivers (where there is no clash).
>
> Before I do that, given you had the issue and moving the module fixes
> it, could you please double check that moving the symlink from
> modules/linux to modules/drivers (NOT modules/extensions, and putting
> back what was there) doesn't cause more problems?
>
> Still not sure why my Sid installation was working just fine...
No, that doesn't work for me.
Check xorg-server-1.20.0/hw/xfree86/loader/loadmod.c. It's some very
confused code. There's a friendly-looking array:
/* Standard set of module subdirectories to search, in order of preference */
static const char *stdSubdirs[] = {
"",
"input/",
"drivers/",
"extensions/",
NULL
};
But that comment is a lie. The FindModulesInSubDir() function recurses
in subdirectories! So the loader will start with the first entry of
that array, but it will search recursively and find either
extensions/libglx.so or linux/libglx.so depending on readdir()
order... This is why this bug occurred only on some systems and not on
others. It also means that your proposed fix won't work.
In xserver 1.19, the linux/ subdir was _prepended_ to the subdir list,
so there the nvidia libglx.so was reliably selected.
I don't know how to fix this without patching the xserver code. Maybe
it's possible to manipulate the search path with an xorg.conf
fragment?
Best regards,
Peter
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Control: reassign -1 glx-alternative-nvidia Control: affects -1 nvidia-driver On Wed, 2018-05-30 at 01:05 +0200, Peter De Wachter wrote: > Hello Luca, > > [Cc'ing bugs this time] > > > I don't think so - I still can't reproduce the problem despite > > that. It > > should all go through the glvnd blobs. > > OK. I don't know what I can do to help. This affected both of my > computers with nvidia graphics, and for now I "fixed" it by copying > the libglx.so to the other directory. > > > Do you have all of the following installed: > > I have most of them but not all. See the attached file. Given there have been multiple reports, I'll upload a new version of glx-alternatives that moves the module redirection from modules/linux to modules/drivers (where there is no clash). Before I do that, given you had the issue and moving the module fixes it, could you please double check that moving the symlink from modules/linux to modules/drivers (NOT modules/extensions, and putting back what was there) doesn't cause more problems? Still not sure why my Sid installation was working just fine... -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Processing control commands: > reassign -1 glx-alternative-nvidia Bug #900248 [nvidia-driver] nvidia-driver: update to 390.59 breaks direct rendering Bug #900264 [nvidia-driver] bzflag is slow since nvidia-graphics-drivers 390.59-1 Bug #900378 [nvidia-driver] glx-alternative-nvidia: Fails to enable proprietary accelerated OpenGL and does not report the problem Bug reassigned from package 'nvidia-driver' to 'glx-alternative-nvidia'. Bug reassigned from package 'nvidia-driver' to 'glx-alternative-nvidia'. Bug reassigned from package 'nvidia-driver' to 'glx-alternative-nvidia'. No longer marked as found in versions nvidia-graphics-drivers/390.59-1. No longer marked as found in versions nvidia-graphics-drivers/390.59-1. No longer marked as found in versions nvidia-graphics-drivers/390.59-1. Ignoring request to alter fixed versions of bug #900248 to the same values previously set Ignoring request to alter fixed versions of bug #900264 to the same values previously set Ignoring request to alter fixed versions of bug #900378 to the same values previously set > affects -1 nvidia-driver Bug #900248 [glx-alternative-nvidia] nvidia-driver: update to 390.59 breaks direct rendering Bug #900264 [glx-alternative-nvidia] bzflag is slow since nvidia-graphics-drivers 390.59-1 Bug #900378 [glx-alternative-nvidia] glx-alternative-nvidia: Fails to enable proprietary accelerated OpenGL and does not report the problem Added indication that 900248 affects nvidia-driver Added indication that 900264 affects nvidia-driver Added indication that 900378 affects nvidia-driver -- 900248: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900248 900264: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900264 900378: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900378 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Version: 390.59-1 Followup-For: Bug #900248 Hi, I can confirm that the above workaround works correctly for me. Marc
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Hi Luca, > I don't think so - I still can't reproduce the problem despite that. It > should all go through the glvnd blobs. > > Do you have all of the following installed: Here I have again upgraded and have the same packages installed as you: ii libegl-nvidia0:amd64 390.59-1amd64 NVIDIA binary EGL library ii libegl1:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- legacy GL support ii libgl1-nvidia-glvnd-glx:amd64 390.59-1amd64 NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgles-nvidia2:amd64 390.59-1amd64 NVIDIA binary OpenGL|ES 2.x library ii libgles2:amd641.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library ii libglx-nvidia0:amd64 390.59-1amd64 NVIDIA binary GLX library ii libglx0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- GLX support ii libnvidia-cfg1:amd64 390.59-1amd64 NVIDIA binary OpenGL/GLX configuration library ii libnvidia-egl-wayland1:amd64 390.59-1amd64 NVIDIA binary Wayland EGL external platform library ii libnvidia-eglcore:amd64 390.59-1amd64 NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1amd64 NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1amd64 NVIDIA Management Library (NVML) runtime library ii libopengl0:amd64 1.0.0+git20180308-2 amd64 Vendor neutral GL dispatch library -- OpenGL support ii nvidia-alternative390.59-1amd64 allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1amd64 NVIDIA metapackage ii nvidia-driver-bin 390.59-1amd64 NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1amd64 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1amd64 NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1amd64 NVIDIA EGL installable client driver (ICD) ii nvidia-egl-wayland-common 390.59-1amd64 NVIDIA binary Wayland EGL external platform - common files ii nvidia-egl-wayland-icd:amd64 390.59-1amd64 NVIDIA Wayland EGL external platform library (ICD) ii nvidia-kernel-dkms390.59-1amd64 NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1amd64 NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1amd64 check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1amd64 Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg-video-nvidia 390.59-1amd64 NVIDIA binary Xorg driver but I am still running on software rendering: $ glxinfo | grep OpenGL OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) ... Doing the same copy game of glx.so from linux to extensions dir I get it working: $ glxinfo | grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 ... Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Hello Luca, [Cc'ing bugs this time] > I don't think so - I still can't reproduce the problem despite that. It > should all go through the glvnd blobs. OK. I don't know what I can do to help. This affected both of my computers with nvidia graphics, and for now I "fixed" it by copying the libglx.so to the other directory. > Do you have all of the following installed: I have most of them but not all. See the attached file. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===--== ii libegl-nvidia0:amd64 390.59-1amd64NVIDIA binary EGL library ii libegl-nvidia0:i386 390.59-1i386 NVIDIA binary EGL library ii libegl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- EGL support ii libegl1:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- legacy GL support ii libgl1:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- legacy GL support ii libgl1-nvidia-glvnd-glx:amd64 390.59-1amd64NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgl1-nvidia-glvnd-glx:i386 390.59-1i386 NVIDIA binary OpenGL/GLX library (GLVND variant) un libgles-nvidia2(no description available) ii libgles2:amd641.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library ii libglvnd0:i3861.0.0+git20180308-2 i386 Vendor neutral GL dispatch library ii libglx-nvidia0:amd64 390.59-1amd64NVIDIA binary GLX library ii libglx-nvidia0:i386 390.59-1i386 NVIDIA binary GLX library ii libglx0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLX support ii libglx0:i386 1.0.0+git20180308-2 i386 Vendor neutral GL dispatch library -- GLX support un libnvidia-cfg1 (no description available) ii libnvidia-eglcore:amd64 390.59-1amd64NVIDIA binary EGL core libraries ii libnvidia-eglcore:i386390.59-1i386 NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1amd64NVIDIA binary OpenGL/GLX core libraries ii libnvidia-glcore:i386 390.59-1i386 NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1amd64NVIDIA Management Library (NVML) runtime library ii libopengl0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- OpenGL support ii nvidia-alternative390.59-1amd64allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1amd64NVIDIA metapackage ii nvidia-driver-bin 390.59-1amd64NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-driver-libs:i386 390.59-1i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1amd64NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1amd64NVIDIA EGL installable client driver (ICD) ii nvidia-egl-icd:i386 390.59-1i386 NVIDIA EGL installable client driver (ICD) un nvidia-egl-wayland-icd (no description available) ii nvidia-kernel-dkms390.59-1amd64NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1amd64NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1amd64check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1amd64Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg 1:7.7+19amd64X.Org X server ii xserver-xorg-core 2:1.20.0-2 amd64Xorg X server - core server ii xserver-xorg-video-nvidia 390.59-1amd64NVIDIA binary Xorg driver dpkg-query: no
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Tue, 2018-05-29 at 01:20 +0200, Peter De Wachter wrote: > Package: nvidia-driver > Followup-For: Bug #900248 > > I think this bug is caused by a change in xserver 1.20. The nvidia > libglx.so gets installed in /usr/lib/xorg/modules/linux/, but this > directory has been removed from X's search path. As a result X only > finds the default libglx.so in /usr/lib/xorg/modules/extensions/. > See this commit: > https://cgit.freedesktop.org/xorg/xserver/commit/?id=97bd6e4536765168 > 91250389ec0fd695c110087c > > Best regards, > Peter I don't think so - I still can't reproduce the problem despite that. It should all go through the glvnd blobs. Do you have all of the following installed: ii libegl-nvidia0:amd64 390.59-1 amd64NVIDIA binary EGL library ii libgl1-nvidia-glvnd-glx:amd64 390.59-1 amd64NVIDIA binary OpenGL/GLX library (GLVND variant) ii libgles-nvidia2:amd64 390.59-1 amd64NVIDIA binary OpenGL|ES 2.x library ii libglx-nvidia0:amd64 390.59-1 amd64NVIDIA binary GLX library ii libnvidia-cfg1:amd64 390.59-1 amd64NVIDIA binary OpenGL/GLX configuration library ii libnvidia-egl-wayland1:amd64 390.59-1 amd64NVIDIA binary Wayland EGL external platform library ii libnvidia-eglcore:amd64 390.59-1 amd64NVIDIA binary EGL core libraries ii libnvidia-glcore:amd64390.59-1 amd64NVIDIA binary OpenGL/GLX core libraries ii libnvidia-ml1:amd64 390.59-1 amd64NVIDIA Management Library (NVML) runtime library ii nvidia-alternative390.59-1 amd64allows the selection of NVIDIA as GLX provider ii nvidia-driver 390.59-1 amd64NVIDIA metapackage ii nvidia-driver-bin 390.59-1 amd64NVIDIA driver support binaries ii nvidia-driver-libs:amd64 390.59-1 amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) ii nvidia-egl-common 390.59-1 amd64NVIDIA binary EGL driver - common files ii nvidia-egl-icd:amd64 390.59-1 amd64NVIDIA EGL installable client driver (ICD) ii nvidia-egl-wayland-common 390.59-1 amd64NVIDIA binary Wayland EGL external platform - common files ii nvidia-egl-wayland-icd:amd64 390.59-1 amd64NVIDIA Wayland EGL external platform library (ICD) ii nvidia-kernel-dkms390.59-1 amd64NVIDIA binary kernel module DKMS source ii nvidia-kernel-support 390.59-1 amd64NVIDIA binary kernel module support files ii nvidia-legacy-check 390.59-1 amd64check for NVIDIA GPUs requiring a legacy driver ii nvidia-vdpau-driver:amd64 390.59-1 amd64Video Decode and Presentation API for Unix - NVIDIA driver ii xserver-xorg-video-nvidia 390.59-1 amd64NVIDIA binary Xorg driver ii libegl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- EGL support ii libgl1:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- legacy GL support ii libgles2:amd641.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLES support ii libglvnd0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library ii libglx0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- GLX support ii libopengl0:amd64 1.0.0+git20180308-2 amd64Vendor neutral GL dispatch library -- OpenGL support -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Followup-For: Bug #900248 I think this bug is caused by a change in xserver 1.20. The nvidia libglx.so gets installed in /usr/lib/xorg/modules/linux/, but this directory has been removed from X's search path. As a result X only finds the default libglx.so in /usr/lib/xorg/modules/extensions/. See this commit: https://cgit.freedesktop.org/xorg/xserver/commit/?id=97bd6e453676516891250389ec0fd695c110087c Best regards, Peter
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Mon, 28 May 2018 21:32:38 +0900 Norbert Preining wrote: > I downgraded all the nvidia stuff to 390.48-3 and with the same > kernel (and the same error message of the kernel) all works back fine as > normal: I tried to do that, and wound up not being able to install any of the nvidia stuff. So for clarity: Did you also downgrade the X server? > My suspect is that (from aptitude.log): > [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3 > [REMOVE] libgles1-glvnd-nvidia:i386 390.48-3 > two package which seem to be not available or installable in sid at the > moment. That doesn't show up on my system, so seems unlikely to be the culprit. With greetings, Herbert Snorrason
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Version: 390.59-1 Followup-For: Bug #900248 I confirm this problem. I got it at upgrade from sid to sid, unfortunately, I lost exact version change. Now I can reproduce it with upgrade between testing and sid. 390.48-3 is working 390.59-1 is broken 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 660 Ti] [10de:1183] (rev a1) (prog-if 00 [VGA controller]) ... Kernel driver in use: nvidia Kernel modules: nvidia -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nvidia-driver depends on: ii nvidia-alternative 390.59-1 ii nvidia-driver-bin 390.59-1 ii nvidia-driver-libs 390.59-1 ii nvidia-installer-cleanup 20151021+8 ii nvidia-kernel-dkms [nvidia-kernel-390.59] 390.59-1 ii nvidia-legacy-check390.59-1 ii nvidia-support 20151021+8 ii nvidia-vdpau-driver390.59-1 ii xserver-xorg-video-nvidia 390.59-1 Versions of packages nvidia-driver recommends: ii nvidia-persistenced 390.25-1 ii nvidia-settings 390.48-2 Versions of packages nvidia-driver suggests: ii nvidia-kernel-dkms 390.59-1 Versions of packages nvidia-driver-libs:amd64 depends on: ii libgl1-nvidia-glvnd-glx 390.59-1 ii nvidia-egl-icd 390.59-1 Versions of packages nvidia-driver-libs:amd64 recommends: ii libgles-nvidia2 390.59-1 ii libglx-nvidia0 390.59-1 ii libnvidia-cfg1 390.59-1 ii libopengl0 1.0.0+git20180308-2 pn nvidia-driver-libs-i386 ii nvidia-egl-wayland-icd 390.59-1 ii nvidia-vulkan-icd390.59-1 Versions of packages xserver-xorg-video-nvidia depends on: ii libc6 2.27-3 ii libnvidia-glcore 390.59-1 ii nvidia-alternative 390.59-1 ii nvidia-installer-cleanup 20151021+8 ii nvidia-legacy-check390.59-1 ii nvidia-support 20151021+8 ii xserver-xorg-core [xorg-video-abi-24] 2:1.20.0-2 Versions of packages xserver-xorg-video-nvidia recommends: ii nvidia-kernel-dkms [nvidia-kernel-390.59] 390.59-1 ii nvidia-settings390.48-2 ii nvidia-vdpau-driver390.59-1 Versions of packages xserver-xorg-video-nvidia suggests: ii nvidia-kernel-dkms 390.59-1 Versions of packages nvidia-alternative depends on: ii dpkg1.19.0.5+b1 ii glx-alternative-nvidia 0.8.3 ii nvidia-legacy-check 390.59-1 Versions of packages nvidia-kernel-dkms depends on: ii dkms 2.3-3 ii nvidia-installer-cleanup 20151021+8 ii nvidia-kernel-support [nvidia-kernel-support--v1] 390.59-1 nvidia-kernel-dkms recommends no packages. Versions of packages glx-alternative-nvidia depends on: ii dpkg 1.19.0.5+b1 ii glx-alternative-mesa 0.8.3 ii glx-diversions0.8.3 ii update-glx0.8.3 glx-alternative-nvidia suggests no packages. Versions of packages xserver-xorg-video-intel depends on: ii libc6 2.27-3 ii libdrm-intel1 2.4.92-1 ii libdrm22.4.92-1 ii libpciaccess0 0.14-1 ii libpixman-1-0 0.34.0-2 ii libudev1 238-5 ii libx11-6 2:1.6.5-1 ii libx11-xcb12:1.6.5-1 ii libxcb-dri2-0 1.13-1 ii libxcb-dri3-0 1.13-1 ii libxcb-sync1 1.13-1 ii libxcb-util0 0.3.8-3+b2 ii libxcb11.13-1 ii libxcursor11:1.1.15-1 ii libxdamage11:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxinerama1 2:1.1.3-1+b3 ii libxrandr2 2:1.5.1-1 ii libxrender11:0.9.10-1 ii libxshmfence1 1.3-1 ii libxss11:1.2.2-1+b2 ii libxtst6 2:1.2.3-1 ii libxv1 2:1.0.11-1 ii libxvmc1 2:1.0.10-1 ii
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Version: 390.59-1 Followup-For: Bug #900248 Dear Maintainer, I have the exact same issue. I've spent few hours trying to install/reinstall all nvidia package until I've found this bug. I've also tried to create package from the 396 svn version, but was not able to create all i386 packages. Happy to test anything if it can help in any way Marc -- Package-specific info: uname -a: Linux arrakis 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux /proc/version: Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.59 Wed May 9 22:33:42 PDT 2018 GCC version: gcc version 7.3.0 (Debian 7.3.0-19) lspci 'display controller [030?]': 09:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK104 [GeForce GTX 670] [10de:1189] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. GK104 [GeForce GTX 670] [1043:841b] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 May 28 08:23 /dev/dri/card0 crw-rw+ 1 root video 226, 128 May 28 08:23 /dev/dri/renderD128 crw-rw-rw- 1 root root 195, 254 May 28 08:23 /dev/nvidia-modeset crw-rw-rw- 1 root root 195, 0 May 28 08:23 /dev/nvidia0 crw-rw-rw- 1 root root 195, 255 May 28 08:23 /dev/nvidiactl /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 May 28 08:23 pci-:09:00.0-card -> ../card0 lrwxrwxrwx 1 root root 13 May 28 08:23 pci-:09:00.0-render -> ../renderD128 video:x:44:dkm OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 May 28 20:42 /etc/alternatives/glx -> /usr/lib/nvidia lrwxrwxrwx 1 root root 47 May 27 22:29 /etc/alternatives/glx--libEGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so lrwxrwxrwx 1 root root 49 May 27 22:29 /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so lrwxrwxrwx 1 root root 49 May 28 20:42 /etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root 51 May 28 20:42 /etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root 46 May 27 22:29 /etc/alternatives/glx--libGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 46 May 27 22:29 /etc/alternatives/glx--libGL.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so lrwxrwxrwx 1 root root 48 May 27 22:29 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 48 May 27 22:29 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 48 May 28 20:42 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 48 May 28 20:42 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 May 28 20:42 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 May 28 20:42 /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 lrwxrwxrwx 1 root root 50 May 27 22:29 /etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 50 May 27 22:29 /etc/alternatives/glx--libGLESv2.so-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 52 May 27 22:29 /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 52 May 27 22:29 /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so lrwxrwxrwx 1 root root 52 May 28 20:42 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 52 May 28 20:42 /etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 May 28 20:42 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 lrwxrwxrwx 1 root root 54 May 28 20:42 /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu ->
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Mon, 2018-05-28 at 21:32 +0900, Norbert Preining wrote: > > Looks like the kernel module fails to load: > > No, that is the usual artifact with newer kernels, this is well > known. I > am running the latest stable kernels normally, currently 4.16.11 > (actually .12 is out), and that has been the case since the 4.15 > series > (AFAIR). I downgraded all the nvidia stuff to 390.48-3 and with the > same > kernel (and the same error message of the kernel) all works back fine > as > normal: > > [ 13.240792] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready > [ 13.265609] nvidia-modeset: Allocated GPU:0 (GPU-ae45f56a-df50- > cbc7-737d-a20dd48d7bdd) @ PCI::01:00.0 > [ 13.409365] [ cut here ] > [ 13.409369] Bad or missing usercopy whitelist? Kernel memory > exposure attempt detected from SLAB object 'nvidia_stack_cache' > (offset 11440, size 3)! > [ 13.409375] WARNING: CPU: 2 PID: 1168 at mm/usercopy.c:81 > usercopy_warn+0x7d/0xa0 > ... > > # glxinfo | grep OpenGL > ... > OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 > OpenGL core profile version string: 4.6.0 NVIDIA 390.48 > ... > > My suspect is that (from aptitude.log): > [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3 > [REMOVE] libgles1-glvnd-nvidia:i386 390.48-3 > two package which seem to be not available or installable in sid at > the > moment. > > Best > > Norbert Nah gles1 is deprecated - I don't have it either on my sid+gnome installation, and yet everything works just fine. Have you done a selective upgrade by any chance? Are mesa and xorg all up to date? Is anything pinned? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
I am also having this issue. dean@debian:~$ glxinfo | grep OpenGL OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.0.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 18.0.4 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.0.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: Running the most current kernel--had no problems until the update to 390.59-1
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
> Looks like the kernel module fails to load: No, that is the usual artifact with newer kernels, this is well known. I am running the latest stable kernels normally, currently 4.16.11 (actually .12 is out), and that has been the case since the 4.15 series (AFAIR). I downgraded all the nvidia stuff to 390.48-3 and with the same kernel (and the same error message of the kernel) all works back fine as normal: [ 13.240792] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready [ 13.265609] nvidia-modeset: Allocated GPU:0 (GPU-ae45f56a-df50-cbc7-737d-a20dd48d7bdd) @ PCI::01:00.0 [ 13.409365] [ cut here ] [ 13.409369] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'nvidia_stack_cache' (offset 11440, size 3)! [ 13.409375] WARNING: CPU: 2 PID: 1168 at mm/usercopy.c:81 usercopy_warn+0x7d/0xa0 ... # glxinfo | grep OpenGL ... OpenGL renderer string: GeForce GTX 1050 Ti/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 390.48 ... My suspect is that (from aptitude.log): [REMOVE] libgles1-glvnd-nvidia:amd64 390.48-3 [REMOVE] libgles1-glvnd-nvidia:i386 390.48-3 two package which seem to be not available or installable in sid at the moment. Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. +JAIST +TeX Live +Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
On Mon, 2018-05-28 at 11:54 +0900, Norbert Preining wrote: > Package: nvidia-driver > Version: 390.59-1 > Severity: grave > Justification: renders package unusable > > Update to the current version in sid breaks direct rendering, my > system now uses the software pipe: > $ glxinfo | grep OpenGL > ... > OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) > ... > > Looking at the Xorg.0.log I see > [ 12.045] (EE) NVIDIA(0): Failed to initialize the GLX module; > please check in your X > [ 12.045] (EE) NVIDIA(0): log file that the GLX module has > been loaded in your X > [ 12.045] (EE) NVIDIA(0): server, and that the module is the > NVIDIA GLX module. If > [ 12.045] (EE) NVIDIA(0): you continue to encounter problems, > Please try > [ 12.045] (EE) NVIDIA(0): reinstalling the NVIDIA driver. > > So then I did as root > # # update-glx --config nvidia > There is only one alternative in link group nvidia (providing > /usr/lib/nvidia/nvidia): /usr/lib/nvidia/current > Nothing to configure. > Processing triggers for glx-alternative-nvidia (0.8.3) ... > Processing triggers for update-glx (0.8.3) ... > Processing triggers for glx-alternative-nvidia (0.8.3) ... > Processing triggers for libc-bin (2.27-3) ... > Processing triggers for initramfs-tools (0.130) ... > update-initramfs: Generating /boot/initrd.img-4.16.11 > # > > and even after reboot nothing has changed. > > Best > > Norbert Looks like the kernel module fails to load: [ 12.697265] nvidia-modeset: Allocated GPU:0 (GPU-ae45f56a-df50-cbc7-737d-a20dd48d7bdd) @ PCI::01:00.0 [ 12.843050] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'nvidia_stack_cache' (offset 11440, size 3)! [ 12.843056] Modules linked in: ip6table_filter ip6_tables xt_conntrack devlink tun iptable_filter nf_nat nf_conntrack br_netfilter bridge stp llc pci_stub overlay vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) scsi_transport_iscsi joydev binfmt_misc x86_pkg_temp_thermal kvm_intel uvcvideo videobuf2_vmalloc hid_generic videobuf2_memops kvm videobuf2_v4l2 irqbypass videobuf2_common crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_usb_audio videodev pcbc snd_usbmidi_lib media snd_rawmidi usbhid hid aesni_intel crypto_simd glue_helper cryptd serio_raw pcspkr iTCO_wdt mxm_wmi iTCO_vendor_support mei_me sg intel_pch_thermal mei acpi_pad evdev ext4 crc16 mbcache jbd2 fscrypto nvidia_drm(PO) drm_kms_helper drm loop nvidia_modeset(PO) nvidia(PO) ipmi_devintf ipmi_msghandler i2c_dev sunrpc parport_pc [ 12.843186] os_memcpy_to_user+0x21/0x40 [nvidia] [ 12.843279] _nv009383rm+0xbf/0xe0 [nvidia] [ 12.843358] ? _nv028084rm+0x79/0x90 [nvidia] [ 12.843434] ? _nv028084rm+0x55/0x90 [nvidia] [ 12.843506] ? _nv013694rm+0xee/0x100 [nvidia] [ 12.843581] ? _nv015342rm+0x154/0x270 [nvidia] [ 12.843667] ? _nv008316rm+0x134/0x1a0 [nvidia] [ 12.843751] ? _nv008295rm+0x29c/0x2b0 [nvidia] [ 12.843834] ? _nv001072rm+0xe/0x20 [nvidia] [ 12.843921] ? _nv007322rm+0xd8/0x100 [nvidia] [ 12.844006] ? _nv001171rm+0x627/0x830 [nvidia] [ 12.844090] ? rm_ioctl+0x73/0x100 [nvidia] [ 12.844136] ? nvidia_ioctl+0x573/0x720 [nvidia] [ 12.844177] ? nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia] There's a new kernel version in sid, could you please try with that? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering
Package: nvidia-driver Version: 390.59-1 Severity: grave Justification: renders package unusable Update to the current version in sid breaks direct rendering, my system now uses the software pipe: $ glxinfo | grep OpenGL ... OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) ... Looking at the Xorg.0.log I see [12.045] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X [12.045] (EE) NVIDIA(0): log file that the GLX module has been loaded in your X [12.045] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX module. If [12.045] (EE) NVIDIA(0): you continue to encounter problems, Please try [12.045] (EE) NVIDIA(0): reinstalling the NVIDIA driver. So then I did as root # # update-glx --config nvidia There is only one alternative in link group nvidia (providing /usr/lib/nvidia/nvidia): /usr/lib/nvidia/current Nothing to configure. Processing triggers for glx-alternative-nvidia (0.8.3) ... Processing triggers for update-glx (0.8.3) ... Processing triggers for glx-alternative-nvidia (0.8.3) ... Processing triggers for libc-bin (2.27-3) ... Processing triggers for initramfs-tools (0.130) ... update-initramfs: Generating /boot/initrd.img-4.16.11 # and even after reboot nothing has changed. Best Norbert -- Package-specific info: uname -a: Linux bulldog 4.16.11 #50 SMP Thu May 24 12:35:27 JST 2018 x86_64 GNU/Linux /proc/version: Linux version 4.16.11 (norbert@bulldog) (gcc version 7.3.0 (Debian 7.3.0-19)) #50 SMP Thu May 24 12:35:27 JST 2018 /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.59 Wed May 9 22:33:42 PDT 2018 GCC version: gcc version 7.3.0 (Debian 7.3.0-19) lspci 'display controller [030?]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:11bf] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: nvidia Kernel modules: nvidia dmesg: [0.909202] pci :01:00.0: vgaarb: setting as boot VGA device [0.909202] pci :01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.909202] pci :01:00.0: vgaarb: bridge control possible [0.909202] vgaarb: loaded [1.309924] fb0: EFI VGA frame buffer device [1.470133] Linux agpgart interface v0.103 [1.911353] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [2.728879] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input14 [2.730912] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input15 [2.733010] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input16 [3.419570] nvidia: loading out-of-tree module taints kernel. [3.420013] nvidia: module license 'NVIDIA' taints kernel. [3.429869] nvidia-nvlink: Nvlink Core is being initialized, major device number 245 [3.430493] nvidia :01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [3.430987] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 390.59 Wed May 9 22:33:42 PDT 2018 (using threaded interrupts) [3.463770] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.59 Wed May 9 21:59:27 PDT 2018 [3.486333] [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver [3.486813] [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on minor 0 [ 12.697265] nvidia-modeset: Allocated GPU:0 (GPU-ae45f56a-df50-cbc7-737d-a20dd48d7bdd) @ PCI::01:00.0 [ 12.843050] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'nvidia_stack_cache' (offset 11440, size 3)! [ 12.843056] Modules linked in: ip6table_filter ip6_tables xt_conntrack devlink tun iptable_filter nf_nat nf_conntrack br_netfilter bridge stp llc pci_stub overlay vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) scsi_transport_iscsi joydev binfmt_misc x86_pkg_temp_thermal kvm_intel uvcvideo videobuf2_vmalloc hid_generic videobuf2_memops kvm videobuf2_v4l2 irqbypass videobuf2_common crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_usb_audio videodev pcbc snd_usbmidi_lib media snd_rawmidi usbhid hid aesni_intel crypto_simd glue_helper cryptd serio_raw pcspkr iTCO_wdt mxm_wmi iTCO_vendor_support mei_me sg intel_pch_thermal mei acpi_pad evdev ext4 crc16 mbcache jbd2 fscrypto nvidia_drm(PO) drm_kms_helper drm loop nvidia_modeset(PO) nvidia(PO) ipmi_devintf ipmi_msghandler i2c_dev sunrpc parport_pc [ 12.843186] os_memcpy_to_user+0x21/0x40 [nvidia] [ 12.843279] _nv009383rm+0xbf/0xe0 [nvidia] [ 12.843358] ? _nv028084rm+0x79/0x90 [nvidia] [
