Re: [PATCH 2/2] MAINTAINERS: ibmvfc driver maintainer change
Brian, can you ACK this one? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: kvm: Set M flag for KVM PTE depending on CPU_FTR_NEED_COHERENT
Usually page table entries only have the M (coherence) flag set, if the
kernel is in SMP mode or to avoid data corruption due to CPU bugs (e.g.
some 74xx CPUs). KVM on book3s_32 however always sets the M flag for a
PTE, which locks up machines based on the amigaone platform when running
QEMU or MoL.
Setting the M flag depending on CPU_FTR_NEED_COHERENT also makes KVM work
on this platform and aligns the PTE setup to the rest of the kernel.
Signed-off-by: Gerhard Pircher
---
With this patch I could successfully run a Debian Wheezy installation
inside QEMU started with --enable-kvm on my AmigaOneG3SE.
arch/powerpc/kvm/book3s_32_mmu_host.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 2035d16..935c7d0 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -204,7 +204,10 @@ next_pteg:
pteg0 = ((eaddr & 0x0fff) >> 22) | (vsid << 7) | PTE_V |
(primary ? 0 : PTE_SEC);
- pteg1 = hpaddr | PTE_M | PTE_R | PTE_C;
+ pteg1 = hpaddr | PTE_R | PTE_C;
+
+ if (cpu_has_feature(CPU_FTR_NEED_COHERENT))
+ pteg1 |= PTE_M;
if (orig_pte->may_write && writable) {
pteg1 |= PP_RWRW;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: offlining cpus breakage
On 01/17/2015 07:09 PM, Preeti U Murthy wrote: > On 01/16/2015 08:34 AM, Michael Ellerman wrote: >> On Fri, 2015-01-16 at 13:28 +1300, Alexey Kardashevskiy wrote: >>> On 01/16/2015 02:22 AM, Preeti U Murthy wrote: Hi Alexey, Can you let me know if the following patch fixes the issue for you ? It did for us on one of our machines that we were investigating on. >>> >>> This fixes the issue for me as well, thanks! >>> >>> Tested-by: Alexey Kardashevskiy >> >> OK, that's great. >> >> But, I really don't think we can ask upstream to merge this patch to generic >> code when we don't have a good explanation for why it's necessary. At least >> I'm >> not going to ask anyone to do that :) >> >> So Pretti can you either write a 100% convincing explanation of why this >> patch >> is correct in the general case, or (preferably) do some more investigating to >> work out what Alexey's bug actually is. > > On further investigation, I found that the issue lies in the latency of > cpu hotplug operation, specifically the time taken for the offline cpu > to enter powersave mode. > > The time between the beginning of the cpu hotplug operation and the > beginning of __cpu_die() operation (which is one of the last stages of > cpu hotplug) takes around a maximum of 40ms. Although this is not > causing softlockups, it is quite a large duration. > > The more serious issue is the time taken for __cpu_die() operation to > complete. The __cpu_die() operation waits for the offline cpu to set its > state to CPU_DEAD before entering powersave state. This time varies from > 4s to a maximum of 200s! It is not this bad always but it does happen > quite a few times. It is during these times that we observe softlockups. > I added trace prints throughout the cpu hotplug code to measure these > numbers. This delay is causing the softlockup and here is why. > > If the cpu going offline is the one broadcasting wakeups to cpus in > fastsleep, it queues the broadcast timer on another cpu during the > CPU_DEAD phase. The CPU_DEAD notifiers are run only after the > __cpu_die() operation completes, which is taking a long time as > mentioned above. So between the time irqs are migrated off the about to > go offline cpu and CPU_DEAD stage, no cpu can be woken up. The above > numbers show that this can be a horridly long time. Hence the next time > that they get woken up the unnatural idle time is detected and > softlockup triggers. > > The patch on this thread that I proposed covered up the problem by > allowing the remaining cpus to freshly reevaluate their wakeups after > the stop machine phase without having to depend on the previous > broadcast state.So it did not matter what the previously appointed > broadcast cpu was upto.However there are still corner cases which cannot > get solved with this patch. And understandably because it is not > addressing the core issue, which is how to get around the latency issue > of cpu hotplug. > > There can be ways in which the broadcast timer be migrated in time > during hotplug to get around the softlockups, but the latency of the cpu > hotplug operation looks like a serious issue. Has anybody observed or > explicitly instrumented cpu hotplug operation before and happened to > notice the large time duration required for its completion? > > Ccing Paul. Ok, finally the problem is clear. The latency observed during hotplug was a result of a bug in the tick-broadcast framework in the cpu offline path as was previously presumed. The problem description and the apt fix is below. Alexey, would you mind giving this patch a try yet again ? I will post it out to mainline as soon as you confirm it fixes your issue. This patch is a tad bit different from the previous one. Thanks! Regards Preeti U Murthy -start patch--- tick/broadcast: Make movement of broadcast hrtimer robust against hotplug From: Preeti U Murthy Today if a cpu handling broadcasting of wakeups goes offline, it hands over the job of broadcasting to another cpu in the CPU_DEAD phase. The CPU_DEAD notifiers are run only after the offline cpu sets its state as CPU_DEAD. Meanwhile, the kthread doing the offline is scheduled out while waiting for this transition by queuing a timer. This is fatal because if the cpu on which this kthread was running has no other work queued on it, it can re-enter deep idle state, since it sees that a broadcast cpu still exists. However the broadcast wakeup will never come since the cpu which was handling it is offline, and this cpu never wakes up to see this because its in deep idle state. Fix this by setting the broadcast timer to a max value so as to force the cpus entering deep idle states henceforth to freshly nominate the broadcast cpu. More importantly this has to be done in the CPU_DYING phase so that it is visible to all cpus right after exiting stop_machine, which is when they can re-enter idle. This ensures that handove
[PATCH] powerpc/pseries: Avoid context switch in EEH reset if required
On pseries platform, the EEH reset backend pseries_eeh_reset() can
be called in atomic context as follows. For this case, we should
call udelay() instead of msleep() to avoid context switching.
drivers/scsi/ipr.c::ipr_reset_slot_reset_done()
drivers/pci/pci.c::pci_set_pcie_reset_state()
arch/powerpc/kernel/eeh.c::pcibios_set_pcie_reset_state()
arch/powerpc/platforms/pseries/eeh_pseries.c::pseries_eeh_reset()
Signed-off-by: Gavin Shan
Tested-by: Wen Xiong
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
b/arch/powerpc/platforms/pseries/eeh_pseries.c
index a6c7e19..67623a3 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -503,8 +503,7 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int
*state)
*/
static int pseries_eeh_reset(struct eeh_pe *pe, int option)
{
- int config_addr;
- int ret;
+ int config_addr, delay, ret;
/* Figure out PE address */
config_addr = pe->config_addr;
@@ -528,9 +527,14 @@ static int pseries_eeh_reset(struct eeh_pe *pe, int option)
/* We need reset hold or settlement delay */
if (option == EEH_RESET_FUNDAMENTAL ||
option == EEH_RESET_HOT)
- msleep(EEH_PE_RST_HOLD_TIME);
+ delay = EEH_PE_RST_HOLD_TIME;
+ else
+ delay = EEH_PE_RST_SETTLE_TIME;
+
+ if (in_atomic())
+ udelay(delay * 1000);
else
- msleep(EEH_PE_RST_SETTLE_TIME);
+ msleep(delay);
return ret;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] CXL: Use image state defaults for reloading FPGA
Acked-by: Ian Munsie Looks like you forgot your Signed-off-by line - mpe, do you want Ryan to resend the whole patch (maybe with the below explanation included), or just reply with a Signed-off-by? This would also be good to CC: Stable, as these new defaults mean that the card will be fully reset when sapphire PERSTs them on reboot, whereas before it was left up to the default value of this register in each card, and could lead to a card getting into a bad state requiring a full power cycle to recover. The symptoms we saw was the tlbia / slbia we do on boot timing out and the driver init aborting. Cheers, -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] CXL: Add image control to sysfs
Acked-by: Ian Munsie This is also missing a Signed-off-by line Cheers, -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[no subject]
Bcc: Subject: Re: [PATCH 3/4] CXL: Enable CAPP recovery In-reply-to: <1421437687-12835-3-git-send-email-gr...@linux.vnet.ibm.com> References: <1421437687-12835-1-git-send-email-gr...@linux.vnet.ibm.com> <1421437687-12835-3-git-send-email-gr...@linux.vnet.ibm.com> Acked-by: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] CXL: Add ability to reset the card
Acked-by: Ian Munsie ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] CXL: Enable CAPP recovery
Acked-by: Ian Munsie Apologies if this is a resend - my mail client just went weird. Cheers, -Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] idle/tick-broadcast: Exit cpu idle poll loop when cleared from tick_broadcast_force_mask
An idle cpu enters cpu_idle_poll() if it is set in the tick_broadcast_force_mask. This is so that it does not incur the overhead of entering idle states when it is expected to be woken up anytime then through a broadcast IPI. The condition that forces an exit out of the idle polling is the check on setting of the TIF_NEED_RESCHED flag for the idle thread. When the broadcast IPI does arrive, it is not guarenteed that the handler sets the TIF_NEED_RESCHED flag. Hence although the cpu is cleared in the tick_broadcast_force_mask, it continues to loop in cpu_idle_poll unnecessarily wasting power. Hence exit the idle poll loop if the tick_broadcast_force_mask gets cleared and enter idle states. Of course if the cpu has entered cpu_idle_poll() on being asked to poll explicitly, it continues to poll till it is asked to reschedule. Signed-off-by: Preeti U Murthy --- kernel/sched/idle.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c index c47fce7..aaf1c1d 100644 --- a/kernel/sched/idle.c +++ b/kernel/sched/idle.c @@ -47,7 +47,8 @@ static inline int cpu_idle_poll(void) rcu_idle_enter(); trace_cpu_idle_rcuidle(0, smp_processor_id()); local_irq_enable(); - while (!tif_need_resched()) + while (!tif_need_resched() && + (cpu_idle_force_poll || tick_check_broadcast_expired())) cpu_relax(); trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id()); rcu_idle_exit(); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] CXL: Use image state defaults for reloading FPGA
On Mon, 2015-01-19 at 16:03 +1100, Ian Munsie wrote: > Acked-by: Ian Munsie > > Looks like you forgot your Signed-off-by line - mpe, do you want Ryan to > resend the whole patch (maybe with the below explanation included), or > just reply with a Signed-off-by? Just resend the series please. > This would also be good to CC: Stable, as these new defaults mean that > the card will be fully reset when sapphire PERSTs them on reboot, > whereas before it was left up to the default value of this register in > each card, and could lead to a card getting into a bad state requiring a > full power cycle to recover. The symptoms we saw was the tlbia / slbia > we do on boot timing out and the driver init aborting. OK. I've decided I'm going to handle stable patches differently for the next cycle, we've been sending too many and then sending fixups and reverts. So please just note that you'd like it to be considered for stable, under the --- line, and I'll add it to my list and if it's still good to go in a few weeks then I'll send it to stable. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
