On Wed, 18 Nov 2020 at 14:38, Marc Zyngier <maz@xxxxxxxxxx> wrote:
>
> Naresh,
>
> On 2020-11-18 06:11, Naresh Kamboju wrote:
> > On Tue, 13 Oct 2020 at 11:09, Naresh Kamboju
> > <naresh.kamboju@xxxxxxxxxx> wrote:
> >>
> >> On stable rc 5.8.15 the following kernel warning was noticed once
> >> while boot and this is hard to reproduce.
> >
> > This is now reproduciable on arm64 NXP ls2088 device
>
> How reproducible? On demand? Once in a while?
Once in a while.
>
> >
> > [ 19.980839] ------------[ cut here ]------------
> > [ 19.985468] WARNING: CPU: 1 PID: 441 at kernel/irq/chip.c:242
> > __irq_startup+0x9c/0xa8
> > [ 19.985472] Modules linked in: rfkill lm90 ina2xx crct10dif_ce
> > qoriq_thermal fuse
> > [ 20.000773] CPU: 1 PID: 441 Comm: (agetty) Not tainted 5.4.78-rc1 #2
>
> Can you please try and reproduce this on mainline?
yes on mainline kernel.
[ 18.284440] ------------[ cut here ]------------
[ 18.289063] WARNING: CPU: 3 PID: 441 at kernel/irq/chip.c:242
__irq_startup+0xa8/0xb0
[ 18.296891] Modules linked in: rfkill caam crct10dif_ce error lm90
ina2xx qoriq_thermal fuse
[ 18.296914] CPU: 3 PID: 441 Comm: (agetty) Not tainted 5.10.0-rc3 #2
[ 18.311693] Hardware name: Freescale Layerscape 2088A RDB Board (DT)
[ 18.311697] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[ 18.311700] pc : __irq_startup+0xa8/0xb0
[ 18.311702] lr : irq_startup+0x64/0x140
[ 18.311708] sp : ffff800011b2f8f0
[ 18.335095] x29: ffff800011b2f8f0 x28: ffff724881a03800
[ 18.335100] x27: ffffa9adf65ff200 x26: 0000000000020902
[ 18.335104] x25: ffffa9adf522bb40 x24: ffffa9adf522b7f8
[ 18.351023] x23: 0000000000000000 x22: 0000000000000001
[ 18.351027] x21: 0000000000000001 x20: ffff724883dbc940
[ 18.351030] x19: ffff7248812a0800 x18: 0000000000000010
[ 18.351035] x17: 0000000000000000 x16: 0000000000000000
[ 18.366952] x15: ffff724883dbcdc0 x14: ffffffffffffffff
[ 18.366956] x13: ffff800011de0000 x12: ffff800011de0000
[ 18.366959] x11: 0000000000000040 x10: ffffa9adf63c64e0
[ 18.388178] x9 : ffffa9adf3f90c3c x8 : ffff7248a0000270
[ 18.388181] x7 : 0000000000000000 x6 : ffffa9adf6334aa8
[ 18.388185] x5 : ffffa9adf6334000 x4 : 0000000000000504
[ 18.388189] x3 : ffff7248812a0800 x2 : 0000000013032004
[ 18.404106] x1 : 0000000013032004 x0 : ffff7248812a0860
[ 18.404111] Call trace:
[ 18.404114] __irq_startup+0xa8/0xb0
[ 18.404116] irq_startup+0x64/0x140
[ 18.404123] __enable_irq+0x78/0x88
[ 18.427685] enable_irq+0x54/0xa8
[ 18.427689] serial8250_do_startup+0x670/0x718
[ 18.427692] serial8250_startup+0x30/0x40
[ 18.427696] uart_startup.part.0+0x12c/0x2e0
[ 18.427701] uart_port_activate+0x68/0xa0
[ 18.447701] tty_port_open+0x98/0x250
[ 18.447704] uart_open+0x24/0x38
[ 18.447707] tty_open+0x120/0x518
[ 18.447712] chrdev_open+0xac/0x1a8
[ 18.447718] do_dentry_open+0x134/0x3a0
[ 18.465200] vfs_open+0x34/0x40
[ 18.465203] path_openat+0x85c/0xde0
[ 18.465207] do_filp_open+0x80/0x108
[ 18.465209] do_sys_openat2+0x1ec/0x2a0
[ 18.465215] do_sys_open+0x60/0xa8
[ 18.482695] __arm64_sys_openat+0x2c/0x38
[ 18.482699] do_el0_svc+0xe0/0x210
[ 18.482702] el0_sync_handler+0x180/0x18c
[ 18.482705] el0_sync+0x174/0x180
[ 18.482710] ---[ end trace 12c4809389e4277f ]---
>
> Looking at the DT:
>
> serial0: serial@21c0500 {
> interrupts = <0 32 0x4>; /* Level high type */
>
> serial1: serial@21c0600 {
> interrupts = <0 32 0x4>; /* Level high type */
>
> serial2: serial@21d0500 {
> interrupts = <0 33 0x4>; /* Level high type */
>
> serial3: serial@21d0600 {
> interrupts = <0 33 0x4>; /* Level high type */
>
>
> The UART interrupt lines are shared. Braindead, 1980 style.
>
> Which UART is agetty trying to use? Is there any other process using
> another UART concurrently? We could have a race between the line being
> shut down on one device, and activated from the other, but I can't
> spot it right away.
>From the boot log,
Created slice system-getty.slice.
Created slice system-serial\x2dgetty.slice.
<>
Found device /dev/ttyS0.
Found device /dev/ttyS1.
<>
Started Getty on tty1.
Started Serial Getty on ttyS1.
Started Serial Getty on ttyS0.
Started Authorization Manager.
And the warning triggered.
>
> If you can reproduce it easily enough, it shouldn't be too hard to trace
> what happens around the activation of the shared interrupt (assuming
> that
> this is where the problem is).
We do not find easy steps to reproduce it.
This warning was noticed while booting once in 20 runs.
ref:
https://qa-reports.linaro.org/lkft/linux-mainline-master/build/v5.10-rc3-391-g9cfd9c45994b/testrun/3443291/suite/linux-log-parser/test/check-kernel-warning-138789/log
- Naresh
