---------- Forwarded Message ----------
Content-Type: text/plain;
charset="us-ascii"
From: SA <[email protected]>
To: [email protected]
Subject: Missing interrupts?
Date: Fri, 18 Jul 2003 16:51:21 +0100
User-Agent: KMail/1.4.3
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <[email protected]>
Status: RO
X-Status: S
Dear LK,
I am testing a new device driver and have found that one one machine it does
not receive any interrupts. I am stumped by this problem and wonder if
anyone had any advice before I start to take things apart blindly.
Machines test where everything worked: kernels 2.4.18-10 and 2.4.18-24.8.0
on athlon based PCs
Machine where interrupts failed to appear: kernel 2.4.18-3 on a pentium 4.
I register the interrupt on open with
err=request_irq(pi_stage.interrupt,pi_int_handler,SA_SHIRQ,PI_IRQ_ID,(void*)
&pi_stage);
My handler looks like
static void pi_int_handler(int irq, void *dev_id,struct pt_regs *regs){
u32 event;
pi_stage.ints_all++;
event=pi_read_control(PI_STAGE_INTEVENTSET);
if(event & PI_STAGE_ALLINTS){
pi_write_control(PI_STAGE_INTEVENTCLEAR,event
&PI_STAGE_ALLINTS); if(event & PI_STAGE_INTGPIO3)
pi_stage.ints_io++;
if(event & PI_STAGE_GPINT){
pi_stage.ints_axis++;
tasklet_schedule(&pi_tasklet);
}
pi_stage.ints_board++;
}
}
On the dodgy machine I see the driver and card working fine except for the
missing interrupts. The variable pi_stage.ints_all is never incremented and
/proc/interrupts never reports any interrupts. On all machines the
conditions that generate the interrupts do occur.
It looks like on this one machine that interrupts are never received by the
system.
Is it possible that differences between the BIOSs on the machines could cause
this? (ie my card is init'd differently so on the bad machine the ints are
never generated or received).
Any suggestions?
Thanks SA
-------------------------------------------------------
Your posting caught my eye, as I am currently having a problem with a device
driver not receiving interrupts on a Pentium 4 system. In the debugging
process we found that our board is asserting it's interrupt, but my driver
never receives it (sound familiar?). I added code to the linux kernel
(version 2.4.20-8) to determine if the IRQ was getting to the O/S once my
system hangs. We found that not only is it NOT getting to the O/S, it never
even makes it to the 8259 Programmable Interrupt Controller. Futhermore, it
appears that things on the motherboard are is such a bad state, that no
other interrupts are getting through (keyboard, mouse, network, etc). This
same board and driver works fine in a Pentium 3 system.
>Machines test where everything worked: kernels 2.4.18-10 and 2.4.18-24.8.0
> on athlon based PCs
>Machine where interrupts failed to appear: kernel 2.4.18-3 on a pentium 4.
Are you running these tests using the same board? You might try moving the
board for this device driver from the athlon PC to the pentium 4 PC just to
insure it is not a problem with the board.
>I register the interrupt on open with
>
err=request_irq(pi_stage.interrupt,pi_int_handler,SA_SHIRQ,PI_IRQ_ID,(void*)
> &pi_stage);
Is the value in pi_stage.interrupt assigned from the irq element of the
pci_dev structure (returned by pci_find_device routine)? This is the
preferred way to obtain your IRQ rather than look directly at your device's
config space.
Even though you are indicating that you will share the IRQ, have you tried
adjusting BIOS settings or moving board to another slot to try to establish
a unique IRQ for yourself? That would at least prevent another device
driver from getting in your way.
Just curious: Are you receiving any interrupts at all in the pentium 4
system? Or is it running for awhile and then missing some? Does a missing
interrupt hang your system?
Kathy Frazier
Senior Software Engineer
Max Daetwyler Corporation-Dayton Division
2133 Lyons Road
Miamisburg, OH 45342
Tel #: 937.439-1582 ext 6158
Fax #: 937.439-1592
Email: [email protected]
http://www.daetwyler.com
Kathy,
How did you check that the driver was asserting the interrupt? (do you have an
additional way of monitoring it?) I have yet to fully investigate my problem
and an additional tool to check if my board is actually asserting the
interrupt (and to find out how far it gets) would be very handy,
Thanks for the suggestions - more notes below
Thanks,
SA
> ">>"s truncated....
> Futhermore, it appears that things on the motherboard are is such a bad
> state, that no other interrupts are getting through (keyboard, mouse,
> network, etc). This same board and driver works fine in a Pentium 3
> system.
>
> >Machines test where everything worked: kernels 2.4.18-10 and 2.4.18-24.8.0
> > on athlon based PCs
> >
> >Machine where interrupts failed to appear: kernel 2.4.18-3 on a pentium 4.
>
> Are you running these tests using the same board? You might try moving the
> board for this device driver from the athlon PC to the pentium 4 PC just to
> insure it is not a problem with the board.
Same board each time
>...
>....
> Is the value in pi_stage.interrupt assigned from the irq element of the
> pci_dev structure (returned by pci_find_device routine)? This is the
> preferred way to obtain your IRQ rather than look directly at your device's
> config space.
I am currently inspecting the board config space - I will modify and test - is
it possible for the config space to be "wrong".
> Even though you are indicating that you will share the IRQ, have you tried
> adjusting BIOS settings or moving board to another slot to try to establish
> a unique IRQ for yourself? That would at least prevent another device
> driver from getting in your way.
The card and driver share "nicely" with a random assortment of hardware on the
"good" machines - I will try to get it a unique (or at least different
interrupt) on the bad machine (it current shares with usb on int 9 which
never seems to get any interrupts) and see how this pans out
> Just curious: Are you receiving any interrupts at all in the pentium 4
> system? Or is it running for awhile and then missing some? Does a missing
> interrupt hang your system?
The bad computer function fine in everyway except for the missing interrupts
from my card - the card and driver are robust in the sense that they can live
without the interrupts (performance can suffer though) so this problem is in
the category annoying and anomolous rather than fatal.
Ta SA.
SA,
>How did you check that the driver was asserting the interrupt? (do you have
an
>additional way of monitoring it?) I have yet to fully investigate my
problem
>and an additional tool to check if my board is actually asserting the
>interrupt (and to find out how far it gets) would be very handy,
We hooked up a logic analyzer to the board and saw that the interrupt was
being asserted.
>> Are you running these tests using the same board? You might try moving
the
>> board for this device driver from the athlon PC to the pentium 4 PC just
to
>> insure it is not a problem with the board.
>Same board each time
>>...
>>....
>> Is the value in pi_stage.interrupt assigned from the irq element of the
>> pci_dev structure (returned by pci_find_device routine)? This is the
>> preferred way to obtain your IRQ rather than look directly at your
device's
>> config space.
>I am currently inspecting the board config space - I will modify and test -
is
>it possible for the config space to be "wrong".
The kernel can re-map things. See pci.txt in the Documentation directory of
the source tree.
>> Even though you are indicating that you will share the IRQ, have you
tried
>> adjusting BIOS settings or moving board to another slot to try to
establish
>> a unique IRQ for yourself? That would at least prevent another device
>> driver from getting in your way.
>The card and driver share "nicely" with a random assortment of hardware on
the
>"good" machines - I will try to get it a unique (or at least different
>interrupt) on the bad machine (it current shares with usb on int 9 which
>never seems to get any interrupts) and see how this pans out
It's worth trying. Just to know that nothing else is messing you up!
Good luck!
Kathy