Re: Problems with device driver interrupts

On 15 Feb 2008 10:26:57 GMT, andrew@xxxxxxxxxxxxxxxxxxxx (Andrew
Gabriel) wrote:

You load your driver (the firmware part threw me - it looked like you
were expecting _that_ to cause an interrupt) and your interrupt
routine gets called when you didn't expect an interrupt. The system
gets funky.

In your interupt code, are you returning DDI_INTR_UNCLAIMED after
verifying that it is _not_ your board interrupting, and returning
DDI_INTR_CLAIMED when you detect (by register read or ??) that your
board _is_ interrupting.

As you know, PCI interrupts can be shared. AFAIK, all interrupt
routines on a shared interrupt get called by the kernel interrupt
code when an int occurs on that line. I'm _guessing_ that the
kernel stops calling the int handler chain at the first "CLAIMED"
return. If it wasn't you, and you return CLAIMED and your code
gets called before that actually interrupting device, that device
doesn't know to reset its int, and the interrupt handler chain gets
called again...and again...

All interrupt handlers for that interrupt will be called -- there
could be more than one device interrupting. If you don't return
CLAIMED, then an error about unserviced interrupts will eventually
be generated. If interrupts on a line are not being serviced by any
driver repeatedly, I think some action is taken to mask them out
(maybe different on different platforms).

If your device is generating an interrupt and you aren't doing
whatever it requires to satisfy/cancel that interrupt, then the
system may go into an interrupt loop, repeatedly representing an
interrupt which you aren't clearing.

My device is not generating an interrupt. I understand that if my
device is generating an interrupt and I don't CLAIM the interrupt, the
system will go into an interrupt loop. Windows OS does the same thing.
Probably most OSs.

I'm on disability and working at home. I might have to wait until I
return to work and hook up a bus and logic analyzer to really see if
the device is generating an interrupt. I don't think it is. The device
works ok in Windows.
.

Relevant Pages

  • RE: [PATCH 2.4.31 1/1] scsi/megaraid2: add 64-bit application sup ?port
    ... +static inline int ... * Interrupt ackrowledgement sequence for IO mapped HBAs ... -static inline void ...
    (Linux-Kernel)
  • Re: [PATCH 06/12] xen pci platform device driver
    ... for initializing the grant table and xenbus in PV on HVM mode. ... interrupt or using the callback ... Both the callback handler and the Xen platform PCI interrupt handler ... static int gnttab_free_count; ...
    (Linux-Kernel)
  • [PATCH 1/1] mxser, remove it
    ... -static int calloutmajor = MXSERCUMAJOR; ... * This routine is called whenever a serial port is opened. ... * enables interrupts for a serial port, linking in its async structure into ... * async structure from the interrupt chain if necessary, ...
    (Linux-Kernel)
  • [PATCH] pass irq handling status down to low-level code
    ... In order for low-level code to know whether/how a hardware interrupt ... -fastcall unsigned int do_IRQ(struct pt_regs *regs) ... This branches to the correct hardware IRQ handler via ... -asmlinkage unsigned int do_IRQ ...
    (Linux-Kernel)
  • [PATCH 3/5][time][x86_64] Split x86_64/kernel/time.c up
    ... +unsigned int do_gettimeoffset_hpet ... * it to the HPET timer of known frequency. ... +/* HPET in LegacyReplacement Mode eats up RTC interrupt line. ...
    (Linux-Kernel)