Thanks Gilles,
Do you mean to execute ipipe_trace_freeze instead of the warning and
kernel/irq/handle.c:146
?
I've recompiled the kernel with the following code in handle.c:146
13 irqreturn_t
12 handle_irq_event_percpu(struct irq_desc *desc, struct irqaction
*action)
11 {
10 irqreturn_t retval = IRQ_NONE;
9 unsigned int flags = 0, irq = desc->irq_data.irq;
8
7 do {
6 irqreturn_t res;
5
4 trace_irq_handler_entry(irq, action);
3 res = action->handler(irq, action->dev_id);
2 trace_irq_handler_exit(irq, action, res);
1
145 if (!irqs_disabled()) ipipe_trace_freeze(1);
1
2 if (WARN_ONCE(!irqs_disabled(),"irq %u handler %pF enabled
interrupts\n",
3 irq, action->handler))
4 local_irq_disable();
But this does not trigger trace freeze.
What is the 'unsigned int v' in the definition of ipipe_trace_freeze?
On 24 February 2014 22:00, Gilles Chanteperdrix <
[email protected]> wrote:
> On 02/24/2014 10:19 PM, Gregory Dymarek wrote:
> > Hi Gilles,
> >
> > I compiled the kernel width the stack unwind disabled and it throws the
> > same warning while booting: http://pastebin.com/mSTnPACr
> > [ 1.948056] WARNING: at kernel/irq/handle.c:146
> > handle_irq_event_percpu+0x198/0x1c0(
> > [ 1.959568] irq 32 handler usb_hcd_irq+0x0/0x84 enabled interrupts
> >
> > Also, when unlpugging USB devices I get kernel panics:
> > http://pastebin.com/Nr87y8Ki
>
> Yes, but we now have a clear trace, where we see that ipipe_do_irq is
> indeed called.
>
> >
> > What else would you need to see to identify the actual failure?
> > How should be the root domain stalled, how to look for it?
>
> The simplest solution is to enable the I-pipe tracer, and trigger a
> trace freeze instead of the warning.
>
> The I-pipe tracer should show us where the root domain is unstalled.
>
> --
> Gilles.
>
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
