DRM + agp_ati + -CURRENT...

As of yesterday morning, my HP Laptop, with a Mobility RS100 Radeon, is 
running -CURRENT.  Unfortunately, I seem to be having problems with 
Direct Rendering.

When I boot up, the agp driver is loaded properly:

agp0: <ATI RS100 AGP bridge> on hostb0

When I launch X, the drm and radeon modules are loaded:

drm0: <ATI Radeon RS100 Mobility U1> on vgapci0
info: [drm] AGP at 0xd4000000 64MB
info: [drm] Initialized radeon 1.19.0 20050911

According to the X server, Direct Rendering is enabled:

(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:05.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xc3ce7000
(II) RADEON(0): [drm] mapped SAREA 0xc3ce7000 to 0x283d3000
(II) RADEON(0): [drm] framebuffer handle = 0xe0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x0000/0x0000; Card 
0x1002/0x4336]
(II) RADEON(0): [agp] 32768 kB allocated with handle 0xc381f700
(II) RADEON(0): [agp] ring handle = 0xd4000000
(II) RADEON(0): [agp] Ring mapped at 0x2c433000
(II) RADEON(0): [agp] ring read ptr handle = 0xd4101000
(II) RADEON(0): [agp] Ring read ptr mapped at 0x282df000
(II) RADEON(0): [agp] vertex/indirect buffers handle = 0xd4102000
(II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x2c534000
(II) RADEON(0): [agp] GART texture map handle = 0xd4302000
(II) RADEON(0): [agp] GART Texture map mapped at 0x2c734000
(II) RADEON(0): [drm] register handle = 0xd0100000
(II) RADEON(0): [dri] Visual configs initialized
(II) RADEON(0): CP in BM mode
(II) RADEON(0): Using 32 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 29 MB for GART textures
<snip>
(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 9
(II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416
(II) RADEON(0): Direct rendering enabled

According to glxgears, the DRI driver is being used:

name of display: scroll.netops.dci.lan:0.0
display: scroll.netops.dci.lan:0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
    GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
    GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI Radeon 20051013 AGP 4x NO-TCL
OpenGL version string: 1.3 Mesa 6.5

However, glxgears is only giving me about 1 FPS.  Most other GL 
applications (gltext, for example, from the xscreensaver package) are 
even slower.  Software Mesa is even faster.

The DRM driver is giving the following error message:

error: [drm:pid51336:drm_alloc_resource] *ERROR* Couldn't find resource 0x0

The PID changes, of course, depending on the PID of the X server, but 
the rest of the error stays the same.

What's really bizarre, however, is that if I set hw.dri.0.debug to 1, 
glxgears gets roughly 200 FPS, faster than software Mesa, but slower 
than it can get (undoubtedly due to the massive amounts of debugging 
information that the kernel is logging).

Any ideas?  Thanks!

Adam