On Tue, 13 Nov 2001, Ben Harris wrote:

> > So, of these, only an 8k file produces an 8k file! Anything less than 8k
> > produces a zero size file, and anything above 32k (including 32k) produces a
> > file 24k too short. Hmmm...
>
> Hmm indeed.  Maybe I should stop playing with this bug and start tracking
> it down...

Right, I think we're dealing with two different bugs, though I could be
wrong.  The following patch seems to fix the cases where writing
more than MAX(8k,blocksize) to a page went wrong, but not the other case:

Index: pmap.c
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/arm26/arm26/pmap.c,v
retrieving revision 1.34
diff -u -r1.34 pmap.c
--- pmap.c	2001/11/16 13:47:06	1.34
+++ pmap.c	2001/11/17 16:30:29
@@ -807,12 +807,19 @@
 {
 	int ppn;
 	boolean_t rv;
+	struct pv_entry *pv;
 	UVMHIST_FUNC("pmap_clear_modify");

 	UVMHIST_CALLED(pmaphist);
 	ppn = atop(page->phys_addr);
 	rv = pmap_is_modified(page);
 	if (rv) {
+		for (pv = &pv_table[ppn]; pv != NULL; pv = pv->pv_next)
+			if (pv->pv_pmap == pmap_kernel() &&
+			    (pv->pv_prot & VM_PROT_WRITE)) {
+				printf("clear_modify on k-writable page\n");
+				return rv;
+			}
 		pv_table[ppn].pv_pflags &= ~PV_MODIFIED;
 		pmap_update_page(ppn);
 	}

I'm not sure this patch is the correct way to go about fixing this
problem.  It may be that the rest of the kernel shouldn't be trying to
clear the modified bit in this case.  In any case, I've still got the
problem of small writes' failing to deal with.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>