| Message ID | 1592308864-30205-1-git-send-email-yash.shah@sifive.com |
|---|---|
| Headers | show |
| Series | Dynamic CPU frequency switching for the HiFive | expand |
> -----Original Message----- > From: David Abdurachmanov <david.abdurachmanov@gmail.com> > Sent: 01 July 2020 17:34 > To: Andreas Schwab <schwab@suse.de> > Cc: Yash Shah <yash.shah@sifive.com>; devicetree@vger.kernel.org; Albert > Ou <aou@eecs.berkeley.edu>; Atish Patra <atish.patra@wdc.com>; Anup > Patel <anup@brainfault.org>; lollivier@baylibre.com; linux- > kernel@vger.kernel.org List <linux-kernel@vger.kernel.org>; Green Wan > <green.wan@sifive.com>; Sachin Ghadi <sachin.ghadi@sifive.com>; > robh+dt@kernel.org; Palmer Dabbelt <palmer@dabbelt.com>; > deepa.kernel@gmail.com; Paul Walmsley ( Sifive) > <paul.walmsley@sifive.com>; Alistair Francis <alistair.francis@wdc.com>; > linux-riscv <linux-riscv@lists.infradead.org>; Bin Meng > <bmeng.cn@gmail.com> > Subject: Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Wed, Jul 1, 2020 at 1:41 PM Andreas Schwab <schwab@suse.de> wrote: > > > > On Jun 16 2020, Yash Shah wrote: > > > > > The patch series adds the support for dynamic CPU frequency > > > switching for FU540-C000 SoC on the HiFive Unleashed board. All the > > > patches are based on Paul Walmsley's work. > > > > > > This series is based on Linux v5.7 and tested on HiFive unleashed board. > > > > I'm using that patch with 5.7.5. > > > > It appears to interfer with serial output when using the ondemand > > governor. > > I do recall that userspace governor is the only one supported but this might > have changed before this patch was posted. > > Yash, do you have more details? Yes, you are right. The userspace governor is the only one supported. - Yash > > > > > I also see soft lockups when using the performance governor: > > > > [ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU > > [ 101.592322] rcu: 0-...!: (932 ticks this GP) > idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4 > > [ 101.601432] (t=6001 jiffies g=4017 q=859) [ 101.605514] rcu: > > rcu_sched kthread starved for 5984 jiffies! g4017 f0x0 > > RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=2 [ 101.615494] rcu: RCU grace- > period kthread stack dump: > > [ 101.620530] rcu_sched R running task 0 10 2 0x00000000 > > [ 101.627560] Call Trace: > > [ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616 [ > > 101.635205] [<ffffffe00085abde>] schedule+0x42/0xb2 [ 101.640070] > > [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8 [ 101.645626] > > [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248 [ 101.651266] > > [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc [ 101.656651] > > [<ffffffe00022654e>] kthread+0xda/0xec [ 101.661426] > > [<ffffffe00020140a>] ret_from_exception+0x0/0xc [ 101.666977] Task > > dump for CPU 0: > > [ 101.670187] loop0 R running task 0 655 2 0x00000008 > > [ 101.677218] Call Trace: > > [ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa [ > > 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34 [ 101.690074] > > [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2 [ 101.696154] > > [<ffffffe00022bb9c>] sched_show_task+0x64/0x66 [ 101.701618] > > [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48 [ 101.706916] > > [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce [ 101.712731] > > [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a [ 101.718375] > > [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2 [ 101.723929] > > [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa [ 101.730094] > > [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea [ 101.735913] > > [<ffffffe00026d1be>] update_process_times+0x1e/0x42 [ 101.741821] > > [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52 [ 101.747456] > > [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0 [ 101.753015] > > [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8 > > [ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c [ > > 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4 [ > > 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a [ > > 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8 [ 101.781663] > > [<ffffffe00020140a>] ret_from_exception+0x0/0xc > > > > Andreas. > > > > -- > > Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 > > BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something > > completely different." > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Jul 03 2020, Yash Shah wrote:
> Yes, you are right. The userspace governor is the only one supported.
That doesn't make sense to me. How is the userspace governor different
from any other governor?
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hi Andreas, > -----Original Message----- > From: Andreas Schwab <schwab@suse.de> > Sent: 01 July 2020 16:11 > To: Yash Shah <yash.shah@sifive.com> > Cc: Paul Walmsley ( Sifive) <paul.walmsley@sifive.com>; > palmer@dabbelt.com; robh+dt@kernel.org; linux-riscv@lists.infradead.org; > linux-kernel@vger.kernel.org; devicetree@vger.kernel.org; Sachin Ghadi > <sachin.ghadi@sifive.com>; aou@eecs.berkeley.edu; anup@brainfault.org; > lollivier@baylibre.com; Green Wan <green.wan@sifive.com>; > atish.patra@wdc.com; alistair.francis@wdc.com; deepa.kernel@gmail.com; > bmeng.cn@gmail.com > Subject: Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Jun 16 2020, Yash Shah wrote: > > > The patch series adds the support for dynamic CPU frequency switching > > for FU540-C000 SoC on the HiFive Unleashed board. All the patches are > > based on Paul Walmsley's work. > > > > This series is based on Linux v5.7 and tested on HiFive unleashed board. > > I'm using that patch with 5.7.5. > > It appears to interfer with serial output when using the ondemand governor. > > I also see soft lockups when using the performance governor: > > [ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU > [ 101.592322] rcu: 0-...!: (932 ticks this GP) > idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4 > [ 101.601432] (t=6001 jiffies g=4017 q=859) [ 101.605514] rcu: rcu_sched > kthread starved for 5984 jiffies! g4017 f0x0 RCU_GP_WAIT_FQS(5) - > >state=0x0 ->cpu=2 [ 101.615494] rcu: RCU grace-period kthread stack > dump: > [ 101.620530] rcu_sched R running task 0 10 2 0x00000000 > [ 101.627560] Call Trace: > [ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616 [ 101.635205] > [<ffffffe00085abde>] schedule+0x42/0xb2 [ 101.640070] > [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8 [ 101.645626] > [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248 [ 101.651266] > [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc [ 101.656651] > [<ffffffe00022654e>] kthread+0xda/0xec [ 101.661426] [<ffffffe00020140a>] > ret_from_exception+0x0/0xc [ 101.666977] Task dump for CPU 0: > [ 101.670187] loop0 R running task 0 655 2 0x00000008 > [ 101.677218] Call Trace: > [ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa [ > 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34 [ 101.690074] > [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2 [ 101.696154] > [<ffffffe00022bb9c>] sched_show_task+0x64/0x66 [ 101.701618] > [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48 [ 101.706916] > [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce [ 101.712731] > [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a [ 101.718375] > [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2 [ 101.723929] > [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa [ 101.730094] > [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea [ 101.735913] > [<ffffffe00026d1be>] update_process_times+0x1e/0x42 [ 101.741821] > [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52 [ 101.747456] > [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0 [ 101.753015] > [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8 > [ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c [ > 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4 [ > 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a [ > 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8 [ 101.781663] > [<ffffffe00020140a>] ret_from_exception+0x0/0xc > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 > BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something > completely different." I am looking into the issues you reported. I will update soon. Thanks for testing. - Yash
On Mon, 06 Jul 2020 01:15:42 PDT (-0700), schwab@suse.de wrote: > On Jul 03 2020, Yash Shah wrote: > >> Yes, you are right. The userspace governor is the only one supported. > > That doesn't make sense to me. How is the userspace governor different > from any other governor? It's not. The issue here is that pretty much everything is on one clock, including all the cores and the simple IO devices. These IO devices have programmable clock dividers that need to mesh up with the input clock rate in order to operate correctly. There's no way to do that atomicly WRT the device's clock, so we have to pause device IO while messing with the clocks. I bet there's some issue with 4cbd7814bbd5 ("tty: sifive: Finish transmission before changing the clock") that's causing the serial to get corrupted, and I guess I'd start with all the issues I pointed out in the patch text :). Presumably we need to fix the SPI driver as well, in much the same fashion (though hopefully with fewer hardware surprises to work around). I'd be way more worried about ChipLink, as I don't know how that's clocked. IIRC Ethernet has its own clock so it should be safe. I'd be very skeptical about turning on dynamic frequency scaling for the HiFive Unleashed, as it's probably just not worth chasing the long tail of bugs. Even allowing the userspace governor is a bit sketchy, but given that it's a very early dev board I assume these sorts of problems are expected. If we do ever turn dynamic frequency scaling on it's not going to default to allowing 1.4GHz, from what I saw speeds much over 1GHz don't work for most people.