nvidia-glx crashes/lockups

Created an attachment (id=1514)
gdm config file

Here's my config file.

how do you know than gdm crashed and not xorg ?

I didn't see anything unusual in the Xorg logs, so I assumed it was gdm, but I
guess Xorg is possible, how to I find out?

Have a look in /var/log/daemon.log for lines with 'gdm' in them.

Mar 4 15:12:03 solaria gdm[19085]: gdm_slave_xioerror_handler: Fatal X error -
Restarting :0

That's EST btw.

I think that means it's an Xorg error, but I'm not sure, so I'm leaving it as
gdm until somebody from above knows for sure

It's happened again, but this time (and a few other times that I didn't report)
X just froze and didn't quit. top shows Xorg as using near 99% processor.
/var/log/gdm/:0.log shows nothing.

The only clue I have is
Mar 12 15:28:05 solaria ntpd[3329]: frequency error -512 PPM exceeds tolerance
500 PPM
in /var/log/syslog a few minutes before the crash

I've been having problems with the system clock being fast (that started a
little while before the X problem), so this might be relevant, but I'm not sure.

VT switching doesn't work, and X is completely frozen except that I can move the
mouse. I'm leaving the computer as it is for now and accessing it with ssh.
Should I send Xorg SIGSTOP to freeze it's state? What should I do to get
information about what happened?

Note: I'm on my laptop (which is only slightly slower than my desktop which is
the one with the problem) now so I don't need this fixed immediately.

Could you please attach a full /var/log/Xorg.0.log? If X crashes and then gets
restarted by gdm, then you'll have a /var/log/Xorg.0.log.old from the previous
(crashy) session.

Created an attachment (id=1696)
Xorg.0.log

This doesn't look like a log from a crashed session to me, but then again, if
you're using the proprietary nVidia driver, all bets are off. Sorry.

(In reply to comment #9)
> This doesn't look like a log from a crashed session to me,
It's from a frozen session like I mentioned earlier. If it crashes I'll upload
again.

> but then again, if
> you're using the proprietary nVidia driver, all bets are off. Sorry.
/me hopes that the OpenGraphics project hurries up and makes a good video card
with open specs and drivers.

*** Bug 14982 has been marked as a duplicate of this bug. ***

*** Bug 14443 has been marked as a duplicate of this bug. ***

*** Bug 13440 has been marked as a duplicate of this bug. ***

*** Bug 14868 has been marked as a duplicate of this bug. ***

*** Bug 14590 has been marked as a duplicate of this bug. ***

*** Bug 15058 has been marked as a duplicate of this bug. ***

*** Bug 14835 has been marked as a duplicate of this bug. ***

*** Bug 13777 has been marked as a duplicate of this bug. ***

*** Bug 14075 has been marked as a duplicate of this bug. ***

*** Bug 14809 has been marked as a duplicate of this bug. ***

*** Bug 15058 has been marked as a duplicate of this bug. ***

*** Bug 14809 has been marked as a duplicate of this bug. ***

Setting severity to critical as at least two of the "duplicate" bugs report the
system freezing. i.e. Ctrl-Alt-F1 not restoring to text console, halting of any
disk activity, although often CPU usage appears high as fans start to become
noisier. Bugs 8487 and 8738 both report that ACPI power-button shutdown is the
only way to unfreeze the system, and both mention that the display will blank
before (but with LCD backlight remaining on) before the system eventually powers
down.
Both also mention that that it seems to happen most often during use of Firefox,
and that although the mouse pointer can still be moved, the pointer does not
change shape as per normal functioning.

If these bugs (8487 and 8738) are definately not the same as the other bugs
being described here (as some bugs mention that the system is still useable and
hense might not be classed as critical), then would it be best to re-open bug
14809 instead with further updates going to that?

(In reply to comment #23)
> and both mention that the display will blank
> before (but with LCD backlight remaining on) before the system eventually powers
> down.

Same with 7183, except that I used ``shutdown -h now'' from ssh.

> Both also mention that that it seems to happen most often during use of Firefox,
> and that although the mouse pointer can still be moved, the pointer does not
> change shape as per normal functioning.

Same with 7183, but it seems to happen almost equally with firefox (lots of
non-default extensions), evolution, and gaim (a few non-defaul extensions) (but
not thunderbird).

>
> If these bugs (8487 and 8738) are definately not the same as the other bugs
> being described here (as some bugs mention that the system is still useable and
> hense might not be classed as critical), then would it be best to re-open bug
> 8487 instead with further updates going to that?
I would suggest that the reporters of 8487 and 8738 try logging in with ssh or
another remote way during a freeze. If that works for them, then 7183 is
probably the same as them.

Setting severity major, as this is a non-default proprietary driver. Everyone
experiencing nvidia problems, please check that you're using the latest version
in Hoary (nvidia-glx 1.0.7174-0ubuntu1)

At http://www.nvnews.net/vbulletin/showthread.php?t=48815 they are suggesting
that disabling APIC (in the BIOS) could be a temporary workaround.

The system does not have to be completely dead to qualify as the same bug (or
same class of bug): this is about either nvidia_drv.o or nvidia.ko crashing or
hanging. Whether you can still ping the machine, or whether it's entirely dead,
or whatever, is largely irrelevant.

Personally I don't think the bug I lodged (7732) or it's duplicate (8421) are in
any real way directly related to 7183 or it's other duplicates, execept that
they're all the same driver (nvidia's binary driver). In my case, with all
versions of the driver since I lodged that bug, things have worked perfectly
with the exception of EDID support getting the details for the screen wrong,
which IMHO is in no way related to a crash or lockup, as I can always get back
to text mode and I can get it working with a small change to xorg.conf. This
includes the latest nvidia-glx 1.0.7174 in Hoary.

I upgraded to the latest nvidia-glx (Hoary) earlier this evening. So far I've
been firefoxing for a good 6 hours or so with no freezes so far... touch wood.

(In reply to comment #25)
> Setting severity major, as this is a non-default proprietary driver. Everyone
> experiencing nvidia problems, please check that you're using the latest version
> in Hoary (nvidia-glx 1.0.7174-0ubuntu1)

Yes, I am using latest nvidia-glx 1.0.7174 but whether -0ubuntu1 or someting, I
cannot remember. But I tried to apt-get the latest nvidia, but nothind comes out
as of eight hours ago.

*** Bug 15097 has been marked as a duplicate of this bug. ***

I don't know if this could be important:
More or less by accident I had disabled glx but used nvidia instead of nv as
driver. I'm not exactly sure if disabling glx automaticly disabled nvidia
aswell, however I had no crash with this configuration so it seems that the bug
happens in the glx driver and not in the kernel module

*** Bug 15100 has been marked as a duplicate of this bug. ***

This only ever seems to do it with FireFox/Konq/GAIM/etc when RenderAccel is set
to True. Perhaps a bug in nvidia's hardware rendering?

(In reply to comment #34)
> This only ever seems to do it with FireFox/Konq/GAIM/etc when RenderAccel is set
> to True. Perhaps a bug in nvidia's hardware rendering?

Ah.. maybe the reason my system is now stable is because I commented out the
RenderAccel line in my xorg.conf....

Basically, "me too," so adding myself to list. Interestingly, I was about to do
this before when everything froze at the login screen for this instance of
bugzilla. Trying the "comment out renderaccel" stuff.

(In reply to comment #23)
> Setting severity to critical as at least two of the "duplicate" bugs report the
> system freezing. i.e. Ctrl-Alt-F1 not restoring to text console, halting of any
> disk activity, although often CPU usage appears high as fans start to become
> noisier.

This is exactly what is happening to me, using either the ubuntu nvidia-glx
7174 package or the user-installed 6629 release. Power button is required to
reboot. I am trying the the user-installed 7174 drivers now.

The freeze appears to occur once every ~10 hours of use or.

(In reply to comment #37)
> (In reply to comment #23)
> This is exactly what is happening to me, using either the ubuntu nvidia-glx
> 7174 package or the user-installed 6629 release. Power button is required to
> reboot. I am trying the the user-installed 7174 drivers now.
>
> The freeze appears to occur once every ~10 hours of use or.

What is your "RenderAccel" setting in your xorg.conf?

> What is your "RenderAccel" setting in your xorg.conf?
>
>

There was no RenderAccel line in my xorg.conf. In the NVIDIA README it says that
RenderAccel is on by default, and to turn it off, you should set the option
"NoRenderAccel."

When I set NoRenderAccel, things slow down on X, of course. I am willing to set
it if it will buy stability, but I hope there will be a fix for this.

By the way, I ran memtest86+ for 5 hours on my system, so I am fairly sure it is
not a busted RAM that's doing this.

(In reply to comment #26)
> At http://www.nvnews.net/vbulletin/showthread.php?t=48815 they are suggesting
> that disabling APIC (in the BIOS) could be a temporary workaround.

I tried this. This has the same affect as turning RenderAccel off (at least on my
PCI Express Dell Precision M 70): X performance is way down.

My guess is RenderAccel requires APIC to work correctly. Yes, I did make sure to
turn RenderAccel on before rebooting with APIC off.

In any case, the main question of interest now is whether installing the NVIDIA
supplied drivers is different from apt-get install nvidia-glx. I will report here
again if I have the crash. As I said, the crash probability so far has been about
0.1 / hour.

(In reply to comment #79)
> Can anybody reproduce this problem on a breezy system?

Yes, although it doesn't happen often. In a twist of bitter irony, it occurred
about half an hour ago, while I was writing a comment on this bug (with an
up-to-date breezy system).

When it occurs I cannot do anything locally, however I can ssh in and see that X
is using 100% cpu. Whether or not I can move the cursor depends on whether
hardware or software cursors are being used - with the former I can move it, but
with the latter cursor movement is performed by X and so doesn't work when it's
hung. Nothing odd appears in the logs

Most of the hangs occur when using Firefox or Epiphany, and usually when I'm
using the scrollbar with several graphic intensive tabs open. As a
I-don't-really-know-what-I'm-talking-about guess, I'd say that it seems to occur
when there are a lot of pixmaps loaded into memory and a blit is being performed
to move the rendered page.

I haven't tried it with RenderAccel off, because it doesn't happen often enough
to tell whether that makes a difference.

I am currently using breezy without renderaccel and haven't had a single crash
so for me it appears the bug is only appearing when using renderaccel

This is happening to me lately on Breezy. But in my case I am getting a total
system freeze. Can't move mouse, can't even ping or ssh into the box. I've tried
various settings on the nVidia driver RenderAccel on or off, nvAGP, whatever.
Nothing matters. I always see system freezes after a few hours of using Firefox.
It always seems to happen when I am scrolling the page with the mouse wheel.
When it happens is random however. I can't seem to force it to happen. Note, I
also use TwinView. This never used to happen with Hoary. This is new bahavior
since I upgraded to Breezy.

*** Bug 25060 has been marked as a duplicate of this bug. ***

*** Bug 25825 has been marked as a duplicate of this bug. ***

*** Bug 25828 has been marked as a duplicate of this bug. ***

*** Bug 18989 has been marked as a duplicate of this bug. ***

*** Bug 21708 has been marked as a duplicate of this bug. ***

*** Bug 22837 has been marked as a duplicate of this bug. ***

*** Bug 23098 has been marked as a duplicate of this bug. ***

*** Bug 21968 has been marked as a duplicate of this bug. ***

*** Bug 22271 has been marked as a duplicate of this bug. ***

OK, I recently switched to a Laptop (HP Pavilion ZV5474EA) that has an Nvidia
GeForce 440 Go 64M card.

It runs rather well with RenderAccel turned on in Gnome, but running the KDE
dekstop or just konqueror caused the Xid 13 lockup.

Also, using xcompmanager does the same, so I think the issue is back from the dead.

I'm running Breezy BTW.

*** Bug 25829 has been marked as a duplicate of this bug. ***

My lockup seems SMP related. I've been running now in single processor mode for the last two weeks with no freezes. On an SMP kernel I was getting a freeze once a day or more. Not happy loosing a CPU but at least for the moment my system is stable. My issue appears to be something in the video driver and SMP kernels.

Just a heads up. This seems to be stable and working great in dapper on my amd64 (EM64T Xeon) machine with an nVidia Quadro card with dual heads.

Changing status to confirmed since there are 10+ duplicates, and many more reporters.

I want to report that since updating to 2.6.15-21-k7 from 2.6.15-18-k7 and updating to the latest nvidia-glx as of last moday I have not had a single freeze like I had seen in the past. I assume the newer nvidia drivers must have fixed this issue.

Given that nvidia-glx has been confirmed to work by a few people maybe we should consider closing this bug. I for one have tried 5 different machines using this driver with various nVidia cards and they are all working great including vga, dvi, and twinview cards on both AGP and PCI-X.

I also think it's time to close this bug. In some cases the freeze-ups were due to other causes (i.e. bugs in the kernel libata that have since been resolved). No crashes in months of using Breezy and Dapper.

I'm still having this problem using nvidia-glx-legacy under DapperRC.

This bug appears to have become a catch-all for nVidia binary-driver crashes. For the subset that shows the symptoms that X hangs (100$ CPU), but the mouse works, I believe the cause is the handling of the XRender extension.

    With the legacy drivers, this is done in software, and when XRender crashes, the entire screen locks (and there is no useful debug information due to nVidia drivers). For these cards, try disabling the Render extension (and disable RenderAccell in xorg.conf).

    With the newer drivers, this is done in hardware on the card, and there seems to be a bug in the nVidia drivers causing huge increases in heat generation when processing XRender and GL calls simultaneously. When the thermal ceiling is hit, and the card slows, XRender processing is also slowed or halted, causing an apparent freeze (and X looping while waiting for feedback from the card). For these cards, either disable Render as above, underclock, or install additional cooling hardware.

I must admit I don't understand much of all the things beings said here (I'm just a simple ubuntu 06.06 user), but I do think I have a simular problem with my GforceII MX400 and Dapper Drake. When using the attached xorg.conf my system locks-up after maybe 2 minutes of use. Frozen screen and no more mouse movement. I had to use the previous xorg.conf to get the computer stable again. I used automatix to install my graphics-card, so I gues I't the latest driver.

Is this still a problem with fully updated dapper?

The problem appears only when the RENDERACCEL option is activated. I guess
this bug will remain open until nvidia fixes it.

On 10/9/06, John Vivirito <email address hidden> wrote:
>
> Is this still a problem with fully updated dapper?
>
> --
> nvidia-glx crashes/lockups
> https://launchpad.net/bugs/13530
>

No. It's working fine.

Calvin

On Mon, 2006-10-09 at 13:45 +0000, John Vivirito wrote:

> Is this still a problem with fully updated dapper?
>

"The adolescent who insists upon a critical reexamination of
conventional wisdom is making himself into an adult. And the adult
whose concerns extend beyond family and beyond nation to mankind has
become fully human."
- Leon Eisenberg

I don´t know. I´m living in Spain at the moment and I don´t have access to
a Dapper computer. I´ll return to Scotland in a few weeks and I´ll let
you know. But, I have a feeling that it was a hardware problem. It has
happened on my Windows partition too, since.

Alan

> Is this still a problem with fully updated dapper?
>
> --
> nvidia-glx crashes/lockups
> https://launchpad.net/bugs/13530
>
>

I had the same problem in breezy and the first release of dapper. Disabling
renderaccel solved the problem. Now I'm using edgy with the acceleration
activated and I'm not seeing any crash, for now.

On 10/10/06, Alan Rae <email address hidden> wrote:
>
> I don´t know. I´m living in Spain at the moment and I don´t have access to
> a Dapper computer. I´ll return to Scotland in a few weeks and I´ll let
> you know. But, I have a feeling that it was a hardware problem. It has
> happened on my Windows partition too, since.
>
> Alan
>
> > Is this still a problem with fully updated dapper?
> >
> > --
> > nvidia-glx crashes/lockups
> > https://launchpad.net/bugs/13530
> >
> >
>
> --
> nvidia-glx crashes/lockups
> https://launchpad.net/bugs/13530
>

Thanks for the bug report.

I'm closing this bug because it seems to have been fixed.
If this is still an issue for someone please feel free to reopen it.

I can still replicate the issue with Edgy prerelease, but I haven't been able to collect enough information to identify it. From looking at the nvnews forums, it appears that the issue remains unsolved. For those investigating, please note that this did not occur with Warty or Hoary.

I have one very stable system with MSWindows and the nv driver. When I install the nvidia-glx package the system is stable for some minutes, sometimes hours. When I use some glx, 3d, zoom, or render application the system crash completely. I send to you where I think is the problem -->

http://www.nvnews.net/vbulletin/showthread.php?t=64682

My system is not stable with the nvidia-glx package or propietary driver. With Dapper and edgy.

The main problem is that I need the tv-out.

--------------
I have one RS480/ATI Xpress 200P Chipset (compaq presario sr1419ES) with pci-x nvidia gforce 6200 TC
---------------------

Regards,

I have the same problem, using nvidia-glx-legacy on two of my computers, both of which have a geforce 2 , one being a GTS Pro (Asus), the other one is a MX 400.

Whenever I use the nvidia driver with Xorg, I get lockups.

Note that this ONLY HAPPENS on Xorg. If I use XGL, the system remains perfectly stable. This is SURELY a Xorg bug/incompatibility with the nvidia driver. I can confirm this on both of my systems.

It is not so much a bug in the Xorg XRender extension, so much as a bug in the combination of the Xorg XRender extension and the NVidia binary drivers. As the NVidia source is closed, the Xorg developers are unable to determine the cause of the issue and address it, and NVidia believes it to be a Xorg bug, and has not made visible attempts to address it. It may be that a migration to XGL will address these issues (as the NVidia drivers may be more optimised for correct behavior with GL than with 2D rendering), it may be that open drivers will allow the bug to be investigated, or there may be other changes to Xorg XRender that inadvertently avoid creating the situation responsible for this bug. If you must use Xorg, plesae consider disabling XRender if you are encountering this freeze.

Try Xubuntu, I Just changed to it and my lockup problems are solved :)
that would imply that the Nvidia driver doesn't like something in Gnome.

It's not GNOME generally, so much as the XRender Cairo backend. The NVidia driver seems to have trouble with power management when switching between (or simultaneously using) XRender and OpenGL. If one of these is avoided, there are no issues. Note that many users report more success when using a GL-based desktop, perhaps indicating the problem is with context swtiching between 2D and 3D acceleration. I'm sure that other major users of XRender along with OpenGL have the same issue (on nvnews.net, this issue has also been reported with KDE).

Emmet Hikory wrote:
> other major users of XRender along with OpenGL have the same issue (on
> nvnews.net, this issue has also been reported with KDE).
>
It would be good to track down those bug reports and link them all
together here so we can see who's making progress on the issue in other
communities.

Bug #109643 might be related to this one if this is power management (i.e. cpu scaling) related...

I'm getting random freezes with the Nvidia-glx package too. The computer doesn't respond to anything when it freezes. Ctrl Alt Backspace does nothing, neither does Ctrl Alt F1. I cannot reproduce this with the nv drivers, only the Nvidia-glx driver. I only seem to be able to reproduce this on my laptop also. Dell Inspiron 8200 with a Nvidia GeForce 2 Go. 32MB
The 9631 driver works perfectly on Dapper. No problem there.

[Expired for linux-restricted-modules-2.6.15 (Ubuntu) because there has been no activity for 60 days.]

Upgraded to 12.04 Success
Installed nvidia driver rebooted Desktop froze then flased and the menu bar at the bottom dissapeared.
Windo popped up saying compix crashed.

Uninstall nvidia driver rebooted and Success.

nvidia driver poor