Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : x86: Fix return type of DO_SYSCALL_INNER macro
GIT version control wrote: > Module: xenomai-jki > Branch: for-upstream > Commit: 852c130d16410a597536c39d06b6abd1c9c6c822 > URL: > http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=852c130d16410a597536c39d06b6abd1c9c6c822 > > Author: Jan Kiszka > Date: Fri Apr 29 14:12:13 2011 +0200 > > x86: Fix return type of DO_SYSCALL_INNER macro > > gcc will complain about 'conversion to ‘int’ from ‘long int’ may alter > its value' with -Wconversion as DO_SYSCALL treats the return value of > DO_SYSCALL_INNER as int. Align DO_SYSCALL_INNER to its user. > > Signed-off-by: Jan Kiszka Should not it be aligned the other way around? Using longs everywhere? In case a syscall returns a pointer? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC]Badness at mmu_context_nohash
On 2011-04-29 18:08, Jean-Michel Hautbois wrote: > 2011/4/29 Philippe Gerum : >> On Thu, 2011-04-28 at 10:33 +0200, Jean-Michel Hautbois wrote: >>> 2011/4/27 Philippe Gerum : 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 2.6.35.11 linux kernel > and the adeos-ipipe-2.6.35.7-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: GW(2.6.35.11) > MSR: 00021000 CR: 24000488 XER: > TASK = ec5220d0[496] 'sipaq' THREAD: ecfac000 CPU: 1 > GPR00: 0001 ecfadd90 ec5220d0 ec5df340 ec58a700 > 0003 > GPR08: c04a2d98 0007 c04a2d98 0067e000 0002f385 1007f1f8 c04a5b40 > ecfac040 > GPR16: c04a5b40 c04deb80 c04a2120 c04a2d98 c04a5b40 c04d008c ecfac000 > 00029000 > GPR24: c04d c04d1e6c 0001 ec58a700 eceaf390 c04d1e78 c0b23b40 > ec5df340 > NIP [c0018d20] switch_mmu_context+0x80/0x438 > LR [c039b94c] schedule+0x774/0x7dc > Call Trace: > [ecfadd90] [44000484] 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 2f80 409e0128 813b018c 2f83 39290001 913b018c > 419e0020 8003018c 7c34 5400d97e <0f00> 8123018c 3929 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: >> http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=c14a47630d62d0328de1957636dceb1d498f7048 >> >> However, it the last 2.6.35 patch issued was based on 2.6.35.7, not >> 2.6.35.11, 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 >> it should > > It is ok, I have the fix. > >> - Please try Richard's suggestion, i.e. moving to 2.6.36, which may give >> us more hints. > > It is better. I don't have the badness on mmu context anymore. > This gives some 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. > > Yes, but I *want* to have the CONFIG_TRACE_IRQFLAGS on. I just wanted > to tell that I had the problem, in order to be sure it is known ;). > Just found and fixed a generic TRACE_IRQFLAGS related bug, see [1]. Kernel (x86) is still unhappy about some inconsistent lock state, but debugging this needs to wait. Jan [1] http://thread.gmane.org/gmane.linux.kernel.adeos.general/1807 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC]Badness at mmu_context_nohash
2011/4/29 Philippe Gerum : > On Thu, 2011-04-28 at 10:33 +0200, Jean-Michel Hautbois wrote: >> 2011/4/27 Philippe Gerum : >> > 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 2.6.35.11 linux kernel >> >> and the adeos-ipipe-2.6.35.7-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 (2.6.35.11) >> >> MSR: 00021000 CR: 24000488 XER: >> >> TASK = ec5220d0[496] 'sipaq' THREAD: ecfac000 CPU: 1 >> >> GPR00: 0001 ecfadd90 ec5220d0 ec5df340 ec58a700 >> >> 0003 >> >> GPR08: c04a2d98 0007 c04a2d98 0067e000 0002f385 1007f1f8 c04a5b40 >> >> ecfac040 >> >> GPR16: c04a5b40 c04deb80 c04a2120 c04a2d98 c04a5b40 c04d008c ecfac000 >> >> 00029000 >> >> GPR24: c04d c04d1e6c 0001 ec58a700 eceaf390 c04d1e78 c0b23b40 >> >> ec5df340 >> >> NIP [c0018d20] switch_mmu_context+0x80/0x438 >> >> LR [c039b94c] schedule+0x774/0x7dc >> >> Call Trace: >> >> [ecfadd90] [44000484] 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 2f80 409e0128 813b018c 2f83 39290001 913b018c >> >> 419e0020 8003018c 7c34 5400d97e <0f00> 8123018c 3929 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: > http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=c14a47630d62d0328de1957636dceb1d498f7048 > > However, it the last 2.6.35 patch issued was based on 2.6.35.7, not > 2.6.35.11, 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 > it should It is ok, I have the fix. > - Please try Richard's suggestion, i.e. moving to 2.6.36, which may give > us more hints. It is better. I don't have the badness on mmu context anymore. This gives some 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. Yes, but I *want* to have the CONFIG_TRACE_IRQFLAGS on. I just wanted to tell that I had the problem, in order to be sure it is known ;). JM ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PULL] x86: Fix return type of DO_SYSCALL_INNER macro
The following changes since commit 985cf80d202f97e32ae45957f2bfca764e3eb243: nios2: fix pipeline patch for 2.6.35-mmu -- take #2 (2011-04-29 11:34:11 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (1): x86: Fix return type of DO_SYSCALL_INNER macro include/asm-x86/syscall.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- x86: Fix return type of DO_SYSCALL_INNER macro gcc will complain about 'conversion to ‘int’ from ‘long int’ may alter its value' with -Wconversion as DO_SYSCALL treats the return value of DO_SYSCALL_INNER as int. Align DO_SYSCALL_INNER to its user. Signed-off-by: Jan Kiszka --- include/asm-x86/syscall.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 06195c9..b02c01d 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -386,7 +386,7 @@ static inline void __xn_get_ebp(void **dest) : "=a" (__resultvar)\ : "0" (name) ASM_ARGS_##nr \ : "memory", "cc", "r11", "cx"); \ - (long) __resultvar; \ + (int) __resultvar; \ }) #define DO_SYSCALL(name, nr, args...) \ -- 1.7.1 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC]Badness at mmu_context_nohash
On Thu, 2011-04-28 at 10:33 +0200, Jean-Michel Hautbois wrote: > 2011/4/27 Philippe Gerum : > > 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 2.6.35.11 linux kernel > >> and the adeos-ipipe-2.6.35.7-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: GW(2.6.35.11) > >> MSR: 00021000 CR: 24000488 XER: > >> TASK = ec5220d0[496] 'sipaq' THREAD: ecfac000 CPU: 1 > >> GPR00: 0001 ecfadd90 ec5220d0 ec5df340 ec58a700 > >> 0003 > >> GPR08: c04a2d98 0007 c04a2d98 0067e000 0002f385 1007f1f8 c04a5b40 > >> ecfac040 > >> GPR16: c04a5b40 c04deb80 c04a2120 c04a2d98 c04a5b40 c04d008c ecfac000 > >> 00029000 > >> GPR24: c04d c04d1e6c 0001 ec58a700 eceaf390 c04d1e78 c0b23b40 > >> ec5df340 > >> NIP [c0018d20] switch_mmu_context+0x80/0x438 > >> LR [c039b94c] schedule+0x774/0x7dc > >> Call Trace: > >> [ecfadd90] [44000484] 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 2f80 409e0128 813b018c 2f83 39290001 913b018c > >> 419e0020 8003018c 7c34 5400d97e <0f00> 8123018c 3929 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: http://git.denx.de/?p=ipipe-2.6.git;a=commit;h=c14a47630d62d0328de1957636dceb1d498f7048 However, it the last 2.6.35 patch issued was based on 2.6.35.7, not 2.6.35.11, 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 it should - 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. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
