free_irq problem in 2.6 kernel

free_irq problem in 2.6 kernel

[brian franklin]

I have a network driver which uses PCI Interrupt D. 
Using kernel
2.6.8-1.528.2.10smp, I now have a problem when I call
free_irq().  It
now masks off the interrupt even though it is shared
with another
device.  My initial call to request_irq() succeeds,
and my driver will
correctly receive interrupts.  But once I call
free_irq(), the
interrupt is now masked, and subsequent calls to
request_irq() don't
unmask the interrupt.

The syntax of my calls to these two functions are:
status = request_irq(priv->irq , jnet_isr, SA_SHIRQ,
name1, dev);
and
free_irq(priv->irq, dev);

Can anyone shed some light on what I might be doing
wrong?

As a side note: I noticed that this kernel now
correctly configures
the IOAPIC configuration register with the interrupt
vector.  Previous
kernels did not.  Can anyone tell me how to
distinguish between a
kernel version that does configured the IOAPIC
configuration registers
correctly, and one that doesn't?  (In previous
versions, the
configuration register would have an interrupt vector
of IRQ169 while
the interrupt was really IRQ19.  Now, the interrupt
vector in the
configuration register matches with the IRQ that is
actually
selected.)

Thanks for any assistance.
Brian Franklin




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

Re: free_irq problem in 2.6 kernel

[Alan Cox]

On Gwe, 2004-10-29 at 23:00, brian franklin wrote:
> 2.6.8-1.528.2.10smp, I now have a problem when I call
> free_irq().  It
> now masks off the interrupt even though it is shared
> with another

free_irq only masks the interrupt line when the last user is
freeing that IRQ line.

> The syntax of my calls to these two functions are:
> status = request_irq(priv->irq , jnet_isr, SA_SHIRQ,
> name1, dev);
> and
> free_irq(priv->irq, dev);
> 
> Can anyone shed some light on what I might be doing
> wrong?

The calls look fine (providing you arent using "dev" as the cookie for
multiple "request_irq" functions on the same IRQ at the same time)

> kernel version that does configured the IOAPIC
> configuration registers
> correctly, and one that doesn't?  (In previous
> versions, the
> configuration register would have an interrupt vector
> of IRQ169 while
> the interrupt was really IRQ19.

It depends at runtime on the system, how the IRQ assignment is done and
sometimes on hardware "features". The official kernel internal policy is
that

a) "irq" is a cookie obtained for PCI devices by pdev->irq 
b) you pass the cookie to request_irq
c) it has no other guaranteed meaning at all

once you get off x86 this gets even more important.