From: Chen Gang <hidden> Date: 2013-03-15 02:51:10
Hello Maintainers:
do next-* tree support powerpc POWER7 with allmodconfig ?
I met an issue, can we bear it (or I need additional trying) ?
Compiling:
make V=1 EXTRA_CFLAGS=-W ARCH=powerpc allmodconfig
set cpu type POWER7 in menuconfig.
set cross-compiler in menuconfig.
under Fedora 16 x86_64 laptop
/usr/bin/powerpc64-linux-gnu-gcc -v
gcc version 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) (GCC)
Issue:
error:
/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards
command:
powerpc64-linux-gnu-gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d -nostdinc -isystem /usr/lib/gcc/powerpc64-linux-gnu/4.7.1/include -I/android/public-kernel/linux-next/arch/powerpc/include -Iarch/powerpc/include/generated -I/android/public-kernel/linux-next/include -Iinclude -I/android/public-kernel/linux-next/arch/powerpc/include/uapi -Iarch/powerpc/include/generated/uapi -I/android/public-kernel/linux-next/include/uapi -Iinclude/generated/uapi -include /android/public-kernel/linux-next/include/linux/kconfig.h -D__KERNEL__ -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -D__ASSEMBLY__ -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -Wa,-maltivec -gdwarf-2 -c -o arch/powerpc/kernel/head_64.o /android/public-kernel/linux-next/arch/powerpc/kernel/head_64.S
(head_64.S includes exceptions-64.S)
thanks.
--
Chen Gang
Asianux Corporation
From: Michael Neuling <hidden> Date: 2013-03-15 04:52:58
do next-* tree support powerpc POWER7 with allmodconfig ?
I met an issue, can we bear it (or I need additional trying) ?
Compiling:
make V=1 EXTRA_CFLAGS=-W ARCH=powerpc allmodconfig
set cpu type POWER7 in menuconfig.
set cross-compiler in menuconfig.
under Fedora 16 x86_64 laptop
/usr/bin/powerpc64-linux-gnu-gcc -v
gcc version 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606) (GCC)
Issue:
error:
/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
/android/public-kernel/linux-next/arch/powerpc/kernel/exceptions-64s.S:1304: Error: attempt to move .org backwards
command:
powerpc64-linux-gnu-gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d -nostdinc -isystem /usr/lib/gcc/powerpc64-linux-gnu/4.7.1/include -I/android/public-kernel/linux-next/arch/powerpc/include -Iarch/powerpc/include/generated -I/android/public-kernel/linux-next/include -Iinclude -I/android/public-kernel/linux-next/arch/powerpc/include/uapi -Iarch/powerpc/include/generated/uapi -I/android/public-kernel/linux-next/include/uapi -Iinclude/generated/uapi -include /android/public-kernel/linux-next/include/linux/kconfig.h -D__KERNEL__ -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -D__ASSEMBLY__ -I/android/public-kernel/linux-next/arch/powerpc -Iarch/powerpc -Wa,-maltivec -gdwarf-2 -c -o arch/powerpc/kernel/head_64.o /android/public-kernel/linux-next/arch/powerpc/kernel/head_64.S
(head_64.S includes exceptions-64.S)
Yep it's a known problem but no one has bothered to fix it since it
doesn't happen in a config that anyone cares about like
pseries_defconfig and ppc64_defconfig. We've been moving code around in
this area a lot recently hence the breakage.
It should be fixed though. Patches welcome. :-)
Mikey
From: Chen Gang <hidden> Date: 2013-03-15 05:14:50
于 2013年03月15日 12:52, Michael Neuling 写道:
Yep it's a known problem but no one has bothered to fix it since it
doesn't happen in a config that anyone cares about like
pseries_defconfig and ppc64_defconfig. We've been moving code around in
this area a lot recently hence the breakage.
It should be fixed though. Patches welcome. :-)
thanks, and I should try, and very glad to try.
:-) :-)
excuse me, I try to provide related patch within this month (2013-03-31), is it ok ?
the reason is:
I am not familiar with ppc assembly code, neither ppc kernel,
so need additional time resource.
(originally, I worked for x86(_64) core dump analysing for kernel and user programs)
thanks.
--
Chen Gang
Asianux Corporation
From: Chen Gang <hidden> Date: 2013-03-21 05:56:10
Hello All:
summary:
the root cause is no enough room in exception area (0x5500 -- 0x7000).
it is caused by the patches "for saving/restre PPR":
they consumed much space of this area (0x5500 -- 0x7000).
for pseries_defconfig and ppc64_defconfig, it is still ok.
but for allmodconfig and "some additional config", it will cause issue.
the solving patch "Make room in exception vector area" can make room larger.
it can let "some additional config" ok.
but for allmodconfig, it is still not enough.
details
reason:
it is caused by:
commit number: 13e7a8e846c2ea38a552b986ea49332f965bbb7a
commit number: 44e9309f1f357794b7ae93d5f3e3e6f11d2b8a7f
they are "for saving/restore PPR"
by Haren Myneni [off-list ref] Thu, 6 Dec 2012
compiling result:
pseries_defconfig: pass (cpu for POWER7)
ppc64_defconfig: pass (cpu for POWER7)
allmodconfig: failed (cpu for POWER7)
analysing:
solving patch:
------------------------------------------------------------------
commit number: 61383407677aef05928541a00678591abea2d84c
Author: Benjamin Herrenschmidt [off-list ref]
Date: Thu Jan 10 17:44:19 2013 +1100
powerpc: Make room in exception vector area
The FWNMI region is fixed at 0x7000 and the vector are now
overflowing that with some configurations. Fix that by moving
some hash management code out of that region as it doesn't need
to be that close to the call sites (isn't accessed using
conditional branches).
------------------------------------------------------------------
but for allmodconfig (not only for "some configurations"):
it really can reduce much overflow bytes,
(maybe from hundreds bytes to dozens bytes)
but still not enough (still content overflow bytes)
additional trying:
after del CONFIG_VSX and CONFIG_PPC_970_NAP in allmodconfig,
(will reduce dozens bytes in the region .0x5500 -- .0x7000)
it can pass compiling (not overflow).
next:
I am sorry:
I am not quite familiar with the detail features of powerpc.
it seems I am not the suitable member to continue trying.
I prefer Benjamin to continue trying (just like what he has done).
if Benjamin will not do it (e.g. maybe no time to do)
I should continue: "make additional room in exception vector area".
(if get no reply within a week: before 2013-03-28, I should continue)
welcome any members' (especially Benjamin) suggestions or completions.
thanks.
:-)
On 2013年03月15日 13:14, Chen Gang wrote:
于 2013年03月15日 12:52, Michael Neuling 写道:
quoted
Yep it's a known problem but no one has bothered to fix it since it
doesn't happen in a config that anyone cares about like
pseries_defconfig and ppc64_defconfig. We've been moving code around in
this area a lot recently hence the breakage.
It should be fixed though. Patches welcome. :-)
thanks, and I should try, and very glad to try.
:-) :-)
excuse me, I try to provide related patch within this month (2013-03-31), is it ok ?
the reason is:
I am not familiar with ppc assembly code, neither ppc kernel,
so need additional time resource.
(originally, I worked for x86(_64) core dump analysing for kernel and user programs)
thanks.
From: Michael Neuling <hidden> Date: 2013-03-21 22:54:50
Chen Gang [off-list ref] wrote:
Hello All:
=20
summary:
the root cause is no enough room in exception area (0x5500 -- 0x7000).
=20
it is caused by the patches "for saving/restre PPR":
they consumed much space of this area (0x5500 -- 0x7000).
for pseries_defconfig and ppc64_defconfig, it is still ok.
but for allmodconfig and "some additional config", it will cause issu=
e.
=20
the solving patch "Make room in exception vector area" can make room la=
rger.
it can let "some additional config" ok.
but for allmodconfig, it is still not enough.
=20
=20
details
reason:
it is caused by:
commit number: 13e7a8e846c2ea38a552b986ea49332f965bbb7a
commit number: 44e9309f1f357794b7ae93d5f3e3e6f11d2b8a7f
they are "for saving/restore PPR"
by Haren Myneni [off-list ref] Thu, 6 Dec 2012
compiling result:
pseries_defconfig: pass (cpu for POWER7)
ppc64_defconfig: pass (cpu for POWER7)
allmodconfig: failed (cpu for POWER7)
=20
analysing:
solving patch:
------------------------------------------------------------------
commit number: 61383407677aef05928541a00678591abea2d84c
Author: Benjamin Herrenschmidt [off-list ref]
Date: Thu Jan 10 17:44:19 2013 +1100
=20
powerpc: Make room in exception vector area
=20=20=20=20=20
The FWNMI region is fixed at 0x7000 and the vector are now
overflowing that with some configurations. Fix that by moving
some hash management code out of that region as it doesn't need
to be that close to the call sites (isn't accessed using
conditional branches).
------------------------------------------------------------------
=20
but for allmodconfig (not only for "some configurations"):
it really can reduce much overflow bytes,
(maybe from hundreds bytes to dozens bytes)
but still not enough (still content overflow bytes)
=20
additional trying:
after del CONFIG_VSX and CONFIG_PPC_970_NAP in allmodconfig,
(will reduce dozens bytes in the region .0x5500 -- .0x7000)
it can pass compiling (not overflow).
=20
=20
next:
I am sorry:
I am not quite familiar with the detail features of powerpc.
it seems I am not the suitable member to continue trying.
=20
I prefer Benjamin to continue trying (just like what he has done).
=20
if Benjamin will not do it (e.g. maybe no time to do)
I should continue: "make additional room in exception vector area".
(if get no reply within a week: before 2013-03-28, I should continu=
e)
=20
=20
=20
welcome any members' (especially Benjamin) suggestions or completions.
This is great, thanks a lot.=20=20
If you want this to be picked up by the maintainer, you'll need to add
your signed-off-by.
The signed-off-by is to indicate that your happy for it to be included
and that you're legally allowed to do so. See
http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
for more info.
Mikey
=20
thanks.
=20
:-)
=20
=20
On 2013=E5=B9=B403=E6=9C=8815=E6=97=A5 13:14, Chen Gang wrote:
quoted
=E4=BA=8E 2013=E5=B9=B403=E6=9C=8815=E6=97=A5 12:52, Michael Neuling =
=E5=86=99=E9=81=93:
quoted
quoted
Yep it's a known problem but no one has bothered to fix it since it
doesn't happen in a config that anyone cares about like
pseries_defconfig and ppc64_defconfig. We've been moving code around =
in
quoted
quoted
this area a lot recently hence the breakage.
It should be fixed though. Patches welcome. :-)
=20
thanks, and I should try, and very glad to try.
=20
:-) :-)
=20
excuse me, I try to provide related patch within this month (2013-03-=
31), is it ok ?
quoted
the reason is:
I am not familiar with ppc assembly code, neither ppc kernel,
so need additional time resource.
(originally, I worked for x86(_64) core dump analysing for kernel=
and user programs)
quoted
=20
thanks.
=20
=20
=20
--=20
Chen Gang
=20
Asianux Corporation
=20
From: Chen Gang <hidden> Date: 2013-03-22 06:56:03
On 2013年03月22日 06:54, Michael Neuling wrote:
This is great, thanks a lot.
If you want this to be picked up by the maintainer, you'll need to add
your signed-off-by.
The signed-off-by is to indicate that your happy for it to be included
and that you're legally allowed to do so. See
http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
for more info.
Mikey
thanks, too.
I prefer Benjamin to have a closer look for my fixing.
if pass his checking, I will send a patch.
(he is on vacation, now, and he will check it when he is back).
Regards
--
Chen Gang
Asianux Corporation
From: Michael Neuling <hidden> Date: 2013-03-25 00:03:43
Chen Gang [off-list ref] wrote:
On 2013=E5=B9=B403=E6=9C=8822=E6=97=A5 06:54, Michael Neuling wrote:
quoted
This is great, thanks a lot.=20=20
=20
If you want this to be picked up by the maintainer, you'll need to add
your signed-off-by.
=20
The signed-off-by is to indicate that your happy for it to be included
and that you're legally allowed to do so. See
http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
for more info.
=20
Mikey
=20
thanks, too.
I prefer Benjamin to have a closer look for my fixing.
if pass his checking, I will send a patch.
(he is on vacation, now, and he will check it when he is back).
benh asked paulus or sfr to send in while he was away.
So please send your signed off by now (if you can), or someone is going
to rewrite it, sent it upstream bypassing you.
Mikey
From: Chen Gang <hidden> Date: 2013-03-25 01:07:38
On 2013年03月25日 08:03, Michael Neuling wrote:
benh asked paulus or sfr to send in while he was away.
So please send your signed off by now (if you can), or someone is going
to rewrite it, sent it upstream bypassing you.
Mikey
thanks, I will send patch now.
:-)
--
Chen Gang
Asianux Corporation
From: Chen Gang <hidden> Date: 2013-03-25 01:32:05
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)
Signed-off-by: Chen Gang <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 144 +++++++++++++++++-----------------
1 files changed, 72 insertions(+), 72 deletions(-)
@@ -1066,78 +1066,6 @@ unrecov_user_slb:#endif /* __DISABLED__ */-/*-*r13pointstothePACA,r9containsthesavedCR,-*r12containthesavedSRR1,SRR0isstillreadyforreturn-*r3hasthefaultingaddress-*r9-r13aresavedinpaca->exslb.-*r3issavedinpaca->slb_r3-*Weassumewearen't going to take any exceptions during this procedure.-*/-_GLOBAL(slb_miss_realmode)-mflrr10-#ifdef CONFIG_RELOCATABLE-mtctrr11-#endif--stwr9,PACA_EXSLB+EX_CCR(r13)/*saveCRinexc.frame*/-stdr10,PACA_EXSLB+EX_LR(r13)/*saveLR*/--bl.slb_allocate_realmode--/*Alldone--returnfromexception.*/--ldr10,PACA_EXSLB+EX_LR(r13)-ldr3,PACA_EXSLB+EX_R3(r13)-lwzr9,PACA_EXSLB+EX_CCR(r13)/*getsavedCR*/--mtlrr10--andi.r10,r12,MSR_RI/*checkforunrecoverableexception*/-beq-2f--.machinepush-.machine"power4"-mtcrf0x80,r9-mtcrf0x01,r9/*slb_allocateusescr0andcr7*/-.machinepop--RESTORE_PPR_PACA(PACA_EXSLB,r9)-ldr9,PACA_EXSLB+EX_R9(r13)-ldr10,PACA_EXSLB+EX_R10(r13)-ldr11,PACA_EXSLB+EX_R11(r13)-ldr12,PACA_EXSLB+EX_R12(r13)-ldr13,PACA_EXSLB+EX_R13(r13)-rfid-b./*preventspeculativeexecution*/--2:mfsprr11,SPRN_SRR0-ldr10,PACAKBASE(r13)-LOAD_HANDLER(r10,unrecov_slb)-mtsprSPRN_SRR0,r10-ldr10,PACAKMSR(r13)-mtsprSPRN_SRR1,r10-rfid-b.--unrecov_slb:-EXCEPTION_PROLOG_COMMON(0x4100,PACA_EXSLB)-DISABLE_INTS-bl.save_nvgprs-1:addir3,r1,STACK_FRAME_OVERHEAD-bl.unrecoverable_exception-b1b---#ifdef CONFIG_PPC_970_NAP-power4_fixup_nap:-andcr9,r9,r10-stdr9,TI_LOCAL_FLAGS(r11)-ldr10,_LINK(r1)/*makeidletaskdothe*/-stdr10,_NIP(r1)/*equivalentofablr*/-blr-#endif-.align7.globlalignment_commonalignment_common:
@@ -1336,6 +1264,78 @@ _GLOBAL(opal_mc_secondary_handler)/*+*r13pointstothePACA,r9containsthesavedCR,+*r12containthesavedSRR1,SRR0isstillreadyforreturn+*r3hasthefaultingaddress+*r9-r13aresavedinpaca->exslb.+*r3issavedinpaca->slb_r3+*Weassumewearen't going to take any exceptions during this procedure.+*/+_GLOBAL(slb_miss_realmode)+mflrr10+#ifdef CONFIG_RELOCATABLE+mtctrr11+#endif++stwr9,PACA_EXSLB+EX_CCR(r13)/*saveCRinexc.frame*/+stdr10,PACA_EXSLB+EX_LR(r13)/*saveLR*/++bl.slb_allocate_realmode++/*Alldone--returnfromexception.*/++ldr10,PACA_EXSLB+EX_LR(r13)+ldr3,PACA_EXSLB+EX_R3(r13)+lwzr9,PACA_EXSLB+EX_CCR(r13)/*getsavedCR*/++mtlrr10++andi.r10,r12,MSR_RI/*checkforunrecoverableexception*/+beq-2f++.machinepush+.machine"power4"+mtcrf0x80,r9+mtcrf0x01,r9/*slb_allocateusescr0andcr7*/+.machinepop++RESTORE_PPR_PACA(PACA_EXSLB,r9)+ldr9,PACA_EXSLB+EX_R9(r13)+ldr10,PACA_EXSLB+EX_R10(r13)+ldr11,PACA_EXSLB+EX_R11(r13)+ldr12,PACA_EXSLB+EX_R12(r13)+ldr13,PACA_EXSLB+EX_R13(r13)+rfid+b./*preventspeculativeexecution*/++2:mfsprr11,SPRN_SRR0+ldr10,PACAKBASE(r13)+LOAD_HANDLER(r10,unrecov_slb)+mtsprSPRN_SRR0,r10+ldr10,PACAKMSR(r13)+mtsprSPRN_SRR1,r10+rfid+b.++unrecov_slb:+EXCEPTION_PROLOG_COMMON(0x4100,PACA_EXSLB)+DISABLE_INTS+bl.save_nvgprs+1:addir3,r1,STACK_FRAME_OVERHEAD+bl.unrecoverable_exception+b1b+++#ifdef CONFIG_PPC_970_NAP+power4_fixup_nap:+andcr9,r9,r10+stdr9,TI_LOCAL_FLAGS(r11)+ldr10,_LINK(r1)/*makeidletaskdothe*/+stdr10,_NIP(r1)/*equivalentofablr*/+blr+#endif++/**Hashtablestuff*/.align7
From: Stephen Rothwell <hidden> Date: 2013-03-25 05:14:44
Hi all,
On Mon, 25 Mar 2013 09:31:31 +0800 Chen Gang [off-list ref] wrote:
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)
Signed-off-by: Chen Gang <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 144 +++++++++++++++++-----------------
1 files changed, 72 insertions(+), 72 deletions(-)
Thanks, Chen,
I have applied this to linux-next today and pending the builds overnight,
will send it to Linus tomorrow or Wednesday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Chen Gang <hidden> Date: 2013-03-25 05:39:22
On 2013年03月25日 13:14, Stephen Rothwell wrote:
Hi all,
On Mon, 25 Mar 2013 09:31:31 +0800 Chen Gang [off-list ref] wrote:
quoted
quoted
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)
Signed-off-by: Chen Gang <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 144 +++++++++++++++++-----------------
1 files changed, 72 insertions(+), 72 deletions(-)
Thanks, Chen,
I have applied this to linux-next today and pending the builds overnight,
will send it to Linus tomorrow or Wednesday.
From: Michael Neuling <hidden> Date: 2013-03-25 06:07:23
Stephen Rothwell [off-list ref] wrote:
Hi all,
On Mon, 25 Mar 2013 09:31:31 +0800 Chen Gang [off-list ref] wrote:
quoted
The FWNMI region is fixed at 0x7000 and the vector are now overflowing
that with allmodconfig. Fix that by moving slb_miss_realmode code out
of that region as it doesn't need to be that close to the call sites
(it is a _GLOBAL function)
Signed-off-by: Chen Gang <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 144 +++++++++++++++++-----------------
1 files changed, 72 insertions(+), 72 deletions(-)
Thanks, Chen,
I have applied this to linux-next today and pending the builds overnight,
will send it to Linus tomorrow or Wednesday.