Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

Hi all,
I need to unset default value of LOCKDEP(=y) and TRACE_IRQFLAGS_SUPPORT(=y)
to both "n". Having asked around and had tried for at least 3 days,
seriously I still couldn't get both items configured as "n"

Perhaps someone can help me on this item first. For instance, Symbol
TRACE_IRQFLAGS description below, to set it, it will need the logics below:

PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] &&
STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] ||
IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE

To unset it, I could either set DEBUG_KERNEL=n or set TRACING_SUPPORT=n (or
FTRACE=n). However, having set it, yet I don't see symbol TRACE_IRQFLAGS is
unset.

Anything wrong of my interpretation of the logics above?

Copied from "/" type TRACE_IRQFLAGS in menuconfig

  ? Symbol: TRACE_IRQFLAGS
[=y]
?
  ? Type  :
boolean
?
  ?   Defined at
lib/Kconfig.debug:1047
?
  ?   Selected by: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] &&
TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT
[=y] || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE [=n ?

?
?

?
?
  ? Symbol: TRACE_IRQFLAGS_SUPPORT
[=y]
?
  ? Type  :
boolean
?
  ?   Defined at arch/arm/Kconfig:174


Appreciate any comments.
Thanks in advance.

Lim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/7370de28/attachment-0001.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Sun, 27 Sep 2015 03:16:11 +1300, vibnwis said:
> To unset it, I could either set DEBUG_KERNEL=n or set TRACING_SUPPORT=n (or
> FTRACE=n). However, having set it, yet I don't see symbol TRACE_IRQFLAGS
> is unset.

Refresher course in Boolean logic.

If there's an OR in there, you need to set *both* to =n, not just one or the
other.

The bigger question is: *WHY* do you think you need to unset the value of
these two things?  What problem are you trying to solve by turning them off?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/766ed3bb/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

To unset TRACE_IRQFLAGS

PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] &&
STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] } ||  IRQSOFF_TRACER [=n]
&& TRACING_SUPPORT [=y] && FTRACE

Let's say
L1= PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y]
L2 = IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE


Setting DEBUG_KERNEL->n will unset  L1 [=0]

and

setting IRQSOFF_TRACER [=y]  || TRACING_SUPPORT [=n] || FTRACE [= n] will
unset L2 [=0]


L1 || L2 => TRACE_IRQFLAGS ->0

This is my boolean logics. Any comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/61f1665e/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Sun, 27 Sep 2015 12:06:49 +1300, vibnwis said:
> Setting DEBUG_KERNEL->n will unset  L1 [=0]
> and

And.  Right.

> setting IRQSOFF_TRACER [=y]  || TRACING_SUPPORT [=n] || FTRACE [= n] will
> unset L2 [=0]

In your first post, you had implied that you had tried  doing one or
the other, not both.

Why are you trying to unset TRACE_IRQFLAGS, anyhow? Does it cause a problem
for you?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/f38cc717/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

>
>
> In your first post, you had implied that you had tried  doing one or
> the other, not both.
>
My mistake. Apologies for the confusion

>
> Why are you trying to unset TRACE_IRQFLAGS, anyhow? Does it cause a problem
> for you?
>
Long story. I need to incorporate Xenoma, the open sournce real-time patch
of Linux. I could not get it work and the assistance I got suggested that
the symbols would need to unset. With it enabled would cause the Xenomai to
fail. However, I had made so much efforts trying to get it unset, yet no
luck.

I am a new newbie, with some experience, but not having the substantial
knowledge. For instance, I do know how to run menuconfig, but for this case
I don't know if I am wrong or inadequate knowledge for solving that
problems. However, a simple logic I applied before applying the logics I
presented above, was simply, disabled all symbols in menuconfig, and had
the .config opened in an editor. Any changes on the .config would trigger
reload contents in the editor. Having disabled all symbols, yet I did not
see any changes in terms of the two symbols. Strange right?

Can the two symbols ever able to unset? Anyone has tried that before?

Appreciate any comments.

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/dfcdeb0b/attachment-0001.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Sun, 27 Sep 2015 14:09:07 +1300, vibnwis said:

> Long story. I need to incorporate Xenoma, the open sournce real-time patch
> of Linux.

First thing to do is to verify that you *really* need the patch at all.
95% of people who think they need special real-time patches don't actually
need them.  Linux already has fairly good soft real-time support, which
is good for most stuff.

> . I could not get it work and the assistance I got suggested that the symbols
> would need to unset

So what *exactly* happened when it failed to work? The patch didn't apply?
The kernel wouldn't compile?  won't boot? Boots but no realtime?  Any
error messages?

What suggested that TRACE_IRQFLAGS would make a difference?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150926/3f6e3307/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

So what *exactly* happened when it failed to work? The patch didn't apply?
The kernel wouldn't compile?  won't boot? Boots but no realtime?  Any
error messages?

What suggested that TRACE_IRQFLAGS would make a difference?

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

"The problematic option is CONFIG_TRACE_IRQFLAGS, not
> > CONFIG_CONTEXT_TRACKING, and you have it enabled, since without it,
> > you would not be able to enable CONFIG_LOCKDEP. Please disable
> > CONFIG_TRACE_IRQFLAGS. You will need to disable all the options
> > depending on that option, such as CONFIG_LOCKDEP."

First thing to do is to verify that you *really* need the patch at all.
95% of people who think they need special real-time patches don't actually
need them.  Linux already has fairly good soft real-time support, which
is good for most stuff.

Experimenting for automation and for educational purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/78a88552/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

Okie, I think one of the reason I am not able to unset
CONFIG_TRACE_IRQFLAGS and CONFIG_LOCKDEP is, "kernel debugging" in
menuconfig is being greyed-out. Would anyone please share some knowledge in
getting the DEBUG_KERNEL disabled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/9c734779/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

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.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/1ebac361/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Sun, 27 Sep 2015 19:00:44 +1300, vibnwis said:

> Would anyone please share some knowledge in getting the DEBUG_KERNEL
> disabled.

Same way you disable anything ese....

'make menuconfig', and hit / and enter DEBUG_KERNEL. Turn off whatever
is causing it to be set.  Recursively apply until done.

Though to be honest, I don't think it will do you much good until you
figure out *why* DEBUG_KERNEL needs to be off....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/94fd3695/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

On 28 September 2015 at 03:52, <Valdis.Kletnieks@vt.edu> 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?
>
The above error message is from the output of the test app, "latency"

>
> 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.....
>
Thanks for sharing. Being a newbie, I would have to have some sort faith
until it is proven otherwise. Hence, I am tasked to get the TRACE_IRQFLAGS
turn off. Once, I have got it done and the results would tell us if the
patches were fine or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/e5accb85/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Mon, 28 Sep 2015 09:58:21 +1300, vibnwis said:

> Thanks for sharing. Being a newbie, I would have to have some sort faith
> until it is proven otherwise. Hence, I am tasked to get the TRACE_IRQFLAGS
> turn off. Once, I have got it done and the results would tell us if the
> patches were fine or not.

The fact they may work with a specific option turned off is *not* proof
that they are "fine" - merely that it doesn't trip over the problem.  It's
kind of like being told your car's brakes are possibly defective and you
should avoid heavy braking - and your response is to choose a path home that
doesn't involve any heavy braking and then saying your brakes are "fine".

It's even more worrisome that people are suggesting "just turn it off"
without being able to point at a reason *why* it needs to be turned off.

Which gives you more confidence:

NVidia's modules won't work on a kernel defined with LOCKDEP enables, we
don't know why, so just turn it off..

versus

NVidia's modules won't work on a LOCKDEP kernel because with that defined,
the locking functions called by the module are redirected to debugging LOCKDEP
variants that are EXPORT_SYMBOL_GPL.  When you try to modprobe it, the _GPL
variants aren't available to the NVidia module due to its licensing, so you
get 'unresolved symbol' errors.  This information should be enough for you to
figure out how to fix your personal copy and make it work (but not to make
that copy redistributable).

See the difference?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/1c7d2ea1/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

The fact they may work with a specific option turned off is *not* proof

> that they are "fine" - merely that it doesn't trip over the problem.  It's
> kind of like being told your car's brakes are possibly defective and you
> should avoid heavy braking - and your response is to choose a path home
> that
> doesn't involve any heavy braking and then saying your brakes are "fine".
>
> It's even more worrisome that people are suggesting "just turn it off"
> without being able to point at a reason *why* it needs to be turned off.
>
> Which gives you more confidence:
>

Totally understand your points. However, Xenomai has been in many
distribution, like Ubuntu. it is simply a kind of interest to get something
to work. I had been an embedded engineer for many years, ( but never dealt
with Linux or Linux kernel). There are many Realtime OSes out there, but
costs a bomb and for hobbyist like me would not spend money buying it.
Having said that, there are a few open realtime patches that make LInux to
be realtime, deterministic. To what level, I am going to test it out. That
is my intention. If you are interested, please have a look at
www.xenomia.org.

It has nothing to do with confidence, it is pure experiment, hobby.
However, I do appreciate sharing your opinions. When times, I will have the
answers.


> NVidia's modules won't work on a kernel defined with LOCKDEP enables, we
> don't know why, so just turn it off..
>
> versus
>
> NVidia's modules won't work on a LOCKDEP kernel because with that defined,
> the locking functions called by the module are redirected to debugging
> LOCKDEP
> variants that are EXPORT_SYMBOL_GPL.  When you try to modprobe it, the _GPL
> variants aren't available to the NVidia module due to its licensing, so you
> get 'unresolved symbol' errors.  This information should be enough for you
> to
> figure out how to fix your personal copy and make it work (but not to make
> that copy redistributable).
>

> See the difference?
>

The kernel I work is for Pandaboard. Hence NVidia will not in the picture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150928/1ec24c30/attachment-0001.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Mon, 28 Sep 2015 11:42:34 +1300, vibnwis said:

> > See the difference?

> The kernel I work is for Pandaboard. Hence NVidia will not in the picture.

The point is that one explanation gives a lot more confidence and understanding
than the other.  I'll let you figure out for yourself which the suggestions
to turn off TRACE_IRQFLAGS sounds more like....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150927/eae5e053/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Jim Cromie]

On Sun, Sep 27, 2015 at 8:52 AM, <Valdis.Kletnieks@vt.edu> 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

I first started using it (then called Adeos/ipipe also) shortly after
starting to build my own kernels,
I had it running on 2.4.27, on a i586mmx, before I had any clue how to hack
at linux.
If I could do it then, its not entirely difficult or crazy.  Maybe I got a
little lucky,
maybe Id accumulated more experience by then than the OP.

main keepers are Phillipe Gerum, Gilles Chanterperdrix, Jan Kiska, they
have numerous patches in linux;
blackfin arch, canbus, arm iirc.  I recognize Valdis' name too, I know my
only honest read on your talents is
`git log --oneline --author $_` for @names,

To me, youre all heavy hitters, and know WTH youre doing in the kernel.

Of course my impression is from almost a decade old, and mainline linux has
gotten huge RT improvements.
I know I never came close to proving I needed adeos/xenomai, so when the
extra steps got in the way,
I just stopped using it, and started actually hacking.

Back then, my notion was to get GPIO pins to emit a jitter free pulse train
to an RC servo.
I did get the GPIO written and accepted, but never got around to putting
interrupts into it
(I thought I might need that to read the pulse train coming from the radio,
using interrupts
to detect rising and falling edges while keep latency down, and polling
loops out)
Or the other things I didnt yet think of.

I still would like to get around to dragging nsc_gpio and scx200_gpio into
the gpiolib era.
I hope Im not forced to protest its removal and promise the upgrades before
my lazy-hobbyist-quality shipment of round-to-its arrive.

But I have to get a bootable image onto a CF for my soekris, havent tried
in years :-{
I never did grok what grub docs were telling me.   I'll have to try lilo
next time.

I still think that reading and writing RC servo pulse trains out of a
generic kernel gpio hw/sw combo
is a reasonable technical goal, even though these days youd probably use a
panda/beagle/rpi board
to do it, iirc the rpi has some slick (arcane but flexible) counters/timers
that could modulate
 a 0.5-3.5ms pulse in a 20ms period without much cpu load.

Anyway, I'll wrap up with a few connected (to me) points and questions.

if you, Valdis, take a careful look at xenomai, I think youll find it
better than you suggested,
and if you see anything wrong, I bet youd get a productive discussion.
With that in mind, I cc'd those guys.
I hope I can follow it, just a bit.  It will be deep water for me.
(I also hope I didnt just do a gang tackle with all the ccs ;-)

do you think vanilla kernel and cheap-ass gpio hw can do an adequate job of
reading 2 channels of
cheap-ass RC servo signals from the RC reciever, and transcode them
(straight shot at 1st, then with kernel-modulation)
to 2 gpio outputs ?   Its not the way one would do it, but it could still
be a useful model.

If so, is it a useful stake in the ground, a practical target for a
semi-skilled, not-yet-retired hobbyist ?
Whats the assemblage of modules that makes sense, and needed features of
them ?
If you want to get specific, talk about the scx200_* modules, I have a hope
of grokking them ;-)

at a high level, I thought Adeos was slick-as-snot thing, maybe a
micro-hypervisor (if such a notion makes sense)
only virtualizing the smallest surface for RT.  The massive RT-kernel
improvements that have been integrated
over the last decade are in contrast sprinkled everywhere, by careful and
skilled magicians, very much a complementary approach.  Using them together
and optimally is a high art (mixology?), and one that surely changes  with
each new RT-kernel derived feature to hit mainline, as well as playing
poorly with other kernel hypervisors (OP did you do that ?)

feel free to rebrand this subject as you see fit, Im already WAY OT.
I hope it will be an illuminating thread, and one that gives me a coherent
picture of how to do it.
It will make starting easier, even (or especially) if it takes me 6 months
to do so.

jeez, Ive got work to do,
and reigniting an old hobby isnt it.
But obviously, the ghost of the itch is still there.
better get some calamine lotion ;-)

thanks
Jim Cromie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151002/70e27270/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Fri, Oct 02, 2015 at 09:56:39AM -0600, Jim Cromie wrote:
> On Sun, Sep 27, 2015 at 8:52 AM, <Valdis.Kletnieks@vt.edu> 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

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Fri, Oct 02, 2015 at 09:56:39AM -0600, Jim Cromie wrote:
> On Sun, Sep 27, 2015 at 8:52 AM, <Valdis.Kletnieks@vt.edu> 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

Actually, I think the following answer on the xenomai mailing list:
http://xenomai.org/pipermail/xenomai/2015-September/035126.html

Should make clear the fact that the answer about TRACE_IRQFLAGS was
an answer to the errors in the kernel log, not an answer to the
issue with mlockall.

-- 
					    Gilles.
https://click-hack.org

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Valdis.Kletnieks at vt.edu]

On Fri, 02 Oct 2015 18:11:53 +0200, Gilles Chanteperdrix said:

> 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.

Thanks for the detailed explanation - It's a refreshing change from the
usual cargo-cult programming "It seems to break but we have no idea why,
so just turn it off" we often see with out-of-tree patches.

One thing jumped out at me:

> The principle of Xenomai is to be able to run while Linux believes
> its interrupts are off, in the middle of its critical sections

Are you saying that it enables interrupts when Linux thinks they are off?

If so, all I can say is: You're a far braver man than I. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151002/d7ac520c/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Fri, Oct 02, 2015 at 05:43:52PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 02 Oct 2015 18:11:53 +0200, Gilles Chanteperdrix said:
> 
> > 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.
> 
> Thanks for the detailed explanation - It's a refreshing change from the
> usual cargo-cult programming "It seems to break but we have no idea why,
> so just turn it off" we often see with out-of-tree patches.

Well, it also depends on what the option is, projects with small
numbers of contributors do not necessarily have the time to
investigate breakages introduced by some obscure options. lockdep is
not "some obscure option", people want to be able to enable it.

> 
> One thing jumped out at me:
> 
> > The principle of Xenomai is to be able to run while Linux believes
> > its interrupts are off, in the middle of its critical sections
> 
> Are you saying that it enables interrupts when Linux thinks they are off?

Yes, but of course if an interrupt happens for Linux during that time,
it is logged, then played back when Linux unmasks interrupts. It is
a very old principle:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.8347

The advantage of doing that is that if an interrupt happens for the
real time system, it can be handled without waiting for Linux to
unmask interrupts.

> 
> If so, all I can say is: You're a far braver man than I. :)

The alternate solution is the native preemption, implemented by the
preempt_rt patch. But we do not know yet which of the two solutions
is crazier. It seems both have strengths and weaknesses. The next
version of Xenomai, about to be released, lets the user choose his
side.

-- 
					    Gilles.
https://click-hack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151003/427f2cfe/attachment.bin 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

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 <
gilles.chanteperdrix@xenomai.org> wrote:

> On Fri, Oct 02, 2015 at 09:56:39AM -0600, Jim Cromie wrote:
> > On Sun, Sep 27, 2015 at 8:52 AM, <Valdis.Kletnieks@vt.edu> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151004/005c6f6d/attachment-0001.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Sun, Oct 04, 2015 at 01:33:16AM +1300, vibnwis wrote:
> 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".

I did not say you were an idiot. I said I was unable to communicate
with you. Anybody can read the xenomai mailing list thread, and see
that I was answering your mails, and your answers showed that you
had not understood my answers. Over and over again.

> 
> 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.

I do not know what patch you are talking about. If you are talking
about an I-pipe patch, I would suggest you to look at the xenomai
download area, and give you an URL, but you are not going to follow
the URL anyway, as you have done with all the previous ones.

This is my last answer to any of your mails.

-- 
					    Gilles.
https://click-hack.org

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Sun, Oct 04, 2015 at 01:33:16AM +1300, vibnwis wrote:
> 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".

And by the way, the link I already posted showed that your question
was answered, whether or not coming from an "idiot".

-- 
					    Gilles.
https://click-hack.org

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

>
>
>
> I did not say you were an idiot.

I said I was unable to communicate
> with you. Anybody can read the xenomai mailing list thread, and see
> that I was answering your mails, and your answers showed that you
> had not understood my answers. Over and over again.
>

i did not say you said i was an idiot as well. I said i was treated like an
"idiot" for assuming i was not able to follow through. Having said that all
your links were not able to resolve the issues. Confidently and yet
impatiently you provided the links thinking of it would be the resolutions,
would it over confident? Over and over again, you links and suggestions
don't work.

You blame me for the issues because i do not comprehend you comments.
Really! Now you confirm that it is your fault for not incorporating the
patch months ago. If you ever have some self-awareness, humbly look into
your part, you would have realise it. in addition, you would probably being
grateful to me for testing, and alerting your the faults you had committed.

As for my part, not filling ashamed of my limited knowledge, i tried my
best to get LOCKDEP and TRACE_IRQFLAGS_SUPPORT disable. Yet,  i couldn't
and hence, tried my luck here in kernelbies. The results say my logic was
right.

Last but not least, i wonder why this discussion would end in such nature?
my guess, no one is perfect, respecting others and their differences and
being patient are the key.

Good luck.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151005/22a4cdee/attachment-0001.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Mon, Oct 05, 2015 at 02:24:17PM +1300, vibnwis wrote:
> >
> >
> >
> > I did not say you were an idiot.
> 
> I said I was unable to communicate
> > with you. Anybody can read the xenomai mailing list thread, and see
> > that I was answering your mails, and your answers showed that you
> > had not understood my answers. Over and over again.
> >
> 
> i did not say you said i was an idiot as well. I said i was treated like an
> "idiot" for assuming i was not able to follow through. Having said that all
> your links were not able to resolve the issues. Confidently and yet
> impatiently you provided the links thinking of it would be the resolutions,
> would it over confident? Over and over again, you links and suggestions
> don't work.

No, really, no. Re-read the thread. When you first posted your
configure line, I told you "do not put a dash at the end of the
argument to the --host option". You sent 4 or 5 more mails
continuing to pass the wrong arguments to the --host option and CC
variable. In the second mail, I patiently sent you a link in Xenomai
documentation explaining another way what to pass to the --host
option, and a link to the autotools documentation giving you the
detailed explanation for cross-compiling. Instead of following these
links, reading them, doing what they said and what I said, you
continued passing the wrong options, then started assuming that you
were not compiling the right code, and started compiling the wrong
code. 

> 
> You blame me for the issues because i do not comprehend you comments.
> Really!

I did not accuse you for not listening me. I said
communicating with you was beyond my competences, so in fact, I
accuse me of not being able to communicate with you. So, I stopped
trying, and told you that I hoped someone else on the xenomai
mailing list would answer you. And somebody probably would have, but
you did not even try.

-- 
					    Gilles.
https://click-hack.org

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Mon, Oct 05, 2015 at 02:24:17PM +1300, vibnwis wrote:
> >
> >
> >
> > I did not say you were an idiot.
> 
> I said I was unable to communicate
> > with you. Anybody can read the xenomai mailing list thread, and see
> > that I was answering your mails, and your answers showed that you
> > had not understood my answers. Over and over again.
> >
> 
> i did not say you said i was an idiot as well. I said i was treated like an
> "idiot" for assuming i was not able to follow through. Having said that all
> your links were not able to resolve the issues. Confidently and yet
> impatiently you provided the links thinking of it would be the resolutions,
> would it over confident? Over and over again, you links and suggestions
> don't work.
> 
> You blame me for the issues because i do not comprehend you comments.
> Really! Now you confirm that it is your fault for not incorporating the
> patch months ago.

Saying that it is my fault for not incorporating the patch months
ago was an over-simplification. More work is needed than simply
incorporating the patch. Please read the mailing list archives if
you want the full story.


> If you ever have some self-awareness, humbly look into
> your part, you would have realise it. in addition, you would probably being
> grateful to me for testing, and alerting your the faults you had
> committed.

I was well aware of the TRACE_IRQFLAGS issue, and in fact, you could
have been too, if you had done what is usually recommended and
browsed the mailing list archives.

> 
> As for my part, not filling ashamed of my limited knowledge, i tried my
> best to get LOCKDEP and TRACE_IRQFLAGS_SUPPORT disable. Yet,  i couldn't
> and hence, tried my luck here in kernelbies. The results say my logic was
> right.

Going to kernelnewbies was the good solution. Our resources are
limited, we do not have time to teach every newbie you to
enable/disable an option in the kernel configuration.

> 
> Last but not least, i wonder why this discussion would end in such nature?
> my guess, no one is perfect, respecting others and their differences and
> being patient are the key.

I have been very patient, but when someone seems not to follow
simple answers he is given, he looses credit and answering him
becomes less urgent.

The problem is that it would seem you have not understood how a free
software project support mailing list works. Our resources are
limited, for my part, I answer during my work, so 5 or 6 mails a day
is not a problem, more than that I have to stop answering and answer
when coming back from work. So, when someone on a free software
project support mailing list gives you answer, you have to try and
understand. If you do not understand the answer, just say so, and do
not ignore it, trying things at random, and post more mails, wasting
his time, and loosing credit. When a mail is not answered, wait a
day or two before asking more questions, to give time to people
doing the support answer you. Two last URL:

http://www.catb.org/esr/faqs/smart-questions.html
http://xenomai.org/asking-for-help/

-- 
					    Gilles.
https://click-hack.org

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

>
>
> Saying that it is my fault for not incorporating the patch months
> ago was an over-simplification.

 It is you who admitted it is your fault. I just repeat what you said.
However, obviously you are not happy other people say it except yourself.



> I was well aware of the TRACE_IRQFLAGS issue, and in fact, you could
> have been too, if you had done what is usually recommended and
> browsed the mailing list archives.
>
You are implying, i would get it resolved even without the patch, by doing
the recommended and browsed the mailing list archives.

>
> Going to kernelnewbies was the good solution. Our resources are
> limited, we do not have time to teach every newbie you to
> enable/disable an option in the kernel configuration.
>
Again, you are implying, that without the patch i could get the issues
resolved. Going to kernelnewbies was to confirm my logic is correct.

>
> I have been very patient, but when someone seems not to follow
> simple answers he is given, he looses credit and answering him
> becomes less urgent.
>
Again, you blame me for not following the comments. You have been going
back and forth on this issues. However, the evidence shows that i did
follow and tried your comments, but not all of them are valid. And with
others helps and my persistent, I managed to resolved some of the issues.
Having said, I do not blame you  for giving false answers. I do appreciate
the efforts.


>
> The problem is that it would seem you have not understood how a free
> software project support mailing list works. Our resources are
> limited, for my part, I answer during my work, so 5 or 6 mails a day
> is not a problem, more than that I have to stop answering and answer
> when coming back from work.


it is you who jumps to the conclusion that i do not understand how free
software project support mailing list works. it is you who thinks i am not
qualified in participating the mailing list. I have done my homework. i had
tried all i could before asking questions. I never expect clear solutions
out from mailing lists.
For your cases, i had stated my appreciation and gratefulness to your
assistance, didn't i?

So, when someone on a free software
> project support mailing list gives you answer, you have to try and
> understand.



> If you do not understand the answer, just say so, and do
> not ignore it, trying things at random, and post more mails, wasting
> his time, and loosing credit.


Being a newbie, i am loosing my credit in whatever way i do in front of
impatient authoritative Xenomai software creator like you. If i say, "i
don't understand', you would say, please go elsewhere, this is not for
newbies. if i say, 'how this is being done', you would say ( above your own
statement) do what is recommended, search the mailing lists, you would get
the answer.

 When a mail is not answered, wait a
day or two before asking more questions, to give time to people
doing the support answer you.

This is completely irrelevant in the original issues. You trying hard to
get me and as hard as you could.

Two last URL:

http://www.catb.org/esr/faqs/smart-questions.html
http://xenomai.org/asking-for-help/=

Not achieving your goals, now you through the books.


Think again, have you really resolved the real issues? others who have or
are reading these would be puzzled what was the real issue. i will let them
to judge it themselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151005/dbd518af/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[vibnwis]

>
>
> No, really, no. Re-read the thread. When you first posted your
> configure line, I told you "do not put a dash at the end of the
> argument to the --host option". You sent 4 or 5 more mails
> continuing to pass the wrong arguments to the --host option and CC
> variable. In the second mail, I patiently sent you a link in Xenomai
> documentation explaining another way what to pass to the --host
> option, and a link to the autotools documentation giving you the
> detailed explanation for cross-compiling. Instead of following these
> links, reading them, doing what they said and what I said, you
> continued passing the wrong options, then started assuming that you
> were not compiling the right code, and started compiling the wrong
> code.
>
 I did tried with and without dash and i managed to get --host issues
resolved looking into the makefile. The issue was it was compiling the
wrong code which was pointed out by Philip. Your comments were not valid.
However, i appreciated it.

>
> --
>                                             Gilles.
> https://click-hack.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151005/d0a24026/attachment.html 

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Gilles Chanteperdrix]

On Mon, Oct 05, 2015 at 08:54:25PM +1300, vibnwis wrote:
> >
> >
> > Saying that it is my fault for not incorporating the patch months
> > ago was an over-simplification.
> 
>  It is you who admitted it is your fault. I just repeat what you said.
> However, obviously you are not happy other people say it except yourself.
> 
> 
> 
> > I was well aware of the TRACE_IRQFLAGS issue, and in fact, you could
> > have been too, if you had done what is usually recommended and
> > browsed the mailing list archives.
> >
> You are implying, i would get it resolved even without the patch, by doing
> the recommended and browsed the mailing list archives.

Yes.

> 
> >
> > Going to kernelnewbies was the good solution. Our resources are
> > limited, we do not have time to teach every newbie you to
> > enable/disable an option in the kernel configuration.
> >
> Again, you are implying, that without the patch i could get the issues
> resolved. Going to kernelnewbies was to confirm my logic is correct.

Yes, people are using xenomai without Jan's patch on the ARM
platform: you have to get the CONFIG_TRACE_IRQFLAGS option disabled.

> 
> >
> > I have been very patient, but when someone seems not to follow
> > simple answers he is given, he looses credit and answering him
> > becomes less urgent.
> >
> Again, you blame me for not following the comments. You have been going
> back and forth on this issues. However, the evidence shows that i did
> follow and tried your comments, but not all of them are valid. And with
> others helps and my persistent, I managed to resolved some of the issues.
> Having said, I do not blame you  for giving false answers. I do appreciate
> the efforts.

We must be looking at different evidences, because I re-read the
thread again this morning, and clearly, at least for the
cross-compilation issue (the --host thing), the way I read the
evidence show that you have sent something like a dozen of mails of
random tries and issues, which could have been avoided if you had
passed the right argument to the --host option from the beginning.

> 
> 
> >
> > The problem is that it would seem you have not understood how a free
> > software project support mailing list works. Our resources are
> > limited, for my part, I answer during my work, so 5 or 6 mails a day
> > is not a problem, more than that I have to stop answering and answer
> > when coming back from work.
> 
> 
> it is you who jumps to the conclusion that i do not understand how free
> software project support mailing list works. it is you who thinks i am not
> qualified in participating the mailing list. I have done my homework. i had
> tried all i could before asking questions. I never expect clear solutions
> out from mailing lists.
> For your cases, i had stated my appreciation and gratefulness to your
> assistance, didn't i?

Yes you did. I am sorry for having sent this mail. This part was
indeed a blatant lack of humility. I will stop answering now.

My apologies.
Regards.

-- 
					    Gilles.
https://click-hack.org