On 17-Jul-2002 Bruce Evans wrote:
> This could also be just a driver problem.  I know the old wddump routine
> worked right but am not sure about any of the current ones.  Maybe dumps
> are broken on the alpha only due to driver problems.  Note that the
> splhigh() didn't actually lock out interrupts in RELENG_4 for drivers
> broken enough to call tsleep().  The [un]safepri hack in tsleep() may
> permit broken dump routines that call tsleep() to "work".  This hack
> has been lost in -current except for rotted comments which still say that
> it is done.

Agreed, if drivers depend on interrupts to work for dumps that is a Bug (tm).

>> On alpha, a random kernel thread is waking up, and is unable to go
>> back to sleep because of the panicstr hack msleep:
>>         mtx_lock_spin(&sched_lock);
>>         if (cold || panicstr) {
>>                 /*
>>                  * After a panic, or during autoconfiguration,
>>                  * just give interrupts a chance, then just return;
>                           ^^^^^^^^^^^^^^^^^^^^^^^^
> This is the rotted comment.  No chance is given here.

Well, when you unlock sched_lock you give ithreads a chance to run.  (This
is only true in a fully preemptive kernel though.)

>>                  * don't run any other procs or panic below,
>>                  * in case this is the idle process and already asleep.
>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Looks like more bitrot.  We've learned that the idle process can't call here.


>>                  */
>>                 if (mtx != NULL && priority & PDROP)
>>                         mtx_unlock(mtx);
>>                 mtx_unlock_spin(&sched_lock);
> The safepri hack (splx(safepri); splx(origpri);) was here instead of these
> mtx operations.

Probably to truly emulate this we should always release the 'mtx' mutex and
then reacquire it if PDROP isn't specified.

>>                 return (0);
>>         }
>> 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.
> I don't want to do this since I think there is no clean way to do it.
> But crash dumps must work without using interrupt threads, etc.  I
> think the "right" way to do the sync is to always do a crash dump and
> have fsck_*fs recover buffers from it rather than let the panicing
> kernel possibly create further damage.  But changing fsck_*fs to do
> this would be a lot of work.

I agree that this would be the best solution for the long term if we can
have it.


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

Reply via email to