Thanks for your response. I have tried other methods for sleeping to avoid
the race condition you are speaking of, but have not had any luck. At this
point, I am using the wait_event_interruptible, but this routine never
returns - I must Cntrl C to stop my test program. So now, the driver looks
something like this:
In routine called from ioctl:
/* a global, declared static int */
RcvIntr = 0;
/* cause H/W to interrupt */
writel(Data, HardwareAddress);
wait_event_interruptible(RcvIntrrcvQ, RcvIntr);
In ISR:
if (USER_INTERRUPTING(pslState)
{
ResetReceiverInterrupt(pslState); /* clear the board's interrupt */
RcvIntr = 1;
wake_up_interruptible(&RcvIntrrcvQ);
}
Since I never get into my ISR, I added some [nasty] kernel hacks in
/arch/i386/kernel/irq.c to see if the O/S ever hears of the interrupt. In a
nutshell:
Global (after the #includes):
static unsigned myIRQ = 0;
In request_irq:
if (!action)
return = -ENOMEM;
+ if (strcmp(devname,"pslengrave") == 0)
+ {
+ myIRQ = irq;
+ printk(KERN_INFO "KJF: monitor pslengrave IRQ\n");
+ }
action->handler = handler;
In do_IRQ:
kstat.irqs[cpu][irq]++;
+ if ((myIRQ !=0) && (irq == myIRQ)) printk (KERN_INFO "KJF: Get spin lock
for IRQ %d\n", irq);
spin_lock(&desc->lock);
+ if ((myIRQ != 0) && (irq == myIRQ)) printk (KERN_INFO "KJF: Calling ack
handler for IRQ %d\n", irq);
desc->handler ->ack(irq);
Told you it was nasty! Note that my driver requests the IRQ (as specified
in the pci_dev structure) as sharable. However,in the current
configuration, no other device is using this IRQ. The request_irq routine
completes successfully and displays my message, but no sign of myIRQ in the
do_IRQ routine.
I appreciate any advice on how to solve this. I am also open to doing any
testing that may be necessary to determine why the OS never hears of the
interrupt. Once our logic analyzer is freed up, I can verify that the board
is interrupting . . . although we have been that route before when I was
testing in my original developement system. The device was interrupting
fine . . .
Thanks in advance for your help!
Kathy
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Alan Cox
Sent: Wednesday, July 31, 2002 8:35 PM
To: Kathy Frazier
Cc: linux-kernel@vger.kernel.org
Subject: Re: Interrupt trouble due to IRQ router VIA?
On Wed, 2002-07-31 at 21:15, Kathy Frazier wrote:
> another system. In this system, the driver times out on the
> interruptible_sleep_on_timeout waiting for the interrupt. One thing that
I
There is a classic kernel programming error which goes something like
this
my_interrupt()
{
foo->ready = 1;
wake_up(&foo_pending);
}
foo_read()
{
while(!foo->ready && !signal_pending(current))
interruptible_sleep_on(&foo_pending);
}
What happens then is this
foo->ready = 0 - true
signal pending = 0 - ok
INTERRUPT
foo->ready=1
wake up
END INTERRUPT
interruptible_sleep_on(&foo_pending);
Waits forever
It could be your timings have changed so such a bug now shows up
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:36 EST