Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/11/2011 02:35 PM, Alexey Galakhov wrote: > On 05/11/2011 06:24 PM, Gilles Chanteperdrix wrote: >> Try this: >> diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c >> index 2ca0d6c..534f97f 100644 >> --- a/ksrc/arch/arm/hal.c >> +++ b/ksrc/arch/arm/hal.c >> @@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu) >> >> rthal_timer_set_oneshot(1); >> >> -return 0; >> +return 10UL / HZ; >> } > Seems to be fixed, thanks! > > I just compared generic and non-generic rthal_timer_request and already > tried "return 1" but did not realized that "1G/Hz" is correct return value. That is good news, all the Xenomai and I-pipe patches were merged. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/11/2011 06:24 PM, Gilles Chanteperdrix wrote: > Try this: > diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c > index 2ca0d6c..534f97f 100644 > --- a/ksrc/arch/arm/hal.c > +++ b/ksrc/arch/arm/hal.c > @@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu) > > rthal_timer_set_oneshot(1); > > - return 0; > + return 10UL / HZ; > } Seems to be fixed, thanks! I just compared generic and non-generic rthal_timer_request and already tried "return 1" but did not realized that "1G/Hz" is correct return value. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/11/2011 12:50 PM, Gilles Chanteperdrix wrote: > On 05/11/2011 12:29 PM, Alexey Galakhov wrote: >> On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote: >>> Ok, so there is a timer interrupt which does not result in reprogramming >>> the timer, all you need to find out is why... Could you print the tsc >>> value for each of these printks? >>> Also, have you tried putting the call to the tsc update function in the >>> acktimer function? >> I did some more investigations and found what actually happens. The call >> to xntimer_next_local_shot does not result in a call to >> rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean >> empty queue? >> >> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. >> rthal_timer_request[non-generic] >> go >> rthal_irq_request 30 >> ipipe_virtualize_irq 30 c0066bcc >> rthal_timer_set_oneshot 1 >> _mach_set_dec 42187 3035818 >> _tsc_update >> xenomai- steal_timer 1 >> xntimer_next_local_shot >> xnarch_program_timer_shot 0 >> rthal_timer_program_shot 0 >> xntimer_tick_aperiodic >> xntimer_next_local_shot >> - return xntimerq_it_begin == NULL >> Xenomai: starting native API services. >> Xenomai: starting POSIX services. >> Xenomai: starting RTDM services. >> _mach_acktimer 0 >> xntimer_tick_aperiodic >> xntimer_next_local_shot >> - return xntimerq_it_begin == NULL >> msgmni has been set to 119 >> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) >> io scheduler noop registered (default) > > I was going to check this real soon (tonight probably). At this point > the only timer which should be in the list is the host timer. From > memory, the host timer is or was installed in ksrc/nucleus/timer.c or > ksrc/nucleus/pod.c depending on the return value of rthal_timer_request. > rthal_timer_request implementation depends on CONFIG_GENERIC_CLOCKEVENTS. > > So, since we have not checked for some time the code in the case where > this option is disabled, rthal_timer_request return value is probably > now interpreted as meaning that we do not need a host timer, whereas we > need one. > > This is my hypothesis at least, but I need to check exactly what happens. > Try this: diff --git a/ksrc/arch/arm/hal.c b/ksrc/arch/arm/hal.c index 2ca0d6c..534f97f 100644 --- a/ksrc/arch/arm/hal.c +++ b/ksrc/arch/arm/hal.c @@ -322,7 +322,7 @@ int rthal_timer_request(void (*handler)(void), int cpu) rthal_timer_set_oneshot(1); - return 0; + return 10UL / HZ; } void rthal_timer_release(int cpu) -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/11/2011 12:29 PM, Alexey Galakhov wrote: > On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote: >> Ok, so there is a timer interrupt which does not result in reprogramming >> the timer, all you need to find out is why... Could you print the tsc >> value for each of these printks? >> Also, have you tried putting the call to the tsc update function in the >> acktimer function? > I did some more investigations and found what actually happens. The call > to xntimer_next_local_shot does not result in a call to > rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean > empty queue? > > Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. > rthal_timer_request[non-generic] > go > rthal_irq_request 30 > ipipe_virtualize_irq 30 c0066bcc > rthal_timer_set_oneshot 1 > _mach_set_dec 42187 3035818 > _tsc_update > xenomai- steal_timer 1 > xntimer_next_local_shot > xnarch_program_timer_shot 0 > rthal_timer_program_shot 0 > xntimer_tick_aperiodic > xntimer_next_local_shot > - return xntimerq_it_begin == NULL > Xenomai: starting native API services. > Xenomai: starting POSIX services. > Xenomai: starting RTDM services. > _mach_acktimer 0 > xntimer_tick_aperiodic > xntimer_next_local_shot > - return xntimerq_it_begin == NULL > msgmni has been set to 119 > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered (default) I was going to check this real soon (tonight probably). At this point the only timer which should be in the list is the host timer. From memory, the host timer is or was installed in ksrc/nucleus/timer.c or ksrc/nucleus/pod.c depending on the return value of rthal_timer_request. rthal_timer_request implementation depends on CONFIG_GENERIC_CLOCKEVENTS. So, since we have not checked for some time the code in the case where this option is disabled, rthal_timer_request return value is probably now interpreted as meaning that we do not need a host timer, whereas we need one. This is my hypothesis at least, but I need to check exactly what happens. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/06/2011 03:33 PM, Gilles Chanteperdrix wrote: > Ok, so there is a timer interrupt which does not result in reprogramming > the timer, all you need to find out is why... Could you print the tsc > value for each of these printks? > Also, have you tried putting the call to the tsc update function in the > acktimer function? I did some more investigations and found what actually happens. The call to xntimer_next_local_shot does not result in a call to rthal_timer_program_shot due to "if (h == NULL)" condition. Does it mean empty queue? Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. rthal_timer_request[non-generic] go rthal_irq_request 30 ipipe_virtualize_irq 30 c0066bcc rthal_timer_set_oneshot 1 _mach_set_dec 42187 3035818 _tsc_update xenomai- steal_timer 1 xntimer_next_local_shot xnarch_program_timer_shot 0 rthal_timer_program_shot 0 xntimer_tick_aperiodic xntimer_next_local_shot - return xntimerq_it_begin == NULL Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. _mach_acktimer 0 xntimer_tick_aperiodic xntimer_next_local_shot - return xntimerq_it_begin == NULL msgmni has been set to 119 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/06/2011 03:55 PM, Gilles Chanteperdrix wrote: > The problem probably comes from the fact that you are running with > CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different > hardware. Looks like S3C2440 is one of the few systems that have GENERIC_CLOCKEVENTS off (see Kconfig). Other systems seem to turn it on. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/06/2011 03:55 PM, Gilles Chanteperdrix wrote: > The problem probably comes from the fact that you are running with > CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different > hardware. Today I found that the problem is reproduceable on an emulator. There is a fork of qemu that emulates mini2440 board, it is here: http://repo.or.cz/w/qemu/mini2440.git . Now I test on the emulator first as it is faster and does not wear out board's flash. It is a bit hacked, i.e. you have to have a bootloader in ./mini2440/u-boot.bin and so on but it is quite usable. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/06/2011 11:28 AM, Alexey Galakhov wrote: > On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote: >> Please try and move the cal to ipipe_tsc_update to the acktimer function. >> Also call printk in the actkimer function, in order to see if the last >> action is a set_dec, or an acktimer. > Just tried to add printk (not moved anything). Got: Just explaining what happens. > > ipipe_mach_set_dec: 4294967295 > ipipe_mach_set_dec: 4294967295 These are for the setup calibration (rthal_calibrate_timer). > ipipe_mach_set_dec: 42186 This is the call to __ipipe_mach_release_timer, at the end of calibration, which should put the timer back under Linux control, in auto-reload mode. > Xenomai: scheduling class idle registered. > Xenomai: scheduling class rt registered. > acktimer > acktimer > acktimer > acktimer > acktimer Linux ticks, set_dec is not called, because the timer auto-reloads. > Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. > ipipe_mach_set_dec: 42187 Here the timer goes under Xenomai control, ipipe_mach_timerstolen is set to 1. > Xenomai: starting native API services. > Xenomai: starting POSIX services. > Xenomai: starting RTDM services. > acktimer First timer interrupt, should trig a call to Xenomai tick timer handler, which should reprogram the next timer. At this time, there is only one timer in Xenomai's list: the host timer, so, we should see an set_dec(42186) again. The problem probably comes from the fact that you are running with CONFIG_GENERIC_CLOCKEVENTS, I will try and reproduce this on different hardware. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/06/2011 11:28 AM, Alexey Galakhov wrote: > On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote: >> Please try and move the cal to ipipe_tsc_update to the acktimer function. >> Also call printk in the actkimer function, in order to see if the last >> action is a set_dec, or an acktimer. > Just tried to add printk (not moved anything). Got: > > ipipe_mach_set_dec: 4294967295 > ipipe_mach_set_dec: 4294967295 > ipipe_mach_set_dec: 42186 > Xenomai: scheduling class idle registered. > Xenomai: scheduling class rt registered. > acktimer > acktimer > acktimer > acktimer > acktimer > Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. > ipipe_mach_set_dec: 42187 > Xenomai: starting native API services. > Xenomai: starting POSIX services. > Xenomai: starting RTDM services. > acktimer > msgmni has been set to 119 > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) > io scheduler noop registered (default) Ok, so there is a timer interrupt which does not result in reprogramming the timer, all you need to find out is why... Could you print the tsc value for each of these printks? Also, have you tried putting the call to the tsc update function in the acktimer function? -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote: > Please try and move the cal to ipipe_tsc_update to the acktimer function. > Also call printk in the actkimer function, in order to see if the last > action is a set_dec, or an acktimer. Tried to move the call. Got exactly the same hangup and dmesg. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 11:26 PM, Gilles Chanteperdrix wrote: > Please try and move the cal to ipipe_tsc_update to the acktimer function. > Also call printk in the actkimer function, in order to see if the last > action is a set_dec, or an acktimer. Just tried to add printk (not moved anything). Got: ipipe_mach_set_dec: 4294967295 ipipe_mach_set_dec: 4294967295 ipipe_mach_set_dec: 42186 Xenomai: scheduling class idle registered. Xenomai: scheduling class rt registered. acktimer acktimer acktimer acktimer acktimer Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded. ipipe_mach_set_dec: 42187 Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. acktimer msgmni has been set to 119 Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered (default) -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 05:23 PM, Alexey Galakhov wrote:
> On 05/05/2011 08:42 PM, Gilles Chanteperdrix wrote:
>> On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
>>> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
> May it be caused by the following code from plat-samsung/time.c ?
>
> static inline void set_dec(unsigned long reload)
> {
> __raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
> TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
Try adding:
if (reload > 0x)
reload = 0x;
before the raw_writel
>>> No effect. It may make sense but does not fix this bug.
>> It may also happen that the timer has a lower limit, when the reload
>> parameter is below this limit, you shoud call ipipe_trigger_irq, as
>> explained in the porting guide.
> Seems to be not the case but tried it anyway (guessed lower limit
> 0x00ff), no effect. Also tried to add printk to __ipipe_mach_set_dec,
> got the following:
This is probably the same issue as I had on AT91. Please try disabling
the NO_HZ configuration option.
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 08:42 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
>> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
>>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
May it be caused by the following code from plat-samsung/time.c ?
static inline void set_dec(unsigned long reload)
{
__raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
>>> Try adding:
>>>
>>> if (reload > 0x)
>>> reload = 0x;
>>>
>>> before the raw_writel
>> No effect. It may make sense but does not fix this bug.
> It may also happen that the timer has a lower limit, when the reload
> parameter is below this limit, you shoud call ipipe_trigger_irq, as
> explained in the porting guide.
Seems to be not the case but tried it anyway (guessed lower limit
0x00ff), no effect. Also tried to add printk to __ipipe_mach_set_dec,
got the following:
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
ipipe_mach_set_dec: 42187
ipipe_mach_set_dec: 4294967295
- - (repeats many times) - -
ipipe_mach_set_dec: 4294967295
ipipe_mach_set_dec: 42186
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
ipipe_mach_set_dec: 42187
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)
- - (hangs) - -
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 04:12 PM, Alexey Galakhov wrote:
> On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
>> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>>> May it be caused by the following code from plat-samsung/time.c ?
>>>
>>> static inline void set_dec(unsigned long reload)
>>> {
>>> __raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
>>> TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
>> Try adding:
>>
>> if (reload > 0x)
>> reload = 0x;
>>
>> before the raw_writel
> No effect. It may make sense but does not fix this bug.
It may also happen that the timer has a lower limit, when the reload
parameter is below this limit, you shoud call ipipe_trigger_irq, as
explained in the porting guide.
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 08:02 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
>> May it be caused by the following code from plat-samsung/time.c ?
>>
>> static inline void set_dec(unsigned long reload)
>> {
>> __raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
>> TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
> Try adding:
>
> if (reload > 0x)
> reload = 0x;
>
> before the raw_writel
No effect. It may make sense but does not fix this bug.
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 03:16 PM, Alexey Galakhov wrote:
> On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
>> You should make sure that pm_idle == default_idle. In this case,
>> __ipipe_halt_root is called instead of arch_idle, and everything should
>> work.
> May it be caused by the following code from plat-samsung/time.c ?
>
> static inline void set_dec(unsigned long reload)
> {
> __raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
> TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
Try adding:
if (reload > 0x)
reload = 0x;
before the raw_writel.
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
> You should make sure that pm_idle == default_idle. In this case,
> __ipipe_halt_root is called instead of arch_idle, and everything should
> work.
May it be caused by the following code from plat-samsung/time.c ?
static inline void set_dec(unsigned long reload)
{
__raw_writel(reload, S3C2410_TCNTB(4)); /* < In fact,
TCNT is 16-bit, so what if reload > 0x and reload & 0x == 0 ??? */
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 06:37 PM, Gilles Chanteperdrix wrote:
> On 05/05/2011 02:20 PM, Alexey Galakhov wrote:
>> Hi,
>>
>> I'm still trying to debug ipipe on the mini2440 board (linux 2.6.35.9 +
>> ipipe 1.18.01 + Gilles' ARM patches). Now I encounter the following
>> problem. If any Xenomai skin module is loaded the system hangs. In fact,
>> it goes into sleep with interrupts off.
>>
>> The sleep was in pm_idle() and it is done correctly. The problem lies
>> somewhere else. I tried to use busy-loop instead of sleep, like that:
>>
>> - if (hlt_counter) {
>> + if (1 || hlt_counter) {
>>
>> in cpu_idle() (arch/arm/kernel/process.c). Now I found that the loop
>> "while (!need_resched())" never exits, need_resched() is always
>> returning false and there are no interrupts. Looks like the timer
>> interrupt either stops ticking or is masked out since xenomai skin is
>> loaded.
>>
>> Can you please help to debug it?
> You should make sure that pm_idle == default_idle. In this case,
> __ipipe_halt_root is called instead of arch_idle, and everything should
> work.
I double-checked this. Yes, __ipipe_halt_root is called.
If I just run the kernel "as is", it hangs with the following stack:
s3c24xx_default_idle (sleep is done correctly, no IRQs are coming!)
arch_idle
__ipipe_halt_root
cpu_idle
To ensure the timer is not stopped when CPU going to sleep, I hacked
s3cxx_default_idle by replacing its entire contents with
for (i = 0; i < 1; ++i) { __asm__ __volatile__ ("nop"); }
return;
Now I'm sure timers aren't blocked by the sleep command. Now the
debugger shows that it enters __ipipe_halt_root and s3cxx_default_idle
over and over again, nothiung else seems to happen.
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] mini2440: ipipe kernel stuck in idle loop after xenomai init
On 05/05/2011 02:20 PM, Alexey Galakhov wrote:
> Hi,
>
> I'm still trying to debug ipipe on the mini2440 board (linux 2.6.35.9 +
> ipipe 1.18.01 + Gilles' ARM patches). Now I encounter the following
> problem. If any Xenomai skin module is loaded the system hangs. In fact,
> it goes into sleep with interrupts off.
>
> The sleep was in pm_idle() and it is done correctly. The problem lies
> somewhere else. I tried to use busy-loop instead of sleep, like that:
>
> - if (hlt_counter) {
> + if (1 || hlt_counter) {
>
> in cpu_idle() (arch/arm/kernel/process.c). Now I found that the loop
> "while (!need_resched())" never exits, need_resched() is always
> returning false and there are no interrupts. Looks like the timer
> interrupt either stops ticking or is masked out since xenomai skin is
> loaded.
>
> Can you please help to debug it?
You should make sure that pm_idle == default_idle. In this case,
__ipipe_halt_root is called instead of arch_idle, and everything should
work.
>
> --
> Alex
>
> ___
> Adeos-main mailing list
> Adeos-main@gna.org
> https://mail.gna.org/listinfo/adeos-main
>
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
