“Armin” <> email@example.com> > schrieb im Newsbeitrag
news:fligg4$dm5$> firstname.lastname@example.org> …
“John Nagle” <> email@example.com> > schrieb im Newsbeitrag
news:fkq45f$mt$> firstname.lastname@example.org> …
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
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
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
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??
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.
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.
Robert Craig wrote:
Interesting… My technical assessment? Yuck! :-
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.