[FIXED] Compositing-related freezes on KDE with every post-334.21 driver

Since upgrading to 337.25 or 340.24, any attempt to resize a OpenGL window causes instant (KDE) desktop freeze.

Sometimes switching to a text VT and back works (leaving olny transient garbage on the X desktop), but in most cases a hard reset is required.

Reverting to 334.21 fixes the problem.

[EDIT] Also disabling compositing allows GL windows to be resized without crashing.

nvidia-bug-report.log.gz (94.3 KB)

Problem still present in 343.22.

Steps to reproduce:

  1. Open a GL window, e.g. GoogleEarth
  2. Attempt to resize window

Result: desktop freezes. In 50% of the cases it is possible to switch to VT (and kill X) after ~1-2 minutes.

dmesg shows a lot of this:

NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000

OK, this is definitely related to compositing. If I disable compositing using the KDE hotkey, window resize works as expected. Switch it back on, and it’s a constant freeze (with lots of Xid 31’s).

It appears that NVIDIA has changed the way compositing manager calls are handled in 337.25, probably exposing bugs in specific versions of KDE and/or xorg. Unfortunately, for distros with locked-down component versions (like RHEL or CentOS) that means that we are totally dependent on NVIDIA to provide a workaround.

This is probably the same problem:

https://bbs.archlinux.org/viewtopic.php?id=182438

Same on 346.16. But this time dmesg looks slightly more helpful:

NVRM: GPU at PCI:0000:01:00: GPU-a34de991-baca-804d-d491-198a5103c530
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 0: 3D-CT KIND Violation. Coordinates: (0x80, 0x0)
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x500420=0x80000100 0x500434=0x80 0x500438=0x3d00 0x50043c=0x10017
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 0003, Class 00009097, Offset 00002398, Data 00000000
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 0: 3D-CT KIND Violation. Coordinates: (0x80, 0x0)
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x500420=0x80000100 0x500434=0x80 0x500438=0x3d00 0x50043c=0x10017
NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ChID 0003, Class 00009097, Offset 00002398, Data 00000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000
NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000

The 343.36 changelog contains this item:

  • Fixed an OpenGL issue that could cause glReadPixels() operations to be improperly clipped when resizing composited application windows, potentially leading to momentary X freezes.

alas no luck: X still hangs on 343.36 and 346.22 on every attempt to resize GL windows, with lots of these:

NVRM: Xid (PCI:0000:01:00): 31, Ch 00000003, engmask 00000101, intr 10000000

Please note that this is on a cleanly-installed CentOS due to a disk crash last week, so it seems very unlikely to be a configuration issue.

I also have freezes with latest beta drivers on KDE (Netrunner 14).
I switch back to the latest version available in repo (331.38) and it works again.

Seems to be fixed in 346.35 (32bit).

Well, better late than never, I guess…

Are you sure this has been fixed in 346.35 and not “workarounded” in kde or something?

I’m still getting the same errors with nvidia 346.35(64-bit) with various different programs.

I installed Nvidia drivers 346.35 from this ppa and I had freezes.

I’m on Netrunner 14.1 x64 (Kubuntu derivative)

I try the drivers 346.35 from edgers ppa to see if there is a difference compared to mamarley ppa.

Can anyone with 32bit driver confirm that this is still broken with his system?
Or can any 64 bit user confirm that it isn’t?

Not sure if 64bit issue or just random :/

OK I test the 346.35 x64 drivers from edgers ppa for a week and no freeze.
So I think there is a problem with mamarley ppa.

I think I speaked too fast. Today I had a freeze with Nvidia drivers 346.65 from edgers ppa.

I don’t know if it’s a problem with the drivers or ppa or kde…

Maybe it’s because I installed hardware enablement stack yesterday, I don’t know… But I will stick to official drivers ;)

As far as I can tell, this bug can only be triggered by “modern” opengl operations… might have something to do with opengl contexts from different applications/threads getting in each others way while requesting buffers with write access or using buffer objects in general.

If I’m not way off with that interpretation, it should be possible to not encounter the bug at all - as long as you only have one thread at a time that uses vbo’s (etc) and all other opengl users only do “old style” stuff (glBegin etc).