Bugzilla – Bug 959245
Mouse cursor disappears after powersave (plasma) or after logout (sddm) - drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Last modified: 2015-12-22 13:52:42 UTC
This might be a duplicate of: https://bugzilla.opensuse.org/show_bug.cgi?id=943707
I am entering this as new, because the other bug has status "closed". It is however present in a freshly installed LEAP 42.1 - please see screenshot at 943707: https://bugzilla.opensuse.org/attachment.cgi?id=659474
--comment at 943707:--
The error comes up with a freshly installed and updated LEAP 42.1 on MSI Z170-A PRO with i7 6700 (integrated graphics). It seems the error is connected with this journal line:
Dec 15 22:10:14 wshome5 kernel: [drm:gen8_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Symptoms as shown in the "screenshot" (taken with a camera, as the internal screenshot tool does not catch the error). The "roller blind" comes up from the lower edge of the screen, moves with Y-movement of the mouse and is colored with the background color at the X-position of the mouse (in the image the "mouse" was over the red mushroom).
Happens all the time with no exceptions to date on sddm-screen after logout and on plasma after screensaver/powersave mode.
A fix would be great, but a workaround (how to reanimate the mouse driver) would be even better (for now).
Is it Leap GM kernel (4.1.12) kernel, or the update kernel (4.1.13)? In anyway, please give "hwinfo --gfx" output.
Also, could you try the latest kernel in OBS Kernel:openSUSE-42.1 repo, too?
my kernel is at the moment:
root root 24 Dec 12 23:07 /boot/vmlinuz -> vmlinuz-4.1.13-5-default
The output from hwinfo --gfx is:
09: PCI 02.0: 0300 VGA compatible controller (VGA)
[Created at pci.366]
Unique ID: _Znp.k1eL5Y9gea9
SysFS ID: /devices/pci0000:00/0000:00:02.0
SysFS BusID: 0000:00:02.0
Hardware Class: graphics card
Device Name: "Onboard IGD"
Model: "Intel Sky Lake Integrated Graphics"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x1912 "Sky Lake Integrated Graphics"
SubVendor: pci 0x1462 "Micro-Star International Co., Ltd. [MSI]"
SubDevice: pci 0x7971
Driver Modules: "drm"
Memory Range: 0xde000000-0xdeffffff (rw,non-prefetchable)
Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
I/O Ports: 0xf000-0xf03f (rw)
IRQ: 130 (963 events)
Module Alias: "pci:v00008086d00001912sv00001462sd00007971bc03sc00i00"
Driver Info #0:
Driver Status: i915 is active
Driver Activation Cmd: "modprobe i915"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Primary display adapter: #9
I can try another kernel (do I find the correct repo?) but not before the weekend. Thanks for the quick look at this, Andreas
(In reply to Andreas Schleth from comment #2)
> Model: "Intel Sky Lake Integrated Graphics"
> Vendor: pci 0x8086 "Intel Corporation"
> Device: pci 0x1912 "Sky Lake Integrated Graphics"
OK, it's Skylake, a pretty new thing. It's not 100% perfectly supported on 4.1, as it seems...
> I can try another kernel (do I find the correct repo?) but not before the
The newer kernels may have a more chance for better support especially for Skylake, but also more chance to get a regression :-< At least, 4.4-rc had some known bugs for SKL:
The latest openSUSE Leap kernel is found in OBS Kernel:openSUSE-42.1 repo, i.e.
Try the latest kernel-default package from there.
Also, if you have time, try kernel-vanilla package, too. It might be that some of our backports caused a regression. Just to be sure...
Created attachment 659612 [details]
gzipped fragment from journal with latest kernel-debug
I tried the following 3 kernel variants (all 4.1.13-5): vanilla, debug and default.
All show exactly the same behavior.
I fear the extended excerpt (attached above) of 1/2 a minute of the debug journal is not really enlightening, as there seems to be just this one error message when greeter screen appears for the second time.
Is there a repo with newer revisions of the kernel for openSUSE?
As this seems to be a reasonably easy exercise, I could try some newer revisions oder release candidates.
For debugging KMS stuff, pass drm.debug=0x0e boot option. Then i915 driver will become chatty.
(In reply to Andreas Schleth from comment #5)
> Is there a repo with newer revisions of the kernel for openSUSE?
You can find 4.3.x and 4.4-rc kernels in OBS Kernel:stable and Kernel:HEAD repos:
Created attachment 659765 [details]
journal with drm.debug=0x0e
I added a journal with chatty drm-driver enabled.
The newer kernels in the repo need to be built locally?
I did not build a kernel this side of Y2K, so I have to see how far I get (and start reading). This will be a lot slower than just installing and starting prebuilt kernels...
(In reply to Andreas Schleth from comment #8)
> The newer kernels in the repo need to be built locally?
No, just add the repository via zypper and update from there, or download the packages manually and install them.
OK, I've set up a test box with SKL here and could reproduce the issue at S3.
I backported a few upstream commits that may address the issue, and built a new quickfix KMP in OBS home:tiwai:bnc959245 repo.
Try later i915-quickfix-kmp-default.rpm from
The package is being built now, and it'll take a bit time.
Just install it, rebuild initrd if not done, reboot and check S3.
Maybe it's not perfectly stable, but stabler than before, at least.
(In reply to Takashi Iwai from comment #10)
> Try later i915-quickfix-kmp-default.rpm from
Oops, a typo there. The right URL is
I refreshed the repo with more possible fix patches. It's being rebuilt again now.
I tried the hot-fix (updated i915.ko) from today (2015/12/18) with no success so far. Attached find a new journal of the critical minute with drm.debug=0x0e enabled.
Created attachment 659925 [details]
journal using the quickfix (2015/12/18) with comments
As a side note: I really appreciate your efforts to pin this down.
NB: my box is built along the latest recommendations of c't -- some more of these may be around after Christmas :-)
Check whether you really took the latest one, show the output of:
rpm -q i915-quickfix-kmp-default --changelog
It should begin with:
* Fri Dec 18 2015 email@example.com
- built from the tarbal based on the latest openSUSE-42.1
Once when confirmed, check the output of "/sbin/modinfo i915 | grep filename"
The path should contain either "updates" or "weak-updates" directory.
Also, how did you test? With the suspend, or with logout?
Oh, one more thing: don't forget to install kernel-firmware package if not present yet, and regenerated initrd. Simply run mkinitrd after installing kernel-firmware package.
... and yet another thing that might be worth: try to change X11 intel driver to use UXA instead of SNA. For example, create /etc/X11/xorg.conf.d/60-intel.conf containing the following:
Identifier "Default Device"
Option "AccelMethod" "UXA"
This isn't always recommended, especially for new chips, but who knows...
* Fr Dez 18 2015 firstname.lastname@example.org
- built from the tarbal based on the latest openSUSE-42.1
/sbin/modinfo i915 | grep filename
my firmware is: 20150925git-1.1 and is installed since first install
(I could grab a slightly newer one from the kernel CR repo -- will try this)
Do I need to build a new initrd with just a new kernel module? (I can try this too)
The last few times, all I needed to trigger this misbehavior was crtl-alt-F1 (go to tty1) and go back (crtl-alt-F7). The login on tty1 is optional, but helpful for a post mortem.
Right now I am running with the proposed device file in xorg.conf.d "...." "UXA".
Now, post this and test...
4 reboots later:
1. mkinitrd (no change)
2. install firmware 20151109git-115.1 from RC repo + mkinitrd (no change)
3. change "AccelMethod" from "UXA" to "SNA" (no change)
4. here I am ...
NB: it is not neccessary to log in to produce this: Just change from sddm-greeter to tty1 and back to tty7.
That kind of instability was expected. So far, I concentrated on the original issue, the crash at S3/S4 and logout. Does the patched driver work better in that regard or do you see the same crash even for S3/S4?
OK, I still see the same type of failure.
After logoff (not leaving tty7) there is a flicker when sddm switches to the greeter screen, the mouse pointer vanishes and if I move the mouse these color bars appear from the lower left edge (and some parts of the upper right hand corner are painted at the upper left).
It is exactly the same behavior as if I switch to tty1 and back to tty7. The error message also is the same. (I do not exactly understand this S3/S4 thing.)
Yesterday I did a few more experiments (all with the latest *ko and firmware):
* change AccelMethod to SNA, UXA, off
* Add option "DRI" "0"
* fiddle with BIOS-Settings (HPET off/on), Graphics Memory increased to 1024M (was 256M), EUP off/on, EIST off/on, CPUID off/on, C-States off/on/auto
All this did not change a thing.
Then I tried the boot parameters nomodeset i915.modeset=0. This only resulted in not getting any X-session at all.
As a side note: from a different partition I still can boot my old 13.2 (all updates until early December). There I do not have this problem at all. Well, sound and USB are not working, but X works well and switching to tty1 and back has no adverse effect.
Well, the same failure at logout is also more or less expected. So far I checked mainly on S3/S4 issues. Does S3/S4 work better or not? If it works more reliably now, it implies that we're on the right track.
I did some more testing:
First reset BIOS an enter the recommended parameters from c't
Then tested suspend to RAM (Ruhezustand) S3? and suspend to disk (Tiefschlaf) S4?
Both are working fine. (The issue with tty1/tty7 and logout/login is still there).
My last test involved the live DVD from Ubuntu 15.10 x86_64 (Kernel 4.2.0-16-generic #19). And this is bad news for my dear old SuSE of 18 years friendship:
Ubuntu worked out of the box: S3/S4, switching the console to tty1 and back to tty7, sound was there and even the USB front panel (that does not work with Leap 42.1) is OK and responding correctly ...
Shall I do a heart/kernel transplant? Would it work (just copy the Ubuntu kernel tree to the proper places)? Would there be a safe way back?
I guess, I could grab the vanilla kernel sources and build it myself.
Is there a kernel 4.2 for openSUSE in the pipeline?
I grabbed the 4.3-kernel from kernel.org and built it (the suse-way). As far as I can see, the switching (tty1/tty7) seems to work and S3 as well. Funny enough, my old usb-issue is still there (but this is another topic).
I have to do some more testing, but I think, I will just wait until openSUSE has moved to at least 4.2.
Thanks again for the assistance. It is good, to be not alone with such an issue.
Oh, only for making the laptop panel working, there are several easy workarounds.
(A) Pass nomodeset boot option.
Passing nomodeset boot option makes the system skipping native graphics driver, and instead using EFI framebuffer. This is the reason why openSUSE 13.2 and Ubuntu worked. Prior to 4.2 kernel, i915 driver's support for Skylake is incomplete, and 4.1.x on Leap has still known bugs as you experienced although the Skylake support was enabled as default.
Of course, with EFI fb, there can be no mode change and no proper support of external output hotplug, and has 3D only in soft-rendering by CPU. But eDP modeset should work as is, at least.
In this bug report, I've tried to improve i915 KMS on 4.1.x kernel, but it's not so trivial because of radical code changes in each kernel. So slowly getting fixed, but, as you see, there are a few issues left yet.
(B) Use 4.2 or newer kernels. We provide always the latest stable kernel and development kernel in OBS repository, as opt-in. You can get the 4.3.x kernel from OBS Kernel:stable repo,
and 4.4-rc kernel from OBS Kernel:HEAD repo,
Either download kernel-default.rpm manually and install it via "zypper in", or register the URL above and let zypper fetch it. GRUB2 supports multi-version kernel boot, so it's fairly safe to try it out.
However, as already mentioned, there seem a few other bugs in 4.3.x or 4.4-rc kernels. Some of them have been already addressed, but some other might still hit. At least, the bug you reported here has been already fixed in these kernels, though.
I have also kernel packages of other versions in my own OBS repo. For example, for 4.2.x, you can find in OBS home:tiwai:kernel:4.2 repo,
This is provided unofficially and unsupported, so use at your own risk.
I have a solution for me.
I tried 2 variants of a home baked kernel 4.3 from kernel.org (one based on the suse-config and one based on the ubuntu config). Both seemed to work.
Now I changed to the stable kernel suse repo (4.3.3) and will stay there. This is easier (and takes a lot less disk space) than building one's own.
(Before I had problems to locate the new kernel versions in yast, as it only shows up when you dig into the "Versions" subpanel, even if you search by repo ...)
Thanks and bye, bye, Andreas
OK, then let's resolve this bug as UPSTREAM.
Meanwhile I backported a few more fixes for Leap kernel. It's tracked on bug 960021.