Yet another Radeon bug... Many people seem to have problems with these video cards, only with slight variations. When connecting a flat panel display to the DVI port on my cheap Radeon 9200 based video card (PCI ID 1002:5961) no picture is shown. The DVI port seems to be completely disabled. This is not a hardware problem, since the setup works nicely under other operating systems. In some cases I have seen an extremely bad picture with lots of "snow", similar to what is described in http://www.mail-archive.com/xfree86@xfree86.org/msg10671.html What puzzles me is that it currently appears to work if I boot in initlevel 3 and then execute startx as root. If I boot directly into gdm in level 5 there is no picture on the display. The XFree86.0.log files are idential except for the time stamps, and AFAICT the same XF86Config file is used.
Oh, and my remark above about many problems is _not_ a complaint about the quality of XFree86, bug fixing speed or anything similar; I just meant to indicate that I have tried to dig up additional information but failed to find the exact similar problem elsewhere. My apologies for the poor wording.
Created attachment 96526 [details] XFree86 log with successfully started with startx This is a XFree86.0.log file from when X is started using startx and DVI output works. Except for the timestamp the only differences are [root@localhost log]# diff -u XFree86.0.log-working_startx XFree86.0.log-nonworking_gdm --- XFree86.0.log-working_startx 2003-12-14 21:35:44.000000000 +0100 +++ XFree86.0.log-nonworking_gdm 2003-12-14 21:34:04.000000000 +0100 @@ -37,7 +37,7 @@ (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" -(--) using VT number 8 +(++) using VT number 7 (II) Open APM successful (II) Module ABI versions: @@ -61,7 +61,7 @@ ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 -(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 +(II) PCI: stages = 0x03, oldVal1 = 0x80004860, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10de,01a4 card 0000,0000 rev b2 class 06,00,00 hdr 80 (II) PCI: 00:00:1: chip 10de,01ac card 10de,0c11 rev b2 class 05,00,00 hdr 80
Created attachment 96527 [details] XF86Config file
There is no technical reason that I can think of, where gdm and startx should operate differently, because the X server is what reads the XF86Config config file, and it will invoke the server identically in each case. If you start your system, and run "startx" then quit, then run "startx" again several times does it work properly, or does it fail the second or third time, etc? Also, do the same for gdm as well. One other thing, I see you are using a different VT depending on wether you're using startx or gdm. Do you have Red Hat Graphical Boot (rhgb) enabled? If so, disable rhgb entirely and try again. TIA
Right, now I'm really puzzled; I hope the following makes sense. First of all thanks for the followup. Judging from the log files gdm and startx are using the same config file, so you are right that there are no differences there. My system is FC1 upgraded from RH9, so even if graphical boot was on it wasn't used. I have disabled it just to be sure. Then I did something slightly silly - I upgraded to the latest versions of the kernel, initscripts etc., and this has caused startx to stop working. The only difference in the log file is that startx now also uses VT 7. Forcing startx to run on VT 8 (startx -- vt8) makes it work again, but doing the same with gdm makes no difference there. The difference between the log files is the oldVal1 value shown above; with startx it is always 0x00000000 and with gdm it is always 0x80004860, independent of the VT used, so something appears to differ between the two ways of starting X. startx only works properly once. When exiting X the display does not switch back to text; instead the graphical display is left on. Subsequent attempts cause the DVI port to be shut off completely. So, to summarize: I'm only able to get output on the DVI port when X is on VT 8 and oldVal1 is 0x00000000; this is the case when using startx -- vt8. In all other cases (gdm on any VT with oldVal1 0x80004860, startx on VT 7 with oldVal1 0x00000000) there is no output on the DVI port.
FWIW, I have tried using the driver from ATI, and it appears to have the exact same problem - the log indicates that the display is detected correctly, but there's no display on the DVI port. The analog port works fine.
I can confirm this bug on clean Fedora Core 1 with Powercolor Radeon 9200 SE video card and Samsung Syncmaster 191T on DVI port. The DVI port works perfectly well (1280x1024 60hz) every OTHER invocation of X (that is, one invocation has no signal on DVI, the next has signal on DVI, the next has no signal again...) -- again the only distinction in the XFree86 log is whether it shows VT 7 or VT 8: [rob@bluedog log]$ diff XFree86.0.log XFree86.0.log.old 21c21 < (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 6 00:19:57 2004 --- > (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 6 00:19:40 2004 42c42 < (--) using VT number 7 --- > (++) using VT number 8
This is a known and possibly fixed problem, check here: http://bugs.xfree86.org/show_bug.cgi?id=673 Apparently you can try the latest driver from http://www.xfree86.org/~alanh/ I will do that a bit later and tell you if anything changes (I have the same prob - no DVI on 9200).
Uhm, yes DVI works with the latest driver/server from the link above. However it's not worth the trouble: the picture quality is noticeably worse - red color is quite misconverged with the other two, which is seen on any small text, any resolution. Dunno if it's the card (Sapphire Ati Radeon 9200 64Mb) or the monitor (Viewsonic VP171s) but going back to good old analog link...
Created attachment 97246 [details] antialias problem Oops. This is actually an antialiasing problem with Xft applications. Strangely, it disappears if I either switch to Gnome (from WindowMaker) or run gnome-font-properties and then restart an application.
Yes! I can confirm that running with the latest radeon_drv.o from Alan Hourihane makes the DVI port work very nicely. Thanks for the hint.
I can confirm this too (radeon_drv.o of date 2003-12-03). Is XFree86 4.4.0 going into FC2?
Uhm. But you don't necessarily need to ship the whole of XFree 4.4 in FC2. Just the latest drivers will do. Is that planned?
I somehow missed Alex's reference in comment #8 to the upstream bug report which contains a patch from Hui Yu at ATI, which claims to fix this problem. I have looked at the patch and it is very trivial, and appears to be a very low risk patch that should not affect any other hardware. As such, I have queued the patch for inclusion in a future XFree86 build, which will probably be available within the next week or so in rawhide. I'll update this report when there is something available for testing. Thanks.
XFree86-4.3.0-55 doesn't seem to include the fix unfortunately. Had to revert to the binary driver provided by xfree86.org.
Can we expect the fix to appear in one of the Fedora Core 2 test releases? It's just a trivial one-liner and has been confirmed as working by at least four people already.
Is this the patch? http://bugs.xfree86.org/attachment.cgi?id=604&action=view If not, please attach the one liner as a unified diff attachment taken from the root of the tree, and I'll review it.
It should be. I've just checked - it was actually commited to XFree CVS together with a bunch of other radeon fixes: http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c?only_with_tag=xf-4_3_99_14 but I'm not asking you to include them all. :)
Someone has confirmed via email a patch that allegedly fixes this issue, and I have applied it to 4.3.0-59. I do not have the hardware to test this personally, however I have added it, and hope that it fixes the problems you've encountered. Please test the new release once it is available in rawhide, and provide feedback as to wether or not it works for you. If you need a driver for Fedora Core 1, you can extract the radeon_drv.o file out of the main XFree86-4.3.0-59.i386.rpm, and rename the old driver, and drop this one in it's place for test purposes. Hope this helps, and thanks in advance for testing.
4.3.0-59 is in rawhide now. Please test it, and close this bug as "RAWHIDE" if it is now fixed, otherwise please set status back to "ASSIGNED".
The 4.3.0-59 works fine for me. Thanks - I was just about to build my own patched package. I'm not allowed to do any changes to the bug status though.
Ok, thanks for the update. Closing as fixed in 'RAWHIDE'
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-118.html
Uh, why not issue an errata for FC1 also? I understand that FC2 is just around the corner, but it still seems a bit improper to me.
Hi Alex, Fedora Core 1, Red Hat Enterprise Linux 3, and Red Hat Linux 9 all share XFree86 4.3.0 from the same src.rpm. The package is configured slightly differently on each OS release due to dependancies on a particular compiler version for some features, etc. but the base code is shared. As such, any bug fixed for 4.3.0 will come from the same src.rpm for all OS releases. Whenever erratum is released for a particular OS release, that release will benefit from all bugfixes applied to date, unless they are release specific in some manner (which is rare). The reason this is released for RHEL 3 only, is that an update was made available for RHEL 3 for other reasons, and this bug fix just happened to be included along with the quarterly updated for RHEL 3. Technically the bug is against FC1, and I'd marked it as "RAWHIDE" above, which at the time meant "Fixed in rawhide, and also will be present in any future erratum released for FC1". That still holds true now, however this bug alone is not enough reason to release an erratum for FC1. Rest assured however that there will be further updates for FC1 made available in the future which will include this bug fix and all others, however RHEL3 errata and FC1 errata are not necessarily released in tandem, unless they are security updates. We do not generally release updates for software for FC except for security reasons, so you should see this fix in the next security update for FC1. If you require the fix immediately, I can make rpm packages available to you on people.redhat.com for FC1, however there are no plans to release official FC1 erratum for the time being, unless there are security issues discovered in X which require immediate fixing and release. The 4.3.0 src.rpm will recompile for FC1 once the spec file is edited and a few macros tweaked (documented in spec file). Hope this helps.
Hi Mike, oh, that's fine with me. I actually have been using the rawhide version for months, and just upgraded to FC2 with no trouble. But I have a question about "future updates for FC1". Is there any rule or policy about for how long updates for the previous FC are going to be produced, after the new release is out? Couldn't find it anywhere.
Oops. Should have looked at the FC FAQ. Two to three months, it seems.