Bug 446042 - Zaphod does not work on ATi X300SE
Summary: Zaphod does not work on ATi X300SE
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-12 09:50 UTC by Jan "Yenya" Kasprzak
Modified: 2009-07-14 17:29 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-07-14 17:29:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
my Xorg.conf file (worked on F8, does not work on F9) (1.79 KB, text/plain)
2008-05-12 09:50 UTC, Jan "Yenya" Kasprzak
no flags Details
Xorg.0.log (49.17 KB, text/plain)
2008-05-12 09:51 UTC, Jan "Yenya" Kasprzak
no flags Details

Description Jan "Yenya" Kasprzak 2008-05-12 09:50:54 UTC
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:

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]
7: /usr/lib64/xorg/modules/drivers//radeon_drv.so(RADEONScreenInit+0x18f7)
[0x2b16c65fd1d7]
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):
xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9.x86_64
xorg-x11-drv-ati-6.8.0-15.fc9.x86_64

My graphics card is:
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300
(PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]

Additional info:
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 xorg.org
today (Subject:  ATi X300SE - zaphod stopped working) with the suggestion to
report the problem here.

Comment 1 Jan "Yenya" Kasprzak 2008-05-12 09:50:55 UTC
Created attachment 305108 [details]
my Xorg.conf file (worked on F8, does not work on F9)

Comment 2 Jan "Yenya" Kasprzak 2008-05-12 09:51:41 UTC
Created attachment 305109 [details]
Xorg.0.log

Comment 3 Dave Airlie 2008-05-12 10:13:43 UTC
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.

Comment 4 Jan "Yenya" Kasprzak 2008-05-12 11:51:57 UTC
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 >
~/redhat/SOURCES/xf86-video-ati-6.8.0git1.tar.bz2
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
as before.

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?

Comment 5 Jan "Yenya" Kasprzak 2008-05-12 12:49:09 UTC
I have tried to disable the Zaphod mode, and apparently there are several
separate problems: 

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


Comment 6 Jan "Yenya" Kasprzak 2008-05-12 16:19:27 UTC
I have tested this also on F9/i386 on a different machine with X300SE and I can
reproduce the problem. Changing architecture to "All".

Comment 7 Bug Zapper 2008-05-14 11:01:46 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Dave Airlie 2008-05-19 01:42:25 UTC
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.

Comment 9 Jan "Yenya" Kasprzak 2008-05-27 11:34:02 UTC
The xorg.conf where it breaks is attached to the comment #1.

Comment 10 Bug Zapper 2009-06-10 00:43:54 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Bug Zapper 2009-07-14 17:29:28 UTC
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.


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