Skip navigation.
Home
The QNX Community Portal

View topic - unexpected interrupt delay

unexpected interrupt delay

Read-only archive of qnx.rtos (Writing resources managers, and general discussion around the QNX Neutrino RTOS) at inn.qnx.com

Re: unexpected interrupt delay

Postby Mario Charest » Fri Jan 04, 2008 3:32 pm

"dadji" <ydadji@hotmail.com> wrote in message
news:fllgh5$hh4$1@inn.qnx.com...
"Armin" <a@nospam.org> schrieb im Newsbeitrag
news:fligg4$dm5$1@inn.qnx.com...
dadji wrote:
"John Nagle" <nagle@downside.com> schrieb im Newsbeitrag
news:fkq45f$mt$1@inn.qnx.com...
Yes. This is a known problem with some CPU boards.
Even some embedded boards have this problem. Look for
emulated old-style serial ports, IDE disks emulated with
flash memory, USB keyboard emulation, and similar
stuff being done in system management mode.
When you have unexpected interrupt delays, give the full
hardware configuration.

There should be no long interrupt lockouts in any
standard QNX software.

How are you measuring the time delay between interrupts?


to measure the interrupt delay i use the Clockcycle() call, and get the
system time by each incoming interrupt.

Are you using an ISR + interrupt handler thread or just an interrupt
thread?

If you are using an ISR ... what is the priority of the returned event?
Is the SIGEV_PULSE_PRIO_INHERIT flag set?

If yes, the interrupt handler thread inherits the low(?) priority of the
pulse event. If no, what is the priority of the interrupt handler ?

If your device is a PCI device ... is its interrupt shared by an other
device?

If yes, is the other driver disabling the interrupt for a long time?

Could it be that the interrupt logic of the hardware of you device has a
bug? Is the interrupt logic implemented in a FPGA??

--Armin

i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.

|There is priority involved, it's the priority of the interrupt handler
thread. It's possible that it gets preempted by a higher priority thread.
Also other interrupt of higher priority might disrupt it.
Mario Charest
 

Re: unexpected interrupt delay

Postby Armin » Sat Jan 05, 2008 9:42 am

dadji wrote:
"Armin" <a@nospam.org> schrieb im Newsbeitrag
news:fligg4$dm5$1@inn.qnx.com...
dadji wrote:
"John Nagle" <nagle@downside.com> schrieb im Newsbeitrag
news:fkq45f$mt$1@inn.qnx.com...
Yes. This is a known problem with some CPU boards.
Even some embedded boards have this problem. Look for
emulated old-style serial ports, IDE disks emulated with
flash memory, USB keyboard emulation, and similar
stuff being done in system management mode.
When you have unexpected interrupt delays, give the full
hardware configuration.

There should be no long interrupt lockouts in any
standard QNX software.

How are you measuring the time delay between interrupts?

to measure the interrupt delay i use the Clockcycle() call, and get the
system time by each incoming interrupt.
Are you using an ISR + interrupt handler thread or just an interrupt
thread?

If you are using an ISR ... what is the priority of the returned event?
Is the SIGEV_PULSE_PRIO_INHERIT flag set?

If yes, the interrupt handler thread inherits the low(?) priority of the
pulse event. If no, what is the priority of the interrupt handler ?

If your device is a PCI device ... is its interrupt shared by an other
device?

If yes, is the other driver disabling the interrupt for a long time?

Could it be that the interrupt logic of the hardware of you device has a
bug? Is the interrupt logic implemented in a FPGA??

--Armin

i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.

OK ... do you use InterruptMask() in the ISR ??
Are there other drivers using InterruptDisable or InterruptLock ??

The interrupt line was shared with other devices. Now i have set my device
to a single (not shared) interrupt line manually, but i have the same error.
I don't think about hardware bug (standard IEEE 1394 device), may be i
didn't consider something in the software.

Yes, there is probably also a failure in your meassurement method.

The best way to see what really happens is a kernel trace.

--Armin






thanks.
Yannick




Then i build the time difference between two consecutive interrupts.
Since the interrupts are expected at least every 125µs, i can set an
upper time range to detect the missing interrupts. For examples i measure
the time difference of two consecutive interrupt of more than 300 µs.
I can also see the effect of the interrupt delay on the scope using the
parallel port pins.

best regards.


John Nagle

Robert Craig wrote:
Interesting.... My technical assessment? Yuck! :-

Robert.


maschoen wrote:
SMI is usually used to emulate in software some hardware feature that
is missing and can be a cost saver. I've seen it used to emulate
missing video modes by doing pixel stretching and also emulation of a
Sound Blaster card. It probably could be used to make a USB keyboard
look like one attached to the standard keyboard interface.


Yannick

Armin
 

Re: unexpected interrupt delay

Postby Armin » Sun Jan 06, 2008 11:09 am

dadji wrote:
"Armin" <a@nospam.org> schrieb im Newsbeitrag
news:fligg4$dm5$1@inn.qnx.com...
dadji wrote:
[ clip ]
i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.

This is OK for the software priorities. But just an additional point.

Is there an other device which is using a hardware interrupt with a
higher hardware priority as your firewire device is using?
If yes ... what about the interrupt load ??

QNX6 supports nested interrupts. That means every ISR can be preempted
by an ISR which handles an IRQ with a higher hardware priority.

This can lead to unpredictable time delays in your ISR (in the range of
micro seconds).

--Armin


The interrupt line was shared with other devices. Now i have set my device
to a single (not shared) interrupt line manually, but i have the same error.
I don't think about hardware bug (standard IEEE 1394 device), may be i
didn't consider something in the software.
thanks.
Yannick
Armin
 

Re: unexpected interrupt delay

Postby John McClurkin » Sun Jan 06, 2008 4:12 pm

dadji wrote:
"Armin" <a@nospam.org> schrieb im Newsbeitrag
news:fligg4$dm5$1@inn.qnx.com...
dadji wrote:
"John Nagle" <nagle@downside.com> schrieb im Newsbeitrag
news:fkq45f$mt$1@inn.qnx.com...
Yes. This is a known problem with some CPU boards.
Even some embedded boards have this problem. Look for
emulated old-style serial ports, IDE disks emulated with
flash memory, USB keyboard emulation, and similar
stuff being done in system management mode.
When you have unexpected interrupt delays, give the full
hardware configuration.

There should be no long interrupt lockouts in any
standard QNX software.

How are you measuring the time delay between interrupts?

to measure the interrupt delay i use the Clockcycle() call, and get the
system time by each incoming interrupt.
Are you using an ISR + interrupt handler thread or just an interrupt
thread?

If you are using an ISR ... what is the priority of the returned event?
Is the SIGEV_PULSE_PRIO_INHERIT flag set?

If yes, the interrupt handler thread inherits the low(?) priority of the
pulse event. If no, what is the priority of the interrupt handler ?

If your device is a PCI device ... is its interrupt shared by an other
device?

If yes, is the other driver disabling the interrupt for a long time?

Could it be that the interrupt logic of the hardware of you device has a
bug? Is the interrupt logic implemented in a FPGA??

--Armin

i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.
The interrupt line was shared with other devices. Now i have set my device
to a single (not shared) interrupt line manually, but i have the same error.
I don't think about hardware bug (standard IEEE 1394 device), may be i
didn't consider something in the software.
thanks.
Yannick

Which interrupt level did you set your device to? If there are devices
using interrupts with a higher priority than the one being used by your
device, your device may be blocked. Our approach is to set our critical
device to use interrupt 9, and to make sure that no other devices share
that interrupt.




Then i build the time difference between two consecutive interrupts.
Since the interrupts are expected at least every 125µs, i can set an
upper time range to detect the missing interrupts. For examples i measure
the time difference of two consecutive interrupt of more than 300 µs.
I can also see the effect of the interrupt delay on the scope using the
parallel port pins.

best regards.


John Nagle

Robert Craig wrote:
Interesting.... My technical assessment? Yuck! :-

Robert.


maschoen wrote:
SMI is usually used to emulate in software some hardware feature that
is missing and can be a cost saver. I've seen it used to emulate
missing video modes by doing pixel stretching and also emulation of a
Sound Blaster card. It probably could be used to make a USB keyboard
look like one attached to the standard keyboard interface.


Yannick

John McClurkin
 

Re: unexpected interrupt delay

Postby Armin » Tue Jan 08, 2008 10:59 am

John McClurkin wrote:
dadji wrote:
"Armin" <a@nospam.org> schrieb im Newsbeitrag
news:fligg4$dm5$1@inn.qnx.com...
dadji wrote:
"John Nagle" <nagle@downside.com> schrieb im Newsbeitrag
news:fkq45f$mt$1@inn.qnx.com...
Yes. This is a known problem with some CPU boards.
Even some embedded boards have this problem. Look for
emulated old-style serial ports, IDE disks emulated with
flash memory, USB keyboard emulation, and similar
stuff being done in system management mode.
When you have unexpected interrupt delays, give the full
hardware configuration.

There should be no long interrupt lockouts in any
standard QNX software.

How are you measuring the time delay between interrupts?

to measure the interrupt delay i use the Clockcycle() call, and get
the system time by each incoming interrupt.
Are you using an ISR + interrupt handler thread or just an interrupt
thread?

If you are using an ISR ... what is the priority of the returned event?
Is the SIGEV_PULSE_PRIO_INHERIT flag set?

If yes, the interrupt handler thread inherits the low(?) priority of
the pulse event. If no, what is the priority of the interrupt handler ?

If your device is a PCI device ... is its interrupt shared by an
other device?

If yes, is the other driver disabling the interrupt for a long time?

Could it be that the interrupt logic of the hardware of you device
has a bug? Is the interrupt logic implemented in a FPGA??

--Armin

i use ISR + interrupt handler thread. The signaling event is of type
SIGEV_INTR, so no priority allocated.
The interrupt line was shared with other devices. Now i have set my
device to a single (not shared) interrupt line manually, but i have
the same error. I don't think about hardware bug (standard IEEE 1394
device), may be i didn't consider something in the software.
thanks.
Yannick

Which interrupt level did you set your device to?

It's a PCI device and the interrupt will be assigned by the PCI bios.

--Armin


If there are devices
using interrupts with a higher priority than the one being used by your
device, your device may be blocked. Our approach is to set our critical
device to use interrupt 9, and to make sure that no other devices share
that interrupt.
Armin
 

Previous

Return to qnx.rtos

Who is online

Users browsing this forum: No registered users and 2 guests

cron