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


Attachment: pgppXfriCXwDj.pgp
Description: PGP signature

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to