i'm using MESA, drm and xorg xservre from CVS HEAD with aiglx support enabled, also xf86-video-ati from CVS HEAD. I'm getting this error when i run glxinfo: libGL warning: 3D driver claims to not support visual 0x4b libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/diego/.drirc: No such file or directory. Error: Unsupported depth 0... exiting A few weeks ago this didn't happend and i could at least run glxgears. Now even glxgears does not run. This is what i'm seeing in the glxgears case (don't know if it is related). libGL warning: 3D driver claims to not support visual 0x4b libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/diego/.drirc: No such file or directory. *********************************WARN_ONCE********************************* File r300_ioctl.c function r300Clear line 555 CB_DPATH has been enabled. Please let me know if this introduces new instabilities. *************************************************************************** drmRadeonCmdBuffer: -22 (exiting)
Created attachment 4909 [details] Xorg.0.log output
Created attachment 4910 [details] Kernel output
i forgot to say the graphics card i'm using: The computer is a Dell d610 with an ATI radeon. lspci says: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300]
*** Bug 6313 has been marked as a duplicate of this bug. ***
Created attachment 4996 [details] [review] Workaround? This patch makes things work for me with r200, but it may just be a workaround. The problem seems related to the 32 bit visual that AIGLX exports for GLX compositing managers.
i just compiled Mesa with this patch. glxinfo works, however glxgears still aborts, here are the mesages: running glxgears, on the console i can read: libGL warning: 3D driver claims to not support visual 0x4b libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/diego/.drirc: No such file or directory. *********************************WARN_ONCE********************************* File r300_ioctl.c function r300Clear line 555 CB_DPATH has been enabled. Please let me know if this introduces new instabilities. *************************************************************************** drmRadeonCmdBuffer: -22 (exiting) /var/log/kern.log contains: Mar 22 01:44:15 calisto kernel: [drm] Setting GART location based on new memory map Mar 22 01:44:15 calisto kernel: [drm] Loading R300 Microcode Mar 22 01:44:15 calisto kernel: [drm] writeback test succeeded in 1 usecs Mar 22 01:44:47 calisto kernel: [drm] Setting GART location based on new memory map Mar 22 01:44:47 calisto kernel: [drm] Loading R300 Microcode Mar 22 01:44:47 calisto kernel: [drm] writeback test succeeded in 1 usecs Mar 22 01:45:51 calisto kernel: [drm] Loading R300 Microcode Mar 22 01:46:50 calisto kernel: [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_V Mar 22 01:46:50 calisto kernel: [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed Mar 22 01:46:50 calisto kernel: [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed
(In reply to comment #6) > i just compiled Mesa with this patch. glxinfo works, however glxgears still > aborts, here are the mesages: > > running glxgears, on the console i can read: > libGL warning: 3D driver claims to not support visual 0x4b > libGL error: > Can't open configuration file /etc/drirc: No such file or directory. > libGL error: > Can't open configuration file /home/diego/.drirc: No such file or directory. > *********************************WARN_ONCE********************************* > File r300_ioctl.c function r300Clear line 555 > CB_DPATH has been enabled. > Please let me know if this introduces new instabilities. > *************************************************************************** > drmRadeonCmdBuffer: -22 (exiting) > > /var/log/kern.log contains: > > Mar 22 01:44:15 calisto kernel: [drm] Setting GART location based on new memory map > Mar 22 01:44:15 calisto kernel: [drm] Loading R300 Microcode > Mar 22 01:44:15 calisto kernel: [drm] writeback test succeeded in 1 usecs > Mar 22 01:44:47 calisto kernel: [drm] Setting GART location based on new memory map > Mar 22 01:44:47 calisto kernel: [drm] Loading R300 Microcode > Mar 22 01:44:47 calisto kernel: [drm] writeback test succeeded in 1 usecs > Mar 22 01:45:51 calisto kernel: [drm] Loading R300 Microcode > Mar 22 01:46:50 calisto kernel: [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset > failed range check (k=0 i=2) while processing 3D_LOAD_V > Mar 22 01:46:50 calisto kernel: [drm:r300_emit_packet3] *ERROR* > r300_emit_raw_packet3 failed > Mar 22 01:46:50 calisto kernel: [drm:r300_do_cp_cmdbuf] *ERROR* > r300_emit_packet3 failed Sounds like ddx and drm dont agree on where gart is. You should probably take a look at that offset and compaire it against other values to see what part gets it wrong. See http://marc.theaimsgroup.com/?l=dri-devel&m=114215352914192&w=2
ok, these are the values i get. I don't know what should i do with them ... Linux Kernel (kern.log) Mar 22 02:55:32 calisto kernel: [drm] Setting GART location based on new memory map Mar 22 02:55:32 calisto kernel: [drm:radeon_do_init_cp] dev_priv->gart_size 8388608 Mar 22 02:55:32 calisto kernel: [drm:radeon_do_init_cp] dev_priv->gart_vm_start 0xd4000000 Mar 22 02:55:32 calisto kernel: [drm:radeon_do_init_cp] dev_priv->gart_buffers_offset 0xd4102000 Mar 22 02:55:32 calisto kernel: [drm:radeon_do_init_cp] Setting phys_pci_gart to f8d70000 03FF8000 Mar 22 02:55:32 calisto kernel: [drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM D3FF8000 mapped at F8D70000 X Window server (/var/log/X.org) (II) RADEON(0): Will use 32 kb for PCI GART table at offset 0x3ff8000 (II) RADEON(0): Will use 47104 kb for textures at offset 0x11f6000
ping? I just compiled drm, xf86-video-ati, xserver and MESA from CVS HEAD same problem, same nubmers from the logs. If you need any more information just tell me. If i should redirect my bug to some other place please tell me were. No 3d application works since 1 month ago. Not even glxgears runs! Thanks
(In reply to comment #9) > ping? > > I just compiled drm, xf86-video-ati, xserver and MESA from CVS HEAD > > same problem, same nubmers from the logs. > > If you need any more information just tell me. > If i should redirect my bug to some other place please tell me were. > > No 3d application works since 1 month ago. Not even glxgears runs! And what was the failing offset? RCS file: /cvs/dri/drm/shared-core/r300_cmdbuf.c,v retrieving revision 1.12 diff -u -b -B -u -r1.12 r300_cmdbuf.c --- r300_cmdbuf.c 7 Mar 2006 01:08:35 -0000 1.12 +++ r300_cmdbuf.c 2 Apr 2006 16:00:20 -0000 @@ -257,6 +257,8 @@ if (offset >= dev_priv->gart_vm_start && offset < (dev_priv->gart_vm_start + dev_priv->gart_size)) return 0; + + DRM_ERROR("offset %08x fails\n", offset); return 1; } Try this also: RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v retrieving revision 1.92 diff -u -b -B -u -r1.92 r300_context.h --- r300_context.h 29 Mar 2006 15:21:01 -0000 1.92 +++ r300_context.h 2 Apr 2006 16:02:09 -0000 @@ -49,9 +49,9 @@ /* PPC doesnt support 16 bit elts ... */ #ifndef MESA_BIG_ENDIAN -#define USER_BUFFERS -#define RADEON_VTXFMT_A -#define HW_VBOS +//#define USER_BUFFERS +//#define RADEON_VTXFMT_A +//#define HW_VBOS #endif
ok, after applying the first patch and running glxgears the offset where the error appers is: 00301fff . If i apply the second patch glxgears works again.
I've tracked this down last night, but not had time to fix it, there is some stupid code in the client side driver that works out the offset by reading card registers, this isn't going to work at all for PCI Express and you have to write registers to read the GART base address, so I'm going to need to do some work in the DRM.
Fixed in Mesa CVS now... the client gets the offset from the kernel instead of trying to be smart and getting it from the register map..
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.