Just to throw some random thoughts and create more entropy, maybe an extended excerpt of your code could be of help.
Can you tell us where do irq 5 comes from? Is it edge or level triggered? How do you process it? Any other info that can be useful?
I've checked the effect of using printks in the example I sent you, it's OK.
I even used plain printfs, without any problem but "RTAI[sched]: unloaded (forced hard/soft/hard transitions: traps 0, syscalls 20000).", signaled by the RTAI scheduler at the end.
The point is that my example, by pending it back to Linux, leave the real processing of the interrupt to the Linux driver.
By knowing if you use function like enable/disable irq I could check if anything is wrong in their RTAI code.
Beside that I'm asking myself if there could be a stack overflow in the kernel part of the thread, because interrupts piles up in the kernel part of the stack.
Paolo
________________________________________
From: Erik Rull [***@rdsoftware.de]
Sent: Tuesday, November 6, 2018 8:29 PM
To: Paolo Mantegazza; ***@rtai.org
Subject: Re: [Rtai] LXRT CHANGED MODE (TRAP)
Hi Paolo,
I don't know what's wrong - but I got again the TRAP somewhere between two
rt_printks and the only line in between is the rt_irq_wait().
<4>[ 21.137625] Waiting for IRQ 5! 0
<4>[ 21.212348] Calling ISRs 5
<4>[ 21.212769] Waiting for IRQ 5! 1
<4>[ 21.213682] Calling ISRs 5
<4>[ 21.214016] Waiting for IRQ 5! 2
<4>[ 21.556554]
<4>[ 21.556560] LXRT CHANGED MODE (TRAP), PID = 458, VEC = 14, SIGNO = 11.
<4>[ 21.557015] Calling ISRs 5
<4>[ 21.557015] Waiting for IRQ 5! 3
<4>[ 21.557794] Calling ISRs 5
<4>[ 21.558196] Waiting for IRQ 5! 4
<4>[ 22.953013] [sched_delayed] sched: RT throttling activated
And the code lines for this log output are:
rt_printk("Waiting for IRQ %hu! %u\n",m_uIRQ,m_uIntrCnt);
ovr = rt_irq_wait(m_uIRQ);
rt_printk("Calling ISRs %u\n",m_uIRQ);
No allocation, nothing - what causes the TRAP?
Best regards,
Erik
Erik Rull wrote:
> Hi Paolo,
>
> I have a rough idea - it could be that I (or better the program) actually try to
> allocate memory. But I do not understand why this happens outside the thread
> stack, e.g. if I have a uint16_t inside the ISR to buffer some I/O registers,
> this usage should be allowed because the variable is on the stack and not on the
> heap, correct?
>
> If I of course try to allocate an std::string, std::iterators, etc. this will
> definitively cause a heap operation that triggers the TRAP - but I don't do that.
>
> Even objects that will not cause something like a malloc or a new internally
> should be safe, correct? So objects or structs that consist only of atomic type
> variables... All these should go on the stack and not on the heap...
>
> And: My stack size option for the thread is set to 0x100000 - this should be a
> fair amount of memory for an ISR stack, shouldn't it? :-)
>
> Best regards,
>
> Erik
>
>
>
>
>> On November 6, 2018 at 4:29 PM Erik Rull <***@rdsoftware.de> wrote:
>>
>> Hi Paolo,
>>
>> thanks! I compared your routines with mine and I didn't find real differences.
>> I tried to create a standalone program but this does not seem to cause the
>> issue... Maybe some stuff beside the rtai tasks / contexts causes the
>> behavior? Is this actually possible? So that the main non-realtime part tries
>> to allocate memory and then the interrupt comes and disrupts this kernel
>> action that then causes the TRAP?
>>
>> Just for my curiosity: Is the main tasklet mandatory and what is the
>> difference between the rtai based pthreads and the standard pthreads? The
>> behavior looks pretty similar. During my investigations I tried exchanging
>> them and didn't notice a difference in behavior...
>>
>> I'm proceeding with my search... there must be a culprit...
>>
>> Best regards,
>>
>> Erik
>>
>>
>>
>>> On November 6, 2018 at 12:21 AM Paolo Mantegazza < ***@polimi.it
>>> <mailto:***@polimi.it>> wrote:
>>>
>>>
>>> You'll receive it with another email.
>>> Paolo
>>> ________________________________________
>>> From: Erik Rull [ ***@rdsoftware.de <mailto:***@rdsoftware.de>]
>>> Sent: Monday, November 5, 2018 10:32 PM
>>> To: Paolo Mantegazza; '***@rtai.org <mailto:'***@rtai.org>'
>>> Subject: Re: [Rtai] LXRT CHANGED MODE (TRAP)
>>>
>>> Hi Paolo,
>>>
>>> I'll try to cut out a test scenario - it might take some time - to have the
>>> chance to compare if I missed a significantpiece inside my routines, your
>>> example would be helpful.
>>>
>>> Best regards,
>>>
>>> Erik
>>>
>>>
>>> Paolo Mantegazza wrote:
>>>> It is difficult for me to understand what's happening. The user space scheme
>>>> is simple. In your case a user space thread, after making it known to RTAI
>>>> that it exists as an interrupt handler, disable interrupts and suspend
>>>> itself using rt_irq_wait. When the interrupt comes the interrupt handler
>>>> just resumes the thread, with interrupts disabled. From that point onward
>>>> you are in the same conditions as in kernel space and must do the same
>>>> things you'd do there.
>>>> I do not see how the just described sequence of operation can cause what you
>>>> describe. However, I know I could be wrong, but to understand why and how I
>>>> need a test case reproducing your troubles.
>>>> On my side I can send you a test case, based on trapping mouse interrupt.
>>>> They do no come very very fast but are not slow either.
>>>> Paolo.
>>>> ________________________________________
>>>> From: Rtai [ rtai-***@rtai.org <mailto:rtai-***@rtai.org>] on behalf
>>>> of Erik Rull [ ***@rdsoftware.de <mailto:***@rdsoftware.de>]
>>>> Sent: Monday, November 5, 2018 6:51 PM
>>>> To: '***@rtai.org <mailto:'***@rtai.org>'
>>>> Subject: [Rtai] LXRT CHANGED MODE (TRAP)
>>>> Hi all,
>>>> I'm running into the same message as described here:
>>>> http://mail.rtai.org/pipermail/rtai/2007-April/017184.html
>>>> The only difference is the PID, VEC and SIGNO is identical
>>>> LXRT CHANGED MODE (TRAP), PID = xxx, VEC = 14, SIGNO = 11.
>>>> The PID points me to the thread that services an interrupt
>>>> Paolos hint in the mail thread above was something with memory allocation. So I
>>>> put rt_printk-Statements into the hard realtime context to find the source of
>>>> evil. I also increased the thread stack size without any noticable change of
>>>> the
>>>> behavior.
>>>> Result of the rt_printk-addings - it is this line:
>>>> ovr = rt_irq_wait(m_uIRQ);
>>>> where ovr is int and m_uIRQ is unsigned.
>>>> And: The LXRT CHANGED MODE line does not appear in the first few interrupts,
>>>> but
>>>> "later" - in most cases less than 10 interrupts.
>>>> And: The LXRT CHANGED MODE line does appear when an interrupt occurs (or
>>>> better:
>>>> very close to the interrupt occurence), not when entering the function or
>>>> during
>>>> the function waits.
>>>> For me, this means that "something" inside rt_irq_wait() seems to cause the
>>>> message.
>>>> Also interesting: when asking for rt_is_hard_real_time(NULL) I still get back a
>>>> true - so the mode hasn't changed??
>>>> I'm using rtai 4.0 on Kernel 3.4.67 with Intel Atom N270 and tsc clocksource
>>>> enabled - yes I know - old stuff...
>>>> Any ideas on how to get rid of this?
>>>> Best regards,
>>>> Erik
>>>> _______________________________________________
>>>> Rtai mailing list
>>>> ***@rtai.org <mailto:***@rtai.org>
>>>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
>
>
>
>> _______________________________________________ Rtai mailing list
>> ***@rtai.org https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
>
>
>
>
>
> _______________________________________________
> Rtai mailing list
> ***@rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>