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]

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

[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

[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

[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

[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

[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

[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.

Kernel 2.6.0-test2 vs 2.2.12 -- Some observations

[J.C. Wren]

	So now that 2.6.0-test2 runs on a 386EX/25 with 8MB of memory, and the CF 
disk is working properly, I have a few observations regarding the change in 
kernels, and the impact that I see.

	These are not (necessarily) judgements, and the comparison may not be 100% on 
equal footing, but nonetheless, they're what I see.  If you have suggestions, 
I'll be happy to try them.  So, with abestos suite in standby mode:

	Both kernels are very limited in what's compiled in.  Basically, it's 386 
optioned, with math emulation enabled, IDE for hard disk only, PPP with 
compression, ethernet (but no drivers, just enough so that PPP works), 
SYSVIPC, ext2 support, /proc support, serial console (serial.h has been 
modified for 6 serial ports, 2 16450s (the 386EX native ports), and 2 
external 16C752's (each channel on a dedicated interrupt).

	The 2.2.12 version is compiled with GCC 2.91.66, the 2.6.0-test2 version with 
GCC 2.96.

	Kernel 2.2.12 is a BlueCat variation, which has some minor tweaks to reduce 
the footprint, modifications to remove real-time clock support, and the 
CLOCK_TICK_RATE changed from 1193180 to 1000000.  The 2.6.0-test2 kernel has 
similiar modifications, implemented as much as possible in the mach- 
directories.  2.2.12 also has support for an AT1700 ethernet controller 
(whose hardware is not present in the system, currently).  2.6.0-test2 is 
build without this.

	2.2.12 compiles out at 755712 bytes, which is uncompressed (we don't compress 
the kernel because a 386EX/25 takes too long to uncompress).  The values 
reported by the kernel as it comes up are: 6884k/8192k availale (596k kernel 
code, 416k reserved, 272k data, 24k init).

	2.6.0-tests compiles out at 1163392 bytes (again, uncompressed, for the same 
reason).  The values reported by the kernel are: 6296k/8132k available (932k 
kernel code, 1424k reserved, 239k data, 68k init, 0k highmem).  The 
CONFIG_EMBEDDED is set (admittedly, I haven't grepped the code to see what 
all this variable impacts).

	I'm sure the reserved value is something I'm failing to tune myself that's 
been tweaked into the BlueCat distro.  That's something I need to look into.  
But 300K of code growth (33%!) for the same basic functionality strikes me 
as... not good.  Any thoughts on this issue?

	For reasons unknown, whereas 2.2.12 picked up the values for how much memory 
we have stuffed into a fake BIOS block, 2.6.0-test2 does not (nor did 
2.5.69).  I have to set a mem=7744k into the boot params.  Anything more, and 
I get kernel paging faults at startup.  I'm unclear why this is, but since it 
can be worked around at the moment, I can let it lay.

	2.2.12 reports 3.49 Bogomips, 2.6.0-test2 reports varying values, depending 
on what HZ is set to (more on this shortly).  4.14 for HZ=100, 8.19 for 
HZ=1000.  I realize that Bogomips are meaningless, and didn't at some point 
the method for determining them change?  I do find it odd that that the 
rating should change by changing the HZ value, however.

	Interactive performance is an atrocity with 2.6.0-test2.  Something as simple 
as backspacing though a command line can cause overrun errors.  Whereas 
before zmodeming a file down was not an issue with 2.2.12 (this, in fact, is 
how software is applied to the CF card), it fails completely under 
2.6.0-test2.  In addition, I started getting 'serial8250: too much work for 
irq4'.  Granted, the console port is a 16450, which has no FIFO.  But to go 
to a newer kernel and get this error doesn't seem right.  Perhaps there's 
some performance tuning I'm missing, but I do know that it was not required 
under 2.2.12, so I'm not sure why I would need to do that under 2.6.0-test2.

	I have not run hdparm on the drives, but e2fsck coming up on a dirty 
partition is amazingly slow on 2.6.0-test2.  On a 32MB CF card with 25% usage 
(about 300 files), it takes less than 10 seconds under 2.2.12.  On 
2.6.0-test2, I'm seeing on the order of 40+ seconds.  Long enough, in fact, 
that the watchdog that makes sure the system has booted into the application 
is timing out and punting the system.

	Any thoughts or things to look for would be greatly appreciated.  I realize 
that many people doing embedded work on small processors are using the older 
kernels.  I'd like to use a newer one, since the device driver interface is 
so much cleaner, and I'd like to use a CF+WiFi card, which is not supported 
in the older kernels.  

	I've posted the .config files, along with the System.map and kernel images to 
http://tinymicros.com/linux.  The final images are run through "objcopy -O 
binary -R .note -R .comment -R .stab -R .stabstr vmlinux vmlinuz" to produce 
the image that goes into the FLASH parts.

	--John

Re: Kernel 2.6.0-test2 vs 2.2.12 -- Some observations

[Andrew Morton]

"J.C. Wren" <jcwren@jcwren.com> wrote:
>
> Interactive performance is an atrocity with 2.6.0-test2.  Something as simple 
>  as backspacing though a command line can cause overrun errors.  Whereas 
>  before zmodeming a file down was not an issue with 2.2.12 (this, in fact, is 
>  how software is applied to the CF card), it fails completely under 
>  2.6.0-test2.

It sounds like something is spinning in-kernel.

What do `free' and `cat /proc/meminfo' and `top' say?

The next step would be to generate a kernel profile.

Re: Kernel 2.6.0-test2 vs 2.2.12 -- Some observations

[J.C. Wren]

Here's the output of the system coming up, and 'free' and 'cat /proc/meminfo'.  Don't have a version of top currently compiled for it, but 'uptime' says 0.00 0.00 0.00 after it's sitting idle a bit.

Linux version 2.6.0-slimedr (root@linux.private.com) (gcc version 2.96 20000731
(Red Hat Linux 7.3 2.96-113)) #31 Thu Aug 7 00:22:22 EDT 2003
Video mode to be used for restore is 3e0
BIOS-provided physical RAM map:
 PROM: 0000000000000000 - 000000000009f000 (usable)
 PROM: 0000000000100000 - 00000000040ffc00 (usable)
user-defined physical RAM map:
 user: 0000000000000000 - 000000000009f000 (usable)
 user: 0000000000100000 - 00000000007f1000 (usable)
7MB LOWMEM available.
On node 0 totalpages: 2033
  DMA zone: 2033 pages, LIFO batch:1
  Normal zone: 0 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node : 0
Kernel command line: root=/dev/hda1 hdb=none ide0=0x1f0,0x3f6,0x09 ide0=noautotune hda=notremovable console=ttyS0,57600 mem=7744k
ide_setup: hdb=none -- BAD OPTION
ide_setup: ide0=0x1f0,0x3f6,0x09

ide_setup: ide0=noautotune
ide_setup: hda=notremovable
Initializing CPU#0
PID hash table entries: 32 (order 5: 256 bytes)
Calibrating delay loop... 4.14 BogoMIPS
Memory: 6296k/8132k available (932k kernel code, 1424k reserved, 239k data, 68k
init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... No.
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: 386
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
Initializing RT netlink socket
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs:   5 entries (12 bytes)
biovec pool[1]:   4 bvecs:   2 entries (48 bytes)
biovec pool[2]:  16 bvecs:   1 entries (192 bytes)
biovec pool[3]:  64 bvecs:   0 entries (768 bytes)
biovec pool[4]: 128 bvecs:   0 entries (1536 bytes)
biovec pool[5]: 256 bvecs:   0 entries (3072 bytes)
pty: 256 Unix98 ptys configured
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
ttyS1 at I/O 0x2f8 (irq = 3) is a 16450
ttyS2 at I/O 0x300 (irq = 12) is a ST16654
ttyS3 at I/O 0x310 (irq = 14) is a ST16654
ttyS4 at I/O 0x320 (irq = 5) is a ST16654
ttyS5 at I/O 0x330 (irq = 6) is a ST16654
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: 32MB CTS, ATA DISK drive
Using anticipatory scheduling elevator
ide0 at 0x1f0-0x1f7,0x3f6 on irq 9
hda: max request size: 128KiB
hda: 64000 sectors (33 MB) w/4KiB Cache, CHS=500/4/32
 hda: hda1
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 68k freed

bash# free
             total       used       free     shared    buffers     cached
Mem:          6388       3252       3136          0        260       1960
-/+ buffers/cache:       1032       5356
Swap:            0          0          0
bash# cat /proc/meminfo
MemTotal:         6388 kB
MemFree:          3148 kB
Buffers:           260 kB
Cached:           1972 kB
SwapCached:          0 kB
Active:           1728 kB
Inactive:          816 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:         6388 kB
LowFree:          3148 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:              32 kB
Writeback:           0 kB
Mapped:           1120 kB
Slab:              552 kB
Committed_AS:     4052 kB
PageTables:         48 kB
VmallocTotal:  1032168 kB
VmallocUsed:         0 kB
VmallocChunk:  1032168 kB
bash#

	--John

On Thursday 07 August 2003 13:34 pm, Andrew Morton wrote:
> "J.C. Wren" <jcwren@jcwren.com> wrote:
> > Interactive performance is an atrocity with 2.6.0-test2.  Something as
> > simple as backspacing though a command line can cause overrun errors. 
> > Whereas before zmodeming a file down was not an issue with 2.2.12 (this,
> > in fact, is how software is applied to the CF card), it fails completely
> > under 2.6.0-test2.
>
> It sounds like something is spinning in-kernel.
>
> What do `free' and `cat /proc/meminfo' and `top' say?
>
> The next step would be to generate a kernel profile.

Re: Kernel 2.6.0-test2 vs 2.2.12 -- Some observations

[Alan Cox]

On Iau, 2003-08-07 at 18:23, J.C. Wren wrote:
> 	For reasons unknown, whereas 2.2.12 picked up the values for how much memory 
> we have stuffed into a fake BIOS block, 2.6.0-test2 does not (nor did 
> 2.5.69).  I have to set a mem=7744k into the boot params.  Anything more, and 
> I get kernel paging faults at startup.  I'm unclear why this is, but since it 
> can be worked around at the moment, I can let it lay.

2.5.x/2.6 (and 2.4) use E820 memory sizing before E801 and earlier
systems. Make sure your E820 tables are right I guess.

> 	I have not run hdparm on the drives, but e2fsck coming up on a dirty 
> partition is amazingly slow on 2.6.0-test2.  On a 32MB CF card with 25% usage 
> (about 300 files), it takes less than 10 seconds under 2.2.12.  On 
> 2.6.0-test2, I'm seeing on the order of 40+ seconds.  Long enough, in fact, 
> that the watchdog that makes sure the system has booted into the application 
> is timing out and punting the system.

You bluecat probably sets umask by default if its designed to keep
latency low. So hdparm -u1 /dev/hda first.

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--