Created attachment 88580 [details] Screenshot demonstrating the issue An apparent redrawing/update issue / regression appeared as I updated to latest git the intel ddx: When opening a terminal window (urxvt 9.18), parts of the window sometimes fail to draw or update properly. This is especially apparent when switching to another virtual desktop and then back again to the one with the terminal window, the upper half of the window fails to draw. Sometimes other parts may fail as well. I have not noticed this problem with any other applications, however. Git-bisected to commit 638d4f60285709b6efc04cef72d4b530460e3239 sna: Remove the move-to-gpu shortcircuiting for partial GPU, no CPU damage -- Window manager: WindowMaker 0.95.4 -- chipset: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10) -- system architecture: i686 / 32bit -- xf86-video-intel: GIT 4a7217b05c232484a80abc7bd67494996dd32057 -- xserver: X.Org X Server 1.14.3-4 from latest Debian testing -- mesa: 9.2.2-1 from Debian testing -- libpixman: 0.30.2-1 -- libdrm version: 2.4.46-3 -- kernel version: 3.11.6 (vanilla+grsec) -- Linux distribution: current Debian Testing -- Machine or mobo model: Asus P5KPL-CM -- Display connector: VGA
Does it require anything in particular on workspace 2 (or a particular webpage)? I've set my machine up roughly identically to yours (other than a different kernel and probably completely different font configuration for urxvt etc) and I'm just wondering if there is anything else I can do to make this more likely to happen... (Hmm, actually not using userptr is one...)
For the record, disabling userptr alone is not enough to make my system trivially misbehave. Any suggestions welcome!
Nothing new to suggest, issue still present in GIT head (587c4866652e40e1e228b333028114766a6d3b08), reverting 638d4f60285709b6efc04cef72d4b530460e3239 fixes it (at least seemingly). Steps I've used to reproduce are: 1) startx 2) On initial WindowMaker workspace (#1), open urxvt terminal 3) Switch to workspace #2 (I use alt+2, not sure if that is the default binding) then back to workspace #1 (alt+1) 4) Upper half of the terminal should now be empty (typically the shell prompt not visible, if no other application run in the terminal.) --- optional --- 5) "ls -l" or something to produce output, this should look a bit wonky as only the lower half of the terminal will draw the damaged areas correctly. 6) Hitting enter several times after 5) should demonstrate weirdly updating damaged areas. Oh, and this is on x86-32bit, of course, seems I've forgotten to mention that - sorry. :(
Created attachment 88668 [details] Xorg.log with --enable-debug=full while reproducing the problem No idea if this is of any use, but attached Xorg.log with --enable-debug=full where reproducing the issue as described in the previous comment. Compressed with xz due to the large size.
3.10 kernel? Did that actually get all the GEM fixes? Can you check with a 3.12?
Or maybe I was just reading the wrong log. Ignore me...
Created attachment 88731 [details] [review] Use MOVE_READ when promoting partial move_area to full move_to_gpu Spotted this in the trace - certainly a bug, but is it the bug?
Lo, and behold! It was :) Tried git head this morning - bug still there. Applied the patch - and it works. Thanks!
Thanks! commit 736b496b458d666416ea94f157c05ce78f98a600 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Nov 5 21:33:18 2013 +0000 sna: Mark partial move_area_to_gpu with MOVE_READ on promotion to move_to_gpu When promoting a partial move_area_to_gpu to a full move_to_gpu, we have to disable certain optimisations that we try to use if MOVE_READ==0. Reported-and-tested-by: Matti Hamalainen <ccr@tnsp.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71198 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.