Bug 55395 - gnome-shell 3.6 BadDrawable with xf86-video-intel sna
Summary: gnome-shell 3.6 BadDrawable with xf86-video-intel sna
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-27 19:53 UTC by fosero
Modified: 2012-09-29 15:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log with debug=full (430.00 KB, application/octet-stream)
2012-09-29 10:32 UTC, fosero
no flags Details

Description fosero 2012-09-27 19:53:36 UTC
gnome-shell with the new screenshield in the 3.5/3.6 series crashes with the 1.20.x drivers with SNA enabled when the screen locks on the timer.

related gnome bug https://bugzilla.gnome.org/show_bug.cgi?id=682173
Comment 1 Gert Michael Kulyk 2012-09-28 19:09:10 UTC
This is xf86-video-intel 2.20.x using sna on a 3.5.x kernel, x86 with i915gm (gen3). For uxa commit
6211d0914e2ed1cdd4cc2e170ee16129fc9f0d73 (Flush batch immediately after queuing a WAIT_FOR_EVENT) did fix the issue, sna still is crashing gnome-shell on idle timeout (further information is to be found on the bugreport mentioned).
Comment 2 Chris Wilson 2012-09-28 19:50:38 UTC
If you ran with --enable-debug=full the reason for the BadDrawable will be evident, and the only source is if the Drawable has been destroyed.
Comment 3 fosero 2012-09-29 10:32:01 UTC
Created attachment 67846 [details]
Xorg log with debug=full

Full Xorg log with debug spew as requested.

This is a user login, wait till the screen goes blank and then wake. At that point (when trying to 'wake') the X crash occurs.

For some reason my .xsession-errors doesn't get written at the moment, so no log with the actual baddrawable error.
Comment 4 Chris Wilson 2012-09-29 15:39:36 UTC
The issue is that the pipe attached to the Drawable is off (DPMS), but we still call WaitVBlank on it to querty the MSC value. That results in an error being propagated back as a BadDrawable. In 2.20.9 we already include DPMS off in the set of state required to evaluate before calling WaitVBlank, so it should already be fixed. Additionally, it would seem that we do not need to report the WaitVBlank error wrt to dri2proto.txt.
Comment 5 Chris Wilson 2012-09-29 15:43:17 UTC
commit dddb6e4e63d5cc8b2a1f2ae3ff287922d30460b9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Sep 27 17:17:30 2012 +0100

    sna: Attempt to restore the current mode if pipe is disabled on DPMS on
    
    If we attempt to power up the pipe through a DPMS request, but it was
    previously disabled due to an error, first try re-enabling.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

commit 33f6f753788398efdf20cde4aa0b4ca402eee8fe
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Sep 29 16:41:00 2012 +0100

    sna/dri: Swallow error from GetMSC
    
    Just ignore the error return from WaitVBlank and make up a value for
    last MSC/SBC similar to an unattached Drawable.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55395
    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.