Bug 522260 - KMS lockups for laptop w/ Radeon HD 3400 / [1002:95c4]
KMS lockups for laptop w/ Radeon HD 3400 / [1002:95c4]
Status: CLOSED DUPLICATE of bug 528593
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-09-09 18:05 EDT by Nick Lamb
Modified: 2009-11-01 17:32 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-01 17:32:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nick Lamb 2009-09-09 18:05:37 EDT
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.
Comment 1 Daniel J Blueman 2009-09-09 18:46:11 EDT
Alternative workaround is booting with 'radeon.modeset=0'
Comment 2 Adam Williamson 2009-09-16 14:41:50 EDT
that's the same as nomodeset.

Fedora Bugzappers volunteer triage team
Comment 3 Nick Lamb 2009-10-20 20:58:22 EDT
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.
Comment 4 Matthew Miller 2009-10-21 15:53:52 EDT
Is this a dupe of bug #517625?
Comment 5 Jérôme Glisse 2009-10-21 17:25:53 EDT
Can you try if adding pcie_aspm=off to your kernel boot parameter fix your lockup ?
Comment 6 Lars Hamann 2009-10-22 02:26:23 EDT
Got similar problems using a RV670PRO with radeon/kms.
(fedora 12 beta / kernel-


Disabling kms via 'nomodeset' fixed that problem.
'pcie_aspm=off' worked too, without disabling kms.
So I'm using 'pcie_aspm=off' right now.
Comment 7 Nick Lamb 2009-10-22 05:20:01 EDT
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.

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]
Comment 8 Nick Lamb 2009-10-22 05:32:01 EDT
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.
Comment 9 Jérôme Glisse 2009-10-28 15:05:19 EDT
Does using kernel from :
And also updating others package especialy xorg-x11-drv-ati helps anyhow ?
Comment 10 Nick Lamb 2009-10-28 16:08:25 EDT
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.
Comment 11 Adam Williamson 2009-10-28 17:12:56 EDT
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
Comment 12 Adam Williamson 2009-10-28 19:25:26 EDT
Live build is currently uploading to:


it should be complete in around 2-3 hours.

Fedora Bugzappers volunteer triage team
Comment 13 Adam Williamson 2009-10-29 00:35:20 EDT
live build is up now, please go ahead and try it.

Fedora Bugzappers volunteer triage team
Comment 14 Nick Lamb 2009-10-29 17:34:26 EDT
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?
Comment 15 Adam Williamson 2009-11-01 17:32:45 EST
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

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

Note You need to log in before you can comment on or make changes to this bug.