request_irq() changes from red hat to suse - Linux

This is a discussion on request_irq() changes from red hat to suse - Linux ; 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: request_irq() changes from red hat to suse

  1. request_irq() changes from red hat to suse

    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?

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

    irqreturn_t irq_isr(int irq, void* dev_id, struct pt_regs* regs)
    {
    irqreturn_t ret;

    ...

    return(ret);
    }



  2. Re: request_irq() changes from red hat to suse

    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


  3. Re: request_irq() changes from red hat to suse


    "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
    >




  4. Re: request_irq() changes from red hat to suse

    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

  5. Re: request_irq() changes from red hat to suse


    "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




  6. Re: request_irq() changes from red hat to suse

    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


  7. Re: request_irq() changes from red hat to suse

    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?


  8. Re: request_irq() changes from red hat to suse


    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.

    >




  9. Re: request_irq() changes from red hat to suse


    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
    >




  10. Re: request_irq() changes from red hat to suse

    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


  11. Re: request_irq() changes from red hat to suse

    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




+ Reply to Thread