On 06/01/2015 07:27, Maciej W. Rozycki wrote:
> On Sun, 31 May 2015, Joshua Kinard wrote:
>
>>> Can you please try this diagnostic patch and report the value of FCSR
>>> printed ("FCSR is:"), and also tell me if the exception has now gone too?
>>>
>>> I'll submit the final fix, properly annotated, if your testing confirms
>>> my diagnosis.
>>
>> That got it to boot again. I added CPU ID to the printk as well, and got some
>> odd output from one of the CPUs:
>>
>> # dmesg | grep FCSR
>> [ 0.000000] CPU0: FCSR is: 00000000
>> [ 0.319158] CPU1: FCSR is: 00000000
>> [ 0.364971] CPU2: FCSR is: ffffffffa8000000
>> [ 0.404854] CPU3: FCSR is: 00000000
>
> The value reported for CPU2 merely shows FCC[7,5,3] bits set, nothing
> really odd about that, the CPU may well have come out of reset like this.
> Neither of the values reported though actually corresponds to the symptom
> you saw, can you double-check you didn't make a typo in your modification
> to `printk'?
I commented on it being odd because out of four CPUs, #2 was coming up with a
sign-extended value, twice (I tested two reboot cycles, same both times). I'm
not fully knowledgable of IP27 hardware, and am probably one of the few on the
planet in possession of R14K node boards, so this might be a quirk of these
specific nodes. Would need others to test to verify, I guess.
Could always turn on heavy diags and poke through the verbose MSC reporting if
needed.
As for a typo, nope:
__enable_fpu(FPU_AS_IS);
fcsr = read_32bit_cp1_register(CP1_STATUS);
-> pr_info("CPU%d: FCSR is: %08lx\n", smp_processor_id(), fcsr);
fcsr &= ~mask;
--J
