Re: [Xenomai-core] Support for 2.6.22/x86
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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. # [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 CON
Re: [Xenomai-core] Support for 2.6.22/x86
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34 > > > [ 210.250523] [] show_trace+0x17/0x19 > > > [ 210.257778] [] dump_stack+0x1b/0x1d > > > [ 210.258070] [] __might_sleep+0xda/0xe1 > > > [ 210.258365] [] wait_for_completion+0x1f/0xc3 > > > [ 210.258688] [] set_cpus_allowed+0x77/0x95 > > > [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus] > > > [ 210.259551] [] rthal_apc_handler+0x5c/0x89 > > > [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147 > > > [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8 > > > [ 210.260536] [] 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34 > > [ 210.250523] [] show_trace+0x17/0x19 > > [ 210.257778] [] dump_stack+0x1b/0x1d > > [ 210.258070] [] __might_sleep+0xda/0xe1 > > [ 210.258365] [] wait_for_completion+0x1f/0xc3 > > [ 210.258688] [] set_cpus_allowed+0x77/0x95 > > [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus] > > [ 210.259551] [] rthal_apc_handler+0x5c/0x89 > > [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147 > > [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8 > > [ 210.260536] [] 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34 > [ 210.250523] [] show_trace+0x17/0x19 > [ 210.257778] [] dump_stack+0x1b/0x1d > [ 210.258070] [] __might_sleep+0xda/0xe1 > [ 210.258365] [] wait_for_completion+0x1f/0xc3 > [ 210.258688] [] set_cpus_allowed+0x77/0x95 > [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus] > [ 210.259551] [] rthal_apc_handler+0x5c/0x89 > [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147 > [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8 > [ 210.260536] [] 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34
> [ 210.250523] [] show_trace+0x17/0x19
> [ 210.257778] [] dump_stack+0x1b/0x1d
> [ 210.258070] [] __might_sleep+0xda/0xe1
> [ 210.258365] [] wait_for_completion+0x1f/0xc3
> [ 210.258688] [] set_cpus_allowed+0x77/0x95
> [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus]
> [ 210.259551] [] rthal_apc_handler+0x5c/0x89
> [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147
> [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8
> [ 210.260536] [] 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()
-> 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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34 > [ 210.250523] [] show_trace+0x17/0x19 > [ 210.257778] [] dump_stack+0x1b/0x1d > [ 210.258070] [] __might_sleep+0xda/0xe1 > [ 210.258365] [] wait_for_completion+0x1f/0xc3 > [ 210.258688] [] set_cpus_allowed+0x77/0x95 > [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus] > [ 210.259551] [] rthal_apc_handler+0x5c/0x89 > [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147 > [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8 > [ 210.260536] [] 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.22/x86
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] [] show_trace_log_lvl+0x1f/0x34 [ 210.250523] [] show_trace+0x17/0x19 [ 210.257778] [] dump_stack+0x1b/0x1d [ 210.258070] [] __might_sleep+0xda/0xe1 [ 210.258365] [] wait_for_completion+0x1f/0xc3 [ 210.258688] [] set_cpus_allowed+0x77/0x95 [ 210.258992] [] lostage_handler+0x75/0x201 [xeno_nucleus] [ 210.259551] [] rthal_apc_handler+0x5c/0x89 [ 210.259869] [] __ipipe_sync_stage+0x13a/0x147 [ 210.260204] [] __ipipe_syscall_root+0x1a6/0x1c8 [ 210.260536] [] 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Support for 2.6.22/x86
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
