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 #77 from Andreas Loew <awl1 at gmx.net> --- Sorry that it took me longer to get back here - I needed an additional rpmbuild run due to running out of disk space for my first attempt... But I can give an all clear signal - at least for my machine, AFAIK, everything seems to be fine: Kernel command line: ro

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #71 from Andreas Loew <awl1 at gmx.net> --- Hello Ilia, hmm - you just caught me with the update five minutes after I had started the rpmbuild with the previous version... ;-) Unfortunately, while I could make the first patch apply to a current RHEL kernel source with only one change (core/engine/device.c ->

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #69 from Andreas Loew <awl1 at gmx.net> --- > 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... OK - that might indeed explain the issues seen... Here you are: [aloew at aloew-lap nva]$ sudo

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #47 from Andreas Loew <awl1 at gmx.net> --- Hi - it's me again ;-) > 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 >

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #32 from Andreas Loew <awl1 at gmx.net> --- Many thanks for your quick reply - even on a Sunday! :-) Regarding: "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." the main issue is that I need to build a

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #82 from Andreas Loew <awl1 at gmx.net> --- Hi Thomas, > I have the same NVIDIA GeForce NVS 130M with the disabled functions. > I checked with nvapeek: > 0000154c: 0000009c > 00001540: b1010001 great - finally somebody who confirms this issue. > uname -a delivers > Linux mobuntu 3.11.0-15-generic #23-Ubuntu

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #17 from Andreas Loew <awl1 at gmx.net> --- Created attachment 90715 --> https://bugs.freedesktop.org/attachment.cgi?id=90715&action=edit Distorted graphics with RHEL6/OL6 showing uname -a kernel 3.12.4 -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #28 from Andreas Loew <awl1 at gmx.net> --- This gets really interesting now: Oracle public yum "playground" 3.6.11-3.6.y.20121225.ol6 (should be stock kernel 3.6.11) does NOT show any hangs, but DOES INDEED ALREADY show the graphics corruption issue FOR ME (although it was thought by the original posters here that it

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #27 from Andreas Loew <awl1 at gmx.net> --- Hmm - bad news once again: I have now compiled and tested a 3.6.kernel to match the commit immediately before the "mega commit", i.e. the kernel tarball has been produced by the following command: $ git archive --format=tar

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #22 from Andreas Loew <awl1 at gmx.net> --- Hello Ilia, regarding (a) and (b): I am just waiting for a rpmbuild of an OL6 version of 3.13-rc3 to finish and will report back on my findings and include a dmesg output from that version. Regarding (c): Would'nt it make more sense than starting with 3.6 release and 3.7 release

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #58 from Andreas Loew <awl1 at gmx.net> --- > > [aloew at aloew-lap envytools-master]$ sudo ./nva/nvapeek 10200c 10 > > 0010200c: SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS SS > > nvapeek 10200c without the 10. (Not sure what that does.... maybe reads out > 0x10 regs) yes - seems to read 10 registers:

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #66 from Andreas Loew <awl1 at gmx.net> --- A Happy New Year to everybody! :-) Just wondering whether you intend to simply close this issue down with the workaround "solution" for me to set kernel option nouveau.config=PCRYPT=0 or whether you are still interested in finding out *why* my Quadro NVS 130M and other

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #65 from Andreas Loew <awl1 at gmx.net> --- Oops - I just remembered that I am booting my kernel with "nouveau.config=PCRYPT=0" in the meantime... Does this make any difference, i.e. do I need to retry the nvapeek/nvapoke sequence without this kernel option? Sorry & thanks, Andreas -- You are receiving this

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #19 from Andreas Loew <awl1 at gmx.net> --- Hello, I would like to join discussions in this bug, as I have found myself affected after the recent update from Red Hat Enterprise Linux/Oracle Linux 6.4 (stock RHEL kernel 2.6.32-358.23.2) to RHEL/OL 6.5 (RHEL kernel 2.6.32-431). My graphics card is NVidia Quadro NVS 130M: BOOT0

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #73 from Andreas Loew <awl1 at gmx.net> --- Yes, definitely, a RHEL6 stock kernel is *very* old (2.6.32.*) - but due to a kernel drm/nouveau module update from 3.x source that they recently did for RHEL 6.5, it also suddenly became new enough to make me see this issue... ;-) Have just successfully applied the updated patch to

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #74 from Andreas Loew <awl1 at gmx.net> --- Just received drivers/gpu/drm/nouveau/core/subdev/devinit/nv50.c:164: error: 'NVDEV_ENGINE_VIC' undeclared (first use in this function) but "fixed" it for me by commenting out the lines for a 0xaf card (I have a 0x86 type anyway, so this code does not apply to me):

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #75 from Andreas Loew <awl1 at gmx.net> --- Created attachment 91786 --> https://bugs.freedesktop.org/attachment.cgi?id=91786&action=edit Complete dmesg output booting 3.12.6 with "hwunits.patch" applied (nouveau.debug=debug) -- You are receiving this mail because: You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #76 from Andreas Loew <awl1 at gmx.net> --- Created attachment 91787 --> https://bugs.freedesktop.org/attachment.cgi?id=91787&action=edit nouveau-related dmesg output booting 3.12.6 with "hwunits.patch" applied (nouveau.debug=debug) -- You are receiving this mail because: You are the assignee for the bug.

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 #29 from Andreas Loew <awl1 at gmx.net> --- OK, finally I have some more encouraging news: It now looks like the issue indeed started much earlier than initially thought, namely already between the 3.4 and 3.5 kernel series!!! Results from my testing with stock kernels obtained from kernel.org (I've never ever before