On Thu, 2011-04-28 at 10:33 +0200, Jean-Michel Hautbois wrote:
> 2011/4/27 Philippe Gerum <r...@xenomai.org>:
> > On Wed, 2011-04-27 at 20:42 +0200, Jean-Michel Hautbois wrote:
> >> Hi list,
> >> I am currently using a Xenomai port on a linux 220.127.116.11 linux kernel
> >> and the adeos-ipipe-18.104.22.168-powerpc-2.12-01.patch.
> >> I am facing a scheduling issue on a P2020 (dual core PowerPC), and I
> >> get the following message :
> >> Badness at arch/powerpc/mm/mmu_context_nohash.c:209
> >> NIP: c0018d20 LR: c039b94c CTR: c00343e4
> >> REGS: ecfadce0 TRAP: 0700 Tainted: G W (22.214.171.124)
> >> MSR: 00021000 <ME,CE> CR: 24000488 XER: 00000000
> >> TASK = ec5220d0 'sipaq' THREAD: ecfac000 CPU: 1
> >> GPR00: 00000001 ecfadd90 ec5220d0 ec5df340 ec58a700 00000000 ffffffff
> >> 00000003
> >> GPR08: c04a2d98 00000007 c04a2d98 0067e000 0002f385 1007f1f8 c04a5b40
> >> ecfac040
> >> GPR16: c04a5b40 c04deb80 c04a2120 c04a2d98 c04a5b40 c04d008c ecfac000
> >> 00029000
> >> GPR24: c04d0000 c04d1e6c 00000001 ec58a700 eceaf390 c04d1e78 c0b23b40
> >> ec5df340
> >> NIP [c0018d20] switch_mmu_context+0x80/0x438
> >> LR [c039b94c] schedule+0x774/0x7dc
> >> Call Trace:
> >> [ecfadd90]  0x44000484 (unreliable)
> >> [ecfadde0] [c039b94c] schedule+0x774/0x7dc
> >> [ecfade50] [c039cb98] do_nanosleep+0xc8/0x114
> >> [ecfade80] [c0059bf8] hrtimer_nanosleep+0xd8/0x158
> >> [ecfadf10] [c0059d48] sys_nanosleep+0xd0/0xd4
> >> [ecfadf40] [c0013c0c] ret_from_syscall+0x0/0x3c
> >> --- Exception: c01 at 0xffa6cc4
> >> LR = 0xffa6cb0
> >> Instruction dump:
> >> 40a2fff0 4c00012c 2f800000 409e0128 813b018c 2f830000 39290001 913b018c
> >> 419e0020 8003018c 7c000034 5400d97e <0f000000> 8123018c 3929ffff 9123018c
> >> Do you have a clue on how to start debugging it ?
> > Yes, but that can't be easily summarized here. In short, we have a
> > serious problem with the sharing of the MMU context between the Linux
> > and Xenomai schedulers in the SMP case on powerpc.
> OK, good to know that it is a known issue. If there is a thread with
> some thoughts about it, I am interested ;).
> >> It is happening quite randomly... :).
> > Does disabling CONFIG_XENO_HW_UNLOCKED_SWITCH clear this issue?
> Well, yes and no. It starts well, but when booting the kernel I get :
The mm switch issue was specifically addressed by this patch, which is
part of 2.12-01:
However, it the last 2.6.35 patch issued was based on 126.96.36.199, not
188.8.131.52, so there is still the possibility that something went wrong
while you forward ported this code.
- Please check that mmu_context_nohash.c does contain the fix above as
- Please try Richard's suggestion, i.e. moving to 2.6.36, which may give
us more hints.
> Badness at kernel/lockdep.c:2327
> NIP: c006e554 LR: c006e53c CTR: 000186a0
Adeos sometimes conflicts with the vanilla IRQ state tracer. I'll have a
look at this. Disable CONFIG_TRACE_IRQFLAGS.
Xenomai-core mailing list