On Tue, 01 Aug 2006 12:22:21 -0500, dnewbold wrote:

> The PCI bus analyzer shows that the interrupt is being asserted, but the
> ISR isn't getting called.
> Any suggestions?

Nothing in particular about the specific symptom, but tangentially,
who taught you to do this:

> ret = request_irq(
> dev->pci->irq,
> irq_isr,
> SA_INTERRUPT | SA_SHIRQ,
> DEV_NAME,
> dev);

SA_INTERRUPT means "call with assembly linkage, directly from interrupt
gate (or whatever your architecture's equivalent is)".

When SA_INTERRUPT is not set, it's a normal interrupt.

SA_SHIRQ means "this interrupt can be shared". SA_INTERRUPT interrupts
cannot be shared, because their call path does not go through the
necessary auxiliary code.

In the perfect world, request_irq would return -EINVAL if you attempted
to set both flags simultaneously.

-- Pete

"Pete Zaitcev" wrote in message
newsan.2006.08.02.00.50.01.25207@zaitcev.lan...
> On Tue, 01 Aug 2006 12:22:21 -0500, dnewbold wrote:
>
>> The PCI bus analyzer shows that the interrupt is being asserted, but the
>> ISR isn't getting called.
>> Any suggestions?
>
> Nothing in particular about the specific symptom, but tangentially,
> who taught you to do this:
>
>> ret = request_irq(
>> dev->pci->irq,
>> irq_isr,
>> SA_INTERRUPT | SA_SHIRQ,
>> DEV_NAME,
>> dev);
>
> SA_INTERRUPT means "call with assembly linkage, directly from interrupt
> gate (or whatever your architecture's equivalent is)".

FYI: SA_INTERRUPT is being removed from my drivers per Rubini
recommendations for 2.4 and 2.6 drivers.

>
> When SA_INTERRUPT is not set, it's a normal interrupt.
>
> SA_SHIRQ means "this interrupt can be shared". SA_INTERRUPT interrupts
> cannot be shared, because their call path does not go through the
> necessary auxiliary code.
>
> In the perfect world, request_irq would return -EINVAL if you attempted
> to set both flags simultaneously.

This has never happened, but SA_INTERRUPT is being removed from my drivers.
This is coincidental to my looking into this problem.
Unfortunately, removing SA_INTERRUPT from the call hasn't had any affect.

>
> -- Pete
>

On Tue, 1 Aug 2006 12:22:21 -0500, "dnewbold"
wrote:

>I'm moved from 2.6.9 to 2.6.16, but my ISR isn't being called.
>
>Under 2.6.9 using Red Hat Enterprise Linux Workstation Release 4 my driver
>has worked fine.
>Under 2.6.16 using SUSE Linux 10.1 everying works exceps the ISR isn't
>getting called.
>
>The source code has not changed.
>Source fragmants are below.
>The compiler does not complain.
>The linker does not complain.
>The kernel does not complain when the driver is loaded.
>The request_irq() return value indicates that all is fine.
>The PCI bus analyzer shows that the interrupt is being asserted, but the ISR
>isn't getting called.
>Any suggestions?

Sharing an interrupt with a misbehaving driver? What does
/proc/interrupts show? Another driver may be claiming your
interrupt.

Just a WAG.

Bill
--
William D Waddington
william.waddington@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

"Bill Waddington" wrote in message
news:hl71d21gap69nh1fkutqob4n3ev9u3soe0@4ax.com...
> On Tue, 1 Aug 2006 12:22:21 -0500, "dnewbold"
> wrote:
>
>>I'm moved from 2.6.9 to 2.6.16, but my ISR isn't being called.
>>
>>Under 2.6.9 using Red Hat Enterprise Linux Workstation Release 4 my driver
>>has worked fine.
>>Under 2.6.16 using SUSE Linux 10.1 everying works exceps the ISR isn't
>>getting called.
>>
>>The source code has not changed.
>>Source fragmants are below.
>>The compiler does not complain.
>>The linker does not complain.
>>The kernel does not complain when the driver is loaded.
>>The request_irq() return value indicates that all is fine.
>>The PCI bus analyzer shows that the interrupt is being asserted, but the
>>ISR
>>isn't getting called.
>>Any suggestions?
>
> Sharing an interrupt with a misbehaving driver? What does
> /proc/interrupts show? Another driver may be claiming your

/proc/interrupts shows that this driver is the only user of that interrupt.

> interrupt.
>
> Just a WAG.
>
> Bill
> --
> William D Waddington
> william.waddington@beezmo.com
> "Even bugs...are unexpected signposts on
> the long road of creativity..." - Ken Burtch

dnewbold wrote:
> ret = request_irq(
> dev->pci->irq,
> irq_isr,
> SA_INTERRUPT | SA_SHIRQ,
> DEV_NAME,
> dev);

Is dev->pci the return from pci_get_device(). That is, you aren't
reading the IRQ value directly from the PCI registers on the card
are you?

Steve

dnewbold wrote:

> /proc/interrupts shows that this driver is the only user of that interrupt.

Does /proc/interrupts show the interrupt count increasing on that
interrupt?

wrote in message
news:1154528502.499220.63920@b28g2000cwb.googlegro ups.com...
> dnewbold wrote:
>
>> /proc/interrupts shows that this driver is the only user of that
>> interrupt.
>
> Does /proc/interrupts show the interrupt count increasing on that
> interrupt?

The count remains at zero.

>

wrote in message
news:1154526556.300073.12540@h48g2000cwc.googlegro ups.com...
> dnewbold wrote:
>> ret = request_irq(
>> dev->pci->irq,
>> irq_isr,
>> SA_INTERRUPT | SA_SHIRQ,
>> DEV_NAME,
>> dev);
>
> Is dev->pci the return from pci_get_device(). That is, you aren't
> reading the IRQ value directly from the PCI registers on the card
> are you?

dev->pci is of type "struct pci_dev*" and is taken from my initial scan of
the PCI device list.
No, I am not reading the irq value from the pci register and using it
directly.

Everything works fine in 2.6.9, but not in 2.6.16.
As best I can tell (for 2.6.16) the interrupt is being asserted on the PCI
bus,
but I can't tell how much further it is going. It isn't generating an actual
interrupt to the process as the count in /proc/interrupts remains at zero.
I'm still sifting through the 2.6.16 sources to see what is happening.

Thanks for the help.

Don

>
> Steve
>

On Wed, 02 Aug 2006 14:22:01 -0500, dnewbold wrote:

> Everything works fine in 2.6.9, but not in 2.6.16.
> As best I can tell (for 2.6.16) the interrupt is being asserted on the PCI bus,
> but I can't tell how much further it is going. It isn't generating an actual
> interrupt to the process as the count in /proc/interrupts remains at zero.
> I'm still sifting through the 2.6.16 sources to see what is happening.

OK. Sounds like it's a good time to compare /proc/interrupts and dmesg
from 2.6.9 and 2.6.16. The dmesg ought to be directly diff-able, which
usually helps tremendously. I suspect a difference in parsing of ACPI
tables at this point.

-- Pete

dnewbold wrote:
> wrote in message
> news:1154526556.300073.12540@h48g2000cwc.googlegro ups.com...
>> dnewbold wrote:
>>> ret = request_irq(
>>> dev->pci->irq,
>>> irq_isr,
>>> SA_INTERRUPT | SA_SHIRQ,
>>> DEV_NAME,
>>> dev);
>>
>
> Everything works fine in 2.6.9, but not in 2.6.16.
> As best I can tell (for 2.6.16) the interrupt is being asserted on
> the PCI bus,
> but I can't tell how much further it is going. It isn't generating an
> actual interrupt to the process as the count in /proc/interrupts
> remains at zero. I'm still sifting through the 2.6.16 sources to see
> what is happening.

You will need a pci_enable_device() after 2.6.10

>
> Thanks for the help.
>
> Don

-Dave