I have had this happen once to me as well. Here's my backtrace:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x3c) [0x80e587c]
1: /usr/bin/Xorg (mieqEnqueue+0x1b7) [0x80e51a7]
2: /usr/bin/Xorg (xf86PostMotionEventP+0xd4) [0x80bf8a4]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0xac4000+0x3172) [0xac7172]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0xac4000+0x3466) [0xac7466]
5: /usr/bin/Xorg (0x8048000+0x6a1f0) [0x80b21f0]
6: /usr/bin/Xorg (0x8048000+0x11dd24) [0x8165d24]
7: (vdso) (__kernel_sigreturn+0x0) [0x6fb400]
8: (vdso) (__kernel_vsyscall+0x10) [0x6fb424]
9: /lib/libc.so.6 (0x776000+0xe9b83) [0x85fb83]
10: /lib/libc.so.6 (0x776000+0x740d4) [0x7ea0d4]
11: /lib/libc.so.6 (0x776000+0x70787) [0x7e6787]
12: /usr/bin/Xorg (Xfree+0x22) [0x80a7452]
13: /usr/bin/Xorg (0x8048000+0x61b2a) [0x80a9b2a]
14: /usr/bin/Xorg (0x8048000+0x61bb2) [0x80a9bb2]
15: /usr/bin/Xorg (CloseWellKnownConnections+0x34) [0x80a3bf4]
16: /usr/bin/Xorg (0x8048000+0x65ce8) [0x80adce8]
17: /usr/bin/Xorg (0x8048000+0x6634e) [0x80ae34e]
18: /usr/bin/Xorg (0x8048000+0x5ebc0) [0x80a6bc0]
19: (vdso) (__kernel_rt_sigreturn+0x0) [0x6fb40c]
20: /lib/libc.so.6 (0x776000+0x70ebd) [0x7e6ebd]
21: /lib/libc.so.6 (__libc_malloc+0x5e) [0x7e81fe]
22: /usr/bin/Xorg (Xalloc+0x2a) [0x80a770a]
23: /usr/bin/Xorg (Xcalloc+0x26) [0x80a7a76]
24: /usr/bin/Xorg (0x8048000+0x111252) [0x8159252]
25: /usr/bin/Xorg (0x8048000+0x11314b) [0x815b14b]
26: /usr/bin/Xorg (0x8048000+0xf4801) [0x813c801]
27: /usr/bin/Xorg (0x8048000+0xf5430) [0x813d430]
28: /usr/bin/Xorg (0x8048000+0x261f7) [0x806e1f7]
29: /usr/bin/Xorg (0x8048000+0x1a8c5) [0x80628c5]
30: /lib/libc.so.6 (__libc_start_main+0xe6) [0x78cbb6]
31: /usr/bin/Xorg (0x8048000+0x1a4b1) [0x80624b1]

This is not a bug in evdev. The X server got stuck waiting on the Radeon chip to respond. Reassigning to xorg-x11-drv-ati.
Please provide more log files as recommended in http://fedoraproject.org/wiki/Xorg/Debugging .

Created attachment 373957 [details]
the Xorg.0.log file

Here is a complete Xorg.0.log. This isn't the one from the crash, but when I
had that log, it looked identical to the current log with just the walkback
stuck on the end.

I'm sort of curious why it didn't pick the radeonhd driver. Is that not yet
being automagically selected for any radeon cards?

Perhaps if the crash happens again, I'll create an xorg.conf (I do not have
one currently) and try to force it to use radeonhd.

Created attachment 373958 [details]
/var/log/dmesg file

This is also the current dmesg file, not the one from the crash, but I
didn't see anything unusual in dmesg when I looked right after the crash.

(In reply to comment #3)
> I'm sort of curious why it didn't pick the radeonhd driver. Is that not yet
> being automagically selected for any radeon cards?

The Fedora preferred driver is radeon (developed by Dave Airlie, Alex Deucher, ...), not radeonhd.

OK, I thought the world was splitting into pre-and post HD drivers. I guess
this is one of those "I tried to get out, but the pulled me back in cases" :-).

Facing the issue from the very early days of F12 and have logged as https://bugzilla.redhat.com/show_bug.cgi?id=539494.

Probably a Xorg issue

Created attachment 375070 [details]
Another example Xorg.0.log crash

About an hour after I rebooted following updates, I got another identical
crash of X. My current versions of various rpms are:

xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.x86_64
xorg-x11-drv-evdev-2.3.1-2.fc12.x86_64
xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64
libdrm-2.4.15-4.fc12.x86_64
kernel-2.6.31.6-145.fc12.x86_64

The attached Xorg log is from the crash (with the new walkback at the end).

Having the same problem (EQ overflowing error in Xorg.0.log) with Radeon HD3470.

During F12 Rawhide, there was a similar, radeon related bug (https://bugzilla.redhat.com/show_bug.cgi?id=528593), which was eventually squashed through some kernel patch. As there are many similar reports on a lot of different hardware, maybe there is something broken in a recent generic DRM patch on the kernel?

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

Most likely duplicate of bug 545834, isn't it?

I have the same problem like initial description. Attaching all my logs.
The problem arises here only when external monitor is connected.
I have no xorg.conf, KMS is not disabled.
Notebook Acer Extensa 5620, ATI Technologies Inc Radeon HD 2400 XT.

Created attachment 377440 [details]
My smolt profile

My backtrace log from Xorg.0.log is exactly the same as in original report.

Just as a (probably useless) data point: I've been using virt-manager and
virt-viewer a lot today, and I've had this same video crash 3 or 4 times
already (usually is is about a week between crashes). I don't know if
there is anything special virt-viewer does to the poor old video driver,
but it sure seems to increase the incidence of crashes.

Since running virt-manager and virt-viewer caused my system to crash so
often, I took the opportunity to try creating an xorg.conf file with
just enough info to specify radeon driver options. None of them
made the crashes stop :-(.

I tried turning off all acceleration via "NoAccel" - X server wouldn't
start at all.

I tried "AccelMethod" "XAA" - still crashed.

I tried "RenderAccel" "off" - still crashed.

I tried "DRI" "off" - still crashed.

Whatever is causing this seems to be very persistent. (I don't suppose
ATI has their catalyst drivers working under 2.6.31 yet :-).

Just for the record: I am getting the same hard lockups using the proprietary Nvidia driver, but the above traceback appears to show that it's not inside that driver when it locks up. It's probably not the ATI driver causing this either.

I too use the virt-manager/KVM so I will try to keep track of whether the crashes occur when I'm using that.

Tom,
when looking for a workaround, your should try the 'nomodeset' kernel parameter first. See here:
https://fedoraproject.org/wiki/Bugs/Common#Miscellaneous_problems_with_ATI_.2F_AMD_graphics_adapters

I do use nomodeset and I still get the lockups about every couple of days.

Greg,
your backtrace is quite different from Tom's (the only seeming similarity being the top part of it with the processing of a motion event - which is unfortunately typical for X server lockups of various causes) and you have very different hardware (nvidia).
There's a very high probability that you are seeing a different issue. If you can reproduce it with the Free driver "nouveau" too, it would be worth reporting as a new bug.
Thanks.

Created attachment 379274 [details]
pstack ouput of hung Xorg process

I tried nomodeset for a day, and didn't crash (but that's not really long
enough to say for sure it prevents the crashes). Instead of crashing, I
get bad graphics when I use nomodeset:

Bug 506552 is back (funny blocks instead of blinking line cursor in Qt).

Scrolling doesn't work very well, the line where I started the scroll
gets sort of chopped in half so only the top or bottom of the characters
appear.

I also tried radeonhd together with nomodeset and radeonhd is even worse
with things like windows not completely disappearing when I iconify them :-).

So I'm back to my original default configuration now which seems to work
best (except when it crashes :-).

Just a philosophical question here: I know everyone is a perfectionist and
wants everything to work "right", but since this is an error the X server
noticed (hence the backtrace), isn't it possible that the server could
respond in some more useful way to errors like this? Maybe re-initialize
the video card, and refresh all the windows to see if it starts from scratch
if it can get back to a sane condition? (If that makes the error happen
again, and we loop doing this, it wouldn't really be any worse than the
current frozen state anyway, so you wouldn't even have to worry about
detecting that :-). If it wants to package up all the info about the
error for the "abrt" tool to send off somewhere so the errors don't become
invisible due to being hacked around like this, it could do that too.

I am having a similar issue here.

Symptoms:

Xorg freezes when trying to display the login screen. It freezes at different points: sometimes when the screen is black and the mouse pointer has that spinning thingy, or just after that spinning thingy disappears, or, less often, when the login window (the one with user names) is partially drawn. When it freezes I can move the mouse and the mouse pointer on the screen follows for a while and then stops responding, at which point I have to reboot my machine.

My hardware, however, is different: NVidia Quadro NVS 440 (2 GPUs, 3 screens attached out of maximum 4). My backtrace, on the other hand, looks somewhat similar (may be because I stared at it for too long):

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49e8d8]
1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e2a4]
2: /usr/bin/Xorg (xf86PostMotionEventP+0xce) [0x478f0e]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fe851913000+0x50bf) [0x7fe8519180bf]
4: /usr/bin/Xorg (0x400000+0x6be17) [0x46be17]
5: /usr/bin/Xorg (0x400000+0x116b13) [0x516b13]
6: /lib64/libpthread.so.0 (0x3fbac00000+0xefa0) [0x3fbac0efa0]
7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x5d722) [0x7fe85314c722]
8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x5debd) [0x7fe85314cebd]
9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0xabb36) [0x7fe85319ab36]
10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x34ee56) [0x7fe85343de56]
11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x34ef82) [0x7fe85343df82]
12: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x34f53f) [0x7fe85343e53f]
13: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fe8530ef000+0x31e588) [0x7fe85340d588]
14: /usr/bin/Xorg (0x400000+0x737d8) [0x4737d8]
15: /usr/bin/Xorg (0x400000+0x160bc4) [0x560bc4]
16: /usr/bin/Xorg (BlockHandler+0x50) [0x431830]
17: /usr/bin/Xorg (WaitForSomething+0x141) [0x45bd01]
18: /usr/bin/Xorg (0x400000+0x2c3b2) [0x42c3b2]
19: /usr/bin/Xorg (0x400000+0x21cfa) [0x421cfa]
20: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3fba41eb1d]
21: /usr/bin/Xorg (0x400000+0x218a9) [0x4218a9]

In there you can spot that I am using NVidia proprietary driver. This is because nouveau driver, as I understand, can not cold start the secondary GPU on my graphic card, so that I can only possibly use two screens with nouveau driver. I have no other option but to use the proprietary driver in order to be able to use the three screens.

The interesting point is that when I only have two screens specified in my server layout there seem to be no issues (two days of fiddling with xorg.conf). It is only when I enable the third screen starting Xorg/GDM freezes. Just before it freezes (5-10 secs), I am able to move the mouse across all the three screens as I should. It might suggest that the NVidia proprietary driver has started and was able to initialize the hardware all right. And given the fact that the same binary blob (nvidia.ko) is used across different platforms (Solaris, BSD, Linux), I am suspecting Xorg to be a more likely root of the issue.

Just for the record, it all worked just fine with Fedora 10 and the NVidia proprietary driver, I was able to use all my three screens driven by the two GPUs on one board.

I am not sure if my issue is related, although the similarity in the backtrace looks suspicious.

Packages involved:
[max@forwin012 ~]$ rpm -qa | egrep "x11-[^d]|nvidia"
xorg-x11-xfs-1.0.5-6.fc12.x86_64
xorg-x11-server-Xorg-1.7.1-12.fc12.x86_64
kmod-nvidia-2.6.31.9-174.fc12.x86_64-190.42-1.fc12.9.x86_64
xorg-x11-utils-7.4-7.fc12.x86_64
xorg-x11-proto-devel-7.4-34.fc12.noarch
xorg-x11-drv-nvidia-libs-190.42-5.fc12.x86_64
xorg-x11-server-common-1.7.1-12.fc12.x86_64
xorg-x11-xauth-1.0.2-7.fc12.x86_64
xorg-x11-drv-nvidia-190.42-5.fc12.x86_64
ConsoleKit-x11-0.4.1-1.fc12.x86_64
xorg-x11-font-utils-7.2-10.fc12.x86_64
xorg-x11-xtrans-devel-1.2.2-4.fc12.noarch
dbus-x11-1.2.16-8.fc12.x86_64
xorg-x11-xinit-1.0.9-13.fc12.x86_64
nvidia-xconfig-1.0-1.fc12.x86_64
pulseaudio-module-x11-0.9.21-1.fc12.x86_64
kmod-nvidia-190.42-1.fc12.9.x86_64
xorg-x11-server-utils-7.4-13.fc12.x86_64
nvidia-settings-1.0-3.2.fc12.x86_64
xorg-x11-xkb-utils-7.4-6.fc12.x86_64

I tried versions 1.7.1-7(updates), 1.7.1-9(koji), 1.7.1-12(updates-testing) of xorg-x11-server-Xorg and xorg-x11-server-common, same issue.

Please let me know if it looks to be the same issue or if I should open a new bug. Can provide more info and debug stuff.

-- 
Max

Created attachment 381008 [details]
Xorg.0.log

I have the same problem as the original reporter, and it seems to be most reproducible when loading certain Flash-based websites in Firefox. I think I can even find a couple of websites that cause the problem consistently; my colleague's corporate website at www.somanetworks.com seemed to be one.

Is there any way to increase debugging in the kernel and/or X in order to dump more information for developers when this happens? The system does lock up hard, i.e. it's totally unpingable from other machines on the network when this happens.

Well, the updates I loaded today didn't bring a new radeon driver, but they
did bring a new X server: xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64.
Since I did this update, the X server has crashed about 3 times today
(as opposed to the more normal once a week rate I was getting). Here's
the latest crash walkback from the Xorg.0.log.old file:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49ea48]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e414]
2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x478fae]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f01e44c0000+0x516f) [0x7f01e44c516f]
4: /usr/bin/X (0x400000+0x6bea7) [0x46bea7]
5: /usr/bin/X (0x400000+0x116d53) [0x516d53]
6: /lib64/libpthread.so.0 (0x7f01e8bbb000+0xf0f0) [0x7f01e8bca0f0]
7: /lib64/libc.so.6 (ioctl+0x7) [0x7f01e7abe937]
8: /usr/lib64/libdrm.so.2 (drmIoctl+0x23) [0x7f01e62733b3]
9: /usr/lib64/libdrm.so.2 (drmCommandWriteRead+0x1c) [0x7f01e62735fc]
10: /usr/lib64/libdrm_radeon.so.1 (0x7f01e5964000+0xff9) [0x7f01e5964ff9]
11: /usr/lib64/libdrm_radeon.so.1 (0x7f01e5964000+0x1045) [0x7f01e5965045]
12: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f01e5b68000+0xbcc86) [0x7f01e5c24c86]
13: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f01e5b68000+0xbccf3) [0x7f01e5c24cf3]
14: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f01e5b68000+0xb733b) [0x7f01e5c1f33b]
15: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f01e5b68000+0xba614) [0x7f01e5c22614]
16: /usr/lib64/xorg/modules/libexa.so (0x7f01e4f1f000+0xb06e) [0x7f01e4f2a06e]
17: /usr/lib64/xorg/modules/libexa.so (0x7f01e4f1f000+0xb541) [0x7f01e4f2a541]
18: /usr/bin/X (0x400000+0xd21ae) [0x4d21ae]
19: /usr/bin/X (0x400000+0xcc99e) [0x4cc99e]
20: /usr/bin/X (0x400000+0x2c71c) [0x42c71c]
21: /usr/bin/X (0x400000+0x21d5a) [0x421d5a]
22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f01e7a06b1d]
23: /usr/bin/X (0x400000+0x21909) [0x421909]

Don't know what changed in the X server, but it sure seems more likely to
trigger the bug now than it did before.

Woa! Today's update brought a new ati driver and a whole new visual for
the crashes: xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.x86_64

I was using virt-manager and viewing some consoles again and as a RHEL 4
virtual machine grub screen in one of the viewers counted down to 0 during
the boot (at which time it changes video mode to display the console text),
my whole screen went completly wacko right at the 0 tick of the clock.

Also, I no longer see any backtrace in the X log file, instead it appears
as though the X server attempted to reset, got about a 3rd of the way through
the process and froze up, because the X log is shorter than it normally
is when I've successfully started X and am running with a working display.

I also tried to ssh into the system after the X freeze, and that still worked,
so I was able to verify the log wasn't simply truncated due to the crash.
When I looked at the log even before rebooting, it was already the short
version immediately following the crash.

I'll attach a slew of files and screen shots and wot-not to describe this
most recent crash.

Created attachment 385679 [details]
crash.jpg - photo of screen after crash

Here's what the screen turned into as X crashed and burned. Just a screen full
of random, but kinda regularly repeating trash.

Created attachment 385680 [details]
virt viewer screenshot

This is a screenshot of the virtual machine console I was booting when the
system crashed as it ticked down to zero. I made this shot when I tried
to reproduce the crash, but it counted down to zero and booted fine without
crashing my X server on this 2nd try. On the other hand, when I ran shutdown
in the machine on the second try, as it reached the point where it was going to
turn the virtual machine off, which would reset the virt viewer to the "not
running" screen, X crashed yet again, with a very similar screen filled with
somewhat different trash.

Created attachment 385681 [details]
Xorg.0.log from normally running system

Here is a sample Xorg.0.log file from a working X session.

Created attachment 385682 [details]
Xorg.0.log.old

Here is the Xorg.0.log.old from the crashed session. Note that it appears
to be the same as the normal log, but stops much earlier, which leads to
my suspicion that X attempted to re-initialize itself and died in the attempt.

I suspect this is has to do with multi-input support added recently in Xorg. It crashes in the input driver evdev_drv.so, not in the video driver.

It may indeed be a different crash, since I just crashed again in the original
way with the everything except the mouse frozen and the same old backtrace in
the Xorg.0.log.old file this time:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49ea48]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x49e414]
2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x478fae]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fe8b5b09000+0x516f) [0x7fe8b5b0e16f]
4: /usr/bin/X (0x400000+0x6bea7) [0x46bea7]
5: /usr/bin/X (0x400000+0x116d53) [0x516d53]
6: /lib64/libpthread.so.0 (0x7fe8ba203000+0xf0f0) [0x7fe8ba2120f0]
7: /lib64/libc.so.6 (ioctl+0x7) [0x7fe8b9106937]
8: /usr/lib64/libdrm.so.2 (drmIoctl+0x23) [0x7fe8b78bb383]
9: /usr/lib64/libdrm.so.2 (drmCommandWriteRead+0x1c) [0x7fe8b78bb5cc]
10: /usr/lib64/libdrm_radeon.so.1 (0x7fe8b6fab000+0x1469) [0x7fe8b6fac469]
11: /usr/lib64/libdrm_radeon.so.1 (0x7fe8b6fab000+0x14b4) [0x7fe8b6fac4b4]
12: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fe8b71af000+0xa7d97) [0x7fe8b7256d97]
13: /usr/lib64/xorg/modules/libexa.so (0x7fe8b6566000+0x41b7) [0x7fe8b656a1b7]
14: /usr/lib64/xorg/modules/libexa.so (0x7fe8b6566000+0x7037) [0x7fe8b656d037]
15: /usr/lib64/xorg/modules/libexa.so (0x7fe8b6566000+0xf753) [0x7fe8b6575753]
16: /usr/bin/X (miImageText8+0x7e) [0x5500ae]
17: /usr/bin/X (0x400000+0xd56ed) [0x4d56ed]
18: /usr/bin/X (doImageText+0x1a3) [0x42f263]
19: /usr/bin/X (ImageText+0x67) [0x42f477]
20: /usr/bin/X (0x400000+0x2ae5b) [0x42ae5b]
21: /usr/bin/X (0x400000+0x2c71c) [0x42c71c]
22: /usr/bin/X (0x400000+0x21d5a) [0x421d5a]
23: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fe8b904eb1d]
24: /usr/bin/X (0x400000+0x21909) [0x421909]

So now I have two ways this X server crashes on this hardware :-).

You are using radeon_drv.so and I am using nvidia_drv.so.

All stack traces presented here involve evdev_drv.so down the stack and xf86PostMotionEventP function.

I wonder if xf86PostMotionEventP() has anything to do with video drivers at all.

I put this bug in initially against evdev because of the stack trace, but
the X gurus changed it to what it is now because they said everything
in X is always running the input loop and that didn't have anything to
do with the crash.

Anyway, I've now gotten the new style crash again for the 3rd time today,
with a difference: The screen mostly looks like the screenshot from
comment #28, but the flash content (at least I assume it is flash) with
the picture of Urban Meyer from si.com was still intact on the screen, though
appeared to shift down a few inches. Any Florida Gators working on the X
server project?

AAUGH! After the 5th (or is it 6th) crash today, I'm switching back to
booting my fedora 11 partition by default on this machine. It uses the
radeonhd driver and disables modesetting and evdev, but at least it
functions correctly in that state (I've tried all those things on
fedora 12 and they only make it worse :-).

The most recent crash was slightly interesting. Instead of suddenly
freezing with no warning, the cursor first started acting funny, as if
the cursor associated with a window had become random blocky trash when
I moved it over that window. As I was about to see if I could reproduce
it by restarting the app, then the screen froze up in the initial
bug report fashion.

(In reply to comment #35)
> I put this bug in initially against evdev because of the stack trace, but
> the X gurus changed it to what it is now because they said everything
> in X is always running the input loop and that didn't have anything to
> do with the crash.

Hi Tom,

Interesting indeed.

It always crashes from within xf86PostMotionEventP function. It can generally be either a) some (explicit local and implicit global) arguments to that function are not valid (or, generally speaking, function preconditions have not been satisfied) or b) process address space has been corrupted. Did evdev developers confirmed that it is neither of these and that the problem is rooted in the code eventually calling xf86PostMotionEventP (the Xorg video drivers in this case)?

-- 
Max

(In reply to comment #36)
> AAUGH! After the 5th (or is it 6th) crash today, I'm switching back to
> booting my fedora 11 partition by default on this machine.

Yep, I did the same, rolled back to Fedora 11. It works just fine with the same proprietary NVidia 190.42 driver. (apart from higher Xorg CPU utilization compared with that of Fedora 10 (no desktop effects involved)).

> It uses the
> radeonhd driver and disables modesetting and evdev, but at least it
> functions correctly in that state (I've tried all those things on
> fedora 12 and they only make it worse :-).

With Fedora 11 I did not have to disable anything (apart from nouveau driver (which can't drive more than one GPU of the 2xGPU Quadro I've got in my desktop at work) in order to be able to use the NVidia proprietary driver).

-- 
Max

Created attachment 387151 [details]
xorg.conf

I finally found a combination that works! (At least I've been running for
about 1/2 day this way with no crashes.) Here's the xorg.conf file
which switches to the radeonhd driver, turns off most of the hardware
acceleration, and also turns off evdev. In addition I added nomodeset
to the kernel boot options.

I have no idea how many of these things I really needed to turn off,
but this combo does in fact work and for what I do (mostly firefox and
emacs), I don't notice any human perceptible performance problems.

Perhaps the difference between this working config and the default busted
config will give someone some ideas about what is wrong...

(In reply to comment #39)
> Created an attachment (id=387151) [details]
> xorg.conf
> 
> I finally found a combination that works! (At least I've been running for
> about 1/2 day this way with no crashes.) Here's the xorg.conf file
> which switches to the radeonhd driver, turns off most of the hardware
> acceleration, and also turns off evdev. In addition I added nomodeset
> to the kernel boot options.

I wonder if just turning off evdev only solves your problem. (I guess that is Option "AutoAddDevices" "False" option).

Created attachment 389433 [details]
kernel crashes

We have one laptop with Mobility Radeon HD 3430 integrated GPU using radeon driver and also see constant kernel crashes but not even mouse moves after crash, we just see black screen. We see these crashes while using Firefox and flash, but not 100% sure if that is the issue.

Is the crash in the log the same issue as others have?

What is the solution?

These crashed became more frequent after updates from one or two weeks ago. Is there a way to revert problematic updates? Is there a way to downgrade X, mesa and radeon driver?

I have this problem too after latest updates on HD 3430 (hybrid on HP 6830s), FC12 32bit. 

Opps like
BUG: unable to handle kernel NULL pointer dereference at 00000018
IP: [<f800907d>] r600_kms_blit_copy+0x55/0x528 [radeon]

or

WARNING: at drivers/gpu/drm/radeon/r600_blit_kms.c:550 r600_blit_prepare_copy+0x2a/0x3b8 [radeon]() (Tainted: P        W )

I have attached dmesg and xorg on Bug 553862


Any workaround for this?

I got a similar one with more serious. The whole system hangs on and stops to receive ANY input. Screen turns to black,too.

I just tried switching back to radeon driver with the new updates:

kernel-2.6.32.9-67.fc12.x86_64
xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.x86_64

It took less than an hour to crash again, but this time instead of funny
trash on screen, my screen went black and decided it wasn't getting a signal
so switched to power saver mode.

No backtrace was left in the X log, no X releated errors showed up at the
end of dmesg or messages, it just died sudden like.

I have switched back to nomodeset and radeonhd (which hopefully will
continue to work).

Created attachment 398523 [details]
Xorg.0.log saved from crash in comment #44

Created attachment 398525 [details]
dmesg saved from crash in comment #44

Created attachment 398526 [details]
messages saved from crash in comment #44

After updating kernel I lost compiz effects(compiz cant be enabled because no 3d), but I have 3d working (glx-gears works fast). 

Earlier with old kernel compiz work without problem and without crash (I have nomodeset enabled). Nomodeset resolve all my problem with old kernel.

The hard crash described in bug 562607 now happens on this RV610 after I
updated the system to fedora 13. I haven't used it enough to be sure the
original bug described in comment #1 has gone away, but I haven't yet
seen a crash for anything other than the gltestperf mesa demo.

I've been using this thing all week now on fedora 13, and have not yet seen
any of the mysterious crashes. I've even used virt-manager a while and installed
some virtual machines without virt-viewer triggering any crash. So far
fedora 13 is looking pretty good on this card.

The one odd behavior I see (which may be a change in firefox rather than
the video driver) is flash content is living up to it's name. Whenever I
use the scroll wheel to scroll a page in firefox, and the page has flash
content, the sections of the page with flash flicker horribly. It is like
they go some solid beige-like color then it tries to redraw them, then
the scrolling moves a bit and the process repeats.

Looking at the same pages on fedora 12, they scrolled smoothly with no
flickering.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.