lkml.org 
[lkml]   [2002]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Interrupt trouble due to IRQ router VIA?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.060 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site