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
Version-Release number of selected component (if applicable):
Created attachment 109813 [details]
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
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
Just to make sure I've got the right packages, do you mean
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.
22.214.171.1243-2 behaves identical to 6.8.1.
Does 6.8.2 change things at all?
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. :)
Thanks for reporting upstream. We'll track it in the upstream bugzilla
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
"email@example.com" 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
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.