Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/start up behaviour of Qnx, Interrupt handling/List of Posts
Forum Topic - start up behaviour of Qnx, Interrupt handling: (6 Items)
   
Update
Yannick Dadji
06/20/2008 4:16 AM
post9452
start up behaviour of Qnx, Interrupt handling   
Hello,
we have written a driver application for a PCI extender card and notice a strange behaviour in the interrupt handling. 
When we start the driver application immediatly after new booting of the PC, we notice that the interrupt handling is 
not working properly: some interrupts are not registered by the system.
The system we use is a PC with Gygabyte 8knxp and pentium 4 processor running QNX 6.3.0 sp 2 (we had other difficulties 
with 6.3.2)
We use interruptAttach() to attach a ISR to the interrupt line. When the system registers an interrupt, the ISR sends 
and event to a Int_Thread that handle the interrupt at a lower priority. Since the card generates an interrupt every 125
µs, we measure the time distance (by generating a pulse to the parallel port and sending the signal to a scope) between
 two successive interrupts that the Int_Thread receives. At this point we notice that some Interrupt are failing 
(distance 250 and 375 µs).
After further debug operation, we noticed that the ISR a times sends the event to the Int_Thread with a delay of up to 
200µs. furthermore we notice that execution of the Interruptunmask() function int the Int_Thread also occurs with delay
 (ca. 300µs) at times. This leads the system to remain in an interruptmask state for some 100 µs and no further 
interrupt can be registered.
This behaviour is not common, since it just happen immediatly after the new booting of the OS. if we wait 10 minutes, 
then every interrupt handling is ok.
Does someone have an explanation for this phenomenon?
Thank
Dadji
Attachment: Bitmap Error_ISR_notActivated.bmp 18.05 KB
Martin Doane
06/20/2008 8:23 AM
post9464
RE: start up behaviour of Qnx, Interrupt handling   
I've seen instances where it seems that memory allocation can "stall" the kernel. You're probably still launching 
processes or have processes that are still allocating memory.

> -----Original Message-----
> From: Yannick Dadji [mailto:y.dadji-foyet@tu-bs.de]
> Sent: Friday, June 20, 2008 4:16 AM
> To: ostech-core_os
> Subject: start up behaviour of Qnx, Interrupt handling
> 
> Hello,
> we have written a driver application for a PCI extender card and notice
> a strange behaviour in the interrupt handling. When we start the driver
> application immediatly after new booting of the PC, we notice that the
> interrupt handling is not working properly: some interrupts are not
> registered by the system.
> The system we use is a PC with Gygabyte 8knxp and pentium 4 processor
> running QNX 6.3.0 sp 2 (we had other difficulties with 6.3.2) We use
> interruptAttach() to attach a ISR to the interrupt line. When the
> system registers an interrupt, the ISR sends and event to a Int_Thread
> that handle the interrupt at a lower priority. Since the card generates
> an interrupt every 125µs, we measure the time distance (by generating a
> pulse to the parallel port and sending the signal to a scope) between
> two successive interrupts that the Int_Thread receives. At this point
> we notice that some Interrupt are failing (distance 250 and 375 µs).
> After further debug operation, we noticed that the ISR a times sends
> the event to the Int_Thread with a delay of up to 200µs. furthermore we
> notice that execution of the Interruptunmask() function int the
> Int_Thread also occurs with delay (ca. 300µs) at times. This leads the
> system to remain in an interruptmask state for some 100 µs and no
> further interrupt can be registered.
> This behaviour is not common, since it just happen immediatly after the
> new booting of the OS. if we wait 10 minutes, then every interrupt
> handling is ok.
> Does someone have an explanation for this phenomenon?
> Thank
> Dadji
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post9452
Yannick Dadji
06/24/2008 5:38 AM
post9548
Re: RE: start up behaviour of Qnx, Interrupt handling   
thank you for your comment. I have a further question. Is it common that a memory allocation "stalls" the kernel on 
realtime OS? I thing (and hope) itsn't, since we couldn't guarantee deterministic behaviour of the OS.
thank!
Aleksandar Ristovski(deleted)
06/24/2008 9:33 AM
post9566
Re: start up behaviour of Qnx, Interrupt handling   
Yannick Dadji wrote:
> thank you for your comment. I have a further question. Is it common that a memory allocation "stalls" the kernel on 
realtime OS? I thing (and hope) itsn't, since we couldn't guarantee deterministic behaviour of the OS.
> thank!

Could you be more specific - what does that mean 'stall'. Malloc is in your libc and runs in user space; I don't see how
 can it 'stall' the kernel... please provide some more detail.

There are numerous restrictions on what you may use in your ISR routine. The documentation will tell you about each 
function (at the bottom of document page there is a table specifying where the function can be used).

For example, on malloc page it says:

Safety:  
Cancellation point No 
Interrupt handler No     <<<< 
Signal handler No 
Thread Yes
Martin Doane
06/24/2008 9:40 AM
post9569
RE: start up behaviour of Qnx, Interrupt handling   
> Yannick Dadji wrote:
> > thank you for your comment. I have a further question. Is it common
> that a memory allocation "stalls" the kernel on realtime OS? I thing
> (and hope) itsn't, since we couldn't guarantee deterministic behaviour
> of the OS.
> > thank!
> 
> Could you be more specific - what does that mean 'stall'. Malloc is in
> your libc and runs in user space; I don't see how can it 'stall' the
> kernel... please provide some more detail.

I'll jump in here, since I made the original claim. If the process does
not have sufficient free memory to satisfy the allocation it must
allocate more memory from the kernel. I have seen this situation cause
InterruptAttachEvent threads to go unserviced for multiple milliseconds.
Jens Steiner
06/26/2008 2:45 AM
post9695
Re: RE: start up behaviour of Qnx, Interrupt handling   
Doesn't this mean that lower priority threads could prevent higher priority threads or even ISRs/InterruptAttach threads
  from execution if the lower priority threads are allocating memory? 

Is there any reference for QNX malloc/calloc being a hazard to real-time constraints?

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems