About half the time the radeon driver released in the Fedora rpm xorg-x11-6.8.2-37.FC4.49.2.x86_64.rpm fails to start properly. The screen us usually blank or a rather pretty pattern of blue and/or red dots with a small square of colored vertical stripes in the center. The keyboard and mouse appear not to be functioning. If the driver starts properly, it continues to run OK. The earlier rpm: xorg-x11-6.8.2-37.FC4.45.x86_64.rpm seems to run the radeon driver OK (though I haven't tested it heavily yet.) The bug is erratic, and seems to depend on the kernel version, on whether it's a cold boot or a restart, the room temperature, etc. The vesa driver runs OK in all recent releases. My hardware is: CPU: AMD Athlon(tm) 64 Processor 3000+ running at 2 GHz (in 64-bit mode) Video Card: Sapphire Card running ATI RV280 [Radeon 9200] Motherboard: Asus K8N-E Deluxe with NVIDIA chipset The kernel is: 2.6.13-1.1525_FC4 and some other recent Fedora Core 4 kernels.
what kind of monitor do you have? Is it DVI or analog input?
The monitor is a BENQ FP731, which is a flat panel display, 1280x1024 pixels, analog input.
(In reply to comment #2) > The monitor is a BENQ FP731, which is a flat panel display, 1280x1024 pixels, > analog input. I have had analogous behaviour with my FC4 i386 system - reported at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169637 My monitor is a Hitachi CM615 CRT screen, analogue input. Mike
The problem has continued in FC5. I had got around the problem by using an older release of the Xorg system, namely *-6.8.2, but this probably won't be possible with FC5, since the libraries and mosule locations have been changed. At present the Xorg server hardly ever starts, unless I press the <Enter> key repeatedly when the server is starting up initially in the boot process, and again after the boot process just before the login screen is supposed to appear. If I do this, the system will boot about 2/3 of the time. This makes me suspect that there is supposed to be some kind of a delay in the start up process, which isn't quite long enough, and that pressing return keeps some system component busy long enough for the board to initialize.
If this still happens with current FC5, please provide the version of the ati driver package it has.
Sorry to take so long on this. The radeon driver is as broken as ever. I am currently using the xorg-x11-drv-fglrx-8.24.8-1.lvn5 driver from the Livna archive (successfully -- no problems). Here is the output of: $ rpm -qil xorg-x11-drv-ati Name : xorg-x11-drv-ati Relocations: (not relocatable) Version : 6.5.7.3 Vendor: Red Hat, Inc. Release : 4 Build Date: Tue Feb 21 05:50:25 2006 Install Date: Sat Mar 25 06:18:48 2006 Build Host: hs20-bc1-6.build.redhat.com Group : User Interface/X Hardware Support Source RPM: xorg-x11-drv-ati-6.5.7.3-4.src.rpm Size : 800481 License: MIT/X11 Signature : DSA/SHA1, Mon Mar 6 15:51:04 2006, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.x.org Summary : Xorg X11 ati video driver Description : X.Org X11 ati video driver. /usr/lib64/xorg/modules /usr/lib64/xorg/modules/drivers /usr/lib64/xorg/modules/drivers/ati_drv.so /usr/lib64/xorg/modules/drivers/atimisc_drv.so /usr/lib64/xorg/modules/drivers/r128_drv.so /usr/lib64/xorg/modules/drivers/radeon_drv.so /usr/lib64/xorg/modules/multimedia /usr/lib64/xorg/modules/multimedia/theatre200_drv.so /usr/lib64/xorg/modules/multimedia/theatre_detect_drv.so /usr/lib64/xorg/modules/multimedia/theatre_drv.so /usr/share/hwdata/videoaliases/ati.xinf /usr/share/hwdata/videoaliases/r128.xinf /usr/share/hwdata/videoaliases/radeon.xinf /usr/share/man/man4/ati.4.gz /usr/share/man/man4/r128.4.gz /usr/share/man/man4/radeon.4.gz
6.5.7.3 is still the version that shipped with X.Org 7.0; 6.5.8 has a lot of stability fixes. If that doesn't help (or if you can't test it), please try with the DRI disabled and attach (as opposed to paste) the full X config and log files.
Ping!
Closing due to the lack of activity from the bug poster.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.