Re: IP27: R14000: Unexpected General Exception in cpu_set_fpu_fcsr_mask()

[Joshua Kinard <kumba@gentoo.org>]

On 05/31/2015 20:09, Maciej W. Rozycki wrote:
> On Sat, 30 May 2015, Joshua Kinard wrote:
> 
>> MMC:
>> 2A 000: *** General Exception on node 0
>> 2A 000: *** EPC: 0xa800000000022178 (0xa800000000022178)
>> 2A 000: *** Press ENTER to continue.
>> 2A 000: POD MSC Unc> why
>> 2A 000:  EPC    : 0xa800000000022178 (0xa800000000022178)
>> 2A 000:  ERREPC : 0xffffffffbfc00ee0 (0xc00000001fc00ee0)
>> 2A 000:  CACERR : 0x00000000d6d7ff21
>> 2A 000:  Status : 0x0000000024407c80
>> 2A 000:  BadVA  : 0x0000000000000000 (0x0)
>> 2A 000:  RA     : 0xa8000000008771cc (0xa8000000008771cc)
>> 2A 000:  SP     : 0xa80000000081be00
>> 2A 000:  A0     : 0x00000000000051a1
>> 2A 000:  Cause  : 0x000000000000c03c (INT:87------ <Float Pt. Exc>)
>> 2A 000:  Reason : 242 (Unexpected General Exception.)
>> 2A 000:  POD mode was called from: 0xc00000001fc027ec (0xc00000001fc027ec)
>> 2A 000: POD MSC Unc>
>>
>> Address 0xa800000022178 centers around line 85 in 4.1.0-rc4's
>> arch/mips/cpu-probe.c:
>>
>> 85:         write_32bit_cp1_register(CP1_STATUS, fcsr0);
>>     a80000000002216c:       3c020003        lui     v0,0x3
>>     a800000000022170:       3445ffff        ori     a1,v0,0xffff
>>     a800000000022174:       00851024        and     v0,a0,a1
>> --> a800000000022178:       44c2f800        ctc1    v0,$31
>>     a80000000002217c:       00000000        nop
>>
>> Looks like cpu_set_fpu_fcsr_mask() was added in April sometime:
>>
>> http://git.linux-mips.org/cgit/ralf/linux.git/commit/arch/mips/kernel/cpu-probe.c?id=9b26616c8d9dae53fbac7f7cb2c6dd1308102976
> 
>  Thanks for your report and the accurate details!
> 
>> Not sure what else can be gleaned.  Seems this version of the R14K (v1.4)
>> doesn't like that FCSR mask.  Don't recall the Octane complaining about this,
>> but I'll try to double-check tomorrow.  It's got a newer rev of R14K silicon.
>> Might be an errata.
> 
>  Nope, it looks to me like sloppy firmware leaving IEEE 754 exception 
> cause and enable bits set behind in FCSR.  Upon writing them back with the 
> same values an FPE exception is triggered as per the semantics of the CTC1 
> instruction (we have some issues elsewhere with that, e.g. try writing
> ~0 to $fsr manually under GDB in a program that uses the FPU and then
> resuming execution).  I overlooked this possibility.  So it looks to me 
> like we need to mask the enables out here and leave the state of FCSR 
> clobbered after r/w mask probing.

ARCS, sloppy?  Never!


>  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

--J