Apply f2928e224d85e7cc139009ab17cefdfec2df5d11 to 5.15 and 5.10?

[Nathan Chancellor]

On Fri, Aug 12, 2022 at 05:00:57PM +0000, Conor.Dooley at microchip.com wrote:
> 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.

I am merely doing basic QEMU boot tests, primarily to catch regressions
in LLVM. There have been times where I see crashes or failed assertions
in LLVM or boot problems in QEMU that are only visible when building the
stable trees versus mainline and -next so they tend to be useful for
that reason. I don't have any RISC-V hardware though; if I did, I'd be
running mainline, so I wouldn't worry much about backporting past 5.15
if that is what you do now. I can always request fixes such as this out
of band :)

> For this patch itself, I think the actual effect depends on what your
> SBI implementation does.

I am using tip-of-tree QEMU, which should have a fairly recent copy of
SBI, which likely explains why this patch resolves the issue.

Cheers,
Nathan