Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Mitch]

Yep, Marcelo is right. I meant to imply that the new DRM module
from X cvs or http://dri.sourceforge.net/downloads.phtml needs
a recompile for the new vmap changes and that was the one that
i use and was working fine - i.e i couldn't reproduce the problem
reported. I didn't mean (or want to imply) that the vmap changes
could/should break the old kernel module. Irrespective i did think
the kernel drm tree needed updating.

Mitch

-------- Original Message --------
Subject: Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with
Date: Thu, 7 Aug 2003 16:26:24 +0200
From: Christoph Hellwig <hch@lst.de>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>, Mitch@0Bits.COM,   Erik Andersen <andersen@codepoet.org>,   Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <1060256649.3169.20.camel@dhcp22.swansea.linux.org.uk>
<Pine.LNX.4.44.0308071023040.6818-200000@logos.cnet>

> I dont understand how the vmap change can break DRM.
>
> The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> acts exactly the same way as before AFAICS).
>
> Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> vmap() change to check if its causing the mentioned problem?

vmap() doesn't break DRM.  The external drm code just detects that
vmap is present and then uses the new interface, but this new code
also expects a new exported symbol.

The DRM code in your tree is completly unaffected.

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Erik Andersen]

On Thu Aug 07, 2003 at 10:27:03AM -0300, Marcelo Tosatti wrote:
> > That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
> > then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
> > 2.4.23.
> 
> I dont understand how the vmap change can break DRM. 
> 
> The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> acts exactly the same way as before AFAICS).
> 
> Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> vmap() change to check if its causing the mentioned problem? 
> 
> The patch is attached. Apply it with -R.

Reverting this patch has no effect on the problem....

    $ glxgears 
    Illegal instruction

same as before,

As a guess, the "Unknown" in the drm detection below could
be related to my problem....  As could the fact I have 2 GB
ram installed.  Or the fact I'm running SMP.  dunno.


Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 1919M
agpgart: Detected Intel(R) 865G chipset
agpgart: AGP aperture is 64M @ 0xf8000000
[----------snip-----------]
[drm] AGP 0.99 on Unknown @ 0xf8000000 64MB
[drm] Initialized radeon 1.1.1 20010405 on minor 0



00:01.0 PCI bridge: Intel Corp. 82865G/PE/P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, fast devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: fe800000-fe8fffff
        Prefetchable memory behind bridge: e7e00000-f7dfffff

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
        Subsystem: PC Partner Limited RV100 QY [Sapphire Radeon VE 7000]
        Flags: bus master, stepping, 66Mhz, medium devsel, latency 64, IRQ 16
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at c000 [size=256]
        Memory at fe8f0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fe8c0000 [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
        Capabilities: [50] Power Management version 2


 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Christoph Hellwig]

On Thu, Aug 07, 2003 at 11:47:53AM -0300, Marcelo Tosatti wrote:
> > vmap() doesn't break DRM.  The external drm code just detects that
> > vmap is present and then uses the new interface, but this new code
> > also expects a new exported symbol.
> 
> And which symbol is that? 

Ask the DRI folks.  They posted a patch on lkml a few days ago.

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Marcelo Tosatti]

On Thu, 7 Aug 2003, Christoph Hellwig wrote:

> > I dont understand how the vmap change can break DRM. 
> > 
> > The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> > acts exactly the same way as before AFAICS).
> > 
> > Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> > vmap() change to check if its causing the mentioned problem? 
> 
> vmap() doesn't break DRM.  The external drm code just detects that
> vmap is present and then uses the new interface, but this new code
> also expects a new exported symbol.

And which symbol is that? 

> The DRM code in your tree is completly unaffected.

Fine.

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Alan Cox]

On Iau, 2003-08-07 at 15:26, Christoph Hellwig wrote:
> > Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> > vmap() change to check if its causing the mentioned problem? 
> 
> vmap() doesn't break DRM.  The external drm code just detects that
> vmap is present and then uses the new interface, but this new code
> also expects a new exported symbol.
> 
> The DRM code in your tree is completly unaffected.

Cool. So its a non issue for people not using the XFree CVS

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Christoph Hellwig]

> I dont understand how the vmap change can break DRM. 
> 
> The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
> acts exactly the same way as before AFAICS).
> 
> Anyway, Mitch (or Erik who's seeing the problem), can please revert the
> vmap() change to check if its causing the mentioned problem? 

vmap() doesn't break DRM.  The external drm code just detects that
vmap is present and then uses the new interface, but this new code
also expects a new exported symbol.

The DRM code in your tree is completly unaffected.

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Marcelo Tosatti]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 976 bytes --]



On 7 Aug 2003, Alan Cox wrote:

> On Mer, 2003-08-06 at 15:38, Mitch@0Bits.COM wrote:
> > I think with the new vmap changes that went in in -pre7 means
> > you will need to get a new drm module (like from X cvs or
> > http://dri.sourceforge.net/downloads.phtml) and recompile it
> > with the new kernel headers which will then pick up the define
> > -DVMAP_4_ARGS in the Makefile and give you a good module that works.
> > 
> > The DRI kernel trees need updating.
> 
> That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
> then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
> 2.4.23.

I dont understand how the vmap change can break DRM. 

The vmap patch only changes internal mm/vmalloc.c code (vmalloc() call
acts exactly the same way as before AFAICS).

Anyway, Mitch (or Erik who's seeing the problem), can please revert the
vmap() change to check if its causing the mentioned problem? 

The patch is attached. Apply it with -R.

[-- Attachment #2: Type: TEXT/PLAIN, Size: 5468 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1016.1.2 -> 1.1016.1.3
#	      kernel/ksyms.c	1.77    -> 1.78   
#	        mm/vmalloc.c	1.15    -> 1.16   
#	include/linux/vmalloc.h	1.2     -> 1.3    
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/07/18	hch@lst.de	1.1016.1.3
# [PATCH] vmap() backport
# 
# Hi Marcelo,
# 
# this patch backports vmap() from 2.5.  vmap() is needed for
# 
#  - XFS
#  - proper AGP support on ia64 and ppc
# (- latest ALSA seems to have some use for in on 2.5)
# 
# the 2.4 implementation is not as sound as the 2.5 one but far less
# intrusive.  It has been tested for more than a year in the XFS tree
# and -aa and in -ac for a while.
# --------------------------------------------
#
diff -Nru a/include/linux/vmalloc.h b/include/linux/vmalloc.h
--- a/include/linux/vmalloc.h	Thu Aug  7 10:21:35 2003
+++ b/include/linux/vmalloc.h	Thu Aug  7 10:21:35 2003
@@ -21,6 +21,9 @@
 
 extern struct vm_struct * get_vm_area (unsigned long size, unsigned long flags);
 extern void vfree(void * addr);
+#define vunmap(addr)	vfree(addr)
+extern void * vmap(struct page **pages, int count,
+		   unsigned long flags, pgprot_t prot);
 extern void * __vmalloc (unsigned long size, int gfp_mask, pgprot_t prot);
 extern long vread(char *buf, char *addr, unsigned long count);
 extern void vmfree_area_pages(unsigned long address, unsigned long size);
diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c
--- a/kernel/ksyms.c	Thu Aug  7 10:21:35 2003
+++ b/kernel/ksyms.c	Thu Aug  7 10:21:35 2003
@@ -112,6 +112,7 @@
 EXPORT_SYMBOL(kfree);
 EXPORT_SYMBOL(vfree);
 EXPORT_SYMBOL(__vmalloc);
+EXPORT_SYMBOL(vmap);
 EXPORT_SYMBOL(vmalloc_to_page);
 EXPORT_SYMBOL(mem_map);
 EXPORT_SYMBOL(remap_page_range);
diff -Nru a/mm/vmalloc.c b/mm/vmalloc.c
--- a/mm/vmalloc.c	Thu Aug  7 10:21:35 2003
+++ b/mm/vmalloc.c	Thu Aug  7 10:21:35 2003
@@ -93,7 +93,8 @@
 }
 
 static inline int alloc_area_pte (pte_t * pte, unsigned long address,
-			unsigned long size, int gfp_mask, pgprot_t prot)
+			unsigned long size, int gfp_mask,
+			pgprot_t prot, struct page ***pages)
 {
 	unsigned long end;
 
@@ -103,9 +104,20 @@
 		end = PMD_SIZE;
 	do {
 		struct page * page;
-		spin_unlock(&init_mm.page_table_lock);
-		page = alloc_page(gfp_mask);
-		spin_lock(&init_mm.page_table_lock);
+
+		if (!pages) {
+			spin_unlock(&init_mm.page_table_lock);
+			page = alloc_page(gfp_mask);
+			spin_lock(&init_mm.page_table_lock);
+		} else {
+			page = (**pages);
+			(*pages)++;
+
+			/* Add a reference to the page so we can free later */
+			if (page)
+				atomic_inc(&page->count);
+
+		}
 		if (!pte_none(*pte))
 			printk(KERN_ERR "alloc_area_pte: page already exists\n");
 		if (!page)
@@ -117,7 +129,9 @@
 	return 0;
 }
 
-static inline int alloc_area_pmd(pmd_t * pmd, unsigned long address, unsigned long size, int gfp_mask, pgprot_t prot)
+static inline int alloc_area_pmd(pmd_t * pmd, unsigned long address,
+			unsigned long size, int gfp_mask,
+			pgprot_t prot, struct page ***pages)
 {
 	unsigned long end;
 
@@ -129,7 +143,8 @@
 		pte_t * pte = pte_alloc(&init_mm, pmd, address);
 		if (!pte)
 			return -ENOMEM;
-		if (alloc_area_pte(pte, address, end - address, gfp_mask, prot))
+		if (alloc_area_pte(pte, address, end - address,
+					gfp_mask, prot, pages))
 			return -ENOMEM;
 		address = (address + PMD_SIZE) & PMD_MASK;
 		pmd++;
@@ -137,8 +152,11 @@
 	return 0;
 }
 
-inline int vmalloc_area_pages (unsigned long address, unsigned long size,
-                               int gfp_mask, pgprot_t prot)
+static inline int __vmalloc_area_pages (unsigned long address,
+					unsigned long size,
+					int gfp_mask,
+					pgprot_t prot,
+					struct page ***pages)
 {
 	pgd_t * dir;
 	unsigned long end = address + size;
@@ -155,7 +173,7 @@
 			break;
 
 		ret = -ENOMEM;
-		if (alloc_area_pmd(pmd, address, end - address, gfp_mask, prot))
+		if (alloc_area_pmd(pmd, address, end - address, gfp_mask, prot, pages))
 			break;
 
 		address = (address + PGDIR_SIZE) & PGDIR_MASK;
@@ -168,6 +186,12 @@
 	return ret;
 }
 
+int vmalloc_area_pages(unsigned long address, unsigned long size,
+		       int gfp_mask, pgprot_t prot)
+{
+	return __vmalloc_area_pages(address, size, gfp_mask, prot, NULL);
+}
+
 struct vm_struct * get_vm_area(unsigned long size, unsigned long flags)
 {
 	unsigned long addr, next;
@@ -246,7 +270,30 @@
 	if (!area)
 		return NULL;
 	addr = area->addr;
-	if (vmalloc_area_pages(VMALLOC_VMADDR(addr), size, gfp_mask, prot)) {
+	if (__vmalloc_area_pages(VMALLOC_VMADDR(addr), size, gfp_mask,
+				 prot, NULL)) {
+		vfree(addr);
+		return NULL;
+	}
+	return addr;
+}
+
+void * vmap(struct page **pages, int count,
+	    unsigned long flags, pgprot_t prot)
+{
+	void * addr;
+	struct vm_struct *area;
+	unsigned long size = count << PAGE_SHIFT;
+
+	if (!size || size > (max_mapnr << PAGE_SHIFT))
+		return NULL;
+	area = get_vm_area(size, flags);
+	if (!area) {
+		return NULL;
+	}
+	addr = area->addr;
+	if (__vmalloc_area_pages(VMALLOC_VMADDR(addr), size, 0,
+				 prot, &pages)) {
 		vfree(addr);
 		return NULL;
 	}

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Alan Cox]

On Mer, 2003-08-06 at 15:38, Mitch@0Bits.COM wrote:
> I think with the new vmap changes that went in in -pre7 means
> you will need to get a new drm module (like from X cvs or
> http://dri.sourceforge.net/downloads.phtml) and recompile it
> with the new kernel headers which will then pick up the define
> -DVMAP_4_ARGS in the Makefile and give you a good module that works.
> 
> The DRI kernel trees need updating.

That doesn't seem a 2.4.22 candidate thing to me. If vmap broke the DRI
then the vmap patch wants reverting for 2.4.22 IMHO, and looking at for
2.4.23.

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Mitch]

I think with the new vmap changes that went in in -pre7 means
you will need to get a new drm module (like from X cvs or
http://dri.sourceforge.net/downloads.phtml) and recompile it
with the new kernel headers which will then pick up the define
-DVMAP_4_ARGS in the Makefile and give you a good module that works.

The DRI kernel trees need updating.

Can you download from the link above and cd to drm and do a

	make -f Makefile.linux radeon.o

and report please if that works for you without crashing glx* ?

Mitch

-------- Original Message --------
Subject: Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with
Date: Tue, 5 Aug 2003 14:36:49 -0600
From: Erik Andersen <andersen:codepoet:org>
Reply-To: andersen:codepoet:org
To: Mitch@0Bits.COM
CC: linux-kernel@vger.kernel.org
References: <Pine.LNX.4.53.0308052032220.31114@mx.homelinux.com>

On Tue Aug 05, 2003 at 08:37:38PM +0100, Mitch@0Bits.COM wrote:
>
> Works fine with XFree86 4.3.x, 2.4.22-pre10 and the radeon.o
> drm module. If you look backwards in your strace file, what is the
> device that file descriptor 5 belongs to ?

I have XFree86 4.2.1 (i.e. xfree86-common, xserver-xfree86,
xlibmesa3-gl, etc) version 4.2.1-9 from Debian unstable installed.

I think you mean file descriptor 4:
    open("/dev/dri/card0", O_RDWR)          = 4

$ ls -la /dev/dri/card0
crw-rw-rw-    1 root     root     226,   0 Jul 12 04:21 /dev/dri/card0

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Erik Andersen]

On Tue Aug 05, 2003 at 08:37:38PM +0100, Mitch@0Bits.COM wrote:
> 
> Works fine with XFree86 4.3.x, 2.4.22-pre10 and the radeon.o
> drm module. If you look backwards in your strace file, what is the
> device that file descriptor 5 belongs to ?

I have XFree86 4.2.1 (i.e. xfree86-common, xserver-xfree86,
xlibmesa3-gl, etc) version 4.2.1-9 from Debian unstable installed.

I think you mean file descriptor 4:
    open("/dev/dri/card0", O_RDWR)          = 4

$ ls -la /dev/dri/card0
crw-rw-rw-    1 root     root     226,   0 Jul 12 04:21 /dev/dri/card0

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: Linux 2.4.22-pre10-ac1 DRI doesn't work with

[Mitch]

Works fine with XFree86 4.3.x, 2.4.22-pre10 and the radeon.o
drm module. If you look backwards in your strace file, what is the
device that file descriptor 5 belongs to ?

core ~% lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500]
core ~% uname -a
Linux core 2.4.22-pre10 #7 Mon Aug 4 18:59:06 BST 2003 i686 unknown unknown GNU/Linux


On Tue Aug 05, 2003 at 06:49:25PM +0200, Ruben Puettmann wrote:
> DRI doesn't work with Radeon 7500 on IBM Thinkpad R40 (2722).
[-----------snip---------------]
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility
[-----------snip---------------]
> XFree86 : 4.2.1
>
>
> Both glxgears and tuxracer crashes with the Illegal instruction error
> message. the strace output of glxgears is:
[-----------snip---------------]
> ioctl(3, FIONREAD, [0])                 = 0
> ioctl(5, 0x40186448, 0xbffffb30)        = 0
> --- SIGILL (Illegal instruction) @ 0 (0) ---
> +++ killed by SIGILL +++


I get this too, with vanilla 2.4.22-pre10....

$ lspci | grep VGA
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY
[Radeon 7000/VE]
$ lspci | grep AGP
00:01.0 PCI bridge: Intel Corp. 82865G/PE/P Processor to AGP Controller
(rev 02)

$ strace glxgears
[-----------snip---------------]
ioctl(3, FIONREAD, [0])                 = 0
ioctl(4, 0x40186448, 0xbffff4d0)        = 0
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++

 -Erik