- 09 May, 2017 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linuxMichael Ellerman authored
Freescale updates from Scott: "Includes a fix for a powerpc/next mm regression on 64e, a fix for a kernel hang on 64e when using a debugger inside a relocated kernel, a qman fix, and misc qe improvements."
-
Nicholas Piggin authored
Similarly to commit 2563a70c ("powerpc/64s: Remove unnecessary relocation branch from idle handler"), the machine check handler has a BRANCH_TO from relocated to relocated code, which is unnecessary. It has also caused build errors with some toolchains: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:395: Error: operand out of range (0xffffffffffff8280 is not between 0x0000000000000000 and 0x000000000000ffff) Fixes: 1945bc45 ("powerpc/64s: Fix POWER9 machine check handler from stop state") Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reported-and-tested-by : Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Michael Ellerman authored
Recently in commit f6eedbba ("powerpc/mm/hash: Increase VA range to 128TB") we increased the virtual address space for user processes to 128TB by default, and up to 512TB if user space opts in. This obviously required expanding the range of the Linux page tables. For Book3s 64-bit using hash and with PAGE_SIZE=64K, we increased the PGD to 2^15 entries. This meant we could cover the full address range, while still being able to insert a 16G hugepage at the PGD level and a 16M hugepage in the PMD. The downside of that geometry is that it uses a lot of memory for the PGD, and in particular makes the PGD a 4-page allocation, which means it's much more likely to fail under memory pressure. Instead we can make the PMD larger, so that a single PUD entry maps 16G, allowing the 16G hugepages to sit at that level in the tree. We're then able to split the remaining bits between the PUG and PGD. We make the PGD slightly larger as that results in lower memory usage for typical programs. When THP is enabled the PMD actually doubles in size, to 2^11 entries, or 2^14 bytes, which is large but still < PAGE_SIZE. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
-
Horia Geantă authored
Makefile.postlink always includes include/config/auto.conf, however this file is not present in a clean kernel tree, causing make to fail: $ git clone linuxppc.git $ cd linuxppc.git $ make distclean arch/powerpc/Makefile.postlink:10: include/config/auto.conf: No such file or directory make[1]: *** No rule to make target `include/config/auto.conf'. Stop. make: *** [vmlinuxclean] Error 2 Equally running 'make distclean; make distclean' will trip the error case. Change the inclusion such that file not being found does not trigger an error. Fixes: f188d052 ("powerpc: Use the new post-link pass to check relocations") Reported-by:
Mircea Pop <mircea.pop@nxp.com> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by:
-
- 05 May, 2017 1 commit
-
-
Scott Wood authored
Commit f4ea6dcb ("powerpc/mm: Enable mappings above 128TB") increased the task size on book3s, and introduced a mechanism to dynamically control whether a task uses these larger addresses. While the change to the task size itself was ifdef-protected to only apply on book3s, the change to STACK_TOP_USER64 was not. On book3e, this had the effect of trying to use addresses up to 128TiB for the stack despite a 64TiB task size limit -- which broke 64-bit userspace producing the following errors: Starting init: /sbin/init exists but couldn't execute it (error -14) Starting init: /bin/sh exists but couldn't execute it (error -14) Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. Fixes: f4ea6dcb ("powerpc/mm: Enable mappings above 128TB") Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Scott Wood <oss@buserror.net>
-
- 04 May, 2017 1 commit
-
-
Gavin Shan authored
Similar to what is done in commit b6541db1 ("powerpc/eeh: Block PCI config access upon frozen PE"), we need block PCI config access for BCM5719 when recovering frozen error on them. Otherwise, an unexpected recursive fenced PHB error is observed. 0001:06:00.0 Ethernet controller: Broadcom Corporation \ NetXtreme BCM5718 Gigabit Ethernet PCIe (rev 10) 0001:06:00.1 Ethernet controller: Broadcom Corporation \ NetXtreme BCM5718 Gigabit Ethernet PCIe (rev 10) Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
- 03 May, 2017 9 commits
-
-
Nicholas Piggin authored
Power9/ISAv3 has no VRMASD field in LPCR, we shouldn't be setting reserved bits, so don't set them on Power9. Signed-off-by:
-
Alistair Popple authored
Commit 616badd2 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2") forced all TCE kills to go via the OPAL call for NVLink2. However the PHB3 implementation of TCE kill was still being called directly from some functions which in some circumstances caused a machine check. This patch adds an equivalent IODA2 version of the function which uses the correct invalidation method depending on PHB model and changes all external callers to use it instead. Fixes: 616badd2 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2") Cc: stable@vger.kernel.org # v4.11+ Signed-off-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
-
Michael Ellerman authored
Currently the radix TLB code includes support for CPUs that do *not* have MMU_FTR_LOCKLESS_TLBIE. On those CPUs we are required to take a global spinlock before issuing a tlbie. Radix can only be built for 64-bit Book3s CPUs, and of those, only POWER4, 970, Cell and PA6T do not have MMU_FTR_LOCKLESS_TLBIE. Although it's possible to build a kernel with Radix support that can also boot on those CPUs, we happen to know that in reality none of those CPUs support the Radix MMU, so the code can never actually run on those CPUs. So remove the native_tlbie_lock in the Radix TLB code. Note that there is another lock of the same name in the hash code, which is unaffected by this patch. Reviewed-by:
-
Mahesh Salgaonkar authored
machine_check_early() gets called in real mode. The very first time when add_taint() is called, it prints a warning which ends up calling opal call (that uses OPAL_CALL wrapper) for writing it to console. If we get a very first machine check while we are in opal we are doomed. OPAL_CALL overwrites the PACASAVEDMSR in r13 and in this case when we are done with MCE handling the original opal call will use this new MSR on it's way back to opal_return. This usually leads to unexpected behaviour or the kernel to panic. Instead move the add_taint() call later in the virtual mode where it is safe to call. This is broken with current FW level. We got lucky so far for not getting very first MCE hit while in OPAL. But easily reproducible on Mambo. Fixes: 27ea2c42 ("powerpc: Set the correct kernel taint on machine check errors.") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Michael Ellerman authored
The entire body of unregister_cpu_online() is inside an #ifdef CONFIG_HOTPLUG_CPU block. This is ugly and means we create an empty function when hotplug is disabled for no reason. Instead move the #ifdef out of the function body and define the function to be NULL in the else case. This means we'll pass NULL to cpuhp_setup_state(), but that's fine because it accepts NULL to mean there is no teardown callback, which is exactly what we want. Signed-off-by: -
Michael Ellerman authored
This code was until recently completely undocumented and even now the comment is not very verbose. We've already had one patch sent to remove the IRQ enable/disable because it's "paradoxical and unnecessary". So document it thoroughly to save anyone else from puzzling over it. Signed-off-by: -
Michael Ellerman authored
Otherwise we might select it when its dependenices aren't enabled, leading to a build break. It's default y anyway, so will be on unless someone disables it manually. Signed-off-by: -
Andrew Donnellan authored
pnv_eeh_reset() has special handling for PEs whose primary bus is the root bus or the bus immediately underneath the root port. The cxl bi-modal card support added in b0b5e591 ("cxl: Add cxl_check_and_switch_mode() API to switch bi-modal cards") relies on this behaviour when hot-resetting the CAPI adapter following a mode switch. Document this in pnv_eeh_reset() so we don't accidentally break it. Suggested-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by:
-
Christophe Leroy authored
This patch allows the use of IRQ to notify the change of GPIO status on MPC8xx CPM IO ports. This then allows to associate IRQs to GPIOs in the Device Tree. Ex: CPM1_PIO_C: gpio-controller@960 { #gpio-cells = <2>; compatible = "fsl,cpm1-pario-bank-c"; reg = <0x960 0x10>; fsl,cpm1-gpio-irq-mask = <0x0fff>; interrupts = <1 2 6 9 10 11 14 15 23 24 26 31>; interrupt-parent = <&CPM_PIC>; gpio-controller; }; The property 'fsl,cpm1-gpio-irq-mask' defines which of the 16 GPIOs have the associated interrupts defined in the 'interrupts' property. Signed-off-by:Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
- 02 May, 2017 5 commits
-
-
Russell Currey authored
Remove unnecessary tags in eeh_handle_normal_event(), and add function comments for eeh_handle_normal_event() and eeh_handle_special_event(). The only functional difference is that in the case of a PE reaching the maximum number of failures, rather than one message telling you of this and suggesting you reseat the device, there are two separate messages. Suggested-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Russell Currey <ruscur@russell.cc> Reviewed-by:
-
Russell Currey authored
eeh_handle_special_event() is called when an EEH event is detected but can't be narrowed down to a specific PE. This function looks through every PE to find one in an erroneous state, then calls the regular event handler eeh_handle_normal_event() once it knows which PE has an error. However, if eeh_handle_normal_event() found that the PE cannot possibly be recovered, it will free it, rendering the passed PE stale. This leads to a use after free in eeh_handle_special_event() as it attempts to clear the "recovering" state on the PE after eeh_handle_normal_event() returns. Thus, make sure the PE is valid when attempting to clear state in eeh_handle_special_event(). Fixes: 8a6b1bc7 ("powerpc/eeh: EEH core to handle special event") Cc: stable@vger.kernel.org # v3.11+ Reported-by:
-
Alastair D'Silva authored
In some situations, a faulty AFU slice may create an interrupt storm of slice errors, rendering the machine unusable. Since these interrupts are informational only, present the interrupt once, then mask it off to prevent it from being retriggered until the AFU is reset. Signed-off-by:
Alastair D'Silva <alastair@d-silva.org> Reviewed-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
-
Vaibhav Jain authored
Fix a boundary condition where in some cases an eeh event that results in card reset isn't passed on to a driver attached to the virtual PCI device associated with a slice. This will happen in case when a slice attached device driver returns a value other than PCI_ERS_RESULT_NEED_RESET from the eeh error_detected() callback. This would result in an early return from cxl_pci_error_detected() and other drivers attached to other AFUs on the card wont be notified. The patch fixes this by making sure that all slice attached device-drivers are notified and the return values from error_detected() callback are aggregated in a scheme where request for 'disconnect' trumps all and 'none' trumps 'need_reset'. Fixes: 9e8df8a2 ("cxl: EEH support") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by:
-
Vaibhav Jain authored
During an eeh event when the cxl card is fenced and card sysfs attr perst_reloads_same_image is set following warning message is seen in the kernel logs: Adapter context unlocked with 0 active contexts ------------[ cut here ]------------ WARNING: CPU: 12 PID: 627 at ../drivers/misc/cxl/main.c:325 cxl_adapter_context_unlock+0x60/0x80 [cxl] Even though this warning is harmless, it clutters the kernel log during an eeh event. This warning is triggered as the EEH callback cxl_pci_error_detected doesn't obtain a context-lock before forcibly detaching all active context and when context-lock is released during call to cxl_configure_adapter from cxl_pci_slot_reset, a warning in cxl_adapter_context_unlock is triggered. To fix this warning, we acquire the adapter context-lock via cxl_adapter_context_lock() in the eeh callback cxl_pci_error_detected() once all the virtual AFU PHBs are notified and their contexts detached. The context-lock is released in cxl_pci_slot_reset() after the adapter is successfully reconfigured and before the we call the slot_reset callback on slice attached device-drivers. Fixes: 70b565bb ("cxl: Prevent adapter reset if an active context exists") Cc: stable@vger.kernel.org # v4.9+ Reported-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Tested-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
-
- 01 May, 2017 2 commits
-
-
Nicholas Piggin authored
This was a hack we added to work around the allmodconfig build breaking, see commit fb43e847 ("powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64"). Since we merged the thin archives support in commit 43c9127d ("powerpc: Add option to use thin archives") this hasn't been necessary, so remove it. Signed-off-by:
-
Michael Neuling authored
Currently if we take an oops caused by an 0x380 or 0x480 exception, we get a print which assumes SLB problems. With radix, these vectors have different meanings. This patch updates the oops message to reflect these different meanings. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
-
- 30 Apr, 2017 7 commits
-
-
Roy Pledge authored
Work for Congestion State Notifications (CSCN) and Message Ring (MR) handling is handled via the workqueue mechanism. This requires the driver to disable those IRQs before scheduling the work and re-enabling it once the work is completed so that the interrupt doesn't continually fire. Signed-off-by:
Roy Pledge <roy.pledge@nxp.com> Signed-off-by:
-
Valentin Longchamp authored
This allows to build the fsl_ucc_hdlc driver as a module. Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
-
Valentin Longchamp authored
The QE_General4 workaround is only valid for the MPC832x and MPC836x SoCs. The other SoCs that embed a QUICC engine are not affected by this hardware bug and thus can use the computed divisors (this was successfully tested on the T1040). Similalry to what was done in commit 8ce795cb ("i2c: mpc: assign the correct prescaler from SVR") in order to avoid changes in the device tree nodes of the QE (with maybe a variant of the compatible property), the PVR reg is read out to find out if the workaround must be applied or not. Signed-off-by:
-
Valentin Longchamp authored
Because of integer computation rounding in u-boot (that sets the QE brg-frequency DTS prop), the clk value is 99999999 Hz even though it is 100 MHz. When setting brg clks that are exact divisors of 100 MHz, this small differnce plays a role and can result in lower clks to be output (for instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6). This patch fixes that by "forcing" the brg_clk to the nearest kHz when the difference is below 2 integer rounding errors (i.e. 4). Signed-off-by:
-
Christophe Leroy authored
immrbar_virt_to_phys() is not used anymore Signed-off-by:
Li Yang <pku.leo@gmail.com> Signed-off-by:
-
Christophe Leroy authored
Since commit 5093bb96 ("powerpc/QE: switch to the cpm_muram implementation"), muram area is not part of immrbar mapping anymore so immrbar_virt_to_phys() is not usable anymore. Fixes: 5093bb96 ("powerpc/QE: switch to the cpm_muram implementation") Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
-
LiuHailong authored
Debug interrupts can be taken during interrupt entry, since interrupt entry does not automatically turn them off. The kernel will check whether the faulting instruction is between [interrupt_base_book3e, __end_interrupts], and if so clear MSR[DE] and return. However, when the kernel is built with CONFIG_RELOCATABLE, it can't use LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) and LOAD_REG_IMMEDIATE(r15,__end_interrupts), as they ignore relocation. Thus, if the kernel is actually running at a different address than it was built at, the address comparison will fail, and the exception entry code will hang at kernel_dbg_exc. r2(toc) is also not usable here, as r2 still holds data from the interrupted context, so LOAD_REG_ADDR() doesn't work either. So we use the *name@got* to get the EV of two labels directly. Test programs test.c shows as follows: int main(int argc, char *argv[]) { if (access("/proc/sys/kernel/perf_event_paranoid", F_OK) == -1) printf("Kernel doesn't have perf_event support\n"); } Steps to reproduce the bug, for example: 1) ./gdb ./test 2) (gdb) b access 3) (gdb) r 4) (gdb) s Signed-off-by:Liu Hailong <liu.hailong6@zte.com.cn> Signed-off-by:
Jiang Xuexin <jiang.xuexin@zte.com.cn> Reviewed-by:
Jiang Biao <jiang.biao2@zte.com.cn> Reviewed-by:
Liu Song <liu.song11@zte.com.cn> Reviewed-by:
Huang Jian <huang.jian@zte.com.cn> [scottwood: cleaned up commit message, and specified bad behavior as a hang rather than an oops to correspond to mainline kernel behavior] Fixes: 1cb6e064 ("powerpc/book3e: support CONFIG_RELOCATABLE") Cc: <stable@vger.kernel.org> # 4.4.x- Signed-off-by:
-
- 28 Apr, 2017 11 commits
-
-
Michael Ellerman authored
Michal Suchánek noticed a comment in book3s/64/mmu-hash.h about the context ids we use for the kernel was inconsistent with the code and other comments in the same file. It should read 1-4 not 1-5. While we're touching it, update "address" to "addresses" which makes more sense as it's referring to more than one address below. Reported-by:
Michal Suchánek <msuchanek@suse.de> Signed-off-by:
-
Alexey Kardashevskiy authored
This enables VFIO on pseries host in order to allow VFIO in nested guest under PR KVM or DPDK in a HV guest. This adds support of the VFIO_SPAPR_TCE_IOMMU type. This adds exchange() callback to allow TCE updates by the SPAPR TCE IOMMU driver in VFIO. This initializes DMA32 window parameters in iommu_table_group as as this does not implement VFIO_SPAPR_TCE_v2_IOMMU and VFIO_SPAPR_TCE_IOMMU just reuses the existing DMA32 window. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Alexey Kardashevskiy authored
When the userspace requests a small TCE table (which takes less than the system page size) and more than 1 TCE level, the existing code returns a single page size which is a bug as each additional TCE level requires at least one page and this is what pnv_pci_ioda2_table_alloc_pages() does. And we end up seeing WARN_ON(!ret && ((*ptbl)->it_allocated_size != table_size)) in drivers/vfio/vfio_iommu_spapr_tce.c. This replaces incorrect _ALIGN_UP() (which aligns zero up to zero) with max_t() to fix the bug. Besides removing WARN_ON(), there should be no other changes in behaviour. Signed-off-by:
-
Alexey Kardashevskiy authored
pnv_pci_table_alloc() ignores possible failure from kzalloc_node(), this adds a check. There are 2 callers of pnv_pci_table_alloc(), one already checks for tbl!=NULL, this adds WARN_ON() to the other path which only happens during boot time in IODA1 and not expected to fail. Signed-off-by:
-
Nicholas Piggin authored
Move a couple of existing scripts under there. Remove scripts directory: a script is a tool, a tool is not a script. Signed-off-by:
-
Nicholas Piggin authored
Currently powerpc has to introduce a dependency on its default build target zImage in order to run a relocation check pass over the linked vmlinux. This is deficient because the check is not run if the plain vmlinux target is built, or if one of the other boot targets is built. Switch to using the kbuild post-link pass, added in commit fbe6e37d ("kbuild: add arch specific post-link Makefile") in order to run this check. In future powerpc will use this to do more complicated operations, but initially using it for something simple is a good first step. Signed-off-by:
-
Nicholas Piggin authored
An externally triggered system reset (e.g., via QEMU nmi command, or pseries reset button) can cause system reset interrupts on all CPUs. In case this causes xmon to be entered, it is undesirable for the primary (first) CPU into xmon to trigger an NMI IPI to others, because this may cause a nested system reset interrupt. So spin for a time waiting for secondaries to join xmon before performing the NMI IPI, similarly to what the crash dump code does. Signed-off-by:
-
Nicholas Piggin authored
Signed-off-by:
-
Nicholas Piggin authored
Have the NMI IPI code use this op when the platform defines it. Signed-off-by:
-
Nicholas Piggin authored
Add a simple NMI IPI system that handles concurrency and reentrancy. The platform does not have to implement a true non-maskable interrupt, the default is to simply use the debugger break IPI message. This has now been co-opted for a general IPI message, and users (debugger and crash) have been reimplemented on top of the NMI system. Signed-off-by:
-
Nicholas Piggin authored
System reset is a non-maskable interrupt from Linux's point of view (occurs under local_irq_disable()), so it should use nmi_enter/exit. Signed-off-by:
-
