* [Xenomai] I-pipe on ARM platform.
@ 2013-04-04 20:58 Gilles Chanteperdrix
2013-04-06 9:48 ` Jan Kiszka
0 siblings, 1 reply; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-04 20:58 UTC (permalink / raw)
To: Xenomai
Hi,
The for-core-3.5.7 and for-core-3.8.2 branches in ipipe_gch.git
repository contain new versions of the I-pipe kernel for the ARM
architecture.
The for-core-3.5.7 branch contains an important fix for SMP platforms,
and the fix for mx28 posted by Martin Krause.
The for-core-3.8.2 branch is the newest port. Known issues are:
- it has been rebased on v3.8.2, so it will not merge with the branch
it started from, if preferred, I can push a merged version;
- ftrace is broken, so I wonder if it would not be simpler to have a
tracer not relying on ftrace, as we did at the beginning of the I-pipe
tracer;
- threaded fasteoi irqs are broken, the branch contains the latest
patch posted on this list, but since I received no comment, I am not
sure it is the right fix.
The pull requests follow.
The following changes since commit 946ca3977e75316751caecc7182f4e64af6499d5:
ipipe-core-3.5.7-blackfin-3 (2013-01-22 11:41:34 +0100)
are available in the git repository at:
git://git.xenomai.org/ipipe-gch.git for-core-3.5.7
Gilles Chanteperdrix (2):
arm/ipipe: fix off-by-one error in IPI virqs allocation
mx28/ipipe: allow building kernel for both mx28 and mx23
Martin Krause (1):
mx28/ipipe: fix the timer selected with I-pipe
arch/arm/kernel/smp.c | 2 +-
arch/arm/mach-mxs/timer.c | 40 ++++++++++++++++------------------------
drivers/clk/mxs/clk-imx28.c | 4 ++++
3 files changed, 21 insertions(+), 25 deletions(-)
The following changes since commit 5a16a5a4dd127afcb2446afa057b55a60cffe7f9:
blackfin/ipipe: import arch-dep bits based on 3.5.7-blackfin-3 (2013-04-04 21:37:51 +0200)
are available in the git repository at:
git://git.xenomai.org/ipipe-gch.git for-core-3.8.2
Gilles Chanteperdrix (18):
avoid kernel fault upon coredump on arm with vivt cache
FCSE: pid life cycle
FCSE: Conversions between VA and MVA
FCSE: Address-space limits
FCSE: Make the shared mappings uncacheable
FCSE: do not flush cache during context switch
"Best-effort" FCSE: choose whether to flush cache at run-time
"Best-effort" FCSE: Allow PID re-use
"Best-effort" FCSE: Handle mappings above 32 MB
"Best effort" FCSE: Reserve address-space for stack
"Best-effort" FCSE: Handle shared mappings
FCSE: add Makefile and compilation option
noarch/ipipe: fix ipipe_update_hostrt
noarch/ipipe: fix one-shot fasteoi irq
noarch/ipipe: introduce IPIPE_NR_ROOT_IRQS
arm/ipipe: import arch-dep bits based on 3.5.7-arm-3
arm/ipipe: avoid calling might_fault() with non-root domains
mx28/ipipe: allow building kernel for both mx28 and mx23
Martin Krause (1):
mx28/ipipe: fix the timer selected with I-pipe
arch/arm/Kconfig | 13 +
arch/arm/boot/compressed/decompress.c | 4 +-
arch/arm/boot/compressed/head.S | 9 +
arch/arm/boot/compressed/string.c | 17 +
arch/arm/common/gic.c | 117 ++++-
arch/arm/common/it8152.c | 7 +-
arch/arm/common/timer-sp.c | 47 ++-
arch/arm/common/vic.c | 6 +-
arch/arm/include/asm/Kbuild | 1 -
arch/arm/include/asm/assembler.h | 28 +-
arch/arm/include/asm/atomic.h | 16 +-
arch/arm/include/asm/bitops.h | 24 +-
arch/arm/include/asm/bug.h | 1 +
arch/arm/include/asm/cacheflush.h | 76 +++-
arch/arm/include/asm/cmpxchg.h | 8 +-
arch/arm/include/asm/entry-macro-multi.S | 8 +
arch/arm/include/asm/fcse.h | 188 +++++++
arch/arm/include/asm/hardware/timer-sp.h | 9 +-
arch/arm/include/asm/ipipe.h | 270 ++++++++++
arch/arm/include/asm/ipipe_base.h | 147 ++++++
arch/arm/include/asm/ipipe_hwirq.h | 269 ++++++++++
arch/arm/include/asm/irq.h | 6 +-
arch/arm/include/asm/irqflags.h | 5 +
arch/arm/include/asm/memory.h | 5 +
arch/arm/include/asm/mmu.h | 11 +
arch/arm/include/asm/mmu_context.h | 156 +++++-
arch/arm/include/asm/percpu.h | 6 +-
arch/arm/include/asm/pgtable.h | 61 ++-
arch/arm/include/asm/proc-fns.h | 23 +-
arch/arm/include/asm/processor.h | 5 +
arch/arm/include/asm/resource.h | 16 +
arch/arm/include/asm/switch_to.h | 9 +
arch/arm/include/asm/thread_info.h | 15 +
arch/arm/include/asm/tlbflush.h | 14 +-
arch/arm/include/asm/uaccess.h | 16 +-
arch/arm/include/uapi/asm/mman.h | 2 +
arch/arm/kernel/Makefile | 2 +
arch/arm/kernel/entry-armv.S | 107 ++++-
arch/arm/kernel/entry-common.S | 69 +++-
arch/arm/kernel/entry-header.S | 48 ++-
arch/arm/kernel/ipipe.c | 596 ++++++++++++++++++++++
arch/arm/kernel/ipipe_tsc.c | 164 ++++++
arch/arm/kernel/ipipe_tsc_asm.S | 246 +++++++++
arch/arm/kernel/process.c | 46 ++-
arch/arm/kernel/ptrace.c | 4 +
arch/arm/kernel/setup.c | 13 +-
arch/arm/kernel/signal.c | 6 +-
arch/arm/kernel/smp.c | 122 ++++-
arch/arm/kernel/smp_twd.c | 110 ++++-
arch/arm/kernel/suspend.c | 2 +-
arch/arm/kernel/traps.c | 24 +
arch/arm/mach-at91/Kconfig | 21 +-
arch/arm/mach-at91/Makefile | 2 +
arch/arm/mach-at91/at91_ipipe.c | 260 ++++++++++
arch/arm/mach-at91/at91_ipipe.h | 19 +
arch/arm/mach-at91/at91rm9200.c | 51 ++
arch/arm/mach-at91/at91rm9200_time.c | 5 +-
arch/arm/mach-at91/at91sam9260.c | 52 ++
arch/arm/mach-at91/at91sam9261.c | 51 ++
arch/arm/mach-at91/at91sam9263.c | 51 ++
arch/arm/mach-at91/at91sam926x_time.c | 4 +
arch/arm/mach-at91/at91sam9g45.c | 53 ++
arch/arm/mach-at91/at91sam9rl.c | 51 ++
arch/arm/mach-at91/at91x40.c | 2 +
arch/arm/mach-at91/at91x40_time.c | 3 +-
arch/arm/mach-at91/clock.c | 2 +
arch/arm/mach-at91/gpio.c | 130 +++++-
arch/arm/mach-at91/include/mach/hardware.h | 21 +
arch/arm/mach-at91/irq.c | 45 ++-
arch/arm/mach-highbank/highbank.c | 7 +-
arch/arm/mach-imx/3ds_debugboard.c | 3 +-
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/avic.c | 5 +-
arch/arm/mach-imx/clk-imx1.c | 3 +-
arch/arm/mach-imx/clk-imx21.c | 3 +-
arch/arm/mach-imx/clk-imx25.c | 11 +-
arch/arm/mach-imx/clk-imx27.c | 3 +-
arch/arm/mach-imx/clk-imx31.c | 3 +-
arch/arm/mach-imx/clk-imx35.c | 6 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 10 +-
arch/arm/mach-imx/clk-imx6q.c | 9 +-
arch/arm/mach-imx/common.h | 3 +-
arch/arm/mach-imx/cpu.c | 2 +-
arch/arm/mach-imx/mach-imx6q.c | 4 +
arch/arm/mach-imx/mach-mx31_3ds.c | 1 +
arch/arm/mach-imx/mach-mx31ads.c | 3 +-
arch/arm/mach-imx/mm-imx1.c | 1 +
arch/arm/mach-imx/mm-imx25.c | 7 +
arch/arm/mach-imx/mm-imx27.c | 13 +
arch/arm/mach-imx/mm-imx3.c | 8 +
arch/arm/mach-imx/time.c | 63 ++-
arch/arm/mach-imx/tzic.c | 31 ++-
arch/arm/mach-integrator/common.h | 2 +-
arch/arm/mach-integrator/core.c | 1 +
arch/arm/mach-integrator/include/mach/platform.h | 2 +-
arch/arm/mach-integrator/include/mach/timex.h | 4 +-
arch/arm/mach-integrator/integrator_cp.c | 3 +-
arch/arm/mach-ixp4xx/common.c | 57 ++-
arch/arm/mach-ixp4xx/include/mach/platform.h | 15 +-
arch/arm/mach-mxs/Kconfig | 1 +
arch/arm/mach-mxs/icoll.c | 13 +
arch/arm/mach-mxs/timer.c | 80 +++-
arch/arm/mach-omap2/gpmc.c | 3 +-
arch/arm/mach-omap2/io.c | 7 +
arch/arm/mach-omap2/irq.c | 56 ++-
arch/arm/mach-omap2/mux.c | 5 +-
arch/arm/mach-omap2/omap-wakeupgen.c | 2 +
arch/arm/mach-omap2/pm34xx.c | 3 +
arch/arm/mach-omap2/pm44xx.c | 6 +-
arch/arm/mach-omap2/prm_common.c | 4 +-
arch/arm/mach-omap2/timer.c | 182 +++++++-
arch/arm/mach-pxa/irq.c | 7 +-
arch/arm/mach-pxa/lpd270.c | 3 +-
arch/arm/mach-pxa/lubbock.c | 3 +-
arch/arm/mach-pxa/mainstone.c | 5 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 3 +-
arch/arm/mach-pxa/time.c | 46 ++-
arch/arm/mach-pxa/viper.c | 7 +-
arch/arm/mach-realview/core.c | 9 +-
arch/arm/mach-realview/core.h | 1 +
arch/arm/mach-realview/realview_eb.c | 1 +
arch/arm/mach-realview/realview_pb1176.c | 1 +
arch/arm/mach-realview/realview_pb11mp.c | 1 +
arch/arm/mach-realview/realview_pba8.c | 1 +
arch/arm/mach-realview/realview_pbx.c | 1 +
arch/arm/mach-s3c24xx/bast-irq.c | 3 +-
arch/arm/mach-s3c24xx/irq-s3c2412.c | 5 +-
arch/arm/mach-s3c24xx/irq-s3c2416.c | 3 +-
arch/arm/mach-s3c24xx/irq-s3c2440.c | 5 +-
arch/arm/mach-s3c24xx/irq-s3c2443.c | 3 +-
arch/arm/mach-s3c24xx/irq-s3c244x.c | 5 +-
arch/arm/mach-sa1100/irq.c | 8 +-
arch/arm/mach-sa1100/time.c | 45 ++-
arch/arm/mach-versatile/core.c | 10 +-
arch/arm/mach-vexpress/v2m.c | 3 +-
arch/arm/mm/Kconfig | 73 +++
arch/arm/mm/Makefile | 1 +
arch/arm/mm/alignment.c | 11 +-
arch/arm/mm/cache-l2x0.c | 20 +-
arch/arm/mm/context.c | 10 +-
arch/arm/mm/copypage-v4mc.c | 2 +-
arch/arm/mm/copypage-xscale.c | 2 +-
arch/arm/mm/fault-armv.c | 33 ++
arch/arm/mm/fault.c | 112 ++++-
arch/arm/mm/fcse.c | 444 ++++++++++++++++
arch/arm/mm/flush.c | 3 +-
arch/arm/mm/idmap.c | 2 +-
arch/arm/mm/ioremap.c | 1 +
arch/arm/mm/mmap.c | 53 ++-
arch/arm/mm/pgd.c | 53 ++-
arch/arm/mm/proc-arm920.S | 9 +
arch/arm/mm/proc-arm926.S | 9 +
arch/arm/mm/proc-feroceon.S | 13 +
arch/arm/mm/proc-xscale.S | 9 +
arch/arm/plat-omap/dmtimer.c | 16 +-
arch/arm/plat-omap/include/plat/dmtimer.h | 6 +
arch/arm/plat-s3c24xx/irq.c | 37 +-
arch/arm/plat-samsung/include/plat/gpio-core.h | 2 +-
arch/arm/plat-samsung/time.c | 214 +++++++--
arch/arm/plat-spear/time.c | 88 +++-
arch/arm/vfp/entry.S | 3 +-
arch/arm/vfp/vfphw.S | 26 +-
arch/arm/vfp/vfpmodule.c | 49 ++-
drivers/clk/mxs/clk-imx28.c | 4 +
drivers/gpio/gpio-mxc.c | 125 +++++-
drivers/gpio/gpio-omap.c | 199 +++++++-
drivers/gpio/gpio-pxa.c | 5 +-
drivers/gpio/gpio-sa1100.c | 8 +-
drivers/irqchip/irq-versatile-fpga.c | 7 +-
drivers/irqchip/spear-shirq.c | 7 +-
drivers/mfd/twl4030-irq.c | 1 +
drivers/mfd/twl6030-irq.c | 8 +-
drivers/misc/Kconfig | 14 +-
include/linux/ipipe_base.h | 4 +
kernel/ipipe/core.c | 8 +-
kernel/ipipe/timer.c | 6 +-
kernel/irq/chip.c | 12 +-
kernel/irq/manage.c | 5 +
mm/mmap.c | 4 +
179 files changed, 6125 insertions(+), 415 deletions(-)
create mode 100644 arch/arm/include/asm/fcse.h
create mode 100644 arch/arm/include/asm/ipipe.h
create mode 100644 arch/arm/include/asm/ipipe_base.h
create mode 100644 arch/arm/include/asm/ipipe_hwirq.h
create mode 100644 arch/arm/include/asm/resource.h
create mode 100644 arch/arm/kernel/ipipe.c
create mode 100644 arch/arm/kernel/ipipe_tsc.c
create mode 100644 arch/arm/kernel/ipipe_tsc_asm.S
create mode 100644 arch/arm/mach-at91/at91_ipipe.c
create mode 100644 arch/arm/mach-at91/at91_ipipe.h
create mode 100644 arch/arm/mm/fcse.c
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-04 20:58 [Xenomai] I-pipe on ARM platform Gilles Chanteperdrix
@ 2013-04-06 9:48 ` Jan Kiszka
2013-04-06 13:24 ` Philippe Gerum
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Jan Kiszka @ 2013-04-06 9:48 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai
On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>
> Hi,
>
> The for-core-3.5.7 and for-core-3.8.2 branches in ipipe_gch.git
> repository contain new versions of the I-pipe kernel for the ARM
> architecture.
>
> The for-core-3.5.7 branch contains an important fix for SMP platforms,
> and the fix for mx28 posted by Martin Krause.
>
> The for-core-3.8.2 branch is the newest port. Known issues are:
> - it has been rebased on v3.8.2, so it will not merge with the branch
> it started from, if preferred, I can push a merged version;
> - ftrace is broken, so I wonder if it would not be simpler to have a
> tracer not relying on ftrace, as we did at the beginning of the I-pipe
> tracer;
> - threaded fasteoi irqs are broken, the branch contains the latest
> patch posted on this list, but since I received no comment, I am not
> sure it is the right fix.
>
> The pull requests follow.
> The following changes since commit 946ca3977e75316751caecc7182f4e64af6499d5:
>
> ipipe-core-3.5.7-blackfin-3 (2013-01-22 11:41:34 +0100)
>
> are available in the git repository at:
> git://git.xenomai.org/ipipe-gch.git for-core-3.5.7
>
> Gilles Chanteperdrix (2):
> arm/ipipe: fix off-by-one error in IPI virqs allocation
> mx28/ipipe: allow building kernel for both mx28 and mx23
>
> Martin Krause (1):
> mx28/ipipe: fix the timer selected with I-pipe
>
> arch/arm/kernel/smp.c | 2 +-
> arch/arm/mach-mxs/timer.c | 40 ++++++++++++++++------------------------
> drivers/clk/mxs/clk-imx28.c | 4 ++++
> 3 files changed, 21 insertions(+), 25 deletions(-)
>
>
> The following changes since commit 5a16a5a4dd127afcb2446afa057b55a60cffe7f9:
>
> blackfin/ipipe: import arch-dep bits based on 3.5.7-blackfin-3 (2013-04-04 21:37:51 +0200)
>
> are available in the git repository at:
> git://git.xenomai.org/ipipe-gch.git for-core-3.8.2
>
> Gilles Chanteperdrix (18):
> avoid kernel fault upon coredump on arm with vivt cache
> FCSE: pid life cycle
> FCSE: Conversions between VA and MVA
> FCSE: Address-space limits
> FCSE: Make the shared mappings uncacheable
> FCSE: do not flush cache during context switch
> "Best-effort" FCSE: choose whether to flush cache at run-time
> "Best-effort" FCSE: Allow PID re-use
> "Best-effort" FCSE: Handle mappings above 32 MB
> "Best effort" FCSE: Reserve address-space for stack
> "Best-effort" FCSE: Handle shared mappings
> FCSE: add Makefile and compilation option
> noarch/ipipe: fix ipipe_update_hostrt
> noarch/ipipe: fix one-shot fasteoi irq
> noarch/ipipe: introduce IPIPE_NR_ROOT_IRQS
^^^^^^
I'm tagging generic patches just with "ipipe:". IIRC, this is what
Philippe requested.
> arm/ipipe: import arch-dep bits based on 3.5.7-arm-3
> arm/ipipe: avoid calling might_fault() with non-root domains
I think ipipe_uaccess_might_fault could become a generic service in case
other archs need it as well. And it has to map directly to might_fault
in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130406/cf16b7c3/attachment.pgp>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-06 9:48 ` Jan Kiszka
@ 2013-04-06 13:24 ` Philippe Gerum
2013-04-06 18:27 ` Gilles Chanteperdrix
2013-04-07 16:55 ` Gilles Chanteperdrix
2 siblings, 0 replies; 14+ messages in thread
From: Philippe Gerum @ 2013-04-06 13:24 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/06/2013 11:48 AM, Jan Kiszka wrote:
> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> The for-core-3.5.7 and for-core-3.8.2 branches in ipipe_gch.git
>> repository contain new versions of the I-pipe kernel for the ARM
>> architecture.
>>
>> The for-core-3.5.7 branch contains an important fix for SMP platforms,
>> and the fix for mx28 posted by Martin Krause.
>>
>> The for-core-3.8.2 branch is the newest port. Known issues are:
>> - it has been rebased on v3.8.2, so it will not merge with the branch
>> it started from, if preferred, I can push a merged version;
>> - ftrace is broken, so I wonder if it would not be simpler to have a
>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>> tracer;
>> - threaded fasteoi irqs are broken, the branch contains the latest
>> patch posted on this list, but since I received no comment, I am not
>> sure it is the right fix.
>>
>> The pull requests follow.
>> The following changes since commit 946ca3977e75316751caecc7182f4e64af6499d5:
>>
>> ipipe-core-3.5.7-blackfin-3 (2013-01-22 11:41:34 +0100)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.5.7
>>
>> Gilles Chanteperdrix (2):
>> arm/ipipe: fix off-by-one error in IPI virqs allocation
>> mx28/ipipe: allow building kernel for both mx28 and mx23
>>
>> Martin Krause (1):
>> mx28/ipipe: fix the timer selected with I-pipe
>>
>> arch/arm/kernel/smp.c | 2 +-
>> arch/arm/mach-mxs/timer.c | 40 ++++++++++++++++------------------------
>> drivers/clk/mxs/clk-imx28.c | 4 ++++
>> 3 files changed, 21 insertions(+), 25 deletions(-)
>>
>>
>> The following changes since commit 5a16a5a4dd127afcb2446afa057b55a60cffe7f9:
>>
>> blackfin/ipipe: import arch-dep bits based on 3.5.7-blackfin-3 (2013-04-04 21:37:51 +0200)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.8.2
>>
>> Gilles Chanteperdrix (18):
>> avoid kernel fault upon coredump on arm with vivt cache
>> FCSE: pid life cycle
>> FCSE: Conversions between VA and MVA
>> FCSE: Address-space limits
>> FCSE: Make the shared mappings uncacheable
>> FCSE: do not flush cache during context switch
>> "Best-effort" FCSE: choose whether to flush cache at run-time
>> "Best-effort" FCSE: Allow PID re-use
>> "Best-effort" FCSE: Handle mappings above 32 MB
>> "Best effort" FCSE: Reserve address-space for stack
>> "Best-effort" FCSE: Handle shared mappings
>> FCSE: add Makefile and compilation option
>> noarch/ipipe: fix ipipe_update_hostrt
>> noarch/ipipe: fix one-shot fasteoi irq
>> noarch/ipipe: introduce IPIPE_NR_ROOT_IRQS
> ^^^^^^
> I'm tagging generic patches just with "ipipe:". IIRC, this is what
> Philippe requested.
Yes please.
>
>> arm/ipipe: import arch-dep bits based on 3.5.7-arm-3
>> arm/ipipe: avoid calling might_fault() with non-root domains
>
> I think ipipe_uaccess_might_fault could become a generic service in case
> other archs need it as well. And it has to map directly to might_fault
> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>
I need this for ppc too, so this makes sense to factor this out.
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-06 9:48 ` Jan Kiszka
2013-04-06 13:24 ` Philippe Gerum
@ 2013-04-06 18:27 ` Gilles Chanteperdrix
2013-04-06 18:32 ` Jan Kiszka
2013-04-07 16:55 ` Gilles Chanteperdrix
2 siblings, 1 reply; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-06 18:27 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/06/2013 11:48 AM, Jan Kiszka wrote:
> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> The for-core-3.5.7 and for-core-3.8.2 branches in ipipe_gch.git
>> repository contain new versions of the I-pipe kernel for the ARM
>> architecture.
>>
>> The for-core-3.5.7 branch contains an important fix for SMP platforms,
>> and the fix for mx28 posted by Martin Krause.
>>
>> The for-core-3.8.2 branch is the newest port. Known issues are:
>> - it has been rebased on v3.8.2, so it will not merge with the branch
>> it started from, if preferred, I can push a merged version;
>> - ftrace is broken, so I wonder if it would not be simpler to have a
>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>> tracer;
>> - threaded fasteoi irqs are broken, the branch contains the latest
>> patch posted on this list, but since I received no comment, I am not
>> sure it is the right fix.
>>
>> The pull requests follow.
>> The following changes since commit 946ca3977e75316751caecc7182f4e64af6499d5:
>>
>> ipipe-core-3.5.7-blackfin-3 (2013-01-22 11:41:34 +0100)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.5.7
>>
>> Gilles Chanteperdrix (2):
>> arm/ipipe: fix off-by-one error in IPI virqs allocation
>> mx28/ipipe: allow building kernel for both mx28 and mx23
>>
>> Martin Krause (1):
>> mx28/ipipe: fix the timer selected with I-pipe
>>
>> arch/arm/kernel/smp.c | 2 +-
>> arch/arm/mach-mxs/timer.c | 40 ++++++++++++++++------------------------
>> drivers/clk/mxs/clk-imx28.c | 4 ++++
>> 3 files changed, 21 insertions(+), 25 deletions(-)
>>
>>
>> The following changes since commit 5a16a5a4dd127afcb2446afa057b55a60cffe7f9:
>>
>> blackfin/ipipe: import arch-dep bits based on 3.5.7-blackfin-3 (2013-04-04 21:37:51 +0200)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.8.2
>>
>> Gilles Chanteperdrix (18):
>> avoid kernel fault upon coredump on arm with vivt cache
>> FCSE: pid life cycle
>> FCSE: Conversions between VA and MVA
>> FCSE: Address-space limits
>> FCSE: Make the shared mappings uncacheable
>> FCSE: do not flush cache during context switch
>> "Best-effort" FCSE: choose whether to flush cache at run-time
>> "Best-effort" FCSE: Allow PID re-use
>> "Best-effort" FCSE: Handle mappings above 32 MB
>> "Best effort" FCSE: Reserve address-space for stack
>> "Best-effort" FCSE: Handle shared mappings
>> FCSE: add Makefile and compilation option
>> noarch/ipipe: fix ipipe_update_hostrt
>> noarch/ipipe: fix one-shot fasteoi irq
>> noarch/ipipe: introduce IPIPE_NR_ROOT_IRQS
> ^^^^^^
> I'm tagging generic patches just with "ipipe:". IIRC, this is what
> Philippe requested.
>
>> arm/ipipe: import arch-dep bits based on 3.5.7-arm-3
>> arm/ipipe: avoid calling might_fault() with non-root domains
>
> I think ipipe_uaccess_might_fault could become a generic service in case
> other archs need it as well.
Ok.
> And it has to map directly to might_fault
> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
That would defeat the purpose of the patch. might_fault can not be
called over non root domains.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-06 18:27 ` Gilles Chanteperdrix
@ 2013-04-06 18:32 ` Jan Kiszka
2013-04-07 15:10 ` Gilles Chanteperdrix
0 siblings, 1 reply; 14+ messages in thread
From: Jan Kiszka @ 2013-04-06 18:32 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai
On 2013-04-06 20:27, Gilles Chanteperdrix wrote:
>> And it has to map directly to might_fault
>> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>
> That would defeat the purpose of the patch. might_fault can not be
> called over non root domains.
True. But we should avoid leaving the costly irq-disable/enable and
domain checks in production code behind when might_fault actually
resolves to a nop. That should be the case for
!CONFIG_DEBUG_ATOMIC_SLEEP && !CONFIG_PROVE_LOCKING.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130406/8620c91d/attachment.pgp>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-06 18:32 ` Jan Kiszka
@ 2013-04-07 15:10 ` Gilles Chanteperdrix
2013-04-07 15:13 ` Gilles Chanteperdrix
2013-04-07 15:14 ` Jan Kiszka
0 siblings, 2 replies; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 15:10 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/06/2013 08:32 PM, Jan Kiszka wrote:
> On 2013-04-06 20:27, Gilles Chanteperdrix wrote:
>>> And it has to map directly to might_fault
>>> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>>
>> That would defeat the purpose of the patch. might_fault can not be
>> called over non root domains.
>
> True. But we should avoid leaving the costly irq-disable/enable and
> domain checks in production code behind when might_fault actually
> resolves to a nop. That should be the case for
> !CONFIG_DEBUG_ATOMIC_SLEEP && !CONFIG_PROVE_LOCKING.
I am almost sure I did not have either of these two options enabled when
I observed the bug.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 15:10 ` Gilles Chanteperdrix
@ 2013-04-07 15:13 ` Gilles Chanteperdrix
2013-04-07 15:14 ` Jan Kiszka
1 sibling, 0 replies; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 15:13 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/07/2013 05:10 PM, Gilles Chanteperdrix wrote:
> On 04/06/2013 08:32 PM, Jan Kiszka wrote:
>
>> On 2013-04-06 20:27, Gilles Chanteperdrix wrote:
>>>> And it has to map directly to might_fault
>>>> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>>>
>>> That would defeat the purpose of the patch. might_fault can not be
>>> called over non root domains.
>>
>> True. But we should avoid leaving the costly irq-disable/enable and
>> domain checks in production code behind when might_fault actually
>> resolves to a nop. That should be the case for
>> !CONFIG_DEBUG_ATOMIC_SLEEP && !CONFIG_PROVE_LOCKING.
>
>
> I am almost sure I did not have either of these two options enabled when
> I observed the bug.
>
migh_fault also resolves to _cond_resched() when
CONFIG_PREEMPT_VOLUNTARY is enabled.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 15:10 ` Gilles Chanteperdrix
2013-04-07 15:13 ` Gilles Chanteperdrix
@ 2013-04-07 15:14 ` Jan Kiszka
2013-04-07 15:26 ` Gilles Chanteperdrix
1 sibling, 1 reply; 14+ messages in thread
From: Jan Kiszka @ 2013-04-07 15:14 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai
On 2013-04-07 17:10, Gilles Chanteperdrix wrote:
> On 04/06/2013 08:32 PM, Jan Kiszka wrote:
>
>> On 2013-04-06 20:27, Gilles Chanteperdrix wrote:
>>>> And it has to map directly to might_fault
>>>> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>>>
>>> That would defeat the purpose of the patch. might_fault can not be
>>> called over non root domains.
>>
>> True. But we should avoid leaving the costly irq-disable/enable and
>> domain checks in production code behind when might_fault actually
>> resolves to a nop. That should be the case for
>> !CONFIG_DEBUG_ATOMIC_SLEEP && !CONFIG_PROVE_LOCKING.
>
>
> I am almost sure I did not have either of these two options enabled when
> I observed the bug.
Hmm. And CONFIG_PREEMPT_VOLUNTARY? In that case, might_sleep seems to
serve as a voluntary preemption point.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130407/daac91d4/attachment.pgp>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 15:14 ` Jan Kiszka
@ 2013-04-07 15:26 ` Gilles Chanteperdrix
0 siblings, 0 replies; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 15:26 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/07/2013 05:14 PM, Jan Kiszka wrote:
> On 2013-04-07 17:10, Gilles Chanteperdrix wrote:
>> On 04/06/2013 08:32 PM, Jan Kiszka wrote:
>>
>>> On 2013-04-06 20:27, Gilles Chanteperdrix wrote:
>>>>> And it has to map directly to might_fault
>>>>> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
>>>>
>>>> That would defeat the purpose of the patch. might_fault can not be
>>>> called over non root domains.
>>>
>>> True. But we should avoid leaving the costly irq-disable/enable and
>>> domain checks in production code behind when might_fault actually
>>> resolves to a nop. That should be the case for
>>> !CONFIG_DEBUG_ATOMIC_SLEEP && !CONFIG_PROVE_LOCKING.
>>
>>
>> I am almost sure I did not have either of these two options enabled when
>> I observed the bug.
>
> Hmm. And CONFIG_PREEMPT_VOLUNTARY? In that case, might_sleep seems to
> serve as a voluntary preemption point.
>From what I see, ipipe_root_only is called systematically, even when
CONFIG_PREEMPT_VOLUNTARY is disabled.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-06 9:48 ` Jan Kiszka
2013-04-06 13:24 ` Philippe Gerum
2013-04-06 18:27 ` Gilles Chanteperdrix
@ 2013-04-07 16:55 ` Gilles Chanteperdrix
2013-04-07 18:47 ` Gilles Chanteperdrix
2 siblings, 1 reply; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 16:55 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/06/2013 11:48 AM, Jan Kiszka wrote:
> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>
>> Hi,
>>
>> The for-core-3.5.7 and for-core-3.8.2 branches in ipipe_gch.git
>> repository contain new versions of the I-pipe kernel for the ARM
>> architecture.
>>
>> The for-core-3.5.7 branch contains an important fix for SMP platforms,
>> and the fix for mx28 posted by Martin Krause.
>>
>> The for-core-3.8.2 branch is the newest port. Known issues are:
>> - it has been rebased on v3.8.2, so it will not merge with the branch
>> it started from, if preferred, I can push a merged version;
>> - ftrace is broken, so I wonder if it would not be simpler to have a
>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>> tracer;
>> - threaded fasteoi irqs are broken, the branch contains the latest
>> patch posted on this list, but since I received no comment, I am not
>> sure it is the right fix.
>>
>> The pull requests follow.
>> The following changes since commit 946ca3977e75316751caecc7182f4e64af6499d5:
>>
>> ipipe-core-3.5.7-blackfin-3 (2013-01-22 11:41:34 +0100)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.5.7
>>
>> Gilles Chanteperdrix (2):
>> arm/ipipe: fix off-by-one error in IPI virqs allocation
>> mx28/ipipe: allow building kernel for both mx28 and mx23
>>
>> Martin Krause (1):
>> mx28/ipipe: fix the timer selected with I-pipe
>>
>> arch/arm/kernel/smp.c | 2 +-
>> arch/arm/mach-mxs/timer.c | 40 ++++++++++++++++------------------------
>> drivers/clk/mxs/clk-imx28.c | 4 ++++
>> 3 files changed, 21 insertions(+), 25 deletions(-)
>>
>>
>> The following changes since commit 5a16a5a4dd127afcb2446afa057b55a60cffe7f9:
>>
>> blackfin/ipipe: import arch-dep bits based on 3.5.7-blackfin-3 (2013-04-04 21:37:51 +0200)
>>
>> are available in the git repository at:
>> git://git.xenomai.org/ipipe-gch.git for-core-3.8.2
>>
>> Gilles Chanteperdrix (18):
>> avoid kernel fault upon coredump on arm with vivt cache
>> FCSE: pid life cycle
>> FCSE: Conversions between VA and MVA
>> FCSE: Address-space limits
>> FCSE: Make the shared mappings uncacheable
>> FCSE: do not flush cache during context switch
>> "Best-effort" FCSE: choose whether to flush cache at run-time
>> "Best-effort" FCSE: Allow PID re-use
>> "Best-effort" FCSE: Handle mappings above 32 MB
>> "Best effort" FCSE: Reserve address-space for stack
>> "Best-effort" FCSE: Handle shared mappings
>> FCSE: add Makefile and compilation option
>> noarch/ipipe: fix ipipe_update_hostrt
>> noarch/ipipe: fix one-shot fasteoi irq
>> noarch/ipipe: introduce IPIPE_NR_ROOT_IRQS
> ^^^^^^
> I'm tagging generic patches just with "ipipe:". IIRC, this is what
> Philippe requested.
>
>> arm/ipipe: import arch-dep bits based on 3.5.7-arm-3
>> arm/ipipe: avoid calling might_fault() with non-root domains
>
> I think ipipe_uaccess_might_fault could become a generic service in case
> other archs need it as well. And it has to map directly to might_fault
> in case CONFIG_IPIPE_DEBUG_CONTEXT is disabled (thus zero overhead).
Hi,
I have just pushed a new version of the for-core-3.8.2 branch with all
the comments addressed.
I also had tested a merge of the previous version with your next-x86
branch, and except a few merge conflicts and a build error without SMP,
adressed by this commit:
http://git.xenomai.org/ipipe-gch.git/?p=ipipe-gch.git;a=commitdiff;h=fae81444a0bfe12de514ac039f866c0f66abfb3c;hp=1198253580e0d5610ee886e1ff3771461a06f414
It seemed to work fine on my x86 boxes.
Regards.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 16:55 ` Gilles Chanteperdrix
@ 2013-04-07 18:47 ` Gilles Chanteperdrix
2013-04-07 19:01 ` Jan Kiszka
0 siblings, 1 reply; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 18:47 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/07/2013 06:55 PM, Gilles Chanteperdrix wrote:
> On 04/06/2013 11:48 AM, Jan Kiszka wrote:
>
>> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>> - ftrace is broken, so I wonder if it would not be simpler to have a
>>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>>> tracer;
> (...)
>
> Hi,
>
> I have just pushed a new version of the for-core-3.8.2 branch with all
> the comments addressed.
>
> I also had tested a merge of the previous version with your next-x86
> branch, and except a few merge conflicts and a build error without SMP,
> adressed by this commit:
> http://git.xenomai.org/ipipe-gch.git/?p=ipipe-gch.git;a=commitdiff;h=fae81444a0bfe12de514ac039f866c0f66abfb3c;hp=1198253580e0d5610ee886e1ff3771461a06f414
>
> It seemed to work fine on my x86 boxes.
The fixes in the next-x86 branch seem to make the tracer working,
though it seems very slow (latencies doubled on ARM). The changes in
timings seem to break some of the regression tests, I also get a
reproducible bug on at91sam9263 while running the "cond-torture-native"
test:
[ 202.650000] Xenomai: Switching main_task to secondary mode after exception #8 in kernel-space at 0xc0093418 (pid 986)
[ 202.650000] I-pipe tracer log (100 points):
[ 202.650000] | # func 0 ipipe_trace_panic_freeze+0x10 (xnpod_trap_fault+0xbc)
[ 202.650000] | # func -3 xnpod_trap_fault+0x14 (xnarch_trap_fault+0x28)
[ 202.650000] | # func -5 xnarch_trap_fault+0x14 (exception_event+0x4c)
[ 202.650000] | # func -9 exception_event+0x10 (ipipe_trap_hook+0x38)
[ 202.650000] | # func -12 ipipe_trap_hook+0x10 (__ipipe_notify_trap+0xa0)
[ 202.650000] | # func -15 __ipipe_notify_trap+0x14 (do_alignment+0x5c)
[ 202.650000] | # func -18 do_alignment+0x14 (do_DataAbort+0x50)
[ 202.650000] | # func -21 do_DataAbort+0x14 (__dabt_svc+0x50)
[ 202.650000] | # begin 0x90000000 -24 __dabt_svc+0x44 (registry_touch_vfsnap+0x18)
[ 202.650000] | # func -28 registry_touch_vfsnap+0x10 (xnregistry_remove+0x1f8)
[ 202.650000] | # func -34 registry_hash_crunch+0x10 (xnregistry_remove+0x18c)
[ 202.650000] | # func -38 __ipipe_set_irq_pending+0x10 (__ipipe_dispatch_irq+0x210)
[ 202.650000] | # func -42 __ipipe_dispatch_irq+0x10 (ipipe_raise_irq+0x40)
[ 202.650000] | # func -44 ipipe_raise_irq+0x10 (printk+0x178)
[ 202.650000] | # func -47 __ipipe_spin_unlock_irqrestore+0x10 (printk+0x164)
[ 202.650000] | # func -72 __ipipe_spin_lock_irqsave+0x10 (printk+0x11c)
[ 202.650000] | # func -77 printk+0x18 (xnregistry_remove+0x170)
[ 202.650000] | # func -82 xnregistry_remove+0x14 (rt_mutex_delete+0x1ac)
[ 202.650000] | # func -87 xnsynch_flush+0x14 (rt_mutex_delete+0x194)
[ 202.650000] | + begin 0x80000000 -94 rt_mutex_delete+0x60 (__rt_mutex_delete+0x5c)
[ 202.650000] + func -97 rt_mutex_delete+0x14 (__rt_mutex_delete+0x5c)
[ 202.650000] + func -100 xnregistry_fetch+0x10 (__rt_mutex_delete+0xa0)
[ 202.650000] + func -104 __rt_mutex_delete+0x14 (hisyscall_event+0x198)
[ 202.650000] + func -109 hisyscall_event+0x14 (ipipe_syscall_hook+0x40)
[ 202.650000] + func -112 ipipe_syscall_hook+0x10 (__ipipe_notify_syscall+0xa8)
[ 202.650000] | + end 0x80000001 -114 __ipipe_notify_syscall+0x98 (__ipipe_syscall_root+0x84)
[ 202.650000] | + begin 0x80000001 -116 __ipipe_notify_syscall+0x34 (__ipipe_syscall_root+0x84)
[ 202.650000] + func -118 __ipipe_notify_syscall+0x10 (__ipipe_syscall_root+0x84)
[ 202.650000] + func -121 __ipipe_syscall_root+0x10 (vector_swi+0x74)
[ 202.650000] | + begin 0x90000000 -126 vector_swi+0x3c (<018e7b70>)
[ 202.650000] | + end 0x90000000 -163 __ipipe_ret_to_user_irqs_disabled+0x14 (<018e6c34>)
[ 202.650000] | + end 0x80000000 -166 __ipipe_syscall_root+0x11c (vector_swi+0x74)
[ 202.650000] | + begin 0x80000000 -170 __ipipe_syscall_root+0xa8 (vector_swi+0x74)
[ 202.650000] | + end 0x80000001 -173 __ipipe_notify_syscall+0x12c (__ipipe_syscall_root+0x84)
[ 202.650000] | + begin 0x80000001 -177 __ipipe_notify_syscall+0xc8 (__ipipe_syscall_root+0x84)
[ 202.650000] | + end 0x80000000 -182 __ipipe_restore_head+0x108 (rt_cond_wait_epilogue+0x2bc)
[ 202.650000] | # func -185 __ipipe_restore_head+0x10 (rt_cond_wait_epilogue+0x2bc)
[ 202.650000] | # func -192 xnsynch_acquire+0x14 (rt_mutex_acquire_inner+0x110)
[ 202.650000] | # func -197 rt_mutex_acquire_inner+0x14 (rt_mutex_acquire+0x24)
[ 202.650000] | # func -199 rt_mutex_acquire+0x14 (rt_cond_wait_epilogue+0x150)
[ 202.650000] | + begin 0x80000000 -205 rt_cond_wait_epilogue+0x40 (__rt_cond_wait_epilogue+0x64)
[ 202.650000] + func -208 rt_cond_wait_epilogue+0x14 (__rt_cond_wait_epilogue+0x64)
[ 202.650000] + func -212 xnregistry_fetch+0x10 (__rt_cond_wait_epilogue+0x84)
[ 202.650000] + func -216 __rt_cond_wait_epilogue+0x14 (losyscall_event+0xd0)
[ 202.650000] | + end 0x80000000 -221 __ipipe_restore_head+0x108 (__xnpod_schedule+0x9bc)
[ 202.650000] | # func -223 __ipipe_restore_head+0x10 (__xnpod_schedule+0x9bc)
[ 202.650000] | # func -228 xnsched_pick_next+0x10 (__xnpod_schedule+0x18c)
[ 202.650000] | # [ 986] main_tas 2 -230 __xnpod_schedule+0x16c (xnshadow_harden+0x348)
[ 202.650000] | + begin 0x80000000 -236 __xnpod_schedule+0x68 (xnshadow_harden+0x348)
[ 202.650000] + func -238 __xnpod_schedule+0x14 (xnshadow_harden+0x348)
[ 202.650000] | + end 0x80000000 -241 __ipipe_restore_head+0x108 (xnshadow_harden+0x2f4)
[ 202.650000] | # func -244 __ipipe_restore_head+0x10 (xnshadow_harden+0x2f4)
[ 202.650000] | + begin 0x80000000 -252 xnsched_finish_unlocked_switch+0x38 (xnshadow_harden+0x188)
[ 202.650000] + func -254 xnsched_finish_unlocked_switch+0x10 (xnshadow_harden+0x188)
[ 202.650000] | + end 0x80000000 -258 __ipipe_switch_tail+0x74 (__schedule+0x480)
[ 202.650000] | + begin 0x80000000 -262 __ipipe_switch_tail+0x34 (__schedule+0x480)
[ 202.650000] + func -264 __ipipe_switch_tail+0x10 (__schedule+0x480)
[ 202.650000] | + end 0x80000000 -270 __ipipe_restore_head+0x108 (__xnpod_schedule+0x5ec)
[ 202.650000] | # func -272 __ipipe_restore_head+0x10 (__xnpod_schedule+0x5ec)
[ 202.650000] | # func -281 at91_mute_pic+0x10 (__xnpod_schedule+0x360)
[ 202.650000] | # func -287 xnsched_pick_next+0x10 (__xnpod_schedule+0x18c)
[ 202.650000] | # [ 989] -<?>- -1 -289 __xnpod_schedule+0x16c (xnpod_schedule_handler+0x3c)
[ 202.650000] | # func -294 __xnpod_schedule+0x14 (xnpod_schedule_handler+0x3c)
[ 202.650000] | # func -296 xnpod_schedule_handler+0x10 (__ipipe_dispatch_irq+0x19c)
[ 202.650000] | +func -302 __ipipe_dispatch_irq+0x10 (ipipe_raise_irq+0x40)
[ 202.650000] | +begin 0x80000001 -305 ipipe_raise_irq+0x34 (__xnpod_schedule+0x44)
[ 202.650000] +func -307 ipipe_raise_irq+0x10 (__xnpod_schedule+0x44)
[ 202.650000] +func -309 __xnpod_schedule+0x14 (gatekeeper_thread+0x38c)
[ 202.650000] | +end 0x80000000 -312 __ipipe_restore_head+0x108 (gatekeeper_thread+0x364)
[ 202.650000] | *+func -314 __ipipe_restore_head+0x10 (gatekeeper_thread+0x364)
[ 202.650000] | *+[ 986] main_tas 2 -322 xnpod_resume_thread+0x148 (gatekeeper_thread+0x208)
[ 202.650000] | *+func -325 xnpod_resume_thread+0x14 (gatekeeper_thread+0x208)
[ 202.650000] | +begin 0x80000000 -330 gatekeeper_thread+0x11c (kthread+0xbc)
[ 202.650000] | +end 0x80000000 -333 __ipipe_restore_head+0x108 (xnsched_renice_root+0x2b0)
[ 202.650000] | *+func -335 __ipipe_restore_head+0x10 (xnsched_renice_root+0x2b0)
[ 202.650000] | *+[ 989] -<?>- -1 -339 xnsched_renice_root+0x154 (rpi_pop+0x488)
[ 202.650000] | *+func -344 xnsched_track_policy+0x10 (xnsched_renice_root+0x13c)
[ 202.650000] | +begin 0x80000000 -349 xnsched_renice_root+0x44 (rpi_pop+0x488)
[ 202.650000] +func -352 xnsched_renice_root+0x14 (rpi_pop+0x488)
[ 202.650000] | +end 0x80000000 -354 __ipipe_restore_head+0x108 (rpi_pop+0x460)
[ 202.650000] | *+func -356 __ipipe_restore_head+0x10 (rpi_pop+0x460)
[ 202.650000] | *+func -361 xnsched_peek_rpi+0x10 (rpi_pop+0x2e4)
[ 202.650000] | +begin 0x80000000 -367 rpi_pop+0x3c (gatekeeper_thread+0xfc)
[ 202.650000] +func -369 rpi_pop+0x14 (gatekeeper_thread+0xfc)
[ 202.650000] +func -374 kthread_should_stop+0x10 (gatekeeper_thread+0xc4)
[ 202.650000] +func -377 ipipe_root_only+0x10 (sub_preempt_count+0x1c)
[ 202.650000] +func -379 sub_preempt_count+0x10 (__schedule+0x4b0)
[ 202.650000] | +end 0x80000001 -383 finish_task_switch.clone.57+0x7c (__schedule+0x490)
[ 202.650000] | +begin 0x80000001 -385 finish_task_switch.clone.57+0x60 (__schedule+0x490)
[ 202.650000] +func -388 ipipe_root_only+0x10 (sub_preempt_count+0x1c)
[ 202.650000] +func -390 sub_preempt_count+0x10 (_raw_spin_unlock_irq+0x24)
[ 202.650000] | +end 0x80000000 -392 ipipe_unstall_root+0x6c (_raw_spin_unlock_irq+0x1c)
[ 202.650000] | #func -395 ipipe_root_only+0x10 (ipipe_unstall_root+0x38)
[ 202.650000] | #begin 0x80000000 -398 ipipe_unstall_root+0x34 (_raw_spin_unlock_irq+0x1c)
[ 202.650000] #func -400 ipipe_unstall_root+0x10 (_raw_spin_unlock_irq+0x1c)
[ 202.650000] #func -404 _raw_spin_unlock_irq+0x10 (finish_task_switch.clone.57+0x44)
[ 202.650000] #func -407 finish_task_switch.clone.57+0x10 (__schedule+0x490)
[ 202.650000] | #end 0x80000000 -410 __ipipe_switch_tail+0x74 (__schedule+0x480)
[ 202.650000] | #begin 0x80000000 -413 __ipipe_switch_tail+0x34 (__schedule+0x480)
[ 202.650000] #func -415 __ipipe_switch_tail+0x10 (__schedule+0x480)
[ 203.470000] Unable to handle kernel paging request at virtual address 20c0041e
[ 203.480000] fcse pid: 84, 0xa8000000, hw pid: 0xa8000000
[ 203.490000] pgd = c3358000, hw pgd = c3358000
[ 203.490000] [20c0041e] *pgd=00000000
[ 203.500000] Internal error: Oops: 1 [#1] PREEMPT ARM
[ 203.500000] Modules linked in:
[ 203.500000] CPU: 0 Not tainted (3.8.2 #22)
[ 203.500000] PC is at registry_touch_vfsnap+0x18/0x28
[ 203.500000] LR is at xnregistry_remove+0x1f8/0x540
[ 203.500000] pc : [<c009341c>] lr : [<c0093fe0>] psr: 60000093
[ 203.500000] sp : c3c95e50 ip : c0093418 fp : c3c95e5c
[ 203.500000] r10: 00000000 r9 : 00000000 r8 : c3af0000
[ 203.500000] r7 : c3af2fd0 r6 : 00002fd0 r5 : c04cc578 r4 : 00000003
[ 203.500000] r3 : 20c0041e r2 : 00000002 r1 : 0000021e r0 : c3af2fd0
[ 203.500000] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 203.500000] Control: 0005317f Table: 23358000 DAC: 00000015
[ 203.500000] Process main_task (pid: 986, stack limit = 0xc3c941b8)
[ 203.500000] Stack: (0xc3c95e50 to 0xc3c96000)
[ 203.500000] 5e40: c3c95ea4 c3c95e60 c0093fe0 c0093414
[ 203.500000] 5e60: 00000000 80000000 c00cd598 00000000 00000000 c3050f00 00000168 c49ce600
[ 203.500000] 5e80: 00000000 00000000 c04cc578 01000000 00000000 80000093 c3c95eec c3c95ea8
[ 203.500000] 5ea0: c00cd6e4 c0093df8 c3c95ec4 c3c95eb8 c006b888 c006adf0 c3c95eec c3c95ec8
[ 203.500000] 5ec0: c0009958 c3c95fb0 c49ce600 00000000 00000000 c3050f00 00000168 00000001
[ 203.500000] 5ee0: c3c95f14 c3c95ef0 c00bee78 c00cd548 c3c95f4c 00000066 016a2000 00000001
[ 203.500000] 5f00: c3c95fb0 c49ce010 c3c95f4c c3c95f18 c00a4450 c00bee2c c3c95f34 c051a9c0
[ 203.500000] 5f20: c006b888 c04c9898 c051a9c0 c051a9c0 c051a9c0 c3c95fb0 00000000 60000013
[ 203.500000] 5f40: c3c95f5c c3c95f50 c006c0c8 c00a42c8 c3c95f8c c3c95f60 c0068608 c006c098
[ 203.500000] 5f60: c3050f00 c3c95fb0 00000002 000f0042 000f0042 c0009adc 00000000 00000000
[ 203.500000] 5f80: c3c95fac c3c95f90 c00100b8 c0068570 21f6cc97 00000000 00000000 000f0042
[ 203.500000] 5fa0: 00000000 c3c95fb0 c0009a14 c0010044 2d01022b 01a42cf4 01a42cf4 00010000
[ 203.500000] 5fc0: 21f6cc97 00000000 00000000 000f0042 017e9000 00000000 017e9000 00000000
[ 203.500000] 5fe0: 00013d48 01a42c48 00009d68 018e7b74 60000010 2d01022b 00000000 00000000
[ 203.500000] Backtrace:
[ 203.500000] [<c0093404>] (registry_touch_vfsnap+0x0/0x28) from [<c0093fe0>] (xnregistry_remove+0x1f8/0x540)
[ 203.500000] [<c0093de8>] (xnregistry_remove+0x0/0x540) from [<c00cd6e4>] (rt_mutex_delete+0x1ac/0x3fc)
[ 203.500000] [<c00cd538>] (rt_mutex_delete+0x0/0x3fc) from [<c00bee78>] (__rt_mutex_delete+0x5c/0xb0)
[ 203.500000] [<c00bee1c>] (__rt_mutex_delete+0x0/0xb0) from [<c00a4450>] (hisyscall_event+0x198/0x35c)
[ 203.500000] r5:c49ce010 r4:c3c95fb0
[ 203.500000] [<c00a42b8>] (hisyscall_event+0x0/0x35c) from [<c006c0c8>] (ipipe_syscall_hook+0x40/0x50)
[ 203.500000] [<c006c088>] (ipipe_syscall_hook+0x0/0x50) from [<c0068608>] (__ipipe_notify_syscall+0xa8/0x164)
[ 203.500000] [<c0068560>] (__ipipe_notify_syscall+0x0/0x164) from [<c00100b8>] (__ipipe_syscall_root+0x84/0x150)
[ 203.500000] [<c0010034>] (__ipipe_syscall_root+0x0/0x150) from [<c0009a14>] (vector_swi+0x74/0x8c)
[ 203.500000] r7:000f0042 r6:00000000 r5:00000000 r4:21f6cc97
[ 203.500000] Code: e24cb004 e52de004 ebfdd939 e5903060 (e5932000)
[ 203.780000] ---[ end trace 672b7e523f922a3f ]---
[
>
> Regards.
>
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 18:47 ` Gilles Chanteperdrix
@ 2013-04-07 19:01 ` Jan Kiszka
2013-04-07 19:16 ` Gilles Chanteperdrix
0 siblings, 1 reply; 14+ messages in thread
From: Jan Kiszka @ 2013-04-07 19:01 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: Xenomai
On 2013-04-07 20:47, Gilles Chanteperdrix wrote:
> On 04/07/2013 06:55 PM, Gilles Chanteperdrix wrote:
>
>> On 04/06/2013 11:48 AM, Jan Kiszka wrote:
>>
>>> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>>> - ftrace is broken, so I wonder if it would not be simpler to have a
>>>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>>>> tracer;
>
>> (...)
>
>>
>> Hi,
>>
>> I have just pushed a new version of the for-core-3.8.2 branch with all
>> the comments addressed.
>>
>> I also had tested a merge of the previous version with your next-x86
>> branch, and except a few merge conflicts and a build error without SMP,
>> adressed by this commit:
>> http://git.xenomai.org/ipipe-gch.git/?p=ipipe-gch.git;a=commitdiff;h=fae81444a0bfe12de514ac039f866c0f66abfb3c;hp=1198253580e0d5610ee886e1ff3771461a06f414
Thanks for the fix, will pick it up as well.
>>
>> It seemed to work fine on my x86 boxes.
>
>
> The fixes in the next-x86 branch seem to make the tracer working,
> though it seems very slow (latencies doubled on ARM).
You mean the I-pipe tracer? That it works is likely due to e00888b4aa.
The slowness, is it compared to an older I-pipe version?
> The changes in
> timings seem to break some of the regression tests,
Timeouts fire?
> I also get a
> reproducible bug on at91sam9263 while running the "cond-torture-native"
> test:
>
> [ 202.650000] Xenomai: Switching main_task to secondary mode after exception #8 in kernel-space at 0xc0093418 (pid 986)
...
> [ 203.470000] Unable to handle kernel paging request at virtual address 20c0041e
I suppose that address is totally off. Use after release issue?
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130407/49f6f748/attachment.pgp>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 19:01 ` Jan Kiszka
@ 2013-04-07 19:16 ` Gilles Chanteperdrix
2013-04-08 21:02 ` Gilles Chanteperdrix
0 siblings, 1 reply; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-07 19:16 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/07/2013 09:01 PM, Jan Kiszka wrote:
> On 2013-04-07 20:47, Gilles Chanteperdrix wrote:
>> On 04/07/2013 06:55 PM, Gilles Chanteperdrix wrote:
>>
>>> On 04/06/2013 11:48 AM, Jan Kiszka wrote:
>>>
>>>> On 2013-04-04 22:58, Gilles Chanteperdrix wrote:
>>>>> - ftrace is broken, so I wonder if it would not be simpler to have a
>>>>> tracer not relying on ftrace, as we did at the beginning of the I-pipe
>>>>> tracer;
>>
>>> (...)
>>
>>>
>>> Hi,
>>>
>>> I have just pushed a new version of the for-core-3.8.2 branch with all
>>> the comments addressed.
>>>
>>> I also had tested a merge of the previous version with your next-x86
>>> branch, and except a few merge conflicts and a build error without SMP,
>>> adressed by this commit:
>>> http://git.xenomai.org/ipipe-gch.git/?p=ipipe-gch.git;a=commitdiff;h=fae81444a0bfe12de514ac039f866c0f66abfb3c;hp=1198253580e0d5610ee886e1ff3771461a06f414
>
> Thanks for the fix, will pick it up as well.
>
>>>
>>> It seemed to work fine on my x86 boxes.
>>
>>
>> The fixes in the next-x86 branch seem to make the tracer working,
>> though it seems very slow (latencies doubled on ARM).
>
> You mean the I-pipe tracer? That it works is likely due to e00888b4aa.
> The slowness, is it compared to an older I-pipe version?
Yes, it seems slower than older versions, but I have no figures, it is
just a general impression. I run "xeno-regression-test" with the tracer
on, as well as with xenomai and ipipe debugging options enabled.
>
>> The changes in
>> timings seem to break some of the regression tests,
>
> Timeouts fire?
Some tests rely on "sleep" for synchronization, I had to add a semaphore
to xddp_test, see:
http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=73232678927c2afe525090a359f241c1acac4a2d;hp=926f4fbc2e38c198eefda6f0a98a278588d421db
I also had a problem with mutex-torture-native, but it does not seem
easy to reproduce.
>
>> I also get a
>> reproducible bug on at91sam9263 while running the "cond-torture-native"
>> test:
>>
>> [ 202.650000] Xenomai: Switching main_task to secondary mode after exception #8 in kernel-space at 0xc0093418 (pid 986)
> ...
>> [ 203.470000] Unable to handle kernel paging request at virtual address 20c0041e
>
> I suppose that address is totally off. Use after release issue?
It seems registry_unexport_pnode reads an invalid object->vfilp and
triggers registry_proc_apc whereas no vfile is currently reading the
object, as if registry_export_pnode had not been called.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai] I-pipe on ARM platform.
2013-04-07 19:16 ` Gilles Chanteperdrix
@ 2013-04-08 21:02 ` Gilles Chanteperdrix
0 siblings, 0 replies; 14+ messages in thread
From: Gilles Chanteperdrix @ 2013-04-08 21:02 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai
On 04/07/2013 09:16 PM, Gilles Chanteperdrix wrote:
>>>> I also had tested a merge of the previous version with your next-x86
>>>> branch, and except a few merge conflicts and a build error without SMP,
>>>> adressed by this commit:
>>>> http://git.xenomai.org/ipipe-gch.git/?p=ipipe-gch.git;a=commitdiff;h=fae81444a0bfe12de514ac039f866c0f66abfb3c;hp=1198253580e0d5610ee886e1ff3771461a06f414
>>
>> Thanks for the fix, will pick it up as well.
I have also pushed a for-core-3.8.2-x86 branch in the ipipe-gch git,
with both the ARM and x86 changes.
> It seems registry_unexport_pnode reads an invalid object->vfilp and>
triggers registry_proc_apc whereas no vfile is currently reading the
> object, as if registry_export_pnode had not been called.
>
Forget that, I do not really understand the vfile code, need to spend
more time on it.
--
Gilles.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-04-08 21:02 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-04 20:58 [Xenomai] I-pipe on ARM platform Gilles Chanteperdrix
2013-04-06 9:48 ` Jan Kiszka
2013-04-06 13:24 ` Philippe Gerum
2013-04-06 18:27 ` Gilles Chanteperdrix
2013-04-06 18:32 ` Jan Kiszka
2013-04-07 15:10 ` Gilles Chanteperdrix
2013-04-07 15:13 ` Gilles Chanteperdrix
2013-04-07 15:14 ` Jan Kiszka
2013-04-07 15:26 ` Gilles Chanteperdrix
2013-04-07 16:55 ` Gilles Chanteperdrix
2013-04-07 18:47 ` Gilles Chanteperdrix
2013-04-07 19:01 ` Jan Kiszka
2013-04-07 19:16 ` Gilles Chanteperdrix
2013-04-08 21:02 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.