interrupt lockups & segfaults / custom hardware

[Paul Miller]

I made a custom board that interfaces a Philips SJA1000 CAN controller to my 
PC's PCI bus.  The device works fine until I start receiving lots of 
interrupts from received CAN messages, and the PC completely locks up.  I'm 
sending 3 messages every 10ms from a DSP.  It usually takes 10-60 seconds for 
a lockup on a 2.66GHz P4.  Here are the details:

First, the chip's interrupt line is active low and remains low until it's 
interrupt vector is read.  If Linux doesn't run my ISR immediately, the pin 
is remains low.  Is this a problem?  I'm wondering if Linux clears the PC 
interrupt and adds my ISR to a queue to be run.  If so, I would expect Linux 
to be receiving thousands on interrupts before the interrupt is actually 
cleared.  This may explain why I'm receiving thousands of interrupts that 
have a null interrupt vector (no interrupt source).  Can I make the interrupt 
edge-triggered?  I suspect I'll need to redesign my hardware.

Second, if I do not service the interrupt (return IRQ_NONE) I get a message in 
syslog that the interrupt occurred and was disabled because 'nobody cared', 
which is fine, but then a segfault appears in syslog.  I suspect this is a 
bug in the kernel.

Aug 31 14:20:18 coecsl24 kernel: irq 17: nobody cared!
Aug 31 14:20:18 coecsl24 kernel:  [__report_bad_irq+42/139] 
__report_bad_irq+0x2
a/0x8b
Aug 31 14:20:18 coecsl24 kernel:  [note_interrupt+111/159] 
note_interrupt+0x6f/0
x9f
Aug 31 14:20:18 coecsl24 kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
Aug 31 14:20:18 coecsl24 kernel:  [common_interrupt+24/32] 
common_interrupt+0x18
/0x20
Aug 31 14:20:18 coecsl24 kernel: handlers:
Aug 31 14:20:18 coecsl24 kernel: [__crc_mii_link_ok+376944/1089141] 
(snd_intel8x
0_interrupt+0x0/0x23c [snd_intel8x0])
Aug 31 14:20:18 coecsl24 kernel: Disabling IRQ #17

2.6.x Kernels, tested with 2.6.7 and 2.6.8.1..

Thanks!
-Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/