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