Red Hat Bugzilla – Bug 446042
Zaphod does not work on ATi X300SE
Last modified: 2009-07-14 13:29:28 EDT
Description of problem:
The dual-screen (zaphod) mode does not work: the secondary head starts up with
the refresh rate out of the monitor range, and when the cursor is moved to the
secondary head, it cannot be moved back. When the last X client disconnects, the
X server crashes with the following backtrace:
0: X(xf86SigHandler+0x65) [0x479fe5]
1: /lib64/libc.so.6 [0x2b16c3f1b2a0]
2: X [0x4a6485]
3: X [0x4a7066]
4: X(xf86_reload_cursors+0x10c) [0x4a6aec]
5: X(xf86CrtcSetMode+0x3fd) [0x4a420d]
6: X(xf86SetDesiredModes+0x1bd) [0x4a469d]
8: X(AddScreen+0x1c9) [0x42bf09]
9: X(InitOutput+0x216) [0x4623c6]
10: X(main+0x286) [0x42c6a6]
11: /lib64/libc.so.6(__libc_start_main+0xfa) [0x2b16c3f0732a]
12: X(FontFileCompleteXLFD+0x279) [0x42bc59]
Fatal server error:
Caught signal 11. Server aborting
Version-Release number of selected component (if applicable):
My graphics card is:
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
I will attach my xorg.conf and Xorg.0.log.
The attached configuration used to work with Fedora 8 drivers, with a slight
problem that the cursor on the secondary head was just a rectangle of random
noise. I have tried to downgrade the system to Fedora 8 X server and ATi driver,
and it crashes immediately after moving the cursor to the secondary head (maybe
the glibc now performs more strict checks on F9 than it used to do on F8?). The
crash is in the memcpy() function - I can create a full backtrace if needed.
For the reference: the problem has been discussed in email@example.com
today (Subject: ATi X300SE - zaphod stopped working) with the suggestion to
report the problem here.
Created attachment 305108 [details]
my Xorg.conf file (worked on F8, does not work on F9)
Created attachment 305109 [details]
Can you try git master easily?
if not let me know I'll do some more test packages..
I've pushed a fix that might fix the backtrace on exit to git master. let me
know if it helps if not, a gdb backtrace might be useful.
I did the following (correct me if I am doing a mistake somewhere):
git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
mv xf86-video-ati xf86-video-ati-6.8.0git1
tar cf - xf86-video-ati-6.8.0git1 | bzip2 -9 >
rpm -i xorg-x11-drv-ati-6.8.0-15.fc9.src.rpm
(edit xorg-x11-drv-ati.spec, changing the version number to 6.8.0git1, removing
the %patch directives, and removing mach64- and r128-related lines from %files)
rpmbuild -ba xorg-x11-drv-ati.spec
rpm -Uvh ~/redhat/RPMS/x86_64/xorg-x11-drv-ati-6.8.0git1-15.x86_64.rpm
It apparently behaves the same way (crashing if the last client disconnects).
However, I have managed to use a secondary head using the following steps:
- when the last client which is disconnecting is at the :0.1 screen, the server
does not crash, and even better, I am now able to move the cursor between both
heads (before that, the cursor disappeared as soon as it crossed the edge
between the two heads and I couldn't get it back).
- now as long as at least one client is connected, the server does not crash.
- it still uses an unsupported mode on the secondary head (it has 1280x1024
native resolution, but according to xrandr(1), the X server uses 1600x1200,
and does not even have 1280x1024 in the list of valid modes for :0.1 VGA-0).
When I switch the secondary head to 1024x768, it works (altough it looks ugly on
a non-native resolution).
- when the last X client disconnects, the server crashes with the same message
Steps to reproduce:
1. X &
2a. DISPLAY=:0.0 xterm &
- now if you kill %2, the X server crashes
or 2b. DISPLAY=:0.1 xterm &
3. kill %2
4a. DISPLAY=:0.1 xrandr
- the server crashes
or 4b. DISPLAY=:0.1 xterm & # Keep at least one client connected
5. DISPLAY=:0.1 xrandr --output VGA-0 --mode 1024x768
- the secondary screen becomes visible
I have also tried to test the same configuration with ATi X1650 in the same box
(both in xorg-x11-drv-ati and xorg-x11-drv-radeonhd - it does not work either;
with -ati, only the secondary screen comes up as :0.0, with -radeonhd, I get the
clone mode instead of dual-screen Zaphod). Should I fill a separate bug for
X1650 in Zaphod mode?
I have tried to disable the Zaphod mode, and apparently there are several
The "crash when the last client disconnects" problem happens on my X300 even
with one head in ServerLayout and one monitor connected. The crash also occurs
on X1650 with radeon (not radeonhd) driver with one head only.
The other problem (in Zaphod mode, I cannot use the secondary head, because the
cursor gets stuck when moving to the secondary head) is apparently an unrelated one.
The third problem - incorrect mode detection on the secondary head - occurs also
without the Zaphod mode (only one screen in xorg.conf, xrandr reports no mode
1280x1024 on VGA-0, and uses 1600x1200 by default, which is over the secondary
monitor specs). When trying to add 1280x1024 mode manually using xrandr
--newmode, I get the BadName error:
X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 153 (RANDR)
Minor opcode of failed request: 16 ()
Serial number of failed request: 16
Current serial number in output stream: 16
I have tested this also on F9/i386 on a different machine with X300SE and I can
reproduce the problem. Changing architecture to "All".
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
okay I tracked down the crash on exit in the X server and have a fix for that.
I'll tag this bug when I push it out...
the cursor getting stuck I'm having trouble reproducing here, but I'll try
again, can you attach and xorg.conf where it breaks please.
The final bug looks like a conf bug somehow.
You might try removing the explicit mode sections, and adding Option
"PreferredMode" to the monitor sections.
The xorg.conf where it breaks is attached to the comment #1.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9'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 9 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:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.