I am resending this mail in the hope that somebody can make sense
out of the MMU fault messages I reported.

Thanks in advance,
Lazaro

---------
Hi,
In response to Jason's mail, here are two instances of MMU faults.
( I use a  Debian box as a boot server for two NFS clients running NetBSD
1.3 )

If anybody feel a more detailed output is needed, please let us know.

Thanks,

Lazaro

-------- case 1
...
starting rpc daemons: portmap.
starting nfs daemons: nfsiod.
creating runtime link editor directory cache.
checking quotas: done.
building databases...
clearing /tmp
updating motd.
trap: bad kernel read access at 0x14
trap type 8, code = 0x402074d, v = 0x14
kernel program counter = 0x8a6a4
kernel: MMU fault trap
pid = 170, pc = 0008A6A4, ps = 2004, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6
        7
dreg: 00000000 00000002 02048600 FFFFFFFF 00000000 00000000 00000000
00000002
areg: 02077C00 000DB0C8 02077C00 005E7E58 00000000 000DA1F0 005E7E04
FFEFFD30

kernel stack (005E7CD0):
5E7CD0: 000CBC58 005E7D20 00000080 02048600 FFFFFFFF 00000000 00000000 0000
0000
[ 15 lines similar to the previous line stripped ...]
panic: MMU fault
Stopped at      _Debugger+0x6:  unlk    a6
db> reboot
syncing disks 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1  giving up
rebooting ...

------ case 2
...
NetBSD 1.3 (GENERIC) #0: Mon Jan  5 16:28 CST 1998
    scottr@beech:/amd/toaster/netbsd/src/sys/arc/hp300/compile/GENERIC
HP 9000/340 (16.67MHz MC68030 CPU+MMU, 16.67MHz MC68882 FPU)
cpu: delay divisor 123
real mem  = 16764928
avail mem = 12136448
using 409 buffers containing 1675264 bytes of memory
Parity detection enabled
trap: bad kernel read access at 0x3
trap type 8, code = 0x4020755, v = 0x3
kernel program counter = 0xc4be0
kernel: MMU fault trap
pid = 0, pc = 000C4BE0, ps = 2100, sfc = 1, dfc = 1
Registers:
             0        1        2        3        4        5        6
        7
dreg: 00002704 0000000C 00000224 00000001 00000002 00000000 000D8000 000000
00
areg: 00000000 000E3664 00155F78 00155F74 FF14D000 FF002000 00155F2C
FFEFFFFC

kernel stack (00155E3C):
155E3C: 000CBC58 00155E8C 00000080 00000224 00000001 00000002 00000000
000D8000
[ 15 lines similar to the previous line stripped ...]
panic: MMU fault
Stopped at      _Debugger+0x6:  unlk    a6
db> reboot
System halted. Hit any key to reboot.

----------------

Til:      ml @ wisent.de
Kopi:     SALEM @ statoil.no, port-hp300 @ netbsd.org (blind kopi: Lazaro
          Daniel Salem)
Fra:      thorpej @ nas.nasa.gov @ INTERNET
Dato:     16.03.98 22:54:01 PST
Tema:     Re: panic: MMU Fault




On Tue, 17 Mar 1998 07:27:04 +0100
 Zadok <ml@wisent.de> wrote:
 > I had the same problem with home-built kernels, just a kernel panic
 > after hardware initialization, trace revealed something near vfs_init()
 > of vfs_opv_init(), recompilation of *vfs*.c ( I just deleted the .o
 > files ) cured the problem. I suspect that config doesn't work out
 > correctly which files to recompile...
The ability for config to get dependencies right is getting better, and
if a "make depend" is run after running config, this mostly works OK, but
if you encounter random lossage like that, a "make clean" is usually in
order :-)
FWIW, when folks report "MMU fault" bugs, it's vitally important that you
include ALL messages that were displayed when the panic occurred.  What
"MMU fault" means is that there was a fatal page fault, i.e. the MMU
encountered an invalid mapping for a virtual address, and the kernel was
not able to recover.  MMU faults are vital to the proper functioning
of demand-paged executables, for example, but when you encounter a panic
as a result of one, it usally means a NULL pointer.
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939