Random NVidia Proprietary Driver Lock-Ups with dual core + 7300

Bug #145112 reported by Troy James Sobotka on 2007-09-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.22 (Ubuntu)
Declined for Gutsy by Timo Aaltonen
linux-restricted-modules-2.6.24 (Ubuntu)
Declined for Gutsy by Timo Aaltonen

Bug Description

Binary package hint: nvidia-glx-new

Summary: Utilizing the NVidia proprietary drivers results in a completely unstable system. Lockups / Lynches result in a system that is completely unrecoverable using Alt-PrtScn - REISUB key combinations. System fine under Feisty.

*** UPDATE ***
Saturday, September 29 2007: Appears tied to the 7300 class of GPUs.
Saturday, September 29 2007: After testing with NV and Vesa, very clearly a result of the new Nvidia drivers.

Frequency: Random. Once to twice per hour in some instances. Unable to determine a fully reproducible set of events.

Architecture: amd64

Version: 7.10

issue has been acknowledged by Nvidia upstream and is being tracked at http://www.nvnews.net/vbulletin/showthread.php?t=99426

Almost certainly attached to the nvidia-glx-new. Seems to have abated using nv. Will try using the other nvidia-glx package.

Definitely associated with the nvidia-glx-new. Can't seem to properly install nvidia-glx anymore to test stability. The freezes range from complete system freezes where Alt-PrtScn combinations can't successfully shutdown the computer to softer freezes where only the mouse cursor is left functional.

description: updated
sam tygier (samtygier) wrote :

i am seeing these too
with amd64 and nvidia 7300 LE

Changed in linux-restricted-modules-2.6.22:
status: New → Confirmed

7300 GS here. Interesting similarity.

Sam, have you managed to perform a remote debug on the crashing system as per https://help.ubuntu.com/community/DebuggingSystemCrash?

I will try soon. It is so utterly frustrating, but we could probably provide some useful information to the developers.

description: updated

i have had a go at the DebuggingSystemCrash.

after the crash i am unable to ping or ssh to the machine (over wired ethernet).

this happens with just metacity (i think it happens faster with compiz), and a few gnome apps open (epiphany, liferea). the frequency of once or twice an hour is about right.

the crash does not seem to occur when i am on a virtual terminal, so the sysrq debugging will not work. (though can be used to reboot, as crtl-alt-del does not work when frozen)

sam tygier (samtygier) wrote :

i have let memtest86 run for an hour. it completed two passes with no errors found.

sam tygier (samtygier) wrote :

i managed to ssh after a freeze

dmesg has.

[ 92.954972] NET: Registered protocol family 17
[ 107.488611] eth0: no IPv6 routers present
[ 278.449711] NVRM: Xid (0008:00): 6, PE0000 0fb8 00ffffff 0000f0a0 00ffffff 00ffffff
[ 565.402594] NVRM: Xid (0008:00): 26, Ch 000001ff M 00001ffc D ffffffff intr ffffffff
[ 565.414343] NVRM: Xid (0008:00): 1, Ch 000001ff M 00001ffc D ffffffff intr ffffffff
[ 565.414851] NVRM: Xid (0008:00): 6, PE01ff 1ffc ffffffff 0000fc78 00ffffff 00ffffff
[ 574.409243] NVRM: Xid (0008:00): 16, Head 00000000 Count 0000de59
[ 582.404730] NVRM: Xid (0008:00): 16, Head 00000000 Count 0000de5a
[ 590.400223] NVRM: Xid (0008:00): 16, Head 00000000 Count 0000de5b
[ 598.395722] NVRM: Xid (0008:00): 8, Channel 0000001e

could it be possible that there are different types of crash, if only sometimes sshing works?

ok, after a few minutes X died, and i was returned to a text terminal.

i had done
echo t | sudo tee /proc/sysrq-trigger

i have attached the dmesg containing it

Sam Tygier wrote:
"i have let memtest86 run for an hour. it completed two passes with no errors found." I let it run on my machine for twelve hours. Not a single error.

Have you tried the remote debugging technique where you ssh into the box before the crash and watch the output?

All we can do to help the devs is do a full dmesg with an lspci -vv and attach them. Hopefully someone will notice.

Sitsofe Wheeler (sitsofe) wrote :

You're getting Xids which could make this very tough to track down. I really hope your system is performing "lynches" though, that could be rather deadly.

You might be able to use some of the information on https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia#troubleshooting to help you...

Sitsofe Wheeler (sitsofe) wrote :

is performing "lynches" should have been
isn't performing "lynches"
Lynching is not behaviour to be engaged in : )

sam tygier (samtygier) wrote :

sometimes the freeze is only temporary, i can ssh in (or stay ssh'ed in). if i run top the xorg is at 100%. i get the Xid errors in my dmesg. the computer appears to be frozen hard, the capslock key does not light the caps light, ctrl-alt-del/backspace ignored.

after around 5 mins, it recovers from the freeze.

some times the freeze is harder. ssh session stops, machine won't reply to pings. i have not seen this recover.

same unstability / flickering on my hp pavilion dv6159eu (nvidia go 7200) and nvidia-glx-new (ALL 100.x series drivers).
Could be this drivers bug on "turbocache" memory access??

andrea 'shinji' delfino wrote:
"same unstability"

Does this mean that you are experiencing lockups?

If this is the case, we might want to do some digging to see exactly what chipset goes into the 7200 and 7300 lines to see if there is the possibility that this is a related bug.

rick_in_kingston (rickggreen) wrote :

Also having the same problem here. Nvidia 7300, on an ASUS M2NVP-VM, have a 6150 onboard but disabled. AMD X2 4200+ with 2G DDR2 800 ram (4 X 512). I am running Gutsy beta, video driver is 100.14.19 with Compiz-Fusion enable, experiencing about 1 or more an hour. None with affects disabled. I did not want to install 100.14, but wanted to install 9636, but system would not let me. I also tried turning off cpu scaling in bios. (Cool and Quiet)
Tried everything I could think of to remove 100.14 but again was thwarted by system. This is on a generic (i386) kernel.
I have another Gutsy install on the same machine but with the 64 kernel. I was able to install 963X, it is having no lockup problems at all with Compiz running and I can run with cpu scaling.
I had the same problems on Friesty with the 9755 and the 100.11 drivers. And again with the 96XX drivers, no problems
I think it is a nvidia driver problem with the 6 and 7 series video GPUs and any of the 97XX and higher drivers.

rick_in_kingston (rickggreen) wrote :

Just picked up the following from the Nvidia support site

nV News Forums > Linux Support Forums > NVIDIA Linux
RE: Demand on WORKING drivers

10-03-07, 12:59 PM #36
NVIDIA Corporation

Join Date: Aug 2002
Posts: 2,781

Default Re: Demand on WORKING drivers
I'd like to follow up on Aaron's update, since not all posts in this thread refer to the same hardware. We identified a regression between 100.14.09 and 100.14.11 specific to G72 based graphics cards (GeForce 7300 GS, etc.) on certain systems; this problem is being investigated. However, there are no known regressions between the two releases affecting G8x GPUs.

I have exactly the same problem with a geforce 7300 GO.

OlivierP (unineurone) wrote :

For those (like me %-)) who experience hard lockups with the 100.14.11/14 drivers, here is a horrible hack to get 100.14.09 installed AND to get l-r-m to "recognize" it, while keeping other restricted modules you may require available. This has only been tested on an up-to-date Gutsy

DO NOT report any bugs or whatsoever if this does not work, burns your CPU or whatnot.

Install the binary drivers from source,
follow the instructions in the NvidiaManual howto here: https://help.ubuntu.com/community/NvidiaManual
and on the NVidia support forum sticky post here: http://www.nvnews.net/vbulletin/showthread.php?t=72490

This will get you with correctly installed drivers. However, when you now enable compiz/Desktop Effects, l-r-m will find that the driver is loaded but NOT enabled, and will happily reinstall the repository drivers if you let it.

To work around this, proceed as follows:
- Edit /usr/lib/python2.5/site-packages/RestrictedManager/handlers/xorg_driver.py

- insert a line here (lines 38-39):
    def is_enabled(self):
        """Returns True if the module is enabled."""[/code]so that it reads:
    def is_enabled(self):
        """Returns True if the module is enabled."""
        return True

- Save & close.

You can now enable Desktop Effects to your heart's content.

Important: the editing of /usr/lib/python2.5/site-packages/RestrictedManager/handlers/xorg_driver.py will need to be redone each time Restricted Manager is updated.

Wow. Thanks for the reversion version number -- 09.

Compiled the new binary nasty blob driver and so far no lockups.

Also edited the Python to enable desktop effects.

Thus far, stable with glx!

Hopefully the driver will get resolved with the next version.

To recap -- download the 09 series driver from Nvidia:
amd64 @ http://us.download.nvidia.com/XFree86/Linux-x86_64/100.14.09/NVIDIA-Linux-x86_64-100.14.09-pkg2.run
i386 @ http://www.nvidia.com/object/linux_display_ia32_100.14.09.html

Get your compiling enabled and install the kernel sources:
sudo aptitude install build-essential linux-source

Restart in your plain mode without X (recovery) and build the blob (failsafe X is a PITA):
sh ./NVIDIA<...>

And fix your xorg.conf as per your needs. For example:
Section "Module"
   Load "glx"
   Load "GLcore"
   Load "v4l"

and change the driver to "nvidia" from whatever.

WFM and will be a decent crutch until NVidia pulls their greymatter together from the nether regions.

Just to clarify, you _will_ get an error with the NVidia module trying to load thanks to some funky garbage that Ubuntu has stuck into the modprobe script. The new modprobe will attempt to use lrm-video to launch the NVidia module. This of course, won't work as lrm-video is part of the restricted modules package.

To get around this, the fix is a relatively simple one:

Edit /etc/modprobe.d/lrm-video and comment out the 'nvidia' line

#install nvidia /sbin/lrm-video nvidia $CMDLINE_OPTS

This will enable the nvidia module to properly load.

It is a lot of hassle, and I suppose we can thank the proprietary garbage drivers of NVidia -- as this bug would likely have been fixed already had the source and documentation been open.

No errors here:
olivierp@neuronemobile:~$ cat /etc/modprobe.d/lrm-video
# Make nvidia/nvidia_legacy and fglrx use /sbin/lrm-video to load
install fglrx /sbin/lrm-video fglrx $CMDLINE_OPTS
install nvidia /sbin/lrm-video nvidia $CMDLINE_OPTS
install nvidia_legacy /sbin/lrm-video nvidia_legacy $CMDLINE_OPTS
install nvidia_new /sbin/lrm-video nvidia_new $CMDLINE_OPTS
olivierp@neuronemobile:~$ dmesg | grep -i nvidia.*kernel
[ 20.212000] NVRM: loading NVIDIA UNIX x86 Kernel Module 100.14.09 Sat
May 26 00:47:07 PDT 2007

Note that each time a new kernel comes through the repositories (including
the associated restricted modules) you will need to re-install the NVIDIA
provided kernel module.

Apparently one can install the archived driver with restricted installed as well.

When I do a full purge on all of the restricted bits, /sbin/lrm-video ceases to exist. This will result in X generating the "lrm-video" not found error when it attempts to load the NVidia module. modprobe nvidia will generate the same error.

I wasn't able to get the nvidia module to take with the restricted packages installed -- the newly compiled libraries seemed to be awol. Followed the blacklisting technique as well. The commenting out of the line pertains only to installations without the restricted packages.

----------------------------------------> From: <email address hidden>> To: <email address hidden>> Date: Sat, 6 Oct 2007 05:01:51 +0000> Subject: [Bug 145112] Re: Random NVidia Proprietary Driver Lynches / Lock-Ups>> Wow. Thanks for the reversion version number -- 09.>> Compiled the new binary nasty blob driver and so far no lockups.>> Also edited the Python to enable desktop effects.>> Thus far, stable with glx!>> Hopefully the driver will get resolved with the next version.>> To recap -- download the 09 series driver from Nvidia:> amd64 @ http://us.download.nvidia.com/XFree86/Linux-x86_64/100.14.09/NVIDIA-Linux-x86_64-100.14.09-pkg2.run> i386 @ http://www.nvidia.com/object/linux_display_ia32_100.14.09.html>> Get your compiling enabled and install the kernel sources:> sudo aptitude install build-essential linux-source>> Restart in your plain mode without X (recovery) and build the blob (failsafe X is a PITA):> sh ./NVIDIA>> And fix your xorg.conf as per your needs. For example:> Section "Module"> Load "glx"> Load "GLcore"> Load "v4l"> EndSection>> and change the driver to "nvidia" from whatever.>> WFM and will be a decent crutch until NVidia pulls their greymatter> together from the nether regions.>> --> Random NVidia Proprietary Driver Lynches / Lock-Ups> https://bugs.launchpad.net/bugs/145112> You received this bug notification because you are a direct subscriber> of the bug.

09 has done the trick for me, I am testing both the 32 and 64 bit versiond of Gutsy. Been working like a charm for 3 days now, no lockups at all.

Express yourself with free Messenger emoticons. Get them today!

I have sent off a bug report with a link to this thread to NVidia as I strongly suspect it is a binary driver issue. Hopefully we will get this resolved. At any rate, if anyone in this thread still has the crashing driver installed, what would be of use is to send off a similar mail to them with the output generated from their bug reporting script. The following quote from their site:

"When emailing <email address hidden>, please attach an nvidia-bug-report.log, which is generated by running "nvidia-bug-report.sh". "

That shell script can be found at /usr/bin/nvidia-bug-report.sh

If anyone from Ubuntu's X team knows better, please inform us.

sam tygier (samtygier) wrote :

i tried idle=poll and it did not help. nothing else on that link seems relivant. did you post the wrong link?

That was the initial response from NVidia's Linux bug email.

I don't know if it helps us much, but I would think we should at least try to follow their bug trail path.

If everyone could send them a similar mail, it might help to get their attention on the matter.

So all subscribers of this bug need to follow the instructions on that NVidia page and submit the reports accordingly -- as per instructions sent from Lonni J Friedman of NVidia's Linux support.

I have just run through the entire list with no success.

Please ship off the log that the shell script generates. Thank you.

NVIDIA has already identified/acknowledged that there is a regression in the
100.14.11 & 100.14.19 drivers for G72 based cards (7300 Go, GS...)
 on certain systems:

Note that most of the time, when using 100.14.11/19, the freeze is hard
enough that you will be unable to switch to a console, or ssh to the box.
You may however be able to use the magic keys to cleanly sync/unmount/reboot
the box.
This link<http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/networking/netconsole.txt;h=1caa6c734691bc8bc2d14493065ae6f08613f5e6;hb=7dcca30a32aadb0520417521b0c44f42d09fe05c>will
help you setup a netconsole, if you have a second box, and will help
capturing a stack trace of the kernel if/when it hangs.

If you do want to use the 100.14.11/19 drivers on a dual core systems and
avoid these freezes, you either will need to disable Desktop effects, or
boot with maxcpus=1 as a kernel option. This will disable your second core.

just to note the freezes occur with desktop effects disabled.
so the options are:
disable a core
downgrade drivers
switch to nv

clemsye (clement207) wrote :

hello, i have exactly the same problem see: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/154843

a man said :"Please read https://wiki.ubuntu.com/X/Debugging and add info about;
 - How complete is the X failure?
+ Does ctrl+alt+f1 take you to a console?
+ Does ctrl+alt+backspace restart X?
+ Does mouse pointer still move?
+ Does the keyboard LED come on when hitting the CAPSLOCK key?
 - /etc/X11/xorg.conf
 - /var/log/Xorg.0.log
 - /var/log/Xorg.0.log.old
 - ~/.xsession-errors
 - output of lspci -vvnn"

ok so:
+Does ctrl+alt+f1 take you to a console? =no
+ Does ctrl+alt+backspace restart X?=no
+ Does mouse pointer still move?=no
+ Does the keyboard LED come on when hitting the CAPSLOCK key?=i don't understand what you mean.....
+ Is compiz active at the time of the crashes =Not necessarily, i have the both(compiz enabled or disabled) with the same frequency.

 - /etc/X11/xorg.conf
 - /var/log/Xorg.0.log
 - /var/log/Xorg.0.log.old
 - ~/.xsession-errors
 - output of lspci -vvnn"

where i can upload the file.?

I managed to use "downgrade" to nvidia-glx driver. The problem seems to be on the package that fails to remove the control file /lib/linux-restricted-modules/.nvidia_new_installed

This file is checked by lrm-video script to see if it needs to load nvidia or nvidia_new

Just by installing nvidia-glx, removing the file mentioned and restarting the system does the trick.

sam tygier (samtygier) on 2007-10-28
description: updated
Jonah (jonah) wrote :

hi i also have had lots of freezes lockups especially with nvidia driver in xorg.conf, it i change it to nv it works better, but stil the lockups and freezes come occasionally. so does this mean it's not just the nvidia-glx driver that's got a bug but also the nv one also...??

Jonah (jonah) wrote :

i've got nvidia 7200 card

Download full text (4.3 KiB)

To all
Had this same problem with the 7300GS on Suse 10.1-10.3 but found this solution at NV using the text of the following file. When you run the first run file with the --apply-patch qualilfier it creates a patched "custom" that can now be run normally. What I think the patch might be doing is shutting off agp in order to run the newer style of card PCI Express. (guessing)

Check out this thread about halfway down.

Note: I did have to change the names to match the downloaded run file from Nvidia. Since running this patch I haven't had a lockup other than with k3b and its 'second burn lockup'. Any glx app like GoogleEarth or Blender froze the system for sure before the patch. Now I am really enjoying these apps. Hope this helps you others with the problem.

I did try the patch on the latest 100.14.19 without success. Seems that even though the author is at Nvidia the patch is not standard to the driver.

In the middle of a piece of music the old driver (100.14.11) Started a 1 second loop of the song and if I tried to use the keyboard to rescue myself out of X I couldn't even use the 5sec holddown of the off button to turn off and restart the system. I had to go to the back of the machine and toggle the machine off and back on which is the same as pulling the plug out of the wall. Really locked to be sure. ZANDER is the contact person at NVIDIA.

If the patch process works, let others know, If it doesn't also let us know though it does work for me.
To apply the patch, use:
# sh /path/to/NVIDIA-Linux-x86-100.14.11-pkg2.run --apply-patch /path/to/NVIDIA_kernel-100.14.11-336672.diff.txt
 # sh NVIDIA-Linux-x86-100.14.11-pkg0-custom.run
diff -ru usr/src/nv/nv-linux.h usr/src/nv.336672/nv-linux.h
--- usr/src/nv/nv-linux.h 2007-06-13 18:59:58.000000000 -0700
+++ usr/src/nv.336672/nv-linux.h 2007-07-27 19:04:39.174241056 -0700
@@ -1075,6 +1075,7 @@

     nv_stack_t *timer_sp;
     nv_stack_t *isr_sp;
+ nv_stack_t *pci_cfgchk_sp;
     nv_stack_t *isr_bh_sp;

     /* keep track of any pending bottom halfes */
@@ -1172,7 +1173,7 @@
         if (nv->flags & NV_FLAG_USE_BAR0_CFG) \
             rm_check_pci_config_space(sp, nv, do_the_bars, NULL); \
         else \
- nv_verify_pci_config(nv, do_the_bars); \
+ nv_check_pci_config_space(nv, do_the_bars); \

diff -ru usr/src/nv/nv.c usr/src/nv.336672/nv.c
--- usr/src/nv/nv.c 2007-06-13 18:59:58.000000000 -0700
+++ usr/src/nv.336672/nv.c 2007-07-27 19:04:39.178241284 -0700
@@ -215,7 +215,7 @@

-void NV_API_CALL nv_verify_pci_config(nv_state_t *nv, BOOL do_the_bars)
+static void nv_check_pci_config_space(nv_state_t *nv, BOOL do_the_bars)
     nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
     unsigned short cmd, flag = 0;
@@ -246,6 +246,14 @@
         verify_pci_bars(nv, nvl->dev);

+void NV_API_CALL nv_verify_pci_config(nv_state_t...


wolfen69 (wolfen69) wrote :

i am seeing these too with amd64 and nvidia 7300 GS.

zippy028 (johncwheat) wrote :

My System;
ASUS M2N SLI Mobo with Nforce 570 Chipset
AMD 64X2 3800 CPU
1GB corsair DDR2
Western Digital SATA HDD
Nvidia 7300 LE

I believe the hardware I listed is part of the problem with the latest drivers.
I removed all of the "nvidia-glx-new" drivers from my system and all kernel sources and or modules relating to the "new" drivers.

What I have installed for nvidia drivers via synaptic
not sure if I need all of the above but 3D acceleration is working with compiz set to extra effects.

I completely removed the restricted driver manager pkgs. via synaptic

Then I installed version 100.14.09 from the nvidia driver archive from console and everything seems to be fine.

I hope this helps in finding a resolution to this problem.


alivesay (andrew-livesay) wrote :

Having the same issues here. AMD64 X2, nvidia 7300 SE, ASUS M2N-E. None of the suggested fixes have worked so far.

Here are the syslog entries when it freezes:

sam tygier (samtygier) on 2007-11-26
Changed in linux-restricted-modules-2.6.22:
importance: Undecided → High
40 comments hidden view all 120 comments

2008/1/29, Timo Aaltonen <email address hidden>:
> Remember that there can only be one version of the libraries installed
> (nvidia-glx*), so it wouldn't work.

nvidia-glx is a suggested package in l-r-m's dependencies. They could
(should?) depend on their identical version kernel-module package, as far as
I understand it. As I said, this would indeed be something challenging (to
stay polite :-) ) for the maintainer(s).

However, the ugly restricted-manager hack I posted somewhile ago, combined
with the information in the 2 outside threads mentioned allows me to have
compiz running days on end without any hardlock on the laptop. Should this
information be combined and posted somewhere on
https://help.ubuntu.com/community/ ?

albech (ubuntu-albech) wrote :

Looks like I have to install another distribution, while Ubuntu moves to Hardy. Waiting another 3 months with these random freezes, just isn't viable.

Besides these freezes (crashes), I have been a happy Ubuntu user.

Timo Aaltonen (tjaalton) wrote :

Please test Hardy alpha4 which is released today(ish). There will be no updates to the gutsy driver.

Changed in linux-restricted-modules-2.6.22:
status: Confirmed → Won't Fix
Changed in linux-restricted-modules-2.6.24:
importance: Undecided → High
status: New → Incomplete
albech (ubuntu-albech) wrote :

Interesting. Let me know how it goes

John Cottier (j-cottier) wrote :

Does this mean its down to us to test the driver for Hardy alpha? How do we do that? Live CD? If so, how can you load the nvidia driver in a live session?

Noel J. Bergman (noeljb) wrote :

> Waiting another 3 months with these random freezes, just isn't viable.

You could always download the driver from NVidia, and build it locally. I've done that with Hardy until quite recently, as an example, and it is quite straightforward.

Ray (f00f-bug) wrote :

Bug confirmed on 7600GS + Intel Quad Core. Proprietary driver causes random lockups, sometimes monitor goes into suspend mode, other times chunks of the cursor and garbage appears in top left corner of screen with no system response. Seems to happen more often with firefox running...

albech (ubuntu-albech) wrote :

I disabled the Nvidia driver and are now running the driver that comes with Ubuntu. It works, but very slow and with no effects whatsoever. But rather that than random crashes every 5-10 min.

"Please test Hardy alpha4 which is released today(ish). There will be no
updates to the gutsy driver."

Two words: "Gutsy Backports".

OK, I made the backport request as Bug #189787 .

OlivierP (unineurone) wrote :

2008/2/7, Michael R. Bernstein <email address hidden>:
> OK, I made the backport request as Bug #189787 .

Umm... given that:
- Gutsy (7.10) multi-core users have a workaround (either proceed with a
"manual" install of 169.09 or run on 1 core)
- Hardy is due for April
- Hardy will be a LTS version
- Hardy's l-r-m package contains the 169.09 nvidia driver

I'd rather have the Ubuntu kernel team / l-r-m maintainers concentrate on
fixing any kernel / l-r-m issues, and do proprietary backports _then_,
rather than backporting 169.09 into Gutsy...

That said, I do hope Hardy will also support the current "legacy" nvidia
driver also. I'm wondering if "nvidia-new" & "nvidia" are appropriate

Timo Aaltonen (tjaalton) wrote :

If I've understood correctly, this issue is fixed in 169.07/09, which is in Hardy so the bug can be closed. As said, there will be no l-r-m backports to any release. Instead, starting from Hardy, the archive will have EnvyNG for those who insist on using the latest upstream crack ;)

Changed in linux-restricted-modules-2.6.24:
status: Incomplete → Fix Released
semateos (sam-bigroomstudios) wrote :

I was having this problem with my dual xeon system running on gutsy using kernel 2.6.22-14-generic and nvidia-glx driver - I upgraded to hardy alpha 4 per the advise above and am still experiencing the random hard locks with the newer generic kernel and nvidia-glx driver. I can't use nvidia-glx-new because my Quadro FX 1400 card is too old. Should I try Envy? Would rather an apt solution. Any other news/advise on this issue? Am currently slumming in windows xp land and would like to get back home to ubuntu land. ;)

Miloš Jakovljević (milos-sd) wrote :

I have the same problem here. I have Intel Core2Duo E6550, 2x1GB of RAM and Gainward 7600GT SilentFX PCI-x video card. First when I had drivers from Gutsy repos, the freez was not complite (I could move my mouse cursor), but when I installed 169.09 drivers with envy, I had a complite freezes. I even upgraded my kernel to Hardy's kernel few days ago using this HowTo - http://ubuntuforums.org/showthread.php?t=646755&highlight=hardy but I had one freez two days ago.
And to say this... I can have a stable system for 1,2 or 3 days. Sometimes it freezes after 1 day, sometimes after 2 days, etc. There is no evidence of something went wrong in the logs. I don't know what can be the problem here, maybe it is cpufqscaling, but I didn't try to disable it. Today I upgraded to 2.6.24-8 version of kernel, and I will wait to see if it is going to freez.

Miloš Jakovljević (milos-sd) wrote :

I didn't say that I am using 32bit version of Gutsy, not 64bit as I can see that this bug is for.

John Cottier (j-cottier) wrote :

@Milos I think this bug applies to any dual core machines, with an ever increasing range of nVidia cards (I am using 32 bit Gutsy bit too). After waiting patiently for 3 months, we have been told this will not be fixed in Gutsy and we will have to wait for Hardy, but so far it seems this has bugs too. Lets hope when Hardy is released we dont end up waiting for the next release for a fix again. I would suggest you use the non restricted driver as constant lock ups can be quite damaging to the file system. Its a little sluggish, but totally stable.

Miloš Jakovljević (milos-sd) wrote :

@John Cotier
Maybe disableing CPU Frequency manager (powernowd) in Services settings will do the job? I didn't try that, but there are people on the forums who say that this helps.

John Cottier (j-cottier) wrote :

according to Sam Tygier the options to bypass this bug are:-

disable a core (kernel boot up parameter)
downgrade drivers (to Feisty)
switch to nv (unrestricted open source driver, but with no 3D acceleration)

I have just switched to the nv driver. But its a nasty situation, its been years since I have 3D or graphics issues, I just hope it does not put too many off using Ubuntu. Maybe its just too soon to have a 3D desktop as the default.

I already said that there's an alternative to keep a contrib like repo where I can update the linux-restricted-modules package to include the last version, which is running on my laptop without lockups for more than a month by now.

I just need a place to put the .deb files.

sam tygier (samtygier) wrote :

Raphael Derosso Pereira, have you looked at launchpads PPA system https://help.launchpad.net/PPAQuickStart

John Cottier, another option is to install a newer driver from nvidia.

John Cottier (j-cottier) wrote :

@Sam Tygier
That's true, but it would break the ubuntu update system. So after every kernel update xorg would likely fall over.

John Cottier (j-cottier) wrote :

It would be interesting to try the new restricted driver in Hardy using a live CD. But I dont know how to do this as the OS seems to require an actual reboot, rather than a restart of X to use the restricted driver, which you cant do on a live CD of course.

Today I upgraded linux-restricted-modules to version, and installed nvidia drivers with envy once again. We'll see will this problem occure again. I hope not. :)

Andrew (andrew-rw-robinson) wrote :

On Feb 19, 2008 5:07 AM, John Cottier <email address hidden> wrote:
> according to Sam Tygier the options to bypass this bug are:-
> disable a core (kernel boot up parameter)
> downgrade drivers (to Feisty)
> switch to nv (unrestricted open source driver, but with no 3D acceleration)

You forget the best option:
Install the binary from the download directly from nvidia.

I have been running the latest driver from nvidia without any problems in gutsy.

The only drawback is that you cannot use apt to install it and
upgrade, but that is a much better solution than slowing your computer
down, running old, slow and buggy drivers or having no 3D support.

@Andrew, is using envy the same as installing binary from nvidia site? As I can see, envy download and install that binary.I installed driver with envy, and I still have that bug. I will wait two days or so to see is the bug going to show.

Andrew (andrew-rw-robinson) wrote :

Never tried envy, sorry

On Feb 19, 2008 9:58 AM, Milos_SD <email address hidden> wrote:
> @Andrew, is using envy the same as installing binary from nvidia site?
> As I can see, envy download and install that binary.I installed driver
> with envy, and I still have that bug. I will wait two days or so to see
> is the bug going to show.
> --
> Random NVidia Proprietary Driver Lock-Ups with dual core + 7300
> https://bugs.launchpad.net/bugs/145112
> You received this bug notification because you are a direct subscriber
> of the bug.

lanzen (lanzen) wrote :

It's now 3 months since I've installed the new 169 nvidia driver and I had no more freezes since.

About envy, let's put it this way: the script is supposed to do for you what needs to be done manually. Check with tseliotat hissite http://albertomilone.com/wordpress/

John Cottier (j-cottier) wrote :

I am sure I have seen the dev guys in the ubuntu forums warn against using envy and easy ubuntu as it can break something. Unless that has changed.

Seagull (chris-gilbride) wrote :

Like something isn't broken now ?? ;-)

Oh, well ... It crashed again. I had 2 day 6h uptime. When will Ubuntu team fix this? :(

Let me make this clear:

As with many things -- this is _not_ a Linux problem but rather a _vendor_ problem.

If you own one of these cards, please take the time to send a letter to NVidia asking them to open their cards up via sample code or documentation in the same manner that AMD has committed to doing. There are rumors that NVidia is preparing a Free Software integration in the future. A polite but stern email might help to speed this along.

Proprietary garbage helps no one, slows down development response time, and creates issues all across the board.

On a side note, completely removing the older driver in Ubuntu and replacing it with one of the newer ones as mentioned has resulted in uptimes of greater than 60 days for me. YMMV.

TimS (tim-slatcher) wrote :

Currently, I am using the NV drivers, could someone tell me if there is a fix or if the latest drivers are good enough to use.
If so, could you tell me the instructions of how to install the latest driver. I have only ever done it with adept before.

John Cottier (j-cottier) wrote :

@Troy I can appreciate your point of view, but from our perspective we have had 3 months of no response from developers. Then told it wont be fixed in Gutsy, and now told its 'not our problem, go and complain to nVidia'. This is hardly kind to Ubuntu's long suffering users.

Somehow I cant imagine nVidia taking much notice of Joe Public, and to be fair why should they. We are not proffesional debuggers so for all they know the problem is not even with their driver, and we are not in a position to prove to them otherwise. Surely nVidia are more likely to take notice of professional bodies like Ubuntu/Canonical who's documentation and opinions would carry more weight and so more likely get noticed and acted upon. Maybe Ubuntu/Canonical could enter into dialog with nVidia over these issues.

But from the none technical users perspective its a case of install Windows and the graphics works ok, install Linux and they lock up (even though both drivers come from nVidia), which for whatever reasons is not a nice place to be. But realistically how can a non technical or none professional user tell nVidia their drivers are no good.

TimS (tim-slatcher) wrote :

Is this fixed in k/ubuntu 8.04 then?

I have installed EnvyNG, what driver do I want to ensure that this does not occur, is it 169.12?

Also, I have heard reports of people not being able to log into KDE when they have the correct drivers installed, any reason for this?

Basically, I am asking if its completely safe to install the 169.12 driver for my 7300gs via EnvyNG.

Thanks a lot.

khuang (khuang) wrote :

I installed 169.12 driver with EnvyNG on Ubuntu 8.04. Same problem as before. The screen freezes randomly, maybe once 2-3 times an hour, it will usually return to normal (unfreeze) after 20+ seconds. Once in awhile, computer will spontaneously reboot.

I haven't tried the other two Nvidia drivers.

I'm using Acer Aspire 5583 (Core 2 Duo T5500 1.66 GHz, GeForce Go 7300)

viret (viret) wrote :

Hi every one.

First, please pardon my poor english !

I had the same trouble on Debian testing.
I've try everything... without success !

The only solution i've found is to disable ethernet driver in bios setting : in fact, the trouble appears often during network traffic.
So, i've disable the on-board LAN controller in bios, and plug a PCI card.... to do the same things, but on an other way.

Since this time (about 1 month), all goes right : no more freeze !

As far as I know it seems to be a kernel problem ! But, i'm not developer !

Hope this will help you !

khuang (khuang) wrote :

Attached is screenshot of System Monitor. I had no other programs open at the time. CPU1 will be running at 100% utilization and then the computer would freeze for 20+ seconds and then CPU2 would be running at 100% utilization and it keeps on switching back and forth with freezes in between.

On my Acer notebook, I am unable to disable onboard LAN from BIOS.

khuang (khuang) wrote :

I found a workaround on the ubuntu forum. (http://ubuntuforums.org/showthread.php?t=579761)

1. Install latest version of nvidia driver (I'm using v173.14.09, installed with EnvyNG)
2. sudo gedit /etc/modprobe.d/options
3. Add the following line:
options nvidia NVreg_RegistryDwords="PerfLevelSrc=0x2222"
4. Save and restart

This has been working for me for the past 3-4 days.

The problem seems to be caused by the powermizer feature which dynamically switches the clock speed of the GPU and video memory. The steps above locks the card into the highest clock speed ("Performance Level 2" - GPU:350mhz, Memory: 700mhz). I then manually underclock 3D clock frequency to GPU:250mhz/Memory:500mhz. It seems like anything lower and it becomes unstable again.

In Windows, I encounter the same problem. By default the Window's driver I use turns this powermizer feature off. When I turn Powermizer on, i get the same freezes as in Ubuntu. So I'm inclined to believe this is an issue with the hardware itself. Something to do with this particular geforce go 7300 card and dual core CPUs.

My system is Acer Aspire 5583 (Geforce Go 7300, Intel Core 2 Duo T5500 1.66mhz) running Ubuntu 8.04.

As a result of the newer driver, this is fixed in Hardy.

I'd suggest bumping up to Hardy if you can. It is unfortunate that Ubuntu can't allow showstopper bugs such as this one to be patched mid release.

John Cottier (j-cottier) wrote :

I have now upgraded this PC to Hardy 8.4.1. Unfortunately the nvidia driver will not even load in Hardy. This is the same bug I have on my home PC when I upgraded that to Hardy.

IE when you click to install the proprietary nvidia driver, it installs the packages and aks to reboot. After reboot I arrive at the console end then the "low resolution mode" dialog pops up. The Monitor is correctly detected. Clicking on the graphic card selection, it has correctly detected my card, but selected the default VESA driver. I manually select Geforce7 series, but I am not allowed to select an nvidia driver, the open source one is selected and greyed out. I select OK and reboot. Now I get massive and blurred VGA login. I then go to System Setting..Monitor and display and find the monitor is now undetected! So I manually select 1680 x 1050 for my LCD monitor. Logoff, restart X, and this is fixed. But the login resolution is still VGA. I sorted this by hacking the xorg.conf to remove any resolution but 1680 x 1050. See bug 232012.

Will this stuff ever be fixed! Oh well, who needs Compiz Fusion and 3D anyway :-(

Displaying first 40 and last 40 comments. View all 120 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions