Message-ID: <CAMfhKb8JivdHv6ihgHDtVGuM5ETmc+K6=qd8a0Ap3kwPkHTxSw@mail.gmail.com>
Date:   Fri, 12 Apr 2019 16:26:30 +0900
From:   Jinyoung Park <jinyoungp@...dia.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Ketan Patil <ketanp@...dia.com>,
        Alex Van Brunt <avanbrunt@...dia.com>
Subject: Fwd: [PATCH 1/1] arch: arm64: process: Unlock console after SMP stopped

(Re-sending)

I have observed this problem during reboot stress test on my ARM64
architecture board which is NVIDIA Tegra ARM64 CPU reference board.
The reboot stress test is to restart the system repeatedly for a long
time. The system is set with Kernel log level 8 for logging all kernel
messages during the tests.
I could see that sometimes latter part of the Kernel messages were
broken(or omitted).
So I have debugged this issue and made this patch.

The console_unlock() function emits all buffered messages in printk
log buffer prior to release the console lock.
This patch calls the console_unlock() after SMP stopped before
performing machine/architecture specific pm(reboot/power off) code.
This is to ensure no more additional messages from other process and
flush out all messages buffered in printk log buffer before the system
is restarted or power off.

> why this is only an ARM64 problem (or why you are only fixing this on ARM64 and not any of the other architectures.)
Honestly I am not sure that this issue is existing on other architectures.
Because my platform is ARM64 architecture and I have observed/verified
this problem with my patch on ARM64 only.

Thanks,
Jinyoung.

2019년 4월 9일 (화) 오후 11:21, Russell King - ARM Linux admin
<linux@...linux.org.uk>님이 작성:

>
> On Tue, Apr 09, 2019 at 11:17:14PM +0900, Jinyoung Park wrote:
> > If the console lock is held by other CPU running while the system is
> > restarting or shutting down, the Kernel messages in the printk log buffer
> > can not be printed out to the console drivers. The Kernel messages can be
> > lost or messed up.
> > This change calls console_unlock after SMP stopped to flush the kernel
> > messages in the printk log buffer to the console drivers.
>
> I think you need to explain how we can get to each of these points
> while the current CPU is holding the console lock - and why this is
> only an ARM64 problem (or why you are only fixing this on ARM64 and
> not any of the other architectures.)
>
> >
> > Signed-off-by: Jinyoung Park <jinyoungp@...dia.com>
> > ---
> >  arch/arm64/kernel/process.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 3767fb21a5b8..d629a75c7602 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -49,6 +49,7 @@
> >  #include <trace/events/power.h>
> >  #include <linux/percpu.h>
> >  #include <linux/thread_info.h>
> > +#include <linux/console.h>
> >
> >  #include <asm/alternative.h>
> >  #include <asm/arch_gicv3.h>
> > @@ -164,6 +165,7 @@ void machine_halt(void)
> >  {
> >   local_irq_disable();
> >   smp_send_stop();
> > + console_unlock();
> >   while (1);
> >  }
> >
> > @@ -177,6 +179,7 @@ void machine_power_off(void)
> >  {
> >   local_irq_disable();
> >   smp_send_stop();
> > + console_unlock();
> >   if (pm_power_off)
> >   pm_power_off();
> >  }
> > @@ -195,6 +198,7 @@ void machine_restart(char *cmd)
> >   /* Disable interrupts first */
> >   local_irq_disable();
> >   smp_send_stop();
> > + console_unlock();
> >
> >   /*
> >   * UpdateCapsule() depends on the system being reset via
> > --
> > 2.19.0
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@...ts.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

Powered by blists - more mailing lists