On Mon, 30 Mar 1998 13:38:05 +0100 
 SALEM@statoil.no wrote:

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

Can you please provide more information?  Build a kernel with DDB,
and when this happens, use the "trace" command to discover what function
it's crashing in.

 > 
 > 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
 > 
 > 
 > 
 > 

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