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/
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 "/
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"
>> EndSect
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"
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: [
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"nvid
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/l
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
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
> > int
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
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
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:
>>>
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"
> > Ident
> 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"
>
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
> > mod
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 mo
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
Package: nvidia-driver
Version: 390.59-1
Followup-For: Bug #900248
Hi,
I can confirm that the above workaround works correctly for me.
Marc
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-1
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.s
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 p
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/mo
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 f
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
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 th
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 co
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 profil
> 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
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
>
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
30 matches
Mail list logo
