On 2016/09/30 21:11, Nick Hudson wrote:
Fixed in sys/uvm/pmap/pmap.c:1.23
Fix confirmed both on mips64-eb and powerpc/booke.
Thank you so much for your great hack!
Rin
On 09/28/16 16:13, Rin Okuyama wrote:
On 2016/09/28 20:40, Nick Hudson wrote:
[snip]
if the mapping changes PA then the resident_count gets reduced by
pmap_{,pte_}remove, but not increased again.
I'm working on a fix.
Thank you very much for your analysis. I'm looking forward to
On 2016/09/28 20:40, Nick Hudson wrote:
The problem is here...
https://nxr.netbsd.org/xref/src/sys/uvm/pmap/pmap.c#1275
1275 if (pte_valid_p(opte) && pte_to_paddr(opte) != pa) {
1276 pmap_remove(pmap, va, va + NBPG);
1277 PMAP_COUNT(user_mappings_changed);
1278
On 09/20/16 12:34, Rin Okuyama wrote:
[snip...]
However, unfortunately, something is still wrong. top(1) reports
resources
of some processes are negative:
% top
...
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
...
573 root 850 4304K -3832K
Sorry for my long silence.
On 2016/09/17 6:02, Nick Hudson wrote:
On 09/16/16 14:19, Rin Okuyama wrote:
I reported a reproducible failure of KASSERT on powerpc/booke in which
destination of pmap_copy_page(9) is executable:
https://mail-index.netbsd.org/port-powerpc/2016/09/11/msg003498.html
On 09/16/16 14:19, Rin Okuyama wrote:
I reported a reproducible failure of KASSERT on powerpc/booke in which
destination of pmap_copy_page(9) is executable:
https://mail-index.netbsd.org/port-powerpc/2016/09/11/msg003498.html
By adding the similar KASSERTs to mips kernel, I observed the same
I reported a reproducible failure of KASSERT on powerpc/booke in which
destination of pmap_copy_page(9) is executable:
https://mail-index.netbsd.org/port-powerpc/2016/09/11/msg003498.html
By adding the similar KASSERTs to mips kernel, I observed the same
failure on ERLITE (evbmips64-eb):
#
