Philippe Gerum wrote:
> I've toyed a bit to find a generic approach for the nucleus to regain
> complete control over a userland application running in a syscall-less
> loop.
> The original issue was about recovering gracefully from a runaway
> situation detected by the nucleus watchdog, where a thread would spin in
> primary mode without issuing any syscall, but this would also apply for
> real-time signals pending for such a thread. Currently, Xenomai rt
> signals cannot preempt syscall-less code running in primary mode either.
> The major difference between the previous approaches we discussed about
> and this one, is the fact that we now force the runaway thread to run a
> piece of valid code that calls into the nucleus. We do not force the
> thread to run faulty code or at a faulty address anymore. Therefore, we
> can reuse this feature to improve the rt signal management, without
> having to forge yet-another signal stack frame for this.
> The code introduced only fixes the watchdog related issue, but also does
> some groundwork for enhancing the rt signal support later. The
> implementation details can be found here:
> The current mayday support is only available for powerpc and x86 for
> now, more will come in the next days. To have it enabled, you have to
> upgrade your I-pipe patch to or 2.6.34-2.7-00 for x86,
> or 2.6.34-2.10-00 for powerpc. That feature relies on a
> new interface available from those latest patches.
> The current implementation does not break the 2.5.x ABI on purpose, so
> we could merge it into the stable branch.
> We definitely need user feedback on this. Typically, does arming the
> nucleus watchdog with that patch support in, properly recovers from your
> favorite "get me out of here" situation? TIA,
> You can pull this stuff from
> git://, queue/mayday branch.

I've retested the feature as it's now in master, and it has one
remaining problem: If you run the cpu hog under gdb control and try to
break out of the while(1) loop, this doesn't work before the watchdog
expired - of course. But if you send the break before the expiry (or hit
a breakpoint), something goes wrong. The Xenomai task continues to spin,
and there is no chance to kill its process (only gdb).

# cat /proc/xenomai/sched
  0  0      idle    -1      -         master     RR         ROOT/0
  1  0      idle    -1      -         master     R          ROOT/1
  0  6120   rt      99      -         master     Tt         cpu-hog
# cat /proc/xenomai/stat
CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          0          0     00500088    0.0  ROOT/0
  1  0      0          0          0     00500080   99.7  ROOT/1
  0  6120   0          1          0     00342180  100.0  cpu-hog
  0  0      0          21005      0     00000000    0.0  IRQ3340: [timer]
  1  0      0          35887      0     00000000    0.3  IRQ3340: [timer]


Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to