Created attachment 92496 [details] Xorg log following sna: Include serial numbers in ValidateGC DBG +++ This bug was initially created as a clone of Bug #70905 +++ I was trying to trigger page flip error with 2.99.907-31-gde0797e --enable-debug=full build with no effect. Tried Spotify client (running in wine), got X Server termination with: (EE) sna_copy_boxes: damage box is beyond the pixmap: box=(1, 1), (32, 33), pixmap=(32, 32) Hence a new bug report, following: commit 50f6701aa5ce8be96e216a942880a8db967c7a6a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 20 20:47:15 2014 +0000 sna: Include serial numbers in ValidateGC DBG Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Oddly, attached Xorg.0.log shows no obvious error indication now. Checked twice with similar effect. Current Operating System: Linux 3.12.7-gentoo-gnu Integrated Graphics Chipset: Intel(R) GM45
Right, that confirms that is the gc->pCompositeClip that is screwed up. More debugging, hopefully a step in the right direction: commit b9ebb016833df5b70336c66993a871e850fd0f61 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 21 09:05:54 2014 +0000 sna: More assertions for tracking gc->pCompositeClip Tracking down who leaves it modified... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sadly that was a bogus assert. However, there was a bit of extra DBG that should should still be useful. (Baby steps.)
Created attachment 92516 [details] Xorg.0.log-2.99.907-44-g720d131 Just to be sure, it's a bug that resides inside a driver and not an effect of some misconfiguration, i.e. in kernel/xorg, on my side? Sometimes I learn to have too much power over my config the hard way.
(In reply to comment #3) > Just to be sure, it's a bug that resides inside a driver and not an effect > of some misconfiguration, i.e. in kernel/xorg, on my side? Sometimes I learn > to have too much power over my config the hard way. It is definitely a bug in the driver/xserver. For some reason it believes that the gc has already been validated for the drawable, but it still have the clip from the previous drawable.
Ok, I think this is the culprit: diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 4a2b614..b1744ae 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -4021,7 +4021,8 @@ static bool must_check sna_gc_move_to_cpu(GCPtr gc, } else changes &= ~GCClipMask; - if (changes || drawable->serialNumber != sgc->serial) { + if (changes || drawable->serialNumber != (sgc->serial & DRAWABLE_SERIAL_BITS)) { + long tmp = gc->serialNumber; gc->serialNumber = sgc->serial; if (fb_gc(gc)->bpp != drawable->bitsPerPixel) { @@ -4042,8 +4043,7 @@ static bool must_check sna_gc_move_to_cpu(GCPtr gc, } fbValidateGC(gc, changes, drawable); - - sgc->serial = drawable->serialNumber; + gc->serialNumber = tmp; } sgc->changes = 0; @@ -15733,6 +15733,7 @@ sna_validate_gc(GCPtr gc, unsigned long changes, DrawablePtr drawable) assert(RegionNil(gc->pCompositeClip) || gc->pCompositeClip->extents.y2 - drawable->y <= drawable->height); sna_gc(gc)->changes |= changes; + sna_gc(gc)->serial = gc->serialNumber; } static const GCFuncs sna_gc_funcs = {
Created attachment 92550 [details] [review] Restore gc->serialNumber correctly after fallback
Applied patch over current git. Looks like the bug is pinned - it made Bruce Springsteen sing. ;)
Thank you very much for your bug report and help, commit 29e11e2e6f80f6485ed69ea72e09e8d9b31fd8e8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 21 22:40:11 2014 +0000 sna: Restore gc->serialNumber correctly after falling back Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73856 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.