It is a surprise for getting a reply from you, Gilles on this subject which I had posed on Xenomai forum and has been treated as if it was coming from an "idiot".
Knowing this is not entirely Xenomai forum, I would still like to ask if I can get hold of the patch, please? if not, hear from you in Xenomai forum. On 3 October 2015 at 05:11, Gilles Chanteperdrix < [email protected]> wrote: > On Fri, Oct 02, 2015 at 09:56:39AM -0600, Jim Cromie wrote: > > On Sun, Sep 27, 2015 at 8:52 AM, <[email protected]> wrote: > > > > > On Sun, 27 Sep 2015 15:08:57 +1300, vibnwis said: > > > > > > > Xenomai patching succeeded but when running one of is test apps, > > > "latency" > > > > showing > > > > > > > > > > >> > 0"000.000| BUG in low_init(): [main] mlockall: > Cannot > > > > allocate > > > > > > > > memory > > > > And the mailing list member suggested the following > > > > > > Is that in dmesg, or output from the test program? > > > Is there more output, or is that it? > > > > > > Personally, if TRACE_IRQFLAGS is causing an issue with mlock, I'd > suspect > > > a very buggy patch indeed. If it can't tolerate a trace function being > > > turned on, there;s probably some very questionable coding in there..... > > > > > > > > > > FWIW, I think Xenomai is far better smelling than your quick sniff has > told > > your olfactory sensors > > TRACE_IRQFLAGS is broken with the I-pipe patch. At least on ARM. The > visible result is LOCKDEP false positives, but there may be some > more subtle kernel data structures corruption due to the fact that > the TRACE_IRQFLAFGS code is called from the Xenomai context. The > principle of Xenomai is to be able to run while Linux believes > its interrupts are off, in the middle of its critical sections. For > this to be possible, the code run in this context must never touch > any Linux kernel data structures. Enabling TRACE_IRQFLAGS breaks > this assumption: Linux code which potentially accesses Linux data > structures gets called from the Xenomai context. The consequences > can be anything, such as mlock failing, though in practice we never > get any report about that. The usual reason for mlockall failing is > because the user is not root, and with default ulimit settings at > least, mlockall can not be called by non-root users. > > Anyway, the reason why TRACE_IRQFLAGS is still broken is my fault: > Jan has sent patches months ago, which I did not check. > > -- > Gilles. > https://click-hack.org >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
