On 01/26/2012 11:36 AM, Jan Kiszka wrote:
On 2012-01-25 19:05, Jan Kiszka wrote:
On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
On 01/25/2012 06:10 PM, Jan Kiszka wrote:
On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
On 01/25/2012 05:52 PM, Jan Kiszka wrote:
On 2012-01-25 17:47, Jan Kiszka wrote:
On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
On 01/25/2012 05:21 PM, Jan Kiszka wrote:
We had two regressions in this code recently. So test all 6 possible
SIGDEBUG reasons, or 5 if the watchdog is not available.
Ok for this test, with a few remarks:
- this is a regression test, so should go to
src/testsuite/regression(/native), and should be added to the
xeno-regression-test
What are unit test for (as they are defined here)? Looks a bit inconsistent.
I put under "regression" all the tests I have which corresponded to
things that failed one time or another in xenomai past. Maybe we could
move unit tests under regression.
- we already have a regression test for the watchdog called mayday.c,
which tests the second watchdog action, please merge mayday.c with
sigdebug.c (mayday.c also allows checking the disassembly of the code in
the mayday page, a nice feature)
It seems to have failed in that important last discipline. Need to check
why.
Because it didn't check the page content for correctness. But that's now
done via the new watchdog test. I can keep the debug output, but the
watchdog test of mayday looks obsolete to me. Am I missing something?
The watchdog does two things: it first sends a SIGDEBUG, then if the
application is still spinning, it sends a SIGSEGV. As far as I
understood, you test tests the first case, and mayday tests the second
case, so, I agree that mayday should be removed, but whatever it tests
should be integrated in the sigdebug test.
Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
test case actually specified a bug as correct behavior.
The fallback case is in fact killing the RT task as before. But I'm
unsure right now: will this leave the system always in a clean state
behind?
The test case being a test case and doing nothing particular, I do not
see what could go wrong. And if something goes wrong, then it needs fixing.
Well, if you kill a RT task while it's running in the kernel, you risk
inconsistent system states (held mutexex etc.). In this case the task is
supposed to spin in user space. If that is always safe, let's implement
the test.
Had a closer look: These days the two-stage killing is only useful to
catch endless loops in the kernel. User space tasks can't get around
being migrated on watchdog events, even when SIGDEBUG is ignored.
To trigger the enforced task termination without leaving any broken
states behind, there is one option: rt_task_spin. Surprisingly for me,
it actually spins in the kernel, thus triggers the second level if
waiting long enough. I wonder, though, if that behavior shouldn't be
improved, ie. the spinning loop be closed in user space - which would
take away that option again.
Thoughts?
Tick-based timing is going to be the problem for determining the
spinning delay, unless we expose it in the vdso on a per-skin basis,
which won't be pretty.
Jan
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
