nouveau graphical corruption in 3.13.2 (original) (raw)

Daniel J Blueman daniel at quora.org
Sat Feb 8 07:38:11 PST 2014

On 8 February 2014 16:33, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

On Sat, Feb 8, 2014 at 2:58 AM, Daniel J Blueman <daniel at quora.org> wrote:

Hi guys,

With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm seeing significant graphical corruption and later unrecoverable GPU lockup, accompanied by thousands of ILLEGALMTHD or related kernel messages [1]. I see similar issues on 3.12 also. Is there any debugging or testing I can do to help diagnose this? Is this new? i.e. was there a kernel where it all worked well? You get caught by the new disable logic in 3.13 that looks at a register to figure out what engines have been disabled: [ 6.306005] nouveau W[ PCE0][0000:04:00.0] disabled, PCE0=1 to enable Perhaps it's actually there and we have incorrect information about the feature disable register -- you can force-enable it with nouveau.config=PCE0=1 if you like. Although this logic is new in 3.13, so if you also saw the issue in 3.12, that's probably not the cause. (Also, the in-kernel logic falls back to M2MF, and so does the DDX, and I don't see any usage in mesa, so even if it's incorrectly disabled, I doubt this would be your issue.) Another thing that's new in 3.13 is MSI -- you can disable it with nouveau.config=NvMSI=0. There's only one currently-open bug about NVAF: https://bugs.freedesktop.org/showbug.cgi?id=60150 -- unfortunately the bug filer wasn't very specific about the issues. But it might be worth trying an ancient kernel (e.g. pre-3.7 -- there was a big rewrite in 3.7, or even one of those 3.2-based franken-kernels that distros maintained.) I suppose if you were to boot with nouveau.noaccel=1 your problems would go away, but so would any 2d/3d accel. [ 85.751375] nouveau E[ PFIFO][0000:04:00.0] DMAPUSHER - ch 3 [Xorg[919]] get 0x0020022a4c put 0x0020023140 ibget 0x00000391 ibput 0x000003c2 state 0x8000e6a8 (err: INVALIDCMD) push 0x00400040 I've seen this kind of error before, on many different card types, and have no clue how it happens -- at no point is that command actually written to the ring (I think). After that happens, it looks like things get a little upset, and basically nothing works again. When I've seen it before things tend to recover, but I guess they don't have to. I wouldn't be surprised if this was some sort of issue in the fifo context switch code (which I'm most unfamiliar with, but others know more). It has all sorts of chipset-specific stuff, and chances are nvaf wasn't well-represented when all those were made. Assuming there isn't an earlier working version of nouveau, one avenue is to do a mmiotrace (https://wiki.ubuntu.com/X/MMIOTracing) of the blob starting X and running e.g. glxgears. Then one would have to look at what ctxprog it uploads and reconcile that with nouveau's somehow. (But perhaps this is entirely wrong and nouveau's ctxprogs are fine.)

Superb writeup! Indeed, booting with nouveau.config=PCI0=1 didn't help as you deduced, nor did nouveau.config=NvMSI=0.

Interestingly, there was graphical failure booting 3.6.11, even nvidia-current fails to initialise, but these two issues could be due to running the Xorg stack in Ubuntu 14.04 pre-release. Using nouveau.noaccel=1 works great for the first X session, but after logging out, lightdm and the next session experiences this consistent screen corruption:

http://quora.org/nouveau-corruption.jpg

Changing to other resolutions except 1280x800 (native panel resolution), there is no corruption, but the corruption is consistently there when changing back to 1280x800. What would be good to look out for to help diagnose this?

Obviously noaccel is a very useful and important fallback. For the accelerated case, I'll wait until the Nvidia blob works in Ubuntu 14.04, then employ MMIO tracing and follow up with the differences I find.

Many thanks, Daniel

Daniel J Blueman

More information about the dri-devel mailing list