ls1021a spurious interrupts duart0

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

ls1021a spurious interrupts duart0

825 次查看
marcojankovic
Contributor II

Hi,

I'm using a custom board with the ls1021a. I m running on Linux 4.4 (linux-fslc-4.4).

Im facing this issue on the duart0 (or 1).

Depending on the boot linux detects irq 31 to be spurious.

I have two cases.

Either the boot completes properly  (with /proc/interrupts at the end of the boot, i have around 575 interrupts).

And i have no problem.

Or

During linux boot, at some points i have this message from the kernel  (/proc/interrupts i have 200 001 interrupts) :

 

irq 31: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 67 Comm: irq/31-serial Not tainted 4.4.0-TQMLS102xA-BSP-0102-rt3+ #6
Hardware name: Freescale LS1021A
Backtrace:
[<c0013774>] (dump_backtrace) from [<c0013964>] (show_stack+0x18/0x1c)
 r6:0000001f r5:00000000 r4:c0fdb8e0 r3:00000000
[<c001394c>] (show_stack) from [<c02505d4>] (dump_stack+0x90/0xa4)
mperature ambia[<c0250544>] (dump_stack) from [<c0061458>] (__report_bad_irq+0x34/0xc8)
 r5:ef4bea28 r4:ef4be9c0
[<c0061424>] (__report_bad_irq) from [<c006189c>] (note_interrupt+0x294/0x2e4)
 r6:0000001f r5:00000000 r4:ef4be9c0 r3:0001863c
[<c0061608>] (note_interrupt) from [<c005ea80>] (handle_irq_event_percpu+0xdc/0x158)
 r10:00000002 r9:c03cfc44 r8:c0fe567e r7:ef4be9c0 r6:0000001f r5:00000002
 r4:00000000 r3:00000000
[<c005e9a4>] (handle_irq_event_percpu) from [<c005eb78>] (handle_irq_event+0x7c/0xb4)
 r10:c005fc50 r9:f0803000 r8:ef408000 r7:00000001 r6:00000000 r5:c0fdba04
 r4:ef4be9c0
[<c005eafc>] (handle_irq_event) from [<c006215c>] (handle_fasteoi_irq+0xbc/0x258)
 r5:c0fdba04 r4:ef4be9c0
[<c00620a0>] (handle_fasteoi_irq) from [<c005e06c>] (generic_handle_irq+0x2c/0x3c)
 r6:00000000 r5:00000000 r4:c0fcad98 r3:c00620a0
[<c005e040>] (generic_handle_irq) from [<c005e354>] (__handle_domain_irq+0x64/0xb8)
[<c005e2f0>] (__handle_domain_irq) from [<c0009444>] (gic_handle_irq+0x50/0x90)
 r8:ed7d7e80 r7:f080200c r6:c0fdba00 r5:c0fd2068 r4:f0802000 r3:ed7d7e80
[<c00093f4>] (gic_handle_irq) from [<c00144d4>] (__irq_svc+0x54/0xa4)
Exception stack(0xed7d7e80 to 0xed7d7ec8)
7e80: ef4bea28 f0800000 00002004 000027c8 ef4be9c0 ed76ba40 ef4bea28 ef4be9d0
7ea0: ef4be9c0 ed76ba40 c005fc50 ed7d7edc ed7d7ee0 ed7d7ed0 c005fb8c c03cfc44
7ec0: a0000113 ffffffff
 r9:ed76ba40 r8:ef4be9c0 r7:ed7d7eb4 r6:ffffffff r5:a0000113 r4:c03cfc44
[<c03cfc1c>] (_raw_spin_unlock_irq) from [<c005fb8c>] (irq_finalize_oneshot+0x78/0x100)
[<c005fb14>] (irq_finalize_oneshot) from [<c005fc88>] (irq_forced_thread_fn+0x38/0x5c)
 r7:00000001 r6:00000000 r5:ef4be9c0 r4:ed76ba40
[<c005fc50>] (irq_forced_thread_fn) from [<c005ff48>] (irq_thread+0x12c/0x1f0)
 r6:00000000 r5:ed7d6000 r4:ed76ba64 r3:00000004
[<c005fe1c>] (irq_thread) from [<c003ad9c>] (kthread+0xd8/0xf0)
 r10:00000000 r9:00000000 r8:00000000 r7:c005fe1c r6:ed76ba40 r5:00000000
 r4:ed76ba80
[<c003acc4>] (kthread) from [<c000fa60>] (ret_from_fork+0x14/0x34)
 r7:00000000 r6:00000000 r5:c003acc4 r4:ed76ba80
handlers:
[<c005ebb0>] irq_default_primary_handler threaded [<c0297a00>] serial8250_interrupt
Disabling IRQ #31

 

In my kernel config i have for the uart :

SERIAL_8250

SERIAL_8250_CONSOLE

SERIAL_8250_EXTENDED

SERIAL_8250_SHARE_IRQ

 

I have attached my kernel_config and the dtsi.

 

Any advice for debugging this issue will be welcomed.

 

thanks you for any information about this issue.

 

Marco

Original Attachment has been moved to: kernel_config.zip

Original Attachment has been moved to: ls1021a.dtsi.zip

0 项奖励
回复
2 回复数

669 次查看
marcojankovic
Contributor II

Hi,

Thank you for your quick reply. I found the issue since then.

I tested on my board to pass my kernel configuration from PREMPT_NONE (where i had no IRQ problems) to PREEMPT_RTB.

This modification changes the RCU subsytem from RCU_TREE to RCU_PREEMPT and some other options. This  configuration was leading to the my random spurious IRQ issues from the DUART.

Is this an expected behaviour ?

Regards.

0 项奖励
回复

669 次查看
ufedor
NXP Employee
NXP Employee

Could you replicate the issue using NXP Linux SDK?

0 项奖励
回复