Created attachment 110752 [details]
journal extract from the crash (with all the X tracebacks)

Just saw this again, but between occurrences I had a boot running for like three days with drm.debug=15 and it didn't happen, eventually I had to give up because I needed to see something else in my logs :( I'll try another boot with drm.debug=14 and hope to catch it...

Created attachment 111369 [details] [review]
Revert-drm-nouveau-fifo-g84-ack-non-stall-interrupt

Also G94 here, and the same bug. It works for a while then GPU locks up with "still angry after 101 spins". But, I bisected and eventually 19a10828814aa commit (drm/nouveau/fifo/g84-: ack non-stall interrupt before handling it) came out as culprit. It's the last nouveau commit before 3.18 was releases.

If you can compile your own kernel, I'm attaching the patch that reverses that commit. It fixes the issue for me completely, no more lockups.

awesome - I love it when someone else does the hard work. I'll build with that revert and confirm if I can, thanks! (it doesn't happen very often to me, so a bit hard to confirm a negative, but I'll do my best).

Ha ha ha, you made me laugh with "hard to confirm a negative" comment, been there - done that. :) This time I got a bit lucky, because I ran 3.18-rc-something the whole time (fixing some other kernel bugs I reported), and when 3.18 got released and suddenly become unstable there were only about a dozen nouveau commits to bisect. It was quite easy to find the faulty one.

Also, I was getting lockups pretty fast, about 6-12 hours after reboot, before I reverted that commit. And now my system has been rock solid for 2 weeks, so I'm pretty confident the revert is the right fix.

So I didn't hit this for like two weeks (12-26 till today) but then I hit it twice today. I'm now running a kernel with the reversion applied, so I guess I'll have to see if that survives three weeks? :)

Nouveau still angry in 3.19-rc5
Filed issue on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=91581

I've been up on the patched kernel for 2 weeks now without seeing the issue.

It'd be worth giving this patch a try:

http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=c869d99187a356b886bdecc757caa0038d142844

Created attachment 112875 [details]
fifo-nv04-remove-the-loop-from-the-interrupt-handler

Would not apply cleanly to 3.19.0-rc6+, so I modified it and attached the patch that I have currently applied and testing. I'd give it at least 2 days before we can be reasonably sure it fixes the issue.

Good news! 2 days and 13 hours later, no lockups, all fine. I'm pretty confident that this patch resolves the issue. It would be great if it could be applied before 3.19 stable comes out.

So Ben told me on IRC he'd committed a change that should address this, but I guess it didn't make it in time for 3.19 because I just hit it with 3.19 stable :( Ben, any chance it could be backported for 3.19 updates? It's a pretty icky bug.

(In reply to Adam Williamson from comment #12)
> So Ben told me on IRC he'd committed a change that should address this, but
> I guess it didn't make it in time for 3.19 because I just hit it with 3.19
> stable :( Ben, any chance it could be backported for 3.19 updates? It's a
> pretty icky bug.

If it's not yet pulled by Linus, what's the kernel git tree where that was submitted?

Just for reference, I cherry-picked that fix for my 3.18.6 and I no longer get the X stuck. Hoping it hits the stables soon...

I have the same problem and it is usually triggered within minutes of using PyCharm IDE. When I work with Eclipse and other things it seems fine but as soon as I have PyCharm running (even in the background while I am not working with it) this happens. I am using 3.18.7-200.fc21.x86_64.

Hi All,
We're having this issue on a whole bunch of F21 x86_64 machines. I took the 3.18.7-200 F21 source rpm, and applied Zlatko's patch from Comment 10, and rebuilt the kernel. The important rpms are here :
http://arif.easyss.net/stuff/kernel-3.18.7-nouveau/

I haven't actually rebooted any of the machines onto this kernel yet, but this might help some people.

JFTR, I've been running with the same patch applied for 3 weeks now and the system is rock solid. If you use 3.18 or 3.19 and experience lockups, the patch will fix it. Hopefully it finds its way to 3.20^H^H4.0 soon. :P

The patch is in Ben's personal tree already:

http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=c869d99187a356b886bdecc757caa0038d142844

but hasn't yet made its way from there into the nouveau tree from which it'd get merged to linus':

http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=linux-3.20

I have, however, prevailed on the Fedora kernel maintainers to put it in at least the F22/Rawhide kernels; the builds of both that are running as I type this will include it. I'm hoping we can get it backported from there to 21 as well.

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

This sounds horribly familiar.  Seeing the same behaviour after I hit the 3.18.x kernels with Fedora 20.  I'm using a "NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)".  Not sure if the additional card information helps or if the bug and fix are definitely the one posted.  Here's hoping it's brought into the mainline kernel soon... (but I will likely try recompiling my own kernel with the offered patch sometime soon.)

The fix is already in mainline, just hasn't been backported.

(In reply to Adam Williamson from comment #21)
> The fix is already in mainline, just hasn't been backported.

Is the fix going to appear in F21 any time soon?

-- 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/155.