Created attachment 91478 [details] dmesg output with bubble3d running ~16 hours (with one interruption) Computer failed second-stage burn-in testing. Was able to run mprime with blended tests overnight. Running the 3D screensaver (initially pinion) with mprime doing "in place FFTs" (loads CPU, cache, little memory): caused X to crash. Lightdm restarted it automatically, but I had no mouse pointer. I then upgraded all of the relevant software to newer versions: Package: xorg Version: 1:7.7+5 Package: xserver-xorg-video-nouveau Version: 1:1.0.10-1 Package: libdrm-nouveau2 Version: 2.4.50-1 Package: libgl1-mesa-dri Version: 9.2.2-1 Package: xscreensaver-gl Version: 5.23-1 uname -a Linux torchlight 3.11-2-686-pae #1 SMP Debian 3.11.10-1 (2013-12-04) i686 GNU/Linux Running bubble3d with mprime doing "in place FFTs", I get a soft lock-up within about 30 minutes. I switched to bubble3d because the screen with the mouse pointer was experiencing ~50% slow-downs even if the pointer was not drawn (it gives info about the gear under the pointer). All the GL screen savers also seem to suffer significant slow-downs with the option to display the frame-rate enabled. On the order of 20->5 fps. This slowdown was not as evident prior to the upgrade (so may be a regression). When running bubble3d for about 16 hours, with the computer otherwise idle, I logged two sets of Cache errors. However, without the soft lock-up. I plan to test with an ATI card to see the problems may be related to power stability rather than software. The motherboard is now about 10 years old, so the capacitors may be drying out.
Created attachment 91479 [details] reconstructed dmesg from kern.log after soft lock-up. Not only was this too long for dmesg, but I accidentally hit the power button on the keyboard. I trimmed the relevant kern.log to capture the relevant data. The soft-lock up happened within about 30 minutes (based on saved IRC logs). I did not intervene for hours (explaining the repeated messages). There really were two instances of bubble3d running: one for each display. One appears to complain about the cache error, while the other complains about the resulting CPU lock-up.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/84.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.