Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
On 05/11/2014 03:55 AM, Benjamin Herrenschmidt wrote:
On Sat, 2014-05-10 at 21:06 +0530, Preeti U Murthy wrote:
On 05/10/2014 09:56 AM, Benjamin Herrenschmidt wrote:
On Fri, 2014-05-09 at 15:22 +0530, Preeti U Murthy wrote:
in __timer_interrupt() outside the _else_ loop? This will ensure that no
matter what, before exiting timer interrupt handler we check for pending
irq work.
We still need to make sure that set_next_event() doesn't move the
dec beyond the next tick if there is a pending timer... maybe we
Sorry, but didn't get this. s/if there is pending timer/if there is
pending irq work ?
Yes, sorry :-) That's what I meant.
can fix it like this:
We can call set_next_event() from events like hrtimer_cancel() or
hrtimer_forward() as well. In that case we don't come to
decrementer_set_next_event() from __timer_interrupt(). Then, if we race
with irq work, we *do not do* a set_dec(1) ( I am referring to the patch
below ), we might never set the decrementer to fire immediately right?
Or does this scenario never arise?
So my proposed patch handles that no ?
With that patch, we do the set_dec(1) in two cases:
- The existing arch_irq_work_raise() which is unchanged
- At the end of __timer_interrupt() if an irq work is still pending
And the patch also makes decrementer_set_next_event() not modify the
decrementer if an irq work is pending, but *still* adjust next_tb unlike
what the code does now.
Thus the timer interrupt, when it happens, will re-adjust the dec
properly using next_tb.
Do we still miss a case ?
I was thinking something like the below in decrementer_set_next_event().
See last line in particular :
- /* Don't adjust the decrementer if some irq work is pending */
- if (test_irq_work_pending())
- return 0;
__get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
- set_dec(evt);
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
- set_dec(1);
+ /* Don't adjust the decrementer if some irq work is pending */
+ if (!test_irq_work_pending())
+ set_dec(evt);
+ else
+ set_dec(1);
^ your patch currently does not have this explicit
set_dec(1) here. Will that create a problem? If there is any irq work
pending at this point, will someone set the decrementer to fire
immediately after this point? The current code in
decrementer_set_next_event() sets set_dec(1) explicitly in case of
pending irq work.
Regards
Preeti U Murthy
Cheers,
Ben.
Regards
Preeti U Murthy
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
__get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
/* Don't adjust the decrementer if some irq work is pending */
if (!test_irq_work_pending())
set_dec(evt);
return 0;
}
Along with a single occurrence of:
if (test_irq_work_pending())
set_dec(1);
At the end of __timer_interrupt(), outside if the current else {}
case, this should work, don't you think ?
What about this completely untested patch ?
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 122a580..ba7e83b 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -503,12 +503,13 @@ void __timer_interrupt(void)
now = *next_tb - now;
if (now = DECREMENTER_MAX)
set_dec((int)now);
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
- set_dec(1);
__get_cpu_var(irq_stat).timer_irqs_others++;
}
+ /* We may have raced with new irq work */
+ if (test_irq_work_pending())
+ set_dec(1);
+
#ifdef CONFIG_PPC64
/* collect purr register values often, for accurate calculations */
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
@@ -813,15 +814,11 @@ static void __init clocksource_init(void)
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
- /* Don't adjust the decrementer if some irq work is pending */
- if (test_irq_work_pending())
- return 0;
__get_cpu_var(decrementers_next_tb) = get_tb_or_rtc() + evt;
- set_dec(evt);
- /* We may have raced with new irq work */
- if (test_irq_work_pending())
- set_dec(1);
+ /* Don't adjust the decrementer if some irq work is pending */
+ if (!test_irq_work_pending())
+ set_dec(evt);
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
On Sun, 2014-05-11 at 13:45 +0530, Preeti U Murthy wrote: + /* Don't adjust the decrementer if some irq work is pending */ + if (!test_irq_work_pending()) + set_dec(evt); + else + set_dec(1); ^ your patch currently does not have this explicit set_dec(1) here. Will that create a problem? If there is any irq work pending at this point, will someone set the decrementer to fire immediately after this point? The current code in decrementer_set_next_event() sets set_dec(1) explicitly in case of pending irq work. Hrm, actually this is an interesting point. The problem isn't that *someone* will do a set_dec, nobody else should that matters. The problem is that irq_work can be triggered typically by NMIs or similar, which means that it might be queued between the test_irq_work_pending() and the set_dec(), thus causing a race. So basically Anton's original patch is fine :-) I had missed that we did a post-set_dec() test already in decrementer_next_event() so as far as I can tell, removing the pre-test, which is what Anton does, is really all we need. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
On 05/11/2014 02:07 PM, Benjamin Herrenschmidt wrote: On Sun, 2014-05-11 at 13:45 +0530, Preeti U Murthy wrote: + /* Don't adjust the decrementer if some irq work is pending */ + if (!test_irq_work_pending()) + set_dec(evt); + else + set_dec(1); ^ your patch currently does not have this explicit set_dec(1) here. Will that create a problem? If there is any irq work pending at this point, will someone set the decrementer to fire immediately after this point? The current code in decrementer_set_next_event() sets set_dec(1) explicitly in case of pending irq work. Hrm, actually this is an interesting point. The problem isn't that *someone* will do a set_dec, nobody else should that matters. The problem is that irq_work can be triggered typically by NMIs or similar, which means that it might be queued between the test_irq_work_pending() and the set_dec(), thus causing a race. So basically Anton's original patch is fine :-) I had missed that we did a post-set_dec() test already in decrementer_next_event() so as far as I can tell, removing the pre-test, which is what Anton does, is really all we need. Isn't this patch required too? @@ -503,12 +503,13 @@ void __timer_interrupt(void) now = *next_tb - now; if (now = DECREMENTER_MAX) set_dec((int)now); - /* We may have raced with new irq work */ - if (test_irq_work_pending()) - set_dec(1); __get_cpu_var(irq_stat).timer_irqs_others++; } + /* We may have raced with new irq work */ + if (test_irq_work_pending()) + set_dec(1); + The event_handler cannot be relied upon to call decrementer_set_next_event() all the time. This is in the case where there are no pending timers. In that case we need to have the check on irq work pending at the end of __timer_interrupt() no? Regards Preeti U Murthy Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
On Sun, 2014-05-11 at 14:13 +0530, Preeti U Murthy wrote: Isn't this patch required too? @@ -503,12 +503,13 @@ void __timer_interrupt(void) now = *next_tb - now; if (now = DECREMENTER_MAX) set_dec((int)now); - /* We may have raced with new irq work */ - if (test_irq_work_pending()) - set_dec(1); __get_cpu_var(irq_stat).timer_irqs_others++; } + /* We may have raced with new irq work */ + if (test_irq_work_pending()) + set_dec(1); + The event_handler cannot be relied upon to call decrementer_set_next_event() all the time. This is in the case where there are no pending timers. In that case we need to have the check on irq work pending at the end of __timer_interrupt() no? I don't think we need to move the test no. If there's a pending irq_work, at that point, it will have done set_dec when being queued up. So we only care about cases where we might change the decrementer. If the event handler doesn't call decrementer_set_next_event() then nothing will modify the decrementer and it will still trigger soon. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
On 05/11/2014 02:33 PM, Benjamin Herrenschmidt wrote: On Sun, 2014-05-11 at 14:13 +0530, Preeti U Murthy wrote: Isn't this patch required too? @@ -503,12 +503,13 @@ void __timer_interrupt(void) now = *next_tb - now; if (now = DECREMENTER_MAX) set_dec((int)now); - /* We may have raced with new irq work */ - if (test_irq_work_pending()) - set_dec(1); __get_cpu_var(irq_stat).timer_irqs_others++; } + /* We may have raced with new irq work */ + if (test_irq_work_pending()) + set_dec(1); + The event_handler cannot be relied upon to call decrementer_set_next_event() all the time. This is in the case where there are no pending timers. In that case we need to have the check on irq work pending at the end of __timer_interrupt() no? I don't think we need to move the test no. If there's a pending irq_work, at that point, it will have done set_dec when being queued up. So we only care about cases where we might change the decrementer. If the event handler doesn't call decrementer_set_next_event() then nothing will modify the decrementer and it will still trigger soon. Hmm ok. Then Anton's patch covers all cases :) Thanks! Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com Regards Preeti U Murthy Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
Am Sun, May 11, 2014 at 01:13:47PM +0530 schrieb Anish Khurana: SET_ETHTOOL_OPS is equivalent to : #define SET_ETHTOOL_OPS(netdev,ops) \ ( (netdev)-ethtool_ops = (ops) ) how it makes difference removing this code and replacing with the code mentioned ? It doesn't change anything in the resulting binaries. The whole point is to remove the macro, which is something Dave wants to happen. Kind regards, Wilfried ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: add scottwood/linux.git
Hi Scott, On Fri, 9 May 2014 16:15:33 -0500 Scott Wood scottw...@freescale.com wrote: On Mon, 2014-03-24 at 20:09 -0500, Scott Wood wrote: On Mon, 2014-03-24 at 10:33 +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-03-24 at 10:16 +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote: The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac: powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14: fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500) Stephen just informed me that your tree wasn't in -next ... Kumar's still is. Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer in -next on its own. Stephen, what's the process for adding a tree? ping Sorry, for the delay. Just send me a git URL for your tree, and a list of the people I should contact in case of conflicts/build/fetch problems and cc the appropriate people/lists. I also assume that this will actually replace Kumar's tree? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: add scottwood/linux.git
Hi Scott, On Mon, 12 May 2014 08:23:36 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: On Fri, 9 May 2014 16:15:33 -0500 Scott Wood scottw...@freescale.com wrote: On Mon, 2014-03-24 at 20:09 -0500, Scott Wood wrote: On Mon, 2014-03-24 at 10:33 +1100, Benjamin Herrenschmidt wrote: On Mon, 2014-03-24 at 10:16 +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-03-19 at 23:25 -0500, Scott Wood wrote: The following changes since commit c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac: powerpc/powernv Platform dump interface (2014-03-07 16:19:10 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to 48b16180d0d91324e5d2423c6d53d97bbe3dcc14: fsl/pci: The new pci suspend/resume implementation (2014-03-19 22:37:44 -0500) Stephen just informed me that your tree wasn't in -next ... Kumar's still is. Can you guys fix that up ? I somewhat rely on the FSL stuff to simmer in -next on its own. Stephen, what's the process for adding a tree? ping Sorry, for the delay. Just send me a git URL for your tree, and a list of the people I should contact in case of conflicts/build/fetch problems and cc the appropriate people/lists. I also assume that this will actually replace Kumar's tree? [Preempting your reply :-)] I have added the above tree from today (and called it fsl) with you as the sole contact. Let me know if you need anything different. I have also removed the galak tree. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix skipping call to early_init_fdt_scan_reserved_mem
On Wed, 2014-04-30 at 01:03 -0500, Rob Herring wrote: From: Rob Herring r...@kernel.org The call to early_init_fdt_scan_reserved_mem will be skipped if reserved-ranges is not found. Move the call earlier so that it is called unconditionally. Signed-off-by: Rob Herring r...@kernel.org Cc: Marek Szyprowski m.szyprow...@samsung.com Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: linuxppc-dev@lists.ozlabs.org Tested-by: Stephen Chivers schiv...@csc.com --- I found this issue in testing of my fdt clean-up series (thanks to Stephen). Since the reserved memory support is new, I don't think it is critical to fix this for 3.15. I plan to include this with my fdt series for 3.16 unless I hear otherwise. Sure, go for it. Cheers, Ben. Rob arch/powerpc/kernel/prom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index 668aa47..d657549 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -567,6 +567,8 @@ static void __init early_reserve_mem_dt(void) unsigned long i, len, dt_root; const __be32 *prop; + early_init_fdt_scan_reserved_mem(); + dt_root = of_get_flat_dt_root(); prop = of_get_flat_dt_prop(dt_root, reserved-ranges, len); @@ -589,8 +591,6 @@ static void __init early_reserve_mem_dt(void) memblock_reserve(base, size); } } - - early_init_fdt_scan_reserved_mem(); } static void __init early_reserve_mem(void) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: reduce multi-hit of pcibios_setup_device() in hotplug
On Thu, 2014-05-08 at 14:30 +0800, Wei Yang wrote: During the EEH hotplug event, pcibios_setup_device() will be invoked two times. And the last time will trigger a warning of re-attachment of iommu group. The two times are: pci_device_add ... pcibios_add_device pcibios_setup_device - 1st time pcibios_add_pci_devices ... pcibios_setup_bus_devices pcibios_setup_device - 2rd time As we see, in pcibios_add_pci_devices() the pci_bus passed in as a parameter is initialized and already added in the system. Which means the pcibios_setup_device() in pcibios_add_device() will be called. Then the pcibios_setup_device() in pcibios_setup_bus_devices() is the 2nd time to be called on the same pci_dev. (CC'ing Bjorn to make sure I get the mess right :-) So the patch makes me a bit nervous because we have convoluted dependencies on some of that in the actual PCI hotplug code (the real thing which rescans busses etc...). I *think* the patch might be right (though incomplete) on those grounds, but I'd like you to verify and test the various hotplug cases in pHyp and I think issue comes from pcibios_add_device() being somewhat a late addition. Basically, what happens I think is at boot time: - bus-is_added is false, dev-is_added is false during initial probe of a given device. So pcibios_add_device() does nothing. - shortly afterward, the core calls pcibios_fixup_bus(), still with bus-is_added set to false, which *will* do the setup because dev-is_added is also false for all devices. - we set bus-is_added - we call pci_bus_add_devices() which sets all the dev-is_added So far so good. Now, when we hotplug something (and there are some distinction here depending on what hotplug path we take which is why I'd like you to scrutinize things a bit more), we mostly hit powerpc's pcibios_add_pci_devices(). Now this function will operate differently on a devtree style probe (phyp/kvm guest) vs. a normal probe (other bare metal machines). The normal case is what you are trying to fix here. It does an explicit pcibios_setup_bus_devices() on the bus being rescanned. I think you are right this isn't necessary. This bus has bus-is_added set to true and thus pcibios_add_device() will do the setup for any new devices. That makes me think that we need a similar fix in pci_of_scan.c for when we call of_rescan_bus(). The fix would be probably in __of_scan_bus(), to move the call to pcibios_setup_bus_devices() inside the if (!rescan_existing) statement, since if we are scanning an existing bus (which thus has bus-is_added set), we know pcibios_add_devices() will have done the updates. In fact I wonder if we could just use bus-is_added for the test in there and get rid of the rescan_existing argument completely. Worth adding something like WARN_ON(rescan_existing != bus-is_added); and do a few tests of hotplug to see what it looks like. Now there are two different hotplug path at least in the pseries code, so have a look make sure we aren't missing anything here and please test all cases ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix attempt to move .org backwards error (again)
On Fri, 2014-05-09 at 17:07 -0700, Guenter Roeck wrote: Commit 4e243b7 (powerpc: Fix attempt to move .org backwards error) fixes the allyesconfig build by moving machine_check_common to a different location. While this fixes most of the errors, both allmodconfig and allyesconfig still fail as follows. arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards Fix by moving machine_check_common after the offending address. This suffers from the same problem as previous attempts, on some of my test configs I get: arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0xb0): relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 IE, it breaks currently working configs. So we need to move more things around and I haven't had a chance to sort it out. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix attempt to move .org backwards error (again)
On 05/11/2014 09:12 PM, Benjamin Herrenschmidt wrote: On Fri, 2014-05-09 at 17:07 -0700, Guenter Roeck wrote: Commit 4e243b7 (powerpc: Fix attempt to move .org backwards error) fixes the allyesconfig build by moving machine_check_common to a different location. While this fixes most of the errors, both allmodconfig and allyesconfig still fail as follows. arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards Fix by moving machine_check_common after the offending address. This suffers from the same problem as previous attempts, on some of my test configs I get: arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0xb0): relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 IE, it breaks currently working configs. Oh well, it was worth a try. Can you give me an example for a failing configuration ? Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix attempt to move .org backwards error (again)
On Mon, 2014-05-12 at 14:12 +1000, Benjamin Herrenschmidt wrote: On Fri, 2014-05-09 at 17:07 -0700, Guenter Roeck wrote: Commit 4e243b7 (powerpc: Fix attempt to move .org backwards error) fixes the allyesconfig build by moving machine_check_common to a different location. While this fixes most of the errors, both allmodconfig and allyesconfig still fail as follows. arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards Fix by moving machine_check_common after the offending address. This suffers from the same problem as previous attempts, on some of my test configs I get: arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0xb0): relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 IE, it breaks currently working configs. So we need to move more things around and I haven't had a chance to sort it out. Ok, I think I sorted it out for now. It's a mess and likely to break again until we do something more drastic like moving everything that's after 0x8000 to a separate file but for now that will do. Patch on its way, I'll also shoot it to Linus today along with a few other things. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix attempt to move .org backwards error (again)
On 05/11/2014 10:37 PM, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 14:12 +1000, Benjamin Herrenschmidt wrote: On Fri, 2014-05-09 at 17:07 -0700, Guenter Roeck wrote: Commit 4e243b7 (powerpc: Fix attempt to move .org backwards error) fixes the allyesconfig build by moving machine_check_common to a different location. While this fixes most of the errors, both allmodconfig and allyesconfig still fail as follows. arch/powerpc/kernel/exceptions-64s.S:1315: Error: attempt to move .org backwards Fix by moving machine_check_common after the offending address. This suffers from the same problem as previous attempts, on some of my test configs I get: arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0xb0): relocation truncated to fit: R_PPC64_REL14 against `.text'+1c90 make[1]: *** [vmlinux] Error 1 make: *** [sub-make] Error 2 IE, it breaks currently working configs. So we need to move more things around and I haven't had a chance to sort it out. Ok, I think I sorted it out for now. It's a mess and likely to break again until we do something more drastic like moving everything that's after 0x8000 to a separate file but for now that will do. Patch on its way, I'll also shoot it to Linus today along with a few other things. Great, thanks a lot! Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix attempt to move .org backwards error (again)
On Sun, 2014-05-11 at 21:52 -0700, Guenter Roeck wrote: Oh well, it was worth a try. Can you give me an example for a failing configuration ? My g5 config which is close to g5_defconfig with PR KVM enabled. In any case, see my other messages. I'm waiting for all my test builders to come back and if it's clear I'll post a new patch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ppc64: Allow allmodconfig to build (finally !)
This shuffles code around in exceptions-64s.S in order to allow an allmodconfig build to succeed. The main problems were: - We have a fixed hole from 0x7000 to 0x8000 for use by FW, under some circumstances the code before that would grow too big and hit the . = 0x7000 - The various attempts at making space in there would trigger cases where short conditional branches from assembly would no longer be able to reach their target. This is especially nasty when these branches reside in alternate feature sections which are appended at the end of each .o file This fixes it by essentially moving all the second level exception handlers to after the hole and moving a couple of functions near the hole itself so they sit at reachable distance of both the first level handlers (before the hole) and the alternate feature sections (end of file). In the long run, if we start hitting this again, we'll probably have to split the file in two, probably at the hole location, to keep the alt sections used by the first level handlers close to them, and move everything else further away. But for now, this will do. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 3afd391..833a68d 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -533,70 +533,6 @@ do_stab_bolted_pSeries: KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x900) KVM_HANDLER(PACA_EXGEN, EXC_HV, 0x982) -#ifdef CONFIG_PPC_DENORMALISATION -denorm_assist: -BEGIN_FTR_SECTION -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER6 do that here for all FP regs. - */ - mfmsr r10 - ori r10,r10,(MSR_FP|MSR_FE0|MSR_FE1) - xorir10,r10,(MSR_FE0|MSR_FE1) - mtmsrd r10 - sync - -#define FMR2(n) fmr (n), (n) ; fmr n+1, n+1 -#define FMR4(n) FMR2(n) ; FMR2(n+2) -#define FMR8(n) FMR4(n) ; FMR4(n+4) -#define FMR16(n) FMR8(n) ; FMR8(n+8) -#define FMR32(n) FMR16(n) ; FMR16(n+16) - FMR32(0) - -FTR_SECTION_ELSE -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER7 do that here for the first 32 VSX registers only. - */ - mfmsr r10 - orisr10,r10,MSR_VSX@h - mtmsrd r10 - sync - -#define XVCPSGNDP2(n) XVCPSGNDP(n,n,n) ; XVCPSGNDP(n+1,n+1,n+1) -#define XVCPSGNDP4(n) XVCPSGNDP2(n) ; XVCPSGNDP2(n+2) -#define XVCPSGNDP8(n) XVCPSGNDP4(n) ; XVCPSGNDP4(n+4) -#define XVCPSGNDP16(n) XVCPSGNDP8(n) ; XVCPSGNDP8(n+8) -#define XVCPSGNDP32(n) XVCPSGNDP16(n) ; XVCPSGNDP16(n+16) - XVCPSGNDP32(0) - -ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206) - -BEGIN_FTR_SECTION - b denorm_done -END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S) -/* - * To denormalise we need to move a copy of the register to itself. - * For POWER8 we need to do that for all 64 VSX registers - */ - XVCPSGNDP32(32) -denorm_done: - mtspr SPRN_HSRR0,r11 - mtcrf 0x80,r9 - ld r9,PACA_EXGEN+EX_R9(r13) - RESTORE_PPR_PACA(PACA_EXGEN, r10) -BEGIN_FTR_SECTION - ld r10,PACA_EXGEN+EX_CFAR(r13) - mtspr SPRN_CFAR,r10 -END_FTR_SECTION_IFSET(CPU_FTR_CFAR) - ld r10,PACA_EXGEN+EX_R10(r13) - ld r11,PACA_EXGEN+EX_R11(r13) - ld r12,PACA_EXGEN+EX_R12(r13) - ld r13,PACA_EXGEN+EX_R13(r13) - HRFID - b . -#endif - .align 7 /* moved from 0xe00 */ STD_EXCEPTION_HV_OOL(0xe02, h_data_storage) @@ -623,43 +559,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR) KVM_HANDLER(PACA_EXGEN, EXC_HV, 0xf82) /* - * An interrupt came in while soft-disabled. We set paca-irq_happened, then: - * - If it was a decrementer interrupt, we bump the dec to max and and return. - * - If it was a doorbell we return immediately since doorbells are edge - * triggered and won't automatically refire. - * - else we hard disable and return. - * This is called with r10 containing the value to OR to the paca field. - */ -#define MASKED_INTERRUPT(_H) \ -masked_##_H##interrupt:\ - std r11,PACA_EXGEN+EX_R11(r13); \ - lbz r11,PACAIRQHAPPENED(r13); \ - or r11,r11,r10;\ - stb r11,PACAIRQHAPPENED(r13); \ - cmpwi r10,PACA_IRQ_DEC; \ - bne 1f; \ - lis r10,0x7fff; \ - ori r10,r10,0x; \ - mtspr SPRN_DEC,r10; \ - b 2f; \ -1: cmpwi r10,PACA_IRQ_DBELL; \ - beq 2f; \ - mfspr r10,SPRN_##_H##SRR1;\ - rldicl r10,r10,48,1; /* clear MSR_EE */\
