Re: [Xenomai-core] [Xenomai-help] Sporadic PC freeze after rt_task_start
On Fri, 2007-07-20 at 16:20 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > ... > > Read my mail, without listening to your own grumble at the same time, > > you should see that this is not a matter of being right or wrong, it is > > a matter of who needs what, and how one will use Xenomai. Your grumble > > does not prove anything unfortunately, otherwise everything would be > > fixed since many moons. > > Why things are unfixed has something to do with their complexity. RPI is > a complex thing AND it is a separate mechanism to the core (that's why I > was suggesting to reuse PI code if possible - something that is already > integrated for many moons). > I'm afraid RPI and PI are very different beasts. The purpose of RPI is to track real-time priority for the _pseudo_ root thread, PI deals with Linux tasks. Moroever, RPI does no priority propagation beyond the first level (i.e. the root thread one), and only has to handle backtracking in a trivial way. For this reason, the PI implementation is way more complex, zillion times beyond RPI, so the effort would be absolutely counter-productive. I understand your POV, the whole RPI thing seems baroque to you, and I can only agree with you here, it is. However, we still need RPI for proper behaviour in a lot of cases, at least with a co-kernel technology under our feet. So, I'm going to submit fixes for this issue, and agree to change the default knob from enabled to disabled for the native and POSIX skins if need be, if the observation period tells us so. Now, within the RPI issue, there is the double locking one: I'm going to be very pragmatic here. If this is logically possible to keep the double locking, I will keep it. The point being that people running real-time applications on SMP configs tend in fact to prefer asymmetry to symmetry when building their design. I mean that separate CPUs are usually dedicated to different application tasks; in such a common pattern, if one of the CPU is running a frequent (mode) switching task, it may put a serious pressure on the nklock for all others (imagine a fast periodic timeline on one CPU sending data to a secondary mode logger on a second CPU, both being synchronized on a Xenomai synch). This is what I don't want, if possible. If it is not possible to define a proper locking scheme without resorting to 1) hairy and overly complex constructs, or 2) voodoo spells, then I will put everyone under the nklock, albeit I think this is a sub-optimal solution. Ok, let's move on. The main focus is -rc1, and beyond that 2.4 final. We are damned late already. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Sporadic PC freeze after rt_task_start
Philippe Gerum wrote: ... > Read my mail, without listening to your own grumble at the same time, > you should see that this is not a matter of being right or wrong, it is > a matter of who needs what, and how one will use Xenomai. Your grumble > does not prove anything unfortunately, otherwise everything would be > fixed since many moons. Why things are unfixed has something to do with their complexity. RPI is a complex thing AND it is a separate mechanism to the core (that's why I was suggesting to reuse PI code if possible - something that is already integrated for many moons). > What I'm suggesting now, so that you can't tell the rest of the world > that I'm such an old and deaf cranky meatball, is that we do place RPI > under strict observation until the latest 2.4-rc is out, and we would > decide at this point whether we should change the default value for the > skins for which it makes sense (both for v2.3.x and 2.4). Obviously, > this would only make sense if key users actually give hell to the 2.4 > testing releases (Mathias, the world is watching you). OK, let's go through this another time, this time under the motto "get the locking right". As a start (and a help for myself), here comes an overview of the scheme the final version may expose - as long as there are separate locks: gatekeeper_thread / xnshadow_relax: rpilock, followed by nklock (while xnshadow_relax puts both under irqsave...) xnshadow_unmap: nklock, then rpilock nested xnshadow_start: rpilock, followed by nklock xnshadow_renice: nklock, then rpilock nested schedule_event: only rpilock setsched_event: nklock, followed by rpilock, followed by nklock again And then there is xnshadow_rpi_check which has to be fixed to: nklock, followed by rpilock (here was our lock-up bug) That's a scheme which /should/ be safe. Unfortunately, I see no way to get rid of the remaining nestings. And I still doubt we are gaining much by the lock split-up on SMP (it's pointless for UP due to xnshadow_relax). In case there is heavy migration activity on multiple cores/CPUs, we now regularly content for two locks in the hot paths instead of just the one everyone has to go through anyway. And while we obviously don't win a dime for the worst case, the average reduction of spinning times trades off against more atomic (cache-line bouncing) operations. Were you able to measure some improvement? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
Gilles Chanteperdrix wrote:
> On 7/20/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > here comes my patch for user space tsc emulation for decrementing
> > counters. I had to extend the __xn_tscinfo structure because the counter
> > value from the last tsc update is needed to calculate the new tsc value.
>
> The struct __xn_tscinfo is a union where "fr" stands for free-running,
> the idea was that you could add your own structure for decrementer
> based tsc.
Ok. Here is version 2 of the patch.
--
Sebastian
Index: include/asm-arm/syscall.h
===
--- include/asm-arm/syscall.h (Revision 2768)
+++ include/asm-arm/syscall.h (Arbeitskopie)
@@ -4,6 +4,9 @@
* ARM port
* Copyright (C) 2005 Stelian Pop
*
+ * Copyright (C) 2007 Sebastian Smolorz <[EMAIL PROTECTED]>
+ * Support for TSC emulation in user space for decrementing counters
+ *
* Xenomai is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published
* by the Free Software Foundation; either version 2 of the License,
@@ -205,6 +208,10 @@
volatile unsigned long long *tsc;
} fr;
struct {
+ volatile unsigned *counter;
+ unsigned mask;
+ volatile unsigned *last_cnt;
+ volatile unsigned long long *tsc;
} dec;
} u;
};
@@ -248,6 +255,28 @@
if ((counter & mask) < (before & mask))
before += mask + 1;
return (before & ~mask) | (counter & mask);
+
+#elif CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_DECREMENTER
+ const unsigned mask = __xn_tscinfo.u.dec.mask;
+ unsigned long long after, before;
+ unsigned counter, last_cnt;
+
+ do {
+ before = *__xn_tscinfo.u.dec.tsc;
+ counter = *__xn_tscinfo.u.dec.counter;
+ last_cnt = *__xn_tscinfo.u.dec.last_cnt;
+ /* compiler barrier. */
+ asm("" : /* */ : /* */ : "memory");
+
+ after = *__xn_tscinfo.u.dec.tsc;
+ } while (after != before);
+
+ counter &= mask;
+ last_cnt &= mask;
+ if (counter > last_cnt)
+ before += mask + 1;
+ return (before + last_cnt - counter);
+
#endif /* CONFIG_XENO_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
}
@@ -280,7 +309,7 @@
switch(__xn_tscinfo.type) {
#if CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING
- case __XN_TSC_TYPE_FREERUNNING:{
+ case __XN_TSC_TYPE_FREERUNNING: {
unsigned long phys_addr;
phys_addr = (unsigned long) __xn_tscinfo.u.fr.counter;
@@ -296,6 +325,23 @@
((char *) addr + (phys_addr & (page_size - 1;
break;
}
+#elif CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_DECREMENTER
+ case __XN_TSC_TYPE_DECREMENTER: {
+ unsigned long phys_addr;
+
+ phys_addr = (unsigned long) __xn_tscinfo.u.dec.counter;
+ addr = mmap(NULL, page_size, PROT_READ, MAP_SHARED,
+ fd, phys_addr & ~(page_size - 1));
+ if (addr == MAP_FAILED) {
+ perror("Xenomai init: mmap(/dev/mem)");
+ exit(EXIT_FAILURE);
+ }
+
+ __xn_tscinfo.u.dec.counter =
+ ((volatile unsigned *)
+ ((char *) addr + (phys_addr & (page_size - 1;
+ break;
+ }
#endif /* CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
case __XN_TSC_TYPE_NONE:
goto error;
Index: include/asm-arm/bits/shadow.h
===
--- include/asm-arm/bits/shadow.h (Revision 2768)
+++ include/asm-arm/bits/shadow.h (Arbeitskopie)
@@ -176,6 +176,12 @@
info.u.fr.tsc = ipipe_info.archdep.tsc.u.fr.tsc;
break;
case IPIPE_TSC_TYPE_DECREMENTER:
+ info.type = __XN_TSC_TYPE_DECREMENTER,
+ info.u.dec.counter = ipipe_info.archdep.tsc.u.dec.counter;
+ info.u.dec.mask = ipipe_info.archdep.tsc.u.dec.mask;
+ info.u.dec.last_cnt = ipipe_info.archdep.tsc.u.dec.last_cnt;
+ info.u.dec.tsc = ipipe_info.archdep.tsc.u.dec.tsc;
+ break;
case IPIPE_TSC_TYPE_NONE:
return -ENOSYS;
Index: configure.in
===
--- configure.in (Revision 2768)
+++ configure.in (Arbeitskopie)
@@ -182,7 +182,8 @@
ixp4xx|pxa) arch=5
tsc_type=__XN_TSC_TYPE_FREERUNNING;;
- s3c2410) arch=4;;
+ s3c2410) arch=4
+ tsc_type=__XN_TSC_TYPE_DECREMENTER;;
sa1100) arch=4
CONFIG_XENO_ARM_SA1100=y
Index: ChangeLog
===
--- ChangeLog (Revision 2768)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-07-19 Sebastian Smolorz <[EMAIL PROTECTED]>
+
+ * include/asm-arm/syscall.h: Add user-space access to
+ tsc emulation for decrementing counters.
+
2007-07-19 Jan Kiszka <[EMAIL PROTECTED]>
* ksrc/nucleus/timer.c (xntimer_tick_aperiodic): Keep processing
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
Gilles Chanteperdrix wrote: > On 7/20/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote: > > Hi, > > > > here comes my patch for user space tsc emulation for decrementing > > counters. I had to extend the __xn_tscinfo structure because the counter > > value from the last tsc update is needed to calculate the new tsc value. > > The struct __xn_tscinfo is a union where "fr" stands for free-running, > the idea was that you could add your own structure for decrementer > based tsc. Ah, ok, will change the patch. The abbreviation was not immediately clear to me. ;-) -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
On 7/20/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote: > Hi, > > here comes my patch for user space tsc emulation for decrementing counters. I > had to extend the __xn_tscinfo structure because the counter value from the > last tsc update is needed to calculate the new tsc value. The struct __xn_tscinfo is a union where "fr" stands for free-running, the idea was that you could add your own structure for decrementer based tsc. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
Hi,
here comes my patch for user space tsc emulation for decrementing counters. I
had to extend the __xn_tscinfo structure because the counter value from the
last tsc update is needed to calculate the new tsc value.
I will post a second patch for Adeos which implements the kernel side for
s3c24xx platforms on adeos-main.
--
Sebastian
Index: include/asm-arm/syscall.h
===
--- include/asm-arm/syscall.h (Revision 2768)
+++ include/asm-arm/syscall.h (Arbeitskopie)
@@ -4,6 +4,9 @@
* ARM port
* Copyright (C) 2005 Stelian Pop
*
+ * Copyright (C) 2007 Sebastian Smolorz <[EMAIL PROTECTED]>
+ * Support for TSC emulation in user space for decrementing counters
+ *
* Xenomai is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published
* by the Free Software Foundation; either version 2 of the License,
@@ -202,6 +205,7 @@
struct {
volatile unsigned *counter;
unsigned mask;
+ volatile unsigned *last_cnt;
volatile unsigned long long *tsc;
} fr;
struct {
@@ -248,6 +252,28 @@
if ((counter & mask) < (before & mask))
before += mask + 1;
return (before & ~mask) | (counter & mask);
+
+#elif CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_DECREMENTER
+ const unsigned long long mask = __xn_tscinfo.u.fr.mask;
+ unsigned long long after, before;
+ unsigned counter, last_cnt;
+
+ do {
+ before = *__xn_tscinfo.u.fr.tsc;
+ counter = *__xn_tscinfo.u.fr.counter;
+ last_cnt = *__xn_tscinfo.u.fr.last_cnt;
+ /* compiler barrier. */
+ asm("" : /* */ : /* */ : "memory");
+
+ after = *__xn_tscinfo.u.fr.tsc;
+ } while (after != before);
+
+ counter &= mask;
+ last_cnt &= mask;
+ if (counter > last_cnt)
+ before += mask + 1;
+ return (before + last_cnt - counter);
+
#endif /* CONFIG_XENO_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
}
@@ -279,8 +305,8 @@
page_size = sysconf(_SC_PAGESIZE);
switch(__xn_tscinfo.type) {
-#if CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING
- case __XN_TSC_TYPE_FREERUNNING:{
+ case __XN_TSC_TYPE_FREERUNNING:
+ case __XN_TSC_TYPE_DECREMENTER: {
unsigned long phys_addr;
phys_addr = (unsigned long) __xn_tscinfo.u.fr.counter;
@@ -296,7 +322,6 @@
((char *) addr + (phys_addr & (page_size - 1;
break;
}
-#endif /* CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
case __XN_TSC_TYPE_NONE:
goto error;
Index: include/asm-arm/bits/shadow.h
===
--- include/asm-arm/bits/shadow.h (Revision 2768)
+++ include/asm-arm/bits/shadow.h (Arbeitskopie)
@@ -176,6 +176,12 @@
info.u.fr.tsc = ipipe_info.archdep.tsc.u.fr.tsc;
break;
case IPIPE_TSC_TYPE_DECREMENTER:
+ info.type = __XN_TSC_TYPE_DECREMENTER,
+ info.u.fr.counter = ipipe_info.archdep.tsc.u.fr.counter;
+ info.u.fr.mask = ipipe_info.archdep.tsc.u.fr.mask;
+ info.u.fr.last_cnt = ipipe_info.archdep.tsc.u.fr.last_cnt;
+ info.u.fr.tsc = ipipe_info.archdep.tsc.u.fr.tsc;
+ break;
case IPIPE_TSC_TYPE_NONE:
return -ENOSYS;
Index: configure.in
===
--- configure.in (Revision 2768)
+++ configure.in (Arbeitskopie)
@@ -182,7 +182,8 @@
ixp4xx|pxa) arch=5
tsc_type=__XN_TSC_TYPE_FREERUNNING;;
- s3c2410) arch=4;;
+ s3c2410) arch=4
+ tsc_type=__XN_TSC_TYPE_DECREMENTER;;
sa1100) arch=4
CONFIG_XENO_ARM_SA1100=y
Index: ChangeLog
===
--- ChangeLog (Revision 2768)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-07-19 Sebastian Smolorz <[EMAIL PROTECTED]>
+
+ * include/asm-arm/syscall.h: Add user-space access to
+ tsc emulation for decrementing counters.
+
2007-07-19 Jan Kiszka <[EMAIL PROTECTED]>
* ksrc/nucleus/timer.c (xntimer_tick_aperiodic): Keep processing
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RPI is good for you
On Fri, 2007-07-20 at 13:54 +0200, M. Koehrer wrote: > Hi Philippe, > I left my test running for a couple of hours - no freeze so far... > > However, I have to do some other stuff on this machine, I have to stop the > test now... > Ok, thanks for the feedback. I will send an extended patch later today, so that you could test it on a longer period when you see fit. TIA, > Regards > > Mathias > > > Hi Philippe, > > > > I have done my tests on 2.3.1 and I tried to apply the patch on 2.3.1 which > > worked > > (with some line offset in the patch...). > > I wait now for any result. > > So far everything is running fine. No issues. > > > > More later. > > > > Regards > > > > Mathias > > > > > > > > > > > > Mathias, > > > > > > Could you try applying the attached patch against v2.3.2, and run your > > > box using the failing configuration. This patch is a _preliminary_ > > > attempt at fixing two major issues, it is not complete, and may not even > > > be fully correct since it does not address all the pending issues yet. > > > Still, I would be interested to know whether I'm on the right path, and > > > if it changes something to your problem, without making your box jump > > > out of the window, that is. > > > > > > TIA, > > > > > > -- > > > Philippe. > > > > > > > > > > -- > > Mathias Koehrer > > [EMAIL PROTECTED] > > > > > > Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren > > ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig > > und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, > > nur 39,85 € inkl. DSL- und ISDN-Grundgebühr! > > http://www.arcor.de/rd/emf-dsl-2 > > > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RPI is good for you
Hi Philippe, I left my test running for a couple of hours - no freeze so far... However, I have to do some other stuff on this machine, I have to stop the test now... Regards Mathias > Hi Philippe, > > I have done my tests on 2.3.1 and I tried to apply the patch on 2.3.1 which > worked > (with some line offset in the patch...). > I wait now for any result. > So far everything is running fine. No issues. > > More later. > > Regards > > Mathias > > > > > > > Mathias, > > > > Could you try applying the attached patch against v2.3.2, and run your > > box using the failing configuration. This patch is a _preliminary_ > > attempt at fixing two major issues, it is not complete, and may not even > > be fully correct since it does not address all the pending issues yet. > > Still, I would be interested to know whether I'm on the right path, and > > if it changes something to your problem, without making your box jump > > out of the window, that is. > > > > TIA, > > > > -- > > Philippe. > > > > > > -- > Mathias Koehrer > [EMAIL PROTECTED] > > > Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren > ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig > und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, > nur 39,85 inkl. DSL- und ISDN-Grundgebühr! > http://www.arcor.de/rd/emf-dsl-2 > -- Mathias Koehrer [EMAIL PROTECTED] Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 39,85 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RPI is good for you
Hi Philippe, I have done my tests on 2.3.1 and I tried to apply the patch on 2.3.1 which worked (with some line offset in the patch...). I wait now for any result. So far everything is running fine. No issues. More later. Regards Mathias > > Mathias, > > Could you try applying the attached patch against v2.3.2, and run your > box using the failing configuration. This patch is a _preliminary_ > attempt at fixing two major issues, it is not complete, and may not even > be fully correct since it does not address all the pending issues yet. > Still, I would be interested to know whether I'm on the right path, and > if it changes something to your problem, without making your box jump > out of the window, that is. > > TIA, > > -- > Philippe. > > -- Mathias Koehrer [EMAIL PROTECTED] Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 39,85 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
