Bug 89273

Summary:

[NVA8] nouveau screen corruption and X lockup when reclocking

Product:

xorg

Reporter:

Max Sydorenko <maxim.stargazer>

Component:

Driver/nouveau

Assignee:

Nouveau Project <nouveau>

Status:

RESOLVED MOVED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

frederic.romagne, maxim.stargazer

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Thinkpad T410, Quadro NVS 3100M (256M GDDR3) vbios dump	none
dmesg of reclock without X	none
dmesg of reclock with X (and glxgears)	none

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

Comment 6 Martin Peres 2019-12-04 08:56:09 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/172.

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.