Bug 78631 - [gm45] kwin of KDE crashes without any notification after resuming from RAM on intel chipset with kernel 3.15
Summary: [gm45] kwin of KDE crashes without any notification after resuming from RAM o...
Status: RESOLVED MOVED
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: IA-64 Linux
: P1 high
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-22 04:16 UTC by Ukyoi D
Modified: 2014-09-12 13:33 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.15.1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Ukyoi D 2014-06-22 04:16:51 UTC
Thanks for reading this post.

When I upgraded to kernel 3.15.1, I found that kwin (the window manager of KDE) crashes frequently after resuming from RAM -- not always the first time, but often the first or the second time. There is no any notification.

Switching to TTY1 and using
    DISPLAY=:0 kwin --replace
can restart kwin, but kwin will crash immediately after switching to X output.

There is no problem in kernel 3.14.

Here is my hardware info:
OS: Archlinux
Kernel: 3.15.1
Video Driver: xf86-video-intel 2.99.912

lspci info:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:03.3 Serial controller: Intel Corporation Mobile 4 Series Chipset AMT SOL Redirection (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
Comment 1 Ukyoi D 2014-07-06 06:58:45 UTC
Here is a more professional report about the issue:
https://bugs.archlinux.org/task/41045
Comment 2 Jani Nikula 2014-08-14 12:39:08 UTC
(In reply to Ukyoi D from comment #1)
> Here is a more professional report about the issue:
> https://bugs.archlinux.org/task/41045

It appears this works with UXA, which might interest Chris. However, it's still a kernel regression. If you have the chance to bisect between 3.14 and 3.15 that might be the fastest way of tracking this down. Or try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel.
Comment 3 Ukyoi D 2014-08-14 14:25:08 UTC
(In reply to Jani Nikula from comment #2)
> (In reply to Ukyoi D from comment #1)
> > Here is a more professional report about the issue:
> > https://bugs.archlinux.org/task/41045
> 
> It appears this works with UXA, which might interest Chris. However, it's
> still a kernel regression. If you have the chance to bisect between 3.14 and
> 3.15 that might be the fastest way of tracking this down. Or try
> drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel.

On my laptop (Thinkpad X200) it just falls back to XRender when using Kernel 3.16.
As far as I know, the only way to workaround it is to use an older kernel.
Comment 4 Jani Nikula 2014-09-12 13:33:54 UTC
(In reply to Ukyoi D from comment #1)
> Here is a more professional report about the issue:
> https://bugs.archlinux.org/task/41045

Ahah, if that's the bug, it's mitigated by

commit ece4a17d237a79f63fbfaf3f724a12b6d500555c
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Thu Aug 7 16:29:53 2014 +0200

    drm/i915: read HEAD register back in init_ring_common() to enforce ordering

and *possibly* fixed by

commit 95468892fdfeef6d1004b524e35957629efdbe00
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 7 15:39:54 2014 +0100

    drm/i915: Reset the HEAD pointer for the ring after writing START

In any case this is tracked at
https://bugs.freedesktop.org/show_bug.cgi?id=76554

Thanks for the report.

Note You need to log in before you can comment on or make changes to this bug.