Re: X300SE PCI-E freezes
On Sun, 24 Jul 2005, Alex Deucher wrote: PCIE is not currently working. So for the moment, PCIE cards will not work. What you can try is setting up the card with the fglrx driver and getting that working then use the radeon register dump scripts in r300 cvs to dump the PCIE config and then compare that to how the regs get set up in the open drm. Attached are dumps with fglrx loaded, before X was started and after it. Card is X700 Pro. What should I be looking from the dumps? For some reason if I start X after boot with fglrx, machine hangs, but if I start X once with the xorg radeon driver, and then switch back to fglrx, it starts working. --j Found Radeon All-in-Wonder at 2:0.0 memory_aperture=0xc000 register_aperture=0xdfef DEVICE_ID(0x0f02): 0x00075e4b=.^K VENDOR_ID(0x0f00): 0x5e4b1002=^K.. Dump of PCIE indirect registers starting from 0 0x 0x1e04 0x06620663 0x0093 0x 0x 0x 0x1004 0x0010 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x1f00 0x00040100 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x400a1807 0x 0x 0x 0x 0x3b24cf74 0xdfef0f00 0x001f 0x0001 0x 0x 0x1fd2 0x 0x1fd2 0xe26a 0x0021006b 0x 0x1004 0x0010 0x 0x 0x0014 0x073c 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x0002 0x 0x0006 0x 0x 0x20212210 0x0d0e0f10 0x06080c30 0x01020305 0x 0x 0x 0x 0x 0x 0x 0x0001 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x046e0b93 0x0818010f 0x0818010f 0x0035 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x0062 0x3ab076b1 0x 0x9738 0x01d5ed08 0x84413ce0 0x0040 0x80241801 0x 0x007f 0x1efe2c80 0x 0x 0x 0x 0x0001 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x 0xDump of PLL registers starting from 0 0x 0x0a608015 0xbf00 0x003c 0x00070086 0x00070097 0x000700e0 0x000700e0 0x0003 0x 0x013f4004 0x1a00 0x0400a430 0x7ffa 0x0400a410 0x 0x 0x 0x001f1212 0x28000200 0x00e16100 0x0007 0x 0x 0x 0x 0x 0x 0x 0x 0x00081c00 0x3001 M=12 ref_div_src=0 clock 0 : N=134 post_div=7 clock 1 : N=151 post_div=7 clock 2 : N=224 post_div=7 clock 3 : N=224 post_div=7 VCLK_ECP_CNTL=0x0003 X_MPLL_REF_FB_DIV=0x013f4004 M=4 X_N=64 M_N=63 new_x_mpll_ref_fb_div is computed to be 0x00fafa41 XPLL_CNTL=0x1a00 new_xpll_cntl is computed to be 0x1a00 MPLL_CNTL=0x0400a410 new_mpll_cntl is computed to be 0x0400a410 MCLK_CNTL=0x MEM_CNTL=0x0069 BUS_CNTL=0x00fe MEM_REG1=0x00090008 MEM_REG2=0x00090008 EXT_MEM_CNTL=0x69668234 MEM_INTF_CNTL=0x003f MEM_STR_CNTL=0x001f MEM_INIT_LAT_TIMER=0xf000 COMMAND_CNTL=0x0017= 0001 0111 MEMORY_BUFFER_CNTL=0xc7ffc000 DDA_CONFIG_CNTL=0x08800720 DDA_ON_OFF_CNTL=0x30020014 GEN_RESET_CNTL=0x MEM_SDRAM_MODE_REG=0x1043
[patch drm] via unichrome improvements
Hello,
I modified some things in the VIA DRM driver to get it working properly
on my K8M800 Unichrome Pro chipset under Linux. I also got it working
on a x86_64 kernel with a 32-bit usermode system.
Could someone on this list please look through my patches and maybe
commit some things? I hope my work can be useful to others.
Below is a description of each patch. They are largely independent
of eachother. All patches are against the current CVS.
01_via_unichrome_pro
Trivial patch to make the VIA driver recognize my PCI id as
a Unichrome Pro chipset. This makes IRQ handling work properly
and avoids the kernel message
irq 201: nobody cared (try booting with the irqpoll option)
02_via_verifier_bugfix
Trivial fix to the VIA command verifier. The bug caused it to accept
some invalid commands on i386 and reject valid commands on x86_64.
03_via_mm_cleanup
Rework the FB and AGP memory management in the VIA driver so that
it no longer blindly passes kernel pointers to and from userspace.
This was a security issue on i386 and a fundamental problem with
32-bit compatibility on x86_64.
04_via_ioctl_security
Enable privilege checking on those ioctls that seem to be intended
for the X server only. Don't know if there was a particular reason
why this wasn't done before.
05_via_futex_niceabort
Avoid Oops and X server crash when something goes wrong during
DRM initialization.
06_via_compat32
Compatibility wrappers around the VIA ioctls to make it work with
a 32-bit usermode system on a x86_64 kernel.
Thanks,
Joris.
diff -urN -U 5 drm.orig/shared-core/via_map.c drm/shared-core/via_map.c
--- drm.orig/shared-core/via_map.c 2005-07-15 23:22:51.0 +0200
+++ drm/shared-core/via_map.c 2005-08-07 11:34:25.0 +0200
@@ -65,11 +65,12 @@
init-sarea_priv_offset);
dev_priv-agpAddr = init-agpAddr;
via_init_futex( dev_priv );
- dev_priv-pro_group_a = (dev-pdev-device == 0x3118);
+ dev_priv-pro_group_a = (dev-pdev-device == 0x3118 ||
+dev-pdev-device == 0x3108);
dev-dev_private = (void *)dev_priv;
return 0;
}
diff -urN -U 5 drm.prev/shared-core/via_verifier.c
drm/shared-core/via_verifier.c
--- drm.prev/shared-core/via_verifier.c 2005-04-18 10:26:00.0 +0200
+++ drm/shared-core/via_verifier.c 2005-08-13 19:17:06.0 +0200
@@ -244,11 +244,11 @@
static __inline__ int
eat_words(const uint32_t **buf, const uint32_t *buf_end, unsigned num_words)
{
- if ((*buf - buf_end) = num_words) {
+ if ((buf_end - *buf) = num_words) {
*buf += num_words;
return 0;
}
DRM_ERROR(Illegal termination of DMA command buffer\n);
return 1;
diff -urN -U 5 drm.orig/shared-core/via_mm.c drm/shared-core/via_mm.c
--- drm.orig/shared-core/via_mm.c 2005-07-15 23:22:51.0 +0200
+++ drm/shared-core/via_mm.c2005-08-07 11:57:33.0 +0200
@@ -23,52 +23,124 @@
*/
#include drmP.h
#include via_drm.h
#include via_drv.h
#include via_ds.h
-#include via_mm.h
#define MAX_CONTEXT 100
+#define MAX_MEMBLOCK_INDEX 5000
+
+/* Structure which maps indices to PMemBlock pointers.
+ index_base is used to make indices globally unique among
+ multiple mem_block_map_t structures, and to avoid ever using
+ the special value 0 as an index. */
+typedef struct {
+ unsigned int index_base;
+ PMemBlock m[MAX_MEMBLOCK_INDEX];
+} mem_block_map_t;
typedef struct {
int used;
int context;
- set_t *sets[2]; /* 0 for frame buffer, 1 for AGP , 2 for System
*/
+ mem_block_map_t *map[2]; /* 0 for frame buffer, 1 for AGP */
} via_context_t;
static via_context_t global_ppriv[MAX_CONTEXT];
static int via_agp_alloc(drm_via_mem_t * mem);
static int via_agp_free(drm_via_mem_t * mem);
static int via_fb_alloc(drm_via_mem_t * mem);
static int via_fb_free(drm_via_mem_t * mem);
-static int add_alloc_set(int context, int type, unsigned int val)
+/*
+ * Allocate a mem_block_map_t and initialize it to make all indices
+ * point to NULL. index_base must be non-zero
+ */
+static mem_block_map_t * via_mem_block_map_init(unsigned int index_base)
{
- int i, retval = 0;
+ mem_block_map_t *map;
+ int i;
- for (i = 0; i MAX_CONTEXT; i++) {
- if (global_ppriv[i].used global_ppriv[i].context == context)
{
- retval = via_setAdd(global_ppriv[i].sets[type], val);
- break;
- }
+ map = drm_alloc(sizeof(mem_block_map_t), DRM_MEM_DRIVER);
+ if (map) {
+ map-index_base = index_base;
+ for (i = 0; i MAX_MEMBLOCK_INDEX; i++)
+ map-m[i] = NULL;
}
-
- return retval;
+ return map;
}
-static int del_alloc_set(int context, int type, unsigned int val)
+/*
+ * Destroy a mem_block_map_t and
SiS 305 problems
The Card is a PCI SiS 305 with 32 MB RAM. I use DRM and Mesa from CVS with a 2.6.13-rc5 kernel. I see 1) I get segfaults in many OpenGL programs, including glxgears and gears from Mesa/progs/demos. The segfaults are always in neutral_VertexAttrib4fvARB. The problem seems to occur in all programs using vertices. Programs using only DrawPixels() and such are not affected. 2) The driver has GL_NV_vertex_program in it's extension string. I have not found a single occurance of GL_NV_vertex_program in the driver source. Wile I think the driver really should support vertex programs and wanted to add them anyway this seems strange. 3) I get lots of Mesa 6.3.1 implementation error: User called no-op dispacth function (an unsupported extension function?) messages with the programs that otherwise work. If I remove glutMainLoop() from winpos.c I get none, but if I remove the gl calls from the draw() function they still appear. What could be the cause of these problems? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4031] Mach64: Mesa does not compile. /usr/bin/ld: cannot find -lEGL
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=4031 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-08-14 11:28 --- Now, the driver compiles in my system (anyway, bug 3956 remains). But compilation ends with error message, that I suppose it is not related to the driver to be installed. This is the end of the output: rm -f mach64_dri.so gcc -m32 -o mach64_dri.so -shared ../../common/driverfuncs.o ../common/mm.o ../common/utils.o ../common/texmem.o ../common/vblank.o ../common/dri_util.o ../common/xmlconfig.o ../common/drirenderbuffer.o mach64_context.o mach64_ioctl.o mach64_screen.o mach64_span.o mach64_state.o mach64_tex.o mach64_texmem.o mach64_texstate.o mach64_tris.o mach64_vb.o mach64_dd.o mach64_lock.o ../../../../../src/mesa/mesa.a ../dri_client/dri.a -L/usr/X11R6/lib -lm -lpthread -lexpat -ldl install mach64_dri.so ../../../../../lib make[6]: Leaving directory `/descargas/xorg/Mesa/src/mesa/drivers/dri/mach64' make[5]: Leaving directory `/descargas/xorg/Mesa/src/mesa/drivers/dri' make[4]: Leaving directory `/descargas/xorg/Mesa/src/mesa' make[3]: Leaving directory `/descargas/xorg/Mesa/src/mesa' make[2]: Leaving directory `/descargas/xorg/Mesa/src' make[2]: Entering directory `/descargas/xorg/Mesa/progs' Making programs for linux-dri-x86 make[3]: Entering directory `/descargas/xorg/Mesa/progs/egl' gcc -c -Wall -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE-D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -I../../include demo1.c make[3]: *** No hay ninguna regla para construir el objetivo `../../lib/libEGL.so', necesario para `demo1'. Alto. make[3]: Leaving directory `/descargas/xorg/Mesa/progs/egl' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/descargas/xorg/Mesa/progs' make[1]: *** [default] Error 1 make[1]: Leaving directory `/descargas/xorg/Mesa' make: *** [linux-dri-x86] Error 2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
