On Sun, Sep 27, 2015 at 8:52 AM, <Valdis.Kletnieks@xxxxxx> 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
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
