Date: Tue, 5 Aug 1997 21:37:37 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, smp@csn.net Subject: Re: tsleep & KTRACE on SMP Message-ID: <199708051137.VAA28583@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I am debugging PR kern/3835 and find that the problem is in tsleep(). >Specifically if the config file contains: > >config dumps on wd0 > >the code to set this up happens in configure() b4 curproc (ie *p) is setup. >configure() maintains the variable 'cold' to deal with this issue. However >when KTRACE is enabled the code in tsleep attempts to use curproc before >testing 'cold': >----------------------------------- cut ----------------------------------- >tsleep(ident, priority, wmesg, timo) >{ > ... > >#ifdef KTRACE > if (KTRPOINT(p, KTR_CSW)) > ktrcsw(p->p_tracep, 1, 0); >#endif > s = splhigh(); > if (cold || panicstr) { Is an error to call tsleep with a NULL or uninitialized curproc. For the non-SMP case, when setdumpdev() is called, curproc is &proc0 (but proc0 is not completely initialized), and `cold' is 1. KTRPOINT(p, KTR_CSW) presumably evaluates to 0 so that there is no problem with KTRACE, and `cold' prevents other problems. Normally, the dump device is not hard-configured. Then settdumpdev() doesn't do much, and tsleep() is first called with curproc = &proc0 when the root file system is mounted. Fixes: 1. SMP apparently neeeds to set curproc to &proc0 earlier. 2. curproc should not be set to &proc0 before proc0 is fully initialized (setting it early is supposed to simplify trap handling, but actually complicates trap handling, since the contents of proc0 can't be relied on. E.g., enabling clock interrupts earlier would cause panics when null pointers to statistics are followed in the interrupt handler). 3. setddumpdev() should be called later. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708051137.VAA28583>