Description of problem: Hardware is: http://www.smolts.org/client/show/pub_62923515-d6d0-431e-b8e8-e2d6ae6d2eb3 With the 20090909 testday x86-64 image, the machine locks up shortly after successfully starting X and GDM. On one occasion it locked up while trying to log in, in another case the cursor continued to move around the screen, but remained stuck part way through the "busy" animation, and all other input was ignored. (For reference in the 20090908 image X wouldn't even start, the machine would hang at a blank screen after the boot finished) The lockups happen to soon for me to get Xorg logs or look at dmesg. With nomodeset, I am able to complete log in and some basic tasks, I will file separate bugs about problems found once I have logged in with nomodeset.
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 ***