All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <palmer@dabbelt.com>, <gregkh@linuxfoundation.org>
Cc: <re@w6rz.net>, <nathan@kernel.org>, <sashal@kernel.org>,
	<dimitri.ledkov@canonical.com>, <anup@brainfault.org>,
	<stable@vger.kernel.org>, <linux-riscv@lists.infradead.org>
Subject: Re: Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10?
Date: Fri, 12 Aug 2022 17:00:57 +0000	[thread overview]
Message-ID: <bfd07e0f-f8e3-a904-667c-f9a69ebbd405@microchip.com> (raw)
In-Reply-To: <mhng-f5bbfb9c-755f-4abe-affd-5c40efd11105@palmer-ri-x1c9>

On 12/08/2022 17:40, Palmer Dabbelt wrote:
> On Fri, 12 Aug 2022 08:36:46 PDT (-0700), Greg KH wrote:
>> On Thu, Aug 11, 2022 at 08:23:21PM -0700, Ron Economos wrote:
>>> On 8/11/22 5:24 PM, Nathan Chancellor wrote:
>>> > Hi all,
>>> >
>>> > Would it be reasonable to apply commit f2928e224d85 ("riscv: set default
>>> > pm_power_off to NULL") to 5.10 and 5.15? I see the following issue when
>>> > testing OpenSUSE's RISC-V configuration in QEMU and it is resolved with
>>> > that change.
>>> >
>>> > Requesting system poweroff
>>> > [    4.497128][  T177] reboot: Power down
>>> > [   32.045207][    C0] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [init:177]
>>> > [   32.045785][    C0] Modules linked in:
>>> > [   32.046166][    C0] CPU: 0 PID: 177 Comm: init Not tainted 5.15.60-default #1 5b276f06901b1c37142db73337a1816290810c90
>>> > [   32.046814][    C0] Hardware name: riscv-virtio,qemu (DT)
>>> > [   32.047256][    C0] epc : default_power_off+0x1a/0x20
>>> > [   32.047667][    C0]  ra : machine_power_off+0x22/0x2a
>>> > [   32.047979][    C0] epc : ffffffff80004a4a ra : ffffffff80004abe sp : ffffffd000bc3d50
>>> > [   32.048405][    C0]  gp : ffffffff81bec160 tp : ffffffe002080000 t0 : ffffffff80490964
>>> > [   32.048827][    C0]  t1 : 0720072007200720 t2 : 50203a746f6f6265 s0 : ffffffd000bc3d60
>>> > [   32.049245][    C0]  s1 : 000000004321fedc a0 : 0000000000000004 a1 : ffffffff81b073c8
>>> > [   32.049676][    C0]  a2 : 0000000000000010 a3 : 00000000000000ab a4 : e0b1d187e51c7400
>>> > [   32.050115][    C0]  a5 : ffffffff80004a30 a6 : c0000000ffffdfff a7 : ffffffff804ea464
>>> > [   32.050555][    C0]  s2 : 0000000000000000 s3 : ffffffff81a20390 s4 : fffffffffee1dead
>>> > [   32.051009][    C0]  s5 : ffffffff81bee0c8 s6 : 0000003feff55a70 s7 : 0000002acc09bf08
>>> > [   32.051427][    C0]  s8 : 0000000000000001 s9 : 0000000000000000 s10: 0000002b0a4db6e0
>>> > [   32.051849][    C0]  s11: 0000000000000000 t3 : ffffffe001e2bf00 t4 : ffffffe001e2bf00
>>> > [   32.052274][    C0]  t5 : ffffffe001e2b000 t6 : ffffffd000bc3ac8
>>> > [   32.052604][    C0] status: 0000000000000120 badaddr: 0000000000000000 cause: 8000000000000005
>>> > qemu-system-riscv64: terminating on signal 15 from pid 2356237 (timeout)
>>> >
>>> > I am not sure if there is any regression potential with that change,
>>> > hence this email. That change applies cleanly to both trees and I don't
>>> > see any additional problems from it.
>>> >
>>> > Cheers,
>>> > Nathan
>>>
>>> Should be fine. I apply this patch to all of my 5.15.x stable builds to
>>> enable warm reboot on the HiFive Unmatched.
>>>
>>
>> Now queued up, thanks.
> 
> Thanks, though on a sort of related note: are folks actually running
> 5.10-based kernels on RISC-V?  I generally don't worry too much about
> trying to backport stuff that far.

FWIW our vendor kernel is on 5.15, I think .58? we are slightly behind,
I blame people being on holidays... We've backported all the PolarFire
stuff to that version so we're aligned with the ARM guys at Microchip.

I think the "official" kernel for the D1 is on 5.4. Outside of the
SiFive "demo"/test/w.e. boards, is there even anything much that would
even have been supported as of 5.10? The jh7100 stuff appears to only
have kernels starting after 5.13.

For this patch itself, I think the actual effect depends on what your
SBI implementation does. I see RCU stalls on "reboot" with and without
this patch added to our vendor tree (which I guess makes sense, it is
pm_power_off..) & "poweroff" does an ECALL & is handled so never stalls.

So backporting this particular may not even make a difference to
whoever is running a 5.10 kernel.

Conor.


WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <palmer@dabbelt.com>, <gregkh@linuxfoundation.org>
Cc: <re@w6rz.net>, <nathan@kernel.org>, <sashal@kernel.org>,
	<dimitri.ledkov@canonical.com>, <anup@brainfault.org>,
	<stable@vger.kernel.org>, <linux-riscv@lists.infradead.org>
Subject: Re: Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10?
Date: Fri, 12 Aug 2022 17:00:57 +0000	[thread overview]
Message-ID: <bfd07e0f-f8e3-a904-667c-f9a69ebbd405@microchip.com> (raw)
In-Reply-To: <mhng-f5bbfb9c-755f-4abe-affd-5c40efd11105@palmer-ri-x1c9>

On 12/08/2022 17:40, Palmer Dabbelt wrote:
> On Fri, 12 Aug 2022 08:36:46 PDT (-0700), Greg KH wrote:
>> On Thu, Aug 11, 2022 at 08:23:21PM -0700, Ron Economos wrote:
>>> On 8/11/22 5:24 PM, Nathan Chancellor wrote:
>>> > Hi all,
>>> >
>>> > Would it be reasonable to apply commit f2928e224d85 ("riscv: set default
>>> > pm_power_off to NULL") to 5.10 and 5.15? I see the following issue when
>>> > testing OpenSUSE's RISC-V configuration in QEMU and it is resolved with
>>> > that change.
>>> >
>>> > Requesting system poweroff
>>> > [    4.497128][  T177] reboot: Power down
>>> > [   32.045207][    C0] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [init:177]
>>> > [   32.045785][    C0] Modules linked in:
>>> > [   32.046166][    C0] CPU: 0 PID: 177 Comm: init Not tainted 5.15.60-default #1 5b276f06901b1c37142db73337a1816290810c90
>>> > [   32.046814][    C0] Hardware name: riscv-virtio,qemu (DT)
>>> > [   32.047256][    C0] epc : default_power_off+0x1a/0x20
>>> > [   32.047667][    C0]  ra : machine_power_off+0x22/0x2a
>>> > [   32.047979][    C0] epc : ffffffff80004a4a ra : ffffffff80004abe sp : ffffffd000bc3d50
>>> > [   32.048405][    C0]  gp : ffffffff81bec160 tp : ffffffe002080000 t0 : ffffffff80490964
>>> > [   32.048827][    C0]  t1 : 0720072007200720 t2 : 50203a746f6f6265 s0 : ffffffd000bc3d60
>>> > [   32.049245][    C0]  s1 : 000000004321fedc a0 : 0000000000000004 a1 : ffffffff81b073c8
>>> > [   32.049676][    C0]  a2 : 0000000000000010 a3 : 00000000000000ab a4 : e0b1d187e51c7400
>>> > [   32.050115][    C0]  a5 : ffffffff80004a30 a6 : c0000000ffffdfff a7 : ffffffff804ea464
>>> > [   32.050555][    C0]  s2 : 0000000000000000 s3 : ffffffff81a20390 s4 : fffffffffee1dead
>>> > [   32.051009][    C0]  s5 : ffffffff81bee0c8 s6 : 0000003feff55a70 s7 : 0000002acc09bf08
>>> > [   32.051427][    C0]  s8 : 0000000000000001 s9 : 0000000000000000 s10: 0000002b0a4db6e0
>>> > [   32.051849][    C0]  s11: 0000000000000000 t3 : ffffffe001e2bf00 t4 : ffffffe001e2bf00
>>> > [   32.052274][    C0]  t5 : ffffffe001e2b000 t6 : ffffffd000bc3ac8
>>> > [   32.052604][    C0] status: 0000000000000120 badaddr: 0000000000000000 cause: 8000000000000005
>>> > qemu-system-riscv64: terminating on signal 15 from pid 2356237 (timeout)
>>> >
>>> > I am not sure if there is any regression potential with that change,
>>> > hence this email. That change applies cleanly to both trees and I don't
>>> > see any additional problems from it.
>>> >
>>> > Cheers,
>>> > Nathan
>>>
>>> Should be fine. I apply this patch to all of my 5.15.x stable builds to
>>> enable warm reboot on the HiFive Unmatched.
>>>
>>
>> Now queued up, thanks.
> 
> Thanks, though on a sort of related note: are folks actually running
> 5.10-based kernels on RISC-V?  I generally don't worry too much about
> trying to backport stuff that far.

FWIW our vendor kernel is on 5.15, I think .58? we are slightly behind,
I blame people being on holidays... We've backported all the PolarFire
stuff to that version so we're aligned with the ARM guys at Microchip.

I think the "official" kernel for the D1 is on 5.4. Outside of the
SiFive "demo"/test/w.e. boards, is there even anything much that would
even have been supported as of 5.10? The jh7100 stuff appears to only
have kernels starting after 5.13.

For this patch itself, I think the actual effect depends on what your
SBI implementation does. I see RCU stalls on "reboot" with and without
this patch added to our vendor tree (which I guess makes sense, it is
pm_power_off..) & "poweroff" does an ECALL & is handled so never stalls.

So backporting this particular may not even make a difference to
whoever is running a 5.10 kernel.

Conor.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-08-12 17:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  0:24 Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10? Nathan Chancellor
2022-08-12  0:24 ` Nathan Chancellor
2022-08-12  3:23 ` Ron Economos
2022-08-12  3:23   ` Ron Economos
2022-08-12 15:36   ` Greg Kroah-Hartman
2022-08-12 15:36     ` Greg Kroah-Hartman
2022-08-12 16:40     ` Palmer Dabbelt
2022-08-12 16:40       ` Palmer Dabbelt
2022-08-12 17:00       ` Conor.Dooley [this message]
2022-08-12 17:00         ` Conor.Dooley
2022-08-15 16:31         ` Nathan Chancellor

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=bfd07e0f-f8e3-a904-667c-f9a69ebbd405@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=anup@brainfault.org \
    --cc=dimitri.ledkov@canonical.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=nathan@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=re@w6rz.net \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.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.