[Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Terje Frøysa]

Dear forum,

While running a long term test of my application, the application terminates without warning and the message below is logged in the console window.
What may be the cause of this event?

Please advice
Regards
Terje Froysa

[220922.899315] Xenomai: xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.
[222027.963757] Xenomai: RTDM: closing file descriptor 0.
[222027.969209] RTDM GPIO 7 - close

Smail: Terje Frøysa, SINTEF ICT (Information and Communication Technology), N-7465 Trondheim, Norway.
Email: terje.froysa@sintef.no<blocked::mailto:terje.froysa@sintef.no> <mailto:terje.froysa@sintef.no<blocked::mailto:terje.froysa@sintef.no>>
Phone: +47 930 03603,
Company: Independent R&D, see <http://www.sintef.no/<blocked::http://www.sintef.no/>

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Gilles Chanteperdrix]

On Wed, Nov 19, 2014 at 08:00:53AM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> While running a long term test of my application, the application terminates without warning and the message below is logged in the console window.
> What may be the cause of this event?

Your application registers a handler for IRQ 135, which returns
RTDM_IRQ_NONE, meaning "the IRQ was not for me". And since there is
no other handler registered for this IRQ which returns
RTDM_IRQ_HANDLED, Xenomai considers your driver is buggy, so
disables the IRQ line, to avoid the buggy code path that is your irq
handler, because if indeed your irq handler did not acknowledge the
IRQ at the device level, and Xenomai does not disable the IRQ line,
the IRQ will trigger again, and the system will enter an infinite
loop in IRQ mode, causing a lockup.

So, return RTDM_IRQ_NONE in an RTDM irq handler should really mean
that the IRQ is for another driver sharing the same line, not that
the IRQ was acknowledged at device level, but your hardware generate
spurious interrupts or your software has nothing to do to handle
this interrupt.

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Terje Frøysa]

Thanks Gilles,

I will check if I have spurious interrupts..


By the way:

I would like to use the function " rtdm_clock_read_monotonic()" from user space.

The Xenomai doxygen API states that the function can called from User-space task (RT, non-RT) but nothing else.
I have googled it, but it is difficult to find what includefile and library is needed.

Please advise.

Regards
Terje


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 19. november 2014 09:22
To: Terje Frøysa
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

On Wed, Nov 19, 2014 at 08:00:53AM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> While running a long term test of my application, the application terminates without warning and the message below is logged in the console window.
> What may be the cause of this event?

Your application registers a handler for IRQ 135, which returns RTDM_IRQ_NONE, meaning "the IRQ was not for me". And since there is no other handler registered for this IRQ which returns RTDM_IRQ_HANDLED, Xenomai considers your driver is buggy, so disables the IRQ line, to avoid the buggy code path that is your irq handler, because if indeed your irq handler did not acknowledge the IRQ at the device level, and Xenomai does not disable the IRQ line, the IRQ will trigger again, and the system will enter an infinite loop in IRQ mode, causing a lockup.

So, return RTDM_IRQ_NONE in an RTDM irq handler should really mean that the IRQ is for another driver sharing the same line, not that the IRQ was acknowledged at device level, but your hardware generate spurious interrupts or your software has nothing to do to handle this interrupt.

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Gilles Chanteperdrix]

On Wed, Nov 19, 2014 at 10:19:57AM +0000, Terje Frøysa wrote:
> Thanks Gilles,
> 
> I will check if I have spurious interrupts..

Check your irq handler to see in which case it returns RTDM_IRQ_NONE.

> 
> 
> By the way:
> 
> I would like to use the function " rtdm_clock_read_monotonic()" from user space.
> 
> The Xenomai doxygen API states that the function can called from User-space task (RT, non-RT) but nothing else.
> I have googled it, but it is difficult to find what includefile and library is needed.

No, the doxygen documentation says that the function may be called
from the context of a user-space threads, that is a bit different,
Philippe considers this a bug in the documentation. Anyway, you can
not use the RTDM skin in user-space, the RTDM skin is for drivers
only (RTDM means "Real-Time Drivers Model"). For user-space, you have
other skins, including the native and posix ones.

With the POSIX skin, to read the monotonic clock, you would use:
clock_gettime(CLOCK_MONOTONIC, &ts);

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Terje Frøysa]

Thanks Gilles,

My driver delivers (to user space) the 64-bit time given by rtdm_clock_read_monotonic().

As far as I can see, the clock_gettime(CLOCK_MONOTONIC, &ts) delivers the "struct timespec" which contains "only" a 32-bit (ns) time.

The two timers seem not comparable....?

Regards
Terje


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 19. november 2014 11:24
To: Terje Frøysa
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

On Wed, Nov 19, 2014 at 10:19:57AM +0000, Terje Frøysa wrote:
> Thanks Gilles,
> 
> I will check if I have spurious interrupts..

Check your irq handler to see in which case it returns RTDM_IRQ_NONE.

> 
> 
> By the way:
> 
> I would like to use the function " rtdm_clock_read_monotonic()" from user space.
> 
> The Xenomai doxygen API states that the function can called from User-space task (RT, non-RT) but nothing else.
> I have googled it, but it is difficult to find what includefile and library is needed.

No, the doxygen documentation says that the function may be called from the context of a user-space threads, that is a bit different, Philippe considers this a bug in the documentation. Anyway, you can not use the RTDM skin in user-space, the RTDM skin is for drivers only (RTDM means "Real-Time Drivers Model"). For user-space, you have other skins, including the native and posix ones.

With the POSIX skin, to read the monotonic clock, you would use:
clock_gettime(CLOCK_MONOTONIC, &ts);

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Gilles Chanteperdrix]

On Wed, Nov 19, 2014 at 10:43:30AM +0000, Terje Frøysa wrote:
> As far as I can see, the clock_gettime(CLOCK_MONOTONIC, &ts)
> delivers the "struct  timespec" which contains "only" a 32-bit (ns) time.

You wee wrong. Look better at the struct timespec.

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Gilles Chanteperdrix]

On Wed, Nov 19, 2014 at 11:28:06AM +0000, Terje Frøysa wrote:
> How can I wee better?

I meant "see" better, sorry.

> 
> I have checked the posix-api.pdf ... It has 37 references to "struct timespec" but no definitions.
> The Xenomai API have 203 documents referring the "struct timespec", but I simply can't find the definition...?
> (But, the "nanosecs_abs_t" definition is easy to find though).
> 
> Have tested it in my program by (long)time_now =  tp.tv_nsecs.
> No warning....

The struct timespec is part of the POSIX standard, and documented by
the glibc, so since Xenomai uses the glibc definition, there is no
need to document it in Xenomai documentation.

The glibc documentation:
http://www.gnu.org/software/libc/manual/html_node/Elapsed-Time.html



> 
> The only timespec definition I can find on the web is the open-source:
> 
> struct timespec
> {
>   time_t tv_sec;
>   long tv_nsec;
> };

So, it turns out the struct has two members and not only one 32 bits
member. How strange? Does not it fit my anwer?

-- 
					    Gilles.

Re: [Xenomai] xnintr_irq_handler: IRQ135 not handled. Disabling IRQ line.

[Gilles Chanteperdrix]

Please keep the conversation on the list. I will simply not answer
the next mail you send me privately.

On Wed, Nov 19, 2014 at 12:01:55PM +0000, Terje Frøysa wrote:
> Ok Gilles, thanks.
> 
> The glibc confirms that the tv_nsec is a long int (4-bytes in ARM)
> while the time returned by the driver is 8-byte (utint64_t).

Yes tv_nsec is 4 bytes
but tv_sec is 4 more bytes god damn it

1000000000ULL * ts->tv_sec + ts->tv_nsec

will give you an 8 bytes values

The glibc documentation says:
The struct timespec structure represents an elapsed time. It is declared in time.h and has the following members:

long int tv_sec

    This represents the number of whole seconds of elapsed time.
long int tv_nsec

    This is the rest of the elapsed time (a fraction of a second), represented as the number of nanoseconds. It is always less than one billion.

Did you even bother to read that documentation?

Are you for real? Or is this a prank?

Please keep the conversation on the list. I will simply not answer
the next mail you send me privately.

-- 
					    Gilles.