Re: nouveau graphical corruption in 3.13.2

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman <daniel@xxxxxxxxx> wrote:
> On 9 February 2014 02:57, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman <daniel@xxxxxxxxx> wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current fails to initialise, but these two issues could be due
>>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>>> nouveau.noaccel=1 works great for the first X session, but after
>>> logging out, lightdm and the next session experiences this consistent
>>> screen corruption:
>>>
>>> http://quora.org/nouveau-corruption.jpg
>>
>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>> points to some key lack of understanding of... something. With
>> noaccel, we're not using pgraph or anything fancy -- it's just a
>> framebuffer, basically. So if we can't even render _that_ right...
>>
>> Hopefully someone else will pipe up re your other issues -- my
>> knowledge base on this is exhausted :(
>
> Interestingly, it turns out that the screen corruption occurs on every
> boot (booting with nouveau.noaccel=1 for now), and I can consistently
> work around it by one suspend-resume cycle.
>
> To that effect, I've captured kernel message output booting 3.14-rc3
> with 'nouveau.noaccel=1 nouveau.debug=trace,DEVINIT=spam drm.debug=0x6
> log_buf_len=16M', and performed a suspend-resume cycle:
> http://quora.org/nouveau-log.txt

An observation:

on boot:

[    7.086599] [drm:drm_crtc_helper_set_mode], [ENCODER:16:LVDS-16]
set [MODE:29:1280x800]
[    7.150571] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000010
0x00000020
[    7.164662] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000020
0x00000030
[    7.164903] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000040
0x00000030

on resume:

[   59.538135] [drm:drm_crtc_helper_set_mode], [ENCODER:16:LVDS-16]
set [MODE:29:1280x800]
[   59.539586] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000010
0x000002a0
[   59.540738] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000020
0x000002b0
[   59.540812] nouveau T[   VBIOS][0000:04:00.0] 0x547f[0]: SUB_DIRECT 0x556f
[   59.540814] nouveau T[   VBIOS][0000:04:00.0] 0x556f[1]: NV_REG
R[0x4061c00c] &= 0xfffffffe |= 0x00000000
[   59.540818] nouveau T[   VBIOS][0000:04:00.0] 0x557c[1]: NV_REG
R[0x4061c00c] &= 0xfffffffe |= 0x00000001
[   59.540836] nouveau T[   VBIOS][0000:04:00.0] 0x5589[1]: TIME 0x3e80
[   59.556702] nouveau T[   VBIOS][0000:04:00.0] 0x558c[1]: NV_REG
R[0x4061c00c] &= 0xfffffffe |= 0x00000000
[   59.556714] nouveau T[   VBIOS][0000:04:00.0] 0x5599[1]: DONE
[   59.556716] nouveau T[   VBIOS][0000:04:00.0] 0x5482[0]: ZM_REG_SEQUENCE 0x05
[   59.556718] nouveau T[   VBIOS][0000:04:00.0] 0x5488[0]:
R[0x4061c00c] = 0x01060200
[   59.556720] nouveau T[   VBIOS][0000:04:00.0] 0x548c[0]:
R[0x4061c010] = 0x0310000a
[   59.556721] nouveau T[   VBIOS][0000:04:00.0] 0x5490[0]:
R[0x4061c014] = 0x00000000
[   59.556723] nouveau T[   VBIOS][0000:04:00.0] 0x5494[0]:
R[0x4061c018] = 0x000f4af8
[   59.556725] nouveau T[   VBIOS][0000:04:00.0] 0x5498[0]:
R[0x4061c01c] = 0x0001caf0
[   59.556726] nouveau T[   VBIOS][0000:04:00.0] 0x549c[0]: SUB_DIRECT 0x55c5
[   59.556728] nouveau T[   VBIOS][0000:04:00.0] 0x55c5[1]: NV_REG
R[0x00e1e4] &= 0xfffffffc |= 0x00000000
[   59.556741] nouveau T[   VBIOS][0000:04:00.0] 0x55d2[1]: NV_REG
R[0x00e100] &= 0xfff7ffff |= 0x00080000
[   59.556751] nouveau T[   VBIOS][0000:04:00.0] 0x55df[1]: ZM_REG_SEQUENCE 0x02
[   59.556753] nouveau T[   VBIOS][0000:04:00.0] 0x55e5[1]:
R[0x4061c118] = 0x15151515
[   59.556754] nouveau T[   VBIOS][0000:04:00.0] 0x55e9[1]:
R[0x4061c11c] = 0x00000015
[   59.556756] nouveau T[   VBIOS][0000:04:00.0] 0x55ed[1]: ZM_REG_SEQUENCE 0x02
[   59.556757] nouveau T[   VBIOS][0000:04:00.0] 0x55f3[1]:
R[0x4061c198] = 0x15151515
[   59.556759] nouveau T[   VBIOS][0000:04:00.0] 0x55f7[1]:
R[0x4061c19c] = 0x00000015
[   59.556760] nouveau T[   VBIOS][0000:04:00.0] 0x55fb[1]: SUB_DIRECT 0x5e02
[   59.556762] nouveau T[   VBIOS][0000:04:00.0] 0x5e02[2]: DONE
[   59.556763] nouveau T[   VBIOS][0000:04:00.0] 0x55fe[1]: DONE
[   59.556765] nouveau T[   VBIOS][0000:04:00.0] 0x549f[0]: SUB_DIRECT 0x55ff
[   59.556766] nouveau T[   VBIOS][0000:04:00.0] 0x55ff[1]: DONE
[   59.556767] nouveau T[   VBIOS][0000:04:00.0] 0x54a2[0]: DONE
[   59.811966] nouveau D[   PDISP][0000:04:00.0] supervisor 0x00000040
0x000002b0
[   59.812033] nouveau T[   VBIOS][0000:04:00.0] 0x5600[0]: DONE

I'm pretty weak on that supervisor logic, unfortunately. But somehow
on boot it's not saying to execute the vbios snippet? Perhaps that's
normal though? Ben?

Also, Daniel -- first off, DEVINIT doesn't really do very much (you
might be thinking it has something to do with device init... while you
wouldn't be completely wrong, you also wouldn't be right enough).
Debug levels below "trace" need a special kernel recompile (there's a
config option for how low to compile in, otherwise there'd be too much
overhead). spam causes nv_wr*/nv_rd* to each print lines, so... a
_lot_ of output. A mmiotrace might be more concise :)

Daniel -- you could try to hack things in the supervisor handler
(core/engine/disp/nv50.c iirc, but just grep for that supervisor debug
print) s.t. it thinks the supervisor values are s.t. it should execute
vbios stuff.

  -ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/