Gilles Chanteperdrix wrote:
Stefan Kisdaroczi wrote:
> A small program only calling rt_task_shadow with NULL-name fails if i start it
> a second time. Error EEXIST (-17). Same for a program calling only
> rt_task_spawn with NULL-name.
I am able to observe this behaviour. I am on it.
> Ap
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> realized, that *_irq_enab
Germain Olivier wrote:
Thank you for your response
So rootcb isn't the "scheduler task".
I was thinking it was this task which was determining what thread to run,
depending of its parameters (priority, periodicity, scheduling mode).
I go back to the code to understand how it work ...
Use the
Jan Kiszka wrote:
Jan Kiszka wrote:
...
[Update] While writing this mail and letting your test run for a while,
I *did* get a hard lock-up. Hold on, digging deeper...
And here are its last words, spoken via serial console:
c31dfab0 0086 c30d1a90 c02a2500 c482a360 0001 0001 0020
Jan Kiszka wrote:
Hi,
well, if I'm not totally wrong, we have a design problem in the
RT-thread hardening path. I dug into the crash Jeroen reported and I'm
quite sure that this is the reason.
So that's the bad news. The good one is that we can at least work around
it by switching off CONFIG_PR
Gilles Chanteperdrix wrote:
Stefan Kisdaroczi wrote:
> A small program only calling rt_task_shadow with NULL-name fails if i start it
> a second time. Error EEXIST (-17). Same for a program calling only
> rt_task_spawn with NULL-name.
I am able to observe this behaviour. I am on it.
> Ap
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
> Therefore we need a dedicated function to re-enable interrupts in the
> ISR. We could name it *_end_irq, but maybe *_enable_isr_irq is more
> obvious. On non-PPC archs it would translate to *_irq_enable. I
> realized, that *_irq_enab
