Bug 469292

Created attachment 322017 [details]
Output from lspci -vvv

Created attachment 322018 [details]
xorg.conf file generated by Xorg -configure

Created attachment 322019 [details]
The Xorg.0.log when it hangs with a config from "Xorg -configure"

Created attachment 322020 [details]
The Xorg.0.log when NoAccel is True (works, though slow)

(In reply to comment #4)
> Created an attachment (id=322020) [details]
> The Xorg.0.log when NoAccel is True (works, though slow)

this is xorg.conf, not Xorg.0.log.

Created attachment 322090 [details]
The Xorg.0.log when NoAccel is True (works, though slow)

Sorry - here's the correct file

I've got the same problem on a Dell Optiplex GX260 which I recently installed rawhide on. Same graphics chipset, same problems, same result with the NoAccel option (works but very slow).

The situation is improved with kernel-2.6.27.4-73.fc10 from Koji:

http://koji.fedoraproject.org/koji/buildinfo?buildID=68324

I can now leave the acceleration on, and 2D seems stable.  However, running and 3D (Compiz, OpenGL games) causes problems (bug #469771).

The -73 kernel doesn't fix it for me. I still get a locked up keyboard and garbled text on the screen though it does look a little better. Still get the 

[drm:i915_driver_load] *ERROR* failed to enable MSI
[drm] Initialized i915 1.6.0 20080730 on minor 0

messages too.

Created attachment 322658 [details]
The Xorg.0.log when it hangs without a config file, newer kernel & Xorg

Little improvement.  The Xserver displayed the X11 crosshatch background, but hung without a mouse.  Versions were:
  kernel-2.6.27.4-68.fc10.i686
  xorg-x11-server-Xorg-1.5.2-12.fc10.i386
  xorg-x11-drv-i810-2.5.0-1.fc10.i386

Again this showed up in /var/log/messages:
  kernel: [drm] Initialized drm 1.1.0 20060810
  kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
  kernel: [drm:i915_driver_load] *ERROR* failed to enable MSI
  kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

The Xorg.0.log was slightly different.  Instead of
  (II) config/hal: Adding input device Power Button (CM)
.. it now had
  (II) config/hal: Adding input device Video Bus
A lot of "Power Button" references changed to "Video Bus", but otherwise there seems to be no significant change in the aberrant behaviour.  Does the kernel handle drm and acceleration now?  Could this be a kernel issue?

Updated to latest rawhide kernel - still hangs with same symptoms and /var/log/messages entries.  Current versions:
  kernel-2.6.27.4-79.fc10.i686
  xorg-x11-server-Xorg-1.5.2-12.fc10.i386
  xorg-x11-drv-i810-2.5.0-1.fc10.i386

> [drm:i915_driver_load] *ERROR* failed to enable MSI
Same message appears in bug 461205. Might be related, might be the same root cause.

Created attachment 323289 [details]
Xorg.0.log from 2008/11/11 rawhide, no config file

Tried with today's rawhide updates;  Problem persists.  Tested versions are:
  kernel-2.6.27.5-94.fc10.i686
  xorg-x11-server-Xorg-1.5.2-12.fc10.i386
  xorg-x11-drv-i810-2.5.0-3.fc10.i386

I still get the following messages in /var/log/messages when the Xserver starts:
Nov 11 20:00:43 Blu kernel: [drm] Initialized drm 1.1.0 20060810
Nov 11 20:00:43 Blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Nov 11 20:00:43 Blu kernel: [drm:i915_driver_load] *ERROR* failed to enable MSI
Nov 11 20:00:43 Blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

I'm attaching a copy of the latest Xorg.0.log, and some ps+lsof output, showing what files and devices the Xserver has actually opened.

Created attachment 323290 [details]
ps for the system, and lsof output for the Xserver process

Created attachment 323470 [details]
Output from ps , lsof , lsmod, and Xorg.0.log

Latest versions:
kernel-2.6.27.5-101.fc10.i686
xorg-x11-server-Xorg-1.5.2-12.fc10.i386
xorg-x11-drv-i810-2.5.0-3.fc10.i386

New kernel, new test.  It still doesn't work with the same symptoms:
X starts, black screen (no backlight); On rare occasions the X11 crosshatch background shows up.  No mouse (or xterm) when crosshatch seen.  Keyboard is always unresponsive (CapsLock LED doesn't toggle).  I can ssh in, but when I kill the Xserver with kill -QUIT 3355 (-HUP and -TERM don't work) the machine freezes.  Unresponsive to pings, I have to power cycle to reboot.  No crash info in /var/log/messages.

When X starts, the following is in /var/log/messages:
Nov 13 09:08:41 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Nov 13 09:08:41 localhost kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Nov 13 09:08:41 localhost kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

If there's any additional diagnostic info I can provide, let me know.

Created attachment 323476 [details]
Latest Xorg.0.log with NoAccel asserted in config file

Just as a refresh, here's the output in Xorg.0.log from an operational Xserver when a config file is created with NoAccel asserted.
     Option     "NoAccel"    "true"

Note that both the none-working (previous) and the noaccel log have
  (EE) intel(0): underrun on pipe A!

Performing a diff between the two log files, there appears to be a lot of extra material after
  (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472
  (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448
  (**) Option "Device" "/dev/input/event5"
  (--) SynPS/2 Synaptics TouchPad touchpad found
in the noaccel log file.  Which might be an indicator where Xorg is hanging up?

Created attachment 323675 [details]
Latest Xorg.0.log, no config file

Another day, another kernel; Still no success. The versions:
kernel-2.6.27.5-109.fc10.i686
xorg-x11-server-Xorg-1.5.2-12.fc10.i386
xorg-x11-drv-i810-2.5.0-3.fc10.i386

This time I consistently get the X11 background crosshatch, but no mouse and the keyboard is unresponsive as before.  Diff'ing with the previous Xorg.0.log, there appear to be some differences that may be significant.

Similar output as before in /var/log/messages:
Nov 14 18:45:48 Blu kernel: [drm] Initialized drm 1.1.0 20060810
Nov 14 18:45:48 Blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Nov 14 18:45:48 Blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

One improvement - when the Xserver hangs, I can reboot via ssh without the system itself hanging.

Created attachment 323989 [details]
Latest Xorg.0.log, no config file, with backtrace

Still no joy with today's kernel and Xorg update, but it looks like it's getting closer(?).  This time there's a backtrace included in Xorg.0.log.  The backtrace seems to involve libdrm and synaptics, so I've included their versions as well.
 kernel-2.6.27.5-113.fc10.i686
 xorg-x11-server-Xorg-1.5.3-5.fc10.i386
 xorg-x11-drv-i810-2.5.0-3.fc10.i386
 xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
 libdrm-2.4.0-0.21.fc10.i386

In /var/log/messages:
Nov 18 19:08:43 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Nov 18 19:08:43 localhost kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Nov 18 19:08:43 localhost kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

When I start X, I now get the X11 crosshatch, but as before no mouse cursor, xterm, and the keyboard is unresponsive.  But I get a backtrace in Xorg.0.log, and messages like:
mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
  .. <snip> ..
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.

The X process can't be killed (even with kill -QUIT or -KILL), it's stuck in a "D" state.

Created attachment 324136 [details]
Latest Xorg.0.log, no config file

New kernel, still no joy.  The current versions are:
  kernel-2.6.27.5-117.fc10.i686
  xorg-x11-server-Xorg-1.5.3-5.fc10.i386
  xorg-x11-drv-i810-2.5.0-3.fc10.i386
  xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
  libdrm-2.4.0-0.21.fc10.i386

Started X from run-level 3 using:
startx /usr/bin/xterm -- -logverbose 7

When I start X, I now get the X11 crosshatch, but as before no mouse cursor, xterm, and the keyboard is unresponsive.  This time there is no backtrace in Xorg.0.log, it just hangs.  The "EQ overflowing" messages are gone.  There is an additional error output to the console that is *not* emitted to Xorg.0.log.  Here's the terminal output:

# startx /usr/bin/xterm -- -logverbose 7
xauth:  creating new authority file /root/.serverauth.3219

X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.10.el5 i686 
Current Operating System: Linux blu 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686
Build Date: 16 November 2008  08:29:02PM
Build ID: xorg-x11-server 1.5.3-5.fc10 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Nov 19 21:31:51 2008
(EE) Unable to locate/open config file
New driver is "intel"
(==) Using default built-in configuration (30 lines)
(EE) open /dev/fb0: No such file or directory
[intel_init_bufmgr:592] Error initializing buffer manager.
(EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
Warning: Cannot convert string "nil2" to type FontStruct

The "intel_init_bufmgr:592" message does not show up in Xorg.0.log.

The usual output in /var/log/messages:
Nov 19 20:07:13 Blu kernel: [drm] Initialized drm 1.1.0 20060810
Nov 19 20:07:13 Blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Nov 19 20:07:13 Blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

Some additional investigation;  By creating a xorg.conf file and adding options there's some partial functionality.  As noted, adding 'Option "NoAccel" "True"' works, but with very slow performance.

Instead, adding:
  Option "AccelMethod" "XAA"
On startup I see:
  [intel_init_bufmgr:592] Error initializing buffer manager.
  (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering
This mostly works.  Pointer and xterm appear, but glxgears is only 64 fps.
x11perf -repeat 2 -putimage100  gives a speed of 1280/sec.  But, the Xserver can be stopped and started without hanging.

Adding
  Option "Legacy3D" "True"
  Option "AccelMethod" "XAA"
Is a little better and worse;  The "intel_init_bufmgr" and "(EE) AIGLX error" are gone, the pointer and xterm appear, but the Xserver background is black or a random pattern.  Dragging the xterm around "paints" or "exposes" the Xserver's cross-hatch.  Performance is better.  glxgears scores 186 fps, but the frame is black (no image).  x11perf gives a putimage100 score of 1360/sec.  Sometimes there are artefacts in the xterm area after dragging the window.

So the lockups appear to associated with EXA acceleration.  The intel_init_bufmgr error and lack of AIGLX support is associated with nonLegacy3D.  But Legacy3D is broken as well - glxgears is all black.

By contrast, the latest F9 performance is glxgears 265 fps, x11perf putimage100 at 1450/sec.  This is without using a xorg.conf file.  F10 really looks like a step backward on this hardware.

Any additional tests or debug I can perform?

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

All my computers seem to use the intel driver.   Out of the 3 computers I've formated with with F10 one is having the problem above.

The card having the problem is a "82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device"

My laptop, which works, is a "Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller".


To get it working I found a forum which said to copy the /usr/lib/xorg/modules/drivers/intel_drv.so from ubuntu.  So I copied it from my brother-in-laws ubuntu laptop and it's working fine.

So the problem seems to be somewhere in that driver.

(In reply to comment #22)
> To get it working I found a forum which said to copy the
> /usr/lib/xorg/modules/drivers/intel_drv.so from ubuntu.  So I copied it from my
> brother-in-laws ubuntu laptop and it's working fine.

Congratulations, you achieved something, which to the best of my opinion couldn't work! :D

Anyway, I would be very interested in getting a) /var/log/Xorg.0.log from your machine, and b) version and release of the Ubuntu package where this driver comes from (so that I can find whether there are some patches they have and we don't or vice-versa).

Thanks a lot

Created attachment 325159 [details]
Xorg.0.log using intel_drv.so from Ubuntu 8.10

I followed Michael Carter's suggestion, and pulled /usr/lib/xorg/modules/drivers/intel_drv.so from the Ubuntu 8.10 install CD, and replaced the one on F10.  The Ubuntu liveUSB xserver hung with the same symptoms reported here. To boot the Ubuntu live I had to add "xforcevesa=xforcevesa" to the boot line.

But the Ubuntu / Fedora10 mix worked (mostly).  Using
  startx /usr/bin/xterm -- -logverbose 7
to start X, it came up with a working Xterm, keyboard, and cursor.  The backlight didn't enable at first, but toggling between vtty1 and 7 fixed that.  The Xserver crosshatch background was correct (not black).  glxgears ran with a framerate of 177fps, but the scene was all black.  x11perf -putimage100 gave 1340/sec.

On shutdown, the Xserver terminated normally, without hanging the system.  The Xorg.0.log file is attached.

Would driver from this link http://koji.fedoraproject.org/koji/buildinfo?buildID=62718 work for you as well?

Created attachment 325324 [details]
Xorg.0.log using koji xorg-x11-drv-i810-2.4.2-8.fc10.i386.rpm

I tried installing the rpm:
  wget -nc -nd http://koji.fedoraproject.org/packages/xorg-x11-drv-i810/2.4
.2/8.fc10/i386/xorg-x11-drv-i810-2.4.2-8.fc10.i386.rpm
  rpm -Uvh --force -p xorg-x11-drv-i810-2.4.2-8.fc10.i386.rpm

Now the versions are:
kernel-2.6.27.5-117.fc10.i686
xorg-x11-server-Xorg-1.5.3-5.fc10.i386
xorg-x11-drv-i810-2.4.2-8.fc10.i386
xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
libdrm-2.4.0-0.21.fc10.i386


No success - black screen, keyboard hang (no caps-lock).  The xserver console output was:
[root@blu ~]# startx /usr/bin/xterm -- -logverbose 7
xauth:  creating new authority file /root/.serverauth.3363


X.Org X Server 1.5.3
Release Date: 5 November 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.10.el5 i686 
Current Operating System: Linux blu 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686
Build Date: 16 November 2008  08:29:02PM
Build ID: xorg-x11-server 1.5.3-5.fc10 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec  1 18:09:26 2008
(EE) Unable to locate/open config file
New driver is "intel"
(==) Using default built-in configuration (30 lines)
(EE) open /dev/fb0: No such file or directory
/usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers//intel_drv.so: undefined symbol: intel_bufmgr_fake_init
giving up.
xinit:  Connection refused (errno 111):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.
[root@blu ~]#

The xinit failure error was probably xterm failing to contact the Xserver (which died) due to some internal mismatch.  The Xorg.0.log is attached.  Soon after the machine locked up (not responsive to pings).  This is the last entry in /var/log/messages before the reboot:

Dec  1 18:09:27 Blu kernel: [drm] Initialized drm 1.1.0 20060810
Dec  1 18:09:27 Blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IR
Q 11
Dec  1 18:09:27 Blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

I also tried re-installing xorg-x11-drv-i810-2.5.0-3.fc10.i386.rpm, and just replacing intel_drv.so with the one from koji (since we only used intel_drv.so from ubuntu), but that gave the same results as in comment #26.

I'm having what appears to be the same problem with an Intel 830M chipset, which I reported in Bug 474118, and discovered the same (unsatisfactory) workaround as the commenters here did.

Is there any information I could provide which would be helpful for getting this fixed?

Created attachment 326584 [details]
 Latest Xorg.0.log, no config file, still hangs

More updates - Still no success without a config file. Latest:
kernel-2.6.27.7-134.fc10.i686
xorg-x11-server-Xorg-1.5.3-5.fc10.i386
xorg-x11-drv-i810-2.5.0-4.fc10.i386
xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
libdrm-2.4.0-0.21.fc10.i386
mesa-libGL-7.2-0.14.fc10.i386
mesa-libGLU-7.2-0.14.fc10.i386
mesa-libGL-devel-7.2-0.14.fc10.i386
mesa-dri-drivers-7.2-0.14.fc10.i386

I've upped the logverbose level from 7 to 255
startx /usr/bin/xterm -- -logverbose 255

No apparent errors during startup, on the console or the logs.  But the screen is black (but backlight on) and the keyboard unresponsive (capslock LED doesn't toggle).  No mouse.  It stills hangs on "kill" signals, even a kill -9.  When xorg is hung, I can still ssh into the laptop.

Additional info:  "chvt 2" works (or for any N) before Xorg runs, but chvt hangs afterwards.  The hung chvt can still be killed with ctrl-C.

Nothing suspicious in /var/log/messages:
Dec 10 21:37:21 blu kernel: [drm] Initialized drm 1.1.0 20060810
Dec 10 21:37:21 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 
(level, low) -> IRQ 11
Dec 10 21:37:21 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

Created attachment 327545 [details]
Latest Xorg.0.log, no config file, still hangs

Latest updates, still hangs:
startx /usr/bin/xterm -- -logverbose 255
Screen goes black, backlight comes on (but still black);  no Xserver crosshatch. The keyboard locks up (caps-lock doesn't toggle LED).  No apparent errors in /var/log/messages:

Dec 20 09:27:06 blu acpid: client connected from 2450[0:0]
Dec 20 09:27:08 blu kernel: [drm] Initialized drm 1.1.0 20060810
Dec 20 09:27:08 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Dec 20 09:27:08 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

No obvious errors in /var/log/Xorg.0.log (attached)

Versions:
kernel-2.6.27.7-134.fc10.i686
xorg-x11-server-Xorg-1.5.3-6.fc10.i386
xorg-x11-drv-i810-2.5.0-4.fc10.i386
xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
libdrm-2.4.0-0.21.fc10.i386
mesa-libGL-7.2-0.15.fc10.i386
mesa-libGLU-7.2-0.15.fc10.i386
mesa-libGL-devel-7.2-0.15.fc10.i386
mesa-dri-drivers-7.2-0.15.fc10.i386

I confirm this, and I'd like to point that these other bugs are related:
https://bugzilla.redhat.com/show_bug.cgi?id=473427
https://bugzilla.redhat.com/show_bug.cgi?id=474336

Only way to make it work is with "NoAccel" option in xorg.conf.

Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

Created attachment 327875 [details]
Latest Xorg.0.log, no config file, latest kernel locks up

Versions - the only update was the kernel:
kernel-2.6.27.9-159.fc10.i686
xorg-x11-server-Xorg-1.5.3-6.fc10.i386
xorg-x11-drv-i810-2.5.0-4.fc10.i386
xorg-x11-drv-synaptics-0.15.2-1.fc10.i386
libdrm-2.4.0-0.21.fc10.i386
mesa-libGL-7.2-0.15.fc10.i386
mesa-libGLU-7.2-0.15.fc10.i386
mesa-dri-drivers-7.2-0.15.fc10.i386

There appears to be a regression.  This time the system locks hard during Xorg startup.  In the attached log file, there's nothing after:
  (II) intel(0): Registers before mode setting

The only entries in /var/log/messages are:
  Dec 26 16:38:00 blu kernel: [drm] Initialized drm 1.1.0 20060810
  Dec 26 16:38:01 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
  Dec 26 16:38:01 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0
There's nothing after that line until the laptop's power-cycled to re-start it.

In Comment #20, adding these (instead of "NoAccel") had some partial success:
        Option "Legacy3D" "True"
        Option "AccelMethod" "XAA
Now these options still result in an Xorg lock-up, using either this or the previous (-134) kernel. Only the "NoAccel" option still works.

Created attachment 329691 [details]
Latest RAWHIDE Xorg.0.log, no config file, still hangs

Since F11 is going into alpha, I'm going to switch this bug back over to Rawhide and start reporting on the latest Rawhide updates. This bug still exists in F10 .. so my primary partition is still on F9.  Xorg acceleration has not worked on this hardware since pre-F10 rawhide.  Hopefully it's solved before F11 goes out the door;  I'd be happy to help an Xorg developer work this, given a little direction.

Without a config file, Xorg still locks up.  Display black, keyboard inactive.  The laptop is live (I can ssh in).  No apparent errors in Xorg.0.log (attached) or /var/log/messages.  Run with:

-bash-3.2# startx /usr/bin/xterm -- -logverbose 255 
xauth:  creating new authority file /root/.serverauth.2291


This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.5.99.901 (1.6.0 RC 1)
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.18.el5 i686 
Current Operating System: Linux blu 2.6.29-0.43.rc2.git1.fc11.i686 #1 SMP Mon Jan 19 01:59:56 EST 2009 i686
Build Date: 12 January 2009  06:30:22PM
Build ID: xorg-x11-server 1.5.99.901-1.fc11 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 21 23:44:08 2009

(==) Using default built-in configuration (39 lines)
SELinux: Disabled on system, not enabling in X server

--------------------
After startup, this is emitted to /var/log/messages:
Jan 21 23:44:08 blu acpid: client connected from 2309[0:0]
Jan 21 23:44:08 blu acpid: 1 client rule loaded
Jan 21 23:44:09 blu kernel: [drm] Initialized drm 1.1.0 20060810
Jan 21 23:44:10 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan 21 23:44:10 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

Although there's no apparent response on the keyboard (capslock doesn't even light) pressing any key or trackpad results in several "select returned .. " messages in Xorg.0.log.

Trying a "chvt 3" in a ssh term just hangs, but it can be aborted with cntrl-C.

Per discussons at 
  https://www.redhat.com/archives/fedora-test-list/2009-January/msg00328.html
and initial comments in this thread:
  https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01325.html

.. I'm updating the bug version to Rawhide.  This bug exists in both F10 and Rawhide.  The maintainers can clone the bug at their discretion.  Thanks.

Updated to the latest rawhide kernel-2.6.29-0.48.rc2.git1.fc11.i686.rpm

X still hangs as described before.

Although the Xorg.0.log looks healthy and there are no abnormal messages in /var/log/messages, the Xserver+keyboard is still black and unresponsive.  But these additional symptoms indicate that the server is really locked up:

  "chvt 2" hangs  (works before the Xserver is brought up)
  "chvt 7" does not hang .. that's the vt the X server is posted to.

  The X server does post a socket at 0.0.0.0:6000, but
  "xdpyinfo -display 127.0.0.1:0" hangs
   no activity in /var/log/Xorg.0.log
   wireshark shows xdpyinfo making a X11 initial connection request.
   The X socket repsonds with an ACK, and that's it.

Looks like a duplicate of bug 464866 to me, but no crashes here.

That's a different chipset (this is 845G) and a consistent lockup at startup.  The other bug is tracking random lockups on different hardware, see this comment:
https://bugzilla.redhat.com/show_bug.cgi?id=464866#c19

Matej, are you running a 845G chipset, and without a xorg.conf file (f10 or rawhide)?  If that *does* work for you, perhaps you could post a Xorg.0.log with "-logverbose 255"?  It could be useful to compare a successful output to the one's I've posted.

(In reply to comment #37)
> Matej, are you running a 845G chipset, and without a xorg.conf file (f10 or
> rawhide)?  If that *does* work for you, perhaps you could post a Xorg.0.log
> with "-logverbose 255"?  It could be useful to compare a successful output to
> the one's I've posted.

Unfortunately, no I don't -- having 965GM.

Created attachment 330437 [details]
Semi successfull output from xdpyinfo, glxinfo, and Xorg.0.log

Some major success with today's rawhide (now it only hangs on glxgears and desktop startup):
kernel-2.6.29-0.64.rc3.fc11.i686
xorg-x11-server-Xorg-1.5.99.901-5.fc11.i386
xorg-x11-drv-i810-2.5.99.1-0.3.fc11.i386
xorg-x11-drv-synaptics-0.99.3-3.fc11.i386
libdrm-2.4.3-0.3.fc11.i386
mesa-libGL-7.3-0.4.fc11.i386
mesa-libGLU-7.3-0.4.fc11.i386
mesa-dri-drivers-7.3-0.4.fc11.i386

Without an xorg.conf file, running
  startx /usr/bin/xterm -- -logverbose 255 
in a console results in an xterm and a functional Xserver, with EXA acceleration.  "x11perf -repeat 2 -putimage100" runs at 1250/sec, not too much of a slow-down from the F9 rate of 1450/sec.

glxinfo succeeds in producing info, but running glxgears paints the outline of the window, then hangs the Xserver.  No keyboard response, no cpu activity.  The screen is still visible, but the mouse has disappeared and is unresponsive to clicks.  A reboot is the only way to recover the laptop keyboard.  The Xserver won't restart after a "kill -9" of the server (it doesn't respond to other signals).  I can still ssh into the laptop;  There are no additional messages in /var/log/messages or /var/log/Xorg.0.log.

I'm not able to bring up a gdm-gnome desktop.  After painting the gnome-panels, something causes the Xserver to hang, possibly using some of glitzy rendering methods that don't quite seem to work yet on this 845G hardware ...

I've attached copies of the output of xdpyinfo, glxinfo, and the Xorg.0.log from before the hang.

If this remains semi-functional throughout a few more updates, this specific bug could probably be closed, since the glxgears hang is possibly a different issue.

Created attachment 330806 [details]
Latest RAWHIDE Xorg.0.log, no config file, HANGING again

The behaviour has completely reverted.  Here's today's rawhide mix:
kernel-2.6.29-0.74.rc3.git3.fc11.i686
xorg-x11-server-Xorg-1.5.99.901-5.fc11.i386
xorg-x11-drv-i810-2.5.99.1-0.3.fc11.i386
xorg-x11-drv-synaptics-1.0.0-1.fc11.i386
libdrm-2.4.4-2.fc11.i386
mesa-libGL-7.3-0.4.fc11.i386
mesa-libGLU-7.3-0.4.fc11.i386
mesa-dri-drivers-7.3-0.4.fc11.i386

As described before black screen, keyboard locked.  Nothing apparently wrong when I ssh in.  "chvt" hangs trying to change to anything but 7 (where startx started the Xserver).

I've noticed that X.org has a xorg-x11-drv-i810 version 2.6.1 released:
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.1.tar.bz2
Any chance that's been packaged and is available to test?

can you try it with UXA acceleration ? (DRI2 takes effect only when UXA enabled)

(In reply to comment #40)
> Created an attachment (id=330806) [details]
> Latest RAWHIDE Xorg.0.log, no config file, HANGING again

Created attachment 331279 [details]
Xorg log with simple config specifing UXA acceleration (hangs)

Post F11 alpha rawhide versions:
kernel-2.6.29-0.93.rc3.git10.fc11.i586
xorg-x11-server-Xorg-1.5.99.902-3.fc11.i386
xorg-x11-drv-i810-2.5.99.1-0.3.fc11.i386
xorg-x11-drv-synaptics-1.0.0-2.fc11.i386
libdrm-2.4.4-4.fc11.i386
mesa-libGL-7.3-0.4.fc11.i386
mesa-libGLU-7.3-0.4.fc11.i386
mesa-dri-drivers-7.3-0.4.fc11.i386

Per comment #41, created a simple config using "Xorg -configure", renamed it to /root/uxa, and added this line to the Device section:
   Option "AccelMethod" "UXA"

Same observed hang as before .. but the following error lines show up in the attached log:
(EE) intel(0): Failed to set tiling on front buffer: Invalid argument
(EE) intel(0): Failed to set tiling on back buffer: Invalid argument
(EE) intel(0): Failed to set tiling on depth buffer: Invalid argument

Nothing unusual in /var/log/messages:
Feb  8 21:22:41 blu acpid: client connected from 2343[0:0]
Feb  8 21:22:41 blu acpid: 1 client rule loaded
Feb  8 21:22:42 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb  8 21:22:48 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Feb  8 21:22:48 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

Similar lines show up using EXA (see next attachment).

Note that the kernel is now i586, per the shift in Fedora kernel conventions.

Created attachment 331280 [details]
Latest RAWHIDE Xorg.0.log, no config file, still hangs

Same RPM's as comment #42.  Ran without a Xorg.conf file, and still hangs as described before.  Xorg will still run with NoAccel; The laptop still works well when booting to F9 with the earlier Xorg/intel drivers.

The log file is attached.  It might be useful to compare this to the log file in comment #41, which had UXA acceleration.

Same Xorg errors as UXA:
(EE) intel(0): Failed to set tiling on front buffer: Invalid argument
(EE) intel(0): Failed to set tiling on back buffer: Invalid argument
(EE) intel(0): Failed to set tiling on depth buffer: Invalid argument

No change in /var/log/messages output.

(In reply to comment #43)
> The log file is attached.  It might be useful to compare this to the log file
> in comment #41, which had UXA acceleration.
  Correction - the UXA log file is with comment #42

Created attachment 331797 [details]
Xorg.0.log for noconf, uxa, and noaccel.  Configs for uxa and noaccel

Still broken using latest rawhide updates, with new intel drivers and kernel:
kernel-2.6.29-0.110.rc4.git3.fc11.i586
xorg-x11-server-Xorg-1.5.99.902-9.fc11.i386
xorg-x11-drv-i810-2.6.0-3.fc11.i386
xorg-x11-drv-synaptics-1.0.0-4.fc11.i386
libdrm-2.4.4-4.fc11.i386
mesa-libGL-7.3-2.fc11.i386
mesa-libGLU-7.3-2.fc11.i386
mesa-dri-drivers-7.3-2.fc11.i386

Running without a config file:
  startx /usr/bin/xterm   -- -logverbose 255
From /var/log/messages:
Feb 12 08:23:40 blu acpid: client connected from 2315[0:0]
Feb 12 08:23:40 blu acpid: 1 client rule loaded
Feb 12 08:23:42 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb 12 08:23:42 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Feb 12 08:23:42 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

Keyboard hangs as before, backlight on, black screen.  ssh in, and chvt doesn't work either (hangs unless "chvt 7")

Running with UXA (xorg.conf_uxa)
  startx /usr/bin/xterm   -- -config /root/uxa -logverbose 255
Feb 12 20:32:05 blu acpid: client connected from 2338[0:0]
Feb 12 20:32:05 blu acpid: 1 client rule loaded
Feb 12 20:32:07 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb 12 20:32:07 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Feb 12 20:32:07 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0
Feb 12 20:32:07 blu kernel: [drm:i915_irq_emit] *ERROR* i915_irq_emit called without lock held, held  0 owner (null) dcdd9000

Keyboard hangs as before, backlight on, black screen.  ssh in, but chvt does not hang.  No apparent affect .. but it doesn't hang.  The  i915_irq_emit error is logged at X startup.

Running with noaccel (xorg.conf_noaccel)
  startx /usr/bin/xterm   -- -config /root/noaccel -logverbose 255
Feb 12 20:51:45 blu acpid: client connected from 2338[0:0]
Feb 12 20:51:45 blu acpid: 1 client rule loaded
Feb 12 20:51:54 blu ntpd[2098]: synchronized to LOCAL(0), stratum 10
Feb 12 20:51:54 blu ntpd[2098]: kernel time sync status change 0001
Feb 12 20:52:09 blu kernel: X[2338]: segfault at 10 ip 080d9160 sp bfd6d4c0 error 4 in Xorg[8047000+1b9000]
It works.  But doesn't exit cleanly.  The segfault message is logged when exiting the primary xterm with a ctrl-D (which causes X to exit).

I've put all at the configs and log output in the attached tarball:
tar tzf 20092012-Xorg_logs_and_configs.tar.gz
  xorg.conf_uxa
  xorg.conf_noaccel
  20092012-Xorg.0.log_noaccel_works
  20092012-Xorg.0.log_noconf_hang
  20092012-Xorg.0.log_uxa_accel_hang

Looks like intel/i810 is *still* broken for the 865G chip.

Created attachment 331956 [details]
Xorg.0.log for noconf and uxa. Config for uxa

Still broken using latest rawhide updates, with new intel drivers and kernel:
kernel-2.6.29-0.118.rc5.fc11.i586
xorg-x11-server-Xorg-1.5.99.902-10.fc11.i386
xorg-x11-drv-i810-2.6.0-5.fc11.i386
xorg-x11-drv-synaptics-1.0.0-4.fc11.i386
libdrm-2.4.4-4.fc11.i386
mesa-libGL-7.3-2.fc11.i386
mesa-libGLU-7.3-2.fc11.i386
mesa-dri-drivers-7.3-2.fc11.i386

Same symptoms with the no-configuration case.  Keyboard hangs, screen black (but backlight on), chvt hangs.  xdpyinfo -display :0  also hangs.  Here's the output from /var/log/messages:
Feb 14 21:27:19 blu acpid: client connected from 2749[0:0]
Feb 14 21:27:19 blu acpid: 1 client rule loaded
Feb 14 21:27:21 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb 14 21:27:21 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Feb 14 21:27:21 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0

It appears that the UXA acceleration option also doesn't work, but it might be closer to working.  The keyboard does not hang.  chvt works.  I can use ctrl-alt-F2 to change to a vt and blindly log in (verified that mingetty changes to bash using ps in a ssh session).  Despite changing vt's and back to vt7, the backlight remains off.  However "xdpyinfo -display :0" hangs when ssh'ing into the laptop.  Though the mouse is not visible, moving the mouse in the direction of the xterm and typing commands doesn't produce any results  (example: "ls > /tmp/x" doesn't create file /tmp/x).  /var/log/messages produces this error on Xorg server startup:
Feb 14 21:36:17 blu acpid: client connected from 2612[0:0]
Feb 14 21:36:17 blu acpid: 1 client rule loaded
Feb 14 21:36:19 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb 14 21:36:19 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Feb 14 21:36:19 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0
Feb 14 21:36:19 blu kernel: [drm:i915_irq_emit] *ERROR* i915_irq_emit called without lock held, held  0 owner (null) dce600f0

Created attachment 332843 [details]
Xorg.0.log for noconf, /var/log/messages, and corrupted glxgears.png

Partial success, but still broken.  Xserver comes up, displays xterm window.  The cursor is invisible.  I can use the touchpad to move it and click, but no cursor.  glxgears runs, but displays a very distorted image (snapshot in attached tarball).  There's a lot of output in /var/log/messages; Things like:
  i2c-adapter i2c-0: unable to read EDID block
  INFO: possible circular locking dependency detected
   ... with backtrace info

Relevant /var/log/messages output is also attached.  As well as the /var/log/Xorg.0.log output.

Current rpm's:
kernel-2.6.29-0.137.rc5.git4.fc11.i586
xorg-x11-server-Xorg-1.5.99.903-3.fc11.i586
xorg-x11-drv-i810-2.6.0-6.fc11.i586
xorg-x11-drv-synaptics-1.0.0-4.fc11.i386
libdrm-2.4.4-5.fc11.i586
mesa-libGL-7.3-2.fc11.i386
mesa-libGLU-7.3-2.fc11.i386
mesa-dri-drivers-7.3-2.fc11.i386

The Xserver was started with:
  startx /usr/bin/xterm -- -logverbose 255

2D performance test:
  x11perf -display :0 -repeat 2 -putimage100
   2400 trep @   4.7668 msec (   210.0/sec): PutImage 100x100 square
   (F9 is 1300/sec)

3D performance test (corrupted output):
  env DISPLAY=:0 glxgears
    413 frames in 5.0 seconds = 82.335 FPS
    (F9 is 257 FPS)

What little is running has severely degraded performance.

When the Xserver is terminated by exiting the xterm, Xserver exits, the screen goes black and doesn't return to a vt console.

Comment on attachment 332843 [details]
Xorg.0.log for noconf, /var/log/messages, and corrupted glxgears.png

wrong messages files

Created attachment 332844 [details]
Xorg.0.log for noconf, /var/log/messages, and corrupted glxgears.png

Correct attachment for Comment #47

Rawhide updated to i586 packages, and package xorg-x11-drv-intel replaced xorg-x11-drv-i810.  Still broken the same as Comment #47 (no cursor, bad glxgears image - attached, very slow 2D & 3D).  There appears to be more debug info.  The current configuration:

kernel-2.6.29-0.159.rc6.git3.fc11.i586
xorg-x11-server-Xorg-1.6.0-2.fc11.i586
package xorg-x11-drv-i810 is not installed
xorg-x11-drv-intel-2.6.0-9.fc11.i586
xorg-x11-drv-synaptics-1.0.99.2-1.fc11.i586
libdrm-2.4.5-0.fc11.i586
mesa-libGL-7.3-5.fc11.i586
mesa-libGLU-7.3-5.fc11.i586
mesa-dri-drivers-7.3-5.fc11.i586

/var/log/messages indicates "possible circular locking dependency detected"; output attached.

In /var/log/Xorg.0.log it detects 4Gig video ram on my old 512M laptop:
(II) intel(0): [DRI2] Setup complete
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 4194303 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
(II) UXA(0): Driver registered support for the following operations:
The log is attached.

F9 correctly shows:  (==) intel(0): VideoRam: 131072 KB

2D and 3D performance is still significantly regressed wrt F9:
                     F9         Rawhide
  2D putimage100    1300/sec    210.0/sec
  2D glxgears        257 fps     95.094 fps

On a postive note, when the Xserver ends it now terminates correctly and returns to a vt console.

Created attachment 333610 [details]
see Comment #50:  console output, showing drm debug messages

Created attachment 333611 [details]
see Comment #50: Xorg.0.log   using -logverbose 255

Created attachment 333612 [details]
see Comment #50: distorted glxgears snapshot

Created attachment 333613 [details]
see Comment #50: /var/log/messages with circular locking debug and backtrace

Created attachment 334470 [details]
Tarball of Xorg.0.log, messages, x11perf and glxgears output

Updated to latest Rawhide - still broken the same as Comment #47 (no cursor, bad
glxgears image (Comment #53), very slow 2D & 3D).  Though corrupt, glxgears is almost equivalent to F9 rates.  The current configuration:

kernel-2.6.29-0.207.rc7.fc11.i586
xorg-x11-server-Xorg-1.6.0-9.fc11.i586
package xorg-x11-drv-i810 is not installed
xorg-x11-drv-synaptics-1.0.99.4-1.fc11.i586
libdrm-2.4.5-0.fc11.i586
mesa-libGL-7.3-10.fc11.i586
mesa-libGLU-7.3-10.fc11.i586
mesa-dri-drivers-7.3-10.fc11.i586

/var/log/messages still indicates "possible circular locking dependency detected"; output attached.

In /var/log/Xorg.0.log it still detects 4Gig video ram on my old 512M laptop:
(II) intel(0): [DRI2] Setup complete
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 4194303 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
(II) UXA(0): Driver registered support for the following operations:
The latest log is attached.

F9 correctly shows:  (==) intel(0): VideoRam: 131072 KB

3D performance (though corrupted) has increased to approach F9 rates.
2D performance is still significantly regressed wrt F9:
                     F9         Rawhide
  2D putimage100    1300/sec    232/sec
  3D glxgears        257 fps    212 fps

The Xserver still exits correctly (doesn't crash/hang on exit).

I've attached a tarball of Xorg.0.log, part of /var/log/messages, and the x11perf and glxgears output.

TEST DAY SUMMARY

I ran the tests outlined in
  https://fedoraproject.org/wiki/QA/Test_Days/2009-03-12
and it confirmed the earlier failures, but had a single significant success;  Adding "nomodeset" to the boot command line resulted in a running Xserver with mouse cursor, and 2D + 3D performance commensurate with F9 speeds.  glxgears was undistorted.  Desktop effects locked up ... but otherwise it seemed usable.

When running without "nomodeset" (using KMS) as in all the stuff previously documented in this bug, it appears the reported amount of video ram is wrong.

I'll add a comment for each test result, so the bugs can link to the specific test.

Created attachment 335189 [details]
/var/log/messages (including boot up, Xserver, GDM) w/ cirular locking error

FAIL - QA:Testcase intelvideo kms
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_kms

  Boots, no flicker, almost everything works
  EXCEPT:
    No mouse cursor.  It detects motion, but the cursor is invisible.
    I can guess where the cursor is and click in windows.
    The backlight often doesn't turn on. It's on at boot, but when
    it should go to full-screen, native resolution for the plymouth
    display the screen goes completely black.

    Laptop continues to boot, but the screen is blank.
    Keyboard is active.  I can ssh in and reboot.

    When the backlight is on, there's a pretty plymouth boot,
    good picture.  Continues to gdm login.  Login screen has no
    mouse cursor.  I can move an invisible mouse with the touchpad
    and click, but no visible cursor feedback.

    Sound and desktop look good, but still no cursor.

    There's a dump in /var/log/messages about 
     INFO: possible circular locking dependency detected
     Attached /var/log/messages
     Atttached /var/log/Xorg.0.log

    Performance (poor):
    2D: x11perf -putimage100   224.0/sec
    3D  glxgears corrupted,    205 fps

glxgears is corrupted as in Comment #53

Created attachment 335190 [details]
/var/log/Xorg.0.log for plain kms Xserver

FAIL - QA:Testcase intelvideo kms
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_kms
   attachment for Comment #57

Mostly PASS - QA:Testcase intelvideo noKMS
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_nokms

With the exception of the "circular locking error" message in /var/log/messages, this seemed pretty functional, recovering performance on a par with F9:

    Performance:
    2D: x11perf -putimage100   224.0/sec
    3D  glxgears corrupted,    205 fps

Still had backlight issues, but I could vt switch (ctl-alt-Fn) a few times and the backlight would come on and the Xserver would be visible.  This didn't seem to "fix" the KMS case (since the text screens were also rendered?).

(In reply to comment #59)
>     Performance:
>     2D: x11perf -putimage100   224.0/sec
>     3D  glxgears corrupted,    205 fps

Wrong performance numbers - the noKMS case was:
    Performance:
    2D: x11perf -putimage100   1430.0/sec
    3D  glxgears clean!!!       174 fps

glxgears looked good.

FAIL - QA:Testcase intelvideo dpms
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_dpms

The display never went to sleep.  The screensaver remained on.  Booting with "nomodeset" and DPMS worked.

FAIL - QA:Testcase intelvideo glx
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_glx

A little hard to do without a cursor, but moving the invisible mouse to the top panel bar, clicking, and using arrow keys, I managed to navigate to the "Desktop Effects" preferences.  The Xserver locked up right after clicking "Enable Desktop Effects".  The screen and keyboard froze (Capslock indicator no longer worked).

This was also true with "nomodeset" on the boot line.

FAIL (or N/A) - QA:Testcase intelvideo xv
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_xv

The gstreamer-properties dialog Video pane only offered
     Default Output / Plugin
        Autodetect, v4l, v4l2, or Custom.
        (no xv option available)

This was also true for "nomodeset".  Is xv not implemented for the 845G ?

PASS - QA:Testcase intelvideo fastuserswitch
https://fedoraproject.org/wiki/QA:Testcase_intelvideo_fastuserswitch

To the extent that other features worked, this passed.  Two users could log in at once and switch back and forth.  With KMS, there was no cursor and glxgears remained corrupted .. but no worse than before.

I have also the i845 video chipset and with the LiveCD provided at http://fedoraproject.org/wiki/QA/Test_Days/2009-03-12 I have the same behaviour as
Bob Arendt at comment #57

Adding "nomodeset" to the boot command line resulted in a running Xserver with
mouse cursor.

I reported the problem also on BZ 484291

To complete the previous comment I like to add that using the "nomodeset" boot parameter I get a running X server - I can login at the gdm screen - but I get an error : "Error activating XKB configuration". 

If I close that error window everithing looks normal, I have mose cursor, the menus are working. The graphical performance is slower then on Fedora8 that I currently using:

glxgears ~225fps (vs. ~442fps on Fedora8)
x11perf putimage100 ~3600/sec (vs. ~5500/sec on Fedora8)

I cannot activate Desktop Effects - when I tried I get a frozen machine.

This rawhide liveCD is a step forward but I hope it will be solved
before F11 goes out the door. I also have this problem since Fedora10 after Fedora8 and Fedora9 working fine with my computer (Fujitsu-Siemens ScenicS2 - i845 video on board).

(In reply to comment #66)
> To complete the previous comment I like to add that using the "nomodeset" boot
> parameter I get a running X server - I can login at the gdm screen - but I get
> an error : "Error activating XKB configuration". 
>
I'd seen this also, and "fixed" it by deleting my home directory and letting gnome build fresh config files, so it appears to be a gnome bug rather than an Xorg bug.  It's probably Bug #180861.  gconf is probably loading some bad keyboard config info, misconfiguring X, then a gnome applet complains.  You might try pulling up a keyboard-preferences config tool and changing the keyboard to something, then back to what you want.  If it's misconfigured, this might overwrite it with a good config.
 
Thanks for the additional confirmation and timing comparison numbers.

Created attachment 337373 [details]
Xorg.0.log with Fedora11 Beta LiveCD on i845 video

The Fedora11 Beta Live CD does not work as expected on my hardware (Fujitsu-Siemens ScenicS2 with i845 integrated video ): boots, almost everything works exept no mouse cursor.  It detects motion, but the cursor is invisible.I can guess where the cursor is and click in windows.This is the same behaviour as with the 2009-03-12 intel Test Days Live CD.
I attached the Xorg.0.log for this case.

Adding "nomodeset" to the boot command line resulted in a running Xserver with
mouse cursor.

Created attachment 337374 [details]
Xorg.0.log with Fedora11 Beta LiveCD on i845 video with "nomodeset" boot parameter

Attached the Xorg.0.log when I started the Fedora11 Beta LiveCD with
"nomodeset" boot parameter - running Xserver with mouse cursor on the same i845
video hardware!

Attached the Xorg.0.log when I started the Fedora11 Beta LiveCD with
"nomodeset" boot parameter - running Xserver with mouse cursor on the same i845
video hardware!
>
>

I have the same problem with the "invisible" mouse cursor on my machine with i845
video also.

Booting the live cd with the "nomodeset" boot parameter makes the cursor visible 
on my machine also.

This appears to be resolved for me (G45/X4500HD) with the latest Intel driver and updates from rawhide:

kernel-2.6.29.1-52.fc11.x86_64
libdrm-2.4.5-4.fc11.i586
libdrm-2.4.5-4.fc11.x86_64
mesa-dri-drivers-7.5-0.7.fc11.i586
mesa-dri-drivers-7.5-0.7.fc11.x86_64
mesa-libGL-7.5-0.7.fc11.i586
mesa-libGL-7.5-0.7.fc11.x86_64
mesa-libGLU-7.5-0.7.fc11.i586
mesa-libGLU-7.5-0.7.fc11.x86_64
xorg-x11-drv-intel-2.6.99.902-2.fc11.x86_64

No xorg.conf and kernel modeset enabled.  Compiz still has window update issues, but otherwise everything looks stable.

This report seems to have got very messy.

First, can we ignore the 'no cursor on i8xx' thing? That's not what was initially reported, doesn't appear to be related, and has its own report (488980).

Bob, aside from the cursor issue, what's the status with current Rawhide, no xorg.conf, and kms enabled? What are the remaining issues in this configuration?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

While I had reported in comment #71 that I no longer get the lockups, of course I got one a couple of days later.  I'm still tracking rawhide, and waiting to see if I can go a week without a lockup in KMS+UXM mode.

For me, the problem is partly the level of churn in rawhide.  Should I update the kernel and Xorg or go for a stability test (I'm tracking about four dozen bugs in various packages)?  I usually update, and that resets the clock.  If I get a re-occurrence, I update and that resets the clock.

It would be nice if some package levels were identified with "we believe this issue is resolved at these levels", but I understand that's not realistic.

Mace: you have a completely different issue from Bob, on completely different hardware, so your comments are not relevant to this report in any case. Please file a separate report.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #72)
> This report seems to have got very messy.
> 
> First, can we ignore the 'no cursor on i8xx' thing? That's not what was
> initially reported, doesn't appear to be related, and has its own report
> (488980).
> 
> Bob, aside from the cursor issue, what's the status with current Rawhide, no
> xorg.conf, and kms enabled? What are the remaining issues in this
> configuration?
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers  

How the hell is this *NOT RELATED?!?* 

It's a spin-off/offshoot of the various problems people have encountered with the i845 Intel video driver which quite frankly has never fuctioned properly from the very first release of the Fedora 10 live cd.

Basically you can't ignore this, because it's *DIRECTLY RELATED TO THE INTEL VIDEO DRIVER*, and shoving it into another little subtopic like you seem to want to *WON"T* make the problems with the i8xx/i845 driver go away.


Do you even understand just what the problems with the i8xx driver being mentioned here even *ARE*?

Sure as hell doesn't seem like it.

Kivar: it's not related because it's a completely different bug. There are several bugs with the older i8xx chipsets with the current intel driver, yes. The best way for them to be fixed is for each problem to have its own distinct report, otherwise everything gets incredibly messy and it's very difficult to tell what's the status of each problem. The missing cursor issue is a distinct issue which is not at all the issue that was initially reported in this bug, and is very unlikely to be caused by the same problem in the code, so there's no sense in discussing it in this bug; it's just noise in this report.

The sensible thing is to have a separate report for that bug, which we do. That's not 'ignoring' it or 'shoving it into another little subtopic', it's just the right way to organize things in Bugzilla.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

clarification: I used the word ignore, yes - I meant to ignore it *in this bug report*, not ignore it generally speaking.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #76)
> Kivar: it's not related because it's a completely different bug. There are
> several bugs with the older i8xx chipsets with the current intel driver, yes.
> The best way for them to be fixed is for each problem to have its own distinct
> report, otherwise everything gets incredibly messy and it's very difficult to
> tell what's the status of each problem. The missing cursor issue is a distinct
> issue which is not at all the issue that was initially reported in this bug,
> and is very unlikely to be caused by the same problem in the code, so there's
> no sense in discussing it in this bug; it's just noise in this report.
> 
> The sensible thing is to have a separate report for that bug, which we do.
> That's not 'ignoring' it or 'shoving it into another little subtopic', it's
> just the right way to organize things in Bugzilla.
> 
> -- 
> Fedora Bugzappers volunteer triage team
> https://fedoraproject.org/wiki/BugZappers  

It's *NOT* a completely different bug or problem. It's pretty much in fact the *SAME* bug(s),but you're seeing different aspects of it with different setups.

Running around creating a bunch of seperate silly subtopic "BUG" reports for a single subject is idiotic and a waste of time and effort.

Why on earth do something as silly as create 101 different subtopics dealing with the problems with the i8xx/i845 drivers when creating just (1) topic
where people can talk about and compare notes about the problems they are running into and seeing with the driver would be so much easier and make more sense.

Bugzilla's not meant to be a forum so this will be my final post on this topic, but it's really very simple. The reason is *they're not the same bug*. I don't see why you don't get this. Just because two problems happen with the same hardware, does not mean they're the same bug. I don't understand why you think "X hangs on startup" is the same as "the cursor's missing if modesetting is enabled". They're utterly and completely different problems.

What I'm expecting to hear from Bob is that the initial issues are mostly resolved and what he has now is a grab-bag of smaller issues: the missing cursor, backlight issue. At which point we will close this bug and follow the others in separate reports.

It doesn't make sense to have one big report for 'every problem anyone ever has with an i8xx chipset', because it's horribly confusing for triagers, maintainers and even reporters (do you really enjoy having to look through 75 comments in this report every time you want to see if someone else has the same problem as you?)

One bug per report is the only sane way to work. You report the bug, I triage it, the maintainer changes some code to try and fix it, you tell us if it's fixed, we close it. That works. Having seven different bugs in the same report just doesn't work. What do we do when three of them are fixed and four aren't? How the heck am I supposed to keep track of that while I'm trying to see if the driver's in good enough shape for us to release Fedora 11? Do I mark it as CLOSED or OPEN? Come on, surely you can see the problem here?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #72) 
> First, can we ignore the 'no cursor on i8xx' thing? That's not what was
> initially reported, doesn't appear to be related, and has its own report
> (488980).
> 
> Bob, aside from the cursor issue, what's the status with current Rawhide, no
> xorg.conf, and kms enabled? What are the remaining issues in this
> configuration?
> 

Adam,

I agree the "no cursor" can go to a separate bug.  This bug has evolved, and I don't mind splitting it into different issues against the intel/i845G hardware. For hardware-specific issues, it would be nice to be able to pull bugs by chipset.  Certainly filing xorg / mesa bugs by chipset would make it easier to find and report against existing bugs.  My travel laptop's intel GM45 chipset clearly doesn't have any of the issues my other 845G laptop has (but using the *same* rawhide intel driver).  By having the video chip (as reported in Xorg.0.log) it could reduce duplicate or confusing reports, and make easier to track individual bugs (missing cursor, etc) specifically against driver + chipset.

Feel free to rename this bug or split it into discrete bugs with more appropriate titles with intel 845G + intel driver in the title.

My last test (comment #57 .. comment #64) with a "naked" config (no xorg.conf, no "nomodeset") still had corrupted glxgears.  Desktop effects, xv, and DPMS also failed.  There were no significant package updates before my business trip.  I'm still out of town, and it will at least 10 days before I'll get a chance to update and re-test with that laptop.  I'll certainly update and report when I return to the states.

Cheers,
-Bob Arendt

glxgears is likely https://bugzilla.redhat.com/show_bug.cgi?id=490366 and/or https://bugzilla.redhat.com/show_bug.cgi?id=489988 . For DPMS, please try with this procedure instead:

https://fedoraproject.org/wiki/QA:Testcase_radeon_dpms

because there's actually a bug in the GNOME display properties applet which caused the test case from the Intel test day to fail, that's a simpler test case which avoids that problem.

For xv, from your comment, you were looking at the wrong box: that's the *input* plugin (hence why it offers v4l, the video capture framework), not the *output* plugin. You want the box under "Default Output", not the box under "Default Input". Please check again :)

For desktop effects, please file a new bug - that'd be better than changing this bug and having all this history attached to it. Thanks!

I'm closing this report now. Thanks for your continued input. Please do add a comment with the bug # when you file new reports on the issues discussed here :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** Bug 470672 has been marked as a duplicate of this bug. ***