Bug 991707 - Intel HD 4000 support regression
Intel HD 4000 support regression
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-03 17:21 EDT by Mark Patton
Modified: 2013-10-08 12:31 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 12:31:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X log file (79.94 KB, text/x-log)
2013-08-03 17:21 EDT, Mark Patton
no flags Details
Kernel-3.9.5 Xorg log (35.69 KB, text/x-log)
2013-08-19 11:14 EDT, Gamaliel
no flags Details
Xorg log 3.10.7 blind (34.99 KB, text/x-log)
2013-08-19 17:18 EDT, Gamaliel
no flags Details
Xorg log 3.10.7 nomodeset (10.13 KB, text/x-log)
2013-08-19 17:18 EDT, Gamaliel
no flags Details
Lspci 3.9.5 (1.56 KB, text/x-log)
2013-08-19 17:19 EDT, Gamaliel
no flags Details
Lspci 3.10.7 (1.56 KB, text/x-log)
2013-08-19 17:20 EDT, Gamaliel
no flags Details
Dmesg 3.10.7 (84.12 KB, text/x-log)
2013-08-19 17:20 EDT, Gamaliel
no flags Details
Lspci -s 00:02.0 -vv -nn 3.9.5 (1.04 KB, text/x-log)
2013-08-19 19:05 EDT, Gamaliel
no flags Details
Lspci -s 00:02.0 -vv -nn 3.10.7 nomodeset (1.00 KB, text/x-log)
2013-08-19 19:07 EDT, Gamaliel
no flags Details
Lspci -s 00:02.0 -vv -nn log 3.10.7 (with KMS). (1.04 KB, text/plain)
2013-08-22 22:07 EDT, Gamaliel
no flags Details
Xorg 3.10.7 (With KMS) (35.10 KB, text/plain)
2013-08-22 22:10 EDT, Gamaliel
no flags Details

  None (edit)
Description Mark Patton 2013-08-03 17:21:00 EDT
Created attachment 782394 [details]
X log file

Description of problem:

Intel(R) Core(TM) i5-3570K
Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller

In Fedora 17, I could play video without screen tearing. 
In Fedora 19, I cannot. The problem seems to be that the hardware is no longer being used directly.

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

Fedora 19 with all updates applied.

How reproducible:

Every time.

Steps to Reproduce:
1. Install fedora 19 on a working system.
2. Try to play a video.

Actual results:

Watch a video stutter that a 10 year old cellphone could play smoothly.

Expected results:

Video play without screen tearing.

Additional info:
xvinfo
X-Video Extension version 2.2
screen #0
 no adaptors present

glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 256 bits)
    GL_NV_conditional_render, GL_NV_fog_distance, GL_NV_light_max_exponent, 

After the failure with stock Fedora 19, I tried installing the latest intel drivers from here https://01.org/linuxgraphics/downloads/2013/intelr-linux-graphics-installer-version-1.0.2. Nothing changed.

In the attached X log you will see
 open /dev/dri/card0: No such file or directory
[     3.554] (WW) Falling back to old probe method for fbdev
[     3.554] (II) Loading sub module "fbdevhw"

So there seems to be a problem recognizing the hardware, but there was no problem in Fedora 17.
Comment 1 Mark Patton 2013-08-13 22:24:50 EDT
I found a magic kernel incantation that fixes the problem. If I manually edit the kernel parameters to include "i915.modeset=1", Xorg runs as expected.

glxinfo | grep -i render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil, 
    GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_light_max_exponent, 

I added the setting to a modprobe.d config file so hopefully I'm set.

I have a work around, but the issue is that Fedora should automatically figure out the right thing to do.
Comment 2 Steve Tyler 2013-08-13 23:11:39 EDT
Could you attach the output of dmesg, so we can see what is on your kernel command line?

In Bug 986620, Comment 7, I noted that you were booting with nomodeset on the kernel command-line, so it seems like you are overriding that:

$ modinfo i915 | grep modeset
parm:           modeset:Use kernel modesetting [KMS] (0=DRM_I915_KMS from .config, 1=on, -1=force vga console preference [default]) (int)

The kernel command-line arguments are configurable in /etc/default/grub.

After making changes to GRUB_CMDLINE_LINUX in /etc/default/grub, run:
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
(It is probably a good idea to make a backup of grub.cfg first ...)
After that, reboot to see what you got ...

grub2 documentation:
http://www.gnu.org/software/grub/manual/
$ info grub2

$ rpm -qa 'grub2*' | sort
grub2-2.00-23.fc19.x86_64
grub2-efi-2.00-23.fc19.x86_64
grub2-starfield-theme-2.00-23.fc19.x86_64
grub2-tools-2.00-23.fc19.x86_64
Comment 3 Steve Tyler 2013-08-14 00:11:05 EDT
The kernel command-line has nomodeset on it.
Have you tried removing it with kernel 3.10.4-300?

Snippet from attached Xorg.0.log:
...
[     3.538] Current Operating System: Linux localhost.localdomain 3.10.4-300.fc19.x86_64 #1 SMP Tue Jul 30 11:29:05 UTC 2013 x86_64
[     3.538] Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.4-300.fc19.x86_64 root=/dev/sda4 ro rootflags=subvol=root nomodeset rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8
...
Comment 4 Mark Patton 2013-08-14 07:19:26 EDT
I've previously tried removing nomodeset (not sure which kernel). Every time I get a garbled screen on boot and I can't switch virtual terminals.

Right now all the updates are applied and I am running kernel 3.10.5-201.
Comment 5 Gamaliel 2013-08-19 11:14:12 EDT
Created attachment 788112 [details]
Kernel-3.9.5 Xorg log
Comment 6 Steve Tyler 2013-08-19 11:21:55 EDT
Gamaliel: Could you attach the output from dmesg and lspci too?
$ dmesg > dmesg-1.log
$ lspci
Comment 7 Steve Tyler 2013-08-19 11:36:45 EDT
Also, could you please update your system:
$ sudo yum update

This is the install kernel:
[    52.748] Current Operating System: Linux ETI-Saturn 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64

The latest kernel is:
$ sudo repoquery kernel
kernel-0:3.10.7-200.fc19.x86_64
Comment 8 Gamaliel 2013-08-19 17:18:03 EDT
Created attachment 788203 [details]
Xorg log 3.10.7 blind

I add the 3.10.7 xorg.log blindly, as well as the one with nomodeset. Without nomodeset, I cannot see anything, not even the plymouth bootscreen: the only thing working is the backlight. With nomodeset, I can see plymouth, but never boot into Xorg multi-user, I can only use getty. Contrast this with the 3.9.5 Xorg.
Comment 9 Gamaliel 2013-08-19 17:18:45 EDT
Created attachment 788204 [details]
Xorg log 3.10.7 nomodeset
Comment 10 Gamaliel 2013-08-19 17:19:48 EDT
Created attachment 788205 [details]
Lspci 3.9.5
Comment 11 Gamaliel 2013-08-19 17:20:19 EDT
Created attachment 788206 [details]
Lspci 3.10.7
Comment 12 Gamaliel 2013-08-19 17:20:58 EDT
Created attachment 788207 [details]
Dmesg 3.10.7
Comment 13 Steve Tyler 2013-08-19 17:57:36 EDT
Thanks, Gamaliel. That's very helpful.

Did you try Mark's workaround: "i915.modeset=1"? (Comment 1)
The kernel command-line arguments are configurable in /etc/default/grub. (Comment 2)

Your dmesg shows:
[    0.125562] smpboot: CPU0: Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (fam: 06, model: 3a, stepping: 09)

The Intel web site shows:
Processor Graphics    Intel® HD Graphics 4000
http://ark.intel.com/products/65707/Intel-Core-i5-3317U-Processor-3M-Cache-up-to-2_60-GHz?q=i5-3317U


The lspci output is not so informative:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

This might show more:
$ lspci -s 00:02.0 -vv -nn
Comment 14 Gamaliel 2013-08-19 19:05:41 EDT
Created attachment 788209 [details]
Lspci -s 00:02.0 -vv -nn 3.9.5
Comment 15 Gamaliel 2013-08-19 19:07:19 EDT
Created attachment 788210 [details]
Lspci -s 00:02.0 -vv -nn 3.10.7 nomodeset
Comment 16 Gamaliel 2013-08-19 19:13:42 EDT
Tried the i915.modeset=1, without success. I have to try to do it blindly again, with a reinstalled grub2. Will post later.
Comment 17 Steve Tyler 2013-08-19 22:30:37 EDT
Thanks for the updated lspci output:

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device [1043:103d]
...
	Kernel driver in use: i915
==

grub2-mkconfig just rebuilds the grub2 menu that you see when you boot and are given a list of kernels to boot. It does not reinstall grub2.

I believe Mark has *both* "nomodeset" and "i915.modeset=1" (Comment 1, Comment 2). He set "i915.modeset=1" in a /etc/modprobe.d/ config file, but I believe you could put both on the kernel command-line. To always boot with those options,
edit /etc/default/grub and run grub2-mkconfig (Comment 2).
Comment 18 Mark Patton 2013-08-19 22:36:19 EDT
Yes. I have both nomodeset and i915.modeset=1 set. When I have access to that machine again in a couple days, I will see if just the i915 setting alone works.

Let me know if any additional testing or information would help.

(In reply to Steve Tyler from comment #17)
> Thanks for the updated lspci output:
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
> processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
> controller])
> 	Subsystem: ASUSTeK Computer Inc. Device [1043:103d]
> ...
> 	Kernel driver in use: i915
> ==
> 
> grub2-mkconfig just rebuilds the grub2 menu that you see when you boot and
> are given a list of kernels to boot. It does not reinstall grub2.
> 
> I believe Mark has *both* "nomodeset" and "i915.modeset=1" (Comment 1,
> Comment 2). He set "i915.modeset=1" in a /etc/modprobe.d/ config file, but I
> believe you could put both on the kernel command-line. To always boot with
> those options,
> edit /etc/default/grub and run grub2-mkconfig (Comment 2).
Comment 19 Steve Tyler 2013-08-19 23:26:23 EDT
(In reply to Mark Patton from comment #18)
> Yes. I have both nomodeset and i915.modeset=1 set. When I have access to
> that machine again in a couple days, I will see if just the i915 setting
> alone works.
> 
> Let me know if any additional testing or information would help.

Thanks for clarifying that. It might be useful to have a photo of any display corruption you see.

These two posts show horizontal black lines:

Garbage screen with Intel Linux Graphics Installer + Ubuntu 12.04.2 64 bits + Samsung NP900X3E-A02US (HD 4000)
https://01.org/linuxgraphics/node/84

Display bug on Samsung Series 9 under X
http://forums.debian.net/viewtopic.php?f=7&t=103703
Comment 20 Gamaliel 2013-08-22 22:07:54 EDT
Created attachment 789418 [details]
Lspci -s 00:02.0 -vv -nn log 3.10.7 (with KMS).

I found two or three things. First, my computer is an ASUS Taichi 21. As you may know, this laptop has two screens, one in the front, and a touchscreen in the back. I have never had any success configuring the back screen, especially its backlight, which never seems to map correctly to the brightness, and thus is always dark and unusable. Today, when trying to log in blindly, I looked at the back screen and there was output in it! All dark and barely noticeable, of course, but the Crypto-password thingy from plymouth was there. However, after I gave the password, both screens showed 0 output. This means that it is trying to configure the wrong screen on my setup (the bad touchscreen one instead of my real monitor). 

Then, I booted Sabayon 13.08 with kernel 3.10, and it also opened the screen properly! Only that in Sabayon, the touchscreen was never recognized, and the display never appeared. So this may just be a particular configuration bug.

It seems to be more like an Xorg-based problem, don't you think?
Comment 21 Gamaliel 2013-08-22 22:10:08 EDT
Created attachment 789419 [details]
Xorg 3.10.7 (With KMS)

These logs, including the KMS lscpi one, were done by writing on paper the commands and logging via a getty console "blindly". No output was ever seen in the screen.

I boot from 3.9.5 to use my computer, and it recognizes everything but the back-screen's backlight.
Comment 22 Mark Patton 2013-08-23 08:00:23 EDT
I booted with only i915.modeset=1 and X ran perfectly. The corruption I see without that kernel parameter doesn't look like the cases linked. I'm out the door so don't have time to take a picture. IIRC most of the screen was black with a colored wavy pattern at the top.

(In reply to Steve Tyler from comment #19)
> (In reply to Mark Patton from comment #18)
> > Yes. I have both nomodeset and i915.modeset=1 set. When I have access to
> > that machine again in a couple days, I will see if just the i915 setting
> > alone works.
> > 
> > Let me know if any additional testing or information would help.
> 
> Thanks for clarifying that. It might be useful to have a photo of any
> display corruption you see.
> 
> These two posts show horizontal black lines:
> 
> Garbage screen with Intel Linux Graphics Installer + Ubuntu 12.04.2 64 bits
> + Samsung NP900X3E-A02US (HD 4000)
> https://01.org/linuxgraphics/node/84
> 
> Display bug on Samsung Series 9 under X
> http://forums.debian.net/viewtopic.php?f=7&t=103703
Comment 23 Alexey Volkov 2013-08-23 12:30:32 EDT
Got another solution:

Just remove "nomodeset" from the kernel bootline and add "acpi_osi=Linux acpi_backlight=vendor" to its end.

My bootline looks like this:

linux	/vmlinuz-3.10.7-200.fc19.x86_64 root=/dev/mapper/rfremix-root ro  rd.lvm.lv=rfremix/root rd.md=0 rd.dm=0 rd.lvm.lv=rfremix/swap  rd.luks=0 vconsole.keymap=us vconsole.font=latarcyrheb-sun16 rhgb quiet acpi_osi=Linux acpi_backlight=vendor

This also fixes "black screen on boot" issue and enables the backlight keys on a keyboard. Video performance is as expected - just fine :)

My system is similar as topic starter's one - Intel i5 Evy Bridge with HD4000 video. Fresh install of Fedora 19.  

Hope this helps.
Regards,
A.
Comment 24 Josh Boyer 2013-09-18 16:35:31 EDT
*********** 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 25 Josh Boyer 2013-10-08 12:31:54 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

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