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?
Created attachment 113735 [details] dmesg of reclock without X dmesg of reclock without X running (to pstate f and back to 7)
Created attachment 113736 [details] dmesg of reclock with X (and glxgears)
(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.
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.
> 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
-- 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.