Alternative workaround is booting with 'radeon.modeset=0'

that's the same as nomodeset.

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

Still occurs with the Fedora 12 beta live image

KMS is useless like this. So it needs to be disabled by default for this hardware until someone actually has the time to investigate and fix the bug.

Is this a dupe of bug #517625?

Can you try if adding pcie_aspm=off to your kernel boot parameter fix your lockup ?

Got similar problems using a RV670PRO with radeon/kms.
(fedora 12 beta / kernel-2.6.31.1-56.fc12.x86_64)

See:
http://www.smolts.org/client/show/pub_66917802-6fe1-48e9-883b-b203e81d9a4a

Disabling kms via 'nomodeset' fixed that problem.
'pcie_aspm=off' worked too, without disabling kms.
So I'm using 'pcie_aspm=off' right now.

Short answer to question from Jerome is no.

With pcie_aspm=off  added to the command line, I see the following in 'dmesg' that mentions ASPM...

--
PCIe ASPM is disabled
ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
--

I started a Live CD-based USB stick in this way, and added a test user, so that I could endeavour to debug the problem over the network. This worked.

I ran Aisleriot, maximised it, and the screen stopped redrawing. The cursor still moves, and my SSH session stayed up. Nothing new and interesting in 'dmesg' when this happens, but the following from the X.org log looks like a potential smoking gun to me:

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

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49e758]
1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x49e124]
2: /usr/bin/Xorg (xf86PostMotionEventP+0xce) [0x478ede]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f6c527b8000+0x3dff) [0x7f6c527bbdff]
4: /usr/bin/Xorg (0x400000+0x6bdf7) [0x46bdf7]
5: /usr/bin/Xorg (0x400000+0x116993) [0x516993]
6: /lib64/libpthread.so.0 (0x7f6c58254000+0xf320) [0x7f6c58263320]
7: /lib64/libc.so.6 (ioctl+0x7) [0x7f6c56ae0717]
8: /usr/lib64/libdrm.so.2 (drmIoctl+0x23) [0x7f6c54569203]
9: /usr/lib64/libdrm.so.2 (drmCommandWriteRead+0x1c) [0x7f6c5456944c]
10: /usr/lib64/libdrm_radeon.so.1 (0x7f6c53c5b000+0xf59) [0x7f6c53c5bf59]
11: /usr/lib64/libdrm_radeon.so.1 (0x7f6c53c5b000+0x1035) [0x7f6c53c5c035]
12: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f6c53e5f000+0xbc6b6) [0x7f6c53f1b6b6]
13: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f6c53e5f000+0xbc723) [0x7f6c53f1b723]
14: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f6c53e5f000+0xba262) [0x7f6c53f19262]
15: /usr/lib64/xorg/modules/libexa.so (0x7f6c53217000+0x85f5) [0x7f6c5321f5f5]
16: /usr/lib64/xorg/modules/libexa.so (0x7f6c53217000+0x920a) [0x7f6c5322020a]
17: /usr/lib64/xorg/modules/libexa.so (0x7f6c53217000+0x74d8) [0x7f6c5321e4d8]
18: /usr/bin/Xorg (0x400000+0xd315b) [0x4d315b]
19: /usr/bin/Xorg (0x400000+0x2a954) [0x42a954]
20: /usr/bin/Xorg (0x400000+0x2c60c) [0x42c60c]
21: /usr/bin/Xorg (0x400000+0x21c9a) [0x421c9a]
22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f6c56a25b4d]
23: /usr/bin/Xorg (0x400000+0x21849) [0x421849]

FWIW the X server is indeed spinning (100% CPU), from this state the X server can be killed (only with SIGKILL) but newly started X servers spin in the same way soon after setting up a mode. I can't speculate on whether this means there's a deeper unrecoverable problem in KMS at that point, or whether it just doesn't reset enough of the Radeon's internal state on a restart, but either way isn't the Right Thing.

Does using kernel from :
http://koji.fedoraproject.org/koji/buildinfo?buildID=138707
And also updating others package especialy xorg-x11-drv-ati helps anyhow ?

Can I update to those packages from a LiveCD image written to a USB stick?

If not, is there a plausible way to test that from the Live CD? Or to get an up-to-date LiveCD which would have these newer packages?

It really isn't practical to install (and then update) Fedora 12 Beta onto this machine because I absolutely need it for work, sorry. A drive swap isn't practical (even if I had that kind of time) because it's a laptop and my spare drives are all full size.

I can spin up a live build for you with that kernel included, I think. Give me a couple of hours.

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

Live build is currently uploading to:

http://adamwill.fedorapeople.org/radeon-20091028-x86_64.iso

it should be complete in around 2-3 hours.

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

live build is up now, please go ahead and try it.

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

No improvement I'm afraid.

Same hang: 

mouse still works, X server reports EQ overflow and backtraces as before

This time it occurred to me to ask what the spinning X server was actually waiting on, I installed strace and watched the process for a few seconds, it spits out only

ioctl(9, 0xc0086464, 0x7fff458cfa10)    = -1 EBUSY (Device or resource busy)

repeated endlessly, maybe that's some help in debugging the problem?

This is another case of KMS hangs on r600+ICH9 hardware combination, closing as a dupe of 528593 where this major issue is being tracked.

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

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