Re: [Xenomai-core] Re: [shirq] first test results
On 13/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: On 11/02/06, Jan Kiszka [EMAIL PROTECTED] wrote: Dmitry Adamushko wrote: And as an additional option, it could be interesting to print out to the log if not all counter values then min,max,average (the same like for the latency :) per second or per 1000 interrupts; so to see whether tweaking the MAX_EDGEIRQ_COUNTER may make the things better. Yes, maybe it's too small. But this also depends on the absolute time required for so many loops, something we should see in the traces then. I'm afraid that we will finally have to move the UART's read-from-fifo to task context to reduce the time spent in IRQ context. Good. Keep me informed as before.We got it working. :) Great! Anyway, this works now. But we also found a bug, as usual, a clean-upbug: You released the IRQ line based on the wrong test, see attached patch. Ah... it worked for my test cases since it depended on the order of xnintr_detach() calls. Thanks. With this fix applied and the IRQ flags as well as the/proc/xenomai/irq output cleaned up, I would say you great work is ready for merge! So I'll create the final patch and submit it to Philippe for merging. One more thing is making all this stuff optional; XENO_OPT_SHIRQ and XENO_OPT_SHIRQ_EDGE or something like this. Thanks,Jan-- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] separate queue debugging switch
Jan Kiszka wrote:
Hi,
while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).
This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.
And this revision also takes care of 2.4.
Jan
Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
+config XENO_OPT_DEBUG_QUEUES
+ bool Queue Debugging support
+ depends on XENO_OPT_DEBUG
+ help
+
+ This option activates debugging checks for all queueing
+ operations of the Xenomai core. It adds even more runtime
+ overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: ksrc/nucleus/Config.in
===
--- ksrc/nucleus/Config.in (revision 564)
+++ ksrc/nucleus/Config.in (working copy)
@@ -18,6 +18,9 @@
bool 'Interrupt shield support' CONFIG_XENO_OPT_ISHIELD
bool 'Statistics collection' CONFIG_XENO_OPT_STATS
bool 'Debug support' CONFIG_XENO_OPT_DEBUG
+ if [ $CONFIG_XENO_OPT_DEBUG = y ]; then
+ bool 'Queue Debugging support' CONFIG_XENO_OPT_DEBUG_QUEUES
+ fi
bool 'Watchdog support' CONFIG_XENO_OPT_WATCHDOG
bool 'Enable periodic timer support' CONFIG_XENO_OPT_TIMING_PERIODIC
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
xnholder_t head;
int elems;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_t lock;
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
} xnqueue_t;
-#if defined(CONFIG_XENO_OPT_DEBUG) defined(CONFIG_SMP)
+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES) defined(CONFIG_SMP)
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0,
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP) */
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
static inline void initq (xnqueue_t *qslot) {
inith(qslot-head);
qslot-elems = 0;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_init(qslot-lock);
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
}
-#ifdef CONFIG_XENO_OPT_DEBUG
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
#if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
@@ -172,7 +172,7 @@
dth(__holder); \
--(__qslot)-elems; })
-#else /* !CONFIG_XENO_OPT_DEBUG */
+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline int insertq (xnqueue_t *qslot,
xnholder_t *head,
@@ -206,7 +206,7 @@
return --qslot-elems;
}
-#endif /* CONFIG_XENO_OPT_DEBUG */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline xnholder_t *getheadq (xnqueue_t *qslot)
{
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] native registry dependencies
Hi, I'm sure now that the native registry is mandatory as soon as CONFIG_XENO_OPT_PERVASIVE is selected. This patch enforces the selection in such a scenario. Jan Index: ksrc/skins/native/Kconfig === --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -9,7 +9,8 @@ if XENO_SKIN_NATIVE != n config XENO_OPT_NATIVE_REGISTRY - bool Registry support + bool + prompt Registry support if !XENO_OPT_PERVASIVE default y help Index: ksrc/skins/native/Config.in === --- ksrc/skins/native/Config.in (revision 564) +++ ksrc/skins/native/Config.in (working copy) @@ -7,8 +7,14 @@ if [ $CONFIG_XENO_SKIN_NATIVE != n ]; then mainmenu_option next_comment comment 'Native interface options' - bool 'Registry support' CONFIG_XENO_OPT_NATIVE_REGISTRY - int 'Number of registry slots' CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS 512 + if [ $CONFIG_XENO_OPT_PERVASIVE != n ]; then + define_bool CONFIG_XENO_OPT_NATIVE_REGISTRY y + else + bool 'Registry support' CONFIG_XENO_OPT_NATIVE_REGISTRY + fi + if [ $CONFIG_XENO_OPT_NATIVE_REGISTRY != n ]; then + int 'Number of registry slots' CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS 512 + fi dep_bool 'Message pipes' CONFIG_XENO_OPT_NATIVE_PIPE $CONFIG_XENO_OPT_PIPE if [ $CONFIG_XENO_OPT_NATIVE_PIPE != n ]; then int 'Bytes in buffer space' CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ 4096 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] fix warnings on !XENO_OPT_NATIVE_REGISTRY
Hi,
this patch addresses the compiler warnings when
CONFIG_XENO_OPT_NATIVE_REGISTRY is switched off.
Jan
Index: ksrc/skins/native/mutex.c
===
--- ksrc/skins/native/mutex.c (revision 564)
+++ ksrc/skins/native/mutex.c (working copy)
@@ -106,7 +106,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __mutex_pnode = {
Index: ksrc/skins/native/heap.c
===
--- ksrc/skins/native/heap.c(revision 564)
+++ ksrc/skins/native/heap.c(working copy)
@@ -106,7 +106,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __heap_pnode = {
Index: ksrc/skins/native/event.c
===
--- ksrc/skins/native/event.c (revision 564)
+++ ksrc/skins/native/event.c (working copy)
@@ -99,7 +99,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __event_pnode = {
Index: ksrc/skins/native/cond.c
===
--- ksrc/skins/native/cond.c(revision 564)
+++ ksrc/skins/native/cond.c(working copy)
@@ -97,7 +97,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __cond_pnode = {
Index: ksrc/skins/native/sem.c
===
--- ksrc/skins/native/sem.c (revision 564)
+++ ksrc/skins/native/sem.c (working copy)
@@ -100,7 +100,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __sem_pnode = {
Index: ksrc/skins/native/queue.c
===
--- ksrc/skins/native/queue.c (revision 564)
+++ ksrc/skins/native/queue.c (working copy)
@@ -103,7 +103,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __queue_pnode = {
Index: ksrc/skins/native/alarm.c
===
--- ksrc/skins/native/alarm.c (revision 564)
+++ ksrc/skins/native/alarm.c (working copy)
@@ -94,7 +94,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __alarm_pnode = {
Index: ksrc/skins/native/pipe.c
===
--- ksrc/skins/native/pipe.c(revision 564)
+++ ksrc/skins/native/pipe.c(working copy)
@@ -71,7 +71,7 @@
.link_proc = __pipe_link_proc,
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __pipe_pnode = {
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [BUG] deleting a T_SUSP'ed native task
Jan Kiszka wrote: Hi Gilles, were you able to successfully run my T_SUSP test-case after the latest changes? For me this code still causes fatal exceptions: This is solved with revision 565, hopefully. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Handling PCI MSI interrupts
I'm having problems using MSI interrupts in Xenomai. When using normal PCI interrupts, my PCI card + RTDM driver work flawlessly. However, I noticed the following while trying to enable MSI (by having Linux do all the administrative register-fill-ins using pci_enable_msi()): 1. The kernel is compiled for MSI. (PCI_CONFIG_MSI=yes) 2. My card correctly advertises the MSI capability (checked with 'lspci -v'). 3. I do get a new IRQ number in the pci_dev struct (217 instead of 193) after invoking pci_enable_msi(). 4. After pci_enable_smi(), 'lspci -v' correctly indicates that Message Signalled Interrupts are now enabled (Enable+). 5. I can register the new IRQ with rtdm_request_irq(). Return value is 0. 6. The IRQ number appears in /proc/xenomai/irq. 7. I can enable the new IRQ with rtdm_irq_enable(). Return value is 0. 8. I can disable the new IRQ with rtdm_irq_disable(). Return value is 0. 9. I can unregister the new IRQ with rtdm_irq_free(). Return value is 0. 10. I'm able to do pci_disable_pci() successfully. If I actually enable the card interrupt, it goes wrong after 7 after arrival of the first interrupt. The ISR is executed (checked that), which checks if the card was actually interrupting and, if so, returns with RTDM_IRQ_ENABLE. After that, the machine is absolutely dead (frozen). Any hints, suggestions or things I may check ? Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] fix warnings on !XENO_OPT_NATIVE_REGISTRY
Jan Kiszka wrote: Hi, this patch addresses the compiler warnings when CONFIG_XENO_OPT_NATIVE_REGISTRY is switched off. Applied, thanks. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kconfig inconsistencies
Jan Kiszka wrote: Hi, here are some build screw-ups one can create by switching off the wrong options: o CONFIG_XENO_OPT_NATIVE_REGISTRY (but CONFIG_XENO_OPT_PERVASIVE remains on): unresolved symbols rt_registry_bind and rt_registry_fetch, several warnings due to #[el]if CONFIG_XENO_... instead of #[el]if defined(CONFIG_XENO_...) o CONFIG_XENO_OPT_PERVASIVE: xnheap_init_mapped and xnheap_destroy_mapped become unresolved Ok, will fix. The first issue reminds me of my unanswered question if (CONFIG_XENO_OPT_PERVASIVE CONFIG_XENO_SKIN_NATIVE !CONFIG_XENO_OPT_NATIVE_REGISTRY) makes any sense at all (kernel objects created from user space are looked up via the registry, right?). Right, it doesn't make sense. I haven't worked out any patch for those issues. Actually, I only wanted to put this patch forward when stumbling over the other: --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -127,7 +127,6 @@ config XENO_OPT_NATIVE_INTR bool Interrupts - default y help This option provides a simple API to deal with interrupts, Rationale: the /default/ way of handling IRQs should be via RTDM-based drivers. Only users who know what they are doing should leave this path and will have to switch on this feature explicitly. If this view can be commonly accepted, I will add some lines to the feature's help text as well. Agreed. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kconfig inconsistencies
Philippe Gerum wrote: Jan Kiszka wrote: I haven't worked out any patch for those issues. Actually, I only wanted to put this patch forward when stumbling over the other: --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -127,7 +127,6 @@ config XENO_OPT_NATIVE_INTR bool Interrupts -default y help This option provides a simple API to deal with interrupts, Rationale: the /default/ way of handling IRQs should be via RTDM-based drivers. Only users who know what they are doing should leave this path and will have to switch on this feature explicitly. If this view can be commonly accepted, I will add some lines to the feature's help text as well. Agreed. Then apply this one, please. I noticed that 2.4 does not know default values for bool options, correct? Jan Index: ksrc/skins/native/Kconfig === --- ksrc/skins/native/Kconfig (revision 568) +++ ksrc/skins/native/Kconfig (working copy) @@ -128,11 +128,11 @@ config XENO_OPT_NATIVE_INTR bool Interrupts - default y help This option provides a simple API to deal with interrupts, - both in kernel and user-space contexts. Registry support is - required. + both in kernel and user-space contexts. Note that the preferred + way of implementing generic drivers usable across all Xenomai + interfaces is defined by the Real-Time Driver Model (RTDM). endif 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] separate queue debugging switch
Jan Kiszka wrote:
Hi,
while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).
This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.
Maybe it's time to introduce debug levels, so that we could reuse them in order
to
add more (selectable) debug instrumentation; queue debugging could then be
given a
certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for this
one...), instead of going for a specific conditional each time we introduce new
checks?
Jan
Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
+config XENO_OPT_DEBUG_QUEUES
+ bool Queue Debugging support
+ depends on XENO_OPT_DEBUG
+ help
+
+ This option activates debugging checks for all queueing
+ operations of the Xenomai core. It adds even more runtime
+ overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
xnholder_t head;
int elems;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_t lock;
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
} xnqueue_t;
-#if defined(CONFIG_XENO_OPT_DEBUG) defined(CONFIG_SMP)
+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES) defined(CONFIG_SMP)
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0,
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP) */
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
static inline void initq (xnqueue_t *qslot) {
inith(qslot-head);
qslot-elems = 0;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_init(qslot-lock);
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
}
-#ifdef CONFIG_XENO_OPT_DEBUG
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
#if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
@@ -172,7 +172,7 @@
dth(__holder); \
--(__qslot)-elems; })
-#else /* !CONFIG_XENO_OPT_DEBUG */
+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline int insertq (xnqueue_t *qslot,
xnholder_t *head,
@@ -206,7 +206,7 @@
return --qslot-elems;
}
-#endif /* CONFIG_XENO_OPT_DEBUG */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline xnholder_t *getheadq (xnqueue_t *qslot)
{
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handling PCI MSI interrupts
Jeroen Van den Keybus wrote: I'm having problems using MSI interrupts in Xenomai. When using normal PCI interrupts, my PCI card + RTDM driver work flawlessly. However, I noticed the following while trying to enable MSI (by having Linux do all the administrative register-fill-ins using pci_enable_msi()): 1. The kernel is compiled for MSI. (PCI_CONFIG_MSI=yes) 2. My card correctly advertises the MSI capability (checked with 'lspci -v'). 3. I do get a new IRQ number in the pci_dev struct (217 instead of 193) after invoking pci_enable_msi(). 4. After pci_enable_smi(), 'lspci -v' correctly indicates that Message Signalled Interrupts are now enabled (Enable+). 5. I can register the new IRQ with rtdm_request_irq(). Return value is 0. 6. The IRQ number appears in /proc/xenomai/irq. 7. I can enable the new IRQ with rtdm_irq_enable(). Return value is 0. 8. I can disable the new IRQ with rtdm_irq_disable(). Return value is 0. 9. I can unregister the new IRQ with rtdm_irq_free(). Return value is 0. 10. I'm able to do pci_disable_pci() successfully. If I actually enable the card interrupt, it goes wrong after 7 after arrival of the first interrupt. The ISR is executed (checked that), which checks if the card was actually interrupting and, if so, returns with RTDM_IRQ_ENABLE. After that, the machine is absolutely dead (frozen). Any hints, suggestions or things I may check ? Does calling rthal_disable_irq() instead of returning RTDM_IRQ_ENABLE, but rather 0, prevents the freeze? Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] separate queue debugging switch
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, while XENO_OPT_DEBUG is generally a useful switch for tracing potential issues in the core and the skins, it also introduces high latencies via the queue debugging feature (due to checks iterating over whole queues). This patch introduces separate control over queue debugging so that you can have debug checks without too dramatic slowdowns. Maybe it's time to introduce debug levels, so that we could reuse them in order to add more (selectable) debug instrumentation; queue debugging could then be given a certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for this one...), instead of going for a specific conditional each time we introduce new checks? Hmm, this means someone have to define what should be printed at which level - tend to be hard decisions... Often it is at least as much useful to have debug groups so that specific parts can be excluded from debugging. I'm pro such groups (one would be those queues e.g.) but contra too many levels (2, at most 3). Ack, selection by increasingly verbose/high-overhead groups is what I have in mind. At this chance, I would also suggest to introduce some ASSERT macro (per group, per level). That could be used to instrument the core with runtime checks. But it could also be quickly removed at compilation time, reducing the code size (e.g. checks at the nucleus layer against buggy skins or at RTDM layer against rough drivers). I'm not opposed to that, if we keep the noise / signal ratio of those assertions at the reasonable low-level throughout the code, and don't use this to enforce silly parametrical checks. Jan -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Em Terça 14 Fevereiro 2006 05:55, você escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Ok, but even if you decide to let rt-mmap be non-deterministic, you still need some means to prevent the scenario you described above. Actually, all you need is some callback when the mapped memory block was actually released (munmap/application exit). Such a callback can be registered inside the rtdm_mmap handler as a vma_fileop. I have never worked with vma_fileop... I would need to learn it first. Here is the patch to offer you access to those ops. Revert the previous version, then apply this one. Actually I would have to revert the modifications I had to do for the patch to apply (some rejected chunks). But I think I'll update to the last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 xenomai? Or it would apply for all of them? Developed and tested against 2.1. The current patch will not cleanly apply against 2.0. Ok, it already applied cleanly on last svn version. I'll reboot my computer and test it. That is something I didn't like in 2.1 series... I always have to recompile the kernel and to reboot when a new xenomai release is available (unless I'm missing something)... On the previous series I just compiled it as modules and it was only necessary to recompile the kernel when a new adeos (ipipe) version was available... It still needs some final documentation notes and a test on kernel 2.4. But is should already work on 2.6. I forgot to mention, I have one more problem. Since I call mmap on driver initialization (thus before any rtdm_dev_open), I do not have any rtdm_user_info_t, so I need to use current instead, but I'm not sure if this will work. Maybe mmap needs the 'current' struct of the user program... I don't know this very well... If that is true, so I'll have to do the maps in a non-rt context anyway... You cannot mmap before you know precisely for which user this should take place. Do you mean that if I use the 'current' and current-mm struct of the driver, when mmaping, the user won't be able to use the returned pointer? During init, it's the insmod/modprobe process - likely not the one you are interested in. Actually, that is the way I was planning for making the maping in a deterministic way... So the earliest point for mmap is device open. If this is too late for you, then now finally forget about this pre-mmapping and turn it into a normal function for secondary mode. It will be hard anyway to find a user who will notice the difference. That is not a question of noting any difference or not... An application can works great most of the time but it can fail under some not common circunstances. The user will need to know, at least, that he will can not rely on rt-capabilities when doing that and will be forced to do that only on initialization. But that is ok for most cases. I think I'll do that (I do not have other options at all :) ). Thanks, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Rodrigo Rosenfeld Rosas wrote: Em Terça 14 Fevereiro 2006 05:55, você escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Ok, but even if you decide to let rt-mmap be non-deterministic, you still need some means to prevent the scenario you described above. Actually, all you need is some callback when the mapped memory block was actually released (munmap/application exit). Such a callback can be registered inside the rtdm_mmap handler as a vma_fileop. I have never worked with vma_fileop... I would need to learn it first. Here is the patch to offer you access to those ops. Revert the previous version, then apply this one. Actually I would have to revert the modifications I had to do for the patch to apply (some rejected chunks). But I think I'll update to the last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 xenomai? Or it would apply for all of them? Developed and tested against 2.1. The current patch will not cleanly apply against 2.0. Ok, it already applied cleanly on last svn version. I'll reboot my computer and test it. That is something I didn't like in 2.1 series... I always have to recompile the kernel and to reboot when a new xenomai release is available (unless I'm missing something)... On the previous series I just compiled it as modules and it was only necessary to recompile the kernel when a new adeos (ipipe) version was available... What about building the Xenomai support as modules instead of statically into the kernel? It still needs some final documentation notes and a test on kernel 2.4. But is should already work on 2.6. I forgot to mention, I have one more problem. Since I call mmap on driver initialization (thus before any rtdm_dev_open), I do not have any rtdm_user_info_t, so I need to use current instead, but I'm not sure if this will work. Maybe mmap needs the 'current' struct of the user program... I don't know this very well... If that is true, so I'll have to do the maps in a non-rt context anyway... You cannot mmap before you know precisely for which user this should take place. Do you mean that if I use the 'current' and current-mm struct of the driver, when mmaping, the user won't be able to use the returned pointer? During init, it's the insmod/modprobe process - likely not the one you are interested in. Actually, that is the way I was planning for making the maping in a deterministic way... So the earliest point for mmap is device open. If this is too late for you, then now finally forget about this pre-mmapping and turn it into a normal function for secondary mode. It will be hard anyway to find a user who will notice the difference. That is not a question of noting any difference or not... An application can works great most of the time but it can fail under some not common circunstances. The user will need to know, at least, that he will can not rely on rt-capabilities when doing that and will be forced to do that only on initialization. But that is ok for most cases. I think I'll do that (I do not have other options at all :) ). Thanks, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handling PCI MSI interrupts
2. Keep my program alive for a few secs using task_sleep() or so to see if cleanup code is going awry. Alas, hangs directly after going to sleep(). Strangely, console output always arrives to the screen unhurt... Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handling PCI MSI interrupts
I've got some bad news. I've rewritten (parts of) my driver to operate in native Linux (i.e. no RTDM, no Xenomai). When I run this in a Xenomai-augmented kernel (with Adeos, evidently), the machine hangs. However, when the same code is run in the same but unmodified kernel, the code works as expected. Therefore it seems that Adeos is to blame here. Now, I could try to write a small driver program illustrating the problem. Of course, it is impossible for you to test on my board. Maybe we could agree on an MSI capable piece of hardware, that I could write the code for ? The reason I would very much like to test this setup is that I look upon MSI as a very viable alternative to these ever-damned interrupt sharing mechanisms. It is becoming more and more difficult to find computers that allow you to reserve (a few) IRQ-lines these days (especially notebooks and OEM desktops). Additionally, MSI is capable of bypassing the IO-APIC entirely (although the Linux kernel needs that APIC support to enable MSI - I've still got to find out why that is). Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Ok, but even if you decide to let rt-mmap be non-deterministic, you still need some means to prevent the scenario you described above. Actually, all you need is some callback when the mapped memory block was actually released (munmap/application exit). Such a callback can be registered inside the rtdm_mmap handler as a vma_fileop. I have never worked with vma_fileop... I would need to learn it first. Here is the patch to offer you access to those ops. Revert the previous version, then apply this one. Actually I would have to revert the modifications I had to do for the patch to apply (some rejected chunks). But I think I'll update to the last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 xenomai? Or it would apply for all of them? Developed and tested against 2.1. The current patch will not cleanly apply against 2.0. It still needs some final documentation notes and a test on kernel 2.4. But is should already work on 2.6. I forgot to mention, I have one more problem. Since I call mmap on driver initialization (thus before any rtdm_dev_open), I do not have any rtdm_user_info_t, so I need to use current instead, but I'm not sure if this will work. Maybe mmap needs the 'current' struct of the user program... I don't know this very well... If that is true, so I'll have to do the maps in a non-rt context anyway... You cannot mmap before you know precisely for which user this should take place. During init, it's the insmod/modprobe process - likely not the one you are interested in. So the earliest point for mmap is device open. If this is too late for you, then now finally forget about this pre-mmapping and turn it into a normal function for secondary mode. It will be hard anyway to find a user who will notice the difference. I also attached a demo for the handler usage based on my previous test framework. Just grab the pattern and put some useful code in the close handler... It will run in non-RT, and could be used to mark the related hardware buffer as finally free for re-allocation. Now, I did realize that there is one more problem on my current design. If the user application exits or is terminated, I'm not sure if the close handler is called if the user forgot/was not able to. If it is not, the buffer would be marked as used until I reloaded the driver... Is the close handler invocated on application termination? Yep, this is a general issue you cannot avoid: all skin objects besides task are only released when the user-space application cleans it up as it's ought to. There is no tracking of used resources, no auto-cleanup. If your application fails to close a device or socket, you will get a stalled handle which can be found in /proc/xenomai/rtdm/open_files. Writing the file descriptor number to this particular proc-file (e.g. echo 3 /proc/xeno...) will trigger an enforced close and will release the file descriptor again. Useful when debugging such broken applications. Yes, sorry... I forgot I've already read this... :) Rodrigo. Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] [PATCH] separate queue debugging switch
Hi,
while XENO_OPT_DEBUG is generally a useful switch for tracing potential
issues in the core and the skins, it also introduces high latencies via
the queue debugging feature (due to checks iterating over whole queues).
This patch introduces separate control over queue debugging so that you
can have debug checks without too dramatic slowdowns.
Jan
Index: ksrc/nucleus/Kconfig
===
--- ksrc/nucleus/Kconfig(revision 564)
+++ ksrc/nucleus/Kconfig(working copy)
@@ -87,6 +87,15 @@
Do not switch this option on unless you really know what you
are doing.
+config XENO_OPT_DEBUG_QUEUES
+ bool Queue Debugging support
+ depends on XENO_OPT_DEBUG
+ help
+
+ This option activates debugging checks for all queueing
+ operations of the Xenomai core. It adds even more runtime
+ overhead then CONFIG_XENO_OPT_DEBUG, use with care.
+
config XENO_OPT_WATCHDOG
bool Watchdog support
default n
Index: include/nucleus/queue.h
===
--- include/nucleus/queue.h (revision 564)
+++ include/nucleus/queue.h (working copy)
@@ -57,27 +57,27 @@
xnholder_t head;
int elems;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_t lock;
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
} xnqueue_t;
-#if defined(CONFIG_XENO_OPT_DEBUG) defined(CONFIG_SMP)
+#if defined(CONFIG_XENO_OPT_DEBUG_QUEUES) defined(CONFIG_SMP)
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0,
XNARCH_LOCK_UNLOCKED }
-#else /* !(CONFIG_XENO_OPT_DEBUG CONFIG_SMP) */
+#else /* !(CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP) */
#define DECLARE_XNQUEUE(q) xnqueue_t q = { { (q).head, (q).head }, 0 }
-#endif /* CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
static inline void initq (xnqueue_t *qslot) {
inith(qslot-head);
qslot-elems = 0;
-#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG)
defined(CONFIG_SMP)
+#if defined(__KERNEL__) defined(CONFIG_XENO_OPT_DEBUG_QUEUES)
defined(CONFIG_SMP)
xnlock_init(qslot-lock);
-#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG CONFIG_SMP */
+#endif /* __KERNEL__ CONFIG_XENO_OPT_DEBUG_QUEUES CONFIG_SMP */
}
-#ifdef CONFIG_XENO_OPT_DEBUG
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
#if defined(__KERNEL__) || defined(__XENO_UVM__) || defined(__XENO_SIM__)
@@ -172,7 +172,7 @@
dth(__holder); \
--(__qslot)-elems; })
-#else /* !CONFIG_XENO_OPT_DEBUG */
+#else /* !CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline int insertq (xnqueue_t *qslot,
xnholder_t *head,
@@ -206,7 +206,7 @@
return --qslot-elems;
}
-#endif /* CONFIG_XENO_OPT_DEBUG */
+#endif /* CONFIG_XENO_OPT_DEBUG_QUEUES */
static inline xnholder_t *getheadq (xnqueue_t *qslot)
{
signature.asc
Description: OpenPGP digital signature
[Xenomai-core] [PATCH] native registry dependencies
Hi, I'm sure now that the native registry is mandatory as soon as CONFIG_XENO_OPT_PERVASIVE is selected. This patch enforces the selection in such a scenario. Jan Index: ksrc/skins/native/Kconfig === --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -9,7 +9,8 @@ if XENO_SKIN_NATIVE != n config XENO_OPT_NATIVE_REGISTRY - bool Registry support + bool + prompt Registry support if !XENO_OPT_PERVASIVE default y help Index: ksrc/skins/native/Config.in === --- ksrc/skins/native/Config.in (revision 564) +++ ksrc/skins/native/Config.in (working copy) @@ -7,8 +7,14 @@ if [ $CONFIG_XENO_SKIN_NATIVE != n ]; then mainmenu_option next_comment comment 'Native interface options' - bool 'Registry support' CONFIG_XENO_OPT_NATIVE_REGISTRY - int 'Number of registry slots' CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS 512 + if [ $CONFIG_XENO_OPT_PERVASIVE != n ]; then + define_bool CONFIG_XENO_OPT_NATIVE_REGISTRY y + else + bool 'Registry support' CONFIG_XENO_OPT_NATIVE_REGISTRY + fi + if [ $CONFIG_XENO_OPT_NATIVE_REGISTRY != n ]; then + int 'Number of registry slots' CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS 512 + fi dep_bool 'Message pipes' CONFIG_XENO_OPT_NATIVE_PIPE $CONFIG_XENO_OPT_PIPE if [ $CONFIG_XENO_OPT_NATIVE_PIPE != n ]; then int 'Bytes in buffer space' CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ 4096 signature.asc Description: OpenPGP digital signature
[Xenomai-core] [PATCH] fix warnings on !XENO_OPT_NATIVE_REGISTRY
Hi,
this patch addresses the compiler warnings when
CONFIG_XENO_OPT_NATIVE_REGISTRY is switched off.
Jan
Index: ksrc/skins/native/mutex.c
===
--- ksrc/skins/native/mutex.c (revision 564)
+++ ksrc/skins/native/mutex.c (working copy)
@@ -106,7 +106,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __mutex_pnode = {
Index: ksrc/skins/native/heap.c
===
--- ksrc/skins/native/heap.c(revision 564)
+++ ksrc/skins/native/heap.c(working copy)
@@ -106,7 +106,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __heap_pnode = {
Index: ksrc/skins/native/event.c
===
--- ksrc/skins/native/event.c (revision 564)
+++ ksrc/skins/native/event.c (working copy)
@@ -99,7 +99,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __event_pnode = {
Index: ksrc/skins/native/cond.c
===
--- ksrc/skins/native/cond.c(revision 564)
+++ ksrc/skins/native/cond.c(working copy)
@@ -97,7 +97,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __cond_pnode = {
Index: ksrc/skins/native/sem.c
===
--- ksrc/skins/native/sem.c (revision 564)
+++ ksrc/skins/native/sem.c (working copy)
@@ -100,7 +100,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __sem_pnode = {
Index: ksrc/skins/native/queue.c
===
--- ksrc/skins/native/queue.c (revision 564)
+++ ksrc/skins/native/queue.c (working copy)
@@ -103,7 +103,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __queue_pnode = {
Index: ksrc/skins/native/alarm.c
===
--- ksrc/skins/native/alarm.c (revision 564)
+++ ksrc/skins/native/alarm.c (working copy)
@@ -94,7 +94,7 @@
.write_proc = NULL
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __alarm_pnode = {
Index: ksrc/skins/native/pipe.c
===
--- ksrc/skins/native/pipe.c(revision 564)
+++ ksrc/skins/native/pipe.c(working copy)
@@ -71,7 +71,7 @@
.link_proc = __pipe_link_proc,
};
-#elif CONFIG_XENO_OPT_NATIVE_REGISTRY
+#elif defined(CONFIG_XENO_OPT_NATIVE_REGISTRY)
static RT_OBJECT_PROCNODE __pipe_pnode = {
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] [PATCH] fix warnings on !XENO_OPT_NATIVE_REGISTRY
Jan Kiszka wrote: Hi, this patch addresses the compiler warnings when CONFIG_XENO_OPT_NATIVE_REGISTRY is switched off. Applied, thanks. -- Gilles Chanteperdrix.
Re: [Xenomai-core] Kconfig inconsistencies
Jan Kiszka wrote: Hi, here are some build screw-ups one can create by switching off the wrong options: o CONFIG_XENO_OPT_NATIVE_REGISTRY (but CONFIG_XENO_OPT_PERVASIVE remains on): unresolved symbols rt_registry_bind and rt_registry_fetch, several warnings due to #[el]if CONFIG_XENO_... instead of #[el]if defined(CONFIG_XENO_...) o CONFIG_XENO_OPT_PERVASIVE: xnheap_init_mapped and xnheap_destroy_mapped become unresolved Ok, will fix. The first issue reminds me of my unanswered question if (CONFIG_XENO_OPT_PERVASIVE CONFIG_XENO_SKIN_NATIVE !CONFIG_XENO_OPT_NATIVE_REGISTRY) makes any sense at all (kernel objects created from user space are looked up via the registry, right?). Right, it doesn't make sense. I haven't worked out any patch for those issues. Actually, I only wanted to put this patch forward when stumbling over the other: --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -127,7 +127,6 @@ config XENO_OPT_NATIVE_INTR bool Interrupts - default y help This option provides a simple API to deal with interrupts, Rationale: the /default/ way of handling IRQs should be via RTDM-based drivers. Only users who know what they are doing should leave this path and will have to switch on this feature explicitly. If this view can be commonly accepted, I will add some lines to the feature's help text as well. Agreed. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] Kconfig inconsistencies
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: I haven't worked out any patch for those issues. Actually, I only wanted to put this patch forward when stumbling over the other: --- ksrc/skins/native/Kconfig (revision 564) +++ ksrc/skins/native/Kconfig (working copy) @@ -127,7 +127,6 @@ config XENO_OPT_NATIVE_INTR bool Interrupts -default y help This option provides a simple API to deal with interrupts, Rationale: the /default/ way of handling IRQs should be via RTDM-based drivers. Only users who know what they are doing should leave this path and will have to switch on this feature explicitly. If this view can be commonly accepted, I will add some lines to the feature's help text as well. Agreed. Then apply this one, please. I noticed that 2.4 does not know default values for bool options, correct? Correct. Jan Index: ksrc/skins/native/Kconfig === --- ksrc/skins/native/Kconfig (revision 568) +++ ksrc/skins/native/Kconfig (working copy) @@ -128,11 +128,11 @@ config XENO_OPT_NATIVE_INTR bool Interrupts - default y help This option provides a simple API to deal with interrupts, - both in kernel and user-space contexts. Registry support is - required. + both in kernel and user-space contexts. Note that the preferred + way of implementing generic drivers usable across all Xenomai + interfaces is defined by the Real-Time Driver Model (RTDM). endif -- Philippe.
Re: [Xenomai-core] [PATCH] separate queue debugging switch
Philippe Gerum wrote: Jan Kiszka wrote: Hi, while XENO_OPT_DEBUG is generally a useful switch for tracing potential issues in the core and the skins, it also introduces high latencies via the queue debugging feature (due to checks iterating over whole queues). This patch introduces separate control over queue debugging so that you can have debug checks without too dramatic slowdowns. Maybe it's time to introduce debug levels, so that we could reuse them in order to add more (selectable) debug instrumentation; queue debugging could then be given a certain level (likely something like CONFIG_XENO_DEBUG_LEVEL=8712 for this one...), instead of going for a specific conditional each time we introduce new checks? Hmm, this means someone have to define what should be printed at which level - tend to be hard decisions... Often it is at least as much useful to have debug groups so that specific parts can be excluded from debugging. I'm pro such groups (one would be those queues e.g.) but contra too many levels (2, at most 3). At this chance, I would also suggest to introduce some ASSERT macro (per group, per level). That could be used to instrument the core with runtime checks. But it could also be quickly removed at compilation time, reducing the code size (e.g. checks at the nucleus layer against buggy skins or at RTDM layer against rough drivers). Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Handling PCI MSI interrupts
Jeroen Van den Keybus wrote: One moment. I'm trying to locate rthal_disable_irq()... Does calling rthal_disable_irq() instead of returning RTDM_IRQ_ENABLE, but rather 0, prevents the freeze? Disable or enable (I guess the latter one)? In either case, there are equivalent wrappers in RTDM: rtdm_irq_enable/disable. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] Handling PCI MSI interrupts
Jeroen Van den Keybus wrote: One moment. I'm trying to locate rthal_disable_irq()... Does calling rthal_disable_irq() instead of returning RTDM_IRQ_ENABLE, but rather 0, prevents the freeze? rthal_irq_disable, sorry. -- Philippe.
Re: [Xenomai-core] Kconfig inconsistencies
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Jan Kiszka wrote: o CONFIG_XENO_OPT_PERVASIVE: xnheap_init_mapped and xnheap_destroy_mapped become unresolved Ok, will fix. This one was in the POSIX skin, and should already be fixed. Ok. Thanks. -- Philippe.
Re: [Xenomai-core] Handling PCI MSI interrupts
In the meantime, I've located the rthal_irq_disable() and used it instead of the RTDM return value (which is now 0). The machine still hangs. More importantly, I noticed that the second (after the first) interrupt gets lost (as is to be expected when the interrupt remains disabled). This causes the RTDM driver to timeout and the Xenomai program using the RTDM driver is actually able to gracefully shut down. It seems that, upon exiting, the machine hangs. I'll now try two new tests: 1. Turn off the cards's interrupts after the first IRQ has arrived. 2. Keep my program alive for a few secs using task_sleep() or so to see if cleanup code is going awry. Any other tests ? Jeroen.
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Em Terça 14 Fevereiro 2006 05:55, você escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Ok, but even if you decide to let rt-mmap be non-deterministic, you still need some means to prevent the scenario you described above. Actually, all you need is some callback when the mapped memory block was actually released (munmap/application exit). Such a callback can be registered inside the rtdm_mmap handler as a vma_fileop. I have never worked with vma_fileop... I would need to learn it first. Here is the patch to offer you access to those ops. Revert the previous version, then apply this one. Actually I would have to revert the modifications I had to do for the patch to apply (some rejected chunks). But I think I'll update to the last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 xenomai? Or it would apply for all of them? Developed and tested against 2.1. The current patch will not cleanly apply against 2.0. Ok, it already applied cleanly on last svn version. I'll reboot my computer and test it. That is something I didn't like in 2.1 series... I always have to recompile the kernel and to reboot when a new xenomai release is available (unless I'm missing something)... On the previous series I just compiled it as modules and it was only necessary to recompile the kernel when a new adeos (ipipe) version was available... It still needs some final documentation notes and a test on kernel 2.4. But is should already work on 2.6. I forgot to mention, I have one more problem. Since I call mmap on driver initialization (thus before any rtdm_dev_open), I do not have any rtdm_user_info_t, so I need to use current instead, but I'm not sure if this will work. Maybe mmap needs the 'current' struct of the user program... I don't know this very well... If that is true, so I'll have to do the maps in a non-rt context anyway... You cannot mmap before you know precisely for which user this should take place. Do you mean that if I use the 'current' and current-mm struct of the driver, when mmaping, the user won't be able to use the returned pointer? During init, it's the insmod/modprobe process - likely not the one you are interested in. Actually, that is the way I was planning for making the maping in a deterministic way... So the earliest point for mmap is device open. If this is too late for you, then now finally forget about this pre-mmapping and turn it into a normal function for secondary mode. It will be hard anyway to find a user who will notice the difference. That is not a question of noting any difference or not... An application can works great most of the time but it can fail under some not common circunstances. The user will need to know, at least, that he will can not rely on rt-capabilities when doing that and will be forced to do that only on initialization. But that is ok for most cases. I think I'll do that (I do not have other options at all :) ). Thanks, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com
Re: [Xenomai-core] [PATCH] provide rtdm_mmap_to_user / rtdm_munmap
Rodrigo Rosenfeld Rosas wrote: Em Terça 14 Fevereiro 2006 05:55, você escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Jan Kiszka escreveu: Ok, but even if you decide to let rt-mmap be non-deterministic, you still need some means to prevent the scenario you described above. Actually, all you need is some callback when the mapped memory block was actually released (munmap/application exit). Such a callback can be registered inside the rtdm_mmap handler as a vma_fileop. I have never worked with vma_fileop... I would need to learn it first. Here is the patch to offer you access to those ops. Revert the previous version, then apply this one. Actually I would have to revert the modifications I had to do for the patch to apply (some rejected chunks). But I think I'll update to the last SVN xenomai. BTW, is this patch for the SVN or 2.1 or 2.0.2 xenomai? Or it would apply for all of them? Developed and tested against 2.1. The current patch will not cleanly apply against 2.0. Ok, it already applied cleanly on last svn version. I'll reboot my computer and test it. That is something I didn't like in 2.1 series... I always have to recompile the kernel and to reboot when a new xenomai release is available (unless I'm missing something)... On the previous series I just compiled it as modules and it was only necessary to recompile the kernel when a new adeos (ipipe) version was available... What about building the Xenomai support as modules instead of statically into the kernel? It still needs some final documentation notes and a test on kernel 2.4. But is should already work on 2.6. I forgot to mention, I have one more problem. Since I call mmap on driver initialization (thus before any rtdm_dev_open), I do not have any rtdm_user_info_t, so I need to use current instead, but I'm not sure if this will work. Maybe mmap needs the 'current' struct of the user program... I don't know this very well... If that is true, so I'll have to do the maps in a non-rt context anyway... You cannot mmap before you know precisely for which user this should take place. Do you mean that if I use the 'current' and current-mm struct of the driver, when mmaping, the user won't be able to use the returned pointer? During init, it's the insmod/modprobe process - likely not the one you are interested in. Actually, that is the way I was planning for making the maping in a deterministic way... So the earliest point for mmap is device open. If this is too late for you, then now finally forget about this pre-mmapping and turn it into a normal function for secondary mode. It will be hard anyway to find a user who will notice the difference. That is not a question of noting any difference or not... An application can works great most of the time but it can fail under some not common circunstances. The user will need to know, at least, that he will can not rely on rt-capabilities when doing that and will be forced to do that only on initialization. But that is ok for most cases. I think I'll do that (I do not have other options at all :) ). Thanks, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] Handling PCI MSI interrupts
I've got some bad news. I've rewritten (parts of) my driver to operate in native Linux (i.e. no RTDM, no Xenomai). When I run this in a Xenomai-augmented kernel (with Adeos, evidently), the machine hangs. However, when the same code is run in the same but unmodified kernel, the code works as expected. Therefore it seems that Adeos is to blame here. Now, I could try to write a small driver program illustrating the problem. Of course, it is impossible for you to test on my board. Maybe we could agree on an MSI capable piece of hardware, that I could write the code for ? The reason I would very much like to test this setup is that I look upon MSI as a very viable alternative to these ever-damned interrupt sharing mechanisms. It is becoming more and more difficult to find computers that allow you to reserve (a few) IRQ-lines these days (especially notebooks and OEM desktops). Additionally, MSI is capable of bypassing the IO-APIC entirely (although the Linux kernel needs that APIC support to enable MSI - I've still got to find out why that is). Jeroen.
