Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Tue, Nov 03, 2009 at 03:44:24PM +0100, Philippe Gerum wrote: > On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote: > > If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, > > then the machine freezes as soon as Xenomai is started. (As a module, > > Xenomai locks the machine when loading). > > Did you try enabling the pipeline debug options, like > CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL? Yes, but it makes no difference, and I see no additional messages from the kernel on the console. BTW, I also disabled CONFIG_XENO_OPT_PERVASIVE, but it still locks up. Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL REQUEST] analogy: critical bugfixes for the NI PCIMIO driver
Hi, Here are some important fixes for the NI PCIMIO driver. I would like to thank Cristian Axenie for giving me access to his development environment. These bugs were particularly noticeable on his PPC board (any acquisition triggered a CPU reboot). Alexis. The following changes since commit 255cf6b2bf8dca9dad05a1c169dcecf6e742955e: Alexis Berlemont (1): analogy: force NI TIO / MIO selections when NI PCIMIO is set are available in the git repository at: ssh+git://git.xenomai.org/xenomai-abe.git analogy Alexis Berlemont (4): analogy: force NI MITE selection when NI PCIMIO is set analogy: fix a critical bug in the NI PCIMIO driver analogy: rename 8255 and NI PCIMIO driver analogy: fix a bug in NI PCIMIO driver ksrc/drivers/analogy/intel/8255.c |2 +- ksrc/drivers/analogy/national_instruments/Kconfig |1 + .../analogy/national_instruments/mio_common.c | 12 ksrc/drivers/analogy/national_instruments/pcimio.c |2 +- 4 files changed, 11 insertions(+), 6 deletions(-) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [pull request] rtdm: Add padding to rtser_config
The following changes since commit 6b1a185b460765c933b17932d77be6967d2e42dc:
Philippe Gerum (1):
nucleus: fix locking in shared heap deletion
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
Jan Kiszka (1):
rtdm: Add padding to rtser_config
include/rtdm/rtserial.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
rtdm: Add padding to rtser_config
The current layout of rtser_config is unfortunate as it may result in
different layout depending on the compiler alignment setting. Namely,
rx_timeout may be aligned on 8-byte boundaries in user land while it may
not be aligned in the kernel, or vice versa.
Avoid this ambiguity by adding a reserved padding field. Bump profile
revision number due to ABI breakage.
Signed-off-by: Jan Kiszka
---
include/rtdm/rtserial.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/rtdm/rtserial.h b/include/rtdm/rtserial.h
index 30bb564..48712b2 100644
--- a/include/rtdm/rtserial.h
+++ b/include/rtdm/rtserial.h
@@ -29,7 +29,7 @@
* Feel free to comment on this profile via the Xenomai mailing list
* (Xenomai-core@gna.org) or directly to the author (jan.kis...@web.de).
*
- * @b Profile @b Revision: 2
+ * @b Profile @b Revision: 3
* @n
* @n
* @par Device Characteristics
@@ -79,7 +79,7 @@
#include
-#define RTSER_PROFILE_VER 2
+#define RTSER_PROFILE_VER 3
/*!
* @anchor RTSER_DEF_BAUD @name RTSER_DEF_BAUD
@@ -263,6 +263,8 @@ typedef struct rtser_config {
/** reception FIFO interrupt threshold, see @ref RTSER_FIFO_xxx */
int fifo_depth;
+ int reserved;
+
/** reception timeout, see @ref RTSER_TIMEOUT_xxx for special
* values */
nanosecs_rel_t rx_timeout;
--
1.6.0.2
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] BUG: scheduling while atomic
cagnul...@tin.it wrote: > Hi, i've got a system running kernel 2.6.22 on a ARM9 / Freescale i.MX27 > The system running well, but every time i run latency it hangs. > It occurs with rtprint too. > Could you help me? See: https://mail.gna.org/public/xenomai-core/2009-08/msg00021.html And you can not run latency with a 100us period on ARM. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] BUG: scheduling while atomic
Hi, i've got a system running kernel 2.6.22 on a ARM9 / Freescale i.MX27 The system running well, but every time i run latency it hangs. It occurs with rtprint too. Could you help me? r...@mx27:~# latency == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds [ 133.84] BUG: scheduling while atomic: sampling-2175/0x0001/2177 [ 133.85] [] (dump_stack+0x0/0x14) from [] (schedule+0x 60/0x874) [ 133.86] [] (schedule+0x0/0x874) from [] (xnshadow_har den+0xd0/0x134) [ 133.86] [] (xnshadow_harden+0x0/0x134) from [] (xnsha dow_wait_barrier+0x100/0x118) [ 133.87] r6:c2e38000 r5:c2e39fb0 r4:c4801610 [ 133.88] [] (xnshadow_wait_barrier+0x0/0x118) from [] (xnshadow_sys_barrier+0x14/0x18) [ 133.89] r5:c2e39fb0 r4:0001 [ 133.89] [] (xnshadow_sys_barrier+0x0/0x18) from [] (l osyscall_event+0xcc/0x1dc) [ 133.90] [] (losyscall_event+0x0/0x1dc) from [] (__ipi pe_dispatch_event+0xd0/0x1c8) [ 133.91] [] (__ipipe_dispatch_event+0x0/0x1c8) from [] (__ipipe_syscall_root+0x80/0x130) [ 133.92] [] (__ipipe_syscall_root+0x0/0x130) from [] ( vector_swi+0x74/0xb4) [ 133.93] r6:40032c94 r5:beecec7c r4:0010 [ 133.94] I-pipe: Detected illicit call from domain 'Xenomai' [ 133.94] into a service reserved for domain 'Linux' and below. [ 133.94] [] (dump_stack+0x0/0x14) from [] (ipipe_check _context+0xd8/0xfc) [ 133.94] [] (ipipe_check_context+0x0/0xfc) from [] (sc hedule+0x804/0x874) [ 133.94] r4:c0081e60 [ 133.94] r4:c0081e60 den+0xd0/0x134) [ 133.94] [] (xnshadow_harden+0x0/0x134) from [] (xnsha dow_wait_barrier+0x100/0x118) [ 133.94] r6:c2e38000 r5:c2e39fb0 r4:c4801610 [ 133.94] [] (xnshadow_wait_barrier+0x0/0x118) from [] (xnshadow_sys_barrier+0x14/0x18) [ 133.94] r5:c2e39fb0 r4:0001 [ 133.94] [] (xnshadow_sys_barrier+0x0/0x18) from [] (l osyscall_event+0xcc/0x1dc) [ 133.94] [] (losyscall_event+0x0/0x1dc) from [] (__ipi pe_dispatch_event+0xd0/0x1c8) [ 133.94] [] (__ipipe_dispatch_event+0x0/0x1c8) from [] (__ipipe_syscall_root+0x80/0x130) [ 133.94] [] (__ipipe_syscall_root+0x0/0x130) from [] ( vector_swi+0x74/0xb4) [ 133.94] r6:40032c94 r5:beecec7c r4:0010 [ 134.05] Unhandled fault: external abort on non-linefetch (0x008) at 0x400 1f010 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.6 # Tue Nov 3 15:47:24 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_ARCH_MTD_XIP=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="xenomai" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Real-time sub-system # CONFIG_XENOMAI=y CONFIG_XENO_GENERIC_STACKPOOL=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_PRIOCPL=y CONFIG_
[Xenomai-core] Fwd: How to fix static priority to processes known in advance
-- Forwarded message -- From: tarek ben ali Date: 2009/11/3 Subject: How to fix static priority to processes known in advance To: xenomai-core@gna.org Hi All, I am beginner to Xenomai i have implemented Xenomai 2.4.5 on a 2.6.26 Kernel.I'm wondering how can I set priority to processes known in advance,some ideas or code please.I count on your boost. regards, Tarek ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
On Tue, 2009-11-03 at 14:34 +0100, Richard Cochran wrote: > I have compiled and run ipipe-2.6.30.3-powerpc-2.7-02 and Xenomai > v2.4.9.1 (well, actually c4c3c82791951df998ac4dc463f79a76884577b6), on > two similar Freescale boards, the MPC8572DS and the P2020DS. Both are > dual core, and both run fine using vanilla Linux 2.6.30 with SMP. > > If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, > then the machine freezes as soon as Xenomai is started. (As a module, > Xenomai locks the machine when loading). Did you try enabling the pipeline debug options, like CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL? > > Without SMP, it seems to run fine (and latency numbers are excellent!) > > I seem to recall having seen that Xenomai SMP was working on some > other Freescale powerpc chips. Looking for any advice... Xenomai runs on Emerson's mvme7100 powered by a 8641D, but FSL eval boards which are known to work with Xenomai are uniprocessor only so far. SMP-wise, PA-Semi's PA6T (ppc64) and Emerson's mvme7100 (ppc32) are known to work, but I can't tell for any other hw. > > Thanks, > > Richard > > ___ > 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
[Xenomai-core] [Xenomai core] Freeze on MPC8572 and P2020 with SMP
I have compiled and run ipipe-2.6.30.3-powerpc-2.7-02 and Xenomai v2.4.9.1 (well, actually c4c3c82791951df998ac4dc463f79a76884577b6), on two similar Freescale boards, the MPC8572DS and the P2020DS. Both are dual core, and both run fine using vanilla Linux 2.6.30 with SMP. If I enable ipipe only, I can still boot SMP. If Xenomai is enabled, then the machine freezes as soon as Xenomai is started. (As a module, Xenomai locks the machine when loading). Without SMP, it seems to run fine (and latency numbers are excellent!) I seem to recall having seen that Xenomai SMP was working on some other Freescale powerpc chips. Looking for any advice... Thanks, Richard ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH v3 5/9] nucleus: Avoid returning errors from xnheap_destroy_mapped
Philippe Gerum wrote:
> On Mon, 2009-11-02 at 19:01 +0100, Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
On Mon, 2009-11-02 at 17:41 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Sat, 2009-10-24 at 19:22 +0200, Philippe Gerum wrote:
>>> On Tue, 2009-10-20 at 13:37 +0200, Jan Kiszka wrote:
Allowing xnheap_delete_mapped to return an error and then attempting to
recover from it does not work out very well: Corner cases are racy,
intransparent to the user, and proper error handling imposes a lot of
complexity on the caller - if it actually bothers to check the return
value...
Fortunately, there is no reason for this function to fail: If the heap
is still mapped, just install the provide cleanup handler and switch to
deferred removal. If the unmapping fails, we either raced with some
other caller of unmap or user space provided a bogus address, or
something else is wrong. In any case, leaving the cleanup callback
behind is the best we can do anyway.
Removing the return value immediately allows to simplify the callers,
namemly rt_queue_delete and rt_heap_delete.
Note: This is still not 100% waterproof. If we issue
xnheap_destroy_mapped from module cleanup passing a release handler
that belongs to the module text, deferred release will cause a crash.
But this corner case is no new regression, so let's keep the head in
the
sand.
>>> I agree with this one, eventually. This does make things clearer, and
>>> removes some opportunities for the upper interfaces to shot themselves
>>> in the foot. Merged, thanks.
>> Well, actually, it does make things clearer, but it is broken. Enabling
>> list debugging makes the nucleus pull the break after a double unlink in
>> vmclose().
>>
>> Basically, the issue is that calling rt_queue/heap_delete() explicitly
>> from userland will break, due to the vmclose() handler being indirectly
>> called by do_munmap() for the last mapping. The nasty thing is that
>> without debugs on, kheapq is just silently trashed.
>>
>> Fix is on its way, along with nommu support for shared heaps as well.
> OK, I see. Just on minor add-on to your fix:
>
> diff --git a/ksrc/nucleus/heap.c b/ksrc/nucleus/heap.c
> index ec14f73..1ae6af6 100644
> --- a/ksrc/nucleus/heap.c
> +++ b/ksrc/nucleus/heap.c
> @@ -1241,6 +1241,7 @@ void xnheap_destroy_mapped(xnheap_t *heap,
> down_write(¤t->mm->mmap_sem);
> heap->archdep.release = NULL;
> do_munmap(current->mm, (unsigned long)mapaddr, len);
> + heap->archdep.release = release;
> up_write(¤t->mm->mmap_sem);
> }
>
> @@ -1252,7 +1253,6 @@ void xnheap_destroy_mapped(xnheap_t *heap,
> if (heap->archdep.numaps > 0) {
> /* The release handler is supposed to clean up the rest. */
> XENO_ASSERT(NUCLEUS, release != NULL, /* nop */);
> - heap->archdep.release = release;
> return;
> }
>
>
> This is safer than leaving a potential race window open between dropping
> mmap_sem and fixing up archdep.release again.
>
Actually, we have to hold the kheap lock, in case weird code starts
mapping randomly from userland without getting a valid descriptor
through a skin call.
>>> Yep, that as well.
>>>
>> Note that 6b1a185b46 doesn't obsolete my patch (pull it from my tree if
>> you like).
>
> Are you still referring to a race with the vmclose() handler?
>
Went through it again, and it's safe as it is (my patch would actually
open a new whole) - dropped.
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
