Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... Shoot! The probably operator was incorrect, -t 2 did work. -- hl ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latency kernel part crashes on ppc64
Heikki Lindholm wrote: o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. A way to know a bit more about this error would be to have a look at the exact address given by the kernel oops in the disassembly of xnpod_schedule and try and find which pointer is invalid. This is not very subtle, but sometimes works. One reason why there used to be some invalid pointers accesses in xnpod_schedule was when the context switch routine (on x86) forgot to declare a few output or clobbered registers. In this case, the compiler may assume that the contents of the registers are correct, whereas the context switch clobbered them. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if the
only option specified is --enable-linux-build. Do you mean you find this
feature superfluous ?
If $enableval is y, then no path has been specified, so you can
default to the running kernel in such a case.
Here is a third version of the patch, where :
* the --enable-sim option is removed
* the --with-linux-srcdir option is removed
* the CC variable is passed to kernel build system
* prepare-kernel.sh no longer removes target directories before
creating symbolic links.
This is needed for creating links in a new kernel for the fist time:
--- scripts/prepare-kernel.sh~ 2006-01-08 20:14:05.0 +0100
+++ scripts/prepare-kernel.sh 2006-01-08 20:19:41.0 +0100
@@ -2,11 +2,12 @@
set -e
do_links() {
-( cd $2
+( if test -x $2; then
+ cd $2
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
if test ! -e $1/$f; then rm -f $f; fi
- done
+ done; else true; fi
cd $1
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latency kernel part crashes on ppc64
Le dimanche 08 janvier 2006 à 18:56 +0200, Heikki Lindholm a écrit : Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? So it seems I'm not alone. I have done some additionnal debugging on this issue in the last days. I still haven't find the bug but I narrowed it down a bit. Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. It freezes exactly upon the invocation of rtdm_event_pulse() which causes a scheduling. In xnpod_schedule, the scheduler queue has been corrupted and this causes the illegal accesses. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. Same for me. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. Same for me. But very often I don't even get a backtrace, it just hangs. o Does -t2 work? Umm. Probably not. See below. Heikki said in a later mail that it works for him, and so it does for me too. o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. Same for me. Some additionnal information: I've disabled FPU handling in Xeno and it doesn't change anything, it still crashes. As I said before, the old klatency test does work reliably for me, with the latest Xenomai. I tried moving the 'display' thread into the kernel, and in this configuration it does no longer crash. I've started simplifying the code trying to get to the simplest code which does have the problem. The results is at http://www.popies.net/tmp/xenobug/bug.tgz if somebody wants to take a look. I'll be working on this again tomorrow... Stelian. -- Stelian Pop [EMAIL PROTECTED] Open Wide ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. This is needed for creating links in a new kernel for the fist time: Sorry... Here is the 4th patch. Ok, looks like fairly local and non-intrusive. I'm merged this patch into the main trunk eventually, so that it gets more exposure and testing. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] heres a go at an adeos-ipipe-2.6.15-i386-1.1-01.patch
Philippe Gerum wrote: Jim Cromie wrote: Philippe Gerum wrote: You may want to try this one: http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.15-i386-1.1-03.patch although Im not surprised, I feel like telling someone, [EMAIL PROTECTED] ~]$ uname -a Linux harpo.jimc.earth 2.6.15-ipipe-103-sony #1 Sat Jan 7 13:54:09 MST 2006 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] ~]$ is NFS root for .. soekris:~# uname -a Linux soekris 2.6.15-ipipe-103-sk #3 Sat Jan 7 13:42:06 MST 2006 i586 GNU/Linux soekris:~# soekris:~# df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.42.1:/nfshost/soekris 20158372 14249292 4885080 75% / tmpfs63268 0 63268 0% /dev/shm /dev/hda1 484602268767190813 59% /mnt/flash 192.168.42.1:/boot20158400 14249312 4885088 75% /boot 192.168.42.1:/lib/modules 20158400 14249312 4885088 75% /lib/modules 192.168.42.1:/media/cdrecorder 20158400 14249312 4885088 75% /mnt/cd 192.168.42.1:/home20158400 14249312 4885088 75% /home 192.168.42.1:/mnt/dilbert 15638816 11716256 3128128 79% /mnt/dilbert 192.168.42.1:/usr/xenomai 20158400 14249312 4885088 75% /usr/xenomai 192.168.42.1:/home/jimc/dilbert/pirt 15638816 11716256 3128128 79% /mnt/pirt woohoo! I just diffed my-1.01 and real-1.03, it looks like I missed a bunch of these: - spin_unlock_irqrestore(ioapic_lock, flags); + spin_unlock_irqrestore_hw(ioapic_lock, flags); did I get lucky ? or is it cuz Im not SMP ? The additional hw locking is to make 100% sure that built-in Adeos domains pushed above Linux could call the related routines i.e. any routine manipulating the io_apic spinlock. This said, I've been a bit silly ironing the IO-APIC enabling code, since you can't get any conflict until the IO-APIC is well, enabled, and interrupts could flow and thus feed the high priority domain. even during the kernel init phase. Since the I-pipe is enabled quite early during this process, I've decided to play extra safe here. or cuz my sony has no APIC (as distinct from ACPI) ? do any PCs have an APIC, or is that something for servers / hi-end or embedded ? It has become the norm for desktops, Intel CPU(s) of hi-end boxen have one especially SMP since it works with the IO-APIC for routing interrupts among other things. Still not the norm for embedded AFAIK, this will possibly evolve the same way over time too. BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1ff4 (usable) BIOS-e820: 1ff4 - 1ff5 (ACPI data) BIOS-e820: 1ff5 - 2000 (ACPI NVS) 511MB LOWMEM available. On node 0 totalpages: 130880 DMA zone: 4096 pages, LIFO batch:0 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 126784 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:0 DMI present. ACPI: RSDP (v000 SONY ) @ 0x000f53f0 ACPI: RSDT (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff4 ACPI: FADT (v002 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff40200 ACPI: OEMB (v001 SONY F1 0x20040323 MSFT 0x0097) @ 0x1ff50040 ACPI: DSDT (v001 SONY F1 0x20040323 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x408 Allocating PCI resources starting at 3000 (gap: 2000:e000) Built 1 zonelists Kernel command line: ro root=LABEL=/ Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 1694.791 MHz processor. Using pmtmr for high-res timesource I-pipe 1.1-03: pipeline enabled. BTW, what happened to 1.01 and 1.02 ? There were three critical changes to merge for starting 1.1; one at a time, -03 has ended the series. tia jimc -- Philippe.
Re: [Xenomai-core] Two patches for the documentation
Niklaus Giger wrote: Hi xeno.sim.patch contains some clarification on how to build the xenoscope. (GCC 3.4 worked for me on a x86 system, but with a lot of warnings, that fwritable is deprecated) xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. It worked for me without any problems for my board. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Best regards Index: README.INSTALL === --- README.INSTALL (Revision 392) +++ README.INSTALL (Arbeitskopie) @@ -150,20 +150,22 @@ needed, but if you do not use it, configure emit a warning, which may be confusing. +The easiest way to build a GNU cross-compiler might involve using Dan Kegel +crosstools found at http://kegel.com/crosstool. + Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC -architecture may be named powerpc-linux-gcc. +architecture may be named powerpc-405-linux-gnu-gcc. -When this prefix contains the name of the architecture, you may pass this prefix -to the --host option of configure. For example, if you type : -configure --host=powerpc-linux - -configure will automatically use powerpc-linux- as a prefix too all compilation +configure will automatically use powerpc-405-linux-gnu- as a prefix too all compilation tools names and deduce the architecture name. If configure is unable to deduce the architecture name from this prefix, you will have to manually pass the name of all compilation tools on configure command line. As in: -configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +It might be a good idea to put all the output into a differen build directory +as to build from from linux source several targets. For each target add +O=../build-target to each make invocation. +configure CROSS_COMPILE=powerpc-405-linux-gnu- For more details: http://sourceware.org/autobook/autobook/autobook_264.html#SEC264 @@ -204,16 +206,18 @@ 2.2 Building for the PowerPC architecture A typical cross-compilation setup, in order to build Xenomai for a -82xx-based system: +PowerPC-405-based system: $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ make xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make bzImage modules # then install as needed +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +# select the kernel and Xenomai options +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +# then install as needed $ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +$ $xenomai_root/configure CROSS_COMPILE=powerpc-405-linux-gnu- $ make install 2.3 Building for the IPF Applied, thanks. Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + Why? +You will need the libelf, libpng, tcl8.x/tk8.x and tix81 _development packages_ in order to build the simulator and its companion tools. For instance, on Debian systems, you will need to install libelfg0-dev, libpng2-dev, tcl8.3-dev, tk8.3-dev and tix41-dev (any ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? --with-adeos-patch specify the path to the Adeos patch. Default is to infer the patch name from Linux kernel version. When using the --enable-linux-build option, configure creates a linux tree in Xenomai build tree, and run the prepare-kernel.sh script for this tree. Typing make re-runs prepare-kernel.sh (in case some changes occured in Xenomai sources) and run make in the kernel tree. Known limitations are: - it is not very well tested, so, maybe some error cases are not handled correctly ; - it is not tested with Linux 2.4 ; - for an unknown reason, xenomai modules are built every time prepare-kernel.sh is run ; - the cross-compilation prefix is inferred from the CC variable, it should work in most situations, but not all. Happy new year. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? -- Gilles Chanteperdrix.
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Hi, attached is a patch of Xenomai trunk build system to allow building Linux kernel as part of Xenomai build process. This way, typing make install builds and installs the Linux kernel, kernel modules and Xenomai. The patch is a bit young and still has a few drawbacks, but before spending to much time on it, I would like to know if anyone is opposed to the idea of building Linux in Xenomai build tree. To try this patch, apply and run the bootstrap script. 3 options are then added to configure : --enable-linux-buildBuild Linux in Xenomai build tree --with-linux-srcdir specify the path to Linux sources. Default is to use, if not cross-compiling, the source of the running kernel or /usr/src/linux. --enable-linux-build=linux-tree ? The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. -- Philippe.
Re: [Xenomai-core] Two patches for the documentation
Niklaus Giger wrote: xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. The CROSS_COMPILE prefix is not used by the configure script of branch 2.1 of Xenomai (though it works with branch 2.0), the --host option of configure should be used instead. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Maybe this would look more apropriate in section 1.2, entitled Configuring and building Linux kernel ? The attached patch, for your review, attempt to reword the paragraph I had written on cross-compilation, and reflect the last two remarks. -- Gilles Chanteperdrix. xeno.readme.patch Description: Binary data
[Xenomai-core] rt_task_spawn with NULL name and pascal linking
Hi, I needed a lot coffee and tobacco resources to find out that rt_task_spawn with NULL name will not work in userspace. The call failed with -3 (ESRCH?). This error seems not documented the xenomai api documention. Using rt_task_create and rt_task_start it was rt_task_start that failed. I think this is related to Jans statement below. As rt_task_spawn is a inline function and a combination of create/start, this can be confusing. I.e. rt_task_shadow works with NULL name and rt_task_spawn dont. At this point I should mention that im testing my pascal-translations of the xenomai native and rtdm headers, but i dont see that the problem should be related to it, I searched the problem a long time i this part ;-) Some questions: Im still using Xenomai 2.0.1, is this the problem ? Shouldnt this be documented better ? Would it work if rt_task_spawn is a skincall? pascal-related: Is there a way to export the c-inline functions also in the libs, so that the complete api is exported ? rt_task_spawn and some rt_*_unbind funtions are inlined. Its not a problem to reprogram these in pascal, but for maintenance reasons it would be nice if i could link against these functions. greetings kisda Am Donnerstag, 8. Dezember 2005 20.40 schrieb Jan Kiszka: Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? pgpw6ySLonvmR.pgp Description: PGP signature
Re: [Xenomai-core] latency kernel part crashes on ppc64
Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: o When and how does it crash? At start-up immediately? Or after a while? o Are there any details / backtraces available with the crash? o Does -t2 work? o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. -- Gilles Chanteperdrix. xeno-build-kernel.3.diff Description: Binary data
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. One odd thing (probably unrelated) is that the first two ioctls get called in what seems like wrong order, eg. START_TMTEST first ends up in tmbench_ioctl_rt and then _nrt and INTERM_RESULT ends up first in _nrt and then _rt. -- Heikki Lindholm
Re: [Xenomai-core] latency kernel part crashes on ppc64
Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... When you are already on it: pure user-space (-t0) also works? o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. One odd thing (probably unrelated) is that the first two ioctls get called in what seems like wrong order, eg. START_TMTEST first ends up in tmbench_ioctl_rt and then _nrt and INTERM_RESULT ends up first in _nrt and then _rt. This takes me back to the number of active real-time tasks during the test. This disabling reduces the scenario basically again to old klatency times. I looked at my code again, but - maybe I'm too blind now - I cannot find even a potential pointer bug, especially when the histogram feature (-h) is not used. I need more input! ;) Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] latency kernel part crashes on ppc64
Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... Shoot! The probably operator was incorrect, -t 2 did work. -- hl
Re: [Xenomai-core] latency kernel part crashes on ppc64
Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Jan Kiszka kirjoitti: Heikki Lindholm wrote: Hi, Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? To get this clearly: You tested the old klatency(+front-end) on latest xeno and it worked? Or does this parse the old klatency worked over old xeno on PPC64? Previously as in ... well ... previously, so it means the old xenomai with klatency intact. Comparing the old test with the new framework, the major difference is that the old one only knew a single kernel RT-task. Its front-end was reading from a pipe and was therefore a pure linux program. Now we have two RT-tasks, one is even a shadow, and they use RT-IPC. Not sure if this really means that the bug must be in the benchmark suite... Right. I'll have to see if there's a problem with any of these. o Does -t2 work? Umm. Probably not. See below. Arrgh, probably - when it's so easy to test... Well, it's one compile and boot cycle more with my current situation. I try to view laziness as a gift... Rebooting - sure, but what do you compile each time? When you are already on it: pure user-space (-t0) also works? Pure user-space works fine. Hmm, that's not so different from the POV of used nucleus mechanisms... o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. One odd thing (probably unrelated) is that the first two ioctls get called in what seems like wrong order, eg. START_TMTEST first ends up in tmbench_ioctl_rt and then _nrt and INTERM_RESULT ends up first in _nrt and then _rt. Forgot to comment on this: It's a normal behaviour. The caller comes across the first IOCTL in primary mode. But as this service is only available to secondary mode, the invocation is restarted after a mode switch. Same happens to the second IOCTL, just the other way around. If you weren't lazy, I would suggest watching the different flow when switching the mode manually first. ;) This takes me back to the number of active real-time tasks during the test. This disabling reduces the scenario basically again to old klatency times. I looked at my code again, but - maybe I'm too blind now - I cannot find even a potential pointer bug, especially when the histogram feature (-h) is not used. I need more input! ;) Hehe. The histogram was the first thing I peered at, only to find out it's not even used. This might be a kernel thread switching bug in my code, but I find it hard to believe, because then even one thread probably wouldn't work. ... and the userspace test with two threads should fail. Another player in this game is the RTDM layer itself. But there is no much of it involved, and it's not really arch-dependent code. Jan signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The current approach is to use the sources of the running kernel if the
only option specified is --enable-linux-build. Do you mean you find this
feature superfluous ?
If $enableval is y, then no path has been specified, so you can
default to the running kernel in such a case.
Here is a third version of the patch, where :
* the --enable-sim option is removed
* the --with-linux-srcdir option is removed
* the CC variable is passed to kernel build system
* prepare-kernel.sh no longer removes target directories before
creating symbolic links.
This is needed for creating links in a new kernel for the fist time:
--- scripts/prepare-kernel.sh~ 2006-01-08 20:14:05.0 +0100
+++ scripts/prepare-kernel.sh 2006-01-08 20:19:41.0 +0100
@@ -2,11 +2,12 @@
set -e
do_links() {
-( cd $2
+( if test -x $2; then
+ cd $2
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
if test ! -e $1/$f; then rm -f $f; fi
- done
+ done; else true; fi
cd $1
find . \( -name Makefile -o -name $config_file -o -name '*.[chS]' \) |
while read f; do
--
Philippe.
Re: [Xenomai-core] latency kernel part crashes on ppc64
Heikki Lindholm wrote: o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. A way to know a bit more about this error would be to have a look at the exact address given by the kernel oops in the disassembly of xnpod_schedule and try and find which pointer is invalid. This is not very subtle, but sometimes works. One reason why there used to be some invalid pointers accesses in xnpod_schedule was when the context switch routine (on x86) forgot to declare a few output or clobbered registers. In this case, the compiler may assume that the contents of the registers are correct, whereas the context switch clobbered them. -- Gilles Chanteperdrix.
Re: [Xenomai-core] latency kernel part crashes on ppc64
Le dimanche 08 janvier 2006 à 18:56 +0200, Heikki Lindholm a écrit : Some recent changes (*cough* RTDM benchmark driver *cough*) broke kernel mode benchmarking for ppc64. Previously klatency worked fine, but now latency -t 1 crashes somewhere in xnpod_schedule. Jan, any pending patches a comin'? So it seems I'm not alone. I have done some additionnal debugging on this issue in the last days. I still haven't find the bug but I narrowed it down a bit. Nope, it should work as it is. But as Stelian also reported problems on his fresh ARM port with the in-kernel test, I cannot exclude that there /might/ be a problem in the benchmark. As I don't have any ppc64 hanging around somewhere, we will have to go through this together. Things I would like to know: Dammit, I hoped you'd whip up a fix just from me noting a problem. Well, all right then, I'll play along...;) o When and how does it crash? At start-up immediately? Or after a while? I inserted some serial debug prints and it gets two passes to eval_outer_loop done (enter/exit function). After that it freezes. It freezes exactly upon the invocation of rtdm_event_pulse() which causes a scheduling. In xnpod_schedule, the scheduler queue has been corrupted and this causes the illegal accesses. Without the debug printing it dies with kernel access of illegal memory at xnpod_schedule, which btw. has been quite a common place to die. Same for me. o Are there any details / backtraces available with the crash? Becaktrace limits to xnpod_schedule if I remember right. Same for me. But very often I don't even get a backtrace, it just hangs. o Does -t2 work? Umm. Probably not. See below. Heikki said in a later mail that it works for him, and so it does for me too. o What happens if your disable rtdm_event_pulse(ctx-result_event); in eval_outer_loop (thus no signalling of intermediate results during the test)? Does it still crash, maybe later during cleanup now? Doesn't freeze and can be exited with ctrl-c and even re-run. Same for me. Some additionnal information: I've disabled FPU handling in Xeno and it doesn't change anything, it still crashes. As I said before, the old klatency test does work reliably for me, with the latest Xenomai. I tried moving the 'display' thread into the kernel, and in this configuration it does no longer crash. I've started simplifying the code trying to get to the simplest code which does have the problem. The results is at http://www.popies.net/tmp/xenobug/bug.tgz if somebody wants to take a look. I'll be working on this again tomorrow... Stelian. -- Stelian Pop [EMAIL PROTECTED] Open Wide
Re: [Xenomai-core] [rfc] Building Linux kernel in Xenomai tree.
Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: Philippe Gerum wrote: Gilles Chanteperdrix wrote: The current approach is to use the sources of the running kernel if the only option specified is --enable-linux-build. Do you mean you find this feature superfluous ? If $enableval is y, then no path has been specified, so you can default to the running kernel in such a case. Here is a third version of the patch, where : * the --enable-sim option is removed * the --with-linux-srcdir option is removed * the CC variable is passed to kernel build system * prepare-kernel.sh no longer removes target directories before creating symbolic links. This is needed for creating links in a new kernel for the fist time: Sorry... Here is the 4th patch. Ok, looks like fairly local and non-intrusive. I'm merged this patch into the main trunk eventually, so that it gets more exposure and testing. -- Philippe.
[Xenomai-core] [PATCH] fix tracer compilation issues
Hi Philippe, two minor updates I fixed since your last merge. The first one triggers if the tracer tries to warn of debugging switch related latencies. The second one when building very specific out-of-tree modules against the kernel (here: madwifi with its binary-only component), stumbling over -pg vs. -fomit-frame-pointer. No need for a separate ipipe release from my POV, just apply for the next round. Jan --- ./kernel/ipipe/tracer.c.orig2006-01-07 13:28:01.0 +0100 +++ ./kernel/ipipe/tracer.c 2006-01-08 23:08:45.0 +0100 @@ -821,7 +821,7 @@ static void *__ipipe_frozen_prtrace_star -- --\n, UTS_RELEASE, IPIPE_ARCH_STRING); - __ipipe_print_dbgwarning(); + __ipipe_print_dbgwarning(m); seq_printf(m, Freeze: %lld cycles, Trace Points: %d (+%d)\n\n, print_path-point[print_path-begin].timestamp, print_pre_trace+1, print_post_trace); --- ./kernel/ipipe/Kconfig.orig 2006-01-07 13:28:01.0 +0100 +++ ./kernel/ipipe/Kconfig 2006-01-07 14:24:50.0 +0100 @@ -17,6 +17,7 @@ config IPIPE_STATS config IPIPE_TRACE bool Latency Tracing depends on IPIPE PROC_FS + select FRAME_POINTER default n ---help--- Activate this option if you want to use per-function tracing of signature.asc Description: OpenPGP digital signature
