On 2012-01-26 16:52, Gilles Chanteperdrix wrote: > On 01/26/2012 04:06 PM, Jan Kiszka wrote: >> On 2012-01-26 15:55, Gilles Chanteperdrix wrote: >>> 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? >>> >>> You can also call in an infinite loop, a xenomais syscall which causes a >>> switch to primary mode, but fails. >> >> Nope, we would be migrated to secondary on xnthread_amok_p when >> returning to user mode. We need a true kernel loop. > > But the loop will continue, and the next call to the syscall will cause > the thread to re-switch to primary mode.
But the "watchdog signal pending" flag will be cleared on each migration, thus the watchdog will never enter the second stage. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
