linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards The last time I got this error, I needed to apply patch powerpc: Fix attempt to move .org backwards error, but that has been included in the powerpc tree now, so I guess something else has added code in a critical place. :-( I have just left this broken for today. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgp1XF9k6ifpC.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Mon, 2014-01-06 at 20:28 +1100, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards The last time I got this error, I needed to apply patch powerpc: Fix attempt to move .org backwards error, but that has been included in the powerpc tree now, so I guess something else has added code in a critical place. :-( I have just left this broken for today. I had to modify that patch when applying it, it's possible that the new version isn't making as much room. Without that change it would fail the build on some of my configs due to some of the asm for the maskable exception handling being too far from the conditional branches that calls it. I think it's time we do a bit of re-org of that file to figure out precisely what has to be where and move things out more aggressively. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:958: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:959: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:983: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:984: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1003: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1013: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1014: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1015: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1016: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1017: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1018: Error: attempt to move .org backwards Caused by commit 1e9b4507ed98 (powerpc/book3s: handle machine check in Linux host). I have reverted these commits (possibly some of these reverts are unnecessary): b63a0ffe35de powerpc/powernv: Machine check exception handling 28446de2ce99 powerpc/powernv: Remove machine check handling in OPAL b5ff4211a829 powerpc/book3s: Queue up and process delayed MCE events 36df96f8acaf powerpc/book3s: Decode and save machine check event ae744f3432d3 powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8 e22a22740c1a powerpc/book3s: Flush SLB/TLBs if we get SLB/TLB machine check errors on power7 0440705049b0 powerpc/book3s: Add flush_tlb operation in cpu_spec 4c703416efc0 powerpc/book3s: Introduce a early machine check hook in cpu_spec 1c51089f777b powerpc/book3s: Return from interrupt if coming from evil context 1e9b4507ed98 powerpc/book3s: handle machine check in Linux host -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgpc4ymwFbUDD.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (Linus' tree related - powerpc)
On Thu, Nov 21, 2013 at 02:33:34PM +1100, Anton Blanchard wrote: Hi, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: stdin:1:0: error: -mcall-aixdesc must be big endian Urgh, allyesconfig is building an LE kernel. Ian: do we need to reverse the polarity of the option, and call it CONFIG_CPU_BIG_ENDIAN? More or less. See what we did with PPC_WERROR, for the same reasons, so that it was off for an allyesconfig. config PPC_DISABLE_WERROR bool Don't build arch/powerpc code with -Werror default n config PPC_WERROR bool depends on !PPC_DISABLE_WERROR default y cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (Linus' tree related - powerpc)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 31: printf: #: invalid number scripts/gcc-version.sh: line 31: printf: #: invalid number stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 31: printf: #: invalid number scripts/gcc-version.sh: line 31: printf: #: invalid number stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 29: printf: #: invalid number scripts/gcc-version.sh: line 29: printf: #: invalid number scripts/gcc-version.sh: line 29: printf: #: invalid number /bin/sh: line 0: test: 0001 6000 0160: integer expression expected scripts/mod/empty.c:1:0: error: -mcall-aixdesc must be big endian /* empty file to figure out endianness / word size */ ^ scripts/mod/devicetable-offsets.c:1:0: error: -mcall-aixdesc must be big endian #include linux/kbuild.h ^ kernel/bounds.c:1:0: error: -mcall-aixdesc must be big endian /* ^ Caused by commit 7c105b63bd98 (powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option). I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBlULjp0d08.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (Linus' tree related - powerpc)
Hi, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: stdin:1:0: error: -mcall-aixdesc must be big endian Urgh, allyesconfig is building an LE kernel. Ian: do we need to reverse the polarity of the option, and call it CONFIG_CPU_BIG_ENDIAN? Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hi all, Yes, I agree. The other filesystems that take an Opt_uid as well do use current_user_ns() and not init_user_ns. They also do a uid_valid() check and fail the mount (or fallback to GLOBAL_ROOT_UID). So I think that would look like this: Looks good to me. Builds and mounts as expected. Acked-by: Jeremy Kerr j...@ozlabs.org Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hey Stephen, On Wed, Aug 21, 2013 at 10:22:46AM +1000, Stephen Rothwell wrote: On Tue, 20 Aug 2013 14:28:44 -0500 Ben Myers b...@sgi.com wrote: I'd prefer not to break Stephen's tree two days in a row. We could just revert d6970d4b726c in the xfs tree for the time being as Stephen has done, but given the choice would prefer the fix. Do you have a preference between the two approaches that Dwight has posted? The first seems more conservative... I will automatically revert that commit when I merge the xfs tree until some other solution is forthcoming (so you don't have to do the revert in the xfs tree). Gah. That makes sense. ;) This does need to be fixed fairly soon, though. Agreed, thanks. -Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hey Dwight, On Wed, Aug 21, 2013 at 02:30:04PM +0800, Jeremy Kerr wrote: Yes, I agree. The other filesystems that take an Opt_uid as well do use current_user_ns() and not init_user_ns. They also do a uid_valid() check and fail the mount (or fallback to GLOBAL_ROOT_UID). So I think that would look like this: Looks good to me. Builds and mounts as expected. Acked-by: Jeremy Kerr j...@ozlabs.org Could you repost this patch with the right subject and a commit header? Given Jeremy's Ack I think we could proceed to pull this in. Regards, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_parse_options': arch/powerpc/platforms/cell/spufs/inode.c:623:16: error: incompatible types when assigning to type 'kuid_t' from type 'int' root-i_uid = option; ^ arch/powerpc/platforms/cell/spufs/inode.c:628:16: error: incompatible types when assigning to type 'kgid_t' from type 'int' root-i_gid = option; ^ Caused by commit d6970d4b726c (enable building user namespace with xfs) from the xfs tree (that was fun to find :-)). I have reverted that commit for today. It could probably be replaced with a patch that just changed XFS_FS to SPU_FS in the UIDGID_CONVERTED config dependency - or someone could fix up SPU_FS. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpL9hfmmReB9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Tuesday 20 August 2013, Dwight Engen wrote: diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c index f390042..90fb308 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -620,12 +620,12 @@ spufs_parse_options(struct super_block *sb, char *options, struct inode *root) case Opt_uid: if (match_int(args[0], option)) return 0; - root-i_uid = option; + root-i_uid = make_kuid(init_user_ns, option); break; case Opt_gid: if (match_int(args[0], option)) return 0; - root-i_gid = option; + root-i_gid = make_kgid(init_user_ns, option); break; case Opt_mode: if (match_octal(args[0], option)) Doesn't this mean the uid/gid is taken from the initial namespace rather than from the namespace of the 'mount' process calling this? I think the logical choice would be to have the UID be the one that gets passed here in the caller's namespace. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Tue, 20 Aug 2013 17:20:52 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_parse_options': arch/powerpc/platforms/cell/spufs/inode.c:623:16: error: incompatible types when assigning to type 'kuid_t' from type 'int' root-i_uid = option; ^ arch/powerpc/platforms/cell/spufs/inode.c:628:16: error: incompatible types when assigning to type 'kgid_t' from type 'int' root-i_gid = option; ^ Caused by commit d6970d4b726c (enable building user namespace with xfs) from the xfs tree (that was fun to find :-)). I have reverted that commit for today. It could probably be replaced with a patch that just changed XFS_FS to SPU_FS in the UIDGID_CONVERTED config dependency - or someone could fix up SPU_FS. Hi, (already sent this email based on Intel's kbuild robot this morning, sorry for the dup to those who already got it). Yep this looks to me like SPU_FS should have been in the list of stuff that had not been UIDGID_CONVERTED, but reviving UIDGID_CONVERTED and adding SPU_FS to it won't work for non powerpc arch because SPU_FS = n won't be defined. The following can be used to mark it as incompatible with USER_NS: diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 9978f59..fcf8336 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -61,6 +61,7 @@ config SPU_FS tristate SPU file system default m depends on PPC_CELL + depends on USER_NS=n select SPU_BASE select MEMORY_HOTPLUG help Or if the rest of spufs is already okay for user namespace (I have not checked it, but this seems to be the only place it is dealing with uid/gid), then the following will fix these particular errors (cross-compile tested, but I don't have a powerpc to run test on): diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c index f390042..90fb308 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -620,12 +620,12 @@ spufs_parse_options(struct super_block *sb, char *options, struct inode *root) case Opt_uid: if (match_int(args[0], option)) return 0; - root-i_uid = option; + root-i_uid = make_kuid(init_user_ns, option); break; case Opt_gid: if (match_int(args[0], option)) return 0; - root-i_gid = option; + root-i_gid = make_kgid(init_user_ns, option); break; case Opt_mode: if (match_octal(args[0], option)) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hi Jeremy, Apologies for breaking your build... On Tue, Aug 20, 2013 at 12:07:02PM -0400, Dwight Engen wrote: On Tue, 20 Aug 2013 17:20:52 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_parse_options': arch/powerpc/platforms/cell/spufs/inode.c:623:16: error: incompatible types when assigning to type 'kuid_t' from type 'int' root-i_uid = option; ^ arch/powerpc/platforms/cell/spufs/inode.c:628:16: error: incompatible types when assigning to type 'kgid_t' from type 'int' root-i_gid = option; ^ Caused by commit d6970d4b726c (enable building user namespace with xfs) from the xfs tree (that was fun to find :-)). I have reverted that commit for today. It could probably be replaced with a patch that just changed XFS_FS to SPU_FS in the UIDGID_CONVERTED config dependency - or someone could fix up SPU_FS. Hi, (already sent this email based on Intel's kbuild robot this morning, sorry for the dup to those who already got it). Yep this looks to me like SPU_FS should have been in the list of stuff that had not been UIDGID_CONVERTED, but reviving UIDGID_CONVERTED and adding SPU_FS to it won't work for non powerpc arch because SPU_FS = n won't be defined. The following can be used to mark it as incompatible with USER_NS: diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig index 9978f59..fcf8336 100644 --- a/arch/powerpc/platforms/cell/Kconfig +++ b/arch/powerpc/platforms/cell/Kconfig @@ -61,6 +61,7 @@ config SPU_FS tristate SPU file system default m depends on PPC_CELL + depends on USER_NS=n select SPU_BASE select MEMORY_HOTPLUG help Or if the rest of spufs is already okay for user namespace (I have not checked it, but this seems to be the only place it is dealing with uid/gid), then the following will fix these particular errors (cross-compile tested, but I don't have a powerpc to run test on): diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c index f390042..90fb308 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -620,12 +620,12 @@ spufs_parse_options(struct super_block *sb, char *options, struct inode *root) case Opt_uid: if (match_int(args[0], option)) return 0; - root-i_uid = option; + root-i_uid = make_kuid(init_user_ns, option); break; case Opt_gid: if (match_int(args[0], option)) return 0; - root-i_gid = option; + root-i_gid = make_kgid(init_user_ns, option); break; case Opt_mode: if (match_octal(args[0], option)) I'd prefer not to break Stephen's tree two days in a row. We could just revert d6970d4b726c in the xfs tree for the time being as Stephen has done, but given the choice would prefer the fix. Do you have a preference between the two approaches that Dwight has posted? The first seems more conservative... Thanks, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hi Ben, On Tue, 20 Aug 2013 14:28:44 -0500 Ben Myers b...@sgi.com wrote: I'd prefer not to break Stephen's tree two days in a row. We could just revert d6970d4b726c in the xfs tree for the time being as Stephen has done, but given the choice would prefer the fix. Do you have a preference between the two approaches that Dwight has posted? The first seems more conservative... I will automatically revert that commit when I merge the xfs tree until some other solution is forthcoming (so you don't have to do the revert in the xfs tree). This does need to be fixed fairly soon, though. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJX5S7I3XCP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (linus' tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc64 allnoconfig) failed like this: In file included from arch/powerpc/include/asm/kvm_ppc.h:33:0, from arch/powerpc/kernel/setup_64.c:67: arch/powerpc/include/asm/kvm_book3s.h:65:20: error: field 'pte' has incomplete type arch/powerpc/include/asm/kvm_book3s.h:69:18: error: field 'vcpu' has incomplete type arch/powerpc/include/asm/kvm_book3s.h:98:34: error: 'HPTEG_HASH_NUM_PTE' undeclared here (not in a function) arch/powerpc/include/asm/kvm_book3s.h:99:39: error: 'HPTEG_HASH_NUM_PTE_LONG' undeclared here (not in a function) arch/powerpc/include/asm/kvm_book3s.h:100:35: error: 'HPTEG_HASH_NUM_VPTE' undeclared here (not in a function) arch/powerpc/include/asm/kvm_book3s.h:101:40: error: 'HPTEG_HASH_NUM_VPTE_LONG' undeclared here (not in a function) arch/powerpc/include/asm/kvm_book3s.h:129:4: error: 'struct kvm_run' declared inside parameter list [-Werror] arch/powerpc/include/asm/kvm_book3s.h:129:4: error: its scope is only this definition or declaration, which is probably not what you want [-Werror] And it went downhill form there. This build does not have CONFIG_KVM defined. Caused by commit f445f11eb2cc (KVM: allow host header to be included even for !CONFIG_KVM) which clearly never saw the light of day in linux-next :-( It would have been nice if the compile failure when KVM is not enabled was included in the commit log so that we could figure out exactly what needed to be protected instead of just effectively removing the whole file. I just reverted that commit for today. Can someone please supply a better solution or even just more information about what that commit was solving. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpgr1EPTSjiM.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/kgdb.c: In function 'kgdb_arch_exit': arch/powerpc/kernel/kgdb.c:492:2: error: '__debugger_breakx_match' undeclared (first use in this function) Caused by commit 9422de3e953d (powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers). I applied powerpc: Fix typo in breakpoint kgdb code from Mikey for this. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1204: Error: attempt to move .org backwards Not sure what caused that - probably a combination of patches adding code low down. I have just left this broken for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpnvRx6z7fjt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/kgdb.c: In function 'kgdb_arch_exit': arch/powerpc/kernel/kgdb.c:492:2: error: '__debugger_breakx_match' undeclared (first use in this function) Caused by commit 9422de3e953d (powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers). I applied powerpc: Fix typo in breakpoint kgdb code from Mikey for this. arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1204: Error: attempt to move .org backwards Not sure what caused that - probably a combination of patches adding code low down. I have just left this broken for today. FWIW I posted this earlier http://patchwork.ozlabs.org/patch/211184/ Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powercp tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: lib/pSeries-reconfig-notifier-error-inject.c:4:34: fatal error: asm/pSeries_reconfig.h: No such file or directory Caused by commit f459d63e1689 (powerpc+of: Remove the pSeries_reconfig.h file) and even if the file existed, things were removed by commit 1cf3d8b3d24c (powerpc+of: Add of node/property notification chain for adds and removes) that would cause lib/pSeries-reconfig-notifier-error-inject.c to fail to build. I have marked it as broken for now using this patch: From: Stephen Rothwell s...@canb.auug.org.au Date: Thu, 15 Nov 2012 18:02:13 +1100 Subject: [PATCH] lib: disable PSERIES_RECONFIG_NOTIFIER_ERROR_INJECT It has been fundamentally broken by other changes. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- lib/Kconfig.debug |1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 41faf0b..ad84944 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1195,6 +1195,7 @@ config MEMORY_NOTIFIER_ERROR_INJECT config PSERIES_RECONFIG_NOTIFIER_ERROR_INJECT tristate pSeries reconfig notifier error injection module depends on PPC_PSERIES NOTIFIER_ERROR_INJECTION + depends on BROKEN help This option provides the ability to inject artifical errors to pSeries reconfig notifier chain callbacks. It is controlled -- 1.7.10.280.gaa39 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgplsIcr2EUZX.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powercp tree related)
On Thu, 2012-11-15 at 18:06 +1100, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: lib/pSeries-reconfig-notifier-error-inject.c:4:34: fatal error: asm/pSeries_reconfig.h: No such file or directory Caused by commit f459d63e1689 (powerpc+of: Remove the pSeries_reconfig.h file) and even if the file existed, things were removed by commit 1cf3d8b3d24c (powerpc+of: Add of node/property notification chain for adds and removes) that would cause lib/pSeries-reconfig-notifier-error-inject.c to fail to build. I have marked it as broken for now using this patch: My bad, didn't notice, I don't have error injection enabled in my test configs. I think that stuff went in after the original patches were written I think. Not a big deal, nobody actually enables that error inject test stuff just yet, I'll put a fix patch into my dt and my next branch asap. Cheers, Ben. From: Stephen Rothwell s...@canb.auug.org.au Date: Thu, 15 Nov 2012 18:02:13 +1100 Subject: [PATCH] lib: disable PSERIES_RECONFIG_NOTIFIER_ERROR_INJECT It has been fundamentally broken by other changes. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- lib/Kconfig.debug |1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 41faf0b..ad84944 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1195,6 +1195,7 @@ config MEMORY_NOTIFIER_ERROR_INJECT config PSERIES_RECONFIG_NOTIFIER_ERROR_INJECT tristate pSeries reconfig notifier error injection module depends on PPC_PSERIES NOTIFIER_ERROR_INJECTION + depends on BROKEN help This option provides the ability to inject artifical errors to pSeries reconfig notifier chain callbacks. It is controlled -- 1.7.10.280.gaa39 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Sat, 22 Sep 2012 07:46:40 +1000 Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all of memory is ZONE_DMA). It's always been like that afaik. We could support ISA device limited addressability using the iommu but that would involve a map/unmap type API (which I remember we did support in the old days by passing NULL to pci_map_*, but we dropped that along the way). I think I'm going to just end up restricting this driver to X86 as was originally suggested. There seems to be no real consistent Kconfig protection for users of isa_virt_to_bus() and friends. We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either as powerpc also allows that to bet set for CHRP and friends. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
On Sat, 2012-09-22 at 16:00 -0400, David Miller wrote: I think I'm going to just end up restricting this driver to X86 as was originally suggested. Probably the easiest fix indeed. There seems to be no real consistent Kconfig protection for users of isa_virt_to_bus() and friends. We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either as powerpc also allows that to bet set for CHRP and friends. It's a old mess :-( And not an easy one to untangle... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
On Thu, 2012-09-20 at 18:53 -0400, David Miller wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Fri, 21 Sep 2012 08:22:44 +1000 Hrm, that's ancient gunk, I'll have to dig. We potentially can support ISA devices DMA'ing from an ISA bridge... but via the iommu, which means isa_virt_to_bus is a non-starter. But then, do we really care ? IE. Is there single device that actually requires ISA_DMA_API and that is expected to work on any currently supported powerpc hw ? :-) We don't even support PReP anymore, so that leaves us with what ? ISA_DMA_API implies a fixed window of addresses which are = 32-bits on the bus, which is a hardware requirement of these devices. isa_virt_to_bus() goes to that physical address, and the expection is that you use GFP_DMA and thus the physical addresses fit inside of an unsigned int. Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all of memory is ZONE_DMA). It's always been like that afaik. We could support ISA device limited addressability using the iommu but that would involve a map/unmap type API (which I remember we did support in the old days by passing NULL to pci_map_*, but we dropped that along the way). isa_virt_to_bus() basically amounts to a virt--phys plus a cast. Anybody has an objection to turning ISA_DMA_API off ? Then you can remove all of the DMA api stuff in powerpc's asm/dma.h but some of it looks like it might be in use. I will dig a bit. I think there might be some users of the ISA DMA engine for legacy floppies and parport on some early pSeries and CHRP machines (including Pegasos). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
[Just bring this to the attention of the PowerPC folks ...] On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller da...@davemloft.net wrote: From: Mika Westerberg mika.westerb...@linux.intel.com Date: Thu, 20 Sep 2012 12:10:14 +0300 On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init': drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration] Caused by commit 1d3ff76759b7 (i825xx: znet: fix compiler warnings when building a 64-bit kernel). Is there some Kconfig dependency missing (CONFIG_ISA)? If we make it dependent on CONFIG_ISA then the driver cannot be built with 64-bit kernel. Then again is there someone running 64-bit kernel on Zenith Z-note notebook? From the pictures it looks like very ancient laptop. An alternative is to make it depend on X86 like this: I think the powerpc port is at fault here. Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus(). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpWzg6cwmaH4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
I think the powerpc port is at fault here. Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus(). Hrm, that's ancient gunk, I'll have to dig. We potentially can support ISA devices DMA'ing from an ISA bridge... but via the iommu, which means isa_virt_to_bus is a non-starter. But then, do we really care ? IE. Is there single device that actually requires ISA_DMA_API and that is expected to work on any currently supported powerpc hw ? :-) We don't even support PReP anymore, so that leaves us with what ? Anybody has an objection to turning ISA_DMA_API off ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
Hi Dave, On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller da...@davemloft.net wrote: I think the powerpc port is at fault here. Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus(). Not disagreeing, but it would be nice if this was documented somewhere (maybe in Documentation/DMA-ISA-LPC.txt). We have not had this problem before because all the other uses of isa_virt_to_bus() are in drivers that depend on X86 or ARM or ISA or EISA. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpH3JFkMDQYO.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Fri, 21 Sep 2012 08:22:44 +1000 Hrm, that's ancient gunk, I'll have to dig. We potentially can support ISA devices DMA'ing from an ISA bridge... but via the iommu, which means isa_virt_to_bus is a non-starter. But then, do we really care ? IE. Is there single device that actually requires ISA_DMA_API and that is expected to work on any currently supported powerpc hw ? :-) We don't even support PReP anymore, so that leaves us with what ? ISA_DMA_API implies a fixed window of addresses which are = 32-bits on the bus, which is a hardware requirement of these devices. isa_virt_to_bus() goes to that physical address, and the expection is that you use GFP_DMA and thus the physical addresses fit inside of an unsigned int. isa_virt_to_bus() basically amounts to a virt--phys plus a cast. Anybody has an objection to turning ISA_DMA_API off ? Then you can remove all of the DMA api stuff in powerpc's asm/dma.h but some of it looks like it might be in use. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
In file included from drivers/atm/fore200e.c:70:0:
drivers/atm/fore200e.h:263:3: error: redefinition of typedef 'opcode_t' with
different type
arch/powerpc/include/asm/probes.h:25:13: note: previous declaration of
'opcode_t' was here
Caused by commit 7118e7e648e0 (powerpc: Consolidate {k,u}probe
definitions) from the powerpc tree.
I have reverted that commit (and the two following:
41ab5266c362powerpc: Add trap_nr to thread_struct
8b7b80b9ebb4powerpc: Uprobes port to powerpc)
for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp88dPx4Isth.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Thu, Sep 06, 2012 at 05:11:53PM +1000, Stephen Rothwell wrote:
Hi all,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
In file included from drivers/atm/fore200e.c:70:0:
drivers/atm/fore200e.h:263:3: error: redefinition of typedef 'opcode_t' with
different type
arch/powerpc/include/asm/probes.h:25:13: note: previous declaration of
'opcode_t' was here
Caused by commit 7118e7e648e0 (powerpc: Consolidate {k,u}probe
definitions) from the powerpc tree.
I have reverted that commit (and the two following:
41ab5266c362 powerpc: Add trap_nr to thread_struct
8b7b80b9ebb4 powerpc: Uprobes port to powerpc)
for today.
Hi Stephen,
I have just posted a patch [1] to fix the issue.
Ananth
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-September/100813.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Fri, Jul 06, 2012 at 01:01:37PM +1000, Stephen Rothwell wrote: solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24 ^ I assume at this point, we are just too large. Yeah, but not in total. I didn't see any of these in the allyes kernel I built with our proof of concept hack to avoid ld -r. I think you'll find that these are all from ld -r output, as I assume no one in kernel land writes drivers or whatever with 33M of text in a single file. Branches in that monstrous section can't even reach the trampolines that ld inserts to extend branch reach. Did I mention that ld -r is a bad idea? One workaround might be to compile with -ffunction-sections. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested': (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern I got more than 6 of these messages before I killed the link. :-( I am not sure what has changed to do this, but it may have been masked for the past few releases due to other linking problems. I have left this broken for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpqRQpIvCMpr.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote: powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested': (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern I got more than 6 of these messages before I killed the link. :-( I am not sure what has changed to do this, but it may have been masked for the past few releases due to other linking problems. Let me guess. You're using bleeding edge gcc but not binutils. a) Recent gcc has fixed prologue and epilogue generation which now properly makes use of out-of-line register save and restore functions when compiling with -Os. b) Recent ld doesn't emit out-of-line save/restore function for ld -r, but yours does. You need my 2012-06-22 patch. c) Kernel uses ld -r for packaging. (b) and (c) together mean you get a definition for _savegpr0_29 munged together with other functions. That's bad. If _savegpr0_29 wasn't emitted until the final link stage then it would be in a code section containing just save/restore functions. ld will analyse that section and notice the absense of toc relocations; functions therein don't use the toc and can thus be called from any toc group without needing a toc adjusting stub. In your case _savegpr0_29 is in a section that has toc relocations (from normal compiled code), so ld decides that any function in that section must have a proper value for the toc register. But calls to _savegpr0_29 don't have a following nop to overwrite with a toc restore insn, hence the ld error. Score another black mark for ld -r. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hi Alan, On Thu, 5 Jul 2012 19:13:48 +0930 Alan Modra amo...@gmail.com wrote: On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote: powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested': (.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern I got more than 6 of these messages before I killed the link. :-( I am not sure what has changed to do this, but it may have been masked for the past few releases due to other linking problems. Let me guess. You're using bleeding edge gcc but not binutils. powerpc-linux-gcc (GCC) 4.6.3 GNU ld (GNU Binutils) 2.22 both built from upstream sources (by Tony). a) Recent gcc has fixed prologue and epilogue generation which now properly makes use of out-of-line register save and restore functions when compiling with -Os. b) Recent ld doesn't emit out-of-line save/restore function for ld -r, but yours does. You need my 2012-06-22 patch. c) Kernel uses ld -r for packaging. (b) and (c) together mean you get a definition for _savegpr0_29 munged together with other functions. That's bad. If _savegpr0_29 wasn't emitted until the final link stage then it would be in a code section containing just save/restore functions. ld will analyse that section and notice the absense of toc relocations; functions therein don't use the toc and can thus be called from any toc group without needing a toc adjusting stub. In your case _savegpr0_29 is in a section that has toc relocations (from normal compiled code), so ld decides that any function in that section must have a proper value for the toc register. But calls to _savegpr0_29 don't have a following nop to overwrite with a toc restore insn, hence the ld error. Score another black mark for ld -r. OK, the new toolchain may be the problem. I changed from: powerpc-linux-gcc (GCC) 4.6.0 GNU ld (GNU Binutils) 2.21 on June 20 and the current errors may have been masked an early bailout after getting theses errors: powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern which have now been fixed. So would a simple patch that puts the _savegpr etc functions in their own section (defined how?) fix this for us? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSYgz9gmEJ9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote: which have now been fixed. So would a simple patch that puts the _savegpr etc functions in their own section (defined how?) fix this for us? Ah, the kernel provides its own save/restore functions, and these get mashed into a .text containing normal functions with toc references by ld -r. Well, you could stop using ld -r. Otherwise, try .section .text.save.restore,ax,@progbits -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
Hi Alan, On Fri, 6 Jul 2012 10:27:10 +0930 Alan Modra amo...@gmail.com wrote: On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote: which have now been fixed. So would a simple patch that puts the _savegpr etc functions in their own section (defined how?) fix this for us? Ah, the kernel provides its own save/restore functions, and these get mashed into a .text containing normal functions with toc references by ld -r. Well, you could stop using ld -r. Otherwise, try .section .text.save.restore,ax,@progbits OK, so that helped a lot. Now I get this: drivers/built-in.o: In function `.idt77252_init_ubr.isra.10': idt77252.c:(.text+0x1ff801c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o drivers/built-in.o: In function `.idt77252_init_tx': idt77252.c:(.text+0x1ff8258): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o drivers/built-in.o: In function `.idt77252_change_qos': idt77252.c:(.text+0x1ff86a0): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o drivers/built-in.o: In function `.idt77252_open': idt77252.c:(.text+0x1ff898c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o idt77252.c:(.text+0x1ff8f4c): relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_22' defined in .text.save.restore section in arch/powerpc/lib/built-in.o drivers/built-in.o: In function `.next_string': solos-pci.c:(.text+0x1ff8f54): relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o solos-pci.c:(.text+0x1ff8f64): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o drivers/built-in.o: In function `.print_buffer': solos-pci.c:(.text+0x1ff904c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o drivers/built-in.o: In function `.atm_remove': solos-pci.c:(.text+0x1ff91d4): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24 against symbol `.sysfs_remove_group' defined in .text section in fs/built-in.o drivers/built-in.o: In function `.fpga_tx': solos-pci.c:(.text+0x1ff950c): additional relocation overflows omitted from the output I assume at this point, we are just too large. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpOd3y4UQmaD.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern And those are generated calls so I don't see how we can fix them. Is this a module ? We should really be linking that stuff directly with the module The interesting thing is that we do build everything except a handful of files with -mminimal-toc unless something's wrong with our main Makefile Can you show the full build command that triggers the above ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern And those are generated calls so I don't see how we can fix them. Is this a module ? We should really be linking that stuff directly with the module No, it's builtin. The interesting thing is that we do build everything except a handful of files with -mminimal-toc unless something's wrong with our main Makefile Yeah, the top arch Makefile sets it, though we do override it in a few places. I tried removing those overrides and it didn't seem to make any difference. Can you show the full build command that triggers the above ? Well that would be a few MBs of log, but here's an excerpt: make -f scripts/Makefile.build obj=net/openvswitch /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-call ed-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c if [ -pg = -pg ]; then set -e ; perl /home/michael/src/kmk/next/scripts/recordmcount.pl powerpc little 64 /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objdump /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objcopy /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-s trict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-ld -m elf64ppc /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-nm --synthetic 0 net/openvswitch/vport-netdev.o; fi; And then a whole bunch of calls to ld. So we are at least building that file with -mminimal-toc. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 03:36:01PM +1000, Michael Ellerman wrote: On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern Those seem to be caused because we don't have a nop after the call, meaning we can't patch the TOC pointer on the way back. Adding a nop fixes those. But, then I get 32,410 variants of this: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern These functions should not need a TOC in the first place. There is code in the linker (for 64 bit only: bfd/elf64-ppc.c) to automatically generate them whenever they are needed. I suspect you compile with -Os. But I don't think you can use these functions when doing a sibling call since restgpr0_nn implies a return to the caller. restgpr1_nn would be different... And those are generated calls so I don't see how we can fix them. I started building with gcc 4.6.3/binutils 2.22 today. gcc 4.6.0/binutils 2.21 do not produce this error, it produces this instead (which has been happening for a long time): powerpc64-linux-ld: TOC section size exceeds 64k So presumably there's some new error checking that we're hitting, I imagine it was always broken, but now it's being more explicit. I'm not so sure. I suspect gcc, but upgrading gcc and binutils at the same time may not be the wisest... Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 17:07 +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern Can you show the full build command that triggers the above ? Well that would be a few MBs of log, but here's an excerpt: make -f scripts/Makefile.build obj=net/openvswitch /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-ca lled-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c if [ -pg = -pg ]; then set -e ; perl /home/michael/src/kmk/next/scripts/recordmcount.pl powerpc little 64 /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objdump /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objcopy /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno -strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-ld -m elf64ppc /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-nm --synthetic 0 net/openvswitch/vport-netdev.o; fi; Just for the record it's not the FTRACE stuff (-pg): /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-inline-functions-calle d-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c And same error. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 05:38:27PM +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 17:07 +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. Will fix. I'm a bit surprised to see this with gcc-4.6 though. Or does this gcc-4.6 have some of my recent mainline gcc patches enabling out-of-line save/restore functions for -Os? -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote: Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. I couldn't see how this might be occurring, then I remembered the kernel has this horrible practise of using ld -r to package object files. So linker generated functions might be munged together with other functions. Does this help? (It won't if the kernel is providing its own save/restore functions.) Index: bfd/elf64-ppc.c === RCS file: /cvs/src/src/bfd/elf64-ppc.c,v retrieving revision 1.387 diff -u -p -r1.387 elf64-ppc.c @@ -6494,9 +6494,10 @@ ppc64_elf_func_desc_adjust (bfd *obfd AT /* Provide any missing _save* and _rest* functions. */ htab-sfpr-size = 0; - for (i = 0; i sizeof (funcs) / sizeof (funcs[0]); i++) -if (!sfpr_define (info, funcs[i])) - return FALSE; + if (!info-relocatable) +for (i = 0; i sizeof (funcs) / sizeof (funcs[0]); i++) + if (!sfpr_define (info, funcs[i])) + return FALSE; elf_link_hash_traverse (htab-elf, func_desc_adjust, info); -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 21:13 +0930, Alan Modra wrote: On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote: Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. I couldn't see how this might be occurring, then I remembered the kernel has this horrible practise of using ld -r to package object files. So linker generated functions might be munged together with other functions. Does this help? (It won't if the kernel is providing its own save/restore functions.) The kernel does provide its own AIUI. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_half': (.text+0xe0): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte': (.text+0x130): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte_msh': (.text+0x180): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_word_negative_offset': (.text+0x1dc): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_half_negative_offset': (.text+0x238): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_negative_offset': (.text+0x294): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_msh_negative_offset': (.text+0x2f0): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: final link failed: Bad value I started building with gcc 4.6.3/binutils 2.22 today. gcc 4.6.0/binutils 2.21 do not produce this error, it produces this instead (which has been happening for a long time): powerpc64-linux-ld: TOC section size exceeds 64k -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJbS17JUrQk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: I hate our ABI is a good answer ? :-) I'll see what I can do tomorrow. Poke me when I'm in the office. Cheers, Ben. powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_half': (.text+0xe0): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte': (.text+0x130): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_byte_msh': (.text+0x180): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_word_negative_offset': (.text+0x1dc): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_half_negative_offset': (.text+0x238): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_negative_offset': (.text+0x294): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `sk_load_byte_msh_negative_offset': (.text+0x2f0): sibling call optimization to `bpf_internal_load_pointer_neg_helper' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `bpf_internal_load_pointer_neg_helper' extern powerpc64-linux-ld: final link failed: Bad value I started building with gcc 4.6.3/binutils 2.22 today. gcc 4.6.0/binutils 2.21 do not produce this error, it produces this instead (which has been happening for a long time): powerpc64-linux-ld: TOC section size exceeds 64k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern Those seem to be caused because we don't have a nop after the call, meaning we can't patch the TOC pointer on the way back. Adding a nop fixes those. But, then I get 32,410 variants of this: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern And those are generated calls so I don't see how we can fix them. I started building with gcc 4.6.3/binutils 2.22 today. gcc 4.6.0/binutils 2.21 do not produce this error, it produces this instead (which has been happening for a long time): powerpc64-linux-ld: TOC section size exceeds 64k So presumably there's some new error checking that we're hitting, I imagine it was always broken, but now it's being more explicit. I think we need some help from the toolchain experts, hi Alan :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Mon, 2012-02-27 at 17:37 +1100, Stephen Rothwell wrote: pci_add_resource_offset(resources, res, - (resource_size_t) hose-io_base_virt - _IO_BASE); + (resource_size_t)(unsigned long)hose-io_base_virt - _IO_BASE); We have to be careful here as we do want sign extension to happen (yeah it's odd, but it's the way we do IOs on ppc32 :-) Maybe I should change it one day). So we probably want to do: (resource_size_t)(long long)(hose-io_base_virt - _IO_BASE) Basically, IO resources are relative to _IO_BASE which on ppc32 is basically the virtual address where we map the first PHB IO space. Subsequent PHB mappings can end up below _IO_BASE, leading to negative resource values for IO BARs on those busses. It all works fine because even an unsigned addition will do the right thing as long as the value is fully sign extended. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On Mon, 2012-02-27 at 20:19 +1100, Benjamin Herrenschmidt wrote: On Mon, 2012-02-27 at 17:37 +1100, Stephen Rothwell wrote: pci_add_resource_offset(resources, res, - (resource_size_t) hose-io_base_virt - _IO_BASE); + (resource_size_t)(unsigned long)hose-io_base_virt - _IO_BASE); We have to be careful here as we do want sign extension to happen (yeah it's odd, but it's the way we do IOs on ppc32 :-) Maybe I should change it one day). So we probably want to do: (resource_size_t)(long long)(hose-io_base_virt - _IO_BASE) Oops ... that was meant to read (long) not (long long)... Any ways, I more or less convinced myself that even without the sign extension it would still work, since the IO port number is eventually cast to an unsigned int by the accessors, so as long as the low 32-bits are correct (and they'll be with or without the sign extension), we should be fine. It's just that something trying to print the resource might end up displaying garbage in the top bits. Cheers, Ben. Basically, IO resources are relative to _IO_BASE which on ppc32 is basically the virtual address where we map the first PHB IO space. Subsequent PHB mappings can end up below _IO_BASE, leading to negative resource values for IO BARs on those busses. It all works fine because even an unsigned addition will do the right thing as long as the value is fully sign extended. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup_phb_resources':
arch/powerpc/kernel/pci-common.c:1520:4: error: cast from pointer to integer of
different size [-Werror=pointer-to-int-cast]
Caused by commit 6c5705fec63d (powerpc/PCI: get rid of device resource
fixups) from the pci tree. In this build, resource_size_t is 64 bits
while pointers are only 32.
I applied the following fix patch.
From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 27 Feb 2012 17:33:48 +1100
Subject: [PATCH] powerpc/PCI: fix up for mismatch between resource_size_t and
pointer size
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
arch/powerpc/kernel/pci-common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 910b9de..808ecbb 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1517,7 +1517,7 @@ static void __devinit pcibios_setup_phb_resources(struct
pci_controller *hose, s
(unsigned long long)res-end,
(unsigned long)res-flags);
pci_add_resource_offset(resources, res,
- (resource_size_t) hose-io_base_virt - _IO_BASE);
+ (resource_size_t)(unsigned long)hose-io_base_virt -
_IO_BASE);
/* Hookup PHB Memory resources */
for (i = 0; i 3; ++i) {
--
1.7.9.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpGgQ6UrjL0L.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (akpm tree related)
Hi Andrew, After merging the final tree, today's linux-next build (powerpc allnoconfig) failed like this: In file included from include/linux/posix_types.h:47:0, from include/linux/types.h:17, from include/linux/page-flags.h:8, from kernel/bounds.c:9: arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t' arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here In file included from include/linux/page-flags.h:8:0, from kernel/bounds.c:9: include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t' Caused by commit a9dbe86e5995 (powerpc: use generic posix_types.h). This think was pointed out a couple of days ago, so maybe Andrew needs a newer version of the patch. I added this fix patch for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 17 Feb 2012 16:25:48 +1100 Subject: [PATCH] powerpc: use generic posix_types.h fix Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/include/asm/posix_types.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h index 1fbe027f..f139325 100644 --- a/arch/powerpc/include/asm/posix_types.h +++ b/arch/powerpc/include/asm/posix_types.h @@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t; #define __kernel_old_dev_t __kernel_old_dev_t #else typedef unsigned int __kernel_size_t; -typedef int__kernel_size_t; +typedef int__kernel_ssize_t; typedef long __kernel_ptrdiff_t; #define __kernel_size_t __kernel_size_t -- 1.7.9 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpifisOXtyoA.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (akpm tree related)
On Fri, 2012-02-17 at 16:30 +1100, Stephen Rothwell wrote: Hi Andrew, After merging the final tree, today's linux-next build (powerpc allnoconfig) failed like this: In file included from include/linux/posix_types.h:47:0, from include/linux/types.h:17, from include/linux/page-flags.h:8, from kernel/bounds.c:9: arch/powerpc/include/asm/posix_types.h:15:14: error: conflicting types for '__kernel_size_t' arch/powerpc/include/asm/posix_types.h:14:22: note: previous declaration of '__kernel_size_t' was here In file included from include/linux/page-flags.h:8:0, from kernel/bounds.c:9: include/linux/types.h:68:1: error: unknown type name '__kernel_ssize_t' Caused by commit a9dbe86e5995 (powerpc: use generic posix_types.h). This think was pointed out a couple of days ago, so maybe Andrew needs a newer version of the patch. Yes, I pointed that out to Peter a while back, maybe it got lost ... Cheers, Ben. I added this fix patch for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 17 Feb 2012 16:25:48 +1100 Subject: [PATCH] powerpc: use generic posix_types.h fix Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/include/asm/posix_types.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/posix_types.h b/arch/powerpc/include/asm/posix_types.h index 1fbe027f..f139325 100644 --- a/arch/powerpc/include/asm/posix_types.h +++ b/arch/powerpc/include/asm/posix_types.h @@ -12,7 +12,7 @@ typedef unsigned long __kernel_old_dev_t; #define __kernel_old_dev_t __kernel_old_dev_t #else typedef unsigned int __kernel_size_t; -typedef int __kernel_size_t; +typedef int __kernel_ssize_t; typedef long __kernel_ptrdiff_t; #define __kernel_size_t __kernel_size_t -- 1.7.9 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree
On 01/20/2012 12:51 PM, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allmodconfig) failed like this: arch/powerpc/platforms/pseries/processor_idle.c:35:6: error: redefinition of 'update_smt_snooze_delay' arch/powerpc/include/asm/system.h:230:20: note: previous definition of 'update_smt_snooze_delay' was here arch/powerpc/platforms/pseries/processor_idle.c:175:5: error: redefinition of 'pseries_notify_cpuidle_add_cpu' arch/powerpc/include/asm/system.h:231:19: note: previous definition of 'pseries_notify_cpuidle_add_cpu' was here Caused by commit 707827f3387d (powerpc/cpuidle: cpuidle driver for pSeries). For this build, CONFIG_PSERIES_IDLE is m. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Hi Stephen, We had a discussion on this particular problem on ppcdev list a few days back and concluded that it is best not have pseries_idle as a module. http://old.nabble.com/-PATCH--cpuidle%3A-Default-y-for-pseries-to33118294.html#a33127587 The following patch disables pseries cpuidle driver to be loaded as a module as there are build problems reported when one is trying to do so. arch/powerpc/platforms/pseries/processor_idle.c:35:6: error: redefinition of 'update_smt_snooze_delay' arch/powerpc/include/asm/system.h:230:20: note: previous definition of 'update_smt_snooze_delay' was here arch/powerpc/platforms/pseries/processor_idle.c:175:5: error: redefinition of 'pseries_notify_cpuidle_add_cpu' arch/powerpc/include/asm/system.h:231:19: note: previous definition of 'pseries_notify_cpuidle_add_cpu' was here Since the above two functions are used in core power architecture functions (store_smt_snooze_delay at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c), this requires some rework in these interactions. For now please disable PSERIES_IDLE to be built as a module for now. Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com --- arch/powerpc/platforms/pseries/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index ae7b6d4..31f22c1 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -122,7 +122,7 @@ config DTL Say N if you are unsure. config PSERIES_IDLE - tristate Cpuidle driver for pSeries platforms + bool Cpuidle driver for pSeries platforms depends on CPU_IDLE depends on PPC_PSERIES default y Regards, Deepthi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allmodconfig) failed like this: arch/powerpc/platforms/pseries/processor_idle.c:35:6: error: redefinition of 'update_smt_snooze_delay' arch/powerpc/include/asm/system.h:230:20: note: previous definition of 'update_smt_snooze_delay' was here arch/powerpc/platforms/pseries/processor_idle.c:175:5: error: redefinition of 'pseries_notify_cpuidle_add_cpu' arch/powerpc/include/asm/system.h:231:19: note: previous definition of 'pseries_notify_cpuidle_add_cpu' was here Caused by commit 707827f3387d (powerpc/cpuidle: cpuidle driver for pSeries). For this build, CONFIG_PSERIES_IDLE is m. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSdVARpVrG1.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Wed, Dec 28, 2011 at 09:32:14PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote: Hi , After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: kernel/built-in.o: In function `irq_dispose_mapping': (.opd+0x159f0): multiple definition of `irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here kernel/built-in.o: In function `irq_create_of_mapping': (.opd+0x15a20): multiple definition of `irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here kernel/built-in.o: In function `.irq_create_of_mapping': (.text+0x147030): multiple definition of `.irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here kernel/built-in.o: In function `.irq_dispose_mapping': (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here I am not sure what caused this. And have just left it broken. Grant, is your irq remapper misbehaving ? H, that's odd. I've not touched it. I'll investigate. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Mon, Jan 2, 2012 at 1:25 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Wed, Dec 28, 2011 at 09:32:14PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote: Hi , After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: kernel/built-in.o: In function `irq_dispose_mapping': (.opd+0x159f0): multiple definition of `irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here kernel/built-in.o: In function `irq_create_of_mapping': (.opd+0x15a20): multiple definition of `irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here kernel/built-in.o: In function `.irq_create_of_mapping': (.text+0x147030): multiple definition of `.irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here kernel/built-in.o: In function `.irq_dispose_mapping': (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here I am not sure what caused this. And have just left it broken. Grant, is your irq remapper misbehaving ? H, that's odd. I've not touched it. I'll investigate. It looks like CONFIG_IRQ_DOMAIN is getting selected by TWL4030_CORE. Drivers must not select that config symbol. It looks like commit da28adbd (mfd: twl-core: Add initial DT support for twl4030/twl6030) is the culprit. The following patch should solve the problem: diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 13c468e..e43a570 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -200,8 +200,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support - depends on I2C=y GENERIC_HARDIRQS - select IRQ_DOMAIN + depends on I2C=y GENERIC_HARDIRQS IRQ_DOMAIN help Say yes here if you have TWL4030 / TWL6030 family chip on your board. This core driver provides register access and IRQ handling ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc related)
Hi , After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: kernel/built-in.o: In function `irq_dispose_mapping': (.opd+0x159f0): multiple definition of `irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here kernel/built-in.o: In function `irq_create_of_mapping': (.opd+0x15a20): multiple definition of `irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here kernel/built-in.o: In function `.irq_create_of_mapping': (.text+0x147030): multiple definition of `.irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here kernel/built-in.o: In function `.irq_dispose_mapping': (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here I am not sure what caused this. And have just left it broken. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpx9qRLyx9F5.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Wed, 2011-12-28 at 19:49 +1100, Stephen Rothwell wrote: Hi , After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: kernel/built-in.o: In function `irq_dispose_mapping': (.opd+0x159f0): multiple definition of `irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x960): first defined here kernel/built-in.o: In function `irq_create_of_mapping': (.opd+0x15a20): multiple definition of `irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.opd+0x9a8): first defined here kernel/built-in.o: In function `.irq_create_of_mapping': (.text+0x147030): multiple definition of `.irq_create_of_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9de0): first defined here kernel/built-in.o: In function `.irq_dispose_mapping': (.text+0x146f4c): multiple definition of `.irq_dispose_mapping' arch/powerpc/kernel/built-in.o:(.text+0x9684): first defined here I am not sure what caused this. And have just left it broken. Grant, is your irq remapper misbehaving ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (tty tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc': drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' undeclared (first use in this function) drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write': drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of different size drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init': drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of different size Caused by commit dcd83aaff1c8 (tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver). MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is included by arch/powerpc/include/asm/reg.h but only when defined (CONFIG_BOOKE) || defined(CONFIG_40x). I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpdHbwbwdanV.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
On Aug 25, 2011, at 9:08 AM, Greg KH g...@kroah.com wrote: On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote: Thanks for the report. Timur, care to send a fixup patch for this so this gets resolved? Yes, I will do it ASAP, probably within the next two hours. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc': drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' undeclared (first use in this function) drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write': drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of different size drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init': drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of different size Caused by commit dcd83aaff1c8 (tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver). MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is included by arch/powerpc/include/asm/reg.h but only when defined (CONFIG_BOOKE) || defined(CONFIG_40x). Thanks for the report. Timur, care to send a fixup patch for this so this gets resolved? greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Greg KH wrote: MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is included by arch/powerpc/include/asm/reg.h but only when defined (CONFIG_BOOKE) || defined(CONFIG_40x). Thanks for the report. Timur, care to send a fixup patch for this so this gets resolved? Is there some trick to building allyesconfig on PowerPC? When I do try that, I get all sorts of weird build errors, and it dies long before it gets to my driver. I get stuff like: LD arch/powerpc/sysdev/xics/built-in.o WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in reference from the function .icp_native_init() to the function .init.text:.icp_native_init_one_node() The function .icp_native_init() references the function __init .icp_native_init_one_node(). This is often because .icp_native_init lacks a __init annotation or the annotation of .icp_native_init_one_node is wrong. and AS arch/powerpc/kernel/head_64.o arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 I guess I don't have the right compiler. Anyway, I think I know how to fix the break that Stephen is seeing. I will post a v4 patch in a few minutes. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi Timur, On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi ti...@freescale.com wrote: Is there some trick to building allyesconfig on PowerPC? When I do try that, I get all sorts of weird build errors, and it dies long before it gets to my driver. I get stuff like: LD arch/powerpc/sysdev/xics/built-in.o WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in reference from the function .icp_native_init() to the function .init.text:.icp_native_init_one_node() The function .icp_native_init() references the function __init .icp_native_init_one_node(). This is often because .icp_native_init lacks a __init annotation or the annotation of .icp_native_init_one_node is wrong. We get lots of those in many builds. :-( Just a warning. and AS arch/powerpc/kernel/head_64.o arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards There is a patch for that pending with either the kvm guys or the powerpc guys. I guess I don't have the right compiler. Yours seems to be OK. If you pass -k to make it will get further. Or you could configure it and then just try building your driver rather than the whole tree. Anyway, I think I know how to fix the break that Stephen is seeing. I will post a v4 patch in a few minutes. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpVhblnqGQKI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi, On Thu, Aug 25, 2011 at 11:51 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Timur, On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi ti...@freescale.com wrote: Is there some trick to building allyesconfig on PowerPC? When I do try that, I get all sorts of weird build errors, and it dies long before it gets to my driver. I get stuff like: LD arch/powerpc/sysdev/xics/built-in.o WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in reference from the function .icp_native_init() to the function .init.text:.icp_native_init_one_node() The function .icp_native_init() references the function __init .icp_native_init_one_node(). This is often because .icp_native_init lacks a __init annotation or the annotation of .icp_native_init_one_node is wrong. We get lots of those in many builds. :-( Just a warning. If you could provide an exhaustive list of them, I'd be interested. Do you account/reference them in the report you make on each new -next tree ? - Arnaud and AS arch/powerpc/kernel/head_64.o arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards There is a patch for that pending with either the kvm guys or the powerpc guys. I guess I don't have the right compiler. Yours seems to be OK. If you pass -k to make it will get further. Or you could configure it and then just try building your driver rather than the whole tree. Anyway, I think I know how to fix the break that Stephen is seeing. I will post a v4 patch in a few minutes. Thanks. -- Cheers, Stephen Rothwell s...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi Arnaud, On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe lacom...@gmail.com wrote: If you could provide an exhaustive list of them, I'd be interested. Do you account/reference them in the report you make on each new -next tree ? I don't refer to them at all :-( If you are not just referring to powerpc ones, then an x86_64 allmodconfig is a good place to start, there are several in there. Otherwise, I will send you the results of some of my builds this evening. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpAyjjoNMIXF.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allysconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards This is probably powerpc or kvm tree related. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgphtgfu73Vmm.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/tty/hvc/hvsi.c:701:12: error: conflicting types for 'hvsi_put_chars' arch/powerpc/include/asm/hvsi.h:92:12: note: previous declaration of 'hvsi_put_chars' was here drivers/tty/hvc/hvsi.c:736:12: error: conflicting types for 'hvsi_open' arch/powerpc/include/asm/hvsi.h:86:12: note: previous declaration of 'hvsi_open' was here drivers/tty/hvc/hvsi.c:802:13: error: conflicting types for 'hvsi_close' arch/powerpc/include/asm/hvsi.h:87:13: note: previous declaration of 'hvsi_close' was here drivers/tty/hvc/hvsi.c:1083:19: error: conflicting types for 'hvsi_init' arch/powerpc/include/asm/hvsi.h:81:13: note: previous declaration of 'hvsi_init' was here Caused by commit 17bdc6c0e979 (powerpc/pseries: Move hvsi support into a library). I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpHeeqWh4eZ8.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Thu, 2011-06-30 at 16:36 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/tty/hvc/hvsi.c:701:12: error: conflicting types for 'hvsi_put_chars' arch/powerpc/include/asm/hvsi.h:92:12: note: previous declaration of 'hvsi_put_chars' was here drivers/tty/hvc/hvsi.c:736:12: error: conflicting types for 'hvsi_open' arch/powerpc/include/asm/hvsi.h:86:12: note: previous declaration of 'hvsi_open' was here drivers/tty/hvc/hvsi.c:802:13: error: conflicting types for 'hvsi_close' arch/powerpc/include/asm/hvsi.h:87:13: note: previous declaration of 'hvsi_close' was here drivers/tty/hvc/hvsi.c:1083:19: error: conflicting types for 'hvsi_init' arch/powerpc/include/asm/hvsi.h:81:13: note: previous declaration of 'hvsi_init' was here Caused by commit 17bdc6c0e979 (powerpc/pseries: Move hvsi support into a library). I have reverted that commit for today. Ooops, that seems to be entirely my fault, not sure what happened, I might have merged the wrong patch version (I had some problem locally with screwing up the git repo where those patches were originally). I'll push a fix tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (Linus' tree related)
On Fri, 17 Jun 2011 15:38:09 +1000
Stephen Rothwell s...@canb.auug.org.au wrote:
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
mm/page_cgroup.c: In function 'page_cgroup_init':
mm/page_cgroup.c:309:13: error: 'pg_data_t' has no member named 'node_end_pfn'
Caused by commit 37573e8c7182 (memcg: fix init_page_cgroup nid with
sparsemem). On powerpc, node_end_pfn() is defined to be (NODE_DATA
(nid)-node_end_pfn) where NODE_DATA(nid) is (node_data[nid]) and
node_data is struct pglist_data *node_data[]. As far as I can see,
struct pglist_data has never had a member called node_end_pfn.
This commit introduces the only use of node_end_pfn() in the generic
kernel code. Presumably the powerpc definition needs to be fixed (to
maybe something like the x86 version). It looks like the sparc version
is broken as well.
Sorry, here is a fix I posted today. but no ack yet.
==
From 507cc95c5ba2351bff16c5421255d1395a3b555b Mon Sep 17 00:00:00 2001
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Date: Thu, 16 Jun 2011 17:28:07 +0900
Subject: [PATCH] Fix node_start/end_pfn() definition for mm/page_cgroup.c
commit 21a3c96 uses node_start/end_pfn(nid) for detection start/end
of nodes. But, it's not defined in linux/mmzone.h but defined in
/arch/???/include/mmzone.h which is included only under
CONFIG_NEED_MULTIPLE_NODES=y.
Then, we see
mm/page_cgroup.c: In function 'page_cgroup_init':
mm/page_cgroup.c:308: error: implicit declaration of function 'node_start_pfn'
mm/page_cgroup.c:309: error: implicit declaration of function 'node_end_pfn'
So, fixiing page_cgroup.c is an idea...
But node_start_pfn()/node_end_pfn() is a very generic macro and
should be implemented in the same manner for all archs.
(m32r has different implementation...)
This patch removes definitions of node_start/end_pfn() in each archs
and defines a unified one in linux/mmzone.h. It's not under
CONFIG_NEED_MULTIPLE_NODES, now.
A result of macro expansion is here (mm/page_cgroup.c)
for !NUMA
start_pfn = ((contig_page_data)-node_start_pfn);
end_pfn = ({ pg_data_t *__pgdat = (contig_page_data);
__pgdat-node_start_pfn + __pgdat-node_spanned_pages;});
for NUMA (x86-64)
start_pfn = ((node_data[nid])-node_start_pfn);
end_pfn = ({ pg_data_t *__pgdat = (node_data[nid]); __pgdat-node_start_pfn +
__pgdat-node_spanned_pages;});
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Changelog:
- fixed to avoid using nid twice in node_end_pfn() macro.
---
arch/alpha/include/asm/mmzone.h |1 -
arch/m32r/include/asm/mmzone.h|8 +---
arch/parisc/include/asm/mmzone.h |7 ---
arch/powerpc/include/asm/mmzone.h |7 ---
arch/sh/include/asm/mmzone.h |4
arch/sparc/include/asm/mmzone.h |2 --
arch/tile/include/asm/mmzone.h| 11 ---
arch/x86/include/asm/mmzone_32.h | 11 ---
arch/x86/include/asm/mmzone_64.h |3 ---
include/linux/mmzone.h|7 +++
10 files changed, 8 insertions(+), 53 deletions(-)
diff --git a/arch/alpha/include/asm/mmzone.h b/arch/alpha/include/asm/mmzone.h
index 8af56ce..445dc42 100644
--- a/arch/alpha/include/asm/mmzone.h
+++ b/arch/alpha/include/asm/mmzone.h
@@ -56,7 +56,6 @@ PLAT_NODE_DATA_LOCALNR(unsigned long p, int n)
* Given a kernel address, find the home node of the underlying memory.
*/
#define kvaddr_to_nid(kaddr) pa_to_nid(__pa(kaddr))
-#define node_start_pfn(nid)(NODE_DATA(nid)-node_start_pfn)
/*
* Given a kaddr, LOCAL_BASE_ADDR finds the owning node of the memory
diff --git a/arch/m32r/include/asm/mmzone.h b/arch/m32r/include/asm/mmzone.h
index 9f3b5ac..115ced3 100644
--- a/arch/m32r/include/asm/mmzone.h
+++ b/arch/m32r/include/asm/mmzone.h
@@ -14,12 +14,6 @@ extern struct pglist_data *node_data[];
#define NODE_DATA(nid) (node_data[nid])
#define node_localnr(pfn, nid) ((pfn) - NODE_DATA(nid)-node_start_pfn)
-#define node_start_pfn(nid)(NODE_DATA(nid)-node_start_pfn)
-#define node_end_pfn(nid) \
-({ \
- pg_data_t *__pgdat = NODE_DATA(nid);\
- __pgdat-node_start_pfn + __pgdat-node_spanned_pages - 1; \
-})
#define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) PAGE_SHIFT))
/*
@@ -44,7 +38,7 @@ static __inline__ int pfn_to_nid(unsigned long pfn)
int node;
for (node = 0 ; node MAX_NUMNODES ; node++)
- if (pfn = node_start_pfn(node) pfn = node_end_pfn(node))
+ if (pfn = node_start_pfn(node) pfn node_end_pfn(node))
break;
return node;
diff --git a/arch/parisc/include/asm/mmzone.h b/arch/parisc/include/asm/mmzone.h
index 9608d2c..e67eb9c 100644
--- a/arch/parisc/include/asm/mmzone.h
+++ b/arch/parisc/include/asm/mmzone.h
@@ -14,13 +14,6 @@ extern struct
linux-next: build failure after merge of the final tree (Linus' tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: mm/page_cgroup.c: In function 'page_cgroup_init': mm/page_cgroup.c:309:13: error: 'pg_data_t' has no member named 'node_end_pfn' Caused by commit 37573e8c7182 (memcg: fix init_page_cgroup nid with sparsemem). On powerpc, node_end_pfn() is defined to be (NODE_DATA (nid)-node_end_pfn) where NODE_DATA(nid) is (node_data[nid]) and node_data is struct pglist_data *node_data[]. As far as I can see, struct pglist_data has never had a member called node_end_pfn. This commit introduces the only use of node_end_pfn() in the generic kernel code. Presumably the powerpc definition needs to be fixed (to maybe something like the x86 version). It looks like the sparc version is broken as well. I have left the powerpc allyesconfig build broken for today (as it is also broken by other changes). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpWMWvqCdiQy.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/mm/mmu_context_hash64.c: In function 'init_new_context':
arch/powerpc/mm/mmu_context_hash64.c:282: error: 'NO_CONTEXT' undeclared (first
use in this function)
Presumably caused by commit 851d2e2fe8db (powerpc: Add Initiate
Coprocessor Store Word (icswx) support) interacting with commit
5e8e7b404ac9 (powerpc/mm: Standardise on MMU_NO_CONTEXT).
I added the below patch for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
From: Stephen Rothwell s...@canb.auug.org.au
Date: Thu, 5 May 2011 13:32:02 +1000
Subject: [PATCH] powerpc: fix up mismerge in mmu_context_hash64.c
NO_CONTEXT was changed to MMU_NO_CONTEXT.
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
arch/powerpc/mm/mmu_context_hash64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_hash64.c
b/arch/powerpc/mm/mmu_context_hash64.c
index c517815..3bafc3d 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -279,7 +279,7 @@ int init_new_context(struct task_struct *tsk, struct
mm_struct *mm)
if (!mm-context.cop_lockp) {
__destroy_context(index);
subpage_prot_free(mm);
- mm-context.id = NO_CONTEXT;
+ mm-context.id = MMU_NO_CONTEXT;
return -ENOMEM;
}
spin_lock_init(mm-context.cop_lockp);
--
1.7.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (ubi tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp9TKmNgK5qc.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote: On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Hmm, strange, include linux/vmalloc.h should be enough to use __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll try to look better. Try adding asm/pgtable.h Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Hmm, strange, include linux/vmalloc.h should be enough to use __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll try to look better. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 21:15 +1100, Benjamin Herrenschmidt wrote: On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote: On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Hmm, strange, include linux/vmalloc.h should be enough to use __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll try to look better. Try adding asm/pgtable.h Thanks, that's what I was thinking about as well. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, Stephen Rothwell wrote: After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Fixed, sorry for the hassle and thank you! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler': drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip' drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip' Caused by commit 17b9f9e2653a (powerpc: Enable GENERIC_HARDIRQS_NO_DEPRECATED) enabling CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously fixing up the above driver. I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpqUko7EeJr9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (block tree related)
On Fri, Mar 11, 2011 at 08:12:38AM +0100, Jens Axboe wrote: On 2011-03-11 07:58, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/char/tpm/tpm_tis.c:96: warning: 'is_itpm' defined but not used drivers/block/drbd/drbd_bitmap.c: In function '__bm_change_bits_to': drivers/block/drbd/drbd_bitmap.c:1287: error: implicit declaration of function 'generic___test_and_set_le_bit' drivers/block/drbd/drbd_bitmap.c:1289: error: implicit declaration of function 'generic___test_and_clear_le_bit' drivers/block/drbd/drbd_bitmap.c: In function 'drbd_bm_test_bit': drivers/block/drbd/drbd_bitmap.c:1438: error: implicit declaration of function 'generic_test_le_bit' Caused by commit 4b0715f09655 (drbd: allow petabyte storage on 64bit arch). I have applied this patch for today (surely there is a better way): Thanks for not dropping it, I'll let the drbd guys send in a proper fix and get it committed. Should that be fixed by adding #include asm-generic/bitops/le.h to arch/powerpc/include/asm/bitops.h (and arch/s390/include/asm/bitops.h, possibly others?) Or are we expected to include that ourselves, directly? We probably need to select CONFIG_GENERIC_FIND_NEXT_BIT from our Kconfig as well? Lars ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Mon, 2011-03-14 at 20:38 +1100, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler': drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip' drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip' Caused by commit 17b9f9e2653a (powerpc: Enable GENERIC_HARDIRQS_NO_DEPRECATED) enabling CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously fixing up the above driver. I have reverted that commit for today. Except that the above driver has nothing to do with powerpc, it's some Intel Moorestown stuff... It should be fixed regardless I suppose, CC'ing Thomas. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Tue, 15 Mar 2011 07:37:54 +1100 On Mon, 2011-03-14 at 20:38 +1100, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler': drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip' drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip' Caused by commit 17b9f9e2653a (powerpc: Enable GENERIC_HARDIRQS_NO_DEPRECATED) enabling CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously fixing up the above driver. I have reverted that commit for today. Except that the above driver has nothing to do with powerpc, it's some Intel Moorestown stuff... It should be fixed regardless I suppose, CC'ing Thomas. I've had to make fixes to this driver in sparc64 allmodconfig builds too :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Mon, 14 Mar 2011, David Miller wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Tue, 15 Mar 2011 07:37:54 +1100 On Mon, 2011-03-14 at 20:38 +1100, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler': drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip' drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip' Caused by commit 17b9f9e2653a (powerpc: Enable GENERIC_HARDIRQS_NO_DEPRECATED) enabling CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously fixing up the above driver. I have reverted that commit for today. Except that the above driver has nothing to do with powerpc, it's some Intel Moorestown stuff... It should be fixed regardless I suppose, CC'ing Thomas. I've had to make fixes to this driver in sparc64 allmodconfig builds too :-) Sigh. Yes, this wants to depend on x86 in the first place. But this is the second instance of blindly and mindlessly changing eoi to irq_eoi w/o looking at the reason for this change. Those patches should have been rejected based on their changelog in the first place: Latest kernel has many changes in IRQ subsystem and its interfaces, like adding irq_eoi for struct irq_chip, this patch is a follow up change for that. When noone beats me to fix that mess, I'll do it tomorrow morning. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Tue, Mar 15, 2011 at 07:37:54AM +1100, Benjamin Herrenschmidt wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpio/langwell_gpio.c: In function 'lnw_irq_handler': drivers/gpio/langwell_gpio.c:210: error: 'struct irq_desc' has no member named 'chip' drivers/gpio/langwell_gpio.c:211: error: 'struct irq_desc' has no member named 'chip' Caused by commit 17b9f9e2653a (powerpc: Enable GENERIC_HARDIRQS_NO_DEPRECATED) enabling CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED for powerpc without previously fixing up the above driver. I have reverted that commit for today. Except that the above driver has nothing to do with powerpc, it's some Intel Moorestown stuff... I sent this this morning: http://marc.info/?l=linux-kernelm=130009963219374w=2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:989: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:999: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1008: Error: attempt to move .org backwards So something has added a bit of bloat in there. I have left this broken for now. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpWPMyeySZhp.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Fri, Dec 03, 2010 at 04:59:58PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2010-12-03 at 16:32 +1100, Stephen Rothwell wrote: After merging the tree, today's linux-next build (powerpc allmodconfig) failed like this: arch/powerpc/lib/hweight_64.S: Assembler messages: arch/powerpc/lib/hweight_64.S:52: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:77: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:106: Error: Unrecognized opcode: `popcntd' This is with: powerpc64-linux-gcc (GCC) 4.4.0 GNU assembler (GNU Binutils) 2.19.1 Caused by commit 64ff31287693c1f325cb9cb049569c1611438ef1 (powerpc: Add support for popcnt instructions). This toolchain is a bit ancient I suppose... Anton, do you reckon we SLES 11 SP1 still uses gcc 4.3. 4.4.0 is not ancient by any means. Neither is binutils 2.19.1. should use .long based macros for these for the time being or just require a newer binutils ? .long macros sound like the proper solution. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc tree related)
Hi all, After merging the tree, today's linux-next build (powerpc allmodconfig) failed like this: arch/powerpc/lib/hweight_64.S: Assembler messages: arch/powerpc/lib/hweight_64.S:52: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:77: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:106: Error: Unrecognized opcode: `popcntd' This is with: powerpc64-linux-gcc (GCC) 4.4.0 GNU assembler (GNU Binutils) 2.19.1 Caused by commit 64ff31287693c1f325cb9cb049569c1611438ef1 (powerpc: Add support for popcnt instructions). -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp8ykb4056qq.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Fri, 2010-12-03 at 16:32 +1100, Stephen Rothwell wrote: After merging the tree, today's linux-next build (powerpc allmodconfig) failed like this: arch/powerpc/lib/hweight_64.S: Assembler messages: arch/powerpc/lib/hweight_64.S:52: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:77: Error: Unrecognized opcode: `popcntw' arch/powerpc/lib/hweight_64.S:106: Error: Unrecognized opcode: `popcntd' This is with: powerpc64-linux-gcc (GCC) 4.4.0 GNU assembler (GNU Binutils) 2.19.1 Caused by commit 64ff31287693c1f325cb9cb049569c1611438ef1 (powerpc: Add support for popcnt instructions). This toolchain is a bit ancient I suppose... Anton, do you reckon we should use .long based macros for these for the time being or just require a newer binutils ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc tree related)
On Fri, 03 Dec 2010 16:59:58 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: This toolchain is a bit ancient I suppose... Anton, do you reckon we should use .long based macros for these for the time being or just require a newer binutils ? The currently documented minimum binutils is 2.12 ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpzngCYknfXy.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
Hi Ben, On Fri, 3 Sep 2010 13:24:10 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: After merging the final tree, today's linux-next build (powerpc64 allnoconfig) failed like this: arch/powerpc/kernel/built-in.o: In function `.sys_call_table': (.text+0x8d48): undefined reference to `.compat_sys_recv' Caused by commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 (powerpc: Wire up direct socket system calls). I have applied this patch for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 3 Sep 2010 13:19:04 +1000 Subject: [PATCH] powerpc: define a compat_sys_recv cond_syscall Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- kernel/sys_ni.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index bad369e..c782fe9 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -50,6 +50,7 @@ cond_syscall(compat_sys_sendmsg); cond_syscall(sys_recvmsg); cond_syscall(sys_recvmmsg); cond_syscall(compat_sys_recvmsg); +cond_syscall(compat_sys_recv); cond_syscall(compat_sys_recvfrom); cond_syscall(compat_sys_recvmmsg); cond_syscall(sys_socketcall); -- 1.7.1 Ping? -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp8yfN5UfJid.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc related)
Hi all, After merging the final tree, today's linux-next build (powerpc64 allnoconfig) failed like this: arch/powerpc/kernel/built-in.o: In function `.sys_call_table': (.text+0x8d48): undefined reference to `.compat_sys_recv' Caused by commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 (powerpc: Wire up direct socket system calls). I have applied this patch for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Fri, 3 Sep 2010 13:19:04 +1000 Subject: [PATCH] powerpc: define a compat_sys_recv cond_syscall Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- kernel/sys_ni.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c index bad369e..c782fe9 100644 --- a/kernel/sys_ni.c +++ b/kernel/sys_ni.c @@ -50,6 +50,7 @@ cond_syscall(compat_sys_sendmsg); cond_syscall(sys_recvmsg); cond_syscall(sys_recvmmsg); cond_syscall(compat_sys_recvmsg); +cond_syscall(compat_sys_recv); cond_syscall(compat_sys_recvfrom); cond_syscall(compat_sys_recvmmsg); cond_syscall(sys_socketcall); -- 1.7.1 -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Fri, 2010-07-16 at 17:19 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allmodconfig) failed like this: ERROR: of_i8042_kbd_irq [drivers/input/serio/i8042.ko] undefined! ERROR: of_i8042_aux_irq [drivers/input/serio/i8042.ko] undefined! Presumably missing EXPORT_SYMBOLs .. Thanks. I'll fix that up. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (powerpc related)
Hi all, After merging the final tree, today's linux-next build (powerpc allmodconfig) failed like this: ERROR: of_i8042_kbd_irq [drivers/input/serio/i8042.ko] undefined! ERROR: of_i8042_aux_irq [drivers/input/serio/i8042.ko] undefined! Presumably missing EXPORT_SYMBOLs .. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpjWziF2tmSw.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (linus' tree related)
On Fri, 2010-05-28 at 15:08 +1000, Stephen Rothwell wrote:
Hi Steven,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
arch/powerpc/platforms/pseries/hvCall_inst.c: In function 'hcall_inst_init':
arch/powerpc/platforms/pseries/hvCall_inst.c:143: warning: passing argument 1
of 'register_trace_hcall_entry' from incompatible pointer type
arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long
unsigned int, long unsigned int *)' but argument is of type 'void (*)(long
unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:143: error: too few arguments to
function 'register_trace_hcall_entry'
arch/powerpc/platforms/pseries/hvCall_inst.c:146: warning: passing argument 1
of 'register_trace_hcall_exit' from incompatible pointer type
arch/powerpc/include/asm/trace.h:122: note: expected 'void (*)(void *, long
unsigned int, long unsigned int, long unsigned int *)' but argument is of
type 'void (*)(long unsigned int, long unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:146: error: too few arguments to
function 'register_trace_hcall_exit'
arch/powerpc/platforms/pseries/hvCall_inst.c:147: warning: passing argument 1
of 'unregister_trace_hcall_entry' from incompatible pointer type
arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long
unsigned int, long unsigned int *)' but argument is of type 'void (*)(long
unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:147: error: too few arguments to
function 'unregister_trace_hcall_entry'
Probably caused by commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e
(tracing: Let tracepoints have data passed to tracepoint callbacks).
I applied this patch which builds (but may be incorrect).
Looks good to me.
Acked-by: Steven Rostedt rost...@goodmis.org
-- Steve
From: Stephen Rothwell s...@canb.auug.org.au
Date: Fri, 28 May 2010 15:05:00 +1000
Subject: [PATCH] tracing: fix for tracepoint API change
Commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e tracing: Let tracepoints
have data passed to tracepoint callbacks requires this fixup to the
powerpc code.
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
arch/powerpc/platforms/pseries/hvCall_inst.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c
b/arch/powerpc/platforms/pseries/hvCall_inst.c
index 1fefae7..e19ff02 100644
--- a/arch/powerpc/platforms/pseries/hvCall_inst.c
+++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
@@ -102,7 +102,7 @@ static const struct file_operations hcall_inst_seq_fops =
{
#define CPU_NAME_BUF_SIZE32
-static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
+static void probe_hcall_entry(void *ignored, unsigned long opcode, unsigned
long *args)
{
struct hcall_stats *h;
@@ -114,7 +114,7 @@ static void probe_hcall_entry(unsigned long opcode,
unsigned long *args)
h-purr_start = mfspr(SPRN_PURR);
}
-static void probe_hcall_exit(unsigned long opcode, unsigned long retval,
+static void probe_hcall_exit(void *ignored, unsigned long opcode, unsigned
long retval,
unsigned long *retbuf)
{
struct hcall_stats *h;
@@ -140,11 +140,11 @@ static int __init hcall_inst_init(void)
if (!firmware_has_feature(FW_FEATURE_LPAR))
return 0;
- if (register_trace_hcall_entry(probe_hcall_entry))
+ if (register_trace_hcall_entry(probe_hcall_entry, NULL))
return -EINVAL;
- if (register_trace_hcall_exit(probe_hcall_exit)) {
- unregister_trace_hcall_entry(probe_hcall_entry);
+ if (register_trace_hcall_exit(probe_hcall_exit, NULL)) {
+ unregister_trace_hcall_entry(probe_hcall_entry, NULL);
return -EINVAL;
}
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (linus' tree related)
Hi Steven,
After merging the final tree, today's linux-next build (powerpc allyesconfig)
failed like this:
arch/powerpc/platforms/pseries/hvCall_inst.c: In function 'hcall_inst_init':
arch/powerpc/platforms/pseries/hvCall_inst.c:143: warning: passing argument 1
of 'register_trace_hcall_entry' from incompatible pointer type
arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long
unsigned int, long unsigned int *)' but argument is of type 'void (*)(long
unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:143: error: too few arguments to
function 'register_trace_hcall_entry'
arch/powerpc/platforms/pseries/hvCall_inst.c:146: warning: passing argument 1
of 'register_trace_hcall_exit' from incompatible pointer type
arch/powerpc/include/asm/trace.h:122: note: expected 'void (*)(void *, long
unsigned int, long unsigned int, long unsigned int *)' but argument is of
type 'void (*)(long unsigned int, long unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:146: error: too few arguments to
function 'register_trace_hcall_exit'
arch/powerpc/platforms/pseries/hvCall_inst.c:147: warning: passing argument 1
of 'unregister_trace_hcall_entry' from incompatible pointer type
arch/powerpc/include/asm/trace.h:100: note: expected 'void (*)(void *, long
unsigned int, long unsigned int *)' but argument is of type 'void (*)(long
unsigned int, long unsigned int *)'
arch/powerpc/platforms/pseries/hvCall_inst.c:147: error: too few arguments to
function 'unregister_trace_hcall_entry'
Probably caused by commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e
(tracing: Let tracepoints have data passed to tracepoint callbacks).
I applied this patch which builds (but may be incorrect).
From: Stephen Rothwell s...@canb.auug.org.au
Date: Fri, 28 May 2010 15:05:00 +1000
Subject: [PATCH] tracing: fix for tracepoint API change
Commit 38516ab59fbc5b3bb278cf5e1fe2867c70cff32e tracing: Let tracepoints
have data passed to tracepoint callbacks requires this fixup to the
powerpc code.
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
arch/powerpc/platforms/pseries/hvCall_inst.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall_inst.c
b/arch/powerpc/platforms/pseries/hvCall_inst.c
index 1fefae7..e19ff02 100644
--- a/arch/powerpc/platforms/pseries/hvCall_inst.c
+++ b/arch/powerpc/platforms/pseries/hvCall_inst.c
@@ -102,7 +102,7 @@ static const struct file_operations hcall_inst_seq_fops = {
#define CPU_NAME_BUF_SIZE 32
-static void probe_hcall_entry(unsigned long opcode, unsigned long *args)
+static void probe_hcall_entry(void *ignored, unsigned long opcode, unsigned
long *args)
{
struct hcall_stats *h;
@@ -114,7 +114,7 @@ static void probe_hcall_entry(unsigned long opcode,
unsigned long *args)
h-purr_start = mfspr(SPRN_PURR);
}
-static void probe_hcall_exit(unsigned long opcode, unsigned long retval,
+static void probe_hcall_exit(void *ignored, unsigned long opcode, unsigned
long retval,
unsigned long *retbuf)
{
struct hcall_stats *h;
@@ -140,11 +140,11 @@ static int __init hcall_inst_init(void)
if (!firmware_has_feature(FW_FEATURE_LPAR))
return 0;
- if (register_trace_hcall_entry(probe_hcall_entry))
+ if (register_trace_hcall_entry(probe_hcall_entry, NULL))
return -EINVAL;
- if (register_trace_hcall_exit(probe_hcall_exit)) {
- unregister_trace_hcall_entry(probe_hcall_entry);
+ if (register_trace_hcall_exit(probe_hcall_exit, NULL)) {
+ unregister_trace_hcall_entry(probe_hcall_entry, NULL);
return -EINVAL;
}
--
1.7.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
