All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.