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: 184.108.40.2061
-- 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 <firstname.lastname@example.org>
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.