-----Philippe Gerum <[email protected]> wrote: -----
>On 02/17/2013 10:01 AM, George Broz wrote: >> Hello All, >> >> I'm using a kernel driver for which some calls cause the >> Xenomai kernel to crash with a message: >> "Xenomai: stuck on nucleus lock..", >> but only when called from a Xenomai task with a non-zero priority. >> >> >> If I make the same calls from a Linux thread that is still part >> of the Xenomai application, no crash results. And it seems >> that when I make the same calls from a Xenomai task that has >> a priority of "0", it also does not crash the kernel. >> >> >> I knew these calls would put the task into secondary mode >> since they make a number of kmallocs/kfrees and other syscalls. > >Xenomai won't switch to secondary mode automatically because a >regular >linux driver calls the regular kernel API, it simply does not know >about >this fact. It would switch only when a transition from userland to >kernel context happens due to a regular linux system call, which >includes the POSIX I/O calls one may invoke to reach such a driver. > >However, if that driver is RTDM-based, the set of POSIX I/O calls >becomes mode-sensitive, and a real-time task (i.e. non-zero prio) may > >well enter the driver code in primary mode, depending on how the >driver >is programmed to handle the request. > >> I didn't expect there to be a difference in behavior between >> a Xenomai task in secondary mode versus a normal Linux thread >> versus a Xenomai task with priority of "0". >> > >Xenomai assumes that 0-prio tasks it creates normally want to run in > >secondary mode, except when they invoke primary mode-only services. >For >this reason, Xenomai switches them back to secondary mode >automatically >when they are done with such kernel services. This does not happen >with >non-zero priority tasks, which are left in the current mode. > >So the difference could be that some kernel API is called from >primary >mode, leading to unexpected results in the latter case, which would >mean >that a RTDM-based driver is doing the wrong thing. > >> >> I'm running Linux 2.6.37.6 w/Xenomai 2.6.1, native API on x86 >> (Atom, SMP, 32-bit). >> >> >> Is it possible that a (well-written) driver can cause such >> behavior? (If not I can post the crashdump details). >> >> >> I would like to use rt_event_ / rt_mutex_ at other times >> which I cannot do if I need to make this a Linux thread. >> Is there a rational explanation that would allow me to use >> these calls and the driver calls if I simply set the task >> to priority "0"? >> > >Is this driver a RTDM driver, or a regular linux one? It is a complex driver - its "runtime" calls are through RTDM, its "setup/teardown" calls are not. The "runtime" calls (called from a different, non-zero prio task) cause no problems and are never called at the same time as the "setup/td" set. The ones causing a problem are the "setup/td" set which are probably calling the kernel in primary mode as you suggest above. If they are called from a task that remains in secondary mode (except to service calls to rt_mutex_, rt_event_ which force a temporary switch to primary) would those calls be as stable as calling them out of a pure Linux thread? Is this a valid/typical application of a 0-prio task? Thanks for your help, Philippe. It's much appreciated! --George _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
