On Sat, Feb 8, 2014 at 2:58 AM, Daniel J Blueman <daniel@xxxxxxxxx> 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 ILLEGAL_MTHD 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/show_bug.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] DMA_PUSHER - ch 3 [Xorg[919]] get 0x0020022a4c put 0x0020023140 ib_get 0x00000391 ib_put 0x000003c2 state 0x8000e6a8 (err: INVALID_CMD) 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.) -ilia _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
