Subject: RE: PXA250 Xscale and page tables
To: Steve Woodford <email@example.com>
From: Colin Cook <firstname.lastname@example.org>
Date: 02/03/2003 09:32:29
Thanks for the education, I think I get the picture. However, I am still
lost as to the proper fix. Can you guys think of why the pages are being
mapped to more than one place? I am using 1.6 now and it still happens.
There is no hard disk on this system, everything is read directly from a RAM
drive which was decompressed from flash on boot. It's a very basic setup. Is
there a debug command I can use to find out where the other pages are mapped
to and who/why allocated them?
From: email@example.com [mailto:firstname.lastname@example.org]On
Behalf Of Steve Woodford
Sent: Sunday, February 02, 2003 4:17 PM
To: Jason R Thorpe
Subject: Re: PXA250 Xscale and page tables
On Sun, 2 Feb 2003, Jason R Thorpe wrote:
> In an older version of NetBSD's UBC (unified buffer cache), these writable
> mappings were kept around in case they were needed again later, lazily
> replaced when new UBC mappings were needed. This led to degraded
> on VIVT platforms (like the ARM) because there was a kernel-writable
> of these pages.
> This was fixed, however, in Jan 2002, and the fix was thus in the
> 1.6 release. What version of NetBSD are you using?
This thread has reminded me about something I have occasionally noticed on
sh5. While checking the TLB, I have noticed some cache-inhibited mappings
right at the start of text. (sh5 has a VIVT I$, and a similar "vac me
harder" type routine in the pmap)
I previously put this down to a problem in the sh5 pmap, but perhaps there
is a more general problem here.