lost interrupt

I'm getting the dreaded "lost interrupt" whenever the kernel tries to
access my onboard CF card. I put an 'IDE_DEBUG' at the start of
'ide_intr()' so I could watch to see if/how many times my interrupt
occurs or gets called. As an example, after I run 'cardmgr' I'll get
7 'lost interrupt' messages. After the last one, I'll get 7
'IDE_DEBUG' messages indicating that there were 7 interrupts queued
and waiting on the correct interrupt line.

So if 7 interrupts are sitting there waiting on the correct line, why
can't they get into the kernel so it can know the CF card is ready,
instead of having to wait for each IDE operation to timeout? From
googling around the usual cause of 'lost interrupt' is setting the irq
incorrectly, but the fact that all 7 get delivered (eventually) to the
ide's 'ide_intr()' would seem to indicate that at least that part is
configured correctly, no?

[relevant info]
kernel: 2.4.20-rc1
interrupt: external #6 (known as 31 internally), shared
cpu: PPC405gp

in 'ide-cs.c' i call 'ide_setup_ports()' to configure the device and I
define an 'ack_intr()' in order to acknowledge and turn off the
shared interrupt. The interrupt is shared, but not with other IDE
hwif's. I'm not using DMA, chipset is 'ide_generic'. This is not a
PCI device.

How do 'ide_ack_intr()' and 'hwif->intrproc()' differ? I've only setup
'ide_ack_intr()', it appears to return a 1 if it determines the
shared interrupt source was the IDE, or 0 if it wasn't. I also use
this place to put the code to reset (or turn off) the interrupt. What
would 'intrproc()' do?

	Trevor

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On May 26, 2003 11:41 pm, Trevor Woerner wrote:

I'm getting the dreaded "lost interrupt" whenever the kernel tries to
access my onboard CF card.

It gets a bit stranger, but I think I'm onto something. I'll try to
confirm this in the next day or so, but it appears on the surface that
my device doesn't give an interrupt between the transfer of each
segment in a multi-segment transaction.

I enabled the debug statements in 'ide-disk.c' and what I found is that
sometimes I receive interrupts and Linux is happy, and other times I
don't. After thinking about it a little bit I believe the times I got
interrupts were when single segments at a time were being read (ATA
command 0x20) and when I didn't get interrupts were when multi-segment
reads (still command 0x20 but with number of sectors > 1) were
performed.

	Trevor

kernel: 2.4.20-rc1
cpu: PPC405gp
device: SanDisk 16MB CF

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/