Bug 94104 - Baytrail Improperly redrawn graphics when xterm scrolls
Summary: Baytrail Improperly redrawn graphics when xterm scrolls
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-11 23:57 UTC by marty
Modified: 2017-04-11 12:24 UTC (History)
1 user (show)

See Also:
i915 platform: BYT
i915 features:


Attachments
dmesg after glitch happened (99.55 KB, text/plain)
2016-02-11 23:57 UTC, marty
no flags Details
screen capture showing "torn" xterm text (555.40 KB, image/png)
2016-02-11 23:59 UTC, marty
no flags Details
dump of intel_reg_dump after glitch (17.26 KB, text/plain)
2016-02-11 23:59 UTC, marty
no flags Details
capture of Xorg.0.log (16.54 KB, text/plain)
2016-02-12 00:00 UTC, marty
no flags Details
dump of vbios (64.00 KB, application/octet-stream)
2016-02-12 00:01 UTC, marty
no flags Details

Description marty 2016-02-11 23:57:58 UTC
Created attachment 121696 [details]
dmesg after glitch happened

I’m seeing weird video glitches on the Intel BayLey Bay –i CRB board, with Fedora 21, XFCE, and I hope someone can help.

This board has a dual-core ATOM SOC, similar to E3845.

Reproduced on Fedora 21's 3.17.4 and 4.1.13 kernels; and 4.3.0 kernel (https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.xz) also.

To recreate, open an xfce4-term.  Generate some output until the cursor is at the bottom (so the next command will cause scrolling).  Wait a few minutes.  Type “ls” (or echo, or most anything; even ssh’ing into the board and doing a “wall hello”, so that the terminal scrolls, can do it).

An area of the terminal window, and sometimes part of the desktop outside of the terminal, will be either a solid, text-colored, rectangle, or a “garbled” area resembling “warped” or torn text, at an odd angle.
Pic attached shoiwng "torn" text.

Hitting Enter or otherwise scrolling again will redraw the window properly; however, moving another 
terminal window over the anomaly and back will NOT cause the glitchy window to be properly redrawn.

Attached output of intel_reg_dumper and dmesg after it happened; also, output of 
/sys/devices/pci0000:00/0000:00:02.0/rom ("vbios.dump"); and the X log (Xorg.0.log).

Kernel cmdline included "drm.debug=0xe".

Versions of some X stuff:
xorg-x11-drv-vesa-2.3.2-19.fc21.x86_64
xorg-x11-xkb-utils-7.7-12.fc21.x86_64
xorg-x11-drv-synaptics-1.8.1-4.fc21.x86_64
xorg-x11-drv-qxl-0.1.2-1.fc21.x86_64
xorg-x11-server-Xorg-1.16.3-2.fc21.x86_64
xorg-x11-drv-vmware-13.0.2-5.20140613git82c9b0c.fc21.x86_64
xorg-x11-drv-vmmouse-13.0.0-13.fc21.x86_64
xorg-x11-drv-evdev-2.9.1-2.fc21.x86_64
xorg-x11-drv-modesetting-0.9.0-2.fc21.x86_64
xorg-x11-xinit-1.3.4-3.fc21.x86_64
xorg-x11-drv-nouveau-1.0.11-1.fc21.x86_64
xorg-x11-drv-openchrome-0.3.3-12.fc21.x86_64
xorg-x11-drv-ati-7.5.0-1.fc21.x86_64
xorg-x11-drv-intel-2.99.916-3.20141117.fc21.x86_64
xorg-x11-drv-fbdev-0.4.3-19.fc21.x86_64
xorg-x11-server-common-1.16.3-2.fc21.x86_64
xorg-x11-utils-7.5-16.fc21.x86_64
xorg-x11-font-utils-7.5-25.fc21.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-14.fc21.noarch
xorg-x11-drv-wacom-0.25.0-2.fc21.x86_64
xorg-x11-xauth-1.0.9-2.fc21.x86_64
xorg-x11-server-utils-7.7-10.fc21.x86_64

Thank you all,
Martin Rogers
Comment 1 marty 2016-02-11 23:59:01 UTC
Created attachment 121697 [details]
screen capture showing "torn" xterm text

screen capture showing "torn" xterm text
Comment 2 marty 2016-02-11 23:59:49 UTC
Created attachment 121698 [details]
dump of intel_reg_dump after glitch

dump of intel_reg_dump after glitch
Comment 3 marty 2016-02-12 00:00:25 UTC
Created attachment 121699 [details]
capture of Xorg.0.log

capture of Xorg.0.log after glitch happened
Comment 4 marty 2016-02-12 00:01:17 UTC
Created attachment 121700 [details]
dump of vbios

dump of /sys/devices/pci0000:00/0000:00:02.0/rom after glitch happened
Comment 5 yann 2017-03-16 12:52:55 UTC
(In reply to marty from comment #4)
> Created attachment 121700 [details]
> dump of vbios
> 
> dump of /sys/devices/pci0000:00/0000:00:02.0/rom after glitch happened

We seem to have neglected the bug a bit, apologies.

marty, since there were improvements pushed in kernel & xf86-video-intel  that will benefit to your system, so please re-test with latest kernel, & xf86-video-intel -alternatively you may use modesetting/glamor with latest mesa version- and mark as REOPENED if you can reproduce (and attach fresh kernel log & Xorg log) and RESOLVED/* if you cannot reproduce.
Comment 6 yann 2017-04-11 12:24:40 UTC
(In reply to yann from comment #5)
> (In reply to marty from comment #4)
> > Created attachment 121700 [details]
> > dump of vbios
> > 
> > dump of /sys/devices/pci0000:00/0000:00:02.0/rom after glitch happened
> 
> We seem to have neglected the bug a bit, apologies.
> 
> marty, since there were improvements pushed in kernel & xf86-video-intel 
> that will benefit to your system, so please re-test with latest kernel, &
> xf86-video-intel -alternatively you may use modesetting/glamor with latest
> mesa version- and mark as REOPENED if you can reproduce (and attach fresh
> kernel log & Xorg log) and RESOLVED/* if you cannot reproduce.

Timeout - assuming resolved+fixed.

If problem still persist with the latest kernels (preferable drm-tip from git://anongit.freedesktop.org/git/drm-tip), reopen this bug with latest logs as attachments.


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.