Date: Mon, 11 Sep 2000 18:21:01 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@pike.osd.bsdi.com> Cc: Boris Popov <bp@butya.kz>, Manfred Antar <null@pozo.com>, current@FreeBSD.ORG Subject: Re: New Fatal trap in Current SMP (random.dev changes ??) Message-ID: <Pine.BSF.4.21.0009111806080.753-100000@besplex.bde.org> In-Reply-To: <200009110439.VAA32934@pike.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Sep 2000, John Baldwin wrote: > Boris Popov wrote: > > Yes, after trap is occured ddb works. But it is impossible to > > continue from ddb because after typing 'c<enter>' machine becomes frozen. > > The same thing occur after any other panic (this is with SMP kernel). > > It only does this in cases when the sched_lock is held by the CPU that traps. > If the trapping CPU does not hold sched_lock when it faults, then you can > do continue and steps as normal. I _think_ that maybe having the debugger > release sched_lock when it enters the debugger and acquire it on the way out > would work, but I'm not sure, and I haven't explored all the interactions of > that yet. ddb shouldn't (appear to) go anywhere normal locking (since it may be invoked on locking code). Similarly for the low-level console drivers. (they may be invoked by ddb or for debugging printfs or panics in locking code). Making things only appear not to go near locking code is too hard. You would have to release and reaquire not only locks, but partially-acquired locks. A special ddb lock is probably required for SMP. Booting with -d is also broken here (it hangs). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009111806080.753-100000>