Bug 82368 - [i915] [MSI 7817] kernel 3.16.0: "drm failed to set drm interface version: Permission denied (13)"
Summary: [i915] [MSI 7817] kernel 3.16.0: "drm failed to set drm interface version: Pe...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Rodrigo Vivi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-08 20:39 UTC by Jens
Modified: 2017-07-24 22:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
log file with 3.16.0 (fails) (6.88 KB, text/plain)
2014-08-08 20:40 UTC, Jens
no flags Details
log file with 3.16.0rc2 (succeeds) (16.75 KB, text/plain)
2014-08-08 20:40 UTC, Jens
no flags Details

Description Jens 2014-08-08 20:39:22 UTC
After upgrading to 3.16.0 from -rc2, I cannot start X any more. Log file of starting X with both kernels attached. The important differences is the following:

 (EE) intel(0): [drm] failed to set drm interface version: Permission denied [13].
 (EE) intel(0): Failed to claim DRM device.
 (II) UnloadModule: "intel"
 (EE) Screen(s) found, but none have a usable configuration.

in the log file with 3.16.0. 

What can this be? Any ideas?

Thank you!
Comment 1 Jens 2014-08-08 20:40:15 UTC
Created attachment 104312 [details]
log file with 3.16.0 (fails)
Comment 2 Jens 2014-08-08 20:40:37 UTC
Created attachment 104313 [details]
log file with 3.16.0rc2 (succeeds)
Comment 3 Jens 2014-08-09 05:46:02 UTC
It seems that a "drm-linux-next" as of 20140808 (instead of drm-linux-nightly as of 20140807) fixes this problem, X starts up again.
Comment 4 Chris Wilson 2014-08-09 06:25:44 UTC
Usually this is due to a race in the master takeover. If you update xf86-video-intel to

commit dea65e8be73b79c50f7ee59c54c4c75cbcff67fb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Aug 9 07:12:23 2014 +0100

    intel: Log open clients on master takeover fail

and apply http://patchwork.freedesktop.org/patch/31388/ to your kernel X should grab all the information I need to identify the guilty party. Even just updating xf86-video-intel should be enough to confirm this hypothesis.
Comment 5 Chris Wilson 2014-08-09 06:26:32 UTC
Oh -nightly not 3.16.0. Yeah, that was a temporary bug.


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.