Bug 125390

My understanding is that X can only handle AGP 4x mode, but I'll leave
that for the X maintainer to verify...

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".

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 
difficulty.   
 
Rory 

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. 

At a guess, the other distros aren't loading the AGP / DRI modules.

all distros load AGP on amd64 (for the iommu)

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).

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
warning.

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)

"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?

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.

Mike,

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.

Rory

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:

        http://fedora.redhat.com/download

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"
component.

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".