185.18.14: any OpenGL causes Xorg to crash and then hang

[etherfish]

The driver seems to work fine until I attempt to use any OpenGL - even glxgears. Any OpenGL seems to work for the first few seconds then the X-server seems to hang. SSH'ing in from another machine shows Xorg segfaulting in the dmesg and a few NVIDIA error messages. A backtrace never appears to make it into /var/log/Xorg.0.log. Afterwards, Xorg wont completely die unless kill'd with SIGKILL (9).

[ 219.310111] NVRM: Xid (0003:00): 16, Head 00000000 Count 00000162
[ 221.305104] NVRM: Xid (0003:00): 8, Channel 00000003
[ 221.307891] Xorg[5615]: segfault at 0 ip 00000030000110c2 sp 00007fffffffd898 error 4 in ld-2.9.so[3000000000+1d000]
[ 221.313459] NVRM: Xid (0003:00): 12, COCOD 00000001 e0012d00 0000502d 00001000 10000080

I realize I'm running a testing kernel, but I think this may possibly be a useful datapoint. Am happy to provide devs any other information they may like. Running 185.18.10 again.

[conky]

I'm having the same problem. OpenGL apps cause X to freeze. The display locks on start of KDE 4.2 with desktop effects enabled. With XIDs appearing in the system log. I was able to ssh in to create a bug report and use Magic SysRq to reboot.

I started up a simple session with twm and some xterms, and the XIDs appear in the system log as soon as I start an OpenGL app such as glxgears:
NVRM: Xid (0002:00): 8, Channel 00000001
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000003
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000004
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000005
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000007
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000009
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000011
NVRM: Xid (0002:00): 16, Head 00000000 Count 00000012

The machine freezes temporarily in this case, but glxgears eventually displays. As glxgears runs, it periodically outputs an XID in the log.

[weedburner]

I can confirm this. Reverting back to 185.18.10 solves the problem.

[technogeeky]

I may be a bit synical, but I don't understand how a regression (if that word is even appropriate) of this magnitude can occur in any software package. In a software package that wasn't a driver, I would assume that this kind of thing would be a very basic unit test that must occur before a build is released.

I haven't tried it out yet; I was hoping to try it and find that maybe the Xinerama / Composite incompatibility was fixed, but this certainly puts a stop to that.

Patience...

[tadawson]

glxgears works fine here at about 25,000 FPS. GPU is a 9800GLX+ with the 185.18.14 driver, and XFree86 4.8.0 . . . . so definitely not a hard driver problem . . . .

- Tim

[jyavenard]

Originally Posted by tadawson

glxgears works fine here at about 25,000 FPS. GPU is a 9800GLX+ with the 185.18.14 driver, and XFree86 4.8.0 . . . . so definitely not a hard driver problem . . . .

- Tim

25000fps with a 9800 ??
I tried glxgears on a 9800 a few days ago, but I got around 4000 fps max

[Dragoran]

Originally Posted by jyavenard

25000fps with a 9800 ??
I tried glxgears on a 9800 a few days ago, but I got around 4000 fps max

glxgears is not a benchmark.


@Topic:

I can confirm the issues on my GTX 285.
Running glxgears causes X to hang.

[Dragoran]

OK, this seems only to happen when PCI MSI is enabled.
With legacy interrupts its fine.

Comparing the two attached bug reports seems to confirm this (both are using MSI).

[Dragoran]

Originally Posted by technogeeky

I may be a bit synical, but I don't understand how a regression (if that word is even appropriate) of this magnitude can occur in any software package. In a software package that wasn't a driver, I would assume that this kind of thing would be a very basic unit test that must occur before a build is released.

PCI MSI is disabled by default, so they likely did not test with it enabled.