Nouveau - Dec 2013 - [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 #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
> that clock is somehow broken. It'd be interesting to see whether the
old blob
> version can be made to work, but I wouldn't spend _too_ much time on
it. May
> be easy to do with an older livecd or something.
I could try and do an install of RHEL6.2 (before the ABI change) onto an USB
HDD. On this version, 285.09 still ran fine. What exactly would you want me to
check with the "blob"?

Is there any diagnostic tool that could check about my "vdec clock" or
pcrypt
status?

In the meantime, I have verified that with the single line

 { "CRYPT", 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init },

commented out, a 3.12.4 kernel works fine - no corruption seen.
> So, in order to completely disable PCRYPT without patching your system you
> can boot with "nouveau.config=PCRYPT=0" in your kernel cmdline
(since 3.7, I > think). It will also disallow userspace from using PCRYPT,
which is probably > for the best if it's really broken. (Whereas just
commenting it out there
> prevents a very specific use-case of it.)
Also, booting both a stock 3.12.4 kernel and even the current RHEL 6.5 2.32-431
kernel with kernel commend line option "nouveau.config=PCRYPT=0" seems
to work
fine, which means that my basic issue is already resolved, as with this option,
I already seem to be able to make sure that future stock RHEL kernels won't
break my screen all the time... ;-)
> With a pre-3.13 kernel, you can also try adding nouveau.perflvl_wr=7777 
> nouveau.perflvl=1 which will force reclocking to happen on boot (to level
'1'
> which in your case is comparable to what you had been booting to anyways), 
> and just might get PCRYPT going (if the clock theory is right). Or hang
your
> machine. (Or both!) With 3.13 you'll need to apply a patch to enable
the
> reclocking functionality. [Obviously test this theory without the PCRYPT 
> disable stuff.]
Can you please provide more details about this?

I tried to pass the below options to stock kernel version 3.13.0-rc4 (as of Dec
16) but got the following message:

Command line: ro root=UUID=034d34cd-a464-4ee3-8db9-d6061a318a16 rd_NO_LUKS
LANG=en_US.UTF-8  KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys rd_NO_MD
SYSFONT=latarcyrheb-sun16 rd_NO_LVM rd_NO_DM nouveau.perflvl_wr=7777
nouveau.perflvl=1
[...]
nouveau: unknown parameter 'perflvl_wr' ignored
nouveau: unknown parameter 'perflvl' ignored

and then of course got the distorted screen again.

So what exactly do I need to do in order to be able to pass these two
parameters and see whether reclocking my "vdec" clock helps to
successfully use
the pcrypt feature?

Many thanks one more time,
Andreas

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20131218/0d3a3aec/attachment-0001.html>