On Wed, 19 Mar 2014, BERTRAND Joël wrote:
Same reboot this morning :
trap type 0x68: cpu 1, pc=410657c0 npc=410657ac
pstate=0xffffffff99820092<,PEF,IE>
Skipping crash dump on recursive panic
panic: +fast data access MMU miss
cpu1: Begin traceback...
cpu1: End traceback...
cpu0: shutting down
cpu1: rebooting
Strange. It claims to have taken a trap type 68 which is an MMU miss, but
those messages come from trap() and the MMU miss code doesn't call that
routine.
A trap 68 should execute either the code at ufast_DMMU_miss if running in
user mode, or kfast_DMMU_miss if running kernel mode. Both do the same
thing: look for a matching entry in the TSB, or punt to data_miss if it
can't be found.
The code at data_miss will walk the page tables looking for a matching
entry. If the entry is not found it will usually generate an NFO entry
and return. There's some complicated code in case of ditry register
windows, but that mostly calls data_access_fault() not trap(), and
data_access_fault() prints "data_access_fault" not "trap type" which comes
from trap()
The only path I see from the miss handler to trap() is locore.s:1752 which
is a rather nasty corner case where the CPU took a MMU miss fault while
trying to save state to handle a data fault, which should never happen.
The problem is, the jump to slowtrap happens shortly after a software
initiated reset instruction, which should reset the machine and bomb out
to the firmware.
So I find this crash really strange. Maybe enabling DDB and dumping some
registers will shed some light on this panic.