Re: next from ddb gives RED state exception?

On 13/06/2014 1:57 AM, Eduardo Horvath wrote:
> On Thu, 12 Jun 2014, Darren Reed wrote:
> 
>> Does this look normal?
>>
>> Cheers,
>> Darren
>>
>> Breakpoint in pid 329.1 (ipfstat) at    netbsd:ipf_getnextrule:
>> save            %
>> sp, -0x370, %sp
>> db{0}> next
>>
>> RED State Exception
>> Error enable reg: 0000.0001.00f0.001f
>> CPU: 0000.0000.0000.0000
>> TL=0000.0000.0000.0005 TT=0000.0000.0000.00d8
>>    TPC=0000.0000.0101.1524 TnPC=0000.0000.0101.1528
>> TSTATE=0000.0000.8200.0506
>> TL=0000.0000.0000.0004 TT=0000.0000.0000.01ff
>>    TPC=0000.0000.0101.8af4 TnPC=0000.0000.0101.8af8
>> TSTATE=0000.0000.8208.1405
>> TL=0000.0000.0000.0003 TT=0000.0000.0000.0060
>>    TPC=0000.0000.0118.0f64 TnPC=0000.0000.0118.0f68
>> TSTATE=0000.0044.8200.0605
>> TL=0000.0000.0000.0002 TT=0000.0000.0000.0060
>>    TPC=0000.0000.0116.62a8 TnPC=0000.0000.0116.62ac
>> TSTATE=0000.0044.8200.1601
>> TL=0000.0000.0000.0001 TT=0000.0000.0000.0060
>>    TPC=00Skipping crash dump on recursive panic
>> panic: cpu0: ipi_send: couldn't send ipi to UPAID 0 (tried 10000 times)
> 
> Oh Goody!  A watchdog reset!  I haven't seen one of those in a loong time.
> 
> You blew your trap stack.
> 
> The CPU has set of 4 trap registers.  Each time the CPU take a trap it 
> stores the trap state in the registers and increases the trap level.  The 
> trap handler usually reads the trap status out and saves it some where, 
> then reduces the trap level so the CPU can take another trap.  That's not 
> happening here.  When you ran out of trap levels the CPU took a RED state 
> exception.
> 
> The TT register will tell you the trap type, in this case 0x60 which is 
> the interrupt vector trap.  The TPC register will tell you what the CPU 
> was doing when it got the trap.  
> 
> In this case, either something is very wrong in the interrupt dispatch 
> code, which should simply read the interrupt dispatch register contents to 
> figure out the interrupt source, queue the interrupt in one of the pending 
> interrupt queues, issue an appropriate level interrupt, and resume 
> execution, or the CPU got an IPI and failed to properly execute it.  I 
> vote for #2.
> 
> I know that IPIs are used for TLB shootdown and cache flushing at least.

In a different experiment with "next" from ddb, I set a breakpoint in
an ipf function, caused the breakpoint to trigger and then did "n".

Whilst the machine did not panic or give me a RED error, it is hung
and hung hard. No response from ping and sending a BREAK to the
console port does nothing. No response to characters on the console
either.

Power button time.

Darren