Radeon X700 Pro can no longer do AGP 8X since commit 295823d0879a

Sean seanlkml at sympatico.ca
Fri Sep 14 01:06:14 PDT 2007

On Thu, 13 Sep 2007 21:12:08 +0200
Michel Dänzer <michel at tungstengraphics.com> wrote:

Hey Michel,

Thanks for taking some time to look at this.

> > A naive reading of the commit suggested that the card was not being
> > detected as AGP version 3.  
> That is correct, based on the capabilities reported by the kernel
> agpgart module and the card's AGP_STATUS register. I don't see how the
> detection could be different before and after this change...

Looks like you're right, this change only affected what was reported
in the xorg log.  According to dmesg, AGP was set to 4x in both cases.

> > Adding a quick hack to force "is_v3" to true, allowed 8X mode to be set by 
> > the latest driver.
> Does agpgart actually set 8x though according to dmesg?

Well, i hadn't thought to check that.  With both 6.6.3 and 6.7.192 it
shows as 4x.  However with 6.7.192 plus the hack forcing "is_v3" to
true, the kernel reports success:

  agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
  agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
  agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

So the question becomes, why does the driver decide v3 is not available,
when the kernel and lspci both see otherwise?   Adding a debug display
after the line in radeon_dri.c where it queries the value:

  CARD32 agp_status = INREG(RADEON_AGP_STATUS) & mode;

INREG(RADEON_AGP_STATUS) resolves to 0x4a0, and mode to 0x1f004a1b;
so agp_status will always be 0, and is_v3 always false.

Couldn't find any info on what the mode bits actually mean, but from the
AGP3 spec it appears the AGP_STATUS should never have bit 7 set like it does
here.  But beyond that i'm stumped.


More information about the xorg mailing list