Bug 125390 - K8V *SE* Deluxe/AGP Bridge conflict with FC2 graphics on boot
K8V *SE* Deluxe/AGP Bridge conflict with FC2 graphics on boot
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-06-05 18:50 EDT by Rory Gleeson
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-06 17:36:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rory Gleeson 2004-06-05 18:50:25 EDT
Motherboard: K8V *SE* Deluxe 
CPU: AMD Athlon 64 3000 
Video card: ATI 9200 se 128mb 
Description of problem: 
After installing either the i386 or x86_64 versions of FC2 and 
booting for the first time, the screen goes awash in various colours 
at the graphical hand-off (just after you see the "Fedora - press I 
for interactive set-up" text).  So, you see Grub and then the initial 
scroll of text without issue. 
note: You can install FC2 in graphical mode.  So, everything works 
perfectly fine until you complete your install and boot in the first 
Version-Release number of selected component (if applicable): 
FC2 Final - both 32 and 64 bit versions. 
How reproducible: 
100% of time. 
In the K8V se Deluxe bios, go to: 
APG Bridge Configuation > 
APG Mode: APG 8x (default) 
Graphics Aperture Size: 64mb (default). Changing it to 128mb at 8x 
doesn't help. 
** Change APG Mode to: APG 4x and you can boot in. ** 
The issue is, with these motherboards, the default is 8x, so others 
may encounter this issue. 
Fix Required: 
Fedora 2 should be able to handle APG 8x Mode with this board. 
Rory Gleeson 
Toronto, Canada 
rory at childelfare dot ca
Comment 1 Ed Bailey 2004-06-06 10:50:42 EDT
My understanding is that X can only handle AGP 4x mode, but I'll leave
that for the X maintainer to verify...
Comment 2 Mike A. Harris 2004-06-07 12:06:47 EDT
Ed is correct, both X.Org X11, and also all releases of XFree86
only support AGP 1x, 2x, and 4x.  AGP 8x is not supported at all
on any hardware.

In order to have a properly working system, you must either set
the AGP rate to either 1x, 2x, or 4x in your system BIOS and use
that, or you must disable 3D acceleration completely by editing
your config file and commenting out the line:

    Load "dri"

Note that this is something that must be done manually, as the
X server is unaware of AGP 8x.

At a future point in time, upstream X releases may be enhanced
to support AGP 8x hardware modes, and such support will likely
be included in a future operating system release once it is
made available by X.Org.

Closing bug as "NOTABUG".
Comment 3 Rory Gleeson 2004-06-07 17:36:14 EDT
I would only add this - I have tested Mandrake 10 Official, SuSE 9.1 
FTP, Knoppix, Suse 9.0/9.1 Live and Mandrakemove with this same 
system in the past week.   
None choked on AGP 8x.  Only Fedora i386 and Fedora X86_64 had 
Comment 4 Rory Gleeson 2004-06-08 16:31:25 EDT
I guess no follow-up to my previous post?  I recognize this was very 
quickly closed as "NotABug."  However, it clearly is a bug with this 
mobo, which is a widely used one.   
Mike Harris wrote: 
"In order to have a properly working system, you must either set 
the AGP rate to either 1x, 2x, or 4x in your system BIOS and use 
that, or you must disable 3D acceleration completely by editing 
your config file and commenting out the line:" 
Please note, the above comment must only apply to Fedora, as the 8x 
APG setting in Mandrake, SuSE, Knoppix and Debian Sarge, which I 
tested last night, may not be supported (I'll assume you're correct) 
but in all the above distros, this setting doesn't cause a graphics 
waashout on boot-up. So, a workaround in Fedora, like the other 
distros I've tested, might be of value. 
Closing it as "notabug" so quickly was premature, I believe. 
Comment 6 Dave Jones 2004-06-08 19:27:57 EDT
At a guess, the other distros aren't loading the AGP / DRI modules.
Comment 7 Arjan van de Ven 2004-06-09 02:03:28 EDT
all distros load AGP on amd64 (for the iommu)
Comment 8 Dave Jones 2004-06-09 07:36:51 EDT
good point. DRI may still be not loaded/enabled though, in which case
the AGPGART drivers won't be used. (The IOMMU just shares some
variables with AGPGART, but doesn't actually use its code).
Comment 9 Alan Cox 2004-06-19 07:45:47 EDT
In part this would be an X bug for not switching down to 4x, and in
the other part if it can't do that its an X bug for not reading the
PCI config bits on the AGP bridge and avoiding loading DRI/printing a

On my Athlon64 AGP is set to 8x and X is fine however (although
clearly not using
AGP 8x) - however the card is not AGP 8x capable (Radeon 9000Pro)
Comment 10 Rory Gleeson 2004-06-19 11:38:21 EDT
"In my Athlon64 AGP is set to 8x and X is fine however (although
clearly not using AGP 8x) - however the card is not AGP 8x capable
(Radeon 9000Pro)"

Ahh, and that's the nexus, as my Radeon 9200SE is 8x compatible. So,
possibly we'll be seeing this issue more at people's hardware becomes
more current.  You don't have an 8x card you could throw in to test,
do you?  If it's an X bug, how do you think other X-based distros are
working around it?
Comment 11 Mike A. Harris 2004-06-23 04:23:09 EDT
I have a Radeon 9200 Pro, but not SE.  I assume the problem is the
same with any AGP 8x card though.  I don't have your motherboard,
but I have an AMD Solo motherboard with AGP 8x.

I agree with Alan that if X can't handle AGP 8x, it should switch
to AGP 4x, and that it could be considered a bug if it does not.

>If it's an X bug, how do you think other X-based distros are
>working around it?

While I could make guesses, I'd rather just examine their source
code and see what if anything they're doing differently. If they
are patching X, it would be trivial for me to review the patches
for inclusion in our X as well, and save a lot of time over trying
to reinvent the wheel.  ;o)

If they're not patching X to work around this however, if the
problem doesn't occur on the other distro, it would imply they were
working around the issue in the kernel or elsewhere (intentionally,
or unintentionally).

What distro version/release have you tested which seems to work ok?

If possible, can you attach your kernel 'messages' log and X server
startup log from that distro, and let me know which version-release
of X they are using?  If you can supply that information, I can
examine it to determine how their kernel and X startup differs from
ours, and then to download their sources and hunt for patches.

Thanks in advance.
Comment 12 Rory Gleeson 2004-06-24 09:07:15 EDT

Mandrake and SuSE 9.1 x86_64 and SuSE x86 all boot in fine.  I'm
almost positive I tried it with Debian, too, but my memory is getting
foggy. LiveCDs work too - MandrakeMove 9.2, MandrakeMove2 snapshot,
Knoppix, SuSE Live 9.0 and SuSE Live 9.1.  I've tried a couple of
other things but don't have them to reference right now.  

I dumped SuSE 64 off my other drive yesterday and switched back to
SuSE 32, with Fedora still going  strong on my other drive.  (By the
way, Fedora is much snappier than SuSE 9.1 32/64, although Mandrake
beats them both.)

Can you point me the gereral direction of where I would find the
kernel 'messages' log and X server start-up log to post for you?  

By the way, I've also enabled/disabled 3D in both versions of SuSE and
it's make no difference on boot.

Comment 13 Mike A. Harris 2005-03-06 17:36:08 EST
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:


If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".

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