Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT
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
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?
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?
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?
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
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?
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.
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.
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....
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.....
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.
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
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
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. :)
On Fri, Oct 02, 2015 at 05:43:52PM -0400, Valdis.Kletnieks@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
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
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
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.
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
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
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
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.
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
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
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
participants (4)
-
Gilles Chanteperdrix -
Jim Cromie -
Valdis.Kletnieks＠vt.edu -
vibnwis