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

[Philippe Gerum <rpm@xenomai.org>]

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.