Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Luca Boccassi]

On Wed, 2017-02-22 at 12:50 +0100, Andreas Beckmann wrote:
> On 2017-02-22 11:29, Luca Boccassi wrote:
> > Ok I managed to fix everything that was trying to load nvidia
> > modules.
> > 
> > Now booting with nouveau, I can't actually manage to reproduce the
> > stale /proc/driver/nvidia with any series - tried 304, 340 and 378.
> > Not
> > sure what's going on...
> 
> What are the kernel messages you get when loading the modules? Try
> to 
> load the module a second time after it had failed to load ...
> The problem should be reproducible at least with 340 as in the
> archive 
> (and should be fixed in svn).
> Anything 361+ should not have the problem any more.
> 
> Let me see if I can find my kernel log entries ... yep, that's 
> * try to load the module -> nouveau already clained our device
> * try to load the module again -> proc_dir_entry 'driver/nvidia'
> already registered
> * access /proc/driver/nvidia -> OOPS
> (with jessie's kernel)
> 
> [...]
> Feb 10 21:39:53 t530 kernel: [6.084133] [drm] Initialized nouveau
> 1.1.2 20120801 for :01:00.0 on minor 1
> Feb 10 21:39:53 t530 kernel: [6.123206] nvidia: module license
> 'NVIDIA' taints kernel.
> Feb 10 21:39:53 t530 kernel: [6.123210] Disabling lock debugging
> due to kernel taint
> Feb 10 21:39:53 t530 kernel: [6.132582] NVRM: The NVIDIA probe
> routine was not called for 1 device(s).
> Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: This can occur when
> a driver such as: 
> Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: nouveau, rivafb,
> nvidiafb or rivatv 
> Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: was loaded and
> obtained ownership of the NVIDIA device(s).
> Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: Try unloading the
> conflicting kernel module (and/or
> Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: reconfigure your
> kernel without the conflicting
> Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: driver(s)), then
> try loading the NVIDIA kernel module
> Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: again.
> Feb 10 21:39:53 t530 kernel: [6.132590] NVRM: No NVIDIA graphics
> adapter probed!
> Feb 10 21:39:53 t530 kernel: [6.132591] [drm] Module unloaded
> [...]
> Feb 10 21:40:12 t530 kernel: [   28.064190] [ cut here ]-
> ---
> Feb 10 21:40:12 t530 kernel: [   28.064196] WARNING: CPU: 5 PID: 4122
> at /build/linux-GU1w8g/linux-3.16.39/fs/proc/generic.c:304
> proc_register+0xc0/0x140()
> Feb 10 21:40:12 t530 kernel: [   28.064197] proc_dir_entry
> 'driver/nvidia' already registered
> Feb 10 21:40:12 t530 kernel: [   28.064198] Modules linked in:
> nvidia(PO+) bnep snd_hrtimer snd_seq [...]
> Feb 10 21:40:12 t530 kernel: [   28.064265] CPU: 5 PID: 4122 Comm:
> modprobe Tainted: P   O  3.16.0-4-amd64 #1 Debian 3.16.39-1
> Feb 10 21:40:12 t530 kernel: [   28.064266] Hardware name: LENOVO
> 24296JG/24296JG, BIOS G4ET95WW (2.55 ) 08/12/2013
> Feb 10 21:40:12 t530 kernel: [   28.064267]  
> 81514c11 8803fdd93c30 0009
> Feb 10 21:40:12 t530 kernel: [   28.064268]  81068867
> 880428d879c0 8803fdd93c80 88042cee4440
> Feb 10 21:40:12 t530 kernel: [   28.064270]  88042dd25a40
> 880428d879c0 810688cc 81730518
> Feb 10 21:40:12 t530 kernel: [   28.064271] Call Trace:
> Feb 10 21:40:12 t530 kernel: [   28.064275]  [] ?
> dump_stack+0x5d/0x78
> Feb 10 21:40:12 t530 kernel: [   28.064278]  [] ?
> warn_slowpath_common+0x77/0x90
> Feb 10 21:40:12 t530 kernel: [   28.064280]  [] ?
> warn_slowpath_fmt+0x4c/0x50
> Feb 10 21:40:12 t530 kernel: [   28.064281]  [] ?
> proc_register+0xc0/0x140
> Feb 10 21:40:12 t530 kernel: [   28.064283]  [] ?
> proc_mkdir_data+0x4c/0x70
> Feb 10 21:40:12 t530 kernel: [   28.064322]  [] ?
> nv_register_procfs+0x4c/0x1e0 [nvidia]
> Feb 10 21:40:12 t530 kernel: [   28.064386]  [] ?
> nvidia_init_module+0x285/0x78b [nvidia]
> Feb 10 21:40:12 t530 kernel: [   28.064451]  [] ?
> nv_drm_init+0xf/0xf [nvidia]
> Feb 10 21:40:12 t530 kernel: [   28.064515]  [] ?
> nvidia_frontend_init_module+0x4d/0x866 [nvidia]
> Feb 10 21:40:12 t530 kernel: [   28.064517]  [] ?
> do_one_initcall+0xcc/0x200
> Feb 10 21:40:12 t530 kernel: [   28.064520]  [] ?
> load_module+0x210d/0x2710
> Feb 10 21:40:12 t530 kernel: [   28.064521]  [] ?
> store_uevent+0x40/0x40
> Feb 10 21:40:12 t530 kernel: [   28.064523]  [] ?
> SyS_finit_module+0x7d/0xa0
> Feb 10 21:40:12 t530 kernel: [   28.064526]  [] ?
> system_call_fast_compare_end+0x10/0x15
> Feb 10 21:40:12 t530 kernel: [   28.064528] ---[ end trace
> 9cc8c799d0ec934f ]---
> Feb 10 21:40:13 t530 kernel: [   28.310327] thinkpad_acpi: EC reports
> that Thermal Table has changed
> Feb 10 21:40:13 t530 kernel: [   28.310334] nouveau :01:00.0:
> enabling device (0004 -> 0007)
> Feb 10 21:40:13 t530 kernel: [   28.310569] NVRM: The NVIDIA probe
> routine was not called for 1 device(s).
> Feb 10 21:40:13 t530 kernel: [   28.310571] NVRM: This can occur 

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andreas Beckmann]

On 2017-02-22 11:29, Luca Boccassi wrote:
> Ok I managed to fix everything that was trying to load nvidia modules.
> 
> Now booting with nouveau, I can't actually manage to reproduce the
> stale /proc/driver/nvidia with any series - tried 304, 340 and 378. Not
> sure what's going on...

What are the kernel messages you get when loading the modules? Try to 
load the module a second time after it had failed to load ...
The problem should be reproducible at least with 340 as in the archive 
(and should be fixed in svn).
Anything 361+ should not have the problem any more.

Let me see if I can find my kernel log entries ... yep, that's 
* try to load the module -> nouveau already clained our device
* try to load the module again -> proc_dir_entry 'driver/nvidia' already 
registered
* access /proc/driver/nvidia -> OOPS
(with jessie's kernel)

[...]
Feb 10 21:39:53 t530 kernel: [6.084133] [drm] Initialized nouveau 1.1.2 
20120801 for :01:00.0 on minor 1
Feb 10 21:39:53 t530 kernel: [6.123206] nvidia: module license 'NVIDIA' 
taints kernel.
Feb 10 21:39:53 t530 kernel: [6.123210] Disabling lock debugging due to 
kernel taint
Feb 10 21:39:53 t530 kernel: [6.132582] NVRM: The NVIDIA probe routine was 
not called for 1 device(s).
Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: This can occur when a driver 
such as: 
Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: nouveau, rivafb, nvidiafb or 
rivatv 
Feb 10 21:39:53 t530 kernel: [6.132585] NVRM: was loaded and obtained 
ownership of the NVIDIA device(s).
Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: Try unloading the conflicting 
kernel module (and/or
Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: reconfigure your kernel 
without the conflicting
Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: driver(s)), then try loading 
the NVIDIA kernel module
Feb 10 21:39:53 t530 kernel: [6.132588] NVRM: again.
Feb 10 21:39:53 t530 kernel: [6.132590] NVRM: No NVIDIA graphics adapter 
probed!
Feb 10 21:39:53 t530 kernel: [6.132591] [drm] Module unloaded
[...]
Feb 10 21:40:12 t530 kernel: [   28.064190] [ cut here ]
Feb 10 21:40:12 t530 kernel: [   28.064196] WARNING: CPU: 5 PID: 4122 at 
/build/linux-GU1w8g/linux-3.16.39/fs/proc/generic.c:304 
proc_register+0xc0/0x140()
Feb 10 21:40:12 t530 kernel: [   28.064197] proc_dir_entry 'driver/nvidia' 
already registered
Feb 10 21:40:12 t530 kernel: [   28.064198] Modules linked in: nvidia(PO+) bnep 
snd_hrtimer snd_seq [...]
Feb 10 21:40:12 t530 kernel: [   28.064265] CPU: 5 PID: 4122 Comm: modprobe 
Tainted: P   O  3.16.0-4-amd64 #1 Debian 3.16.39-1
Feb 10 21:40:12 t530 kernel: [   28.064266] Hardware name: LENOVO 
24296JG/24296JG, BIOS G4ET95WW (2.55 ) 08/12/2013
Feb 10 21:40:12 t530 kernel: [   28.064267]   81514c11 
8803fdd93c30 0009
Feb 10 21:40:12 t530 kernel: [   28.064268]  81068867 880428d879c0 
8803fdd93c80 88042cee4440
Feb 10 21:40:12 t530 kernel: [   28.064270]  88042dd25a40 880428d879c0 
810688cc 81730518
Feb 10 21:40:12 t530 kernel: [   28.064271] Call Trace:
Feb 10 21:40:12 t530 kernel: [   28.064275]  [] ? 
dump_stack+0x5d/0x78
Feb 10 21:40:12 t530 kernel: [   28.064278]  [] ? 
warn_slowpath_common+0x77/0x90
Feb 10 21:40:12 t530 kernel: [   28.064280]  [] ? 
warn_slowpath_fmt+0x4c/0x50
Feb 10 21:40:12 t530 kernel: [   28.064281]  [] ? 
proc_register+0xc0/0x140
Feb 10 21:40:12 t530 kernel: [   28.064283]  [] ? 
proc_mkdir_data+0x4c/0x70
Feb 10 21:40:12 t530 kernel: [   28.064322]  [] ? 
nv_register_procfs+0x4c/0x1e0 [nvidia]
Feb 10 21:40:12 t530 kernel: [   28.064386]  [] ? 
nvidia_init_module+0x285/0x78b [nvidia]
Feb 10 21:40:12 t530 kernel: [   28.064451]  [] ? 
nv_drm_init+0xf/0xf [nvidia]
Feb 10 21:40:12 t530 kernel: [   28.064515]  [] ? 
nvidia_frontend_init_module+0x4d/0x866 [nvidia]
Feb 10 21:40:12 t530 kernel: [   28.064517]  [] ? 
do_one_initcall+0xcc/0x200
Feb 10 21:40:12 t530 kernel: [   28.064520]  [] ? 
load_module+0x210d/0x2710
Feb 10 21:40:12 t530 kernel: [   28.064521]  [] ? 
store_uevent+0x40/0x40
Feb 10 21:40:12 t530 kernel: [   28.064523]  [] ? 
SyS_finit_module+0x7d/0xa0
Feb 10 21:40:12 t530 kernel: [   28.064526]  [] ? 
system_call_fast_compare_end+0x10/0x15
Feb 10 21:40:12 t530 kernel: [   28.064528] ---[ end trace 9cc8c799d0ec934f ]---
Feb 10 21:40:13 t530 kernel: [   28.310327] thinkpad_acpi: EC reports that 
Thermal Table has changed
Feb 10 21:40:13 t530 kernel: [   28.310334] nouveau :01:00.0: enabling 
device (0004 -> 0007)
Feb 10 21:40:13 t530 kernel: [   28.310569] NVRM: The NVIDIA probe routine was 
not called for 1 device(s).
Feb 10 21:40:13 t530 kernel: [   28.310571] NVRM: This can occur when a driver 
such as: 
Feb 10 21:40:13 t530 kernel: [   28.310571] NVRM: nouveau, rivafb, nvidiafb or 
rivatv 
Feb 10 21:40:13 t530 kernel: [   28.310571] NVRM: was loaded and obtained 
ownership of the NVIDIA device(s).
Feb 10 21:40:13 

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Luca Boccassi]

On Tue, 2017-02-21 at 20:56 +, Luca Boccassi wrote:
> On Mon, 2017-02-20 at 11:25 +, Luca Boccassi wrote:
> > On Sun, 2017-02-19 at 21:09 +0100, Andreas Beckmann wrote:
> > > Control: fixed -1 361.45.18-1
> > > 
> > > On 2017-02-11 00:06, Andreas Beckmann wrote:
> > > > Problem is that the 340xx driver (didn't check 304xx) does not
> > > > unregister the proc entries if it aborts loading (due to
> > > > nouveau
> > > > being
> > > > loaded already).
> > > 
> > > The missing nv_unregister_procfs() call was added upstream in the
> > > 361
> > > series.
> > > 
> > > The same problem seems to exist in 304xx. I've ported my patch to
> > > that
> > > legacy series, too, but I have no way to test it properly.
> > > 
> > > Luca, perhaps you could try the following (even if you have no
> > > 304xx
> > > requiring hardware, as long as the test machine has a nvidia
> > > gpu):
> > > * load nouveau module
> > > * load 304xx module (should fail, since another module has
> > > already
> > > grabbed the device)
> > > 
> > > I don't know if the relevant code path gets executed if no
> > > supported
> > > hardware is available ... if it is I would expect the 304xx
> > > module
> > > (without patch) to leave a stale /proc/driver/nvidia (requires
> > > reboot to
> > > get rid of it again), while the patched version leaves /proc
> > > clean.
> > > It's also possible that the problem is not (easily) reproducible
> > > on
> > > 304xx, since the initialization of the procfs entries seems to
> > > come
> > > much
> > > later.
> > 
> > I can certainly give it a spin, in the next couple of days
> > probably,
> > will report back how it goes.
> > 
> > Kind regards,
> > Luca Boccassi
> 
> It is surprisingly difficult to boot with only nouveau! Loads and
> loads
> of things trying to load the nvidia module.
> 
> Anyway, I just tried with the latest 378 kernel module, and it still
> leaves behind the /proc/driver/nvidia, if nouveau is loaded first.
> 
> Kind regards,
> Luca Boccassi

Ok I managed to fix everything that was trying to load nvidia modules.

Now booting with nouveau, I can't actually manage to reproduce the
stale /proc/driver/nvidia with any series - tried 304, 340 and 378. Not
sure what's going on...

Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Luca Boccassi]

On Mon, 2017-02-20 at 11:25 +, Luca Boccassi wrote:
> On Sun, 2017-02-19 at 21:09 +0100, Andreas Beckmann wrote:
> > Control: fixed -1 361.45.18-1
> > 
> > On 2017-02-11 00:06, Andreas Beckmann wrote:
> > > Problem is that the 340xx driver (didn't check 304xx) does not
> > > unregister the proc entries if it aborts loading (due to nouveau
> > > being
> > > loaded already).
> > 
> > The missing nv_unregister_procfs() call was added upstream in the
> > 361
> > series.
> > 
> > The same problem seems to exist in 304xx. I've ported my patch to
> > that
> > legacy series, too, but I have no way to test it properly.
> > 
> > Luca, perhaps you could try the following (even if you have no
> > 304xx
> > requiring hardware, as long as the test machine has a nvidia gpu):
> > * load nouveau module
> > * load 304xx module (should fail, since another module has already
> > grabbed the device)
> > 
> > I don't know if the relevant code path gets executed if no
> > supported
> > hardware is available ... if it is I would expect the 304xx module
> > (without patch) to leave a stale /proc/driver/nvidia (requires
> > reboot to
> > get rid of it again), while the patched version leaves /proc clean.
> > It's also possible that the problem is not (easily) reproducible on
> > 304xx, since the initialization of the procfs entries seems to come
> > much
> > later.
> 
> I can certainly give it a spin, in the next couple of days probably,
> will report back how it goes.
> 
> Kind regards,
> Luca Boccassi

It is surprisingly difficult to boot with only nouveau! Loads and loads
of things trying to load the nvidia module.

Anyway, I just tried with the latest 378 kernel module, and it still
leaves behind the /proc/driver/nvidia, if nouveau is loaded first.

Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Luca Boccassi]

On Sun, 2017-02-19 at 21:09 +0100, Andreas Beckmann wrote:
> Control: fixed -1 361.45.18-1
> 
> On 2017-02-11 00:06, Andreas Beckmann wrote:
> > Problem is that the 340xx driver (didn't check 304xx) does not
> > unregister the proc entries if it aborts loading (due to nouveau being
> > loaded already).
> 
> The missing nv_unregister_procfs() call was added upstream in the 361
> series.
> 
> The same problem seems to exist in 304xx. I've ported my patch to that
> legacy series, too, but I have no way to test it properly.
> 
> Luca, perhaps you could try the following (even if you have no 304xx
> requiring hardware, as long as the test machine has a nvidia gpu):
> * load nouveau module
> * load 304xx module (should fail, since another module has already
> grabbed the device)
> 
> I don't know if the relevant code path gets executed if no supported
> hardware is available ... if it is I would expect the 304xx module
> (without patch) to leave a stale /proc/driver/nvidia (requires reboot to
> get rid of it again), while the patched version leaves /proc clean.
> It's also possible that the problem is not (easily) reproducible on
> 304xx, since the initialization of the procfs entries seems to come much
> later.

I can certainly give it a spin, in the next couple of days probably,
will report back how it goes.

Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andreas Beckmann]

Control: fixed -1 361.45.18-1

On 2017-02-11 00:06, Andreas Beckmann wrote:
> Problem is that the 340xx driver (didn't check 304xx) does not
> unregister the proc entries if it aborts loading (due to nouveau being
> loaded already).

The missing nv_unregister_procfs() call was added upstream in the 361
series.

The same problem seems to exist in 304xx. I've ported my patch to that
legacy series, too, but I have no way to test it properly.

Luca, perhaps you could try the following (even if you have no 304xx
requiring hardware, as long as the test machine has a nvidia gpu):
* load nouveau module
* load 304xx module (should fail, since another module has already
grabbed the device)

I don't know if the relevant code path gets executed if no supported
hardware is available ... if it is I would expect the 304xx module
(without patch) to leave a stale /proc/driver/nvidia (requires reboot to
get rid of it again), while the patched version leaves /proc clean.
It's also possible that the problem is not (easily) reproducible on
304xx, since the initialization of the procfs entries seems to come much
later.


Andreas

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Luca Boccassi]

On Sat, 11 Feb 2017 00:06:32 +0100 Andreas Beckmann  wrote:
> Control: tag -1 - moreinfo
>
> On Fri, 10 Oct 2014 09:14:17 +0200 Andreas Beckmann  wrote:
> > The only point I could imagine to "block" is when the script tries to
> > read /proc/driver/nvidia/version - which should only exist if the driver
> > got loaded properly.
>
> Today I ran into this problem, too. :-)
>
> Problem is that the 340xx driver (didn't check 304xx) does not
> unregister the proc entries if it aborts loading (due to nouveau being
> loaded already). The error unwinding is a mess! 375.26 is correct in
> that respect. So the script tries to access stale proc entries resulting in
>   BUG: unable to handle kernel paging request at ...
> I have tested a small patch that adds a call to nv_unregister_proc(),
> which was sufficient to fix my problem. It is probably not correct for
> all unwinding paths ...
>
>
> Andreas

Nice catch! Never came across this issue myself.
Should we try to get this fix in Stretch if no issues are found in sid
for a while?

Kind regards,
Luca Boccassi

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andreas Beckmann]

Control: tag -1 - moreinfo

On Fri, 10 Oct 2014 09:14:17 +0200 Andreas Beckmann  wrote:
> The only point I could imagine to "block" is when the script tries to
> read /proc/driver/nvidia/version - which should only exist if the driver
> got loaded properly.

Today I ran into this problem, too. :-)

Problem is that the 340xx driver (didn't check 304xx) does not
unregister the proc entries if it aborts loading (due to nouveau being
loaded already). The error unwinding is a mess! 375.26 is correct in
that respect. So the script tries to access stale proc entries resulting in
  BUG: unable to handle kernel paging request at ...
I have tested a small patch that adds a call to nv_unregister_proc(),
which was sufficient to fix my problem. It is probably not correct for
all unwinding paths ...


Andreas

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Elena Grassi]

I also incurred in this problem on my box.

root@decoder:/home/data# uname -a
Linux decoder 4.0.0-1-amd64 #1 SMP Debian 4.0.2-1 (2015-05-11) x86_64 GNU/Linux

01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce
GT 610] (rev a1)

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
(charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)




-- 
$ pom


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andrei POPESCU]

On Vi, 10 oct 14, 09:14:17, Andreas Beckmann wrote:
 On 2014-10-10 08:09, Vincent Cheng wrote:
  If I try it again the script
  /usr/lib/nvidia/check-for-mismatching-nvidia-module gets stuck in D
  state. Also the bug script for the package gets stuck, I had to switch
  to disable KMS to be able to use reportbug.
  
  It may be worth adding set -x to the script to see precisely where
  it's getting stuck.
 
 The only point I could imagine to block is when the script tries to
 read /proc/driver/nvidia/version - which should only exist if the driver
 got loaded properly.

Trying to check older versions I discovered the bug is only triggered by 
the following sequence:

- use 'nvidia' (e.g. boot to graphical login)
- update-alternatives --set glx /lib/bin/mesa-diverted (and remove any 
  'nvidia' relevant bits from xorg.conf)
- reboot to use 'nouveau'
- dpkg -i libgl1-nvidia-glx

I can reproduce this with all 340.x. Going further back would require 
downgrading Xorg, so I didn't test. If you need any specific info don't 
hesitate to ask.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Vincent Cheng]

Hi Andrei,

On Thu, Oct 9, 2014 at 1:53 PM, Andrei POPESCU andreimpope...@gmail.com wrote:
 Package: libgl1-nvidia-glx
 Version: 340.46-1
 Severity: important

 Hi,

 If I have KMS active I get this when trying to install or upgrade
 libgl1-nvidia-glx:

 root@sid:~# dpkg -i libgl1-nvidia-glx_340.46-1_i386.deb
 (Se citește baza de date ... 197382 de fișiere și directoare actualmente 
 instalate.)

LC_ALL=C, please (for future bug reports). Your typical package
maintainer is much more likely to speak English than Romanian.

 If I try it again the script
 /usr/lib/nvidia/check-for-mismatching-nvidia-module gets stuck in D
 state. Also the bug script for the package gets stuck, I had to switch
 to disable KMS to be able to use reportbug.

It may be worth adding set -x to the script to see precisely where
it's getting stuck.

My only other suggestion at this point is to try out older versions of
the kernel and/or the nvidia packages, and see if there's a known good
combination that works (is this a regression of some sort?). Other
than that, I've no idea what's happening.

Regards,
Vincent


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andreas Beckmann]

On 2014-10-10 08:09, Vincent Cheng wrote:
 If I try it again the script
 /usr/lib/nvidia/check-for-mismatching-nvidia-module gets stuck in D
 state. Also the bug script for the package gets stuck, I had to switch
 to disable KMS to be able to use reportbug.
 
 It may be worth adding set -x to the script to see precisely where
 it's getting stuck.

The only point I could imagine to block is when the script tries to
read /proc/driver/nvidia/version - which should only exist if the driver
got loaded properly.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764639: libgl1-nvidia-glx: failst to upgrade or install with KMS (nouveau) active

[Andrei POPESCU]

Package: libgl1-nvidia-glx
Version: 340.46-1
Severity: important

Hi,

If I have KMS active I get this when trying to install or upgrade 
libgl1-nvidia-glx:

root@sid:~# dpkg -i libgl1-nvidia-glx_340.46-1_i386.deb
(Se citește baza de date ... 197382 de fișiere și directoare actualmente 
instalate.)
Preparing to unpack libgl1-nvidia-glx_340.46-1_i386.deb ...
Unpacking libgl1-nvidia-glx:i386 (340.46-1) over (340.46-1) ...
Se pregătește libgl1-nvidia-glx:i386 (340.46-1) ...
[   84.433639] BUG: unable to handle kernel paging request at a0ece9b8
[   84.433694] IP: [81203d70] proc_get_inode+0xd0/0x130
[   84.433728] PGD 1816067 PUD 1817063 PMD 75fa7067 PTE 0
[   84.433763] Oops:  [#1] SMP
[   84.433784] Modules linked in: rpcsec_gss_krb5 auth_rpcgss oid_registry 
nfsv4 dns_resolver nfs lockd sunrpc fscache ctr ccm cpufreq_powersave 
cpufreq_stats cpufreq_userspace cpufreq_conservative binfmt_misc xfs 
crc32c_generic libcrc32c btusb bluetooth 6lowpan_iphc uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media 
arc4 iwl4965 iwlegacy r852 sm_common mac80211 ppdev iTCO_wdt 
iTCO_vendor_support nand cfg80211 snd_hda_codec_analog nand_ecc 
snd_hda_codec_generic psmouse nand_bch pcspkr pcmcia thinkpad_acpi coretemp 
nvram sdhci_pci bch firewire_ohci nouveau evdev i2c_i801 serio_raw sg mxm_wmi 
ttm drm_kms_helper snd_hda_intel drm snd_hda_controller ata_generic nand_ids 
sdhci mmc_core mtd yenta_socket rfkill pcmcia_rsrc pcmcia_core i2c_algo_bit 
r592 memstick i2c_core lpc_ich
[   84.434267]  mfd_core snd_hda_codec snd_hwdep snd_pcm ata_piix snd_timer 
battery ac snd wmi parport_pc e1000e parport shpchp tpm_tis acpi_cpufreq video 
tpm processor button soundcore ehci_pci uhci_hcd ptp ehci_hcd usbcore 
usb_common pps_core tp_smapi(O) thinkpad_ec(O) loop firewire_sbp2 firewire_core 
crc_itu_t fuse autofs4 ext4 crc16 mbcache jbd2 sd_mod crc_t10dif 
crct10dif_generic crct10dif_common ahci libahci libata scsi_mod thermal 
thermal_sys
[   84.434553] CPU: 0 PID: 1047 Comm: check-for-misma Tainted: P   O  
3.16-2-amd64 #1 Debian 3.16.3-2
[   84.434590] Hardware name: LENOVO 8918CJG/8918CJG, BIOS 7KETA9WW (2.09 ) 
12/27/2007
[   84.434619] task: 880075dd0c60 ti: 8800767ac000 task.ti: 
8800767ac000
[   84.434647] RIP: 0010:[81203d70]  [81203d70] 
proc_get_inode+0xd0/0x130
[   84.434684] RSP: 0018:8800767afc98  EFLAGS: 00010246
[   84.434705] RAX: 8000 RBX: 88007800a0c8 RCX: 0019
[   84.434733] RDX: a0ece960 RSI: 0001 RDI: 88007800a0c8
[   84.434759] RBP: 8800767afca8 R08: 006e R09: 0001
[   84.434786] R10: 2bb0 R11:  R12: 88007b8a2640
[   84.434813] R13: 88007800a348 R14: ff9c R15: 
[   84.434841] FS:  () GS:88007fc0(0063) 
knlGS:f75a9940
[   84.434872] CS:  0010 DS: 002b ES: 002b CR0: 80050033
[   84.434896] CR2: a0ece9b8 CR3: 75df3000 CR4: 07f0
[   84.434926] Stack:
[   84.434936]  88007b8a2640 8800784d0318 0007 
81208f19
[   84.434975]  8800784d0318 8800784d03d8 8800784d03d8 
8800767afe00
[   84.435013]  811ae029 8800767afe00 0001 
811ae88f
[   84.435051] Call Trace:
[   84.435067]  [81208f19] ? proc_lookup_de+0x79/0xd0
[   84.435094]  [811ae029] ? lookup_real+0x19/0x50
[   84.435117]  [811ae88f] ? __lookup_hash+0x2f/0x40
[   84.435143]  [81505259] ? lookup_slow+0x3e/0xa3
[   84.435166]  [811b0e25] ? path_lookupat+0x715/0x780
[   84.435190]  [811b0eb6] ? filename_lookup+0x26/0xc0
[   84.435215]  [811b4fa4] ? user_path_at_empty+0x54/0x90
[   84.435242]  [810562a1] ? __do_page_fault+0x1d1/0x4e0
[   84.435268]  [811a4b11] ? new_sync_read+0x71/0xa0
[   84.435292]  [811a9ab6] ? vfs_fstatat+0x46/0x90
[   84.435316]  [8105d3a5] ? sys32_stat64+0x15/0x30
[   84.435339]  [811a51bd] ? vfs_read+0xed/0x170
[   84.435363]  [8150e308] ? page_fault+0x28/0x30
[   84.435386]  [8150ea5c] ? sysenter_dispatch+0x7/0x21
[   84.435408] Code: 2a 48 89 93 40 01 00 00 48 89 d8 5b 41 5c 5d c3 0f 1f 00 
48 89 43 50 41 8b 74 24 08 85 f6 74 b8 48 89 df e8 93 a8 fb ff eb ae 90 48 83 
7a 58 00 48 c7 c0 40 78 62 81 48 c7 c2 40 79 62 81 48 0f
[   84.435642] RIP  [81203d70] proc_get_inode+0xd0/0x130
[   84.436929]  RSP 8800767afc98
[   84.437473] CR2: a0ece9b8
[   84.437473] ---[ end trace 1c9475731480931e ]---
Killed
dpkg: error processing package libgl1-nvidia-glx:i386 (--install):
 subprocesul script post-installation instalat a returnat starea de eroare la 
ieșire 137
Processing triggers for nvidia-alternative (340.46-1) ...
Processing triggers for glx-alternative-nvidia (0.4.2) ...
update-initramfs: deferring update (trigger activated)
Processing