Ben Harris wrote:
> 

> --------8<--------
> int
> mmmmap(dev, off, prot)
>         dev_t dev;
>         int off, prot;
> {
>         struct proc *p = curproc;       /* XXX */
> 
>         /*
>          * /dev/mem is the only one that makes sense through this
>          * interface.  For /dev/kmem any physaddr we return here
>          * could be transient and hence incorrect or invalid at
>          * a later time.  /dev/null just doesn't make any sense
>          * and /dev/zero is a hack that is handled via the default
>          * pager in mmap().
>          */
> -------->8--------
> 
> If mmap() on /dev/kmem isn't returning an error, I think something is wrong.

I "fixed" this problem by adding the following lines:

 ....
                case 1: 
                        /* minor device 1 is kernel memory */
                        return arm_byte_to_page(vtophys(off));
 ....

I have now found that there's some coherency problems between the 
pages mapped into kernel address space and the pages that is mapped
into the user application's address space.

I really do know to little about the StrongARM to even be on this 
list, but does the SA data-cache tag on virtual addresses or
physical ? 

-- 
Johan Rydberg			johan.rydberg@netinsight.net
Net Insight AB, Sweden		direct: +46-8-685 04 17
http://www.netinsight.net	phone:  +46-8-685 04 00
				fax:    +46-8-685 04 20