Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 145200 - VESA driver doesn't work
Summary: VESA driver doesn't work
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
: 144550 (view as bug list)
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-01-15 06:29 UTC by Bill Nottingham
Modified: 2014-03-17 02:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-11 22:57:05 UTC

Attachments (Terms of Use)
lspci output (deleted)
2005-01-15 06:30 UTC, Bill Nottingham
no flags Details
log from 64bit VESA driver (fails) (deleted)
2005-01-15 06:32 UTC, Bill Nottingham
no flags Details
log from 32bit VESA driver (works) (deleted)
2005-01-15 06:33 UTC, Bill Nottingham
no flags Details config file (for both 32 and 64 bit) (deleted)
2005-01-15 06:33 UTC, Bill Nottingham
no flags Details

Description Bill Nottingham 2005-01-15 06:29:32 UTC
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):


Comment 1 Bill Nottingham 2005-01-15 06:30:00 UTC
Created attachment 109813 [details]
lspci output

Comment 2 Bill Nottingham 2005-01-15 06:32:33 UTC
Created attachment 109814 [details]
log from 64bit VESA driver (fails)

Comment 3 Bill Nottingham 2005-01-15 06:33:26 UTC
Created attachment 109815 [details]
log from 32bit VESA driver (works)

Comment 4 Bill Nottingham 2005-01-15 06:33:53 UTC
Created attachment 109816 [details] config file (for both 32 and 64 bit)

Comment 5 Mike A. Harris 2005-01-15 06:41:06 UTC
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.

Comment 6 Mike A. Harris 2005-01-15 06:42:59 UTC
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

Comment 7 Warren Togami 2005-01-16 20:42:29 UTC
Is Bug 144550 the same issue?

Comment 8 Bill Nottingham 2005-01-17 03:28:27 UTC
Appears so, feel free to dup one way or another.

Comment 9 Warren Togami 2005-01-17 03:31:15 UTC
*** Bug 144550 has been marked as a duplicate of this bug. ***

Comment 10 Bill Nottingham 2005-01-17 04:00:17 UTC
24bpp doesn't change the results/logs any.

Comment 11 Jeff Schultz 2005-01-17 05:08:58 UTC
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.

Comment 12 Mike A. Harris 2005-01-17 07:16:58 UTC
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.

Comment 13 David Snyderman 2005-01-19 14:14:12 UTC
I think this bug is a duplicate of-- or at least related to-- Bug 138825.

Comment 14 Mike A. Harris 2005-02-01 00:17:50 UTC
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.

Comment 16 Jeff Schultz 2005-02-01 09:56:36 UTC
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

and friends?

Comment 17 Mike A. Harris 2005-02-01 10:22:41 UTC
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.

Comment 18 Bill Nottingham 2005-02-02 03:54:21 UTC behaves identical to 6.8.1.

Comment 19 Mike A. Harris 2005-03-06 17:31:08 UTC
Does 6.8.2 change things at all?

Comment 20 Bill Nottingham 2005-03-09 04:21:15 UTC

Comment 22 Mike A. Harris 2005-03-22 13:25:32 UTC
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.

Comment 23 Bill Nottingham 2005-03-23 03:43:52 UTC
MSI K8MM-ILSR motherboard, Athlon64 3400+. As stated before, K8M800 chipset.

Comment 24 Jeff Schultz 2005-03-23 09:29:03 UTC
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"

Comment 25 Mike A. Harris 2005-04-11 02:20:00 UTC
Please report this problem in the X.Org bugzilla located at 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.

Comment 27 Mike A. Harris 2005-04-11 02:23:10 UTC
Setting status to "NEEDINFO", awaiting upstream bug report URL.

Comment 28 Bill Nottingham 2005-04-11 19:52:44 UTC
xorg-bugzilla-noise. Nice, good way to make it look like it will get looked at. :)

Comment 29 Mike A. Harris 2005-04-11 22:57:05 UTC
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
"" now, utilizing our administrative superpowers
to force our will onto all that read X bug reports. ;o)

Setting status to "UPSTREAM" for tracking.

Comment 30 Keith Distin 2005-04-15 08:53:11 UTC
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!

Comment 31 Keith Distin 2005-04-16 09:27:36 UTC
(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.

Comment 32 Mike A. Harris 2005-04-16 11:38:08 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.