Re: next from ddb gives RED state exception?

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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.

Eduardo