Bug 1009356

Summary: No /dev/dri with generation or 6 or later Intel GPU
Product: [Fedora] Fedora Reporter: Sylvia Else <sylviabz1>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, marcelo.barbosa, skottler
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-19 13:43:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmesg with no modeset
none
demsg with the "nomodeset" removed from the kernel command line none

Description Sylvia Else 2013-09-18 09:35:22 UTC
Description of problem: Direct rendering interface is not available when using a generation 6 or later Intel GPU. 


Version-Release number of selected component (if applicable):

3.10.11-200.fc19.i686.PAE
How reproducible:
Totally


Steps to Reproduce:
1. Buy gen 6 or later GPU, and install.
2. Boot.
3. ls -la /dev/dri

Actual results:
ls: cannot access /dev/dri: No such file or directory


Expected results:
Directory listing, including card0.

Additional info:
The i915 module is loaded, but not actually used, in this situation. It needs the modeset=1 module option, which is not set by default. Setting it in the kernel command line works, but the booting process is not then visible on screen.

Comment 1 Sylvia Else 2013-09-18 12:48:02 UTC
It seems that contrary to an earlier impression I had, putting

options i915 modeset=1

into a file in the /etc/modprobe.d directory is also effective, with the added advantage that it doesn't mess up the screen during booting.

Comment 2 Josh Boyer 2013-09-18 20:11:32 UTC
Can you attach the output of dmesg with and without the modeset=1 parameter specified?

Comment 3 Josh Boyer 2013-09-18 20:43:21 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 4 Sylvia Else 2013-09-19 07:08:07 UTC
I have tested against 3.11.1-200.fc19, and the behaviour is the same.

In fact, the situation has become clear enough. In i915_dma.c, at line 1480, there is a test for the generation being >= 6 in the absence of modesetting, and the function bails with an error if so. Presumably modesetting is required for the thing to work. An error message would have been nice.

Anyway, moving to i915_drv.c, line 1190, we see code (CONFIG_DRM_I915_KM is in fact set) that sets modesetting by default if the i915_modeset variable has been left at its initial value of -1. 

However the kernel line includes "nomodeset" which has the effect of clearing the i915_modeset variable to zero, thus preventing the default use of modesetting.

I haven't been able to determine what it is that causes nomodeset to be included in the kernel line, but as long as its there, and in the absence of a modprobe to overcome it, the i915 module, and with it the direct rendering interface, is not going to be available with the recent GPUs.

Comment 5 Sylvia Else 2013-09-19 07:15:11 UTC
Created attachment 799756 [details]
dmesg with no modeset

demsg output with kernel line as installed.

Comment 6 Sylvia Else 2013-09-19 07:17:05 UTC
Created attachment 799757 [details]
demsg with the "nomodeset" removed from the kernel command line

Comment 7 Sylvia Else 2013-09-19 07:21:00 UTC
I have to retract my earlier observation that adding an option to the modprobe.d directory resolves the problem, at least without some other operation involving (I think) the installation of kernels (I'm unclear what the interaction is).

Comment 8 Sylvia Else 2013-09-19 13:13:25 UTC
It occurs to me now that the nomodeset on the kernel command line is probably there because I used the video-trouble shooting installation option. If so, then it was not clear that that would have ramifications well beyond the installation phase.

Comment 9 Josh Boyer 2013-09-19 13:43:39 UTC
(In reply to Sylvia Else from comment #8)
> It occurs to me now that the nomodeset on the kernel command line is
> probably there because I used the video-trouble shooting installation
> option. If so, then it was not clear that that would have ramifications well
> beyond the installation phase.

Yes, that would do it.  Please remove it from your grub configuration file.  The kernel is doing exactly what it is told if nomodeset is specified on the command line.