To: Aaron Brown <abrown@eecs.harvard.edu>
Cc: Paul Kranenburg <pk@cs.few.eur.nl>, phil@steelhead.cs.wwu.edu,
        thorpej@nas.nasa.gov, netbsd-developers@NetBSD.ORG
Subject: Re: sparc/4m port 
In-Reply-To: Your message of "Thu, 07 Dec 1995 18:52:34 EST."
             <Pine.HPP.3.91.951207184853.14977A-100000@muscato> 
Date: Fri, 08 Dec 1995 17:41:43 -0500
Message-Id: <27605.818462503@BALVENIE.PDL.CS.CMU.EDU>
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class

> P.S. Has anyone ever tried to use accounting with a NFS-mounted /var? If
> I turn it on, the kernel panics since the NFS statfs code accesses curproc,
> which for some reason is null when the hardclock handler calls the accounting
> routines. I'm trying to determine if this is bug in the port or in the MI
> code; should curproc be NULL here?

Yeah, i encountered and diagnosed this probably a year ago, on the
Alpha (when i was still running mostly-diskless, and wanted to test
the accounting code).

short form: yes, it's reasonable for curproc to be NULL when hardclock
calls the accounting routines.  The bug is either in the NFS code or
in the accounting code.  (i'd unconditionally say the latter, but i
don't really know how to fix it there easily...  but then, i don't
really know how to fix it in the NFS code too easily, either....  8-)


chris