On Wed, Jan 01, 2003 at 06:47:04PM +1030, Brett Lymn wrote:
>
> This is probably related, possibly because coda is getting stuck in
> the mount syscall but the output from df is wrong at this point too -
> it only "comes good" when you use the coda file system (do a ls or cd
> into it) only then does the output look right.  Here is a sample:
>

Tracking things through it looks like this is related, I am guessing
that the fields are not filled in by the initial mount because the
tsleep was interrupted - I suppose they are filled in when the
mountpoint is searched for...
 
>  
> > So either we have to figure out why getNewVnode is called, or use the
> > trick that is used for Linux and fork off a child process to perform the
> > mount syscall.
> > 
> 
> I will see if I can workout why getNewVnode is called.
> 

OK - getNewVnode is NOT called during the venus start up.  The
function traceback is as follows:

coda_call
venus_statfs
coda_nb_statfs
sys_mount
syscall_plain

The statfs is done to fill in the data for the mount point.  I think
the problem is that in coda_call a wakeup is sent to the venus process
to process a message, coda_call then tsleeps on a response from venus
but in our case venus is waiting for the mount call to return so it
will not process any messages (I am guessing this is so).  This is why
the linux approach works, the parent process is free to handle the
messages for the mount whilst the child is blocked in the actual mount
call.  To me, forking a child to do the mount seems a bit hackish -
coda_call should be able to detect the fact that coda is not mounted
yet and avoid the deadlock.

-- 
Brett Lymn