Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT

[Jim Cromie]

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