Re: [Xenomai-help] RE : IRQ latency
On 05/18/2012 09:06 AM, Jean-Pascal JULIEN wrote:
>>> Hi,
>>>
>>> I installed xenomai on an overo water board (cortex A8) and performed
>>> latency tests.
>
>> What version of Xenomai?
>
>>> I tested two modules.
>>> The first module is based on an internal timer. It toggles a GPIO each
>>> 1ms.
>>> The second module waits for an external interrupt from an input GPIO
>>> (square signal at 1KHz). When that happens, the module toggles a GPIO pin.
>>>
>>> When i load the system and do a transfer from Ethernet to the sd card the
>>> first module works fine with a maximum latency less than 50us.
>>> But the second module, in the same context, have a maximum latency of
>>> several milliseconds.
>>>
>>> As the first module works fine i think i have a problem with the hardware
>>> configuration like the hardware irq priority.
>>> In the irq.c file, the irq priority level is not set for the linux domain.
>>>
>>> Should i configure the irq level at the initialization of the board ? What
>>> else could cause this issue ?
>
>> The error is more likely in the code of your driver. Show us the code.
>
> Hi Gilles,
>
>
> Sorry, i forgot the essential.
> My linux kernel version is the 2.6.38 from sakoman.
> My xenomai version is xenomai-2.6.0
> The adeos patch is : adeos-ipipe-2.6.38.8-arm-1.18-04.patch (
> ./prepare-kernel.sh --linux=${WORKDIR}/git --arch=arm
> --adeos=${WORKDIR}/xenomai-2.6.0/ksrc/arch/arm/patches/adeos-ipipe-2.6.38.8-arm-1.18-04.patch).
> The xenomai user space is make with the next configuration :
> ./configure --build=arm-ti-linux --host=arm-none-linux-gnueabi --prefix=/usr
> --includedir=/usr/include/xenomai --enable-arm-tsc=omap3 --disable-dox-doc
> --disable-dbx LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu"
You do not need --enable-arm-tsc.
I see nothing wrong with your code. However this version of the I-pipe
patch has a bug with gpio irqs. You can try backporting this patch:
http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=81bfc05c4716b76e79f5e486baf4c52015a3b92c
To fix it. If that is the cause of your problem, then you should only
see the bug if you are running some other real-time program which
triggers a user-space task wakeup based in an interrupt, such as for
instance the timer interrupt. Running the "latency" test for instance
would do that.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai Periodic Latency Spikes
On 05/17/2012 09:12 PM, Wolz, Troy wrote: > Hello, > > When running the latency program provided in the Xenomai source, my > latency numbers for 'max latency' is consistently over 30 us. I have > installed Xenomai 2.6.0 using Linux kernel 2.6.38.8. I have attached > my config for my linux kernel. SMI is disabled, legacy USB support is > disabled in the BIOS, and the other obvious latency killers provided > in the troubleshooting guide have been checked. Oly CONFIG_ACPI_PROCESSOR should be turned off. It is recommended to keep CONFIG_ACPI on. CONFIG_XENO_OPT_DEBUG_XNLOCK has some impact on latencies, if you want to reduce latencies, you should turn it off. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai Periodic Latency Spikes
On 05/17/2012 09:35 PM, Wolz, Troy wrote: > In the attached plots, there appear to be very periodic spikes in > latency. In the time between these spikes, the worst case latency is > around 5 us. Is this to be expected? Is worst case latency typically > periodic in nature? >From the measurements I posted recently: http://sisyphus.hd.free.fr/~gilles/core-3.2-latencies It seems on higher-end machines, the probability decreases approximately exponentially from the average latency to the max latency. So, every latency smaller than the worst case latency has some probability to happen, and happens from time to time. On an atom 230 (which admittedly is not a such high end machine), the average latency is less than 10us, but the maximum latency reaches 70us when running with CONFIG_SMP. The worst case latency you obtain on a machine without load, or over a short period of time does not mean anything. If you are serious about measuring the worst case latency, you have to do it over a long period of time while running under load. We provide the "xeno-test" and "dohell" scripts for that. If your kernel is running with CONFIG_HZ set to 1000, the thing which happens once every 1ms is the 8254 timer interrupt, on cpu 0 at least. If you want to know what happens when the worst case latency is reached you have to enable the I-pipe tracer and run the latency test with the "-f" argument. I am not saying that there is not a problem with your setup, but there is nothing proving that in what you posted. Please no: - private mails - html mails - un-wrapped lines - top-posting. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai Periodic Latency Spikes
On 05/17/2012 09:12 PM, Wolz, Troy wrote: > Hello, > > When running the latency program provided in the Xenomai source, my latency > numbers for 'max latency' is consistently over 30 us. And you think that it should be under 30 us because... ? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IRQ latency
>> Hi, >> >> I installed xenomai on an overo water board (cortex A8) and performed >> latency tests. > > What version of Xenomai? And more importantly, what version of the I-pipe patch. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IRQ latency
> Hi, > > I installed xenomai on an overo water board (cortex A8) and performed > latency tests. What version of Xenomai? > I tested two modules. > The first module is based on an internal timer. It toggles a GPIO each > 1ms. > The second module waits for an external interrupt from an input GPIO > (square signal at 1KHz). When that happens, the module toggles a GPIO pin. > > When i load the system and do a transfer from Ethernet to the sd card the > first module works fine with a maximum latency less than 50us. > But the second module, in the same context, have a maximum latency of > several milliseconds. > > As the first module works fine i think i have a problem with the hardware > configuration like the hardware irq priority. > In the irq.c file, the irq priority level is not set for the linux domain. > > Should i configure the irq level at the initialization of the board ? What > else could cause this issue ? The error is more likely in the code of your driver. Show us the code. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/15/2012 04:34 PM, aubin.rebil...@free.fr wrote: > I really didn't see how my code could influence this so I checked the > bug fixes for Xenomai 2.5 and i found one which was not fixed in my > version of xenomai. The bug was the return value of rthal_timer_request. Oh, I missed that, don't do that. Please use Xenomai 2.6. It is backward compatible with old I-pipe patches. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] POSIX API
On 05/15/2012 10:02 AM, ali hagigat wrote: > I am looking for all POSIX functions of Linux, i wonder if any body > has POSIX.1-2008 manual or IEEE1003.1 or a similar document. > Does xenomai change libc.a ? As far as I understood, xenomai adds new > functions(they start with rt_), besides it changes some of posix > functions while it keeps some posix functions untouched. Functions which start with rt_ are part of the native skin. The implementation of the posix skin does not change libc.a, it implements a new library libpthread_rt.so, and the function substitution is done at link-edition time by using the linker --wrap option. > Is there any book regarding to the real time programming in xenomai? You can start here: http://www.xenomai.org/index.php/Included_documentation_summary For instance the --wrap trick is explained here: http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Under_the_hood:_the_--wrap_flag -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on kernel 3.x and x86
On 05/14/2012 10:13 AM, Philippe Gerum wrote: > There is an upcoming patch for linux 3.2, which is the first of the new > pipeline "core" series, a massive refactoring of the I-pipe > implementation and API, aimed at a better integration with Xenomai: > http://git.denx.de/?p=ipipe-2.6.git;a=shortlog;h=refs/heads/core-3.2 For those interested, here are a few latency measurements made with this new patch on the various platforms I have, in order to compare Xenomai 2.6.1 with the current state of the upcoming 3.x branch. The graphs show clearly that Xenomai 3.x has better average and minimum latencies on low end platforms. The lower end the platform, the more the latency graph is shifted to the left. http://sisyphus.hd.free.fr/~gilles/core-3.2-latencies/ -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/14/2012 06:18 PM, Gilles Chanteperdrix wrote: > On 05/14/2012 06:13 PM, aubin.rebil...@free.fr wrote: >> Hi Gilles, >> >> I've followed your advices and reimplemented the timer management. >> Now it's an up counter wrapping to 0 on overflow, it uses a match >> register to trigger the interrupt and it's never disabled. >> >> I've also cleaned the code : suppressed linux specific calls, move >> update_tsc to linux handler, etc... as you advised me. >> >> Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI >> disabled, and it's working fine. >> I also tested with only CONFIG_XENOMAI disabled and it's still >> working as expected. >> >> Nevertheless, the issue is still the same. It hangs after starting >> the init program. >> >> After investigations, the problem is that __ipipe__mach_set_dec is >> never called after Xenomai has taken control of the timer. The last >> timer update was done in rthal_timer_calibrate and it effectively >> triggers an interrupt after MAXINT ticks (I've put a printk in the >> linux timer handler and it's displayed after a few time). >> >> My problem is that i don't really understand the timer management by >> Xenomai. As i understood each skin has its own timers and Xenomai >> manages to trigger them when expected. But what code is managing the >> linux timer ? >> I'm expecting to probably have errors in my ipipe code that's why i'm >> asking this, to follow the execution and see where it is broken. >> >> Thank you very much, > > > If the interrupt triggers only once, it probably means that the timer > needs some acknowledgement that must be put in __ipipe_mach_acktimer. > > The code managing Linux timer works and has been validated on all the > port so far. So, the thing probably at fault is the timer management > code in the I-pipe patch. Do not worry for Linux timer interrupt, only > take care of ipipe_mach_set_dec and ipipe_mach_acktimer. > > Also, if some timer programming is done in linux timer interrupt, it > should not be done once ipipe_mach_timerstolen is true. > To summarize, there are two states in the system: Either Linux is handling the timer, in which case: - ipipe_mach_timerstolen == 0 - ipipe_mach_acktimer is called to acknowledge the linux timer interrupt - linux timer interrupt routine is called for each timer interrupt, HZ times a second, and in charge to reprogram the timer hardware if it needs to be reprogrammed Either xenomai is handling the timer, in which case: - ipipe_mach_timerstolen == 1 - ipipe_mach_acktimer is called to acknowledge the xenomai timer interrupt - ipipe_mach_set_dec is called by xenomai to program the next timer interrupt linux timer interrupt is called HZ times a second, but should not touch anything related to the timer hardware, because that part is handled by xenomai now (vie ipipe_mach_set_dec). if CONFIG_IPIPE is enabled and CONFIG_XENOMI is disabled, only the first state happens. if CONFIG_XENOMAI is enabled, as soon as xenomai is started, we enter the second state. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/14/2012 06:13 PM, aubin.rebil...@free.fr wrote: > Hi Gilles, > > I've followed your advices and reimplemented the timer management. > Now it's an up counter wrapping to 0 on overflow, it uses a match > register to trigger the interrupt and it's never disabled. > > I've also cleaned the code : suppressed linux specific calls, move > update_tsc to linux handler, etc... as you advised me. > > Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI > disabled, and it's working fine. > I also tested with only CONFIG_XENOMAI disabled and it's still > working as expected. > > Nevertheless, the issue is still the same. It hangs after starting > the init program. > > After investigations, the problem is that __ipipe__mach_set_dec is > never called after Xenomai has taken control of the timer. The last > timer update was done in rthal_timer_calibrate and it effectively > triggers an interrupt after MAXINT ticks (I've put a printk in the > linux timer handler and it's displayed after a few time). > > My problem is that i don't really understand the timer management by > Xenomai. As i understood each skin has its own timers and Xenomai > manages to trigger them when expected. But what code is managing the > linux timer ? > I'm expecting to probably have errors in my ipipe code that's why i'm > asking this, to follow the execution and see where it is broken. > > Thank you very much, If the interrupt triggers only once, it probably means that the timer needs some acknowledgement that must be put in __ipipe_mach_acktimer. The code managing Linux timer works and has been validated on all the port so far. So, the thing probably at fault is the timer management code in the I-pipe patch. Do not worry for Linux timer interrupt, only take care of ipipe_mach_set_dec and ipipe_mach_acktimer. Also, if some timer programming is done in linux timer interrupt, it should not be done once ipipe_mach_timerstolen is true. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.
On 05/11/2012 05:02 PM, Frederik Bayart wrote: > now with mailing list in cc > > Hallo Gilles, > > by adding my user to group xenomai and configuring the > xeno_nucleus.xenomai_gid parameter on the command line, I was able to > run my binary as non-root, so my problem is solved. > > However, I noticed that if I start my binary as root, and using > seteuid and setegid to non-root as in de example still fails. I don't > know whether this is normal or a bug. It is normal. For your case to run, the fork itself must be run a root. So, you should call again seteuid/setegid before vfork, then drop again the rights before exec (if you do not want the exec to be run as root). -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Does qemu-kvm impact realtime performance?
On 05/10/2012 04:26 PM, Henri Roosen wrote: > Hi all, > > Does anyone know if running qemu-kvm impacts the realtime Xenomai > performance of the host system? > > I have a multicore x86 target that runs a Xenomai enabled kernel and a > realtime application. Next to the realtime application I would like to > run qemu-kvm (on one of the cores) that runs some non-realtime guest > os. So I would like to know if qemu-kvm have impact on the > latencies/jitter of the realtime threads? I would say it should have no direct impact, we should not expect kvm to create hard irqs masking sections. However, as usual, running a whole OS and applications inside another OS probably has a huge impact on cache, and so should cause more jitter than running xenomai on an idle system. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 07:38 PM, aubin.rebil...@free.fr wrote: >> De: "Gilles Chanteperdrix" >> À: "aubin rebillat" >> Cc: xenomai-help@gna.org >> Envoyé: Jeudi 10 Mai 2012 19:28:46 >> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC >> >> On 05/10/2012 03:26 PM, aubin.rebil...@free.fr wrote: >>> Hello, >>> >>> I am trying to port Xenomai on the TS-7553 SBC from Technologic >>> systems, based on the ECONA CNS2132 (STAR8132) from Cavium >>> networks (250 MHz arm922t). >>> A Linux kernel is available for this board, version 2.6.24.4, which >>> is running fine. >>> I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and >>> I implemented all the IPIPE code for the CNS2132 and everything is >>> compiling and booting fine. >> >> Note that the following page: >> http://www.openembedded.org/wiki/TS-7500 >> >> Proposes patches for linux 2.6.35, which is really, really, really >> more >> current than 2.6.24, and for which an I-pipe patch also exists. >> >> I mean, with 2.6.24, you may find bugs we do not even remember, >> because >> they were fixed such a long time ago. >> > > I preferred to use the version 2.6.24 which is shipped with the board > because the manufacturer can provide support in case of trouble. As soon as you patch with the I-pipe patch, the manufacturer can answer to your support requests that you are not using its kernel. > But, I compiled and tested the version 2.6.35 and it's running fine at > first but the dmesg output is corrupted with a lot of "BAD IRQ". > I thought that this version was not really stable yet and I don't have > enough time in my project to ensure it. That's why I preferred to use > the version 2.6.24. > > If a bug is happening with our application, I will definitely move > to the most recent one. Well, I had a look at the patches for 2.6.35, and they really mess with things with which they should not (cache and TLB handling for instance). If you intend to do some serious work with this platform, you should really consider doing a clean linux port, or get some specialist to do it. Otherwise this will byte you sooner or later. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 07:29 PM, aubin.rebil...@free.fr wrote:
>> Also, from the sources I could gather (snakeos-sdk), the hardware
>> timer
>> for str8100 is programmed in periodic, auto-reload mode. Obviously,
>> when
>> CONFIG_IPIPE is on, you have to change this to make the timer run in
>> one-shot mode, as required by Xenomai.
>
> I did not know that it was required, i thought it was handy not to reprogram
> the timer each time.
That is likely your problem. You can not assume that a decreasing
counter is all of a sudden a free-running counter with match register.
You have to find the processor datasheet and look at how its registers
must be programmed to run in one-shot mode, if at all possible.
Note that since linux 2.6.24, linux itself switched to one-shot mode,
because it allows high resolution software timers.
>>> #ifdef CONFIG_IPIPE
>>> void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
>>> {
>>> // No cascaded interrupt using the VIC
>>> }
>>> #endif /* CONFIG_IPIPE */
>>
>> You probably do not need to define this function if you #define
>> ipipe_mach_irq_mux_p to always be 0.
>>
>
> I do, to avoid an undefined reference.
If you #define ipipe_mach_irq_mux_p(irq) 0
The compilers optimizes away the function call, and there is no
undefined reference. At least with current compilers.
>
> Nevertheless, thank you very much for all this.
>
> When i developped the IPIPE code for this board i followed the
> HOWTO but it's quite vague so I mostly read what has been done
> with other boards and what has been done with linux for this board
> to implement it.
This HOWTO assumes that you understand what you are doing. No HOWTO
guide is a substitute for that unfortunately.
> Therefore, I'm clearly not aware of the interactions between Linux
> and Xenomai. I will definitely read the publications available on
> the Xenomai website.
Well, it is not all that complicated. When xenomai wants to program the
timer it calls ipipe_mach_set_dec, and when a timer interrupt happens,
ipipe_mach_acktimer is called, whether the timer is handled by Linux, or
it has been taken over by Xenomai.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 03:26 PM, aubin.rebil...@free.fr wrote: > Hello, > > I am trying to port Xenomai on the TS-7553 SBC from Technologic systems, > based on the ECONA CNS2132 (STAR8132) from Cavium networks (250 MHz arm922t). > A Linux kernel is available for this board, version 2.6.24.4, which is > running fine. > I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and I > implemented all the IPIPE code for the CNS2132 and everything is compiling > and booting fine. Note that the following page: http://www.openembedded.org/wiki/TS-7500 Proposes patches for linux 2.6.35, which is really, really, really more current than 2.6.24, and for which an I-pipe patch also exists. I mean, with 2.6.24, you may find bugs we do not even remember, because they were fixed such a long time ago. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 06:04 PM, aubin.rebil...@free.fr wrote:
> I'm not that experienced with initrd/initramfs and that was what the
> manufacturer recommended and i followed it so i can have support from
> them. But yes, at first, i think it can boot from another device.
Could you wrap your lines around 72 characters ? I have to do it for you
when I want to reply your posts.
>
>>
>>> I will look into the OABI and EABI settings then. I will also set
>>> up
>>> an NFS file system to mount debian from and see what is happening.
>>>
>>> Thank you Gilles for your reply. I will keep posting about my
>>> progresses.
>>
>> The issue may simply well be that your timer code does not work.
>> Could
>> you post the code for your port? That is, the code you added to get
>> it
>> work with the I-pipe patch.
>> Have you checked that linux timer is
>> still
>> ticking after Xenomai has been started?
>
> No, i did not check that the linux timer is still ticking.
> But i think it is because parts of the init script are executed and
> it is a shell script calling several sub-processes.
If subprocesses were an issue, nobody would be able to run xenomai.
> Nevertheless, I will put some printk in the linux timer handler to be sure.
>
>>
>> You can also try to boot with CONFIG_IPIPE but without
>> CONFIG_XENOMAI.
>
> I did, and it's booting just fine.
Ok. Then it is really likely the timer code which is broken. As the only
difference when xenomai is started is that linux timer is handled by
xenomai.
> void ipipe_mach_update_tsc(void)
> {
> union tsc_reg *local_tsc;
> unsigned long stamp;
> unsigned long flags;
>
> local_irq_save_hw(flags);
> local_tsc = &tsc[ipipe_processor_id()];
> stamp = str8100_read_timer_counter();
> if (stamp < local_tsc->low)
> local_tsc->high++;
> local_tsc->low = stamp;
> local_irq_restore_hw(flags);
> }
Since this code is called from the timer ack routine, the interrupts are
already off, so, you should not need local_irq_save_hw. On the other
hand, calling ipipe_mach_update_tsc in the timer ack routine adds to the
timer interrupt latency, so, should be done only if the time source is
wrapping really fast. As your timesource is a 32 bits timesource
(according to what you wrote in __ipipe_mach_get_tscinfo), it is
probably not wrapping fast, and you can call ipipe_mach_update_tsc from
linux timer interrupt.
>
> void __ipipe_mach_acktimer(void)
> {
> #ifndef CONFIG_VIC_INTERRUPT
> write_seqlock(&xtime_lock);
> str8100_clear_timer_interrupt_status(__ipipe_mach_timerint);
> write_sequnlock(&xtime_lock);
> #endif
>
> ipipe_mach_update_tsc();
> }
Wrong: you can not call write_seqlock from the acktimer routine. The
seqlock are reserved to usage by Linux. Also note that you should remove
the call to str8100_clear_timer_interrupt_status from Linux timer interrupt.
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> unsigned long flags;
>
> if (delay > 8)
> {
> local_irq_save_hw(flags);
> TIMER1_MATCH_VALUE1_REG = TIMER1_COUNTER_REG + delay;
> local_irq_restore_hw(flags);
> }
> else
> ipipe_trigger_irq(__ipipe_mach_timerint);
> }
ipipe_mach_set_dec is called with interrupts already off, so there is no
need to call local_irq_save_hw/local_irq_restore_hw.
Also, from the sources I could gather (snakeos-sdk), the hardware timer
for str8100 is programmed in periodic, auto-reload mode. Obviously, when
CONFIG_IPIPE is on, you have to change this to make the timer run in
one-shot mode, as required by Xenomai.
> #ifdef CONFIG_IPIPE
> void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
> {
> // No cascaded interrupt using the VIC
> }
> #endif /* CONFIG_IPIPE */
You probably do not need to define this function if you #define
ipipe_mach_irq_mux_p to always be 0.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 05:18 PM, aubin.rebil...@free.fr wrote: >> root=/dev/ram0 means that you are using an initrd, which has been >> deprecated for many years. > > I don't really have another option because the board does not support > U-BOOT (according to the manufacturer) and due to the specific > bootloader on the board I need an initrd : The bootloader only > initialises some hardware and loads the kernel image and the initrd > in memory before jumping on the kernel code. Then it uses the "linux > booting linux" technique to launch debian. I agree with you that it > is not the way of doing it today and i suspect the board manufacturer > to do so to sell a "fast booting board" because linux is booted in > less than 4 secs (of course for debian, it takes really more). They > actually made many things that seemed nice when i read the > description but when i wanted to develop with it I saw a lot of > really strange technique / behaviors (See the UART after for > example). There is no difference that I know of from the bootloader side whether booting with an initrd or an initramfs. Anyway, the only difference is that initramfs wastes more memory, it is not what is causing the problem. Either using an initrd or an initramfs wastes boot time, which is usually a scarse resource on embedded systems. Whatever the bootloader, I do not see what prevents you from passing different parameters than "root=/dev/ram0" to the kernel, which would be enough to boot from another device. But all this is unimportant. > I will look into the OABI and EABI settings then. I will also set up > an NFS file system to mount debian from and see what is happening. > > Thank you Gilles for your reply. I will keep posting about my > progresses. The issue may simply well be that your timer code does not work. Could you post the code for your port? That is, the code you added to get it work with the I-pipe patch. Have you checked that linux timer is still ticking after Xenomai has been started? You can also try to boot with CONFIG_IPIPE but without CONFIG_XENOMAI. Note that in case you do not know it, there is a guide for porting the I-pipe patch on new ARM platforms: http://www.xenomai.org/index.php/I-pipe:ArmPorting -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
On 05/10/2012 03:26 PM, aubin.rebil...@free.fr wrote: > Hello, > > I am trying to port Xenomai on the TS-7553 SBC from Technologic systems, based on the ECONA CNS2132 (STAR8132) from Cavium networks (250 MHz arm922t). > A Linux kernel is available for this board, version 2.6.24.4, which > is running fine. > I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and I implemented all the IPIPE code for the CNS2132 and everything is compiling and booting fine. > > Therefore, I applied the procedure to add the Xenomai nucleus > (version 2.5.6) to my IPIPE patched kernel: > >> prepare_kernel.sh --arch=arm --linux=../linux-2.6.24.4 make >> O=../build_root ts7500_defconfig make O=../build_root bzImage >> modules > > And everything is compiling fine (Just an error due to the non-existence of the phy_addr_t type in 2.6.24 kernel which is easy to fix). > > Also, This board does not support standard bootloaders (GRUB, > U-BOOT, …), it uses a specific one (TS-BOOTROM) developed by the board manufacturer. > The bootloader is quite simple, it initialises some hardware and > loads the kernel and initrd into ram before jumping on the kernel code. > Then after the kernel boot, an initialisation script in the initrd mounts a debian partition, executes pivot_root on it and launches the debian init program. > Due to this boot process to have a debian environment, I preferred > to have a fine running kernel with Xenomai before adding any user space support. > > My problem is that during the initialisation script in the initrd > the kernel hangs and only if Xenomai is enabled in the kernel configuration. Without Xenomai, the kernel is booting to debian correctly. > > Could it be because of the lack of user space support ? It does not > seem likely because if Xenomai crashes a log should be printed. Am I wrong ? > > Could it be because of the initrd ? Do I need a xenomai specific > initrd ? I did not see anything about initrd and xenomai anywhere so > I assume that the answers are ''no''. Am I wrong ? > > In my tests, I disabled the pivot_root call in the init script but > it does not change anything. > > Nevertheless, here is the boot log : > > [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 16256 > [0.00] Kernel command line: root=/dev/ram0 init=/linuxrc console=null > lpj=958464 > (...) > [0.56] Warning: unable to open an initial console. > > As you can see no problem is reported at all. > > Does anyone have an idea about what may go wrong ? root=/dev/ram0 means that you are using an initrd, which has been deprecated for many years. "unable to open an initial console" means that you will not get further output from the kernel. The kernel looks for the "/dev/null" file, but does not seem to find it. But even if it found it, it would probably stop outputting anything. So, I suggest you use whatever serial port is outputting these messages to see further output messages. Using console=ttyS0,115200 as a kernel parameter for instance. If the kernel mysteriously fails when running init, you have to pay attention at the kernel OABI/EABI settings. To know if the issue is really related to xenomai, try disabling CONFIG_IPIPE and CONFIG_XENOMAI starting from the failing kernel configuration, and see if booting still fails. If it still fails, then your issue is likely not related to Xenomai or the I-pipe patch. Another trick is to use an NFS mounted root filesystem, this way, by capturing the network traffic with wireshark, you can see in details what accesses the board does to the filesystem, and what fails. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Userland-compile error
On 05/08/2012 07:34 PM, Vikram Dhillon wrote: > On Tue, May 8, 2012 at 1:17 PM, Gilles Chanteperdrix > wrote: >> On 05/08/2012 06:23 PM, Vikram Dhillon wrote: >>> Hello Gilles, >>> >>> On Tue, May 8, 2012 at 11:32 AM, Gilles Chanteperdrix >>> wrote: >>>>> = >>>>> root@zion:/usr/src/xenomai-2.6.0/examples/posix# make >>>>> XENO=/usr/xenomai/ KSRC=/usr/src/linux-2.6.38.8-xenomai/ >>>>> --xeno-cflags is deprecated, use --skin=name --cflags instead >>>>> --xeno-ldflags is deprecated, use --skin=name --ldflags instead >>>>> gcc -DCONSUMER -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall >>>>> -Werror-implicit-function-declaration -pipe -D__XENO__ >>>>> -I/usr/xenomai/include/posix-Wl,@/usr/xenomai/lib/posix.wrappers >>>>> -L/usr/xenomai/lib -lpthread_rt -lxenomai -lpthread -lrt -Xlinker >>>>> -rpath -Xlinker /usr/xenomai/lib satch.c -o satch >>>>> /usr/bin/ld: /tmp/ccLV0g8I.o: undefined reference to symbol >>>>> 'pthread_cancel@@GLIBC_2.0' >>>>> /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO >>>>> /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker >>>>> command line >>>>> /lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid >>>>> operation >>>>> collect2: ld returned 1 exit status >>>>> make: *** [satch] Error 1 >>>>> = >>>> >>>> This is a strange error, are you sure you are not mixing a 64 bits >>>> toolchain with 32 bits libraries? Did xenomai compilation run correctly >>>> otherwise? Do xenomai tests run, such as latency for instance? >>>> >>> >>> >>> Yes, the compile and latency tests actually work just fine, I can >>> execute them, the error occurs when I try to compile a program from >>> the examples or something that I wrote. Don't worry about the second >>> error, that was just to demonstrate that after removing lpthread from >>> compile switches, the program compiles. >> >> You do not answer all my questions. What machine are you running? Is it >> an x86_64 or a 32 bits machine? >> >> I'm using Ubuntu 12.04 if that >>> provides any help, the debian package xeno-config also gives that >>> deprecated error so that may just be a problem with the debian >>> package. >> >> If you install xenomai from sources, you should not install debian >> package. You will have conflict between the two. >> >> -- >>Gilles. > > I have a 32-bit machine. Even after removing the debian package for > xeno-config, I have the same error. Things you can try: - try and compile a simple example not using xenomai, calling pthread_cancel and linking it with -lpthread, passing -Wl,-t on gcc command line to see what libpthread.so is used. - when you compile xenomai, look at how for instance cyclictest is compiled, and see if the flags used to compile your examples are the same. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Userland-compile error
On 05/08/2012 07:34 PM, Vikram Dhillon wrote: > On Tue, May 8, 2012 at 1:17 PM, Gilles Chanteperdrix > wrote: >> On 05/08/2012 06:23 PM, Vikram Dhillon wrote: >>> Hello Gilles, >>> >>> On Tue, May 8, 2012 at 11:32 AM, Gilles Chanteperdrix >>> wrote: >>>>> = >>>>> root@zion:/usr/src/xenomai-2.6.0/examples/posix# make >>>>> XENO=/usr/xenomai/ KSRC=/usr/src/linux-2.6.38.8-xenomai/ >>>>> --xeno-cflags is deprecated, use --skin=name --cflags instead >>>>> --xeno-ldflags is deprecated, use --skin=name --ldflags instead >>>>> gcc -DCONSUMER -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall >>>>> -Werror-implicit-function-declaration -pipe -D__XENO__ >>>>> -I/usr/xenomai/include/posix-Wl,@/usr/xenomai/lib/posix.wrappers >>>>> -L/usr/xenomai/lib -lpthread_rt -lxenomai -lpthread -lrt -Xlinker >>>>> -rpath -Xlinker /usr/xenomai/lib satch.c -o satch >>>>> /usr/bin/ld: /tmp/ccLV0g8I.o: undefined reference to symbol >>>>> 'pthread_cancel@@GLIBC_2.0' >>>>> /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO >>>>> /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker >>>>> command line >>>>> /lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid >>>>> operation >>>>> collect2: ld returned 1 exit status >>>>> make: *** [satch] Error 1 >>>>> = >>>> >>>> This is a strange error, are you sure you are not mixing a 64 bits >>>> toolchain with 32 bits libraries? Did xenomai compilation run correctly >>>> otherwise? Do xenomai tests run, such as latency for instance? >>>> >>> >>> >>> Yes, the compile and latency tests actually work just fine, I can >>> execute them, the error occurs when I try to compile a program from >>> the examples or something that I wrote. Don't worry about the second >>> error, that was just to demonstrate that after removing lpthread from >>> compile switches, the program compiles. >> >> You do not answer all my questions. What machine are you running? Is it >> an x86_64 or a 32 bits machine? >> >> I'm using Ubuntu 12.04 if that >>> provides any help, the debian package xeno-config also gives that >>> deprecated error so that may just be a problem with the debian >>> package. >> >> If you install xenomai from sources, you should not install debian >> package. You will have conflict between the two. >> >> -- >>Gilles. > > I have a 32-bit machine. Even after removing the debian package for > xeno-config, I have the same error. You should remove all xenomai debian packages. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Userland-compile error
On 05/08/2012 06:23 PM, Vikram Dhillon wrote: > Hello Gilles, > > On Tue, May 8, 2012 at 11:32 AM, Gilles Chanteperdrix > wrote: >>> = >>> root@zion:/usr/src/xenomai-2.6.0/examples/posix# make >>> XENO=/usr/xenomai/ KSRC=/usr/src/linux-2.6.38.8-xenomai/ >>> --xeno-cflags is deprecated, use --skin=name --cflags instead >>> --xeno-ldflags is deprecated, use --skin=name --ldflags instead >>> gcc -DCONSUMER -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall >>> -Werror-implicit-function-declaration -pipe -D__XENO__ >>> -I/usr/xenomai/include/posix-Wl,@/usr/xenomai/lib/posix.wrappers >>> -L/usr/xenomai/lib -lpthread_rt -lxenomai -lpthread -lrt -Xlinker >>> -rpath -Xlinker /usr/xenomai/lib satch.c -o satch >>> /usr/bin/ld: /tmp/ccLV0g8I.o: undefined reference to symbol >>> 'pthread_cancel@@GLIBC_2.0' >>> /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO >>> /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker >>> command line >>> /lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid >>> operation >>> collect2: ld returned 1 exit status >>> make: *** [satch] Error 1 >>> = >> >> This is a strange error, are you sure you are not mixing a 64 bits >> toolchain with 32 bits libraries? Did xenomai compilation run correctly >> otherwise? Do xenomai tests run, such as latency for instance? >> > > > Yes, the compile and latency tests actually work just fine, I can > execute them, the error occurs when I try to compile a program from > the examples or something that I wrote. Don't worry about the second > error, that was just to demonstrate that after removing lpthread from > compile switches, the program compiles. You do not answer all my questions. What machine are you running? Is it an x86_64 or a 32 bits machine? I'm using Ubuntu 12.04 if that > provides any help, the debian package xeno-config also gives that > deprecated error so that may just be a problem with the debian > package. If you install xenomai from sources, you should not install debian package. You will have conflict between the two. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Userland-compile error
On 05/08/2012 05:13 AM, Vikram Dhillon wrote: > Hi all, > > I recently compiled and installed a xenomai patched kernel but I am > currently having some issues compiling sample code that came with the > xenomai kernel. So here's what is happening: > > = > root@zion:/usr/src/xenomai-2.6.0/examples/posix# make > XENO=/usr/xenomai/ KSRC=/usr/src/linux-2.6.38.8-xenomai/ > --xeno-cflags is deprecated, use --skin=name --cflags instead > --xeno-ldflags is deprecated, use --skin=name --ldflags instead > gcc -DCONSUMER -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall > -Werror-implicit-function-declaration -pipe -D__XENO__ > -I/usr/xenomai/include/posix-Wl,@/usr/xenomai/lib/posix.wrappers > -L/usr/xenomai/lib -lpthread_rt -lxenomai -lpthread -lrt -Xlinker > -rpath -Xlinker /usr/xenomai/lib satch.c -o satch > /usr/bin/ld: /tmp/ccLV0g8I.o: undefined reference to symbol > 'pthread_cancel@@GLIBC_2.0' > /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO > /lib/i386-linux-gnu/libpthread.so.0 so try adding it to the linker > command line > /lib/i386-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make: *** [satch] Error 1 > = This is a strange error, are you sure you are not mixing a 64 bits toolchain with 32 bits libraries? Did xenomai compilation run correctly otherwise? Do xenomai tests run, such as latency for instance? > > > Linker issue here, the program satch in posix directory won't compile, > first change in the posix makefile: > = > CFLAGS=-DCONSUMER $(shell $(XENOCONFIG) --skin=posix --cflags) $(APP_CFLAGS) > LDFLAGS=$(shell $(XENOCONFIG) --skin=posix --ldflags) $(APP_LDFLAGS) > = > > > Then, the program still doesn't compile so I actually had to remove > the lpthread switch in compiling: > = > vikram@zion:/usr/src/xenomai-2.6.0/examples/posix$ gcc -DCONSUMER > -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall > -Werror-implicit-function-declaration -pipe -D__XENO__ > -I/usr/xenomai/include/posix -Wl,@/usr/xenomai/lib/posix.wrappers > -L/usr/xenomai/lib -lpthread_rt -lxenomai -lrt -Xlinker -rpath > -Xlinker /usr/xenomai/lib satch.c -o satch > vikram@zion:/usr/src/xenomai-2.6.0/examples/posix$ ls > Makefile Makefile~ README satch satch.c > vikram@zion:/usr/src/xenomai-2.6.0/examples/posix$ ./satch > Xenomai: binding failed: Operation not permitted. > = > > Can anyone tell me what is causing the issue here? Thanks! This one usually means that you are not running the example as root user. > > - Vikram > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help > -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Debugging oops in xnheap_init
On 05/08/2012 02:59 AM, Doug Brunner wrote:
> I just got an oops from running one of my POSIX skin RT applications:
>
> [183168.735823] BUG: unable to handle kernel paging request at 00700bf5
> [183168.737436] IP: [] xnheap_init+0x1cf/0x210
> [183168.738604] *pde =
> [183168.739406] Oops: 0002 [#1] PREEMPT
> [183168.740173] last sysfs file: /sys/devices/virtual/bdi/0:19/uevent
> [183168.740173] Modules linked in: e1000 xeno_rtipc lxfb cfbcopyarea
> cfbimgblt cfbfillrect binfmt_misc psmouse usbhid serio_raw hid ata_piix
> [last unloaded: e1000]
> [183168.740173]
> [183168.740173] Pid: 2557, comm: eve_dal Not tainted 2.6.37 #1 /Bochs
> [183168.740173] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
> [183168.740173] EIP is at xnheap_init+0x1cf/0x210
> [183168.740173] EAX: 00700bf1 EBX: eed0e210 ECX: eed0e730 EDX: eed0e2fc
> [183168.740173] ESI: EDI: EBP: eed27da4 ESP: eed27d7c
> [183168.740173] DS: 007b ES: 007b FS: GS: 0033 SS: 0068
> [183168.740173] Process eve_dal (pid: 2557, ti=eed26000
> task=f5773280 task.ti=eed26000)
> [183168.740173] I-pipe domain Linux
> [183168.740173] Stack:
> [183168.740173] eed0e304 0030 c157d4a9 eed0e210 eed0e2fc
> eed0e2fc 003e
> [183168.740173] f85ea000 eed0e210 eed27dc8 c10c0c44 1000
> f85aa000 0004
> [183168.740173] eed0e200 fff4 eed0e210 eed27df0 c10cf198
> eed27de4 c1058b86 eed27f20
> [183168.740173] Call Trace:
> [183168.740173] [] ? xnheap_init_mapped+0xd4/0x210
> [183168.740173] [] ? xnshadow_sys_event+0x68/0x210
> [183168.740173] [] ? commit_creds+0xe6/0x190
> [183168.740173] [] ? xnshadow_sys_bind+0x293/0x420
> [183168.740173] [] ? __d_lookup+0x12e/0x160
> [183168.740173] [] ? dput+0x66/0x1b0
> [183168.740173] [] ? path_to_nameidata+0x1e/0x50
> [183168.740173] [] ? link_path_walk+0x422/0x7c0
> [183168.740173] [] ? path_put+0x25/0x30
> [183168.740173] [] ? __ipipe_restore_root+0x1d/0x30
> [183168.740173] [] ? kmem_cache_free+0xa7/0x100
> [183168.740173] [] ? putname+0x2a/0x40
> [183168.740173] [] ? user_path_at+0x4a/0x80
> [183168.740173] [] ? losyscall_event+0xad/0x200
> [183168.740173] [] ? __ipipe_dispatch_event+0xb5/0x170
> [183168.740173] [] ? losyscall_event+0x0/0x200
> [183168.740173] [] ? __ipipe_syscall_root+0x45/0xd0
> [183168.740173] [] ? system_call+0x2d/0x53
> [183168.740173] Code: 24 e8 a6 cc 19 00 fa 8b 0d 28 36 61 c1 0f ba
> 2d c0 1b 61 c1 00 19 f6 8b 55 e8 83 e6 01 89 8b f0 00 00 00 8b 01 89 83
> ec 00 00 00<89> 50 04 31 c0 89 11 8b 15 c0 1b 61 c1 83 05 2c 36 61 c1 01 83
> [183168.740173] EIP: [] xnheap_init+0x1cf/0x210 SS:ESP
> 0068:eed27d7c
> [183168.740173] CR2: 00700bf5
>
> As you can see, this happened with kernel 2.6.37, and I built it with
> Xenomai 2.6.0. The offending instruction was at xnheap_init + 463:
>
> 0xc10c090b: mov-0x18(%ebp),%edx
> 0xc10c090e: and$0x1,%esi
> 0xc10c0911: mov%ecx,0xf0(%ebx)
> 0xc10c0917: mov(%ecx),%eax
> 0xc10c0919: mov%eax,0xec(%ebx)
> 0xc10c091f: mov%edx,0x4(%eax)
> 0xc10c0922: xor%eax,%eax
> 0xc10c0924: mov%edx,(%ecx)
> 0xc10c0926: mov0xc1611bc0,%edx
> 0xc10c092c: addl $0x1,0xc161362c
> 0xc10c0933: addl $0x1,0xc17c83e4
>
> This corresponds to ath(xnholder_t *, xnholder_t *) in
> include/xenomai/nucleus/queue.h, line 48:
>
> 43static inline void ath(xnholder_t *head, xnholder_t *holder)
> 44{
> 45/* Inserts the new element right after the heading one
> */
> 46holder->last = head;
> 47holder->next = head->next;
> 48holder->next->last = holder;
> 49head->next = holder;
> 50}
>
> It's apparently the call to appendq() at
> kernel/xenomai/nucleus/heap.c:332 that does this, with a junk pointer
> dereference. So, heap->stat_link.next is not valid at the time of this
> call, yet it's initialized by the call to inith() on line 319. I don't
> know what would have changed that, unless it's a bad pointer elsewhere
> that caused overwriting of this data. Any ideas where to go from here?
>
If the bug is reproducible, two things you can try:
- enable CONFIG_XENO_OPT_DEBUG_QUEUES
- enable the I-pipe tracer and panic freezes, you should get a trace
when the bug happens.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms
On 04/26/2012 12:39 PM, Philippe Gerum wrote: > On 04/12/2012 05:57 PM, Philippe Gerum wrote: >> On 04/12/2012 05:45 PM, Michael Pustylnik wrote: >>> The code masking the interrupt in IPIC (call for >>> ipipe_pre_cascade_noeoi()) initially showed up in the patch you >>> recommended (see your email attached). >>> >>> Later on it was integrated in Xenomai commit >>> "9a5e42df8bccc59620c08caeb4b9fe92dbf94a1b". >>> >>> As shown in the trail below, it keeps interrupts all the time until the >>> scheduler returns, thus breaking real-time responsiveness. >>> >>> A solution to this is probably to remove calling >>> ipipe_pre_cascade_noeoi() and let the cascading handler mask the >>> interrupt. Am I missing something? Do you think it is safe to use this >>> solution? >> >> No, as interrupts could be re-enabled before invoking the handler, you >> would get an IRQ storm. >> >> The solution is to rework the cascaded IRQ handling in the generic >> pipeline core, so that all decoded IRQs are acked/masked, then the >> multiplex IRQ unmasked, then all the decoded IRQ handlers fired when >> syncing the relevant pipeline stage. >> >> A fix for this will follow when enough testing will have been done on >> arm and ppc, to check whether that logic does not raise other issue. >> > > This is the patch series fixing the issue in the newest pipeline "core" > implementation, currently for kernel 3.2. Something along these lines would > work for > earlier kernels as well. > > http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=0a9a7b4e4ce9f4196a574471ad58f4389820c438 > http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=f2ca3c2baf58bf43f4c00fb05b91b16da9fd77f2 > http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=a4b909ccf80c5afa132aa7a9ccf0022cb8a6e6f2 > http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=b47bc773ff07ce886aaf490921ac59e98ed9575a I have done a backport of this change for a pre ipipe-core (ARM) I-pipe. The diff is here: http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=81bfc05c4716b76e79f5e486baf4c52015a3b92c;hp=7d31a77f62acb57eb83409c8f514d0f2dacf7fe5 -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.
On 04/25/2012 12:28 PM, Frederik Bayart wrote: > Hallo, > > We are switching from linux 2.6.30.8 with xenomai 2.4.10 to linux 2.6.38.8 > with xenomai 2.6.0 (stable release) on debian lenny. If you are concerned with security (which seems to be the case since you want to avoid running real-time programs as root): - you should note that debian lenny is no longer maintained for security update (since february actually), so, an upgrade to squeeze is recommended. Chances are that it is possible to become root when running as an ordinary user on a lenny system without too much trouble. - it is entirely possible that it is possible to become root abusing xenomai interfaces, xenomai interfaces are not implemented with security in mind. > > In our daemon (with real pid root), we are setting effective pid and gid to > 1000 and are calling popen to execute a shell command. > The popen succeeds, but when I try to read the output with fgets, I get the > error : > > Xenomai: binding failed: Operation not permitted. > > I verified that the effective user for both commands is the same. > > This was working on xenomai 2.4.10 > I added the user with pid 1000 already to the xenomai group but this > doesn't work. That is not enough, you should also do what is said here: http://www.xenomai.org/index.php/Non-root_RT -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.
On 04/25/2012 04:00 PM, Frederik Bayart wrote: > Migration to squeeze is the next step planned. > In attachment a small test program to reproduce the problem and a makefile. > The program is running as root but we want e.g. the command executed > by the popen command running as user 'triphase' > > if you run the program and press CTRL-C, you get Xenomai: binding > failed on 2.6.0 and output (of part of the output) from 'ls' on > 2.4.10. I am afraid you will have to add the triphase user to the xenomai group and pass the xeno_nucleus.xenomai_gid option to the kernel. Or else rewrite the vfork + exec yourself dropping root privileges after the fork. The reason is that the native api assumes that if you fork in a xenomai program, chances are you will want to use the native api in the child program. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.
On 04/25/2012 12:28 PM, Frederik Bayart wrote: > Hallo, > > We are switching from linux 2.6.30.8 with xenomai 2.4.10 to linux 2.6.38.8 > with xenomai 2.6.0 (stable release) on debian lenny. > > In our daemon (with real pid root), we are setting effective pid and gid to > 1000 and are calling popen to execute a shell command. > The popen succeeds, but when I try to read the output with fgets, I get the > error : > > Xenomai: binding failed: Operation not permitted. > > I verified that the effective user for both commands is the same. > > This was working on xenomai 2.4.10 > I added the user with pid 1000 already to the xenomai group but this > doesn't work. > > Does anyone know what the problem could be ? Quite frankly, the description is a bit vague. For instance, the "binding failed: operation not permitted" message should happens as a result of starting a program, or as a result of popen, not when calling fgets. Anyway, please try and reduce the bug to a simple and minimal test case which still causes the bug, and post the code here. A piece of code is worth a thousand words, and this exercise may help you identify which piece of the puzzle causes the bug. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] libnative and libxenomai dependy problem
On 04/25/2012 12:05 PM, Willy Lambert wrote: > 2012/4/23 Gilles Chanteperdrix : >> On 04/23/2012 03:57 AM, Willy Lambert wrote: >>> 2012/4/23 Gilles Chanteperdrix : >>>> On 04/23/2012 01:57 AM, Willy Lambert wrote: >>>>> Hi, >>>>> >>>>> I just run into the same kind of problem of a one year old discussion : >>>>> http://www.mail-archive.com/xenomai-help@gna.org/msg12669.html >>>>> >>>>> having such kind of errors : >>>>> /usr/lib/libnative.so.3: undefined symbol: xeno_current_mode_key >>>>> I have a xenomai 2.6.0 recompiled from sources with the --dl-open >>>>> option enabled. >>>>> root@beta(10.0):~# cat /proc/xenomai/version >>>>> 2.6.0 >>>>> >>>>> >>>>> I re-post something because I'm not sure it is up to date and as I >>>>> have the next version I am suprised the problem still arises >>>>> >>>>> I have 2 question : >>>>> _ did I missconfigured something in my compiller flags or linking ? >>>>> _ are the solutions of last thread still up to date ? >>>>> >>>> >>>> You need to dlopen libxenomai in order for dlopen(libnative) to succeed. >>>> >>>> -- >>>>Gilles. >>> >>> In fact I never called dlopen(libnative) myself. It is done in a >>> library to which I am linked. Do I have a to dlopen it in my personnal >>> code ? >>> >> you have to manage for dlopen(libxenomai) to be called before >> dlopen(libnative), and with the RTDL_GLOBAL flag so that libnative will >> find the symbols defined by libxenomai. >> >> -- >>Gilles. > > Thanks for support. In fact I am not using dlopen directly (dynamic > linking) dynamic linking and dlopen are two different things. When you use dynamic linking, dlopen is not used underneath. dlopen is part of the libdl library, which you do not even need for dynamic linked appications. > but in ordering the linking I got it working (without having > to set the flag which might be set underneath). > I'm quite surprised thougth that is is a "soft" dependency. Is it my > bad not having used --xeno-config directly ? (I use a shortcut because > all the stuff is under CMake and I am not an expert with it). Yes, you should use xeno-config. The reason why libxenomai is not made a dependency of libnative is that the straight-forward solution to do this with the version of libtool we use breaks badly when cross-compiling. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rtcan I/O hang bug with /proc/rtcan/rtcan0/registers
On 04/24/2012 08:47 PM, Andrew Tannenbaum wrote: > I'm running > > Linux 2.6.38.8 > Xenomai 2.6.0 > Atom N270 CPU > > I'm talking to CAN with a PEAK PCI SJA1000 CAN adapter. > > I have a control loop running at 200 Hz, and I use it to drive a motor > and read an encoder using rtcan. My code is based on the > rtcansend/rtcanrecv examples. > > I found a bug where my control loop was hanging, and I've isolated the > problem so that it may be reproduced with Xenomai supplied tools, > without using my own code. > > The problem is: > > When I have a loop that is sending CAN packets, if I read > /proc/rtcan/rtcan0/registers at the same time, it causes the loop to > hang. The hang is in rt_dev_sendto. > > To reproduce: > > Configure the CAN controller > > $ rtcanconfig rtcan0 --baudrate=100 start > > Send packets, in this case, SYNC messages at 1000 Hz > with tty output 1 Hz. > > $ rtcansend rtcan0 -i 0x80 -p 1000 -l 100 > > It will print CAN SYNC (0x80) messages: > > <0x080> [0] > <0x080> [0] > ... > > In another window, read rtcan0/registers in a loop (10 Hz): > > $ while :; do cat /proc/rtcan/rtcan0/registers; sleep .1; done Hi Andrew, I am probably not the one which will answer your question, because I know nothing about CAN hardware. What I know however is that some hardware registers, when read, have side effects. For instance reading an interrupt status may deassert the hardware interrupt. The code for /proc/rtcan/rtcan0/registers is compiled if CONFIG_XENO_DRIVERS_CAN_DEBUG is #defined. This would seem to indicate that perhaps some registers have side effects, and so this /proc file more a debug tool than something which should be used on a regular basis. Regards. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Adeos patch for x86_64
On 04/23/2012 12:08 PM, Anisha Kaul wrote: > Greetings, > > I have some confusion - The Adeos patches support x86 architecture. > They haven't mentioned anything explicitly about x86_64 architecture. > Can I assume that these x86 patches of Adeos (with Xenomai) will run > properly on a 64 bit machine? > > http://download.gna.org/adeos/patches/v2.6/ Architectures for the adeos patch have the same meaning as for the Linux kernel. So your question boils down to: "does Linux x86 architecture support x86_64"? Googling for this question leads to this article: http://lwn.net/Articles/243704/ -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:51 PM, Gilles Chanteperdrix wrote: > On 04/23/2012 02:35 PM, Andrey Nechypurenko wrote: >>>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one >>>> element in this array >>>> "pwm-task", >>>> pwm_task_proc, >>>> 0, >>>> RTDM_TASK_HIGHEST_PRIORITY, >>>> 2000); // 20ms period >>> >>> Do not use a thread, use a timer. >> >> So you mean instead of starting periodic task with rtdm_task_init() it >> is better use timer functions to trigger pin toggling piece of code? >> Could you please elaborate on it a little? I thought that >> rtdm_task_sleep() and rtdm_task_wait_period() are using timers >> internally to wake up the thread at the right moment. Is not they? > > Yes, but once the timer is woken up, a context switch is needed to wake > up the thread, this adds time. > >> >> Is not it a kind of work-around you suggesting? If there are some >> problems which led to the imprecise timing of the sleep/wait functions >> mentioned above, then, if technically possible, it would be better to >> fix them instead of working around this behavior. > > No, the time it takes to switch context between threads is unavoidable. > So, if you want to avoid it, you have to use a timer (rtdm_timer_init), > note that it is really common in RTOS interfaces to offer a timer API, > this is not a workaround at all. > > The other alternative I describe in my last mail, that is, using a > dedicated hardware timer with its own irq handler, is a bit more of a > workaround, but still not uncommon in the RTOS world. > Another trick, which this time really is a workaround is to program the timers to wake up a little bit early, and spin to wait for the exact time wanted. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:35 PM, Andrey Nechypurenko wrote: >>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one >>> element in this array >>> "pwm-task", >>> pwm_task_proc, >>> 0, >>> RTDM_TASK_HIGHEST_PRIORITY, >>> 2000); // 20ms period >> >> Do not use a thread, use a timer. > > So you mean instead of starting periodic task with rtdm_task_init() it > is better use timer functions to trigger pin toggling piece of code? > Could you please elaborate on it a little? I thought that > rtdm_task_sleep() and rtdm_task_wait_period() are using timers > internally to wake up the thread at the right moment. Is not they? Yes, but once the timer is woken up, a context switch is needed to wake up the thread, this adds time. > > Is not it a kind of work-around you suggesting? If there are some > problems which led to the imprecise timing of the sleep/wait functions > mentioned above, then, if technically possible, it would be better to > fix them instead of working around this behavior. No, the time it takes to switch context between threads is unavoidable. So, if you want to avoid it, you have to use a timer (rtdm_timer_init), note that it is really common in RTOS interfaces to offer a timer API, this is not a workaround at all. The other alternative I describe in my last mail, that is, using a dedicated hardware timer with its own irq handler, is a bit more of a workaround, but still not uncommon in the RTOS world. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 02:27 PM, Gilles Chanteperdrix wrote:
> On 04/23/2012 01:56 PM, Andrey Nechypurenko wrote:
>> Hi Folks,
>>
>> Following my tests with PWM generation using GPIO in user space [1],
>> I've made the RTDM module [2] to further reduce the jitter. As a
>> result, jitter was improved, but still under heavy system load the
>> servo motor I am trying to control starts shaking. Now, I fill stuck
>> and hope to get some help here.
>>
>> At one hand, I can not imaging that 800MHz ARM (BeagleBoard xM) could
>> not manage to generate 20mS PWMs from RTDM driver precise enough to
>> avoid sporadic servo movements. So probably I am doing something
>> wrong. On the other hand, I do not see where the possible mistake can
>> happen and hope that someone experienced in with Xenomai could help.
>>
>> There is an article about observed behavior [3] with more details, but
>> the core problem, I guess, boils down to the following code fragment:
>>
>> void pwm_task_proc(void *arg) {
>> const int which = (int)arg;
>>
>> // Toggling GPIO pin
>> for(;;) {
>> //set_data_out has offset 0x94 . Set gpio pin to 1 (up)
>> iowrite32(0x4000, gpio + 0x6094);
>>
>> // wait requested pulse width time (duty)
>> if(0 != rtdm_task_sleep(up_period[which]))
>> rtdm_printk("PWM: rtdm_task_sleep() returns error\n");
>>
>> //clear_data_out has offset 0x90 . Set gpio pin to 0 (down)
>> iowrite32(0x4000, gpio + 0x6090);
>>
>> // wait until the next pulse should start (20mS interval)
>> if(0 != rtdm_task_wait_period())
>> rtdm_printk("PWM: rtdm_task_wait_period() returns error\n");
>> }
>>
>> This is the function running as a periodic task started with the following
>> call:
>>
>> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
>> element in this array
>> "pwm-task",
>> pwm_task_proc,
>> 0,
>> RTDM_TASK_HIGHEST_PRIORITY,
>> 2000); // 20ms period
>
> Do not use a thread, use a timer.
>
So, rtdm_timer_init
If this still has too much overhead, you can use the OMAP3 API do
dedicate a GPTIMER to this task, and simply register an irq for the
GPTIMER which does the job (as opposed to a timer created with
rtdm_timer_init).
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Jitter while generating PWMs with GPIO from RTDM driver
On 04/23/2012 01:56 PM, Andrey Nechypurenko wrote:
> Hi Folks,
>
> Following my tests with PWM generation using GPIO in user space [1],
> I've made the RTDM module [2] to further reduce the jitter. As a
> result, jitter was improved, but still under heavy system load the
> servo motor I am trying to control starts shaking. Now, I fill stuck
> and hope to get some help here.
>
> At one hand, I can not imaging that 800MHz ARM (BeagleBoard xM) could
> not manage to generate 20mS PWMs from RTDM driver precise enough to
> avoid sporadic servo movements. So probably I am doing something
> wrong. On the other hand, I do not see where the possible mistake can
> happen and hope that someone experienced in with Xenomai could help.
>
> There is an article about observed behavior [3] with more details, but
> the core problem, I guess, boils down to the following code fragment:
>
> void pwm_task_proc(void *arg) {
> const int which = (int)arg;
>
> // Toggling GPIO pin
> for(;;) {
> //set_data_out has offset 0x94 . Set gpio pin to 1 (up)
> iowrite32(0x4000, gpio + 0x6094);
>
> // wait requested pulse width time (duty)
> if(0 != rtdm_task_sleep(up_period[which]))
> rtdm_printk("PWM: rtdm_task_sleep() returns error\n");
>
> //clear_data_out has offset 0x90 . Set gpio pin to 0 (down)
> iowrite32(0x4000, gpio + 0x6090);
>
> // wait until the next pulse should start (20mS interval)
> if(0 != rtdm_task_wait_period())
> rtdm_printk("PWM: rtdm_task_wait_period() returns error\n");
> }
>
> This is the function running as a periodic task started with the following
> call:
>
> retval = rtdm_task_init(&pwm_task[i], // there is currently only one
> element in this array
> "pwm-task",
> pwm_task_proc,
> 0,
> RTDM_TASK_HIGHEST_PRIORITY,
> 2000); // 20ms period
Do not use a thread, use a timer.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 01:05 PM, Willy Lambert wrote: > 2012/4/23 Philippe Gerum : >> On 04/23/2012 03:51 AM, Willy Lambert wrote: >>> >>> Hi, >>> >>> I have a message in dmesg about SMI workaround : >>> Xenomai: SMI-enabled chipset found, but SMI workaround disabled >>> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter >>> high interrupt latencies! >>> >>> My kernel should be configured properly and following the "In case of >>> high latencies" of >>> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did >>> some tests. >>> >>> Latency test is here (if it is us it should be ok no ?): >>> >> >> Yes, this looks ok, but you need to run this test longer, and try a few >> usual suspects like plugging in/out USB devices while doing so (e.g. mouse, >> netdev). >> >> The point of this message is to tell you that your chipset is known to >> create latency issues in some cases (like most Intel chipset these days), >> but you did not enable the Xenomai code which works around such issues by >> shutting down problematic SMI sources. That may be right, or even required >> to leave all the SMI sources enabled (e.g. thermal control), but this might >> also lead to unacceptable latency spots. YMMV. >> >> This is basically a heads up message. >> >> -- >> Philippe. > > Ok, thanks for answers. > > I did the test again , playing with usb and using the stress program > to generate CPU load. The max latency for now is 15us in 4 mins. So I > think it will be ok to keep SMI on for the time. Please let me know if > this test is still stoo short. > ^C---|---|---|---||--|- > RTS| 0.604| 2.332| 15.161| 0| 0|00:03:59/00:03:59 > > Do you know by chance where I can found infos about SMI sources ? I > suppose it is not in the ICH8M docs, it would be in my board doc ? Or > have I a soft way to do this check so that I don't have to spend time > with my vendor which will obviously have hard time to answer that ? The list of potential SMI sources IS in the ICH8M docs. Whether these sources are used by your board essentially depends on the BIOS implementation (an SMI traps into BIOS code). So the theoretical answer to this question is to disassemble the the BIOS blob. The practical answer is to run latency during a few hours, under stress using all the hardware which will be used in your target project (network card, disk I/Os, USB key I/Os, etc...). If an SMI is used but latencies remain acceptable with regard to your goals, no reason to bother. If you find unacceptable latencies, see the TROUBLESHOOTING guide, to see how to enable SMI workaround. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Smi workaround on ICH8M
On 04/23/2012 03:51 AM, Willy Lambert wrote:
> Hi,
>
> I have a message in dmesg about SMI workaround :
> Xenomai: SMI-enabled chipset found, but SMI workaround disabled
> (check CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter
> high interrupt latencies!
>
> My kernel should be configured properly and following the "In case of
> high latencies" of
> http://www.xenomai.org/index.php/Configuring_x86_kernels thread, I did
> some tests.
>
> Latency test is here (if it is us it should be ok no ?):
>
> RTT| 00:00:22 (periodic user-mode task, 100 us period, priority 99)
> RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat
> worst
> RTD| 1.238| 1.365| 4.778| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.388| 5.292| 0| 0| 0.605|
> 9.414
> RTD| 0.847| 1.365| 6.113| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.363| 4.676| 0| 0| 0.605|
> 9.414
> RTD| 1.229| 1.365| 4.489| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.368| 4.194| 0| 0| 0.605|
> 9.414
> RTD| 1.231| 1.386| 5.625| 0| 0| 0.605|
> 9.414
> RTD| 0.681| 1.365| 6.020| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.365| 4.762| 0| 0| 0.605|
> 9.414
> RTD| 1.165| 1.366| 6.987| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.364| 5.453| 0| 0| 0.605|
> 9.414
> RTD| 1.093| 1.382| 5.567| 0| 0| 0.605|
> 9.414
> RTD| 0.629| 1.365| 6.437| 0| 0| 0.605|
> 9.414
> RTD| 1.236| 1.364| 4.584| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.366| 6.671| 0| 0| 0.605|
> 9.414
> RTD| 1.238| 1.372| 4.436| 0| 0| 0.605|
> 9.414
> RTD| 0.981| 1.384| 5.949| 0| 0| 0.605|
> 9.414
> RTD| 0.626| 1.363| 5.844| 0| 0| 0.605|
> 9.414
> RTD| 1.217| 1.364| 4.448| 0| 0| 0.605|
> 9.414
> RTD| 1.237| 1.365| 4.451| 0| 0| 0.605|
> 9.414
> RTD| 1.236| 1.368| 4.619| 0| 0| 0.605|
> 9.414
>
> So I did a lspci -nn | grep LPC which gives :
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC
> Interface Controller [8086:2815] (rev 04)
>
> It is adviced to edit the ksrc/arch/x86/smi.c file. Is it still up to
> date ? If yes could you help me to edit it ? I suppose it is this
> section :
> static struct pci_device_id rthal_smi_pci_tbl[] = {
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_10)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801E_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB2_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_5)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH10_1)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PCH_LPC_MIN+7)},
> {0,},
> };
>
> I suppose I should add a line, with something from : pci_ids.h, but
> it's not very clear to me which one to select.
If you see the messages, the ids for your chipset already are in the
table. If you want to enabled the SMI workaround, simply enable it in
the kernel configuration.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] libnative and libxenomai dependy problem
On 04/23/2012 03:57 AM, Willy Lambert wrote: > 2012/4/23 Gilles Chanteperdrix : >> On 04/23/2012 01:57 AM, Willy Lambert wrote: >>> Hi, >>> >>> I just run into the same kind of problem of a one year old discussion : >>> http://www.mail-archive.com/xenomai-help@gna.org/msg12669.html >>> >>> having such kind of errors : >>> /usr/lib/libnative.so.3: undefined symbol: xeno_current_mode_key >>> I have a xenomai 2.6.0 recompiled from sources with the --dl-open >>> option enabled. >>> root@beta(10.0):~# cat /proc/xenomai/version >>> 2.6.0 >>> >>> >>> I re-post something because I'm not sure it is up to date and as I >>> have the next version I am suprised the problem still arises >>> >>> I have 2 question : >>> _ did I missconfigured something in my compiller flags or linking ? >>> _ are the solutions of last thread still up to date ? >>> >> >> You need to dlopen libxenomai in order for dlopen(libnative) to succeed. >> >> -- >>Gilles. > > In fact I never called dlopen(libnative) myself. It is done in a > library to which I am linked. Do I have a to dlopen it in my personnal > code ? > you have to manage for dlopen(libxenomai) to be called before dlopen(libnative), and with the RTDL_GLOBAL flag so that libnative will find the symbols defined by libxenomai. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] libnative and libxenomai dependy problem
On 04/23/2012 01:57 AM, Willy Lambert wrote: > Hi, > > I just run into the same kind of problem of a one year old discussion : > http://www.mail-archive.com/xenomai-help@gna.org/msg12669.html > > having such kind of errors : > /usr/lib/libnative.so.3: undefined symbol: xeno_current_mode_key > I have a xenomai 2.6.0 recompiled from sources with the --dl-open > option enabled. > root@beta(10.0):~# cat /proc/xenomai/version > 2.6.0 > > > I re-post something because I'm not sure it is up to date and as I > have the next version I am suprised the problem still arises > > I have 2 question : > _ did I missconfigured something in my compiller flags or linking ? > _ are the solutions of last thread still up to date ? > You need to dlopen libxenomai in order for dlopen(libnative) to succeed. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] linux 2.6.11
On 04/22/2012 03:53 PM, Wolfgang Grandegger wrote: > On 04/22/2012 01:34 PM, Gilles Chanteperdrix wrote: >> On 04/22/2012 01:24 PM, Gilles Chanteperdrix wrote: >>> On 04/22/2012 11:10 AM, Wolfgang Grandegger wrote: >>>> But all this does not explain a factor of 3 with your driver. I doubt >>>> that it's due to a move from 2.6.29 -> 2.6.32. Try using ftrace to find >>>> out what's going on (if it's already available). >>> >>> Threaded interrupts were introduced around this time. And threaded >>> interrupts DO have a significant impact on latencies. > > Yes, but thread interrupts are normally not enabled/used by default. I'm > not speaking about CONFIG_PREEMPT_RT. Well, do we speak about latencies? > He just said "reading an ADC on an EP9312 ARM board has slowed by a > factor of three". I'm not even sure if it's related to Xenomai at all. > xenophile (&$#^?) , could you please be more precise. Yes, without answers to these questions, xenophile's post looks a lot like a troll attempt. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] linux 2.6.11
On 04/22/2012 01:24 PM, Gilles Chanteperdrix wrote: > On 04/22/2012 11:10 AM, Wolfgang Grandegger wrote: >> But all this does not explain a factor of 3 with your driver. I doubt >> that it's due to a move from 2.6.29 -> 2.6.32. Try using ftrace to find >> out what's going on (if it's already available). > > Threaded interrupts were introduced around this time. And threaded > interrupts DO have a significant impact on latencies. > But I agree: tracing with ftrace or the I-pipe tracer if using xenomai to see where the time is spent is the way to go. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] linux 2.6.11
On 04/22/2012 11:10 AM, Wolfgang Grandegger wrote: > But all this does not explain a factor of 3 with your driver. I doubt > that it's due to a move from 2.6.29 -> 2.6.32. Try using ftrace to find > out what's going on (if it's already available). Threaded interrupts were introduced around this time. And threaded interrupts DO have a significant impact on latencies. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] linux 2.6.11
On 04/22/2012 08:23 AM, xenophile wrote: > I'm interested in exploring RT on this hardware and part of the change > of kernel was to move to more recent kernel which has better support for > this board and to find a kernel that has been used RT with this type of > hardware so that I don't have to start from scratch. > > Yesterday I tested 2.6.33 and it was equally slow. I need to find out if > this is due to kernel version or gcc. (4.3.4) > > I need to resolve the cause of this factor of 2 or 3 slow down before I > get involved in xenomia patching so as to start from a sound base. Well, given the way xenomai works, we do not depend much on the linux performances. So, if you want to compare something, it should be the xenomai latency differences between the two kernel versions. Using linux performance to get an idea of xenomai performance does not really make any sense. To give you just an example, at some point around 2.6.30, the linux kernel introduced threaded interrupts, which greatly increase interrupt latencies. Xenomai does not use threaded interrupts, so it is essentially unaffected by the change. Of course there are some indirect effect such as the size of the kernel, which has an impact on I-cache and so on the latency. > Thanks, I was hoping to find some comments on which kernels are more > responsive. I'm sure there's good and bad since RT is not one of the > main priorities for kernel development, this may not be a case of the > most recent being the best. > > From a simple user experience circa 2.6.11 was hugely more responsive > than the more recent offerings. Maybe 2.6.13 or 2.6.14 are close enough > to be in the same league. > > I would have thought this sort of thing would have been thoroughly > investigated by RT people and would be documented. We run xenomai, so, what we investigate are xenomai performances. On a system running xenomai, the performance-sensitive job is done by xenomai, not by linux anyway. And we check between two releases that we do not get differences in performances. So, I am pretty sure that on at91rm9200 for instance (the platform I have which should be the closest to an EP9312), the xenomai user-space latency from 2.6.29 to 3.2.1 is around 220us. Besides, in terms of performance, the relation performance/version probably also depends on the platform which is running the kernel. So for instance, you may have found that 2.6.11 was good on x86, but maybe it sucked on ARM. Apart from that, as I already said, we provide you with: - the latest version of xenomai which should supports all past kernel versions - the tools to do the performance measurement. So, you have everything you need to do the comparison. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] linux 2.6.11
On 04/21/2012 10:12 PM, xenophile wrote: > Hi, > > I am trying to see why a trivial driver reading an ADC on an EP9312 ARM > board has slowed by a factor of three. Since I installed it under 2.6.29 > a couple fo years ago. > > It's looking like this is due to a kernel update I did in the mean time > to 2.6.32 If the kernel is patched with Xenomai, did you check that you have the same setting for FCSE ? Other than that, you can have an idea of how the time is spent in both cases using the I-pipe tracer. > Would there be any value in trying to rebuild a 2.6.11 based system for > realtime work ? xenomai comes with a latency test that you can run on any two configuration to compare their latencies. If you go on the adeos project download area: http://download.gna.org/adeos/patches/ You will find kernel patches for versions such as 2.6.13 or 2.6.14, they are supposed to work with xenomai latest stable release. You can even find patches for 2.4 kernels for i386 and ppc. Chances are however that these patches have bugs which have been fixed since then (after all, 2.6.11 is 7 years old). -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Can't use interrupt after adeos patch
On 04/18/2012 04:24 AM, hustgongchen wrote: > Hi everyone: > I use linux kernel 2.6.33 and xenomai 2.5.3 to build my rt-embedded > system based on S3c2440, > but i found I can't use interrupt after put the adeos patch to linux > kernel.The system crashes once > I insert a USB device to it or receive a ethernet packet(the net card i use > is CS8900). > Because even i didn't build xenomai into kernel , the system still > crashed once received a > hardware interrupt so i guess the problem is about adeos patch.Is there any > bug with > adeos-ipipe-2.6.33-arm-1.16-01.patch? Please try xenomai 2.6.0 and the patches it contains. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Understanding the output of hackbench when run together with xeno-test
On 04/18/2012 11:09 AM, Anisha Kaul wrote:
> On 18 April 2012 14:11, Gilles Chanteperdrix
> wrote:
>> Try: xeno-test -l "dohell -b
>> /home/anisha/Desktop/RealTime/downloadedPages/hackbench 14400"
>
> and that worked! I tried it with 2 seconds.
You will not obtain the worst case latencies by running the test for 2
seconds, you have to let xeno-test run at least a few hours.
>
> I realize now that the problem is in the "parameters" which I specify
> with hackbench:
>
> xeno-test -l "dohell -b
> /home/anisha/Desktop/RealTime/downloadedPages/hackbench -pipe 100
> process 100 2"
>
> The sub `dohell` command (with hackbench parameters) work well, but it
> doesn't work when attached with `xeno-test`. I remove the hackbench's
> parameters ("-pipe 100 process 100"), then it starts working.
>
> Thanks for your help, but what should I do if I want those parameters?
> Hardcoding them in the hackbench's code as a temporary solution? Or I
> am still missing a point?
As of now, the simplest way is to hardcode them in the dohell script.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Understanding the output of hackbench when run together with xeno-test
On 04/18/2012 09:25 AM, Anisha Kaul wrote: > On 17 April 2012 17:04, Gilles Chanteperdrix > wrote: >> Ok, it is not clear: but you need to pass a duration if you do not pass >> the patch to LTP, which means either the "-l path" or "seconds" argument >> is mandatory. > > Thanks for replying. I couldn't have made it out myself that the last > argument is compulsory. > The problem isn't solved yet, actually. > > I tried `dohell` separately with `hackbench` and `seconds` parameter > as follows (and it worked properly): Try: xeno-test -l "dohell -b /home/anisha/Desktop/RealTime/downloadedPages/hackbench 14400" -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Understanding the output of hackbench when run together with xeno-test
On 04/17/2012 01:30 PM, Gilles Chanteperdrix wrote: > On 04/17/2012 01:11 PM, Anisha Kaul wrote: >> Greetings, >> >> The hackbench command I issued is as follows: ___ >> >> /usr/xenomai/bin/xeno-test -l "dohell -b ./hackbench -pipe 100 process 100" > > You do not use dohell properly. The syntax for running dohell is > detailed below > >> /usr/xenomai/bin/dohell [ -b path ] [ -s server ] [ -p port ] [ -m >> mntpoint ] [ -l path | seconds ] >> >> Generate load, using an assorted set of commands and optionnaly: >> - hackbench if the path to the hackbench binary is specified with -b; >> - nc to send TCP data to "server" port "port" if -s is specified (if -p >> is not specified, the port 9, aka discard is used); >> - dd to write data under "mntpoint" if -m is specified. >> >> during the runtime of the LTP test if the path to the LTP installation >> directory is specifed with -l or during "seconds" seconds. > Ok, it is not clear: but you need to pass a duration if you do not pass the patch to LTP, which means either the "-l path" or "seconds" argument is mandatory. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Understanding the output of hackbench when run together with xeno-test
On 04/17/2012 01:11 PM, Anisha Kaul wrote: > Greetings, > > The hackbench command I issued is as follows: ___ > > /usr/xenomai/bin/xeno-test -l "dohell -b ./hackbench -pipe 100 process 100" You do not use dohell properly. The syntax for running dohell is detailed below > /usr/xenomai/bin/dohell [ -b path ] [ -s server ] [ -p port ] [ -m > mntpoint ] [ -l path | seconds ] > > Generate load, using an assorted set of commands and optionnaly: > - hackbench if the path to the hackbench binary is specified with -b; > - nc to send TCP data to "server" port "port" if -s is specified (if -p > is not specified, the port 9, aka discard is used); > - dd to write data under "mntpoint" if -m is specified. > > during the runtime of the LTP test if the path to the LTP installation > directory is specifed with -l or during "seconds" seconds. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Pandaboard, Xenomai and Wifi drivers
On 04/16/2012 02:44 PM, Robert wrote: > Hello, I have a pandaboard with Xenomai compilled with vanilla kernel > source 2.6.38-8, but with this kernel tree there is no wifi support > for panda. How and which kernel should I compile to remain a wifi > usability? I do not think this list is the right place to ask this question, what we can tell you however is the most recent kernel supported by xenomai. You can try xenomai-2.6 from the git repository which supports linux 3.0. xenomai-2.6 will support linux 3.2 soon, but we are not there yet. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 08:55 AM, Andrey Nechypurenko wrote: > Thank you very much Gilles for the explanations! > I think I understand the overall picture better now. > > Thank you, > Andrey. To summarize again: - the native API and posix API were made available in kernel-space at the beginning of the xenomai project as a mean to help porting applications from rtai and rtlinux to xenomai, they could also be used to write drivers, but it started to no longer make sense as soon as the RTDM API appeared; - they will both be gone in xenomai 3.0, only the RTDM API will be available in kernel-space. native and posix will still be available in user-space of course. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 01:47 AM, Gilles Chanteperdrix wrote: > On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote: >> Hi Gilles, >> >> Thank you very much for such low-latency reply! :-) >> >>> RTDM is the API of choice for developing drivers for real-time >>> applications using xenomai. >> >> Please correct me if I just misunderstand something here, but as I >> understand, RTDM is an abstraction layer with concrete implementation >> using xenomai API. As stated in the referenced paper from Jan Kiszka, >> the original reason for introducing this layer was to achieve >> portability across different RT solutions for Linux. Since that time, >> a lot of considered RT solutions becomes irrelevant. In fact, I would >> say, there are only Xenomai and preempt_rt. If this assumption is >> true, then I can not see the advantages of the additional layer unless >> it is more then just an abstraction layer. Does RTDM API makes certain >> tasks easier/better compared to the similar native xenomai API? Just >> to give concrete example - what is the advantage of using >> rtdm_task_init() vs. rt_task_create or xnintr_init() vs. >> rtdm_irq_request()? > > The native API is designed to write applications, not drivers. The RTDM > API is designed to write drivers. Using the native API in user-space is > deprecated, the native API is made for user-space. Using the native API in *kernel-space* is deprecated, the native API is made for user-space. Writing applications in kernel-space is not what we recommend, as much as writing drivers in user-space. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/16/2012 12:53 AM, Andrey Nechypurenko wrote: > Hi Gilles, > > Thank you very much for such low-latency reply! :-) > >> RTDM is the API of choice for developing drivers for real-time >> applications using xenomai. > > Please correct me if I just misunderstand something here, but as I > understand, RTDM is an abstraction layer with concrete implementation > using xenomai API. As stated in the referenced paper from Jan Kiszka, > the original reason for introducing this layer was to achieve > portability across different RT solutions for Linux. Since that time, > a lot of considered RT solutions becomes irrelevant. In fact, I would > say, there are only Xenomai and preempt_rt. If this assumption is > true, then I can not see the advantages of the additional layer unless > it is more then just an abstraction layer. Does RTDM API makes certain > tasks easier/better compared to the similar native xenomai API? Just > to give concrete example - what is the advantage of using > rtdm_task_init() vs. rt_task_create or xnintr_init() vs. > rtdm_irq_request()? The native API is designed to write applications, not drivers. The RTDM API is designed to write drivers. Using the native API in user-space is deprecated, the native API is made for user-space. RTDM is not an additional layer, RTDM uses the same primitives as the native API, and so does the posix API. So, there is no additional overhead involved. rtdm_task_init is the way to create a kernel-space thread, but what rtdm brings is not really that, this is only a building block, what RTDM brings is the infrastructure which make the dialog possible between the application and the driver. On the driver side, you implement open/read/write/ioctl callbacks, and magically, these functions get called when the application calls open/read/write/ioctl in user-space. > >> Also note that in the case of omap3, gptimers may be used to generate >> PWM without software assistance. And that the gpio kernel functions are >> safe to be used in real-time context. > > We already using 2 available hardware PWM generators. The experiment > with GPIO was mainly to start collecting experience with Xenomai and > see how far the one can go in user space. Now, I want to make the next > step and write kernel module which is doing the same. That is why the > question about RTDM. We are going to continue with the PWM example to help you understand what we encourage you to do. You can make an RTDM driver which will allow to control the GPIOs from user-space, as you probably already found out, this will incur a high jitter to the PWM signal. Not only that, but it will also make the application code depend on hardware details (the number of the GPIOS, the duty cycle). What your application really want to control is the motor speed, so, what you should do is an RTDM driver, which generates the PWM using GPIOS, in kernel-space, according to instructions given by the application (via write or ioctl) about the target motor speed. You no longer have any jitter problem, and now the application is completely ignorant of the hardware details, it controls what it wants to control: the motor speed. If you split the code this way (drivers in kernel-space, using RTDM, application in user-space, using the native or posix api), you only have to modify drivers when changing hardware, and you can write several applications using the same hardware without having to rewrite every time the interactions with hardware. That is the way things are done with linux, there is no reason not to do the same with xenomai. The famous example which does not do that in the linux world is the X server, and even this is changing as more and more interactions with graphic driver are moving to kernel-space. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] RTDM or native Xenomai API
On 04/15/2012 11:24 PM, Andrey Nechypurenko wrote: > Hi Folks, > > In our hobby robotics project [1] we start using Xenomai for RT tasks. > The first application was PWM generation with GPIO to control servo > motors [2] (the next would be dealing with interrupts from wheel > encoders). We have made it from the user space and result was not as > good as we would like it to be so I decide to write kernel module to > reduce the jitter. And here comes the question whether to use RTDM or > just plain Xenomai API? > > I was never using RTDM in the past. Based on what I have read, the > main intent of the RTDM is to make driver code portable across > different RT solutions for Linux. I understand it and it makes sense. > However, looking around and asking myself what are these different > solutions, I just can name Xenomai and preempt_rt patch. AFAIK, all > the rest are either dead (or almost dead) or not relevant for hobby > open-source development. So my question is what are the practical > advantages of using RTDM instead of Xenomai API? I would be very glad > to hear the opinion of experienced Linux RT developers about it. RTDM is the API of choice for developing drivers for real-time applications using xenomai. We aim at the same separation as you have with Linux: driver code in kernel-space (using RTDM in the case of Xenomai), application code resides in user-space, using any other skin, though what probably makes sense to a new project is to use the native or posix skin. Both skins have bindings to access RTDM drivers. So, in particular, it means that writing driver code (meaning code which interacts with hardware) in user-space is not what we would recommend. And handling interrupts in user-space is even less recommended. Also note that in the case of omap3, gptimers may be used to generate PWM without software assistance. And that the gpio kernel functions are safe to be used in real-time context. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
On 02/24/2012 12:07 AM, Jeff Webb wrote:
> On 02/23/2012 04:26 PM, Gilles Chanteperdrix wrote:
>> On 02/23/2012 11:02 PM, Jeff Webb wrote:
>>> I was happy to see that printf now works from real-time POSIX
>>> threads in Xenomai 2.6.0. Unfortunately, I'm seeing some strange
>>> behavior that surfaces when I try to print the string "\n" by
>>> itself. When I run the attached example program, I get:
>>>
>>> $ ./printf_test start CPU time limit exceeded $
>>>
>>> IfI replace the two printf calls with rt_printf calls and
>>> #include,I get the expected result:
>>>
>>> $ ./rt_printf_test start 1 2 3 4 ^C $
>>>
>>> The original example also works if these two lines:
>>>
>>> printf("%d", count); printf("\n");
>>>
>>> are replaced with:
>>>
>>> printf("%d\n", count);
>>>
>>> Can someone confirm if this a bug in Xenomai 2.6.0, something
>>> specific to my HW/SW installation, or some mistake in my test
>>> program?
>>
>> I would bet the call to printf is replaced with something else
>> (such as putchar). Could you disassemble the test to check this?
>
> Yes, it appears that putchar is called indeed.
>
>> Note that I have fixed similar issues in xenomai-2.6 current
>> repository, so you could give it a try.
>
> I may give that a try. Now that I have confirmed that putchar is the
> issue, do you think xenomai-2.6 current will fix the problem? Is
> putchar now wrapped as well? I noticed that puts appears to be
> wrapped from the disassembly output.
It should now be fixed in xenomai-2.6 repository.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_event_wait makes linux crash if executed while debugging with gdbserver
On 04/13/2012 04:49 PM, Fabio Visona wrote: > Hello, > > I am trying to debug a Xenomai task through gdbserver over ethernet, with: > > gdbserver host:12345 --attach 240 > > where 240 is the PID of the Xenomai real-time task I want to debug. You are supposed to debug the whole process, not attach to just one thread. So, you should pass the pid of the process main thread. > Execution crashes at EXCPT 0x0, which should be a system call, according > to Xenomai sources (syscall.h). > > Xenomai version is 2.5.3, Linux 2.6.34.7, running on a Blackfin BF518 > processor. Please try with xenomai 2.5.6, and if it does not work, it would be nice if you could try 2.6.0. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
On 04/11/2012 06:56 PM, Gilles Chanteperdrix wrote: > On 04/11/2012 04:19 PM, Wolfgang Grandegger wrote: >> Hi, >> >> On 04/05/2012 02:46 PM, Minh GIANG wrote: >>> i'm sorry sir, what i displayed just in the last mail, isn't good, because >>> i removed rt_dev_ioctl(...) in cross-link program >>> And then, with rt_dev_ioctl( RTSER_RTIOC_WAIT_EVENT ). >>> >>> [93076.465077] base=0x2f8 iir=0x4 >>> [93076.465082] base=0x2f8 status=0x0 >>> [93076.465084] base=0x2f8 iir=0x1 >> >> TX on rtser0: >> >>> [93076.556794] base=0x3f8 iir=0x2 >>> [93076.556799] base=0x3f8 status=0x0 >>> [93076.556801] base=0x3f8 iir=0x1 >> >> RX of 8 chars on rtser1: >> >>> [93076.557819] base=0x2f8 iir=0x4 >>> [93076.557823] base=0x2f8 status=0x0 >>> [93076.557825] base=0x2f8 iir=0x1 >> >>> [93076.558860] base=0x2f8 iir=0x4 >>> [93076.558865] base=0x2f8 status=0x0 >>> [93076.558867] base=0x2f8 iir=0x1 >> >>> [93076.559898] base=0x2f8 iir=0x4 >>> [93076.559901] base=0x2f8 status=0x0 >>> [93076.559903] base=0x2f8 iir=0x1 >> >>> [93076.560943] base=0x2f8 iir=0x4 >>> [93076.560946] base=0x2f8 status=0x0 >>> [93076.560948] base=0x2f8 iir=0x1 >> >>> [93076.561969] base=0x2f8 iir=0x4 >>> [93076.561971] base=0x2f8 status=0x0 >>> [93076.561973] base=0x2f8 iir=0x1 >> >>> [93076.563006] base=0x2f8 iir=0x4 >>> [93076.563009] base=0x2f8 status=0x0 >>> [93076.563011] base=0x2f8 iir=0x1 >> >>> [93076.564012] base=0x2f8 iir=0x4 >>> [93076.564012] base=0x2f8 status=0x0 >>> [93076.564012] base=0x2f8 iir=0x1 >> >>> [93076.564012] base=0x2f8 iir=0x4 >>> [93076.564012] base=0x2f8 status=0x0 >>> [93076.564012] base=0x2f8 iir=0x1 >> >> TX on rtser0: >> >>> [93076.656766] base=0x3f8 iir=0x2 >>> [93076.656770] base=0x3f8 status=0x0 >>> [93076.656772] base=0x3f8 iir=0x1 >> >> RX on rtser1: >> >>> [93076.657793] base=0x2f8 iir=0x4 >>> [93076.657795] base=0x2f8 status=0x0 >>> [93076.657797] base=0x2f8 iir=0x1 >> >> ... and so on. >> >> This looks completely normal and I'm really puzzled why the >> rt_dev_ioctl(RTSER_RTIOC_WAIT_EVENT) does not work as expected. Ah, I >> just realized that the following patch was not yet applied: >> >> https://mail.gna.org/public/xenomai-core/2011-11/msg9.html >> >> I think it will fix your problem. > > Sorry, it looks like I completely forgot this patch. Could you rebase it > on the current contents of xenomai-2.6 so that I can merge it? > Actually, the patches are merged in xenomai-2.6 repository. The problem we have is simply that xenomai 2.6.0 is too old. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
On 04/11/2012 04:19 PM, Wolfgang Grandegger wrote: > Hi, > > On 04/05/2012 02:46 PM, Minh GIANG wrote: >> i'm sorry sir, what i displayed just in the last mail, isn't good, because >> i removed rt_dev_ioctl(...) in cross-link program >> And then, with rt_dev_ioctl( RTSER_RTIOC_WAIT_EVENT ). >> >> [93076.465077] base=0x2f8 iir=0x4 >> [93076.465082] base=0x2f8 status=0x0 >> [93076.465084] base=0x2f8 iir=0x1 > > TX on rtser0: > >> [93076.556794] base=0x3f8 iir=0x2 >> [93076.556799] base=0x3f8 status=0x0 >> [93076.556801] base=0x3f8 iir=0x1 > > RX of 8 chars on rtser1: > >> [93076.557819] base=0x2f8 iir=0x4 >> [93076.557823] base=0x2f8 status=0x0 >> [93076.557825] base=0x2f8 iir=0x1 > >> [93076.558860] base=0x2f8 iir=0x4 >> [93076.558865] base=0x2f8 status=0x0 >> [93076.558867] base=0x2f8 iir=0x1 > >> [93076.559898] base=0x2f8 iir=0x4 >> [93076.559901] base=0x2f8 status=0x0 >> [93076.559903] base=0x2f8 iir=0x1 > >> [93076.560943] base=0x2f8 iir=0x4 >> [93076.560946] base=0x2f8 status=0x0 >> [93076.560948] base=0x2f8 iir=0x1 > >> [93076.561969] base=0x2f8 iir=0x4 >> [93076.561971] base=0x2f8 status=0x0 >> [93076.561973] base=0x2f8 iir=0x1 > >> [93076.563006] base=0x2f8 iir=0x4 >> [93076.563009] base=0x2f8 status=0x0 >> [93076.563011] base=0x2f8 iir=0x1 > >> [93076.564012] base=0x2f8 iir=0x4 >> [93076.564012] base=0x2f8 status=0x0 >> [93076.564012] base=0x2f8 iir=0x1 > >> [93076.564012] base=0x2f8 iir=0x4 >> [93076.564012] base=0x2f8 status=0x0 >> [93076.564012] base=0x2f8 iir=0x1 > > TX on rtser0: > >> [93076.656766] base=0x3f8 iir=0x2 >> [93076.656770] base=0x3f8 status=0x0 >> [93076.656772] base=0x3f8 iir=0x1 > > RX on rtser1: > >> [93076.657793] base=0x2f8 iir=0x4 >> [93076.657795] base=0x2f8 status=0x0 >> [93076.657797] base=0x2f8 iir=0x1 > > ... and so on. > > This looks completely normal and I'm really puzzled why the > rt_dev_ioctl(RTSER_RTIOC_WAIT_EVENT) does not work as expected. Ah, I > just realized that the following patch was not yet applied: > > https://mail.gna.org/public/xenomai-core/2011-11/msg9.html > > I think it will fix your problem. Sorry, it looks like I completely forgot this patch. Could you rebase it on the current contents of xenomai-2.6 so that I can merge it? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Information on license of Xenomai
On 04/10/2012 12:07 PM, Anisha Kaul wrote: > Greetings, > > I found this quote: >> Xenomai libraries are licensed under the terms of the LGPL. > From here: http://www.xenomai.org/index.php/Xenomai:Roadmap#Xenomai_3_FAQ > > Does that apply to Xenomai 2 also? Yes. > And are there no issues of having > different licenses of user space and kernel space (like RTAI) in > Xenomai 2? No. The linux kernel is GPL, the glibc is LGPL. > I couldn't find any /explicit topic/ w.r.t the license, on the > Xenomai's website. That is maybe because there is nothing more about it than what is documented in the sources. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Disadvantages of preempt_rt
On 04/07/2012 07:33 AM, Anisha Kaul wrote: > Greetings, > > From here: http://www.xenomai.org/index.php/Xenomai:Roadmap#Xenomai_3_FAQ > > Quote: >> the target hardware platform has limited horsepower, and/or you want the >> real-time job to put the smallest possible overhead on your system. This is >> where dual kernels are usually better than a native preemption system. > > > Preempt_rt does preempt the whole Linux. In what way does preempting > Linux put load on the system? I think you are misunderstanding what preempt_rt is, preempt_rt does not preempt linux, preempt_rt is simply linux modified, when a linux kernel patched with preempt_rt runs, nothing else than linux runs, so nothing preempts the whole linux. This is achieved by means which have a global overhead on the whole system. The exact means are described on the rt wiki FAQ: https://rt.wiki.kernel.org/articles/f/r/e/Frequently_Asked_Questions_7407.html Note the answer to FAQ 3, which explains that improving latencies is a trade off, and means degrading the average performances of the system. That is the overhead we are talking about. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] analogy - serial port
On 04/02/2012 04:12 PM, Minh GIANG wrote: > Hello everybody, > > Do the Analogy driver support the serial port. I can attach the serial > port(ttyS0) to rtser0 with xeno_16550A.ko as mentionned in Xenomai > Documentation > > modprobe xeno_16550A io=[,...] irq=[,...] > [baud_base=[,...]] > [tx_fifo=[,...]] [start_index=] > > > How can i tell to the Analogy driver to recognize the serial port in > order to use the Analogy API. i have seen the command > > /xeno_install/sbin/analogy_config analogy0 analogy_ni_pcimio > > i think that analogy_ni_pcimio is the drivers suppors of National > Instruments PCI / PXI cards. But i don't have the DAQ card yet, > currently i test with two serial ports on my computer while connecting > them by one cable. the first aim is to test the api analogy. > > Thanks, > > > > when i try to add the analogy_ni_pcimio module over terminal linux. i > get one message error > > insmod analogy_ni_pcimio.ko > > analogy_ni_pcimio.ko : -1 Unknown symbol in module And I forgot. Please stick to plain text mails, do not waste everyone's bandwidth with HTML. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] analogy - serial port
On 04/02/2012 04:12 PM, Minh GIANG wrote: > Hello everybody, > > Do the Analogy driver support the serial port. I can attach the serial > port(ttyS0) to rtser0 with xeno_16550A.ko as mentionned in Xenomai > Documentation > > modprobe xeno_16550A io=[,...] irq=[,...] > [baud_base=[,...]] > [tx_fifo=[,...]] [start_index=] > > > How can i tell to the Analogy driver to recognize the serial port in > order to use the Analogy API. i have seen the command > > /xeno_install/sbin/analogy_config analogy0 analogy_ni_pcimio > > i think that analogy_ni_pcimio is the drivers suppors of National > Instruments PCI / PXI cards. But i don't have the DAQ card yet, > currently i test with two serial ports on my computer while connecting > them by one cable. the first aim is to test the api analogy. Sorry, I did not make myself clear: the RTDM API is a general API for making drivers, Analogy is a class of drivers for acquisition boards written using RTDM. The analogy library allow access to this class of driver, so, you can not use the analogy library with a serial port driver. > > Thanks, > > > > when i try to add the analogy_ni_pcimio module over terminal linux. i > get one message error > > insmod analogy_ni_pcimio.ko > > analogy_ni_pcimio.ko : -1 Unknown symbol in module See dmesg to understand what symbol is missing. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] difference Analogy API et rtdm API in xenomai
On 04/02/2012 01:30 AM, Minh GIANG wrote: > Hello, > > thank for your advice, my other question is that i should use the POSIX API > instead of Native API in Xenomai for my application because it will be more > portable, but it seems easier with Native API for development, i'm wrong? > In conclusion, it will be better that i develop my project (data acquision > for example) with Analogy and POSIX API. The two APIs provide equivalent services, which one you prefer is largely a matter of taste. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] CAN: Locked in rtdm_sem_timeddown of tx_sem; Lost TX IRQ ?
On 03/20/2012 06:26 PM, Thierry Bultel wrote: > Hello, > > the issue I am describing here happens on a dual-core Atom (without > hyperthreading) > > It is easy to reproduce with 2.6.32.7+xenomai 2.5.2, which was my > initial configuration until > I remembered that Philippe told us that SMP was correctly supported from > 2.6.38.8 > > The fact is that I have been able to reproduce it with > 2.6.38.8+xenomai-2.6 as well. Only once, but I did. > > I am using CAN with a IXXAT PCI-04 board . > There is a single thread per bus. > > With the old kernel, after about 400-500 seconds, and heavy load the > communication stops, and after some > analysis, I found out that my process was stuck at : > > rtcan_raw.c > >/* Try to pass the guard in order to access the controller */ > * ret = rtdm_sem_timeddown(&dev->tx_sem, timeout, NULL);* > > > The Refcount shown in /proc/rtcan/rtcan0/info is 1. > > The workaround I found was to set the timeout to a non-zero value with > the appropriate ioctl, > and when a timeout issues, to stop and restart the bus, with the effect > to destroy and re-recreate the semaphore and > thus to communicate again. > > By reading the code, the only reason I can see is that a TX interrupt is > lost. > > I do not have much more ways to analyze deeper, so any advice would be > greatly appreciated Have you tried xenomai 2.5.6 ? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai support for marvells mv78100 or mv78200
On 03/29/2012 01:48 PM, Björn Slotkowski wrote: > Hello, > > > > we have a short question: > > > > Is there any xenomai support for marvells mv78100 or mv78200 ? > > I cannot find anything in the internet. > > A compilation of linux 2.6.31.8 with xenomai 2.5.4 fails with errormessage > "Unsupported ARM machine". You do not need to search the internet for the answer to this question, simply xenomai FAQ. Actually this is xenomai FAQ number 1. You will be redirected here: http://xenomai.org/index.php/Embedded_Device_Support#ARM where you will find that there is no support for this processor. If you are going to port the I-pipe patch to this architecture, I suggest you use an up-to-date version of xenomai, and not a random old version such as 2.5.4. Regards. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] difference Analogy API et rtdm API in xenomai
On 03/30/2012 03:45 PM, Minh GIANG wrote: > hello everybody, > > i have a small question, which is the difference between the analogy API > and rtdm API in xenomai. for exemple, i think that i can open a port for > data transmission in the two api. The RTDM API is an API allowing to implement drivers for xenomai using the usual POSIX open/close/ioctl/etc... API. Analogy is a driver implemented using the RTDM API. So, you can access it using either the usual POSIX open/close/ioctl/etc... API, or using the analogy library provided. So, yes, you can use the two APIs, but using the analogy library is probably simpler. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: > Hi Gilles, > > On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: >> On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: >>> On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: >>>> Hello, >>>> >>>> while playing with rt_pipe, I realized that a select()/poll() function >>>> does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the >>>> other end. I think this is because the poll callback does not support >>>> POLLHUP: >>>> >>>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 >>>> >>>> Is this by purpose? At least a blocking read() works as expected. It >>>> does unblock and return 0 in that case. >>> >>> rt_pipes are deprecated, we are not going to add new features to them >>> now. Please do not use them for new developments. We now have socket >>> based RTIPCs. See examples/rtdm/profiles/ipc. > > Ah, I was not aware of that. This solution does also work for any skin > (and does not require to misuse the native skin any more). > >> On the other hand, if you have a small patch to fix this, I will not >> hurt anyone to merge it. > > OK. See patch below. Merged, thanks. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] error with rt_pipe
On 03/26/2012 08:11 PM, Daniele wrote: > Hi > I have these errors when I'm trying to make an example of pipe rt_pipes are deprecated, see xddp sockets examples in examples/rtdm/profiles/ipc/xddp* -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:48 AM, Wolfgang Grandegger wrote: > On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: >> Hi Gilles, >> >> On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: >>> On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: >>>> On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: >>>>> Hello, >>>>> >>>>> while playing with rt_pipe, I realized that a select()/poll() function >>>>> does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the >>>>> other end. I think this is because the poll callback does not support >>>>> POLLHUP: >>>>> >>>>> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 >>>>> >>>>> Is this by purpose? At least a blocking read() works as expected. It >>>>> does unblock and return 0 in that case. >>>> >>>> rt_pipes are deprecated, we are not going to add new features to them >>>> now. Please do not use them for new developments. We now have socket >>>> based RTIPCs. See examples/rtdm/profiles/ipc. >> >> Ah, I was not aware of that. This solution does also work for any skin >> (and does not require to misuse the native skin any more). > > BTW, is there another interface (whith less overhead) to signal Linux > thread from RT threads to trigger some work, e.g. for reading from shmem? The simplest thing to do in such a case is to make the "Linux" thread a Xenomai thread but running with the SCHED_OTHER policy, you can then use simpler IPCs such as semaphores. Starting with Xenomai 2.6.0, such a thread is guaranteed to return to secondary mode as soon as possible. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: > On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: >> Hello, >> >> while playing with rt_pipe, I realized that a select()/poll() function >> does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the >> other end. I think this is because the poll callback does not support >> POLLHUP: >> >> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 >> >> Is this by purpose? At least a blocking read() works as expected. It >> does unblock and return 0 in that case. > > rt_pipes are deprecated, we are not going to add new features to them > now. Please do not use them for new developments. We now have socket > based RTIPCs. See examples/rtdm/profiles/ipc. > On the other hand, if you have a small patch to fix this, I will not hurt anyone to merge it. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: > Hello, > > while playing with rt_pipe, I realized that a select()/poll() function > does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the > other end. I think this is because the poll callback does not support > POLLHUP: > > http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 > > Is this by purpose? At least a blocking read() works as expected. It > does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/21/2012 05:46 AM, Glen Wernersbach wrote: > I am going to start trying to see if I can figure out what is not getting > set. > > By the way. This board also has 4 other serial ports on a 8250.c driver. It > also fails under the xeno build. But the serial console works, right? So there is at least on serial port working. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] How do I increase CPU time limit.
On 03/20/2012 03:43 PM, Philippe Gerum wrote: > On 03/20/2012 03:09 PM, Chris Stone wrote: >> I have a thread which uses a lot of CPU and it is receiving a SIGXCPU: >> Cpu time limit exceeded. Does this message really mean I have exceeded >> some CPU time limit? If so, how do I increase or disable the CPU time >> limit? The code that I am running has been working for quite some time >> under regular Linux and I have just ported it to Xenomai, so I doubt >> there are any infinite loops in it. > > This could be the runaway thread detector triggering, after 4s of > uninterrupted runtime (which is huge, is this intended?). This is a > debug mechanism Xenomai implements to recover from a runaway thread > chewing CPU in primary mode, without having to resort to the reset button. > You can either extend the grace period above the default 4s, using > CONFIG_XENO_OPT_WATCHDOG_TIMEOUT, or disable the watchdog entirely by > switching off CONFIG_XENO_OPT_WATCHDOG. This said, 4s is really long > already, so the regular kernel might not cope with even more starvation > from normal interrupts. > > Other explanation would be not time-related. If > CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX is enabled, any attempt to switch to > secondary mode while holding a real-time (Xenomai created) mutex in the > code would trigger such signal, as a warning to point out a priority > inversion. You may find an example of how to install a SIGXCPU handler and decode signals sent by xenomai in examples/native/sigdebug.c -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 09:19 PM, Glen Wernersbach wrote: > I actually think in is in the settings because if run just the setup part of > the code without reading and writing, on the kernel that works my activity > LED turns off. > > On the xeno kernel the LED never changes. I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any difference which could cause a difference of hardware behaviour. So, it must be another option triggered by this config change. So, if you want us to help you, please post the .configs. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 05:40 PM, Glen Wernersbach wrote: > Here it is. Just a simple modification of the atmel_serial. > > The define for it is CONFIG_MACH_MATRIX518 >From a quick glance, I do not see anything conflicting with xenomai. Note that this driver has the same issue as the vanilla atmel serial: it may loose characters in case of high irq latencies. Anyway, could you post the two kernel configurations, the one which works, the one which does not work? Other than that, I guess all you can do is try and debug the driver, starting with the serial irq and trying and understanding how it gets lost. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 05:32 PM, Glen Wernersbach wrote: > I don't get any error from anything. You do not know that, as you do not check write return value. Any chance to see the driver code? Without that, I am afraid we can not help. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 04:22 PM, Glen Wernersbach wrote: > My arm embedded system is set for 2.6.29 so I think I have to use that > patch. It was the latest one for that version. The problem is that you may have a bug which has been fixed since then. Is the code for that matrix500 driver available somewhere? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 04:17 PM, Glen Wernersbach wrote:
> Don't have a full dev enviroment on my embedded arm. Here is the program.
> Very very basic:
> close(fd);
>
>
>
>
>
>
> fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
Why closing and reopening? Are you sure this does not reset configuration?
> if (fd == -1) {
> printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
> return 0;
> }
>
>
> //write the data to my device which echos them back
> write(fd, buf, sizeof(buf)-1);
missing return value check.
>
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 03:53 PM, Glen Wernersbach wrote: > Ipipe version: > 1.13-05 That is completely outdated, please use one of the I-pipe patches which comes with xenomai 2.6.0 (since you are using xenomai 2.6.0). -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled
On 03/20/2012 02:28 PM, Glen Wernersbach wrote: > Hi All, > > I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when > CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial > write then read serial program does not work. > > If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work. Do you get a message on the kernel console about characters lost on serial device? These seems to be more frequent when the interrupt pipeline delays the interrupt than without the interrupt pipeline, but always exists. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] How to view the latency of my hello world program?
On 03/20/2012 08:49 AM, Anisha Kaul wrote: > Greetings, > > Distribution: OpenSuse 11.2 > Kernel: 2.6.35 > 64bit > > I have compiled the hello world program shown at the bottom of this > link: http://www.cs.ru.nl/lab/xenomai/exercises/ex01/Exercise-1.html > It has compiled successfully. > > I want to see its latency. Then you have to modify that program in order for it to measure the latency and print it. You can look at the "latency" test sources to see how it can be done. > > I am aware of the program "/usr/xenomai/bin/xeno-test" but I can't > understand its output. There is nothing magic, you have all the sources, you can look at them to understand what happens. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Should posix threads show up in /proc/xenomai/sched.
On 03/14/2012 06:59 PM, Chris Stone wrote: > Using the "Porting POSIX applications to Xenomai" document I have > ported an existing application to Xenomai. We create multiple threads > in our application and I have the following questions related to > posix threads (I could not find an answer in a search of > xenomai-help): > > If the threads are running in primary mode, should they be listed in > /proc/xenomai/sched? My threads show up, with the correct real time > priorities, when I do a top -H, but they are not in > /proc/xenomai/sched, so does that mean they are all running in > secondary mode? > No, it means that they are not xenomai thread. If the application is compiled correctly, xenomai threads are those created with pthread_create. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] system locks when calling Linux clock_gettime
On 03/13/2012 07:06 PM, Herrera-Bendezu, Luis wrote: > Hello, > > Xenomai version 2.4.10, Linux version 2.6.30.3, CPU PPC. > > I am trying to work around an issue where the Linux and Xenomai realtime > clocks > drifts when Linux clock is updated by NTP. It was suggested in the mail > exchange: > http://www.mail-archive.com/xenomai-core@gna.org/msg07646.html > > to use clock_gettime()/clock_settime() to keep both clocks in sync. > > However, calling linux clock_gettime() from a Xenomai thread is causing > system to > freeze after a few minutes as shown in the following test program where the > interval > to re-sync clocks is small, 50 msec, to force error faster: Yes, this is a known issue too. You can only call __real_clock_gettime when in secondary mode. So, preferably from a thread created with __real_pthread_create. Any chance of updating xenomai? Xenomai 2.6 allows accessing a clock synchronized with Linux clock from xenomai threads, without even emitting a system call depending on the architecture. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai stop working
On 03/13/2012 07:32 AM, 马强 wrote:
> Hi, Gilles.
>
> I could not find "mxc_min_delay = 0xff" in linux source tree
> and xenomai directory. mxc_min_delay comes from ipipe,
> there is also no such statement in latest patch downloaded
> from website.
>
> If mxc_min_delay is 0xff, in my system this means 32us for 8MHz
> ipipe tsc. For a real time system, It seems a little bit longer.
>
> I used mxc_min_delay=16(2us) to do a test during last weekend,
> until now and no stall have happened again. So mxc_min_delay = 0x10
> maybe enough for my test CPU, I can't decide which value should be used.
Linux uses a similar mechanism for its clock_event_device named
min_delta_ns. In latest releases min_delta_ns is set such that it
corresponds to 0xff ticks. But you are right: this value is too large
for xenomai.
>
> The following code copy from the time.c file that patched by xenomai.
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> if (delay > mxc_min_delay) {
> unsigned long tcmp;
>
> if (!timer_is_v2()) {
> tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
> __raw_writel(tcmp, timer_base + MX1_2_TCMP);
> } else {
> tcmp = __raw_readl(timer_base + V2_TCN) + delay;
> __raw_writel(tcmp, timer_base + V2_TCMP);
> }
> } else
> ipipe_trigger_irq(__ipipe_mach_timerint);
> }
>
> My question is whether this function will be interrupted by other high
> priority interrupts.
No, this function is called with hardware irqs off.
--
Gilles.
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] find segmentation fault in real-time-task
On 03/09/2012 06:30 PM, Michael Heuer wrote: > Hi guys, I'm posting the first time and i hope you can help me. > > At the moment i have a segmentation fault in the real-time part of my > program (task created with rt_task_create, Xenomai 2.5.6). > > Is there a way to register an signal to print the call-stack? > > If its in the non real-time part the signal is raised and i get my > information but in the real-time part i just get an Segmentation fault > in the shell... Using xenomai does not make any difference with regard to that question: you can, just as without xenomai, register a handler for the SIGSEGV signal. But if the segmentation fault is due to a stack overflow (which, I suspect, is your problem), you will get another segmentation fault in the segmentation fault signal handler, so, you have to use sigaltstack to avoid that, but then using the "backtrace" function to walk the call stack will no longer work, so, you need to use the SA_SIGINFO flag, and walk the stack yourself extracting the stack pointer register value from the "context" argument of the signal handler. This is a little complicated. Another much simpler solution is to use gdb. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai stop working
On 03/09/2012 07:06 AM, 马强 wrote: > Hi Gilles, > > I have changed mxc_min_delay as follow > mxc_min_delay = ((__ipipe_cpu_freq + 50) / 100) ?: 1; > -> > mxc_min_delay = ((__ipipe_cpu_freq + 25) / 50) ?: 1; > means make min delay form 1us to 2us, and it seems to work well. I need a > longer test to check it out. > > Another issue about this change is whether 2us is long enough? In other > words, Is 2us a threshold value that due to hardware or an assumed value that > make the possibility smaller? if it is the later one, 2us and someone bigger > seems not to be a perfect solution. You can try mxc_min_delay = 0xff, since it is what linux does in the latest release. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai stop working
On 03/08/2012 04:13 AM, ?? wrote: > Hi > > I have installed xenomai-2.5.6 on imx53 quick start board with Linux > 2.6.35, it works well but stop working when I do some kernel real time task. > > When it stop working, system is not totally down, it will be recovered > after about 8~9 minutes, which comes This usually means that the hardware timer is programmed for a too short delay and wraps instead of ticking right away. You need to increase, in __ipipe_mach_set_dec for the cpu you use, the minimum delay for which an irq is triggered. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai main heap size
On 03/07/2012 10:37 AM, Mauro Salvini wrote: >> On 03/06/2012 04:15 PM, Mauro Salvini wrote: >>> Hi, >>> >>> in Xenomai kernel configuration section there is CONFIG_XENO_OPT_SYS_HEAPSZ >>> to configure Xenomai internal heap size. >>> Is it possible to change the main heap size using kernel boot parameters? >>> or this can be done only with a kernel re-compile? >> >> How is this question related to the "preemptive doesn't work" thread ? >> >> -- >> Gilles. > > It isn't related, I suppose. Why this question? My thread has "Xenomai main > heap size" title... > Sorry. My e-mail client put your mail in that thread, as if you had replied to it, so I assumed you did. No, the heap size can only be changed by using the kernel configuration. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Freeze while running examples
On 03/06/2012 05:53 PM, Philippe Gerum wrote: > On 03/06/2012 05:45 PM, Gilles Chanteperdrix wrote: >> On 03/06/2012 04:14 AM, Oscar Dávila wrote: >>> 2012/3/2 Gilles Chanteperdrix >>> >>>> On 03/03/2012 01:14 AM, Oscar Dávila wrote: >>>>> 2012/3/2 Gilles Chanteperdrix >>>>> >>>>>> On 03/02/2012 11:04 AM, Gilles Chanteperdrix wrote: >>>>>>> On 03/01/2012 05:23 AM, Oscar Dávila wrote: >>>>>>>> Finally i could get the dump >>>>>>>> >>>>>>>> >>>>>>>> post-prompt >>>>>>>> No breakpoints or watchpoints. >>>>>>>> >>>>>>>> breakpoints-table-end >>>>>>>> >>>>>>>> post-prompt >>>>>>>> Dump of assembler code for function __ipipe_sync_stage: >>>>>>>> 0xc106d376<__ipipe_sync_stage+0>: push %ebp >>>>>>>> (...) >>>>>>>> 0xc106d526<__ipipe_sync_stage+432>: ret >>>>>>>> End of assembler dump. >>>>>>> >>>>>>> The address where the EIP is when the NMI watchdog triggers is >>>>>>> 0xc106d5e1, so, outside this code. >>>>>>> >>>>>> And this dump does not seem to correspond to the kernel that was running >>>>>> when the bug happened, because in that case we had >>>>>> >>>>>> 0xc106d5e1 == __ipipe_sync_stage + 0x21b >>>>>> >>>>>> whereas in your dump, >>>>>> >>>>>> __ipipe_sync_stage + 0x21b == 0xc106d591 >>>>>> >>>>>> Sorry about that, i lost that image of the kernel. >>>>> >>>>> Here is a new complete test. >>>>> >>>>> Kernel Messages >>>>> >>>>> >>>>> Kernel failure message 1: >>>>> BUG: NMI Watchdog detected LOCKUP on CPU0, ip c10751d3, registers: >>>>> >>>>>local_irq_disable_hw(); >>>>> c10751bf: fa cli >>>>> c10751c0: 89 e0 mov%esp,%eax >>>>> c10751c2: 25 00 e0 ff ff and$0xe000,%eax >>>>>root_stall_after_handler(); >>>>>while (__ipipe_check_root_resched()) >>>>> c10751c7: 83 78 14 00 cmpl $0x0,0x14(%eax) >>>>> c10751cb: 75 58 jnec1075225<__xirq_end+0x2> >>>>> c10751cd: f6 40 08 08 testb $0x8,0x8(%eax) >>>>> c10751d1: 74 52 je c1075225<__xirq_end+0x2> >>>>> c10751d3: eb f8 jmpc10751cd >>>> <__ipipe_sync_stage+0x12b> >>>>>__ipipe_preempt_schedule_irq(); >>>> >>>> Looks like an infinite loop when CONFIG_PREEMPT is off. Try putting an >>>> #ifdef CONFIG_PREEMPT around this code: >>>> >>>> #ifdef CONFIG_PREEMPT >>>> while (__ipipe_check_root_resched()) >>>> __ipipe_preempt_schedule_irq(); >>>> #endif >>>> >>>> To test that this is indeed the issue, you may try enabling >>>> CONFIG_PREEMPT in the code. >>> >>> >>> >>> I recompiled the kernel enabling CONFIG_PREEMPT and it worked, also i tried >>> the other option, where i add the #ifdef CONFIG_PREEMPT to the source of >>> core.c, and it also worked. >>> >>> So it seems that was the problem. Now i can run trivial_periodic. >>> >>> But after some time with the kernel after running trivial_periodic, the >>> machines still freezes, i will try to see where the failure is happening >>> now. >>> >>> Which type of preemption model its preferred? i mean, using the >>> CONFIG_PREEMPT enabled or without the: >>> while (__ipipe_check_root_resched()) >>> __ipipe_preempt_schedule_irq(); >> >> We should not need either workaround. From reading the code, I do not >> understand why the compiler creates this infinite loop. It would be >> interesting to generate the pre-processed file to understand how this >> happens. >> > > Because CONFIG_PREEMPT is disabled, but __ipipe_check_root_resched() is > instantiated. This can't fly. > Sorry, I was looking at the wrong version of the patch. This seems to have been fixed in later releases. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Xenomai main heap size
On 03/06/2012 04:15 PM, Mauro Salvini wrote: > Hi, > > in Xenomai kernel configuration section there is CONFIG_XENO_OPT_SYS_HEAPSZ > to configure Xenomai internal heap size. > Is it possible to change the main heap size using kernel boot parameters? or > this can be done only with a kernel re-compile? How is this question related to the "preemptive doesn't work" thread ? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Freeze while running examples
On 03/06/2012 04:14 AM, Oscar Dávila wrote: > 2012/3/2 Gilles Chanteperdrix > >> On 03/03/2012 01:14 AM, Oscar Dávila wrote: >>> 2012/3/2 Gilles Chanteperdrix >>> >>>> On 03/02/2012 11:04 AM, Gilles Chanteperdrix wrote: >>>>> On 03/01/2012 05:23 AM, Oscar Dávila wrote: >>>>>> Finally i could get the dump >>>>>> >>>>>> >>>>>> post-prompt >>>>>> No breakpoints or watchpoints. >>>>>> >>>>>> breakpoints-table-end >>>>>> >>>>>> post-prompt >>>>>> Dump of assembler code for function __ipipe_sync_stage: >>>>>> 0xc106d376 <__ipipe_sync_stage+0>: push %ebp >>>>>> (...) >>>>>> 0xc106d526 <__ipipe_sync_stage+432>: ret >>>>>> End of assembler dump. >>>>> >>>>> The address where the EIP is when the NMI watchdog triggers is >>>>> 0xc106d5e1, so, outside this code. >>>>> >>>> And this dump does not seem to correspond to the kernel that was running >>>> when the bug happened, because in that case we had >>>> >>>> 0xc106d5e1 == __ipipe_sync_stage + 0x21b >>>> >>>> whereas in your dump, >>>> >>>> __ipipe_sync_stage + 0x21b == 0xc106d591 >>>> >>>> Sorry about that, i lost that image of the kernel. >>> >>> Here is a new complete test. >>> >>> Kernel Messages >>> >>> >>> Kernel failure message 1: >>> BUG: NMI Watchdog detected LOCKUP on CPU0, ip c10751d3, registers: >>> >>> local_irq_disable_hw(); >>> c10751bf: fa cli >>> c10751c0: 89 e0 mov%esp,%eax >>> c10751c2: 25 00 e0 ff ff and$0xe000,%eax >>> root_stall_after_handler(); >>> while (__ipipe_check_root_resched()) >>> c10751c7: 83 78 14 00 cmpl $0x0,0x14(%eax) >>> c10751cb: 75 58 jnec1075225 <__xirq_end+0x2> >>> c10751cd: f6 40 08 08 testb $0x8,0x8(%eax) >>> c10751d1: 74 52 je c1075225 <__xirq_end+0x2> >>> c10751d3: eb f8 jmpc10751cd >> <__ipipe_sync_stage+0x12b> >>> __ipipe_preempt_schedule_irq(); >> >> Looks like an infinite loop when CONFIG_PREEMPT is off. Try putting an >> #ifdef CONFIG_PREEMPT around this code: >> >> #ifdef CONFIG_PREEMPT >>while (__ipipe_check_root_resched()) >>__ipipe_preempt_schedule_irq(); >> #endif >> >> To test that this is indeed the issue, you may try enabling >> CONFIG_PREEMPT in the code. > > > > I recompiled the kernel enabling CONFIG_PREEMPT and it worked, also i tried > the other option, where i add the #ifdef CONFIG_PREEMPT to the source of > core.c, and it also worked. > > So it seems that was the problem. Now i can run trivial_periodic. > > But after some time with the kernel after running trivial_periodic, the > machines still freezes, i will try to see where the failure is happening > now. > > Which type of preemption model its preferred? i mean, using the > CONFIG_PREEMPT enabled or without the: >while (__ipipe_check_root_resched()) >__ipipe_preempt_schedule_irq(); We should not need either workaround. From reading the code, I do not understand why the compiler creates this infinite loop. It would be interesting to generate the pre-processed file to understand how this happens. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Xenomai-core] preemptive doesn't work
On 03/06/2012 04:14 PM, Roberto Bielli wrote: > Hi Gilles, > > i changed the min value of the '__ipipe_mach_set_dec' but the situation > is the same. > I see with the scope that the task with less priority is not interrupted. In the trace you sent, we clearly saw that it was interrupted by a timer interrupt. > > It's difficult to see with the ipipe trace the problem so i put the > xenomai trace in the application with > |xntrace_user_start|/|xntrace_user_stop|. > Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ? See the latency test for an example of usage of the I-pipe tracer in user-space. When using latency -f the trace is available in /proc/ipipe/trace/frozen. What about T_WARNSW (it is the third time I ask). Also, it would be nice if you could try a more recent version of Xenomai and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Xenomai-core] preemptive doesn't work
On 03/06/2012 02:00 PM, Roberto Bielli wrote: > Hi Gilles, > > here is the new trace. There is nothing to see on that trace. Please increase the number of trace points, and trigger a trace when you detect a problem., the number of trace points should be sufficient to get the timer programmation which happens before the problem. Also, did you try T_WANRSW ? Please disable the configuration of you mail server which asks me to send a receipt to each every mail you send me. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] [Xenomai-core] preemptive doesn't work
On 03/06/2012 11:14 AM, Roberto Bielli wrote: > Hi, > > here is the trace. Please try to capture the xntimer_next_local_shot which happens before the bug to see if the timer ticks when expected. Also note that if we are going through __ipipe_preempt_schedule_irq, it means that the task eating the cpu is running in secondary mode. So, you should use T_WARNSW to see. Please keep the discussion on the mailing list. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Specifying/changing the number of CPU core's in xenomai: - reg
On 03/06/2012 07:46 AM, SUBRAMANIAN NATESAN wrote: > Hi, > > In a multi-core environment, is it possible in xenomai, to specify the cpu > cores which should or should not be used? Like if there are 4 cores, can we > specify, that core 2 need not be used at all, dynamically, during the > execution of a real time task? You can use sched_setaffinity to set the CPU on which a task should run. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Difference between threads and tasks in Xenomai: -reg
On 03/05/2012 08:55 PM, SUBRAMANIAN NATESAN wrote: > Hi, > > What is the difference between the threads and tasks in Xenomai. Tasks are > defined in skins and threads in kernel. rt_task_info and xnthread_info > structures have the similar variables, which have information regarding > corresponding task or thread. > > Also, during context switch, whether thread control block or task control > block is used? Where would be the program counter and all the necessary > details stored? task is just the usual name for threads, in the context of RTOSes. Legacy RTOSes and native skin speak about tasks whereas the posix skin speaks about thread, but that is the only difference. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] How can I use xenomai with the linux kernel of 2.6.32 on the plarform of omap3530?
On 03/04/2012 12:53 AM, Arnout Vandecappelle wrote: > On Wednesday 29 February 2012 10:08:05 Gilles Chanteperdrix wrote: >> On 02/29/2012 08:14 AM, xgd...@sina.com wrote: >>> Dear sir, sorry to trouble u,but i have a problem i can't >>> solve. Now i use an omap3530 Evaluation Boards and the linux >>> kernel which manufacturers provides is 2.6.32 . i have to use this >>> kernel.when i try the step: $ scripts/prepare-kernel.sh >>> --linux= [--adeos=] >>> [--arch=],i can't find the adeos-patch which matches the >>> kernel ,so I need ur help and how can i use xenomai with the linux >>> kernel of 2.6.32 on the platform of omap3530? thanks for ur help.Best >>> wishes to you! >>> Sincerely yours, Liang Runhan >> >> You have two soilutions: >> - either you adapt the patches for linux 2.6.31 or 2.6.33 to linux 2.6.32 >> - or you adapt a more recent linux kernel version for which an Adeos >> patch exists to your board. >> >> If you know more linux than xenomai, the second solution is easier. >> Besides 2.6.32 is seriously outdated now. > > OMAP3530 support is almost fully merged in the 3.0 mainline kernel, IIRC. > I think only a few of the video accelerator drivers are missing. So the > mainline v3.0 (with the corresponding Adeos patches from gna.org) and see > how far you get. OMAP3 support is available has ben mainline kernel for years in the mainline kernel, I would say since at least 2.6.31. The problem is more board support for the specific board this user wants, and drivers. But as I said, adding this support if you have it for another kernel is easier than adapting I-pipe support. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Scheduling and context switch in Xenomai: - reg
On 03/03/2012 02:02 PM, SUBRAMANIAN NATESAN wrote: > Hi, > > During the context switch in scheduling, could you please let me know, > where the process/thread's information or state is stored and which > function call is responsible for it? Linux uses switch_to, xenomai uses xnarch_switch_to. These are defined differently for each architecture and may be either macros or functions depending on the architecture. The registers are loaded and saved from the task control block. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Freeze while running examples
On 03/03/2012 01:14 AM, Oscar Dávila wrote: > 2012/3/2 Gilles Chanteperdrix > >> On 03/02/2012 11:04 AM, Gilles Chanteperdrix wrote: >>> On 03/01/2012 05:23 AM, Oscar Dávila wrote: >>>> Finally i could get the dump >>>> >>>> >>>> post-prompt >>>> No breakpoints or watchpoints. >>>> >>>> breakpoints-table-end >>>> >>>> post-prompt >>>> Dump of assembler code for function __ipipe_sync_stage: >>>> 0xc106d376 <__ipipe_sync_stage+0>: push %ebp >>>> (...) >>>> 0xc106d526 <__ipipe_sync_stage+432>: ret >>>> End of assembler dump. >>> >>> The address where the EIP is when the NMI watchdog triggers is >>> 0xc106d5e1, so, outside this code. >>> >> And this dump does not seem to correspond to the kernel that was running >> when the bug happened, because in that case we had >> >> 0xc106d5e1 == __ipipe_sync_stage + 0x21b >> >> whereas in your dump, >> >> __ipipe_sync_stage + 0x21b == 0xc106d591 >> >> Sorry about that, i lost that image of the kernel. > > Here is a new complete test. > > Kernel Messages > > > Kernel failure message 1: > BUG: NMI Watchdog detected LOCKUP on CPU0, ip c10751d3, registers: > > local_irq_disable_hw(); > c10751bf: fa cli > c10751c0: 89 e0 mov%esp,%eax > c10751c2: 25 00 e0 ff ff and$0xe000,%eax > root_stall_after_handler(); > while (__ipipe_check_root_resched()) > c10751c7: 83 78 14 00 cmpl $0x0,0x14(%eax) > c10751cb: 75 58 jnec1075225 <__xirq_end+0x2> > c10751cd: f6 40 08 08 testb $0x8,0x8(%eax) > c10751d1: 74 52 je c1075225 <__xirq_end+0x2> > c10751d3: eb f8 jmpc10751cd > <__ipipe_sync_stage+0x12b> > __ipipe_preempt_schedule_irq(); Looks like an infinite loop when CONFIG_PREEMPT is off. Try putting an #ifdef CONFIG_PREEMPT around this code: #ifdef CONFIG_PREEMPT while (__ipipe_check_root_resched()) __ipipe_preempt_schedule_irq(); #endif To test that this is indeed the issue, you may try enabling CONFIG_PREEMPT in the code. > -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] ABI
On 03/02/2012 03:56 PM, Utsav Patel wrote: > While running the program, I am getting this. > > ceems@ceems-desktop:~/Desktop$ ./hello > Xenomai: incompatible ABI revision level > (needed=1, current=4). > > Can any one tell me what this means? What should I do? You get this error when mixing xenomai user-space support dans kernel-space support from different branches. For instance xenomai kernel-space version from branch 2.5 with xenomai user-space support from branch 2.6. What you should do is compile xenomai kernel-space and user-space using sources in the same branch. Another possible explanation is that you are using gcc 4.6 on x86. And in that case, you should add "-fno-omit-frame-pointer" to the CFLAGS you pass to xenomai user-space configure script. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
