Bug 449491 - intel driver, lockup, 845G chipset
intel driver, lockup, 845G chipset
Status: CLOSED DUPLICATE of bug 461829
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
rawhide
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-02 15:47 EDT by Jason Long
Modified: 2008-11-07 12:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-07 12:06:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log file for when X freezes (22.66 KB, text/plain)
2008-06-02 15:47 EDT, Jason Long
no flags Details
My X.org configuration file (this config causes lockups) (811 bytes, text/plain)
2008-06-02 16:32 EDT, Jason Long
no flags Details
Xorg.0.log including crash (27.21 KB, text/plain)
2008-07-20 13:56 EDT, Ralf Ertzinger
no flags Details

  None (edit)
Description Jason Long 2008-06-02 15:47:38 EDT
Description of problem:

X.org freezes the console on startup (using "startx", or booting to runlevel 5.)
The console is unresponsive to terminal switching (Ctrl+Alt+F1, etc.) or to
reboot (Ctrl+Alt+Del). SSH still works fine.


Version-Release number of selected component:
 xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.i386
 xorg-x11-server-common-1.4.99.901-29.20080415.fc9.i386
 xorg-x11-drv-i810-2.2.1-24.fc9.i386


How reproducible:
 happens at least 75% of the time. Occassionally, X.org starts and displays the
desktop screen just fine. However, after shutting the X session down, and trying
to start another one, it will likely freeze again.


Steps to Reproduce:
1. boot to runlevel 3
2. login
3. run "startx"

Actual results:
  blank screen,
  keyboard and mouse are totally unresponsive (e.g. numlock key does not toggle
numlock led)
  ctrl+alt+f1, ctrl+alt+f2, ctrl+alt+del all have no effect


Expected results:
  display of Gnome desktop


Additional info:

I will attach a full Xorg.0.log. The following lines from that log file may be
interesting:

  Error in I830WaitLpRing(), timeout for 2 seconds
  pgetbl_ctl: 0x1ffe0001 getbl_err: 0x00000000
  ipeir: 0x00000000 iphdr: 0x00ffffff
  LP ring tail: 0x00016de0 head: 0x00016df0 len: 0x0001f001 start 0x00000000
  eir: 0x0000 esr: 0x0000 emr: 0xff7b
  instdone: 0xffc1 instpm: 0x0000
  memmode: 0x00000000 instps: 0x0000002c
  hwstam: 0xeffe ier: 0x0002 imr: 0x053c iir: 0x0081

  Fatal server error:
  lockup

This may be a duplicate of Bug #436896, but that bug features a different Intel
chipset...
Comment 1 Jason Long 2008-06-02 15:47:38 EDT
Created attachment 307663 [details]
Xorg.0.log file for when X freezes
Comment 2 Jason Long 2008-06-02 16:32:25 EDT
Created attachment 307812 [details]
My X.org configuration file (this config causes lockups)

I realized I should've included my xorg.conf file. Here it is.

Also, my Linux kernel version is:
  2.6.25.3-18.fc9.i686
Comment 3 Jason Long 2008-06-02 16:35:54 EDT
I found myself a work-around.

If I add "NoAccel" to the device section, e.g.

Section "Device"
        Identifier  "Videocard0"
        Driver      "intel"
        Option      "NoAccel"
EndSection

I am no longer able to replicate the problem.
Comment 4 Ralf Ertzinger 2008-07-20 13:55:05 EDT
I'm seeing something similar, on a 945GM running rawhide.

Attaching Xorg.0.log, there is no xorg.conf.

RPM: xorg-x11-drv-i810-2.3.2-2.fc9.i386

Has happened only twice so far, both time several hours after the system had
come back from suspend.
Comment 5 Ralf Ertzinger 2008-07-20 13:56:11 EDT
Created attachment 312222 [details]
Xorg.0.log including crash
Comment 6 Jason Long 2008-10-01 08:22:36 EDT
I am now running the following versions of X.org. The lockups/freezes still occur when Acceleration is enabled. This is on my 845G Intel chipset.

xorg-x11-server-Xorg-1.5.0-2.fc9.i386
xorg-x11-server-common-1.5.0-2.fc9.i386
xorg-x11-drv-i810-2.3.2-2.fc9.i386
Comment 7 Ariszló 2008-10-08 05:38:00 EDT
I also have Intel 82845G but I had no problem using it up until Fedora 10 Beta.

Now this is what happens.

No problem if I am using the intel driver with Jason's NoAccel option:

Section "Device"
        Identifier  "Videocard0"
        Driver      "intel"
        Option      "NoAccel"
EndSection

No problem with vesa either.

Using the intel driver without the "NoAccel" option, the boot process reaches the GDM login screen and then freezes so hard that even Alt+Ctrl+Delete does not work. The same happens if I delete xorg.conf.

Using the i810 driver with or without the "NoAccel" option (no difference), the boot process will not reach the GDM login screen. All I have is a blank screen with a blinking cursor. Alt+Ctrl+Delete and the virtual terminals work, though.
Comment 8 Philip Heron 2008-10-08 06:10:46 EDT
I've had a stable system since disabling the Composite extension:

Section "Extensions"
    Option "Composite" "Disable"
EndSection

I haven't been using the desktop effects, so I'm not sure why this helped me.
Comment 9 Jason Long 2008-10-10 15:12:38 EDT
I tried disabling the Composite extension, but it made no discernable change in behavior for me.

This week I *upgraded* to Fedora Rawhide. I am now running
xorg-x11-server-Xorg-1.5.1-10.fc10.i386
xorg-x11-server-common-1.5.1-10.fc10.i386
xorg-x11-drv-i810-2.4.2-9.fc10.i386

I now have a new behavior. The display is no longer locking up on me, but X is still failing to start up. I get the following message:

>>>
(EE) intel(0): ivch detect failed due to address mismatch (0 vs 2)
(EE) intel(0): Failed to pin front buffer: Cannot allocate memory

Fatal server error:
Couldn't bind memory for BO front buffer
<<<

This occurs when I do not have "NoAccel" in the xorg.conf file. When I add "NoAccel" the X server starts up and works, but is slow.
Comment 10 Matěj Cepl 2008-11-07 12:06:16 EST

*** This bug has been marked as a duplicate of bug 461829 ***

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