Description of problem: S3 Unichrome Pro (K8M800), Athlon64. Using VESA b/c native doesn't work. The VESA driver doesn't work with a 64-bit kernel; neither the 64-bit VESA driver, nor the 32-bit VESA driver (run in a chroot). It does work on the same box with a full 32bit install (with a 32bit kernel). Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21
Created attachment 109813 [details] lspci output
Created attachment 109814 [details] log from 64bit VESA driver (fails)
Created attachment 109815 [details] log from 32bit VESA driver (works)
Created attachment 109816 [details] X.org config file (for both 32 and 64 bit)
Can you test this with older 64bit kernels, as I believe it is potentially a kernel issue, and if it's just turning up now, it might be a kernel regression. CC'ing a few kernel folk in case they're aware of anything that might have broken BIOS access lately. Note: On x86_64, VBE is done via x86emu.
Bill, can you also try using 24bit depth? The log shows 16bit depth, which is rarely used nowadays. Just like to see if that makes any difference.
Is Bug 144550 the same issue?
Appears so, feel free to dup one way or another.
*** Bug 144550 has been marked as a duplicate of this bug. ***
24bpp doesn't change the results/logs any.
Fails for all depths tried, including 8 bit. Not surprising because the xf86ExecX86int10 call in VBEGetModeInfo is yielding 0x14f instead of the desired 0x4f for every mode tried.
Now that you mention it, I think someone else reported a very similar bug already as well. If I find it, I'll crosslink the two bugs.
I think this bug is a duplicate of-- or at least related to-- Bug 138825.
This bug isn't a duplicate of bug #138825. This bug is indicating the "vesa" driver does not work properly on the system reported. This issue is believed to be a bug in the X server's 64bit PCI handling, which was recently fixed. Please update to the latest rawhide xorg-x11 packages and test the "vesa" driver on this hardware, and provide a status update of wether it works with the new xorg-x11 or not. Thanks in advance. Setting status to "NEEDINFO", awaiting testing feedback.
Will do, though I won't have console time with that machine until the weekend. Just to make sure I've got the right packages, do you mean http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/xorg-x11-6.8.1.903-2.x86_64.rpm and friends?
Yep, that is the correct location. You can alternatively adjust your yum.conf to point to rawhide, do the update with yum, then disable the yum.conf changes. Thanks in advance.
6.8.1.903-2 behaves identical to 6.8.1.
Does 6.8.2 change things at all?
No.
Bill, can you attach the details of the system in question, including brand/model of system, and any other relevant components? After we've got that, we'll see if there is a similar system in Westford that can be used for physical debugging/troubleshooting. Thanks in advance. Setting status to "NEEDINFO", awaiting hardware details and/or physical access to hardware for troubleshooting/debugging.
MSI K8MM-ILSR motherboard, Athlon64 3400+. As stated before, K8M800 chipset.
For me, it's a Gigabyte K8 Triton Series MB GA-K8VM800M, Socket 754 Chipset is VIA K8M800, and that appears to be the problem. (Pretty sure I saw the same problem reported by someone with a DFI board using it too.) AMD "Athlon64 3000"
Please report this problem in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component, as this issue appears that it will require someone to have direct physical access to the hardware, so reporting this upstream will maximize the chances that the issue will be investigated and resolved sooner. Once the issue is filed upstream, please paste the URL here and we will track the issue in the upstream bugzilla, and if fixes become available, we will review them for consideration in future updates and OS releases.
Setting status to "NEEDINFO", awaiting upstream bug report URL.
xorg-bugzilla-noise. Nice, good way to make it look like it will get looked at. :) https://bugs.freedesktop.org/show_bug.cgi?id=2982
Thanks for reporting upstream. We'll track it in the upstream bugzilla now. Yeah, xorg-bugzilla-noise was named by someone with no PR skills... ;o) On the up side of things however, your comment there acted as a catalyst to get it changed today. Adam Jackson had bugzilla admin perms, and myself GNU mailman, so we conspired together and changed the name to "xorg-team.org" now, utilizing our administrative superpowers to force our will onto all that read X bug reports. ;o) Setting status to "UPSTREAM" for tracking.
I thought I also had this bug. Using the same motherboard and cpu, the VESA driver failed. I borrowed a graphics card from another machine and installed FC3, however on rebooting the kernel wouldn't load - I got a crc error. This led me to do some hardware investigations. To cut a long story short the motherboard was incorrectly identifying my CL3 memory as CL2.5 so I changed this manually in the BIOS settings. I can now install FC3 - the generic VESA driver works - and the new installation boots properly. This may not be a bug at all!
(In reply to comment #30) Jeff has just pointed out to me that there is more than one motherboard referenced in this bug, so to clarify: I have a Gigabyte GA-K8VM800M on which I've updated the BIOS to the latest version (F5). The RAM timings are hidden in the Advanced Chipset Setup menu, which is accessed by pressing Ctrl-F1 in the main BIOS page.
This issue is being tracked in X.Org bugzilla now, please make any/all comments and status updates about the problem in the X.Org bugzilla so that developers in the community who are not using Fedora Core will see your comments. This will help ensure the highest likelyhood that a solution will present itself. Thanks.