Bug 89273 - [NVA8] nouveau screen corruption and X lockup when reclocking
Summary: [NVA8] nouveau screen corruption and X lockup when reclocking
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-21 22:31 UTC by Max Sydorenko
Modified: 2015-03-24 13:08 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump (62.50 KB, text/plain)
2015-02-21 22:31 UTC, Max Sydorenko
no flags Details
dmesg of reclock without X (157.17 KB, text/plain)
2015-02-21 22:34 UTC, Max Sydorenko
no flags Details
dmesg of reclock with X (and glxgears) (166.53 KB, text/plain)
2015-02-21 22:35 UTC, Max Sydorenko
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Max Sydorenko 2015-02-21 22:31:30 UTC
Created attachment 113734 [details]
Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump

Kernel: 3.19.1
Hardware: Thinkpad T410, Quadro NVS 3100M (256M GDDR3) [similar hw but different VRAM compared to bug 88415]
Problem: reclocking between pstates 3 and 7 is flawless, but reclocking to pstate f causes problems.
Possible scenarios:

1. X server is not running, trying to reclock from the fb. 
   echo f > pstate
  Image gets corrupted (vertical flickering lines), but there is no lockup and after
   echo 7 > pstate
everything gets back to normal. After that system works just fine.
Dmesg attached (with nouveau.debug=debug)

2. X server is running. 
   echo f > pstate
   Screen gets corrupted in similar fashion, but system locks up and after few second stops to respond even to SysRq.
I managed to get dmesg for this scenario too.

I also mmiotraced functioning reclocking with the nvidia blob. Trace is quite large (120MB). Should I truncate it somehow to upload, or just provide as is?
Comment 1 Max Sydorenko 2015-02-21 22:34:15 UTC
Created attachment 113735 [details]
dmesg of reclock without X

dmesg of reclock without X running (to pstate f and back to 7)
Comment 2 Max Sydorenko 2015-02-21 22:35:28 UTC
Created attachment 113736 [details]
dmesg of reclock with X (and glxgears)
Comment 3 Roy 2015-02-21 22:52:07 UTC
(In reply to Max Sydorenko from comment #0)
> Created attachment 113734 [details]
> Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump
> 
> Kernel: 3.19.1
> Hardware: Thinkpad T410, Quadro NVS 3100M (256M GDDR3) [similar hw but
> different VRAM compared to bug 88415]
> Problem: reclocking between pstates 3 and 7 is flawless, but reclocking to
> pstate f causes problems.
[...]
> I also mmiotraced functioning reclocking with the nvidia blob. Trace is
> quite large (120MB). Should I truncate it somehow to upload, or just provide
> as is?

Thanks for reporting. I've had very little GDDR3 cards to test with (in fact... just one), so these logs will be extremely useful. If you can, please provide the trace in full. Feel free to compress it using xz or similar.
Comment 4 Ilia Mirkin 2015-02-21 23:21:17 UTC
I believe the two issues are unrelated. The flickering issue is probably due to incorrect timing parameters somewhere. The hang is, more than likely, due to

[  144.038590] nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x00000040, ch 3

Which we don't handle currently. rnndb has it as

                        <bitfield pos="6" name="PEEPHOLE_FAULT"/>

So we probably have to reprogram PBUS.HOST_MEM.CHAN and PBUS.HOST_MEM.PEEPHOLE (or at the very least the latter) -- that's 0x1704 and 0x1710 respectively. Not 100% sure what they are, but software/nv50.c does:

	nv_wr32(priv, 0x001704, chan->vblank.channel);
	nv_wr32(priv, 0x001710, 0x80000000 | chan->vblank.ctxdma);

Hopefully someone who understands these things a little better will step in here.
Comment 5 Max Sydorenko 2015-02-21 23:32:32 UTC
> Thanks for reporting. I've had very little GDDR3 cards to test with (in
> fact... just one), so these logs will be extremely useful. If you can,
> please provide the trace in full. Feel free to compress it using xz or
> similar.
Here is direct link to xz-ed mmiotrace
https://www.dropbox.com/s/el0zzw80ttmt584/mmiotrace.log.tar.xz?dl=0


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.