Re: Reboots?

[Roland McGrath]

> 1) Errors displayed to the terminal about Free inodes having particular 
> sizes.  I think I saw a note saying that I shouldn't be worried about 
> this, but it's happening frequently during compiles and installs.

If you can find a way reproduce this reliably when you are never writing
the filesystem from linux, then please do so and show us.  If you mount the
filesystem on linux and then remove files, this will leave harmless turds
that produce these warnings.  If the turds got there by any other means,
then they might no be harmless (and at any rate we'd like to figure out
what is going on).

This comes up when creating new files (or directories or whatever).  If
this is happening with inodes that have never been used before, then either
something corrupted the unused inode on disk, or the filesystem got
confused about their contents in-core.  (mke2fs fills the inode tables with
all zeros to start with, so there should be no turds.)

It should only be possible for it to come up when reallocating inodes that
were previously used and then freed again, i.e. a file created and then
removed.  Compilations usually create and remove a lot of files /tmp, so
that is a likely situation for something related to this to arise.  If this
is what's happening, then the bug is a failure to clear the inode's block
fields, or perhaps a failure to sync the changes.

> 2) I am seeing alot of reboots mid-compile with messages like:
> 
> checking for setlocale... (cached) yes
> checking for strchr... (cached) make: *** wait: Computer bought the 
> farm.  Stop.make: *** Waiting for unfinished jobs....
> make: *** wait: Computer bought the farm.  Stop.
> sh: ../sysdeps/mach/hurd/fork.c:523: __fork: Unexpected error: (ipc/mig) 
> server died.
> 
> Is there any type of useful debugging I should be doing to give you more 
> information?

These errors suggest the proc server crashed.  I don't know why init didn't
catch the death and crash the system.  If you see this happen commonly
after a compile runs for a while, then perhaps there is some kind of bloat
going on in the proc server.  You could check at the proc server with ps
periodically doing the run and see if there is anything notable leading up
to the crash.

If you are really adventurous, you could try running gdb /hurd/proc,
do: set noninvasive, attach 0, cont.  It's conceivable you might see gdb
print something enlightening before it all goes down in flames.

The best way to try to really debug something as crucial as the proc server
is to run a sub-hurd and have the sub-hurd be the one crashing.