Re: [Xenomai-core] rtdm_iomap_to_user() with PowerPC

2007-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Markus Osterried wrote: Sorry for being intrusive. I've already done a quick and dirty bug fix, so final bug fix is not urgent. Just wanted to know about time schedule. At least 2.4 is near, but I guess another 2.3 release will follow as well (due to recently accumulated

[Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Jan Kiszka
Hi all, testing my ltt patches over 2.6.23-i386 with latest Xenomai SVN, I found the first noteworthy effect. First the relevant trace snippet: ... kernel_irq_exit: 430.606359465 (/usr/src/lttng-xenomai/trace4/cpu_0), 0, 0, swapper, , 0, 0x0, SYSCALL xn_nucleus_irq_enter: 430.608893573

Re: [Xenomai-core] [Adeos-main] [PATCH] i386: switch to root domain on unhandled non-root faults

2007-11-08 Thread Jan Kiszka
Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: This patch addresses the recently discovered issue that I-pipe actually need to deal with faults over non-root domain in which the current domain shows no interest in. Such faults could be

[Xenomai-core] [PATCH] Wrong -lpthread/-lrt order in testsuite/clocktest/Makefile.am ?

2007-11-08 Thread Fillod Stephane
Hi, Testing xenomai-2.4-rc5, I've encountered the following link error: powerpc-linux-uclibc-gcc -Wl,--wrap -Wl,pthread_create -Wl,--wrap -Wl,mmap -Wl,--wrap -Wl,munmap -o clocktest clocktest-clocktest.o ../../skins/posix/.libs/libpthread_rt.a -lpthread -lrt

Re: [Xenomai-core] [PATCH] Wrong -lpthread/-lrt order in testsuite/clocktest/Makefile.am ?

2007-11-08 Thread Gilles Chanteperdrix
On Nov 8, 2007 3:10 PM, Fillod Stephane [EMAIL PROTECTED] wrote: Hi, Testing xenomai-2.4-rc5, I've encountered the following link error: powerpc-linux-uclibc-gcc -Wl,--wrap -Wl,pthread_create -Wl,--wrap -Wl,mmap -Wl,--wrap -Wl,munmap -o clocktest clocktest-clocktest.o

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Jan Kiszka
Jan Kiszka wrote: ... Xenomai is loaded at this time but not yet used. Linux runs in tickless highres mode and obviously had programmed the host timer to fire here. But instead of one timer IRQ (233) + its handling, we see an additional early shot (about 3 µs too early here - the longer the

Re: [Xenomai-core] [Adeos-main] [PATCH] i386: switch to root domain on unhandled non-root faults

2007-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: This patch addresses the recently discovered issue that I-pipe actually need to deal with faults over non-root domain in which the current domain shows no interest in. Such faults could be

Re: [Xenomai-core] User space drivers on PPC440

2007-11-08 Thread Philippe Gerum
Steven A. Falco wrote: The rt_misc_get_io_region() has the start argument as an unsigned long. On the PPC440, we have a 36-bit address space, where the I/O registers are generally above the 4GB area. For example, the UART is at address 0x1ef600300. The Linux request_region call has

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: ... Xenomai is loaded at this time but not yet used. Linux runs in tickless highres mode and obviously had programmed the host timer to fire here. But instead of one timer IRQ (233) + its handling, we see an

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Philippe Gerum
Jan Kiszka wrote: Jan Kiszka wrote: ... Xenomai is loaded at this time but not yet used. Linux runs in tickless highres mode and obviously had programmed the host timer to fire here. But instead of one timer IRQ (233) + its handling, we see an additional early shot (about 3 µs too early here

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: ... Xenomai is loaded at this time but not yet used. Linux runs in tickless highres mode and obviously had programmed the host timer to fire here. But instead of one timer IRQ (233) + its handling, we see an additional early shot

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Jan Kiszka
Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Jan Kiszka wrote: ... Xenomai is loaded at this time but not yet used. Linux runs in tickless highres mode and obviously had programmed the host timer to fire here. But instead of one timer IRQ (233) + its

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Philippe Gerum
Jan Kiszka wrote: sysinfo.tmfreq was meant to be such value. Well, then it is totally mis-initialised on x86 so far, same on powerpc. In fact, there it is the _clock_ frequency, not the timer frequency. So what is meant by this? One comment actually call it Timebase frequency (powerpc).

[Xenomai-core] User space drivers on PPC440

2007-11-08 Thread Steven A. Falco
The rt_misc_get_io_region() has the start argument as an unsigned long. On the PPC440, we have a 36-bit address space, where the I/O registers are generally above the 4GB area. For example, the UART is at address 0x1ef600300. The Linux request_region call has start typed as a

Re: [Xenomai-core] User space drivers on PPC440

2007-11-08 Thread Steven A. Falco
(i.e. CONFIG_RESOURCES_64BIT is set even though this is a 23-bit processor). Make that a 32-bit processor. :-[ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Testing LTTng: first insights

2007-11-08 Thread Jan Kiszka
Philippe Gerum wrote: ... Ok, I'm not going to argue about cleanliness or brokenness about this... issue, because it's first and foremost a matter of taste. The main point, I think, is this one: is the clock device something which may be changed on-the-fly during real-time operations, in such

[Xenomai-core] ipipe_pin_range_globally.

2007-11-08 Thread Gilles Chanteperdrix
Hi, In the process of updating the I-pipe patch for ARM, I have written ipipe_pin_range_globally. But now that I look at the place where ipipe_pin_range_globally is called, I see that it is called only upon memory mapping in the vmalloc area, should not it be called also when memory is unmapped