There's no codes there -- that's an Interrupt Instruction Pointer (what instruction bundle was being executed at the time of panic). That's tells you what code [in the kernel] was running. The Interrupt Fault Address is the data address referenced at the time of panic. For dereference panics, that's the address which caused the panic. For non-dereference panics [such as INIT usually], this is less meaningful.
I won't claim there may be some variant of this I haven't seen -- but usually INIT panics are Transfer-Of-Controls (TOC). Either someone pushed the TOC button on your IPF server, ServiceGuard or other clustering packages are running and decided to bring down the node because it was thought to be hung, or the GSP console was used to do CM>TC or something.
Presuming that you have sufficient dump space that the dump [and there should have been one] was saved, go to /var/adm/crash and look for a crash.XX directory (where XX starts at 0 and goes up based on the last crash). Check for one from April 18th and give the dump to support if you wish to find out exactly what happened.
If you want to try to figure it out yourself, you really should contact support to get the crashinfo tool [since otherwise, you'll spend a lot of time figuring out how to get what it will summarize for you]. Or use kwdb -q4 in the dump directory, and post the result of "examine &msgbuf+0x8 using s" -- the message buffer up to the panic (and any stack) may give us some idea.
If it really was an externally driven TOC, though, the dump won't know much other than "We got a TOC". If ServiceGuard did it, the dump could indicate why with a bit of work (again, crashinfo would help sum this up).
