Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Joshua Kinard <kumba@gentoo.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Linux MIPS List <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: IP27: R14000: Unexpected General Exception in cpu_set_fpu_fcsr_mask()
Date: Tue, 02 Jun 2015 14:56:50 -0400	[thread overview]
Message-ID: <556DFC72.9010705@gentoo.org> (raw)
In-Reply-To: <alpine.LFD.2.11.1506021208120.22908@eddie.linux-mips.org>

On 06/02/2015 07:32, Maciej W. Rozycki wrote:
> On Tue, 2 Jun 2015, Joshua Kinard wrote:
> 
>> 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.
> 
>  That's how the CFC1 instruction works, it sign-extends the 32-bit value 
> written to the destination register on 64-bit processors.  So if the chip 
> has come out of reset with FCSR.FCC[7] set, then the bit will be repeated 
> across bits 63:32 when the bit pattern from FCSR has been transferred to a 
> general-purpose register.
> 
>> 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;
> 
>  OK, thanks for confirming.  So it looks like the cause of the exception 
> vanished at the same time.  There's no harm in reinitialising FCSR here 
> though, any vendor-specific bits possibly set will be cleared on process 
> creation anyway.

I had a thought and moved the printk to be near the top of cpu_probe(), since
it was possible the value of fcsr was getting clobbered by earlier code.  sure
enough, I got saner-looking values:

From full power-down:
# dmesg | grep FCSR
[    0.000000] CPU0: FCSR is: 000051a1
[    0.319163] CPU1: FCSR is: d0828324
[    0.364956] CPU2: FCSR is: a8011980
[    0.404819] CPU3: FCSR is: 00000000

Following a warm reboot cycle:
# dmesg | grep FCSR
[    0.000000] CPU0: FCSR is: 00000000
[    0.319248] CPU1: FCSR is: 00000000
[    0.364920] CPU2: FCSR is: 00000000
[    0.404893] CPU3: FCSR is: 00000000

Following a second full power-down:
# dmesg | grep FCSR
[    0.000000] CPU0: FCSR is: c6001100
[    0.318236] CPU1: FCSR is: 908203a4
[    0.364976] CPU2: FCSR is: a9801888
[    0.404828] CPU3: FCSR is: 08000088

With your new patch posted, it boots up just fine.

--J

WARNING: multiple messages have this Message-ID (diff)
From: Joshua Kinard <kumba@gentoo.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Linux MIPS List <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: IP27: R14000: Unexpected General Exception in cpu_set_fpu_fcsr_mask()
Date: Tue, 02 Jun 2015 14:56:50 -0400	[thread overview]
Message-ID: <556DFC72.9010705@gentoo.org> (raw)
Message-ID: <20150602185650.YUdjoRp0gk2LX1Ro1maS8aedSnbwcm5zx_D7dabbCeY@z> (raw)
In-Reply-To: <alpine.LFD.2.11.1506021208120.22908@eddie.linux-mips.org>

On 06/02/2015 07:32, Maciej W. Rozycki wrote:
> On Tue, 2 Jun 2015, Joshua Kinard wrote:
> 
>> 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.
> 
>  That's how the CFC1 instruction works, it sign-extends the 32-bit value 
> written to the destination register on 64-bit processors.  So if the chip 
> has come out of reset with FCSR.FCC[7] set, then the bit will be repeated 
> across bits 63:32 when the bit pattern from FCSR has been transferred to a 
> general-purpose register.
> 
>> 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;
> 
>  OK, thanks for confirming.  So it looks like the cause of the exception 
> vanished at the same time.  There's no harm in reinitialising FCSR here 
> though, any vendor-specific bits possibly set will be cleared on process 
> creation anyway.

I had a thought and moved the printk to be near the top of cpu_probe(), since
it was possible the value of fcsr was getting clobbered by earlier code.  sure
enough, I got saner-looking values:

  reply	other threads:[~2015-06-02 18:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-30  5:00 IP27: R14000: Unexpected General Exception in cpu_set_fpu_fcsr_mask() Joshua Kinard
2015-06-01  0:09 ` Maciej W. Rozycki
2015-06-01  2:57   ` Joshua Kinard
2015-06-01 11:27     ` Maciej W. Rozycki
2015-06-01 20:16       ` Ralf Baechle
2015-06-02  4:56       ` Joshua Kinard
2015-06-02  6:51         ` Ralf Baechle
2015-06-02 11:42           ` Maciej W. Rozycki
2015-06-02 11:32         ` Maciej W. Rozycki
2015-06-02 18:56           ` Joshua Kinard [this message]
2015-06-02 18:56             ` Joshua Kinard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=556DFC72.9010705@gentoo.org \
    --to=kumba@gentoo.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox