I installed Fedora Core 2 (for x86_64) on a box with an ATI Radeon 9200 (128MB). Generic VGA operation is fine, so the install went normally, but when I booted the resulting system, the screen showed only a color herringbone pattern. Modifying the /etc/X11/xorg.conf (via booting a rescue disk) eventually proved that Depth 8 worked (even at 1600x1200), whereas higher Depth's all had major image issues (herringbone, or 2x2 or 4x4 duplication), even at 640x480. I would guess there's some code in the Radeon driver which isn't 64 bit clean. Box: AMD64 3000+ on "ASUS K8V SE Deluxe" motherboard. Monitor: Decaview V400 ("DCVe400"), which the install treated as Unknown. Xorg seems to deduce a Modeline as good as my old hand-done one, thank you guys.
Forgot to mention that /var/log/xorg.0.log looked normal. I don't think the server knew about the image corruption.
A quick look at the source found the problem [or anyway one of of the problems]. xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_common.h contains two unions which assume they know the size of "int". They should be using "INT32", as provided by "#include <X11/Xmd.h>". Dunno how many int's need to be INT32, but it's a safe transformation, in code that doesn't cast between ints and pointers.
This bug was reported by others in the Red Hat Bugzilla as #124063 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124063 but the person that Bugzilla shows as assigned to that bug, Mike A. Harris (mharris@redhat.com), prefers that the bug be tracked from here. When I investigated my box's failure, I couldn't find the usual /var/log/xorg.log. I suspect this is because the boot wasn't at the stage of wanting me to log in. Rather, the first boot into a freshly configured Fedora Core 2 wants you to click on a "Do you accept.." button. I assume the log was going to some nonstandard place. I do have an xorg.log from from X running at Depth 32. The log seems to be unaware that there is any problem. I had to power cycle out, of course, because the screen was unreadable. My comments above about INT32 turn out to be wrong. On x86_64, a Make of xorg uses sizeof(int)==4, sizeof(long)==8, sizeof(float)==4. So, "int" continues to be INT32 on that architecture. I hunted for unions but didn't find any that depended on sizeof(long). I hunted for casts of pointers to int, but haven't found any yet. I did find many casts of various ulong "Size" variables to int, but those should work, until graphics starts using more than 4 GB of RAM :-) Possibly the problem is endianness. Or maybe some bus needs 2 ints per write and is getting one int. If anyone knows of a useful debug mode, I can collect an xorg.log for them.
AMD64 is the same endian as x86. I think you're going about trying to find the problem the wrong way however, by making random guesses of what the problem is, and then hunting through the code to find instances of that problem. Kindof like taking random pills from the doctor until you find the right ones for the illness you're having. ;o) Looking at the raw facts of the problem, I would say that it is either a generic driver bug on a certain model/revision of the 9200 variant you have, or possibly even a hardware bug, but I'd lean towards some kind of driver bug which requires a fix specific to the chip you have. There are other possibilities also, but rather than guess, what is more important is to be able to reproduce the problem easily and debug it from there to find out what is going wrong and where. Configure X for a configuration that doesn't work, and then attach the config file and X server log file from that configuration as bugzilla file attachments using the link above. Also please provide the output of: "lspci -vvn". I've got an official ATI Radeon 9200 Pro here for testing/troubleshooting, but no other variants or brands. Once I've got time available, if nobody else has confirmed the issue, I can try to reproduce. It'll probably be a month or two before I'll have time to investigate though. I'll CC'd Hui Yu from ATI once I figure out the email address he uses in bugzilla, in case he might be aware of such a problem. Might be a good idea to CC some of the other Radeon developers/contributors too. Thanks Don.
Created attachment 478 [details] output of /sbin/lspci -vvn As requested, the output of /sbin/lspci -vvn
Created attachment 479 [details] Xorg.0.log while the Depth was >8, and the screen was scrambled Xorg log while the visual problem was manifesting.
Created attachment 480 [details] xorg.conf I'm using. The xorg.conf that was in use when the log was gathered, is this file, except edited to have a greater Depth. Sorry, I didn't keep a copy of the actual file itself: but this is definitely a trivial edit thereof.
Just wanted to add that this bug affects me as well. I have the exact same motherboard (ASUS K8V SE Deluxe) and gfx card (radeon 9200, not pro) The card is made by ATI, not a 3rd party like Sapphire. This bug affects both the graphical boot, as well as regular X11. It occurs both in regular fedora core 2, as well as the 64bit version of fc2. This makes me wonder about the blame on 64bit cleanliness, since with regular fc2 the proc is running in 32bit mode.
I also have this problem, and I'm also using Asus K8V motherboard. My graphics card is Gigabyte Radeon 9200. It may be a problem of cooperation of Radeon 9200 with Asus K8V. ATI has released drivers for linux which may work good, but they are only for 32-bit system. Instructions for installing them on Fedora Core 2 are here: http://www.fedoraforum.org/forum/showthread.php?t=16690&page=1&pp=15 , and the drivers are here: http://ati.com/support/drivers/linux/radeon-linux.html?type=linux&prodType=graphic&prod=productsLINUXdriver&submit.x=11&submit.y=8&submit=GO%21 . ATI says that 64-bit drivers are "under development", so I hope they will be ready in near future.
I upgraded my FC2-x86_64 to FC3-x86_64, ie xorg-x11-6.7.0-2.x86_64.rpm to xorg-x11-6.8.1-12.x86_64.rpm It's not fixed. This is getting old (literally). C'mon people.
I configured my BIOS to run the Radeon's AGP bus at 4x instead of at 8x, and the problem went away. I assume that this is a workaround, not a fix, since the card works at 8x at 8bpp. I hear (but haven't confirmed) that Suse 9 has no problem using this card at 8x. Further reports to this effect have been added to http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124063 during the recent outage of bugs.freedesktop.org.
I'm also using Asus K8V SE Deluxe motherboard, so we all seem to something in common. I tried to use "AGPMode" "4" and it worked first, xorg started. So this made a difference. However, 15 minutes later or so, the screen froze, I could move the mouse, but not kill the X server, etc... So that does not fix it completely. Just to let you know. P.S. If this is an hardware failure then all the Asus mobos seem affected, which is pretty unlikely.
Whats the status of this bug using a current version of xorg?
I'm closing this bug due to the lack of activity. If the problem still persists using a current version of xorg, please reopen.
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.