Bug 687988

Summary: [Sandy_Bridge] Sandy Bridge DRI rendering weirdness
Product: Red Hat Enterprise Linux 6 Reporter: Mark Gordon <mgordon>
Component: xorg-x11-drv-intelAssignee: Adam Jackson <ajax>
Status: CLOSED NOTABUG QA Contact: desktop-bugs <desktop-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.1CC: ajax, cmeadors, hui.xiao, jane.lv, jvillalo, luyu, pvine, rdoty
Target Milestone: rcKeywords: Regression, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-31 19:44:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 600438    
Attachments:
Description Flags
X log
none
/var/log/messages
none
dmesg output none

Description Mark Gordon 2011-03-15 23:00:15 UTC 
Description of problem:
If I run glxgears on a Sandy Bridge machine, the window is initially solid black.  If I cover a lower corner of the glxgears window with another window, the glxgears window renders as it should.  If I move the covering window halfway up the glxgears window, the top portion of the glxgears window is rendered, and the bottom portion, up to the level of the covering window, isn't refreshed.  If I cover only an upper corner, the portion of the glxgears window which is above the bottom of the covering window renders properly.  If an entire edge is covered, either top or side, there's no rendering.

Version-Release number of selected component (if applicable):
mesa-libGL-7.10-1.el6 (same for mesa-libGLU, mesa-dri-drivers)
xorg-x11-drv-intel-2.14.0-1.el6

How reproducible:
100%

Steps to Reproduce:
1. glxgears
2. cover corners/edges with another window (e.g. gnome-terminal)
  
Actual results:
breakage, failure to render/refresh

Expected results:
spinning gears

Additional info:
per glxinfo: "direct rendering: Yes"

I'm not sure whether this is a mesa bug, a driver bug, a kernel bug, an X server bug...

This worked fine in 6.0, granted without direct rendering, at which point this is technically a regression.
Comment 2 Matěj Cepl 2011-03-17 11:24:01 UTC 
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 3 Mark Gordon 2011-03-23 18:44:15 UTC 
Created attachment 487120 [details]
X log
Comment 4 Mark Gordon 2011-03-23 18:44:51 UTC 
Created attachment 487121 [details]
/var/log/messages
Comment 5 Mark Gordon 2011-03-23 18:45:13 UTC 
Created attachment 487122 [details]
dmesg output
Comment 6 Mark Gordon 2011-03-23 18:45:42 UTC 
No xorg.conf existed.
Comment 7 Xiao, Hui 2011-03-25 02:58:06 UTC 
Hi,

we recommend to use the newer machine for all the tests. Could you please try to find a Sandy Bridge D stepping machine instead of C? :-)

Thanks
Comment 8 John Villalovos 2011-03-25 16:21:39 UTC 
Mark,

Our SugarBay system at Red Hat should be D stepping machines.

Which Sandy Bridge system are you using for your testing?
Comment 9 Mark Gordon 2011-03-31 19:44:20 UTC 
Never mind.  Updated MB/CPU acquired & installed, and the problem can no longer be reproduced.  Closing.