I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Thanks, Guenter
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
thanks,
greg k-h
On Thu, 9 May 2019 08:53:24 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
What exact code do you build?
In my source there the SLB relon handler starts just above this line and a lot of out-ouf-line are handlers before. Moving some out-of-line handlers below the parts with fixed location should fix the build error.
Thanks
Michal
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
What exact code do you build?
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig $ powerpc64-linux-gcc --version powerpc64-linux-gcc (GCC) 8.3.0
Guenter
On Thu, 9 May 2019 06:07:31 -0700 Guenter Roeck linux@roeck-us.net wrote:
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
What exact code do you build?
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig $ powerpc64-linux-gcc --version powerpc64-linux-gcc (GCC) 8.3.0
Gcc should not see this file. I am asking because I do not see an .org directive at line 839 of 4.4.179. I probably need some different repo or extra patches to see the same code as you do.
Thanks
Michal
On 5/9/19 6:26 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 06:07:31 -0700 Guenter Roeck linux@roeck-us.net wrote:
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
What exact code do you build?
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig $ powerpc64-linux-gcc --version powerpc64-linux-gcc (GCC) 8.3.0
Gcc should not see this file. I am asking because I do not see an .org directive at line 839 of 4.4.179. I probably need some different repo or extra patches to see the same code as you do.
v4.4.179-143-gc4db218e9451 from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git branch linux-4.4.y
That also includes 'powerpc/64s: Improve RFI L1-D cache flush fallback', but reverting it does not make a difference. Also, the .org is hidden in STD_RELON_EXCEPTION_PSERIES().
Guenter
On Thu, 9 May 2019 07:06:32 -0700 Guenter Roeck linux@roeck-us.net wrote:
On 5/9/19 6:26 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 06:07:31 -0700 Guenter Roeck linux@roeck-us.net wrote:
On 5/9/19 2:49 AM, Michal Suchánek wrote:
On Thu, 9 May 2019 08:53:24 +0200 Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Any ideas on what to do here?
What exact code do you build?
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig $ powerpc64-linux-gcc --version powerpc64-linux-gcc (GCC) 8.3.0
Gcc should not see this file. I am asking because I do not see an .org directive at line 839 of 4.4.179. I probably need some different repo or extra patches to see the same code as you do.
v4.4.179-143-gc4db218e9451 from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git branch linux-4.4.y
Still don't see it. That branch is at 4.4.179 and c4db218e9451 does not exist after fetching from the repo.
Anyway, here is a patch (untested):
Subject: [PATCH] Move out-of-line exception handlers after relon exception handlers.
The relon exception handlers need to be at specific location and code inflation in the common handler code can cause
Error: attempt to move .org backwards
Signed-off-by: Michal Suchanek msuchanek@suse.de --- arch/powerpc/kernel/exceptions-64s.S | 88 ++++++++++++++-------------- 1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 938a30fef031..1d477d21ff09 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -772,50 +772,6 @@ kvmppc_skip_Hinterrupt: b . #endif
-/* - * Code from here down to __end_handlers is invoked from the - * exception prologs above. Because the prologs assemble the - * addresses of these handlers using the LOAD_HANDLER macro, - * which uses an ori instruction, these handlers must be in - * the first 64k of the kernel image. - */ - -/*** Common interrupt handlers ***/ - - STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception) - - STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ) - STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt) - STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt) -#ifdef CONFIG_PPC_DOORBELL - STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception) -#else - STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception) -#endif - STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception) - STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception) - STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception) - STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt) - STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception) -#ifdef CONFIG_PPC_DOORBELL - STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception) -#else - STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception) -#endif - STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception) - STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception) - STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception) -#ifdef CONFIG_ALTIVEC - STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception) -#else - STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception) -#endif -#ifdef CONFIG_CBE_RAS - STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception) - STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception) - STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception) -#endif /* CONFIG_CBE_RAS */ - /* * Relocation-on interrupts: A subset of the interrupts can be delivered * with IR=1/DR=1, if AIL==2 and MSR.HV won't be changed by delivering @@ -969,6 +925,50 @@ system_call_entry: ppc64_runlatch_on_trampoline: b __ppc64_runlatch_on
+/* + * Code from here down to __end_handlers is invoked from the + * exception prologs above. Because the prologs assemble the + * addresses of these handlers using the LOAD_HANDLER macro, + * which uses an ori instruction, these handlers must be in + * the first 64k of the kernel image. + */ + +/*** Common interrupt handlers ***/ + + STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception) + + STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ) + STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt) + STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt) +#ifdef CONFIG_PPC_DOORBELL + STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception) +#else + STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception) +#endif + STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception) + STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception) + STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception) + STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt) + STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception) +#ifdef CONFIG_PPC_DOORBELL + STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception) +#else + STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception) +#endif + STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception) + STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception) + STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception) +#ifdef CONFIG_ALTIVEC + STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception) +#else + STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception) +#endif +#ifdef CONFIG_CBE_RAS + STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception) + STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception) + STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception) +#endif /* CONFIG_CBE_RAS */ + /* * Here r13 points to the paca, r9 contains the saved CR, * SRR0 and SRR1 are saved in r11 and r12,
Greg Kroah-Hartman gregkh@linuxfoundation.org writes:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Well it fixes some, but creates others :}
Any ideas on what to do here?
Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is sufficient to get it building. Is that an option for your build tests Guenter?
We can try to rearrange some of the exception vectors as Michal suggested, but that's not without risk either.
cheers
On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
Greg Kroah-Hartman gregkh@linuxfoundation.org writes:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Well it fixes some, but creates others :}
Any ideas on what to do here?
Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is sufficient to get it building. Is that an option for your build tests Guenter?
I could turn it off unconditionally, meaning it would affect all other branches. I would rather stop building ppc:allmodconfig for v4.4.y.
Guenter
Guenter Roeck linux@roeck-us.net writes:
On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
Greg Kroah-Hartman gregkh@linuxfoundation.org writes:
On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error: attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit"), which is part of a large patch series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Michael, I thought this patch series was supposed to fix ppc issues, not add to them :)
Well it fixes some, but creates others :}
Any ideas on what to do here?
Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is sufficient to get it building. Is that an option for your build tests Guenter?
I could turn it off unconditionally, meaning it would affect all other branches. I would rather stop building ppc:allmodconfig for v4.4.y.
Yeah fine by me. No one actually runs allmodconfig anyway.
cheers
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck -
Michael Ellerman -
Michal Suchánek