[discuss] [PATCH] [1/7] x86_64: Disable aperture pci region check in amd64 AGP driver

sean darcy seandarcy2 at gmail.com
Mon May 15 02:44:45 CEST 2006


On 5/9/06, Dave Jones <davej at redhat.com> wrote:
> On Sun, May 07, 2006 at 09:04:15AM -0400, sean darcy wrote:
>
>  > I'm running fc5, with the updates. If I apply the patch, X will not
>  > start - the machine hangs ( at least from the keyboad - I can ssh in )
>  > and top shows X taking 99+% of cpu.
>  >
>  > There are also the mtrr error messages - which may have something to
>  > do with it??
>  >
>  > In any case, I've reverted the patch on my machine so X will start,
>  > albeit without agp. I'm concerned that if the patch is in the kernel,
>  > you'll have those with the chipset suddenly without X.
>  >
>  > While I see your point that the aperture looks Ok from dmesg, and that
>  > this may have uncovered a bug in agp or dri, including it in the
>  > kernel going to surprise some people :). At present, the kernel and X
>  > muddle through. I'd suggest that this fix is only included if the agp
>  > or dri bug is also fixed.
>  >
>  > I'm happy to try whatever might help my betters who actually know how
>  > all this really works :)
>
> What video driver are you using ?
>
>                 Dave
> --



i've been messing around some more. I've built rc4 with git1. Applied
Andi Kleen's patch. No kernel boot parameters.

dmesg looks ok:

.........
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Checking aperture...
CPU 0: aperture @ f0000000 size 32 MB
Aperture from northbridge cpu 0 too small (32 MB)
AGP bridge at 00:00:00
Aperture from AGP @ f0000000 size 4096 MB (APSIZE 0)
Aperture from AGP bridge too small (0 MB)
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 4000000
Built 1 zonelists
Kernel command line: root=/dev/hda5 vga=791 video=vesafb
..................
agpgart: Detected AGP bridge 0
agpgart: Setting up Nforce3 AGP.
agpgart: AGP aperture is 64M @ 0x4000000
.................
Linux agpgart interface v0.101 (c) Dave Jones
[drm] Initialized drm 1.0.1 20051102
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC5] -> GSI 16 (level,
low) -> IRQ 177
mtrr: type mismatch for 4000000,4000000 old: write-back new: write-combining
[drm] Initialized radeon 1.24.0 20060225 on minor 0
[drm] Initialized radeon 1.24.0 20060225 on minor 1
.............................

But when I startx, I hear the click of the monitor going into graphic
mode, then I get the no signal message on the monitor.

I can ssh into the machine. top shows X at 99.9%.  Xorg.0.log looks fine:

.....
(--) Chipset ATI Radeon 8500 AIW BB (AGP) found......
.....................
(II) Reloading /usr/lib64/xorg/modules/drivers/radeon_drv.so
......................
(==) RADEON(0): Using XAA acceleration architecture
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/lib64/xorg/modules/libxaa.so
(II) Module xaa: vendor="X.Org Foundation"
	compiled for 7.0.0, module version = 1.2.0
	ABI class: X.Org Video Driver, version 0.8
(**) RADEON(0): AGP 4x mode is configured
(**) RADEON(0): Enabling AGP Fast Write
.......................
(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0x10003000
(II) RADEON(0): [drm] mapped SAREA 0x10003000 to 0x2b4d6203e000
(II) RADEON(0): [drm] framebuffer handle = 0xe8000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [agp] Mode 0x1f000217 [AGP 0x10de/0x00e1; Card 0x1002/0x4242]
(II) RADEON(0): [agp] 8192 kB allocated with handle 0x00000001
(II) RADEON(0): [agp] ring handle = 0x04000000
(II) RADEON(0): [agp] Ring mapped at 0x2b4d62040000
(II) RADEON(0): [agp] ring read ptr handle = 0x04101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0x2b4d62141000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0x04102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2b4d62142000
(II) RADEON(0): [agp] GART texture map handle = 0x04302000
(II) RADEON(0): [agp] GART Texture map mapped at 0x2b4d62342000
(II) RADEON(0): [drm] register handle = 0xf4000000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): Depth moves disabled by default
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 8 MB GART aperture
(II) RADEON(0): Using 1 MB for the ring buffer
(II) RADEON(0): Using 2 MB for vertex/indirect buffers
(II) RADEON(0): Using 5 MB for GART textures
(II) RADEON(0): Memory manager initialized to (0,0) (1280,8191)
(II) RADEON(0): Reserved area from (0,1024) to (1280,1026)
(II) RADEON(0): Largest offscreen area available: 1280 x 7165
(II) RADEON(0): Will use back buffer at offset 0x1400000
(II) RADEON(0): Will use depth buffer at offset 0x1900000
(II) RADEON(0): Will use 34816 kb for textures at offset 0x1e00000
(II) RADEON(0): Render acceleration enabled
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
.........................
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 177
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 5111808
(II) RADEON(0): Direct rendering enabled
(==) RandR enabled
....................


The only error reported was in syslog:
May 14 18:02:15 localhost kernel: agpgart: Found an AGP 2.0 compliant
device at 0000:00:00.0.
May 14 18:02:15 localhost kernel: agpgart: Putting AGP V2 device at
0000:00:00.0 into 4x mode
May 14 18:02:15 localhost kernel: agpgart: Putting AGP V2 device at
0000:01:00.0 into 4x mode
May 14 18:02:17 localhost kernel: [drm] Setting GART location based on
old memory map
May 14 18:02:17 localhost kernel: [drm] Loading R200 Microcode
May 14 18:02:17 localhost kernel: [drm] writeback test failed


I also built 2.6.17-rc4 without the patch. agp was disabled and X started.

FWIW:
lspci
00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb
AC'97 Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller
(v2.5) (rev a2)
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller
(v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI
Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc R200 BB
[Radeon All in Wonder 8500DV]
01:00.1 PCI bridge: ATI Technologies Inc R200 BC [Radeon All in Wonder 8500]
02:00.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 04)
03:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001
Gigabit Ethernet Controller (rev 13)

Here's the Device sectio from xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "radeon"
        VendorName  "ATI"
        BoardName   "ATI Radeon 8500AIW"
#       Option      "AGPFastWrite"   "yes"
#       Option      "AGPMode"        "4"
#       Option      "EnablePageFlip" "yes"
#       Option      "RenderAccel"    "yes"
#       Option      "AccelMethod"    "exa"

I've tried it both with and without the various options.


Note all this is without any iommu command line parameters.

I'd really love to get this fixed, but I sure think it's a bad idea to
apply the patch to the production kernel.

I think Andi Kleen is probably right: it's covering up some other bug.
But it would be a real pain if someone with this board ( me ) couldn't
get X up.

Thanks for looking at this.

sean



More information about the discuss mailing list