[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0256a0a0139c56db75cffa4fe14079ad@kernel.org>
Date: Wed, 18 Nov 2020 09:08:36 +0000
From: Marc Zyngier <maz@...nel.org>
To: Naresh Kamboju <naresh.kamboju@...aro.org>
Cc: open list <linux-kernel@...r.kernel.org>,
linux- stable <stable@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sasha Levin <sashal@...nel.org>
Subject: Re: WARNING: kernel/irq/chip.c:242 __irq_startup+0xa8/0xb0
Naresh,
On 2020-11-18 06:11, Naresh Kamboju wrote:
> On Tue, 13 Oct 2020 at 11:09, Naresh Kamboju
> <naresh.kamboju@...aro.org> 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?
>
> [ 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?
> [ 20.000775] Hardware name: Freescale Layerscape 2088A RDB Board (DT)
> [ 20.000779] pstate: 60000085 (nZCv daIf -PAN -UAO)
> [ 20.018253] pc : __irq_startup+0x9c/0xa8
> [ 20.018256] lr : irq_startup+0x64/0x130
> [ 20.018259] sp : ffff80001122f8e0
> [ 20.029303] x29: ffff80001122f8e0 x28: ffff0082c242d400
> [ 20.029306] x27: ffffdd0f47234768 x26: 0000000000020902
> [ 20.029309] x25: ffffdd0f461a6f10 x24: ffffdd0f461a6bc8
> [ 20.029311] x23: 0000000000000000 x22: 0000000000000001
> [ 20.029314] x21: 0000000000000001 x20: ffff0082c22f8780
> [ 20.029316] x19: ffff0082c1060800 x18: 0000000000000001
> [ 20.029318] x17: 0000000000000000 x16: ffff8000114a0000
> [ 20.029321] x15: 0000000000000000 x14: ffff0082c0e92f90
> [ 20.071738] x13: ffff0082c0e93080 x12: ffff800011460000
> [ 20.071741] x11: dead000000000100 x10: 0000000000000040
> [ 20.071743] x9 : ffffdd0f47093ba8 x8 : ffffdd0f47093ba0
> [ 20.087653] x7 : ffff0082a00002b0 x6 : ffffdd0f47074958
> [ 20.087655] x5 : ffffdd0f47074000 x4 : ffff800011230000
> [ 20.087657] x3 : 0000000000000504 x2 : 0000000000000001
> [ 20.103567] x1 : 0000000003032004 x0 : ffff0082c1060858
> [ 20.103570] Call trace:
> [ 20.103573] __irq_startup+0x9c/0xa8
> [ 20.103577] irq_startup+0x64/0x130
> [ 20.118359] __enable_irq+0x7c/0x88
> [ 20.118362] enable_irq+0x54/0xa8
> [ 20.118367] serial8250_do_startup+0x658/0x718
> [ 20.118371] serial8250_startup+0x38/0x48
Looking at the DT:
serial0: serial@...0500 {
interrupts = <0 32 0x4>; /* Level high type */
serial1: serial@...0600 {
interrupts = <0 32 0x4>; /* Level high type */
serial2: serial@...0500 {
interrupts = <0 33 0x4>; /* Level high type */
serial3: serial@...0600 {
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.
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).
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists