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
Booting with -d is also broken here (it hangs).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message