Bug 650544 - i965 behaves really freaking in F14&F15
Summary: i965 behaves really freaking in F14&F15
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-07 00:05 UTC by Krzysztof "Uosiu" Hajdamowicz
Modified: 2018-04-11 07:48 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-08-16 16:58:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/messages (217.33 KB, application/x-gzip)
2010-11-07 00:05 UTC, Krzysztof "Uosiu" Hajdamowicz
no flags Details
fpaste-dmesg.txt from fpaste (69.49 KB, text/plain)
2010-11-09 14:37 UTC, Matěj Cepl
no flags Details
fpaste-sysinfo.txt from fpaste (26.78 KB, text/plain)
2010-11-09 14:37 UTC, Matěj Cepl
no flags Details
fpaste-Xorg.0.log.old.txt from fpaste (72.12 KB, text/plain)
2010-11-09 14:37 UTC, Matěj Cepl
no flags Details
fpaste-Xorg.0.log.txt from fpaste (70.99 KB, text/plain)
2010-11-09 14:37 UTC, Matěj Cepl
no flags Details
fpaste-Xorg.9.log.txt from fpaste (73.00 KB, text/plain)
2010-11-09 14:37 UTC, Matěj Cepl
no flags Details
anaconda.log, syslog, X.log from during install of F14 when X failed to start. (22.53 KB, application/x-gzip)
2010-11-26 23:17 UTC, John Brier
no flags Details
fpaste --sysinfo after initial install (before yum update) (53.29 KB, text/plain)
2010-11-26 23:32 UTC, John Brier
no flags Details
after initial install (before yum update) dmesg (63.79 KB, text/plain)
2010-11-26 23:33 UTC, John Brier
no flags Details
after initial install (before yum update) Xorg.0.log (8.20 KB, text/plain)
2010-11-26 23:34 UTC, John Brier
no flags Details
nomodeset drm.debug=0x04 Xorg.*.log (50.29 KB, text/plain)
2010-11-26 23:47 UTC, John Brier
no flags Details
nomodeset drm.debug=0x04 dmesg (63.36 KB, text/plain)
2010-11-26 23:47 UTC, John Brier
no flags Details
nomodeset drm.debug=0x04 /var/log/messages (276.85 KB, text/plain)
2010-11-26 23:48 UTC, John Brier
no flags Details
'X -configure' generated xorg.conf (uses intel driver) (2.11 KB, text/plain)
2010-11-27 00:22 UTC, John Brier
no flags Details
'X -configure' generated xorg.conf in use all '/var/log/Xorg.*.log' files (41.51 KB, text/plain)
2010-11-27 00:24 UTC, John Brier
no flags Details
'X -configure' changed to Driver "vesa-Xorg.0.log (70.35 KB, text/plain)
2010-11-27 00:29 UTC, John Brier
no flags Details
modesetting ENABLED xorg.conf generated by 'X -configure' Xorg.0.log (70.35 KB, text/plain)
2010-11-27 00:49 UTC, John Brier
no flags Details
modesetting ENABLED no-xorg.conf intel-driver Xorg.0.log (75.99 KB, text/plain)
2010-11-27 00:50 UTC, John Brier
no flags Details

Description Krzysztof "Uosiu" Hajdamowicz 2010-11-07 00:05:14 UTC
Created attachment 458396 [details]
/var/log/messages

Description of problem:
Freshly installed Fedora 14 on Thinkpad R61i 8943-DKG
fpaste --sysinfo
http://fpaste.org/omNa/

In Fedora 13 everything worked out-of-the box.
To install F14 i had to add nomodeset to kernel parameters. In other case - screen is blank (black).
After install F14 - nomodeset is required to finish booting the system.
With KMS enabled plymouth enters eyecandy mode, but none of VTerms contains standard login prompt and GDM can't start. Keyboard reacts for capslock etc.
With nomodeset - system enters GDM. Overall graphics experience is extremally poor. Compiz segfaults X.org, video playback experience varies a lot. 720p/AC3 video is a bit laggy, but acceptable in mplayer, youtube standard lowres video in flash looks like slideshow

Version-Release number of selected component (if applicable):
xorg-x11-drv-intel-2.12.0-7.fc15.x86_64
Fedora 14, 15 and rawhide behaves perfectly the same- I've upgraded 14 to 15 in hope to fix the problem

How reproducible:
Always

Steps to Reproduce:
1. Install F14 from DVD
2. Boot it
3. Start using it
  
Actual results:
KMS makes system behave weird. Graphics performance is poor.

Expected results:
Problemless behavior of system like in F13

Additional info:

Xorg.0.log : http://fpaste.org/ci4m/
Xorg.0.log.old : http://fpaste.org/YaNN/
Xorg.9.log : http://fpaste.org/eUPQ/
dmesg: http://fpaste.org/mmze/

Comment 1 Matěj Cepl 2010-11-09 14:37:19 UTC
Created attachment 459117 [details]
fpaste-dmesg.txt from fpaste

Comment 2 Matěj Cepl 2010-11-09 14:37:26 UTC
Created attachment 459118 [details]
fpaste-sysinfo.txt from fpaste

Comment 3 Matěj Cepl 2010-11-09 14:37:35 UTC
Created attachment 459119 [details]
fpaste-Xorg.0.log.old.txt from fpaste

Comment 4 Matěj Cepl 2010-11-09 14:37:42 UTC
Created attachment 459120 [details]
fpaste-Xorg.0.log.txt from fpaste

Comment 5 Matěj Cepl 2010-11-09 14:37:49 UTC
Created attachment 459121 [details]
fpaste-Xorg.9.log.txt from fpaste

Comment 6 Matěj Cepl 2010-11-09 14:44:14 UTC
> [    56.132] (==) Using config file: "/etc/X11/xorg.conf"
> [    56.363] (II) VESA: driver for VESA chipsets: vesa

According to your Xorg logs, you use VESA driver (from xorg-x11-drv-vesa). Could you please ATTACH /etc/X11/xorg.conf to this bug? Also, what happens when remove /etc/X11/xorg.conf (move it somewhere else where Xorg won't find it)?

When you remove the configuration file, please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 7 Krzysztof "Uosiu" Hajdamowicz 2010-11-09 14:49:40 UTC
After forcing driver="intel" in xorg.conf (driver vesa was declared in /etx/X11/xorg.conf) system boots and works. So the only one problem is why F14 installer can't work on my graphics card with KMS?

Comment 8 Matěj Cepl 2010-11-09 22:26:53 UTC
(In reply to comment #7)
> After forcing driver="intel" in xorg.conf (driver vesa was declared in
> /etx/X11/xorg.conf) system boots and works.

You can just remove /etc/X11/xorg.conf and most likely you would get intel driver as well. Or of course you can replace

Driver "vesa"

with 

Driver "intel"

in your xorg.conf as well.

> So the only one problem is why F14 installer can't work on my graphics card
> with KMS?

Lately some graphics card don't work well with VESA driver.

Much more interesting question is why do you have "vesa" driver in your xorg.conf? Did you create it now, or was it created by the Fedora 14 (not earlier) installer?

Thank you for reporting the bug

Comment 9 Krzysztof "Uosiu" Hajdamowicz 2010-11-10 20:26:17 UTC
Read carefully first post:

To install F14 i had to add nomodeset to kernel parameters. In other case -
screen is blank (black).

I had to use "Install fedora with basic graphics driver" to see anaconda. With normal install option after booting kernel in lowres mode, when kernel should switch do KMS i could only see blank screen (black) and nothing else

Comment 10 Matěj Cepl 2010-11-11 11:24:30 UTC
(In reply to comment #9)
> Read carefully first post:
> 
> To install F14 i had to add nomodeset to kernel parameters. In other case -
> screen is blank (black).
> 
> I had to use "Install fedora with basic graphics driver" to see anaconda. With
> normal install option after booting kernel in lowres mode, when kernel should
> switch do KMS i could only see blank screen (black) and nothing else

nomodeset and "basic graphics driver" are two different things.

* "Basic graphics driver" is more human-friendly name for VESA driver.
* nomodeset uses native driver (xorg-x11-drv-intel in your case) but without using kernel modesetting capabilities. Obviously native driver (with or without KMS) understands the graphics card better and it always works better than emulation of third standard (VESA in this situation).

Meaning, for you the best solution would be probably to have nomodeset on your kernel command line and no /etc/X11/xorg.conf, so that you would be using intel driver without KMS.

Does it make a sense?

Comment 11 John Brier 2010-11-26 23:15:52 UTC
(In reply to comment #0)
> In Fedora 13 everything worked out-of-the box.
> To install F14 i had to add nomodeset to kernel parameters. In other case -
> screen is blank (black).

I have the same behavior on an Asus U3S

I am attaching 'f14-install-nomodeset.tar.gz' which includes

/tmp/anaconda.log
/tmp/syslog
/tmp/X.log

from after the X failed to start during install.

Comment 12 John Brier 2010-11-26 23:17:42 UTC
Created attachment 463162 [details]
anaconda.log, syslog, X.log from during install of F14 when X failed to start.

Comment 13 John Brier 2010-11-26 23:32:13 UTC
After fresh install with nomodeset enabled, I manually had to do init 5 because default was 3..

X failed to start

I am attaching
 'after-initial-install-fpaste--sysinfo.txt'
 'after-initial-install-Xorg.0.log' (sorry I didn't get the others)
 'after-initial-install-dmesg'

Comment 14 John Brier 2010-11-26 23:32:50 UTC
Created attachment 463165 [details]
fpaste --sysinfo after initial install (before yum update)

Comment 15 John Brier 2010-11-26 23:33:36 UTC
Created attachment 463166 [details]
after initial install (before yum update) dmesg

Comment 16 John Brier 2010-11-26 23:34:14 UTC
Created attachment 463167 [details]
after initial install (before yum update) Xorg.0.log

Comment 17 John Brier 2010-11-26 23:46:01 UTC
(In reply to comment #6)
> > [    56.132] (==) Using config file: "/etc/X11/xorg.conf"
> > [    56.363] (II) VESA: driver for VESA chipsets: vesa
I have similar things in my logs, see above

> According to your Xorg logs, you use VESA driver (from xorg-x11-drv-vesa).
> Could you please ATTACH /etc/X11/xorg.conf to this bug? Also, what happens when
> remove /etc/X11/xorg.conf (move it somewhere else where Xorg won't find it)?

For me, I have never had an xorg.conf

> When you remove the configuration file, please add drm.debug=0x04 to the kernel
> command line, restart computer, and attach
done

> * your X server config file (/etc/X11/xorg.conf, if available),
> * X server log file (/var/log/Xorg.*.log)
> * output of the dmesg command, and
> * system log (/var/log/messages)
> 
> to the bug report as individual uncompressed file attachments using the
> bugzilla file attachment link above.
> 
> We will review this issue again once you've had a chance to attach this
> information.
> 

I will do that.

I am attaching all my Xorg.*.log as 

nomodeset-drm.debug0x04-Xorg.star.log

also 

nomodeset-drm.debug0x04-dmesg.txt
nomodeset-drm.debug0x04-var-log-messages.txt

as requested

Comment 18 John Brier 2010-11-26 23:47:05 UTC
Created attachment 463170 [details]
nomodeset drm.debug=0x04   Xorg.*.log

Comment 19 John Brier 2010-11-26 23:47:53 UTC
Created attachment 463171 [details]
nomodeset drm.debug=0x04 dmesg

Comment 20 John Brier 2010-11-26 23:48:37 UTC
Created attachment 463172 [details]
nomodeset drm.debug=0x04 /var/log/messages

Comment 21 John Brier 2010-11-27 00:20:01 UTC
I did 'X -configure' and it created an /root/xorg.conf.new which set the driver to intel, I dropped it into /etc/X11/xorg.conf

I am attaching /var/log/Xorg.*.log

as X-configure-intel-Xorg.star.log

Comment 22 John Brier 2010-11-27 00:22:41 UTC
Created attachment 463173 [details]
'X -configure' generated xorg.conf (uses intel driver)

Comment 23 John Brier 2010-11-27 00:24:20 UTC
Created attachment 463174 [details]
'X -configure' generated xorg.conf in use all  '/var/log/Xorg.*.log' files

Comment 24 John Brier 2010-11-27 00:28:14 UTC
Next I just edited the xorg.conf generated by 'X -configure' and s

changed

 Driver      "intel"

to

 Driver      "vesa"

This allowed X to start up but I only got 1024x768 resolution, not the 1280x800 native res of my LCD.

I am attaching the /var/log/Xorg.0.log

Comment 25 John Brier 2010-11-27 00:29:46 UTC
Created attachment 463175 [details]
'X -configure'  changed to Driver "vesa-Xorg.0.log

Comment 26 John Brier 2010-11-27 00:42:27 UTC
Okay so based on the error I saw in Xorg.0.log:

[  1625.856] (EE) intel(0): No kernel modesetting driver detected.
[  1625.856] (II) UnloadModule: "intel"

I decided to put the the xorg.conf generated by 'X -configure' into /etc/X11/xorg.conf including the Driver "intel" and then *remove* 'nomodeset' from the kernel line, and *this* allowed it to work, with 1280x1024 native resolution.

I'm attaching the /var/log/Xorg.0.log now

Comment 27 John Brier 2010-11-27 00:49:14 UTC
Created attachment 463176 [details]
modesetting ENABLED xorg.conf generated by 'X -configure' Xorg.0.log

Comment 28 John Brier 2010-11-27 00:49:58 UTC
Okay just to be sure I removed the /etc/X11/xorg.conf that was generated by 'X -configure' and rebooted and all is fine..

attaching Xorg.0.log

Comment 29 John Brier 2010-11-27 00:50:34 UTC
Created attachment 463178 [details]
modesetting ENABLED no-xorg.conf intel-driver Xorg.0.log

Comment 30 John Brier 2010-11-27 01:00:11 UTC
===Summary of troubleshooting===

So originally in the Description the problem for the reporter was that after install during the first boot nothing worked, so he had to enable nomodeset.

In my case I didn't have to enable nomodeset.. i already had nomodeset on the kernel line.. apparently anaconda caries over any options you have to use to start the installer to the grub.conf after it's installed.

For some reason the system was not set to boot to runlevel 5.. I don't think this is a big deal.. probably my fault (though I swear I set it to install graphical desktop).

Then I did all the troubleshooting with vesa/intel *while* 'nodmodeset' was still enabled on the kernel line only to finally try removing it based on this error in /var/log/Xorg.0.log:

[  1625.856] (EE) intel(0): No kernel modesetting driver detected.
[  1625.856] (II) UnloadModule: "intel"

So it seems intel driver depends on this?

The other guy didn't say if he had to remove 'nomodeset' to get this to work, he just said he had to switch from 'Driver "vesa"' to 'Driver "intel"'

I don't know where he got that from, maybe he put it in there...

I think he is correct though regarding comment #7

===
After forcing driver="intel" in xorg.conf (driver vesa was declared in
/etx/X11/xorg.conf) system boots and works. So the only one problem is why F14
installer can't work on my graphics card with KMS?
===

Why does F14 anaconda require 'nomodeset' and not work with KMS?

somethign in the kernel/drivers of the installation kernel/initrd/media?


What is the fix for this? Release notes information?

Does this need to be moved to a different component, like anaconda?

Comment 31 John Brier 2010-11-27 02:29:24 UTC
I haven't tested this, but I think if you just do an F14 install with this graphics card, use nomodeset to install and then after it reboots, remove 'nomodeset' from the kernel line and reboot all will be fine.

I have no idea where the original reporter came up with 'Driver "vesa"' that seems wrong..

This happens in RHEL 6 too, and I did verify if you simply remove 'nomodeset' then reboot and do nothing else X will work

https://bugzilla.redhat.com/show_bug.cgi?id=657664

Comment 32 Stefan Hellermann 2010-12-02 17:56:47 UTC
I've run into the same issue, after removing /etc/X11/xorg.conf and nomodeset everything works now. At install time I got a black screen, so I tried "basic graphics driver". After Fedora was installed I removed the nomodeset from kernel cmdline, but the image from bootup was frozen. I think I could login (I heard the login-sound after entering my login without seeing anything)

I thought remove this nomodeset is enough to get back to the normal driver. 
Until I read this thread I had not noticed that there was a Xorg.conf with vesa.

I think it's a bad idea using vesa without nomodeset. Maybe there could be some checks against this, somewhere? And probably it would be good to inform the user that he is using vesa.

Comment 33 Fedora End Of Life 2012-08-16 16:58:54 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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