lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 22 Feb 2014 23:33:04 -0500
From:	Ilia Mirkin <imirkin@...m.mit.edu>
To:	Daniel J Blueman <daniel@...ra.org>
Cc:	Ben Skeggs <bskeggs@...hat.com>, Dave Airlie <airlied@...ux.ie>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Maarten Lankhorst <maarten.lankhorst@...onical.com>,
	Marcin Slusarz <marcin.slusarz@...il.com>
Subject: Re: nouveau graphical corruption in 3.13.2

On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman <daniel@...ra.org> wrote:
> On 9 February 2014 02:57, Ilia Mirkin <imirkin@...m.mit.edu> wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman <daniel@...ra.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists