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>