On 16-Jul-2002 Andrew Gallatin wrote:
>
> Alfred Perlstein writes:
> > > We need to somehow let only interrupt threads and the panic'ed process
> > > run after a panic. I have no idea how to do this in a clean,
> > > low-impact way.
> > >
> > > Drew
> > >
> > > PS: I was trying to make crashdumps fail on x86 by increasing HZ. But
> > > I cannot. I have no idea why this only happens on alpha.
> >
> > um, psuedocode...
> >
> > for ithreads, td->td_flags |= TD_ITHREAD
> > for panicing thread, td->td_flags |= TD_INPANIC
> >
> > if ((cold || panicstr) && (td->td_flags & (TD_ITHREAD|TD_INPANIC)) != 0) {
> >
>
> I have no idea what's planned for td_flags. Is stealing 2 values for
> this use acceptable? I didn't consider touching the flags to be
> lightweight..
>
>
> If so, I was thinking more like
>
>#define TDF_PANICSCHED 0x000002 /* may be scheduled during/after a panic */
You can already do if (td->td_ithd != NULL) to do the TD_ITHREAD test.
The problem is that this won't work if there is a process on the run queue with
a higher priority than the currently running process.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message