similar to: [Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #88 from Andreas Loew <awl1 at gmx.net> --- (In reply to comment #87) > > has there been any progress so far in getting this into the mainstream Linux > > kernel (or mainstream git) for the next official kernel release? > This should be upstream as of commit > 4019aaa2b314a5be9886ae1db64ff8c6d3c060ed,

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #86 from Andreas Loew <awl1 at gmx.net> --- Hello Ilia, has there been any progress so far in getting this into the mainstream Linux kernel (or mainstream git) for the next official kernel release? I'd like to make an attempt to get this patch (or rather, a backport of it) into official RHEL 6.x kernels, but I'd like

https://bugs.freedesktop.org/show_bug.cgi?id=58378 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #91714|0 |1 is obsolete| | --- Comment #70 from Ilia Mirkin <imirkin at

https://bugs.freedesktop.org/show_bug.cgi?id=58378 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Distorted graphics on |[NV86] Distorted graphics |NVIDIA GeForce 8400M G |on NVIDIA GeForce 8400M G

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #81 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #80) > Hello, > > I have the same NVIDIA GeForce NVS 130M with the disabled functions. > I checked with nvapeek: > 0000154c: 0000009c > 00001540: b1010001 > > uname -a delivers > Linux mobuntu 3.11.0-15-generic #23-Ubuntu SMP Mon

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #21 from Ilia Mirkin <imirkin at alum.mit.edu> --- (a) Can we see a full boot log (e.g. output of dmesg) with a recent kernel? Ideally it would include the time that the visual issues happen. (b) This looks like it could be a fencing issue, i.e. we try to draw to a texture, but then instead of waiting, we don't wait. There

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #23 from Ilia Mirkin <imirkin at alum.mit.edu> --- The mega-commit is ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69. So you could check out ebb945a94bba^ and see if it works, and then test ebb945a94bba to see if it doesn't. In either case, you could use those as your new "good" or "bad" starting points. You

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #31 from Ilia Mirkin <imirkin at alum.mit.edu> --- You really need to figure out how to do things inside the git tree and not do some sort of crazy export. That will speed things up by an order of magnitude. To get the list of nouveau changes between 3.4 and 3.5: git log v3.4..v3.5 -- drivers/gpu/drm/nouveau To do a bisect

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #36 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #35) > Follow-up question note that I am digging deeper into git... ;-) > > From the commits in the v3.4..v3.5 range, only two of them: > > 9bd0c15fcfb42f6245447c53347d65ad9e72080b (dated Jun 26, 2012) and >

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #41 from Ilia Mirkin <imirkin at alum.mit.edu> --- The fix for that compilation issue is contained in d1b167e168bdac0b6af11e7a8c601773639fc419 Basically you need to make nouveau_channel_idle return an int, and just stick a 'return ret' at the end. And adjust the prototype in nouveau_drv.h. -- You are receiving this

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #44 from Ilia Mirkin <imirkin at alum.mit.edu> --- Try commenting the same line out and see what happens... (i.e. the one with 0x74c1) FWIW I do remember seeing some PCRYPT-related (and PVP/PBSP-related) errors on start in the form of MMIO write failures in your log and thinking it odd: nouveau E[ PBUS][0000:01:00.0] MMIO

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #46 from Ilia Mirkin <imirkin at alum.mit.edu> --- Well, given that it doesn't work on the blob makes it sound like you have some sort of funkiness in your hardware. One unsubstantiated theory is that the vdec clock is *disabled*, and pcrypt is hooked up to that clock. Or perhaps that clock is somehow broken. It'd be

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #51 from Ilia Mirkin <imirkin at alum.mit.edu> --- So actually I'm told that pcrypt is on the main clock, so that theory is out. Can you grab envytools (https://github.com/envytools/envytools) and run nvapeek 10200c nvapoke 10200c 10 nvapeek 10200c and see what's in dmesg?Do you see additional MMIO read/write failures,

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #54 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #52) > Hello again, Ilia, > > > Can you grab envytools (https://github.com/envytools/envytools) and run > > bad news (or maybe expected from what we have been seeing earlier): > > [aloew at aloew-lap envytools-master]$

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #57 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #55) > > > [aloew at aloew-lap envytools-master]$ ./nva/nvapoke 10200c 10 > > > WARN: Can't probe 0000:01:00.0 > > > PCI init failure! > > > You need to run these as root. > > Ouch - sorry - could have indeed

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #59 from Ilia Mirkin <imirkin at alum.mit.edu> --- There was a bug in nvapeek/poke (it was using the wrong address space by default), can you update your pull and try again? [That explains why you saw 'S' in the output.] -- You are receiving this mail because: You are the assignee for the bug. -------------- next part

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #63 from Ilia Mirkin <imirkin at alum.mit.edu> --- Yeah, it prints "..." instead of 0. This makes a lot of sense when you're peeking a large range full of 0's. Anyways, were there any additional messages in dmesg, e.g. MMIO read/write failures as a result? -- You are receiving this mail because: You are the

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #67 from Ilia Mirkin <imirkin at alum.mit.edu> --- Could you provide the output of nvapeek 154c nvapeek 1540 Those registers specify which engines are there. I think we're ignoring them in nouveau... -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #68 from Ilia Mirkin <imirkin at alum.mit.edu> --- Created attachment 91714 --> https://bugs.freedesktop.org/attachment.cgi?id=91714&action=edit patch to honor disabled engines Give this a shot (without forcing PCRYPT=0). You should hopefully see a message saying that it and a few other engines are disabled. This needs

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #72 from Ilia Mirkin <imirkin at alum.mit.edu> --- (In reply to comment #71) > Would 3.12.6 be an appropriate version to apply your updated patch to > successfully? I'm working against, effectively, 3.13-rc8. I'd think it would apply to 3.12, and just about any other semi-recent kernel, but I guess RHEL does