Re: Analysing a kernel panic

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/