Analysing a kernel panic

Guillaume Dargaud dargaud at
Tue Jul 12 00:38:18 EST 2011

> Ok, I'm not familiar with that PIC. You need to check what's going on
> between the PIC, your interrupt source and the kernel.
> Normally, if it's an edge interrupt,  it's a single event that gets
> latched by the PIC. The kernel will then call ack() on that PIC driver
> (irq_chip) which should clear that latch -before- getting into your
> device driver for processing.
> Also, the interrupt shall either be masked while processing or if it
> re-enters, the PIC code shall try to mask it (lazy masking) until the
> original handler completes at which point it gets unmasked. That shall
> be handled by the standard flow handlers, so it really depends on how
> you hookup your PIC in SW.

This should be all this:

static int xad_driver_probe(struct of_device* dev, const struct of_device_id *match) {
	struct device_node *dn = dev->node;
	Xad.irq = irq_of_parse_and_map(dn, 0);
"XadIsr", &Xad);

IIRC IRQF_DISABLED is obsolete (I've tried without).

What mystifies me is that:
- my same code on slightly different hardware works perfectly (the differences are not relevant to the driver but to the 
user application).
- a simplified standalone code works (so, non-linux).

Guillaume Dargaud

More information about the Linuxppc-dev mailing list