|Summary:||VESA driver doesn't work|
|Product:||[Fedora] Fedora||Reporter:||Bill Nottingham <notting>|
|Component:||xorg-x11||Assignee:||X/OpenGL Maintenance List <xgl-maint>|
|Status:||CLOSED UPSTREAM||QA Contact:|
|Version:||3||CC:||alan, davej, jws, keith, riel, rvokal, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-04-11 22:57:05 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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 kernel). Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21
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] X.org 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 difference.
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 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-184.108.40.2063-2.x86_64.rpm 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
220.127.116.113-2 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 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.
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. :) https://bugs.freedesktop.org/show_bug.cgi?id=2982
Comment 29 Mike A. Harris 2005-04-11 22:57:05 UTC
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 "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.
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 properly. 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. Thanks.