You have an 865, not an 845...and also, other reporters in that bug don't seem to be experiencing the same hangs. Thanks for the report, though.

I also have some problems with i845 KMS solution on BZ488980. I do not experience the above problems, but ocasionally at boot time the system hangs when the mouse cursor first appears on screen.

I also have problems with Firefox - when I place the mouse cursor in navigation bar I get some grey 1 pixel lines. These lines I noticed in web pages where the caracters where distorted by some dashed 1 pixel lines. This behaviour appears also in the terminal window. 

If I boot the same kernel-2.6.29.3-155.fc11.i586 with the nomodeset boot parameter I do not have any of the above stated problems.

So the kernel-2.6.29.3-155.fc11.i586 is a big step in the right dirrection but maybe needs a bit of attention!

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

>when I place the mouse cursor in navigation
>bar I get some grey 1 pixel lines.

I see this too (also Intel 82845G/GL). I think it's a separate bug, so I opened bug 502096.

Created attachment 345028 [details]
another Xorg.0.log

I'm also seeing hangs with kernel-PAE-2.6.29.3-155.fc11.i686 and an 82865G:
  00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

My Xorg.0.log is attached.  I was able to login and start Xfce, and then I opened a terminal window, and it hung before the bash prompt appeared.  The mouse cursor still moves, though, and I can login remotely.

Nothing particularly interesting in dmesg output:
$ dmesg | tail
Bridge firewalling registered
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
[drm] DAC-5: set mode 1024x768 f
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0 NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
fuse init (API version 7.11)
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts

Created attachment 345029 [details]
sysprof-1.0.12 output

I assume that the sysprof mentioned in bug 488980 comment 39 is this?
  http://www.daimi.au.dk/~sandmann/sysprof/

If so, I ran it and here are the results.  It gathered 27 samples over a couple of minutes.  I tried moving the mouse and hitting some keys on the hung console while it was gathering samples, but that didn't seem to affect the number of samples it gathered.

This issue was discussed at the QA/RelEng blocker review meeting, in co-ordination with the X developers. It was agreed that we will likely disable kernel modesetting by default for this chipset for F11 release, as a workaround rather than a fix. The bug will remain open as we must eventually ensure the chip works well with kernel modesetting, but will be downgraded from blocker status, once a build with kernel modesetting disabled is pushed.

I'm also seeing this problem on a system that has 865G:

http://www.smolts.org/client/show/pub_45e71f52-1171-43c0-9c36-aacc87834e13

I can attach an Xorg log if requested, but it I see you already got one.

Even if it is downgraded, does that mean that KMS might be reawakened on the chip after F11 release once this is fixed?

yes, that would be the reason to keep it open. we must fix the KMS case in the end, because we want to kill all the modesetting code from the driver in the long run, and rely on kernel modesetting exclusively. so obviously all KMS bugs have to be fixed. disabling kms by default for F11 GA is just a short-term workaround.

Please try the scratch build here

 http://koji.fedoraproject.org/koji/taskinfo?taskID=1377794

do not add any "i915.modeset" or "nomodeset" lines and try it, it should disable modesetting on its own on your chipset.

Please test ASAP, guys - we're on a very tight wire for final release. thanks a lot for your help :)

I've had feedback from one person, so far, that it works as intended - it behaves just like booting a regular kernel with 'nomodeset'.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1378653

new build with a better patch, please test this one instead.

The build from comment 12 works for me: it boots in text mode with no kernel parameters.

$ uname -r
2.6.29.4-163.i8xx_nokms.fc11.i686.PAE
$ cat /proc/cmdline
ro root=/dev/mapper/VolGroup-lv_root rhgb quiet

there's one other obvious test - boot it on a post i8xx system and make sure modesetting is still used :) can anyone do that? I don't have an intel adapter in any of my systems any more.

Kristian apparently expressed the view that he thinks this is similar to or the same as #498131 . I don't see how that could be the case, as it seems people are encountering this problem with the packages that fixed 498131, but I thought it worth mentioning here.

can anyone confirm for sure that they experience this problem with the package set which was reported to fix 498131:

kernel-2.6.29.3-155.fc11
libdrm-2.4.6-7.fc11
xorg-x11-drv-intel-2.7.0-6.fc11

or later?

https://koji.fedoraproject.org/koji/taskinfo?taskID=1379720

while we're at it, please test this, it may or may not work with full kms/gem on i855/865/845. Please try it with no "nomodeset" passed. X should, in theory, work.

This needs to be done asap, as we're down to the wire and will otherwise have to disable it by default.

AdamW, I have tested it on 965 and 945... where's the trust?

kristian reports that his i865 does not suffer from this issue. That gives us three people seeing hangs on systems with an i865, and one not.

I tried the latest kernel from comment 17 (2.6.29.4-163.i8xx.fc11.i686.PAE) with and without 'nomodeset' and it seems okay both ways.  I didn't see any hanging even with KMS enabled.  I didn't test for very long (just a few minutes), but previously it would hang within ~10 seconds of logging in.  I was able to login, start Firefox, go to a handful of sites, do some file management, and logout with no hangs and KMS enabled.

Thanks for the feedback, Jeff.

(In reply to comment #19)
> kristian reports that his i865 does not suffer from this issue. That gives us
> three people seeing hangs on systems with an i865, and one not.

I bet he did not try hard enough ;)
(/me actually seeing it on two different pieces of i865 hardware)

(In reply to comment #17)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=1379720
> 
> while we're at it, please test this, it may or may not work with full kms/gem
> on i855/865/845. Please try it with no "nomodeset" passed. X should, in theory,
> work.
> 
> This needs to be done asap, as we're down to the wire and will otherwise have
> to disable it by default.  

Works like a charm. No hang even after a couple of minutes of aggressively switching desktops with lots of windows which previously lead to a crash in a couple of seconds. Even subjectively feels a bit snappier than without modesetting. Thanks a lot!

(In reply to comment #22)
> Works like a charm.

Even compiz works beautifully and I could play some supertux. Yay \o/

The final kernel that we will compose with is now being built:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1380684

please test that, once it's ready, and confirm that the issue is resolved. thanks a lot!

grr. correction: http://koji.fedoraproject.org/koji/taskinfo?taskID=1380686

Re-confirming that the latest kernel, comment 25, still works for me, and I have KMS enabled.

$ uname -r
2.6.29.4-167.fc11.i686.PAE
$ cat /proc/cmdline
ro root=/dev/mapper/VolGroup-lv_root rhgb quiet

Thanks a lot guys, based on comment 23 and comment 26 let's claim that it has been closed. If anybody is of different opinion, please, reopen the bug with additional information.

Latest packages are working much better for me as well. I also have KMS enabled:

kernel-PAE-2.6.29.4-167.fc11.i686
libdrm-2.4.6-7.fc11.i586
xorg-x11-drv-intel-2.7.0-6.fc11.i586

...only one X lockup so far, but at the time I was trying to reenable compiz (and did something a little weird with it). So I can't really attribute that to the same problem.

correct resolution...matej, read the workflow ;)

Oh God, I've wasted the whole week playing with wobbly windows, thank you so much mister McMartin.