[Xenomai-core] Support for 2.6.22/x86

[Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

Our development trunk now contains the necessary support for running
Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
the generic clock event device abstraction that comes with newest
kernels. Other archs / kernel versions still work the older way, until
all archs eventually catch up with clockevents upstream.

This support won't be backported to 2.3.x, because it has some
significant impact on the nucleus. Tested as thoroughly as possible here
on low-end and mid-range x86 boxen, including SMP.

Please give this hell.

http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch

-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Philippe Gerum wrote:
> Our development trunk now contains the necessary support for running
> Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> the generic clock event device abstraction that comes with newest
> kernels. Other archs / kernel versions still work the older way, until
> all archs eventually catch up with clockevents upstream.
> 
> This support won't be backported to 2.3.x, because it has some
> significant impact on the nucleus. Tested as thoroughly as possible here
> on low-end and mid-range x86 boxen, including SMP.
> 
> Please give this hell.
> 
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> 

Running some tests, the gate to hell just opened:

[  210.247006] BUG: sleeping function called from invalid context at
kernel/sched.c:3941
[  210.248171] in_atomic():1, irqs_disabled():1
[  210.248828] no locks held by frag-ip/881.
[  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
[  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
[  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
[  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
[  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
[  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
[  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
[  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
[  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
[  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
[  210.260536]  [<c0102809>] system_call+0x29/0x41

Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.

However, this gremlin looks like it is /far/ older than 2.6.22 support.
Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
I'm afraid. :-/

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > Our development trunk now contains the necessary support for running
> > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > the generic clock event device abstraction that comes with newest
> > kernels. Other archs / kernel versions still work the older way, until
> > all archs eventually catch up with clockevents upstream.
> > 
> > This support won't be backported to 2.3.x, because it has some
> > significant impact on the nucleus. Tested as thoroughly as possible here
> > on low-end and mid-range x86 boxen, including SMP.
> > 
> > Please give this hell.
> > 
> > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> > 
> 
> Running some tests, the gate to hell just opened:
> 
> [  210.247006] BUG: sleeping function called from invalid context at
> kernel/sched.c:3941
> [  210.248171] in_atomic():1, irqs_disabled():1
> [  210.248828] no locks held by frag-ip/881.
> [  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
> [  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
> [  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
> [  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
> [  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
> [  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
> [  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
> [  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
> [  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
> [  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
> [  210.260536]  [<c0102809>] system_call+0x29/0x41
> 
> Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
> qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.
> 
> However, this gremlin looks like it is /far/ older than 2.6.22 support.
> Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
> I'm afraid. :-/

Why did we never get this migration case before? I'm running with all
debug knobs on too, and never hit this issue. Anyway... The APC
dispatcher does explicitly unlock the APC serialization lock. However,
the I-pipe syncer would stall the stage before calling the dispatcher,
so we need to bracket the dispatch loop within an unstall/stall block.
This said, I'm still wondering why the preemption is disabled here.

Do you happen to run with the tracer on when testing?

> 
> Jan
> 
-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > Our development trunk now contains the necessary support for running
> > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > the generic clock event device abstraction that comes with newest
> > kernels. Other archs / kernel versions still work the older way, until
> > all archs eventually catch up with clockevents upstream.
> > 
> > This support won't be backported to 2.3.x, because it has some
> > significant impact on the nucleus. Tested as thoroughly as possible here
> > on low-end and mid-range x86 boxen, including SMP.
> > 
> > Please give this hell.
> > 
> > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> > 
> 
> Running some tests, the gate to hell just opened:
> 
> [  210.247006] BUG: sleeping function called from invalid context at
> kernel/sched.c:3941
> [  210.248171] in_atomic():1, irqs_disabled():1
> [  210.248828] no locks held by frag-ip/881.
> [  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
> [  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
> [  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
> [  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
> [  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
> [  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
> [  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
> [  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
> [  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
> [  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
> [  210.260536]  [<c0102809>] system_call+0x29/0x41
> 
> Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
> qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.
> 
> However, this gremlin looks like it is /far/ older than 2.6.22 support.
> Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
> I'm afraid. :-/

Btw, you should have a look at a critical change in the way raw I-pipe
spinlocks are now manipulated (include/linux/spinlock.h wrappers).
In short, to solve a deadly bug in all previous implementations, a set
of dedicated helpers is now used to stall/unstall the current stage for
the spin_lock_irq* forms, the way it has to be, i.e. touching both the
real and virtual IRQ masks.

Such bug would accidentally clear the hardware IRQ mask, which would
lead to a recursive lock attempt whenever an interrupt is caught at the
wrong time on the same CPU, e.g.:

mask_and_ack_8259A
	local_irq_save_hw()+spinlock
	printk("spurious IRQ #...")
		printk() ->vprintk()
		...
		spin_lock_irqsave()
		spin_unlock_irqrestore()
			local_irq_enable_hw()
				<IRQ> -> mask_and_ack_8259A

The way to solve this is to make sure that the stall bit for the current
domain always reflects the state of the hardware mask when operating raw
I-pipe locks.

As a consequence of this, you may not assume anymore that calling
spin_unlock() + local_irq_restore_hw() in sequence would have the same
effect than calling spin_unlock_irqrestore() on any ipipe_spinlock_t
locks. This would have the very undesirable side-effect of leaving the
virtual IRQ mask in stalled mode. I fixed an issue of this kind in the
tracer code (__ipipe_global_path_unlock) already, precisely caught after
getting a might_sleep() warning when reading /proc/ipe/trace/{max,
frozen}.

So you may want to double-check whether some constructs of this kind
might exist in any of your local patches. I did not find any in the
vanilla code, but another round of verifications may be useful.

-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > Our development trunk now contains the necessary support for running
> > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > the generic clock event device abstraction that comes with newest
> > kernels. Other archs / kernel versions still work the older way, until
> > all archs eventually catch up with clockevents upstream.
> > 
> > This support won't be backported to 2.3.x, because it has some
> > significant impact on the nucleus. Tested as thoroughly as possible here
> > on low-end and mid-range x86 boxen, including SMP.
> > 
> > Please give this hell.
> > 
> > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> > 
> 
> Running some tests, the gate to hell just opened:
> 
> [  210.247006] BUG: sleeping function called from invalid context at
> kernel/sched.c:3941
> [  210.248171] in_atomic():1, irqs_disabled():1
> [  210.248828] no locks held by frag-ip/881.
> [  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
> [  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
> [  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
> [  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
> [  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
> [  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
> [  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
> [  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
> [  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
> [  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
> [  210.260536]  [<c0102809>] system_call+0x29/0x41
> 
> Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
> qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.
> 
> However, this gremlin looks like it is /far/ older than 2.6.22 support.
> Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
> I'm afraid. :-/
> 

Confirmed, this is an old bug. Just adding a might_sleep() statement
even in UP config inside the lostage handler would trigger the warning.

> Jan
> 
-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

On Sat, 2007-06-30 at 13:02 +0200, Philippe Gerum wrote:
> On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
> > Philippe Gerum wrote:
> > > Our development trunk now contains the necessary support for running
> > > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > > the generic clock event device abstraction that comes with newest
> > > kernels. Other archs / kernel versions still work the older way, until
> > > all archs eventually catch up with clockevents upstream.
> > > 
> > > This support won't be backported to 2.3.x, because it has some
> > > significant impact on the nucleus. Tested as thoroughly as possible here
> > > on low-end and mid-range x86 boxen, including SMP.
> > > 
> > > Please give this hell.
> > > 
> > > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> > > 
> > 
> > Running some tests, the gate to hell just opened:
> > 
> > [  210.247006] BUG: sleeping function called from invalid context at
> > kernel/sched.c:3941
> > [  210.248171] in_atomic():1, irqs_disabled():1
> > [  210.248828] no locks held by frag-ip/881.
> > [  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
> > [  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
> > [  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
> > [  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
> > [  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
> > [  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
> > [  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
> > [  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
> > [  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
> > [  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
> > [  210.260536]  [<c0102809>] system_call+0x29/0x41
> > 
> > Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
> > qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.
> > 
> > However, this gremlin looks like it is /far/ older than 2.6.22 support.
> > Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
> > I'm afraid. :-/
> > 
> 
> Confirmed, this is an old bug. Just adding a might_sleep() statement
> even in UP config inside the lostage handler would trigger the warning.

Ok, found it. It's an I-pipe issue. Working on a fix.

> 
> > Jan
> > 
-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

On Sat, 2007-06-30 at 16:26 +0200, Philippe Gerum wrote:
> On Sat, 2007-06-30 at 13:02 +0200, Philippe Gerum wrote:
> > On Sat, 2007-06-30 at 09:48 +0200, Jan Kiszka wrote:
> > > Philippe Gerum wrote:
> > > > Our development trunk now contains the necessary support for running
> > > > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > > > the generic clock event device abstraction that comes with newest
> > > > kernels. Other archs / kernel versions still work the older way, until
> > > > all archs eventually catch up with clockevents upstream.
> > > > 
> > > > This support won't be backported to 2.3.x, because it has some
> > > > significant impact on the nucleus. Tested as thoroughly as possible here
> > > > on low-end and mid-range x86 boxen, including SMP.
> > > > 
> > > > Please give this hell.
> > > > 
> > > > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> > > > 
> > > 
> > > Running some tests, the gate to hell just opened:
> > > 
> > > [  210.247006] BUG: sleeping function called from invalid context at
> > > kernel/sched.c:3941
> > > [  210.248171] in_atomic():1, irqs_disabled():1
> > > [  210.248828] no locks held by frag-ip/881.
> > > [  210.249494]  [<c01040e9>] show_trace_log_lvl+0x1f/0x34
> > > [  210.250523]  [<c0104d6c>] show_trace+0x17/0x19
> > > [  210.257778]  [<c0104e6a>] dump_stack+0x1b/0x1d
> > > [  210.258070]  [<c0112030>] __might_sleep+0xda/0xe1
> > > [  210.258365]  [<c028bacf>] wait_for_completion+0x1f/0xc3
> > > [  210.258688]  [<c01143d8>] set_cpus_allowed+0x77/0x95
> > > [  210.258992]  [<c89cc202>] lostage_handler+0x75/0x201 [xeno_nucleus]
> > > [  210.259551]  [<c0146fe2>] rthal_apc_handler+0x5c/0x89
> > > [  210.259869]  [<c0143ba9>] __ipipe_sync_stage+0x13a/0x147
> > > [  210.260204]  [<c010e6b6>] __ipipe_syscall_root+0x1a6/0x1c8
> > > [  210.260536]  [<c0102809>] system_call+0x29/0x41
> > > 
> > > Setup is latest SVN + a "few" patches (the well-known ones), CONFIG_SMP,
> > > qemu -smp 2, RTnet in loopback mode, just terminating the frag-ip example.
> > > 
> > > However, this gremlin looks like it is /far/ older than 2.6.22 support.
> > > Calling set_cpus_allowed() from atomic lostage_handler is simply bogus,
> > > I'm afraid. :-/
> > > 
> > 
> > Confirmed, this is an old bug. Just adding a might_sleep() statement
> > even in UP config inside the lostage handler would trigger the warning.
> 
> Ok, found it. It's an I-pipe issue. Working on a fix.

Well, it wasn't an I-pipe issue, even if simulating the hardirq context
(irq_enter/exit) also when running a virtual IRQ may be discussed,
compared to considering those as Linux softirqs; still, the logic is
correct.

Attempting to track CPU affinities over the lostage handler from the
nucleus was the wrong thing, and beyond that, the way it was done was
logically flawed, and pointless. #2687 should be better.

> 
> > 
> > > Jan
> > > 
-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Jim Cromie]

Philippe Gerum wrote:
> Our development trunk now contains the necessary support for running
> Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> the generic clock event device abstraction that comes with newest
> kernels. Other archs / kernel versions still work the older way, until
> all archs eventually catch up with clockevents upstream.
>
> This support won't be backported to 2.3.x, because it has some
> significant impact on the nucleus. Tested as thoroughly as possible here
> on low-end and mid-range x86 boxen, including SMP.
>
> Please give this hell.
>
> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
>
>   

Ive been running 22-rc7 on my Sony VAIO with this patch applied since 
July 3,

the only thing wrong Ive seen is that perl ( both bleed and maint )
is failing its time related regression tests.
ie
    rsync -avz rsync://public.activestate.com/perl-current/ .
    rsync -avz rsync://public.activestate.com/perl-5.8.x .

Failed 3 tests out of 1429, 99.79% okay.
        ../ext/Time/HiRes/t/HiRes.t
        ../lib/Benchmark.t
        op/time.t

the lib/Benchmark.t test is hanging, and must be killed manually.

These tests pass on Fedora -
Linux harpo.jimc.earth 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 
2007 i686 i686 i386 GNU/Linux

thanks

Re: [Xenomai-core] Support for 2.6.22/x86

[Philippe Gerum]

Hi Jim,

On Sun, 2007-07-08 at 01:00 -0600, Jim Cromie wrote:
> Philippe Gerum wrote:
> > Our development trunk now contains the necessary support for running
> > Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
> > the generic clock event device abstraction that comes with newest
> > kernels. Other archs / kernel versions still work the older way, until
> > all archs eventually catch up with clockevents upstream.
> >
> > This support won't be backported to 2.3.x, because it has some
> > significant impact on the nucleus. Tested as thoroughly as possible here
> > on low-end and mid-range x86 boxen, including SMP.
> >
> > Please give this hell.
> >
> > http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
> >
> >   
> 
> Ive been running 22-rc7 on my Sony VAIO with this patch applied since 
> July 3,
> 
> the only thing wrong Ive seen is that perl ( both bleed and maint )
> is failing its time related regression tests.
> ie
>     rsync -avz rsync://public.activestate.com/perl-current/ .
>     rsync -avz rsync://public.activestate.com/perl-5.8.x .
> 
> Failed 3 tests out of 1429, 99.79% okay.
>         ../ext/Time/HiRes/t/HiRes.t
>         ../lib/Benchmark.t
>         op/time.t
> 
> the lib/Benchmark.t test is hanging, and must be killed manually

Thanks for the feedback.

Does this happen with the I-pipe switched off too?
Also, is Xenomai patched in your kernel with any of the skins statically
enabled, or just the I-pipe?

> .
> 
> These tests pass on Fedora -
> Linux harpo.jimc.earth 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 
> 2007 i686 i686 i386 GNU/Linux
> 
> thanks
> 
-- 
Philippe.

Re: [Xenomai-core] Support for 2.6.22/x86

[Jim Cromie]

Philippe Gerum wrote:
> Hi Jim,
>
> On Sun, 2007-07-08 at 01:00 -0600, Jim Cromie wrote:
>   
>> Philippe Gerum wrote:
>>     
>>> Our development trunk now contains the necessary support for running
>>> Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
>>> the generic clock event device abstraction that comes with newest
>>> kernels. Other archs / kernel versions still work the older way, until
>>> all archs eventually catch up with clockevents upstream.
>>>
>>> This support won't be backported to 2.3.x, because it has some
>>> significant impact on the nucleus. Tested as thoroughly as possible here
>>> on low-end and mid-range x86 boxen, including SMP.
>>>
>>> Please give this hell.
>>>
>>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
>>>
>>>   
>>>       
>> Ive been running 22-rc7 on my Sony VAIO with this patch applied since 
>> July 3,
>>
>> the only thing wrong Ive seen is that perl ( both bleed and maint )
>> is failing its time related regression tests.
>> ie
>>     rsync -avz rsync://public.activestate.com/perl-current/ .
>>     rsync -avz rsync://public.activestate.com/perl-5.8.x .
>>
>> Failed 3 tests out of 1429, 99.79% okay.
>>         ../ext/Time/HiRes/t/HiRes.t
>>         ../lib/Benchmark.t
>>         op/time.t
>>
>> the lib/Benchmark.t test is hanging, and must be killed manually
>>     
>
> Thanks for the feedback.
>
> Does this happen with the I-pipe switched off too?
> Also, is Xenomai patched in your kernel with any of the skins statically
> enabled, or just the I-pipe?
>
>   

Im not sure what 'switched off' means, so heres the 'relevant' parts of 
the .config
Now that I look at it, Ive obviously not attended to the advice in 
README.INSTALL.

This config worked nicely with ntp, FWIW.

Given that this is a laptop, Id like to keep ACPI and/or CPU-freq if 
possible,
but I'll try some combos to see if any work for both the battery,
and for the perl tests.  I'll try a conservative/recommended config too.
Any suggestions or test-requests are welcome.


vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 1.70GHz
stepping        : 6
cpu MHz         : 1700.000


#
# Real-time sub-system
#

#
# WARNING! You enabled APM, CPU Frequency scaling or ACPI 'processor'
#

#
# option. These options are known to cause troubles with Xenomai.
#


[jimc@domain.hid linux-2.6.22-rc7-ipipe-190-sony]$ grep XENO .config
CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PRIOCPL=y
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set
CONFIG_XENO_HW_FPU=y
# CONFIG_XENO_HW_NMI_DEBUG_LATENCY is not set
# CONFIG_XENO_HW_SMI_DETECT_DISABLE is not set
CONFIG_XENO_HW_SMI_DETECT=y
# CONFIG_XENO_HW_SMI_WORKAROUND is not set
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_SKIN_RTAI is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
# CONFIG_XENO_DRIVERS_16550A is not set
# CONFIG_XENO_DRIVERS_TIMERBENCH is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
# CONFIG_XENO_DRIVERS_SWITCHTEST is not set
# CONFIG_XENO_DRIVERS_CAN is not set

[jimc@domain.hid linux-2.6.22-rc7-ipipe-190-sony]$ grep APM .config
# WARNING! You enabled APM, CPU Frequency scaling or ACPI 'processor'
# Power management options (ACPI, APM)
# CONFIG_APM is not set

[jimc@domain.hid linux-2.6.22-rc7-ipipe-190-sony]$ grep ACPI .config
# WARNING! You enabled APM, CPU Frequency scaling or ACPI 'processor'
# Power management options (ACPI, APM)
# ACPI (Advanced Configuration and Power Interface) Support
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_PNPACPI=y
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_BLK_DEV_IDEACPI is not set

[jimc@domain.hid linux-2.6.22-rc7-ipipe-190-sony]$ grep _PM .config
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_X86_PM_TIMER=y
# CONFIG_VIDEO_PMS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_PM3 is not set

Re: [Xenomai-core] Support for 2.6.22/x86

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]

Jim Cromie wrote:
> Philippe Gerum wrote:
>> Hi Jim,
>>
>> On Sun, 2007-07-08 at 01:00 -0600, Jim Cromie wrote:
>>   
>>> Philippe Gerum wrote:
>>>     
>>>> Our development trunk now contains the necessary support for running
>>>> Xenomai over 2.6.22/x86. This work boils down to enabling Xenomai to use
>>>> the generic clock event device abstraction that comes with newest
>>>> kernels. Other archs / kernel versions still work the older way, until
>>>> all archs eventually catch up with clockevents upstream.
>>>>
>>>> This support won't be backported to 2.3.x, because it has some
>>>> significant impact on the nucleus. Tested as thoroughly as possible here
>>>> on low-end and mid-range x86 boxen, including SMP.
>>>>
>>>> Please give this hell.
>>>>
>>>> http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.22-rc6-i386-1.9-00.patch
>>>>
>>>>   
>>>>       
>>> Ive been running 22-rc7 on my Sony VAIO with this patch applied since 
>>> July 3,
>>>
>>> the only thing wrong Ive seen is that perl ( both bleed and maint )
>>> is failing its time related regression tests.
>>> ie
>>>     rsync -avz rsync://public.activestate.com/perl-current/ .
>>>     rsync -avz rsync://public.activestate.com/perl-5.8.x .
>>>
>>> Failed 3 tests out of 1429, 99.79% okay.
>>>         ../ext/Time/HiRes/t/HiRes.t
>>>         ../lib/Benchmark.t
>>>         op/time.t
>>>
>>> the lib/Benchmark.t test is hanging, and must be killed manually
>>>     
>> Thanks for the feedback.
>>
>> Does this happen with the I-pipe switched off too?
>> Also, is Xenomai patched in your kernel with any of the skins statically
>> enabled, or just the I-pipe?
>>
>>   
> 
> Im not sure what 'switched off' means, so heres the 'relevant' parts of 

There are a few stages of Xenomai/I-pipe support we usually test when
weird this come up:

1. Xenomai fully enabled and running (like you probably did)
2. Xenomai enabled, but no skin loaded (=> all skins must be modular)
3. Xenomai disabled in the .config, only I-pipe
4. I-pipe patched in but disabled (under "Processor types and features")
5. Vanilla kernel (but otherwise identical .config)

There is no strict order what to try first. It rather depends on
intuition and the compilation time you want to invest (fiddling with
CONFIG_IPIPE means full kernel rebuild).

> the .config
> Now that I look at it, Ive obviously not attended to the advice in 
> README.INSTALL.
> 
> This config worked nicely with ntp, FWIW.
> 
> Given that this is a laptop, Id like to keep ACPI and/or CPU-freq if 
> possible,

ACPI is OK (except ACPI_PROCESSOR), but CPU_FREQ is a no-go for Xenomai
unless you force the frequency governor into the fixed maximum
performance mode (which means at least temporary CPU_FREQ off).
Otherwise, Xenomai timing will by totally screwed up.

> but I'll try some combos to see if any work for both the battery,
> and for the perl tests.  I'll try a conservative/recommended config too.
> Any suggestions or test-requests are welcome.
> 

First of all, it would be good to identify which stage of Xenomai
support (see above) breaks your test case. Then, as it seems to be some
timer issue, you could try to use kernel timer debugging features. E.g.
have a look /proc/timer_list. Is there your perl test stalled on some
timer, maybe with a silly expiry date? What does strace report if you
let your test run over it, ie. which syscall does not return?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]