Created attachment 110777 [details]
After update kernel to 3.18.0 I start getting artefacts in my DE (KDE). But restart X-server solve this, until the next reboot.
-- chipset: Intel HM55
-- system architecture: 64-bit
-- xf86-video-intel: 2.99.916
-- xserver: 126.96.36.1991
-- mesa: 10.3.5
-- libdrm: 2.4.58
-- kernel: 3.18.0 and 3.18.0-gentoo
-- Linux distribution: Gentoo
-- Machine or mobo model: HP G62-b26ER
-- Display connector: standart laptop display (LVDS?)
1. Install 3.18.0 kernel
3. Login into DE
Created attachment 110778 [details]
Artefacts screenshoot 1
Created attachment 110779 [details]
Artefacts screenshoot 2
Created attachment 110780 [details]
Created attachment 110781 [details]
"xrandr --verbose" output
Created attachment 110782 [details]
Created attachment 110783 [details]
You are hitting sw fallback due to a kernel bug, but that shouldn't result in any corruption. :|
Can you describe your KDE setup and if there is an easy way to trigger the corruption (i.e. does it affect any widget/application reliably)?
I use Gentoo (~amd64) and minimal KDE installation with kde-base/kdebase-meta-4.14.3.
I get those artifacts in window decorations (titles, buttons), main panel, main menu and Konsole. As you can see it on two attached screenshots.
I get they always after first reboot and just login into KDM. Logout (xserver rstart) just solve this.
Created attachment 110818 [details]
Artefacts screenshoot 3
Also sometimes I get this in firefox.
Scroll or tab switch solve this.
Created attachment 111116 [details]
Artefacts screenshoot 4
If you need some more info - just say what I should provide and I do it. This issue is very annoying...
The error was prevented by
Author: Daniel Vetter <email@example.com>
Date: Mon Nov 24 11:12:42 2014 +0100
drm/i915: Disallow pin ioctl completely for kms drivers
However, fixing the actual bug is a lot more tricky and requires reproducing in a debug environment. Perhaps if you recompile xf86-video-intel with ./configure --enable-debug=pixmap that would catch the error?
(In reply to Chris Wilson from comment #12)
> Perhaps if you recompile xf86-video-intel with
> ./configure --enable-debug=pixmap that would catch the error?
Well, I can try.
Which files you need?
iirc gentoo have a USE flag for debug and full-debug builds of xf86-video-intel (but not debug=pixmap). If you ask gentoo to do a full-debug of xf86-video-intel that will be enough. If an error is detected, X will quit with a FatalError message, please compress the Xorg.0.log (xz is perfect for the task) and attach. If that proves too big, try
(head -1500 Xorg.0.log; echo ...; tail -1500 Xorg.0.log) | xz -9 > Xorg.0.log.xz
(In reply to Chris Wilson from comment #14)
> iirc gentoo have a USE flag for debug and full-debug builds of
> xf86-video-intel (but not debug=pixmap). If you ask gentoo to do a
> full-debug of xf86-video-intel that will be enough. If an error is detected,
> X will quit with a FatalError message, please compress the Xorg.0.log (xz is
> perfect for the task) and attach. If that proves too big, try
> (head -1500 Xorg.0.log; echo ...; tail -1500 Xorg.0.log) | xz -9 >
I can build xf86-video-intel as usual but also add --enable-debug=pixmap.
It's will be enough?
Yes, that should be enough. It will enable a bunch of sanity checks around operations that may trigger a FatalError if they fail.
Created attachment 111860 [details]
Xorg.0.log with --enable-debug=pixmap
Well, I'm not see any FatalErrors... Artifacts still here.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/38.