When starting X (with DRI enabled), the screen just goes blank and the keyboard
is dead. Xorg consumes 100% CPU and can't be killed... well it doesn't really
go away, just the terminal shows it is killed, but there is an Xorg process
with the same pid hogging the CPU. When run trough strace (before killing), it
just endlessly does:
ioctl(9, 0x6444, 0) = -1 EBUSY (Device or resource busy)
FD #9 is /dev/dri/card0 (as is FD #10 FWIW). My X version is:
root@wombat:~> Xorg -version
X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: Linux 2.6.9-34.ELsmp x86_64 Red Hat, Inc.
Current Operating System: Linux wombat 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20
14:51:34 EST 2006 x86_64
Build Date: 29 January 2007
Build ID: xorg-x11-server 1.1.1-47.5.fc6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
root@wombat:~> rpm -q xorg-x11-server-Xorg xorg-x11-drv-ati
I found some oddities in the log file, namely that a) the driver was somehow
confused by the cards secondary bus ID, b) it didn't recognize the Radeon X800
GTO as such, but as an X850 PRO and c) somehow used only 128MB of the 256MB
(II) Primary Device is: PCI 07:00:0
(--) Assigning device section with no busID to primary device
(WW) RADEON: No matching Device section for instance (BusID PCI:7:0:1) found
(--) Chipset ATI Radeon X850 PRO (R480) (PCIE) found
(II) resource ranges after xf86ClaimFixedResources() call:
(II) RADEON(0): Page flipping disabled
(II) RADEON(0): Will try to use DMA for Xv image transfers
(II) RADEON(0): Generation 2 PCI interface, using max accessible memory
(II) RADEON(0): Detected total video RAM=262144K, accessible=131072K (PCI
(--) RADEON(0): Mapped VideoRAM: 131072 kByte (256 bit DDR SDRAM)
(II) RADEON(0): Color tiling enabled by default
The output of lspci -v also shows that only 128MB are mapped.
I could get X to work when I disabled DRI (I used "install radeon /bin/false"
in /etc/modprobe.conf to do that). I've attached xorg.conf, Xorg.0.log, strace
output (shortened) and lspci output to the upstream bugreport:
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 150304 [details]
/etc/X11/xorg.conf of the machine in question
Created attachment 150305 [details]
Xorg.0.log with xorg.conf
Created attachment 150306 [details]
Xorg.0.log without xorg.conf
Matej, running without xorg.conf didn't change things. Note that you could have
found xorg.conf and the log on the upstream bugzilla as well ;-). There's also
strace output that might be of use.
Just FYI, I tried (32bit) Knoppix 5.2 and found the same problem, i.e. this is
not a 32bit vs. 64bit thing.
Just FYI (again ;-)), I tried F7 test4 Live (64bit) and the problem was still there.
Just reproduced the problem with:
Is there anything else I should try (Rawhide?) -- I'm eager to work on this as
I've been suffering from a lack of 3D (gaming, caring for my 3D packages) for a
trying the rawhide ati driver might very useful as it has a major rework of the
ati radeon driver.... I'm not sure if you need to pull in the xserver and mesa
packages as well for it to work...
RPM requirements are basically the same. I'll give it a try.
Without DRI, it gave me a 800x600 resolution. But that may as well be a part of
the new XRandR-enabled "users have to be explicit that they don't need
prescription glasses" world order of things ;-). Will that be fixed in F8 or can
it be easily worked around?
With DRI (i.e. the Radeon kernel driver loaded), it gave me the same 800x600
resolution with a moving mouse pointer and the contents of whatever was in the
framebuffer. Nothing else working, I tried to one time kill it with
Ctrl-Alt-BackSpc or to switch consoles with Ctrl-Alt-F1, both of which hung X
Do you think it should make a difference with F8/Rawhide. I've got a free disk
ATM so I could install it there (if it's installable at all right now?).
I've installed Rawhide now (what a mess ATM ;-) and found that with the DRM
module loaded, it's much similar to comment #11: It gives a working mouse
cursor, but the FB contents are "what's there", in my case I could (with a a bit
imagination) see parts of my usual desktop background, but heavily distorted --
it still only does 800x600 no matter what I try to fiddle in xorg.conf while my
desktop is 1400x1050.
I've dug a bit into that second problem and found from Xorg.0.log that it seems
to think that a TV is my main display or something similarly bogus. Is that an
already known problem or shall I open a new bug for it?
Forgot the package versions in comment #12:
Is there any luck with the latest rawhide driver? upstream has been fixing ATI
bugs in this area at an extreme rate...
I'll check this soonish, when I don't need the machine for "real work" ;-).
Doesn't work (black screen, hung, SysRq works):
Dave, according to upstream (http://bugs.freedesktop.org/show_bug.cgi?id=9957
comments 40-42), you seem to have fixed this in current drm-git (which
apparently needs mesa-git, xserver-git to function well). It would be nice if
you could backport these changes. F8 would be sufficient for me, I'll upgrade my
I'll hopefully get the patch into the Fedora kernel so it'll be there early in
F8 updates and I'll stick it in F7 kernel as well for good measure...
Is it only the kernel that needs fixing? The comments upstream about AIGLX seem
to suggest otherwise.
contains some kernel packages for F8 with the fix in them.. no other fix is
necessary for Fedora. I've checked the fix in to the kernel tree for F-7 and F-8
so the kernel releases on those should have it in them soon.
kernel-188.8.131.52-45.fc8 works for me, thanks a lot!