Re: [Xenomai-core] [PATCH 1/1] rtdk: various fixes.
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
When exiting a process, rtdk buffers are not flushed. Fix that by
introducing a destructor for the library which flushes the buffers.
When forking, if the main thread has an rt_printf buffer, it is reused by
the child, which is a good thing, however, it is not emptied, so could
cause
the same message to be printed twice. Fix that by emptying the main thread
buffer upon fork.
When spawning the rt_print thread, it uses a stack size of
PTHREAD_STACK_MIN, which may be too small for printf to work reliably on
some architectures, set the stack size to the
empirically-known-to-be-working size of... 32Kb.
---
src/rtdk/init.c |5 +
src/rtdk/internal.h |1 +
src/rtdk/rt_print.c | 21 -
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/rtdk/init.c b/src/rtdk/init.c
index 2084c73..b864175 100644
--- a/src/rtdk/init.c
+++ b/src/rtdk/init.c
@@ -22,3 +22,8 @@ static __attribute__ ((constructor)) void
__init_rtdk(void)
{
__rt_print_init();
}
+
+static __attribute__ ((destructor)) void __exit_rtdk(void)
+{
+ __rt_print_exit();
+}
diff --git a/src/rtdk/internal.h b/src/rtdk/internal.h
index bd15b2d..345d4fa 100644
--- a/src/rtdk/internal.h
+++ b/src/rtdk/internal.h
@@ -23,6 +23,7 @@
#include sys/time.h
void __rt_print_init(void);
+void __rt_print_exit(void);
void __real_free(void *ptr);
void *__real_malloc(size_t size);
diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
index c6b5c55..dae7d7b 100644
--- a/src/rtdk/rt_print.c
+++ b/src/rtdk/rt_print.c
@@ -455,7 +455,7 @@ static void spawn_printer_thread(void)
pthread_attr_t thattr;
pthread_attr_init(thattr);
- pthread_attr_setstacksize(thattr, PTHREAD_STACK_MIN);
+ pthread_attr_setstacksize(thattr, 32768);
Mmh... maybe rather $something +PTHREAD_STACK_MIN?
No, PTHREAD_STACK_MIN sucks, it is not appropriate, and have very
varying values on different platforms. On some plaforms, with some
versions of glibc, it is 4096, way too small, so that printf generates a
segfault due to a stack overflow.
However, due to the work done when solving the stack issue reported by
Stefan, I hid the magic constants in a function called xeno_stacksize
and xeno_stacksize(0) gives a reasonnable default value.
OK, then go for this service (is it already merged)?
pthread_create(printer_thread, thattr, printer_loop, NULL);
}
@@ -464,6 +464,15 @@ static void forked_child_init(void)
struct print_buffer *my_buffer = pthread_getspecific(buffer_key);
struct print_buffer **pbuffer = first_buffer;
+ if (my_buffer) {
+ /* Any content of my_buffer should be printed by our parent,
+not us. */
+ memset(my_buffer-ring, 0, my_buffer-size);
+
+ my_buffer-read_pos = 0;
+ my_buffer-write_pos = 0;
+ }
+
Ack.
/* re-init to avoid finding it locked by some parent thread */
pthread_mutex_init(buffer_lock, NULL);
@@ -518,3 +527,13 @@ void __rt_print_init(void)
spawn_printer_thread();
pthread_atfork(NULL, NULL, forked_child_init);
}
+
+void __rt_print_exit(void)
+{
+ if (buffers) {
+ /* Flush the buffers. Do not call print_buffers here
+ * since we do not know if our stack is big enough. */
+ nanosleep(print_period, NULL);
+ nanosleep(print_period, NULL);
+ }
+}
IIRC, that's what cleanup_buffer is supposed to do, triggered by the
pthread key destruction. Can you explain why it failed in your scenario.
pthread_key destruction is called when a thread is cancelled. My
testcase was calling exit.
exit() does not trigger these cleanup hooks? Too bad.
Besides, cleanup_buffer flushes the buffers
from the context of the calling thread, which is a bad idea, due to the
stack sizes situation.
If a thread requesting rt_printk services is not capable of performing
this work during it's cleanup, when there is no significant stack load,
I would say it's misconfigured /wrt stack size.
Do you agree with this rebased patch?
diff --git a/src/rtdk/init.c b/src/rtdk/init.c
index 2084c73..b864175 100644
--- a/src/rtdk/init.c
+++ b/src/rtdk/init.c
@@ -22,3 +22,8 @@ static __attribute__ ((constructor)) void __init_rtdk(void)
{
__rt_print_init();
}
+
+static __attribute__ ((destructor)) void __exit_rtdk(void)
+{
+ __rt_print_exit();
+}
diff --git a/src/rtdk/internal.h b/src/rtdk/internal.h
index bd15b2d..345d4fa 100644
--- a/src/rtdk/internal.h
+++ b/src/rtdk/internal.h
@@ -23,6 +23,7 @@
#include sys/time.h
void __rt_print_init(void);
+void __rt_print_exit(void);
void __real_free(void *ptr);
void *__real_malloc(size_t size);
diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
index 1d2b70a..fc170d0 100644
--- a/src/rtdk/rt_print.c
+++ b/src/rtdk/rt_print.c
@@ -29,6 +29,7 @@
Re: [Xenomai-core] [PATCH xenomai-2.5 0/3] rtcan: mscan: new OF platform driver for MPC521x and MPC5200
Wolfgang Grandegger wrote: From: Wolfgang Grandegger w...@denx.de This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x from Freescale by introducing a new OF platform driver for both, the MPC521x and MPC5200, while still keeping the old driver for the MPC5200 for compatibility with older kernel versions. Hi Wolfgang, there seems to be something missing, because I get a compilation error on lite-5200: http://sisyphus.hd.free.fr/~gilles/bx/#powerpc Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH xenomai-2.5 0/3] rtcan: mscan: new OF platform driver for MPC521x and MPC5200
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: From: Wolfgang Grandegger w...@denx.de This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x from Freescale by introducing a new OF platform driver for both, the MPC521x and MPC5200, while still keeping the old driver for the MPC5200 for compatibility with older kernel versions. Hi Wolfgang, there seems to be something missing, because I get a compilation error on lite-5200: http://sisyphus.hd.free.fr/~gilles/bx/#powerpc Well, I obviously did not test the driver with old versions of the Linux kernel, sorry. For 2.6.29 and 2.6.30 the following patch should fix the build: diff --git a/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c b/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c index 48abd89..47e34b6 100644 --- a/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c +++ b/ksrc/drivers/can/mscan/rtcan_mscan_mpc5xxx.c @@ -76,7 +76,11 @@ static u32 __devinit mpc52xx_can_get_clock(struct of_device *ofdev, else *mscan_clksrc = MSCAN_CLKSRC_XTAL; +#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,31) + freq = mpc52xx_find_ipb_freq(ofdev-node); +#else freq = mpc5xxx_get_bus_frequency(ofdev-node); +#endif if (!freq) return 0; For 2.4 I will have a close look now. This proves, your regression test build tool is really useful. Thanks, Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] I-pipe for 2.6.32 PPC
On Tue, 2010-01-12 at 17:18 -0500, Lennart Sorensen wrote: On Tue, Jan 12, 2010 at 08:23:35PM +0100, Philippe Gerum wrote: This is likely because your knowledge overwhelms mine. I'm only a moron, so git diff with a proper commit number, or even patch -R does work for me. Simple things always work for simple idiots, it's a fact of life. Well I have not been able to find the magic invocation that lets me take the DENX tree (which I have had around for a long time just to look at occationally, whenever I was trying to get an ipipe patch to apply), apply the ipipe patch, revert the DENX changes to get back to a release kernel, and generate a diff of the ipipe changes. It has never worked when I tried. To get a complete pipeline, you need the -noarch side, and the -powerpc side. ipipe-2.6.32-powerpc is based on ipipe-2.6.32-noarch, which is based on v2.6.32 mainline. From the official I-pipe tree located there: git://git.denx.de/ipipe-2.6.git $ git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpc gives: 704529e powerpc/ipipe: arch-dependent bits for 2.6.32.2 2cc8efe Merge branch 'DENX-v2.6.32' into ipipe-2.6.32-newppc 01765d4 powerpc: merge DENX-v2.6.32 bits ea15238 powerpc: merge 2.6.32.2 -stable So, what you want is a merge between 2.6.32.2 mainline and the powerpc bits, skipping the DENX bits: $ git checkout -b ipipe-mainline ipipe-2.6.32-noarch $ git cherry-pick ea15238 $ git cherry-pick 704529e This will lead to two trivial rejects, one is in the ppc64 section you do not care about, the other in process.c, which is a hunk related to supporting the PA6T 64bit architecture as well, which you don't care about, either. # unmerged: arch/powerpc/kernel/process.c # unmerged: arch/powerpc/mm/hash_native_64.c Basically, it's a 2 minutes work. Granted, it applies to 2.6.32.2 only, and more conflicts could pop up with different revisions of this work; but this has never been a massive pain to move from a DENX tree to mainline, and I did it quite a few times. If you do think that the situation for x86 must be applicable to any other architecture, then I really can't do anything for you, except perhaps suggest to get your feet a bit more wet with those, and probably do some reality check against your knowledge of the embedded world. Actually yes I think the x86 situation should be applicable to other architectures. I am currently running embedded x86, powerpc and coldfire, all using release kernels. That to me is a highly desirable goal. The coldfire was painful a year ago, but it sure has come a long way in that year. x86 does not qualify for this discussion; with a x86-based system, even if the kernel at hand does not support the very latest fancy device you have on board, your kernel will likely still boot and run properly. On the other hand, you would not even try booting your mpc8360 over a kernel built for 44x. But given you want to support both, if either of both happen to be in a poor state in your reference tree, things start hitting the crapper. The DENX tree saved my day so far, because it allowed me to work on all powerpc platforms from a single code base. Aside of this, I don't intend to get dragged into such a discussion, it's a pure loss of time. So please, take what I can offer, or just blame me for being an idiot to have a different perspective from yours, but don't waste my bandwidth. I need it direly to be able to issue patches you can use, even at the expense of cloning a git tree. Well debian used to try and package xenomai. They are still on 2.4.8. I suspect they may have given up on it given that they only use release kernels, and many of the patches are useless in that case. What's the point of trying then. The Blackfin uClinux distro was still shipping 2.4.7 in their latest 2009R1 release, albeit they merged the Blackfin-specific bits from the pipeline into their official kernel tree, many moons ago. Incidentally, I'm maintaining those bits for their development kernel directly feeding mainline, so I don't think your reasoning should be generalized. This said, if you have first hand information from the Debian team regarding this, maybe you should tell them to drop us a note; we would be happy to help. However, if you do think that some good reason might exist to work with DENX material when it comes to powerpc over embedded platforms, but want to help in issuing a mainline-based version of the pipeline patches regularly, then I would agree to ease your task. Well I do work with embedded powerpc, and so far have had no use for the DENX tree. I have no idea what powerpc systems need stuff from the DENX tree to work, but certainly not the mpc8360 I deal with. I understand your point from your perspective. But maintaining our code base for mpc8360 only is not enough for us. The reason why the powerpc patches are DENX-based is simply that this tree worked for me over time, for various platforms
Re: [Xenomai-core] [Adeos-main] I-pipe for 2.6.32 PPC
Hi Philippe, Philippe Gerum wrote: [snip] On Tue, 2010-01-12 at 17:18 -0500, Lennart Sorensen wrote: You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards: http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3 Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions. Here is the story. Lennart mentioned on the linuxppc-dev mailing list, that he has a iPipe patch for 2.6.32: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079191.html I asked him privately, if the patch is available and he sent it to me with the note, that I can publish it on the mailing list if I feel it's useful. This patch helped me to go ahead immediately with some related development work. I also forwarded the patch to you. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Adeos-main] I-pipe for 2.6.32 PPC
On Fri, 2010-01-15 at 11:14 -0500, Lennart Sorensen wrote: On Fri, Jan 15, 2010 at 04:03:31PM +0100, Philippe Gerum wrote: To get a complete pipeline, you need the -noarch side, and the -powerpc side. ipipe-2.6.32-powerpc is based on ipipe-2.6.32-noarch, which is based on v2.6.32 mainline. From the official I-pipe tree located there: git://git.denx.de/ipipe-2.6.git $ git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpc rceng02:/data/git-trees/ipipe-2.6# git log --abbrev-commit --oneline -4 ipipe-2.6.32-powerpc fatal: ambiguous argument 'ipipe-2.6.32-powerpc': unknown revision or path not in the working tree. Use '--' to separate paths from revisions From your end, the ipipe branches you care of are remote ones available from the origin namespace, so you should try origin/ipipe-2.6.32-powerpc, and origin/ipipe-2.6.32-noarch is specs. Hmm, is my git version too old? No, I think it's fine. snip x86 does not qualify for this discussion; with a x86-based system, even if the kernel at hand does not support the very latest fancy device you have on board, your kernel will likely still boot and run properly. On the other hand, you would not even try booting your mpc8360 over a kernel built for 44x. But given you want to support both, if either of both happen to be in a poor state in your reference tree, things start hitting the crapper. The DENX tree saved my day so far, because it allowed me to work on all powerpc platforms from a single code base. Certainly kernels for embedded systems often are only menat for one system. That doesn't mean you couldn't build a kernel with support for multiple systems. Sure, but for that, you need to have a single source tree that works for both. This is the gist of the issue I'm facing. The Blackfin uClinux distro was still shipping 2.4.7 in their latest 2009R1 release, albeit they merged the Blackfin-specific bits from the pipeline into their official kernel tree, many moons ago. Incidentally, I'm maintaining those bits for their development kernel directly feeding mainline, so I don't think your reasoning should be generalized. This said, if you have first hand information from the Debian team regarding this, maybe you should tell them to drop us a note; we would be happy to help. No I don't. Just speculation. I just remember trying to use the package and finding that it simply could not apply to the released kernel sources. I understand your point from your perspective. But maintaining our code base for mpc8360 only is not enough for us. The reason why the powerpc patches are DENX-based is simply that this tree worked for me over time, for various platforms (52xx, 4xx/44x, pa6t come to mind), way before mainline did. Xenomai supports recent platforms like the 512x series precisely because of that as well. Does this mean that the pipeline patches will be based on the DENX tree until hell freezes? No, this does not, because the DENX folks are doing their job as well, and make their best to close the gap between their tree and mainline, taking all needed provisions to get their bits merged upstream sooner. Well I hope it happens soon. Things always become much easier when you can work with the official kernel releases. The powerpc support in the main kernel tree seem rather good. Generally yes, it is. We just have to deal with exceptions, and those exceptions used to be many. I agree that things evolve and the situation has to be reassessed from time to time, though. It's probably a good time to do this. A sidenote though: you can run Xenomai over mpc8360 because DENX published this support which was initially based on their tree, on behalf of a customer, like a bunch of other developments: http://www.denx.de/en/Software/SoftwareXenomaiProjects This makes your argument, about not depending on anything being DENX-originated, sound a bit weird. Make no mistake, you owe them quite a few kudos. Actually, anyone running Xenomai over powerpc owe them a lot. Oh I know that. We paid for it. It was well worth it. That doesn't mean I want to use the DENX kernel tree. But at least, you know for sure why having a working kernel is important, specially to those who cannot rely on mainline yet. You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards: http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3 Well I managed to get every piece except a few ppc64 bits (which as usual seemed to only apply to parts of the DENX tree. When will those bits go mainline I wonder. They seem to have been there for a while now). I can only test on the 83xx boards we have here, but
Re: [Xenomai-core] [Adeos-main] I-pipe for 2.6.32 PPC
On Fri, 2010-01-15 at 16:33 +0100, Wolfgang Grandegger wrote: Hi Philippe, Philippe Gerum wrote: [snip] On Tue, 2010-01-12 at 17:18 -0500, Lennart Sorensen wrote: You did port the pipeline to 2.6.32/ppc32 for running on mpc8360, which fits your needs. But the pipeline patch has to be upgraded for ppc64 as well. Even for ppc32, a patch is normally validated for a set of 4xx, 512x, 52xx, 82xx, 85xx, and 86xx platforms, by the Xenomai standards: http://www.xenomai.org/index.php/Embedded_Device_Support#Supported_Evaluation_Boards_3 Btw, your patch never made it to the list, since this is a subscriber-only list, and last time I checked, you were not subscribed. Or maybe you posted from a different mail address, but I did not see your mail though. I usually acknowledge public contributions. Here is the story. Lennart mentioned on the linuxppc-dev mailing list, that he has a iPipe patch for 2.6.32: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079191.html I asked him privately, if the patch is available and he sent it to me with the note, that I can publish it on the mailing list if I feel it's useful. This patch helped me to go ahead immediately with some related development work. I also forwarded the patch to you. It must be stuck somewhere, I really can't find it in my mailbox. I'll check on my side again. Thanks. Wolfgang. ___ Adeos-main mailing list adeos-m...@gna.org https://mail.gna.org/listinfo/adeos-main -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH xenomai-2.5 0/3] rtcan: mscan: new OF platform driver for MPC521x and MPC5200
Wolfgang Grandegger wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: From: Wolfgang Grandegger w...@denx.de This patch series adds RT-Socket-CAN support for the MSCAN on the MPC512x from Freescale by introducing a new OF platform driver for both, the MPC521x and MPC5200, while still keeping the old driver for the MPC5200 for compatibility with older kernel versions. Hi Wolfgang, there seems to be something missing, because I get a compilation error on lite-5200: http://sisyphus.hd.free.fr/~gilles/bx/#powerpc Well, I obviously did not test the driver with old versions of the Linux kernel, sorry. No problem, that is what the build test is for. For 2.6.29 and 2.6.30 the following patch should fix the build: Ok. I applied a slightly different modification (fixing in wrappers.h). I am waiting for your fix for 2.4 for pushing. For 2.4 I will have a close look now. This proves, your regression test build tool is really useful. That is, if you assume people in the wild are trying older versions... -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
