Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Zaphod does not work on ATi X300SE|
|Product:||[Fedora] Fedora||Reporter:||Jan "Yenya" Kasprzak <kas>|
|Component:||xorg-x11-drv-ati||Assignee:||Dave Airlie <airlied>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-14 13:29:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jan "Yenya" Kasprzak 2008-05-12 05:50:54 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: 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-22.214.171.1241-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 email@example.com today (Subject: ATi X300SE - zaphod stopped working) with the suggestion to report the problem here.
Comment 1 Jan "Yenya" Kasprzak 2008-05-12 05:50:55 EDT
Created attachment 305108 [details] my Xorg.conf file (worked on F8, does not work on F9)
Comment 2 Jan "Yenya" Kasprzak 2008-05-12 05:51:41 EDT
Created attachment 305109 [details] Xorg.0.log
Comment 3 Dave Airlie 2008-05-12 06:13:43 EDT
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 07:51:57 EDT
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 08:49:09 EDT
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 12:19:27 EDT
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 07:01:46 EDT
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-18 21:42:25 EDT
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 07:34:02 EDT
The xorg.conf where it breaks is attached to the comment #1.
Comment 10 Bug Zapper 2009-06-09 20:43:54 EDT
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 13:29:28 EDT
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.