Linux Kernel
3.7.1
|
Go to the source code of this file.
Macros | |
#define | TRACE_SYSTEM irq |
#define | _TRACE_IRQ_H |
#define | softirq_name(sirq) { sirq##_SOFTIRQ, #sirq } |
#define | show_softirq_name(val) |
#define show_softirq_name | ( | val | ) |
DECLARE_EVENT_CLASS | ( | softirq | , |
TP_PROTO(unsigned int vec_nr) | , | ||
TP_ARGS(vec_nr) | , | ||
TP_STRUCT__entry(__field(unsigned int, vec)) | , | ||
TP_fast_assign(__entry->vec=vec_nr;) | , | ||
TP_printk("vec=%u [action=%s]", __entry->vec, show_softirq_name(__entry->vec)) | |||
) |
TRACE_EVENT | ( | irq_handler_entry | , |
TP_PROTO(int irq, struct irqaction *action) | , | ||
TP_ARGS(irq, action) | , | ||
TP_STRUCT__entry(__field(int, irq) __string(name, action->name)) | , | ||
TP_fast_assign(__entry->irq=irq;__assign_str(name, action->name);) | , | ||
TP_printk("irq=%d name=%s", __entry->irq, __get_str(name)) | |||
) |
irq_handler_entry - called immediately before the irq action handler : irq number : pointer to struct irqaction
The struct irqaction pointed to by contains various information about the handler, including the device name, ->name, and the device id, ->dev_id. When used in conjunction with the irq_handler_exit tracepoint, we can figure out irq handler latencies.
TRACE_EVENT | ( | irq_handler_exit | , |
TP_PROTO(int irq, struct irqaction *action, int ret) | , | ||
TP_ARGS(irq, action, ret) | , | ||
TP_STRUCT__entry(__field(int, irq) __field(int, ret)) | , | ||
TP_fast_assign(__entry->irq=irq;__entry->ret=ret;) | , | ||
TP_printk("irq=%d ret=%s", __entry->irq, __entry->ret?"handled":"unhandled") | |||
) |
irq_handler_exit - called immediately after the irq action handler returns : irq number : pointer to struct irqaction : return value
If the value is set to IRQ_HANDLED, then we know that the corresponding ->handler scuccessully handled this irq. Otherwise, the irq might be a shared irq line, or the irq was not handled successfully. Can be used in conjunction with the irq_handler_entry to understand irq handler latencies.