Red Hat Bugzilla – Bug 542264
Intel video is dead (regressed from F12)
Last modified: 2011-08-31 12:23:16 EDT
Description of problem:
At boot, once video goes into graphic mode, the screen is filled with
garbage (it looks like a test pattern of colorful vertical lines).
Version-Release number of selected component (if applicable):
100%, but needs specific hardware
Steps to Reproduce:
Console is not usable
VT & X11
The nomodeset works, but I cannot use it! Without KMS, X11 cannot start:
(EE) intel(0): No valid modes.
This is really bad for me.
Last working kernels are:
00:02.0 VGA compatible controller: Intel Corporation Auburndale/Havendale Integr
ated Graphics Controller (rev 10)
Similar problem for me, with slightly different symptoms.
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Boot in graphic mode shows sparse horizontal lines. GDM never starts. Can switch to tty1 and login text mode though.
Last working kernel was same as above. None of the 2.6.32 kernels up to and including .62 has worked for me.
Created attachment 378869 [details]
dmesg - stock kernel 2.6.32+, ok
Created attachment 378870 [details]
dmesg - bad 22.214.171.124-9.fc13
Still broken on 2.6.33-0.48.rc8.git1.fc14.
Updated to kernel-2.6.34-0.10.rc1.git0.fc14.x86_64: no more modeset,
which makes the console useful at least but not ideal: it's impossible
to run X without kernel modesetting on this hardware (VESA is possile
but has wrong aspect ratio).
Seriously, this is just wrong. Fedora 12 works, upstream 2.6.33 works,
RHEL 6 2.6.32-17.el6 works. What is going on, why can't we just back out
bad patches from Fedora 13 and 14?
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.
More information and reason for this action is here:
I'm seeing the same thing, at least the same as Darrell in comment 1, and probably the same as what Pete is reporting. I'm running 2.6.33-1.fc13.x86_64 with xorg-x11-drv-intel-2.10.0-4.fc13.x86_64
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
Initially I get graphics at boot, for example the password prompt for the encrypted physical volume, and the text consoles are clearly running with modesetting. But then X doesn't work.
Created attachment 402576 [details]
dmesg - bad 2.6.33-1.fc13.x86_64 (GM965)
Created attachment 402577 [details]
Xorg.0.log - bad xorg-x11-drv-intel-2.10.0-4.fc13.x86_64 (GM965)
Starting aproximately Mar. 1, 2010, video randomly "shakes" and occasionally
all video disappears, i.e., the screen is completely grey or black. This has
occurred when openoffice.org, firefox 3.5.8, and emacs have had focus, implying
the underlying X Window graphics is at fault, or some general component is at
fault, not the individual programs.
Machine is an IBM ThinkPad R52, model 1860CAU laptop running fedora 12 with the
latest updates applied.
uname -a shows:
Linux phj-r52-laptop2 126.96.36.199-70.fc12.i686.PAE #1 SMP Wed Mar 3 04:57:21 UTC 2010 i686 i686 i386 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
and /var/log/Xorg.0.log shows:
(II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
xrandr -q shows:
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024x768 60.0*+ 60.0
800x600 60.3 56.2
BTW, Pete Johnson's simptom probably has nothing to do with this bug.
Nothing is randomly shaking or anything in my case. The initialization
Yes, I agree with Pete Z, the bug Pete J reported in comment 11 doesn't sound related. The symptoms I reported are also different from those reported initially in this bug, though they may be related. For me the switch to gfx works on boot and I can see the Fedora symbol animated in the middle of the screen. However X won't start, that's when I see garbage on the screen. Switching back to a VT doesn't help (still garbage on the screen) but I can hit ctrl-alt-delete then to reboot.
My system is working now. It looks like the F13 install must have put a bogus /etc/X11/xorg.conf in place? It contained a configuration snippet to force the vesa driver. I removed the xorg.conf entirely and now X uses the intel driver and is working well.
An intriguing idea but not in my case. Glad it worked out for someone though.
While I know this looks like a kernel issue, I am reassigning it over to xorg-x11-drv-intel to get the X folks looking at it.
(In reply to comment #10)
> Created an attachment (id=402577) [details]
> Xorg.0.log - bad xorg-x11-drv-intel-2.10.0-4.fc13.x86_64 (GM965)
This has nothing to do with this bug ... you Xorg is actually using a VESA driver.
(In reply to comment #15)
> An intriguing idea but not in my case. Glad it worked out for someone though.
Pete, could we get /var/log/Xorg.0.log from non-working configuration? Also, am I right, you have no /etc/X11/xorg.conf or any configuration in /etc/X11/xorg.conf.d?
I have no /etc/X11/xorg.conf and /etc/X11/xorg.conf.d is empty (not even
dot-files). However, please note that the problem occurs before X is started.
The X11 configuration files should not be in effect, and there is no
Xorg.0.log. I have no Plymouth.
This bug is assigned to xorg-x11-drv-intel because same people work on
in-kernel code and the X11 module.
I updated the OS, so kernel is
Created attachment 431529 [details]
Photo of the problem
Pete, I'm reasonably sure this is because you have VT-D enabled, and that your BIOS doesn't set it up properly. Booting with iommu=off or with VT-D disabled in the BIOS should fix it. Can you try that?
Thanks, booting with iommu=off works. And I know this box has a duff BIOS.
I guess what threw me off was that F12 and RHEL 6 worked. Should I close this?
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.
More information and reason for this action is here:
This is therefore really a kernel bug. Assigning to David Woodhouse as he just loves BIOS / iommu issues, right David? Ajax, do add a note if you can provide any pointers for kernel team that wouldn't be obvious.
Does this still happen with the latest f14 or f15 kernel?
I sent that computer to Joe Vlck at mothership and bought a new one.
We probably should close this bug, if Darrell is ok with that.
Thanks Pete. I'm going to be a bit proactive and close it out for now. If it's still happening in a new release, we can open a new bug and gather the relevant information.