Red Hat Bugzilla – Bug 474118
xorg intel driver causes X to hang on i830 chipset
Last modified: 2009-09-21 10:11:12 EDT
Created attachment 325352 [details]
xorg.conf from my Thinkpad X30
Description of problem:
On a Thinkpad X30 with an Intel i380M graphics chipset, X locks up immediately on starting. This happens with the Fedora 10 installer, when booting to runlevel 5 after a Fedora 10 install, and also when starting X from a virtual terminal in runlevel 3.
This makes it impossible to use the installer in GUI mode, and impossible to use X on this hardware, in general. This was not a problem in Fedora 9.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to install Fedora.
2. Or, alternately, if you installed by upgrading via yum, try to start X.
X will lock up the machine. In some cases, everything but the mouse pointer becomes inoperable.
X starts and is usable.
I found a workaround: X will work if I add the line
Option "NoAccel" "yes"
to the Device section of my xorg.conf, but then the driver is running unaccelerated. It worked without this in Fedora 9 (though there was occasional, but bearable, screen corruption).
This workaround isn't helpful at all at install-time, however, since there the user has no way of adding this option to the installer's xorg.conf.
Note also that if I change the driver to "vesa", the X server hangs that way also---the effect on screen is something like a tie-dyed T-shirt---but it's not a hard lock-up, and I can still return to a VT to kill X.
I've attached the xorg.conf, though it's not very enlightening.
I've also commented on this in Bug 464869, which I might be duplicating right now, but I'm not certain that guy is having the same problem as me, which is why I'm reporting this separately.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 325576 [details]
xorg.conf, working, but with hardware acceleration turned off
Created attachment 325578 [details]
log when X hangs
The first xorg.conf which I attached when I reported the bug is the one which exhibits the problem.
Created attachment 326387 [details]
Xorg.0.log from unresponsive X login screen.
I'm having the same problem on a Dell Dimension 2400 with the following graphics adapter according to lspci:
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA controller])
I'll attach my Xorg.0.log in case it's helpful.
Is this a duplicate of Bug 473427 ?
Same problem with a Dell Dimension 2400 with the same graphics chip....
This is pretty urgent as there is no sensible way to get F10 into this machine.
I have made an install iso using mock/pungi and rebuilt using all current rpms as at 3rd January, and this iso gives a messed up graphics install as soon as the first graphics screen is presented during the install.
(In reply to comment #8)
> This is pretty urgent as there is no sensible way to get F10 into this machine.
You can work around this by doing a text-based install. (Type 'linux text' at the initial installer prompt.) Once you have an install, you need to apply the change mentioned above to your Xorg.conf. That should get you going.
Nonetheless, this *is* a serious problem, as this workaround shouldn't be necessary, and anyway running X unaccelerated is not great.
One other comment here is that I tried booting the install with "nomodeset" on the kernel line (This should not work as it is not an ATI card!)- (I start the install from a grub stansa and do an HD install that references the DVD iso from a partition that won't be changed during install.
In that instance when I get to the point that the iso has been called from the HD install method it produces a clean looking graphical screen but X hangs at that point and I cannot enter any more input or do anything other than reboot, and I am unable to switch VT either to get at any diagnostics.
I also tried adding vga=0x318 to the kernel line with the same results.
I am not keen to continue with a text install as running F10 with X unaccelerated would be tedious in the extreme. However if there is a way to get at more diagnostics it would useful to progress this.
I have now tested an install on a Dimension 2400 which has the 82845G graphics
chipset - the only way I could get a graphical install was to run (using my
updated F10 DVD personal re-spin including updates to 3rd January 2009), and
initiating the install from a grub stansa calling the iso from an HD install,
and including the parameter "xdriver=vesa nomodeset" from the kernel boot line.
This allowed a graphical install and when it got to firstboot I intercepted the
boot and entered the same parameter as above to the kernel line to initiate
This worked and I can then boot the system with the same procedure to run as
"normal" - however the graphics with the vesa driver are far from perfect, and
the screen is fuzzy despite having 1280x1024 resolution set.
I have edited xorg.conf to include the vesa driver and it will boot although
the text mode Plymouth boot line works apart from a brief interruption at an
early stage when the screen blanks for a moment.
system-config-display is not installed by default and this may help a little if
installed and used to reconfigure the display - but the basic problem is that
the driver is buggy and needs fixing.
Once installed by changing xorg.conf to have the "intel" driver and using the "NoAccel" option gives me a normal graphical boot (apart from a short time when the screen goes blank around a third of the way across the Plymouth blue+white line, and I get the correct screen resolution but the graphics performance is poor (eg dragging a terminal window is choppy though it does work).
I could not get the i810 driver to work at all even with the NoAccel option.
This problem no longer occurs with Fedora 11. I had no problem installing F11 on the same laptop which had this problem with F10 installation.
Closing per comment #13.