On Friday, February 28, 2003, at 03:49  PM, Quentin Garnier wrote:

Jumping back to this old message...

> Speaking of which, I'd like the opinion of a UVM specialist (I must say
> I'm quite clueless on the issue). To make glxinfo run (it seems to 
> choke
> later on my second video card, but it's another story) I had to apply 
> the
> following patch to uvm/uvm_map.c :
>
> diff -u -r1.1.1.3 -r1.2
> --- uvm_map.c	2003/02/28 13:29:29	1.1.1.3
> +++ uvm_map.c	2003/02/28 23:36:05	1.2
> @@ -2894,7 +2894,7 @@
>
>  		offset = current->offset + (start - current->start);
>  		size = MIN(end, current->end) - start;
> -		if (uobj != NULL) {
> +		if (uobj != NULL && uobj->pgops->pgo_put != NULL) {
>  			simple_lock(&uobj->vmobjlock);
>  			error = (uobj->pgops->pgo_put)(uobj, offset,
>  			    offset + size, flags | PGO_CLEANIT);

This patch looks reasonable, but is slightly wrong (the uobj needs to 
be unlocked).  I'll go ahead and check in a fixed patch.

It's possible that the XFree86 driver is expecting the msync(2) call to 
flush the cache, or something.  I can't really think of any other 
reason why it might issue an msync(2) on an mmap'd device.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>