Date: Tue, 16 Jul 2002 21:39:51 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG, Andrew Kolchoogin <andrew@snark.rinet.ru>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: VOP_GETATTR panic on Alpha Message-ID: <XFMail.20020716213951.jhb@FreeBSD.org> In-Reply-To: <20020717103919.D3087-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Yes.
>> */
>> 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
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?XFMail.20020716213951.jhb>