On Fri, 10 Jul 2020 13:29:29 +0800, "e- d8 i> sunshilong" said:

[72873.713473] <IRQ> [72873.713474] switch_mm_irqs_off+0x31b/0x4e0 [72873.713475] xnarch_switch_to+0x2f/0x80 [72873.713476] ___xnsched_run.part.74+0x154/0x480 [72873.713476] ___xnsched_run+0x35/0x50 [72873.713477] xnintr_irq_handler+0x346/0x4c0 [72873.713478] ? xnintr_core_clock_handler+0x1b6/0x360 [72873.713479] dispatch_irq_head+0x8e/0x110 [72873.713479] ? xnintr_irq_handler+0x5/0x4c0 [72873.713481] ? dispatch_irq_head+0x8e/0x110 [72873.713482] __ipipe_dispatch_irq+0xd9/0x1c0 [72873.713483] __ipipe_handle_irq+0x86/0x1e0 [72873.713483] common_interrupt+0xf/0x2c [72873.713484] </IRQ>

Maybe, the later one(i.e. </IRQ>) implies there was an interrupt request and the common_interuppt() function handler it.

No. It's possible for the kernel traceback to include some routines that were in an IRQ, and some more that were outside IRQ context. So you can tell which are which, the stack dump is formatted as: <IRQ> function that was running when the trace was called for the function that call it another function back (...) interrupt_handler of some sort </IRQ> function that was running when the interrupt hit this caller and its parent etc