* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Benjamin Herrenschmidt @ 2014-05-11 8:37 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <536F3192.2050004@linux.vnet.ibm.com>
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.
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Preeti U Murthy @ 2014-05-11 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <1399797477.17624.40.camel@pasglop>
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.
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Benjamin Herrenschmidt @ 2014-05-11 9:03 UTC (permalink / raw)
To: Preeti U Murthy; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <536F384C.3070409@linux.vnet.ibm.com>
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.
^ permalink raw reply
* Re: [PATCH] powerpc: irq work racing with timer interrupt can result in timer interrupt hang
From: Preeti U Murthy @ 2014-05-11 9:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulmck, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <1399799008.17624.43.camel@pasglop>
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 <preeti@linux.vnet.ibm.com>
Regards
Preeti U Murthy
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
From: Wilfried Klaebe @ 2014-05-11 12:46 UTC (permalink / raw)
To: Anish Khurana
Cc: devel, linux-s390, b.a.t.m.a.n, dev, xen-devel, linux-rdma,
netdev@vger.kernel.org, linux-usb, linux-wireless,
linux-kernel@vger.kernel.org, linux-acenic, trivial, e1000-devel,
bridge, devel, nios2-dev, virtualization, linuxppc-dev,
David S. Miller
In-Reply-To: <CANKiNjV7qrx-556DJk0qcOopnBs4NnKy51POEeZ7LpbdjX35OQ@mail.gmail.com>
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 =3D (ops) )
>=20
> 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
^ permalink raw reply
* Re: linux-next: add scottwood/linux.git
From: Stephen Rothwell @ 2014-05-11 22:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-next, linuxppc-dev
In-Reply-To: <1399670133.15726.440.camel@snotra.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
Hi Scott,
On Fri, 9 May 2014 16:15:33 -0500 Scott Wood <scottwood@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 Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: add scottwood/linux.git
From: Stephen Rothwell @ 2014-05-12 0:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Scott Wood, linux-next, linuxppc-dev
In-Reply-To: <20140512082336.501fa8a2@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]
Hi Scott,
On Mon, 12 May 2014 08:23:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Fri, 9 May 2014 16:15:33 -0500 Scott Wood <scottwood@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
sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix skipping call to early_init_fdt_scan_reserved_mem
From: Benjamin Herrenschmidt @ 2014-05-12 0:42 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Rob Herring, linux-kernel, Paul Mackerras,
Grant Likely, linuxppc-dev, Marek Szyprowski
In-Reply-To: <1398837832-30052-1-git-send-email-robherring2@gmail.com>
On Wed, 2014-04-30 at 01:03 -0500, Rob Herring wrote:
> From: Rob Herring <robh@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 <robh@kernel.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Tested-by: Stephen Chivers <schivers@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)
^ permalink raw reply
* Re: [PATCH] powerpc: reduce multi-hit of pcibios_setup_device() in hotplug
From: Benjamin Herrenschmidt @ 2014-05-12 2:59 UTC (permalink / raw)
To: Wei Yang; +Cc: Bjorn Helgaas, linuxppc-dev, aik, gwshan
In-Reply-To: <1399530602-4231-1-git-send-email-weiyang@linux.vnet.ibm.com>
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.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Benjamin Herrenschmidt @ 2014-05-12 4:12 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1399680478-4970-1-git-send-email-linux@roeck-us.net>
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.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Guenter Roeck @ 2014-05-12 4:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1399867920.17624.73.camel@pasglop>
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
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Benjamin Herrenschmidt @ 2014-05-12 5:37 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1399867920.17624.73.camel@pasglop>
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.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Guenter Roeck @ 2014-05-12 5:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1399873020.17624.79.camel@pasglop>
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
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Benjamin Herrenschmidt @ 2014-05-12 5:48 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <5370537F.8020901@roeck-us.net>
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.
^ permalink raw reply
* [PATCH] powerpc/ppc64: Allow allmodconfig to build (finally !)
From: Benjamin Herrenschmidt @ 2014-05-12 5:57 UTC (permalink / raw)
To: linuxppc-dev
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 <benh@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)
- xori r10,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
- oris r10,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,0xffff; \
- 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 */ \
- rotldi r10,r10,16; \
- mtspr SPRN_##_H##SRR1,r10; \
-2: mtcrf 0x80,r9; \
- ld r9,PACA_EXGEN+EX_R9(r13); \
- ld r10,PACA_EXGEN+EX_R10(r13); \
- ld r11,PACA_EXGEN+EX_R11(r13); \
- GET_SCRATCH0(r13); \
- ##_H##rfid; \
- b .
-
- MASKED_INTERRUPT()
- MASKED_INTERRUPT(H)
-
-/*
* Called from arch_local_irq_enable when an interrupt needs
* to be resent. r3 contains 0x500, 0x900, 0xa00 or 0xe80 to indicate
* which kind of interrupt. MSR:EE is already off. We generate a
@@ -759,50 +658,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(0xe60, hmi_exception, .unknown_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
@@ -949,6 +804,17 @@ hv_facility_unavailable_relon_trampoline:
#endif
STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist)
+ /* Equivalents to the above handlers for relocation-on interrupt vectors */
+ STD_RELON_EXCEPTION_HV_OOL(0xe40, emulation_assist)
+ MASKABLE_RELON_EXCEPTION_HV_OOL(0xe80, h_doorbell)
+
+ STD_RELON_EXCEPTION_PSERIES_OOL(0xf00, performance_monitor)
+ STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable)
+ STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable)
+ STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
+ STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
+
+
/* Other future vectors */
.align 7
.globl __end_interrupts
@@ -1028,11 +894,183 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
bl .kernel_bad_stack
b 1b
+
+#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
/*
- * Here r13 points to the paca, r9 contains the saved CR,
- * SRR0 and SRR1 are saved in r11 and r12,
- * r9 - r13 are saved in paca->exgen.
+ * Data area reserved for FWNMI option.
+ * This address (0x7000) is fixed by the RPA.
*/
+ .= 0x7000
+ .globl fwnmi_data_area
+fwnmi_data_area:
+
+ /* pseries and powernv need to keep the whole page from
+ * 0x7000 to 0x8000 free for use by the firmware
+ */
+ . = 0x8000
+#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
+
+/*
+ * Denorm interrupt assist moved out of line to here, where it remains
+ * close enough to the call site which uses a small conditional branch
+ */
+#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)
+ xori r10,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
+ oris r10,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
+
+/*
+ * 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.
+ *
+ * Warning: This code is reached using a (small) conditional branch from both
+ * the 1st level exception handlers below 0x8000 and the alternate feature
+ * sections of that file which the linker puts right after the text in here.
+ *
+ * For that to work, we thus need this code to be roughly near the "middle"
+ * so that we can reach it with <32k offsets. Here works... for now.
+ */
+#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,0xffff; \
+ 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 */ \
+ rotldi r10,r10,16; \
+ mtspr SPRN_##_H##SRR1,r10; \
+2: mtcrf 0x80,r9; \
+ ld r9,PACA_EXGEN+EX_R9(r13); \
+ ld r10,PACA_EXGEN+EX_R10(r13); \
+ ld r11,PACA_EXGEN+EX_R11(r13); \
+ GET_SCRATCH0(r13); \
+ ##_H##rfid; \
+ b .
+
+ MASKED_INTERRUPT()
+ MASKED_INTERRUPT(H)
+
+/*
+ * 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(0xe60, hmi_exception, .unknown_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,
+ * r9 - r13 are saved in paca->exgen.
+ */
.align 7
.globl data_access_common
data_access_common:
@@ -1075,69 +1113,6 @@ instruction_access_common:
STD_EXCEPTION_COMMON(0xe20, h_instr_storage, .unknown_exception)
-/*
- * Here is the common SLB miss user that is used when going to virtual
- * mode for SLB misses, that is currently not used
- */
-#ifdef __DISABLED__
- .align 7
- .globl slb_miss_user_common
-slb_miss_user_common:
- mflr r10
- std r3,PACA_EXGEN+EX_DAR(r13)
- stw r9,PACA_EXGEN+EX_CCR(r13)
- std r10,PACA_EXGEN+EX_LR(r13)
- std r11,PACA_EXGEN+EX_SRR0(r13)
- bl .slb_allocate_user
-
- ld r10,PACA_EXGEN+EX_LR(r13)
- ld r3,PACA_EXGEN+EX_R3(r13)
- lwz r9,PACA_EXGEN+EX_CCR(r13)
- ld r11,PACA_EXGEN+EX_SRR0(r13)
- mtlr r10
- beq- slb_miss_fault
-
- andi. r10,r12,MSR_RI /* check for unrecoverable exception */
- beq- unrecov_user_slb
- mfmsr r10
-
-.machine push
-.machine "power4"
- mtcrf 0x80,r9
-.machine pop
-
- clrrdi r10,r10,2 /* clear RI before setting SRR0/1 */
- mtmsrd r10,1
-
- mtspr SRR0,r11
- mtspr SRR1,r12
-
- ld r9,PACA_EXGEN+EX_R9(r13)
- 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)
- rfid
- b .
-
-slb_miss_fault:
- EXCEPTION_PROLOG_COMMON(0x380, PACA_EXGEN)
- ld r4,PACA_EXGEN+EX_DAR(r13)
- li r5,0
- std r4,_DAR(r1)
- std r5,_DSISR(r1)
- b handle_page_fault
-
-unrecov_user_slb:
- EXCEPTION_PROLOG_COMMON(0x4200, PACA_EXGEN)
- DISABLE_INTS
- bl .save_nvgprs
-1: addi r3,r1,STACK_FRAME_OVERHEAD
- bl .unrecoverable_exception
- b 1b
-
-#endif /* __DISABLED__ */
-
/*
* Machine check is different because we use a different
@@ -1297,30 +1272,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
.globl __end_handlers
__end_handlers:
- /* Equivalents to the above handlers for relocation-on interrupt vectors */
- STD_RELON_EXCEPTION_HV_OOL(0xe40, emulation_assist)
- MASKABLE_RELON_EXCEPTION_HV_OOL(0xe80, h_doorbell)
-
- STD_RELON_EXCEPTION_PSERIES_OOL(0xf00, performance_monitor)
- STD_RELON_EXCEPTION_PSERIES_OOL(0xf20, altivec_unavailable)
- STD_RELON_EXCEPTION_PSERIES_OOL(0xf40, vsx_unavailable)
- STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable)
- STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable)
-
-#if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV)
-/*
- * Data area reserved for FWNMI option.
- * This address (0x7000) is fixed by the RPA.
- */
- .= 0x7000
- .globl fwnmi_data_area
-fwnmi_data_area:
-
- /* pseries and powernv need to keep the whole page from
- * 0x7000 to 0x8000 free for use by the firmware
- */
- . = 0x8000
-#endif /* defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) */
/* Space for CPU0's segment table */
.balign 4096
^ permalink raw reply related
* [PATCH] powerpc: module: fix stubs for BE
From: Rusty Russell @ 2014-05-12 7:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alistair Popple, Anton Blanchard, linuxppc-dev
A simple patch which was supposed to swap r12 and r11 also
inexplicably changed the offset by two bytes. This instruction
(to load r2) isn't used in LE, so it wasn't noticed.
Fixes: b1ce369e82 ("powerpc: modules: use r12 for stub jump address.)
Reported-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Alistair Popple <alistair@popple.id.au>
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index ef349d0..077d2ce 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -134,7 +134,7 @@ static u32 ppc64_stub_insns[] = {
0xe98b0020, /* ld r12,32(r11) */
#if !defined(_CALL_ELF) || _CALL_ELF != 2
/* Set up new r2 from function descriptor */
- 0xe84b0026, /* ld r2,40(r11) */
+ 0xe84b0028, /* ld r2,40(r11) */
#endif
0x7d8903a6, /* mtctr r12 */
0x4e800420 /* bctr */
^ permalink raw reply related
* Re: [PATCH] printk/of_serial: fix serial console cessation part way through boot.
From: Geert Uytterhoeven @ 2014-05-12 9:33 UTC (permalink / raw)
To: Stephen Chivers
Cc: devicetree@vger.kernel.org, linux-serial, Greg KH,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
rob+dt, Grant Likely, Jiri Slaby, Chris Proctor
In-Reply-To: <20140510053734.AF4E9E0692@canberra.localdomain>
Hi Stephen,
On Sat, May 10, 2014 at 7:37 AM, Stephen Chivers <schivers@csc.com> wrote:
> Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
> "serial_core: Unregister console in uart_remove_one_port()"
> fixed a crash where a serial port was removed but
> not deregistered as a console.
>
> There is a side effect of that commit for platforms having serial consoles
> and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
> is disabled midway through the boot process.
>
> This cessation of the serial console affects PowerPC computers
> such as the MVME5100 and SAM440EP.
>
> The sequence is:
>
> bootconsole [udbg0] enabled
> ....
> serial8250/16550 driver initialises and registers its UARTS,
> one of these is the serial console.
> console [ttyS0] enabled
> ....
> of_serial probes "platform" devices, registering them as it goes.
> One of these is the serial console.
> console [ttyS0] disabled.
>
> The disabling of the serial console is due to:
>
> a. unregister_console in printk not clearing the
> CONS_ENABLED bit in the console flags,
> even though it has announced that the console is disabled; and
This part re-attaches the serial console on unbind/bind with the sh-sci driver,
too, which didn't work before. Cool, thanks!
> b. of_platform_serial_probe in of_serial not setting the port type
> before it registers with serial8250_register_8250_port.
This part I couldn't test.
> This patch ensures that the serial console is re-enabled when of_serial
> registers a serial port that corresponds to the designated console.
>
> Signed-off-by: Stephen Chivers <schivers@csc.com>
> Tested-by: Stephen Chivers <schivers@csc.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [unregister_console]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc/corenet64_smp_defconfig: enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x
From: Shengzhou Liu @ 2014-05-12 10:31 UTC (permalink / raw)
To: linuxppc-dev, scottwood; +Cc: Shengzhou Liu
By default we enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x,
which are needed on T2080QDS, T4240QDS, B4860QDS, etc.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
---
arch/powerpc/configs/corenet64_smp_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 63508dd..bbd70bb 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -111,6 +111,8 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
CONFIG_SPI=y
CONFIG_SPI_GPIO=y
CONFIG_SPI_FSL_SPI=y
--
1.8.0
^ permalink raw reply related
* [PATCH V6 1/2] KVM: PPC: BOOK3S: Always use the saved DAR value
From: Aneesh Kumar K.V @ 2014-05-12 11:34 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
Although it's optional, IBM POWER cpus always had DAR value set on
alignment interrupt. So don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
Changes from V5:
* Split the patch to two and also update commit message
arch/powerpc/kvm/book3s_emulate.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 99d40f8977e8..5d0f71663b99 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -611,6 +611,12 @@ u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
{
+#ifdef CONFIG_PPC_BOOK3S_64
+ /*
+ * Linux's fix_alignment() assumes that DAR is valid, so can we
+ */
+ return vcpu->arch.fault_dar;
+#else
ulong dar = 0;
ulong ra = get_ra(inst);
ulong rb = get_rb(inst);
@@ -635,4 +641,5 @@ ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
}
return dar;
+#endif
}
--
1.9.1
^ permalink raw reply related
* [PATCH V6 2/2] KVM: PPC: BOOK3S: Remove open coded make_dsisr in alignment handler
From: Aneesh Kumar K.V @ 2014-05-12 11:34 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
In-Reply-To: <1399894447-11322-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Use make_dsisr instead of open coding it. This also have
the added benefit of handling alignment interrupt on additional
instructions.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/disassemble.h | 34 +++++++++++++++++++++++++++++
arch/powerpc/kernel/align.c | 34 +----------------------------
arch/powerpc/kvm/book3s_emulate.c | 39 +---------------------------------
3 files changed, 36 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/include/asm/disassemble.h b/arch/powerpc/include/asm/disassemble.h
index 856f8deb557a..6330a61b875a 100644
--- a/arch/powerpc/include/asm/disassemble.h
+++ b/arch/powerpc/include/asm/disassemble.h
@@ -81,4 +81,38 @@ static inline unsigned int get_oc(u32 inst)
{
return (inst >> 11) & 0x7fff;
}
+
+#define IS_XFORM(inst) (get_op(inst) == 31)
+#define IS_DSFORM(inst) (get_op(inst) >= 56)
+
+/*
+ * Create a DSISR value from the instruction
+ */
+static inline unsigned make_dsisr(unsigned instr)
+{
+ unsigned dsisr;
+
+
+ /* bits 6:15 --> 22:31 */
+ dsisr = (instr & 0x03ff0000) >> 16;
+
+ if (IS_XFORM(instr)) {
+ /* bits 29:30 --> 15:16 */
+ dsisr |= (instr & 0x00000006) << 14;
+ /* bit 25 --> 17 */
+ dsisr |= (instr & 0x00000040) << 8;
+ /* bits 21:24 --> 18:21 */
+ dsisr |= (instr & 0x00000780) << 3;
+ } else {
+ /* bit 5 --> 17 */
+ dsisr |= (instr & 0x04000000) >> 12;
+ /* bits 1: 4 --> 18:21 */
+ dsisr |= (instr & 0x78000000) >> 17;
+ /* bits 30:31 --> 12:13 */
+ if (IS_DSFORM(instr))
+ dsisr |= (instr & 0x00000003) << 18;
+ }
+
+ return dsisr;
+}
#endif /* __ASM_PPC_DISASSEMBLE_H__ */
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 94908af308d8..34f55524d456 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -25,14 +25,13 @@
#include <asm/cputable.h>
#include <asm/emulated_ops.h>
#include <asm/switch_to.h>
+#include <asm/disassemble.h>
struct aligninfo {
unsigned char len;
unsigned char flags;
};
-#define IS_XFORM(inst) (((inst) >> 26) == 31)
-#define IS_DSFORM(inst) (((inst) >> 26) >= 56)
#define INVALID { 0, 0 }
@@ -192,37 +191,6 @@ static struct aligninfo aligninfo[128] = {
};
/*
- * Create a DSISR value from the instruction
- */
-static inline unsigned make_dsisr(unsigned instr)
-{
- unsigned dsisr;
-
-
- /* bits 6:15 --> 22:31 */
- dsisr = (instr & 0x03ff0000) >> 16;
-
- if (IS_XFORM(instr)) {
- /* bits 29:30 --> 15:16 */
- dsisr |= (instr & 0x00000006) << 14;
- /* bit 25 --> 17 */
- dsisr |= (instr & 0x00000040) << 8;
- /* bits 21:24 --> 18:21 */
- dsisr |= (instr & 0x00000780) << 3;
- } else {
- /* bit 5 --> 17 */
- dsisr |= (instr & 0x04000000) >> 12;
- /* bits 1: 4 --> 18:21 */
- dsisr |= (instr & 0x78000000) >> 17;
- /* bits 30:31 --> 12:13 */
- if (IS_DSFORM(instr))
- dsisr |= (instr & 0x00000003) << 18;
- }
-
- return dsisr;
-}
-
-/*
* The dcbz (data cache block zero) instruction
* gives an alignment fault if used on non-cacheable
* memory. We handle the fault mainly for the
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 5d0f71663b99..6bbdb3d1ec77 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -569,44 +569,7 @@ unprivileged:
u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
{
- u32 dsisr = 0;
-
- /*
- * This is what the spec says about DSISR bits (not mentioned = 0):
- *
- * 12:13 [DS] Set to bits 30:31
- * 15:16 [X] Set to bits 29:30
- * 17 [X] Set to bit 25
- * [D/DS] Set to bit 5
- * 18:21 [X] Set to bits 21:24
- * [D/DS] Set to bits 1:4
- * 22:26 Set to bits 6:10 (RT/RS/FRT/FRS)
- * 27:31 Set to bits 11:15 (RA)
- */
-
- switch (get_op(inst)) {
- /* D-form */
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- dsisr |= (inst >> 12) & 0x4000; /* bit 17 */
- dsisr |= (inst >> 17) & 0x3c00; /* bits 18:21 */
- break;
- /* X-form */
- case 31:
- dsisr |= (inst << 14) & 0x18000; /* bits 15:16 */
- dsisr |= (inst << 8) & 0x04000; /* bit 17 */
- dsisr |= (inst << 3) & 0x03c00; /* bits 18:21 */
- break;
- default:
- printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
- break;
- }
-
- dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
-
- return dsisr;
+ return make_dsisr(inst);
}
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH V6 1/2] KVM: PPC: BOOK3S: Always use the saved DAR value
From: Alexander Graf @ 2014-05-12 13:01 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1399894447-11322-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 12.05.14 13:34, Aneesh Kumar K.V wrote:
> Although it's optional, IBM POWER cpus always had DAR value set on
> alignment interrupt. So don't try to compute these values.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied both to kvm-ppc-queue.
Alex
^ permalink raw reply
* Re: [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
From: Felipe Balbi @ 2014-05-12 14:49 UTC (permalink / raw)
To: netdev, David S. Miller, linux-rdma, linux-acenic, nios2-dev,
linuxppc-dev, e1000-devel, devel, linux-usb, virtualization,
linux-wireless, xen-devel, linux-s390, devel, b.a.t.m.a.n, bridge,
dev, trivial, linux-kernel
In-Reply-To: <20140511001231.GC7875@kaos.lebenslange-mailadresse.de>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Sun, May 11, 2014 at 12:12:32AM +0000, Wilfried Klaebe wrote:
> net: get rid of SET_ETHTOOL_OPS
>
> Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
> This does that.
>
> Mostly done via coccinelle script:
> @@
> struct ethtool_ops *ops;
> struct net_device *dev;
> @@
> - SET_ETHTOOL_OPS(dev, ops);
> + dev->ethtool_ops = ops;
>
> Compile tested only, but I'd seriously wonder if this broke anything.
>
> Suggested-by: Dave Miller <davem@davemloft.net>
> Signed-off-by: Wilfried Klaebe <w-lkml@lebenslange-mailadresse.de>
for drivers/usb/gadget/:
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] powerpc: fix build of epapr_paravirt on 64-bit book3s
From: Scott Wood @ 2014-05-12 15:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Stuart Yoder
This fixes an allyesconfig build break introduced by commit
7762b1ed7aaee223230793fcee80672e2e3aa7a8 "powerpc: move epapr paravirt
init of power_save to an initcall".
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Stuart Yoder <stuart.yoder@freescale.com>
---
arch/powerpc/kernel/epapr_paravirt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index 8a7a62c..eab2f2a 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -73,8 +73,10 @@ int __init epapr_paravirt_early_init(void)
static int __init epapr_idle_init(void)
{
+#if !defined(CONFIG_64BIT) || defined(CONFIG_PPC_BOOK3E_64)
if (epapr_has_idle)
ppc_md.power_save = epapr_ev_idle;
+#endif
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error (again)
From: Guenter Roeck @ 2014-05-12 15:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <1399873724.17624.80.camel@pasglop>
On Mon, May 12, 2014 at 03:48:44PM +1000, Benjamin Herrenschmidt wrote:
> 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.
>
I'll be more than happy to wait. Let me know if I can test something.
Thanks,
Guenter
^ permalink raw reply
* Re: Bug in reclaim logic with exhausted nodes?
From: Nishanth Aravamudan @ 2014-05-12 18:46 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linux-mm, mgorman, linuxppc-dev, anton, rientjes
In-Reply-To: <alpine.DEB.2.10.1404031139090.21739@nuc>
Hi Christoph,
Sorry for the delay in my response!
On 03.04.2014 [11:41:37 -0500], Christoph Lameter wrote:
> On Mon, 31 Mar 2014, Nishanth Aravamudan wrote:
>
> > Yep. The node exists, it's just fully exhausted at boot (due to the
> > presence of 16GB pages reserved at boot-time).
>
> Well if you want us to support that then I guess you need to propose
> patches to address this issue.
Yep, that's my plan, I was hoping to get input from developers/experts
such as yourself first. Obviously, code speaks louder though...
> > I'd appreciate a bit more guidance? I'm suggesting that in this case
> > the node functionally has no memory. So the page allocator should
> > not allow allocations from it -- except (I need to investigate this
> > still) userspace accessing the 16GB pages on that node, but that, I
> > believe, doesn't go through the page allocator at all, it's all from
> > hugetlb interfaces. It seems to me there is a bug in SLUB that we
> > are noting that we have a useless per-node structure for a given
> > nid, but not actually preventing requests to that node or reclaim
> > because of those allocations.
>
> Well if you can address that without impacting the fastpath then we
> could do this. Otherwise we would need a fake structure here to avoid
> adding checks to the fastpath
Ok, I'll keep thinking about what makes the most sense.
> > I think there is a logical bug (even if it only occurs in this
> > particular corner case) where if reclaim progresses for a THISNODE
> > allocation, we don't check *where* the reclaim is progressing, and thus
> > may falsely be indicating that we have done some progress when in fact
> > the allocation that is causing reclaim will not possibly make any more
> > progress.
>
> Ok maybe we could address this corner case. How would you do this?
This is where I started to get stumped. It seems like did_some_progress
is only checking that any progress is made. It would be more expensive
in the reclaim path to check what nodes we made progress on and verify
it was on the intended one (if we are reclaiming due to THISNODE). I
will try and look at this case specifically more, I apologize it's
taking me quite a bit of time to get up-to-speed on the code and design.
Thanks,
Nish
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox