Date: Tue, 20 May 2003 17:17:41 -0300 From: "Daniel C. Sobral" <dcs@tcoip.com.br> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.ORG> Subject: Re: /dev/null and KSE panic 100% reproducible Message-ID: <3ECA8D65.8020908@tcoip.com.br> In-Reply-To: <Pine.BSF.4.21.0305201259280.22764-100000@InterJet.elischer.org> References: <Pine.BSF.4.21.0305201259280.22764-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian, it is clear from the bt full that the first panic was the
/dev/null one. Alas, I saw it happen, so I can also confirm that.
I got a serial setup here, and I'll eventually get down to reproduce the
panic and get further information from it. I'll test without MAC, to see
if that helps (I hope it doesn't -- it might prevent me from testing
your own patch), and then test your patch.
I have seen this panic mostly during another panic indeed. I think there
was a single case where that wasn't true, but I can't recall if I can
say that for sure or if the KSE panic might have hidden another panic.
I think I can't get to this before tomorrow, so I'm just sending a
message to state that I consider the ball to be in my hands for now.
I'll get back to you, rest assured. :-)
Julian Elischer wrote:
>
> On Tue, 20 May 2003, Julian Elischer wrote:
>
>>Someone put the following code into kern/kern_switch.c
>> /*
>> * Only allow non system threads to run in panic
>> * if they are the one we are tracing. (I think.. [JRE])
>> */
>> if (panicstr && ((td->td_proc->p_flag & P_SYSTEM) == 0 &&
>> (td->td_flags & TDF_INPANIC) == 0))
>> goto retry;
>>
>>
>>It has the effect of throwing away threads that it has taken off teh run
>>queue if we are in a panic.
>>
>>at a later time anything that goes through these threads will assume
>>they are still on teh run queue and panic becasue they are not..
>>
>>try the following:
>>
>>change it to:
>>
>> if (panicstr && ((td->td_proc->p_flag & P_SYSTEM) == 0 &&
>> (td->td_flags & TDF_INPANIC) == 0)) {
>> /* note that it is no longer on the run queue */
>> TD_SET_CAN_RUN(td);
>> goto retry;
>> }
>>
>>
>>if it fails you may try TD_SET_SUSPENDED(td) instead, but I think this
>>is better.
>>
>
>
> Note, this panic can only happen if you are already panicing, as seen
> below..
> This is why I haven't seen it.
>
>
>>>panic: No strategy on dev null responsible for buffer 0xc776ab90
>>>
>>>syncing disks, buffers remaining... 2230 2230 2229 2229 2229 2228 2228
>>>2228 2228 2228 2228 panic: KSE not on run queue
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
Daniel.Sobral@tcoip.com.br
dcs@tcoip.com.br
Outros:
dcs@newsguy.com
dcs@freebsd.org
capo@notorious.bsdconspiracy.net
A plucked goose doesn't lay golden eggs.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ECA8D65.8020908>