Re: UltraSPARC III... Stability issue ?

Eduardo Horvath a écrit :
> 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.

	Very strange. I have rebuilt a debug kernel (6.99.37). Old kernel 
(6.99.36) panics with trap 68 on high I/O (I have seen this bug during a 
source tree update...). I'm unable to reproduce this panic with 6.99.37. 
6.99.31 was rock solid.

	I will try to rebuild a kernel without debug information as my 
blade2000 is now stable but very slow...

	Regards,

	JKB