| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
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