After installing latest x11-drm snapshot, I did get following messages in kernel log and glx-using apps didn't work at all: [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed Then I tried upgrading to both x11-drm and Mesa CVS to get things working again. Also, x11-drm installs drivers to /lib/modules/${kernelversion}/x11-drm directory. This means when the in-kernel drm modules are also compiled, the new modules won't get picked up.
I can confirm this. There is even an upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=6241 I don't see how the kernel module path is related to this, though. Maybe the x11-drm ebuild could check if the current kernel has drm compiled in/as module and bail out if it does? ieee80211 does a similar thing.
Also happens with sys-kernel/gentoo-sources-2.6.17-r3
I'd appreciate it if someone could track down the patch that went into CVS to fix this issue.
I think it is this one: --- radeon_screen.c.1.59 2006-07-21 21:00:59.000000000 +1000 +++ radeon_screen.c.1.60 2006-07-21 21:00:45.000000000 +1000 @@ -351,8 +351,6 @@ return NULL; } - if (sPriv->drmMinor >= 6) { - ret = radeonGetParam( sPriv->fd, RADEON_PARAM_GART_BASE, &screen->gart_base); if (ret) { @@ -375,7 +373,6 @@ screen->drmSupportsPointSprites = (sPriv->drmMinor >= 13); screen->drmSupportsCubeMapsR100 = (sPriv->drmMinor >= 15); } - } screen->mmio.handle = dri_priv->registerHandle; screen->mmio.size = dri_priv->registerSize; @@ -428,9 +425,7 @@ return NULL; } - screen->gart_texture_offset = dri_priv->gartTexOffset + (( screen->card_type == RADEON_CARD_PCI) - ? INREG( RADEON_AIC_LO_ADDR ) - : ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0x0ffffU ) << 16 ) ); + screen->gart_texture_offset = dri_priv->gartTexOffset + screen->gart_base; } screen->chip_flags = 0; @@ -979,12 +974,12 @@ static const char *driver_name = "Radeon"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; static const __DRIversion dri_expected = { 4, 0, 0 }; - static const __DRIversion drm_expected = { 1, 3, 0 }; + static const __DRIversion drm_expected = { 1, 6, 0 }; #elif RADEON_COMMON && defined(RADEON_COMMON_FOR_R200) static const char *driver_name = "R200"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; static const __DRIversion dri_expected = { 4, 0, 0 }; - static const __DRIversion drm_expected = { 1, 5, 0 }; + static const __DRIversion drm_expected = { 1, 6, 0 }; #elif RADEON_COMMON && defined(RADEON_COMMON_FOR_R300) static const char *driver_name = "R300"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; The file is /Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c And the comment in cvs is "use gart base from drm not try to work it out ourselves.. bump radeon client to need 1.6 drm where this first appeared.. this fixes r300 on PCIE" It is the only commit of Dave Airlie on that day that mentions PCIE. Hope that helps.
Could someone try that patch and see if it helps?
I had to tweak the patch a bit so that it applies cleanly: --- src/mesa/drivers/dri/radeon/radeon_screen.c +++ src/mesa/drivers/dri/radeon/radeon_screen.c @@ -343,7 +343,6 @@ return NULL; } - if (sPriv->drmMinor >= 6) { gp.param = RADEON_PARAM_GART_BASE; gp.value = &screen->gart_base; @@ -371,7 +370,6 @@ screen->drmSupportsFragShader = (sPriv->drmMinor >= 18); screen->drmSupportsPointSprites = (sPriv->drmMinor >= 13); screen->drmSupportsCubeMapsR100 = (sPriv->drmMinor >= 15); - } } screen->mmio.handle = dri_priv->registerHandle; @@ -425,9 +423,7 @@ return NULL; } - screen->gart_texture_offset = dri_priv->gartTexOffset + ( screen->IsPCI - ? INREG( RADEON_AIC_LO_ADDR ) - : ( ( INREG( RADEON_MC_AGP_LOCATION ) & 0x0ffffU ) << 16 ) ); + screen->gart_texture_offset = dri_priv->gartTexOffset + screen->gart_base; } screen->chip_flags = 0; @@ -976,12 +972,12 @@ static const char *driver_name = "Radeon"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; static const __DRIversion dri_expected = { 4, 0, 0 }; - static const __DRIversion drm_expected = { 1, 3, 0 }; + static const __DRIversion drm_expected = { 1, 6, 0 }; #elif RADEON_COMMON && defined(RADEON_COMMON_FOR_R200) static const char *driver_name = "R200"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; static const __DRIversion dri_expected = { 4, 0, 0 }; - static const __DRIversion drm_expected = { 1, 5, 0 }; + static const __DRIversion drm_expected = { 1, 6, 0 }; #elif RADEON_COMMON && defined(RADEON_COMMON_FOR_R300) static const char *driver_name = "R300"; static const __DRIutilversion2 ddx_expected = { 4, 5, 0, 0 }; The functionality should be identical. The code now cleanly compiles and the bug described above is gone, i.e. glxgears starts fine. I am no expert in mesa, though, so I wouldn't know if it is a proper fix.
Alright, thanks Jochen. This has been added in r4. Priit, let me know if mesa-6.5-r4 fixes this problem for you too.
Looks good! Thanks Jochen and Joshua :)
