Philippe Gerum wrote: > > It's not a magic value, it means that up to 32 memory contexts may be > stalled in the drop queue at any point in time, waiting for a normal > Linux task to be switched in to flush them, while a large number of > Xenomai threads is going through frequent domain migrations. Hitting > this limit _is_ where the problem lies, not the static limit itself, > and it tells that something needs to be fixed in the application, so > that it does not starve the regular Linux activities this way. > > IOW, it's ok to raise this compile-time value to account for > applications living on the edge, but we should not make a feature out > of an application design issue, by adding such a configuration knob.
I do not understand. In my opionion no application behaviour should ever cause the Kernel to oops. Playing around with Kernel configuration values, to come around such Oopses is where the problem lies and not in the application itself. I do nat have fully understood what exactly does the Kernel cause to oops in this specific case, but a killall of an application is similar to e.g. a caught SIGSEGV, which might happen in normal development, and looks very weird if it leads to a Kernel crash whatsoever. In my opinion the BUG_ON() call inside sched.c is a bug and should be replaced by something that handles the situation more gracefully. Best regards, Daniel Schnell. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
