Analysing a kernel panic

[Guillaume Dargaud]

> 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);
	rc=request_irq(Xad.irq, XadIsr, IRQF_TRIGGER_RISING  | IRQF_DISABLED | IRQF_SHARED /*| IRQF_SAMPLE_RANDOM*/, 
"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
http://www.gdargaud.net/