Re: [resend][bug] low-probability console lockups since 5.19

From: Conor Dooley
Date: Thu Sep 29 2022 - 17:23:04 EST


On Thu, Sep 29, 2022 at 04:19:03PM +0206, John Ogness wrote:
> On 2022-09-29, Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
> > I will, possibly tonight but probably not, run the bisection again
> > with the threaded printer merge reverted. Hopefully it is not filled
> > with conflicts if I go that way...
>
> It might be easier for you to just apply the following patch to run your
> tests . This simple patch disables kthread usage.

Thanks a million John, restarted bisection from master prior to the
merge of the reverts & have ended up finding the actual issue thanks
to your hack - a RISC-V specific clocksource change. I'll close the
regzbot issue & open a new one against the actual source of my issues.

#regzbot invalid: bisection lead me up the garden path

It looks like I have an issue that's caused by the PCI controller driver
on this SoC* which triggers RCU stalls - but thanks to the clocksource
issue the RCU stalls never get reported & the system just locks up. The
system locked up in the same place on the kthreads branch so I guess I
just got unlucky with my bisection because of that.

Thanks again for the hack to bisect with,
Conor.

* likely due to running the wrong FPGA bitstream, the root port's
connection to the cpus is configured by the FPGA fabric.

>
> John Ogness
>
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index b095fb5f5f61..9679887c0805 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3605,6 +3605,10 @@ static int __init printk_activate_kthreads(void)
> {
> struct console *con;
>
> + /* hack: never activate kthreads */
> + if (!printk_kthreads_available)
> + return 0;
> +
> console_lock();
> printk_kthreads_available = true;
> for_each_console(con)