Bug 474118 - xorg intel driver causes X to hang on i830 chipset
xorg intel driver causes X to hang on i830 chipset
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-02 05:41 EST by Joel Uckelman
Modified: 2009-09-21 10:11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-21 10:11:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xorg.conf from my Thinkpad X30 (593 bytes, text/plain)
2008-12-02 05:41 EST, Joel Uckelman
no flags Details
xorg.conf, working, but with hardware acceleration turned off (628 bytes, text/plain)
2008-12-03 14:06 EST, Joel Uckelman
no flags Details
log when X hangs (43.86 KB, text/plain)
2008-12-03 14:07 EST, Joel Uckelman
no flags Details
Xorg.0.log from unresponsive X login screen. (30.53 KB, text/plain)
2008-12-09 15:08 EST, Bryan Schneiders
no flags Details

  None (edit)
Description Joel Uckelman 2008-12-02 05:41:43 EST
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):


How reproducible:


Steps to Reproduce:
1. Try to install Fedora.
2. Or, alternately, if you installed by upgrading via yum, try to start X.
Actual results:

X will lock up the machine. In some cases, everything but the mouse pointer becomes inoperable.

Expected results:

X starts and is usable.

Additional info:

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.
Comment 1 Matěj Cepl 2008-12-03 12:52:06 EST
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.
Comment 2 Joel Uckelman 2008-12-03 14:06:08 EST
Created attachment 325576 [details]
xorg.conf, working, but with hardware acceleration turned off
Comment 3 Joel Uckelman 2008-12-03 14:07:06 EST
Created attachment 325578 [details]
log when X hangs
Comment 4 Joel Uckelman 2008-12-03 14:08:10 EST
The first xorg.conf which I attached when I reported the bug is the one which exhibits the problem.
Comment 5 Bryan Schneiders 2008-12-09 15:08:28 EST
Created attachment 326387 [details]
Xorg.0.log from unresponsive X login screen.
Comment 6 Bryan Schneiders 2008-12-09 15:09:39 EST
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.
Comment 7 Bryan Schneiders 2008-12-09 15:18:58 EST
Is this a duplicate of  Bug 473427 ?
Comment 8 Mike C 2009-01-05 09:40:50 EST
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.
Comment 9 Joel Uckelman 2009-01-05 09:58:01 EST
(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.
Comment 10 Mike C 2009-01-05 10:04:07 EST
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.
Comment 11 Mike C 2009-01-06 07:58:49 EST
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.
Comment 12 Mike C 2009-01-06 10:56:48 EST
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.
Comment 13 Joel Uckelman 2009-06-21 17:31:25 EDT
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.
Comment 14 Vedran Miletić 2009-09-21 10:11:12 EDT
Closing per comment #13.

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