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:
next prev parent 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