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

By adding the similar KASSERTs to mips kernel, I observed the same
failure on ERLITE (evbmips64-eb):

  # uname -mpr
  7.99.38 evbmips mips64eb
  # cd /usr/pkgsrc/lang/perl5; make
  (snip)
  => Checking for portability problems in extracted files
  (snip)
  Use which C compiler? [gcc]
  execve_loadvm: check exec failed 8
  execve_loadvm: check exec failed 8
  execve_loadvm: check exec failed 8
  execve_loadvm: check exec failed 8
  Checking for GNU cc in disguise and/or its version number...
  panic: kernel diagnostic assertion "!VM_PAGEMD_EXECPAGE_P(VM_PAGE_TO_MD(dst_pg))" 
failed: file "/var/build/src/sys/arch/mips/mips/pmap_machdep.c", line 628
  kernel: breakpoint trap
  Stopped in pid 2328.1 (sed) at  netbsd:cpu_Debugger+0x4: jr      ra
                  bdslot: nop

 Matt fixed it with src/sys/uvm/pmap/pmap.c:1.22

Thanks to Matt's fix, I succeeded to build perl5 without kernel panic both
on mips and powerpc/booke.

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      85    0  4304K -3832K nanoslp    0:01  0.00%  0.00% cron
  ...

The simplest example to reproduce this error may be the following script:

  #!/bin/sh
  for i in `seq 1 100`; do
          echo $i | echo > /dev/null
  done
  echo 'hit enter to exit'
  read i

top reports resource of sh executing this script is negative, both on
mips and powerpc/booke. On the other hand, the following scripts do *not*
cause the problem:

  #!/bin/sh
  for i in `seq 1 100`; do
          echo $i > /dev/null
  done
  echo 'hit enter to exit'
  read i

  #!/bin/sh
  yes | echo > /dev/null

I therefore guess that this problem occurs when pipes are created many
times, regardless of amount of data flow.

At the moment, I don't know whether this problem is related to pmap or
not. But, at least, it occurs on mips and powerpc/booke, whereas it does
not on amd64, arm/allwinner, and powerpc/ibm4xx.

Thanks,
Rin

Reply via email to