Hardware 3D acceleration doesn't work anymore after the PowerPC updates 4.14-1

Hi All, I tested the latest Git kernel version with the new PowerPC updates 4.14-1 [0][1] on my Varisys Cyrus Plus board (A-EON AmigaOne X5000) [2][3] with a Qoriq P5020 PowerPC CPU from NXP yesterday. Unfortunately the hardware 3D acceleration doesn't work anymore since the PowerPC updates 4

Re: Hardware 3D acceleration doesn't work anymore after the PowerPC updates 4.14-1

Hi Christian, Christian Zigotzky writes: > Hi All, > > I tested the latest Git kernel version with the new PowerPC updates > 4.14-1 [0][1] on my Varisys Cyrus Plus board (A-EON AmigaOne X5000) > [2][3] with a Qoriq P5020 PowerPC CPU from NXP yesterday. Unfortunately > the hardware 3D accelerat

Re: [PATCH V3] cxl: Add support for POWER9 DD2

Christophe Lombard writes: > The PSL initialization sequence has been updated to DD2. > This patch adapts to the changes, retaining compatibility with DD1. > The patch includes some changes to DD1 fix-ups as well. > > Tests performed on some of the old/new hardware. > > The function is_page_fault

Re: Hardware 3D acceleration doesn't work anymore after the PowerPC updates 4.14-1

Hi Michael, It works! :-) I have successfully tested it with ubuntu MATE 16.04.3 LTS PowerPC (Mesa 17.0.7 with an AMD Radeon HD4870) and with the MATE PowerPC Remix 2017 (Mesa 17.0.1 with an AMD Radeon HD4870). Many thanks for your help! Cheers, Christian On 11 September 2017 at 11:28AM,

[PATCH] powerpc/perf: Fix for core/nest imc call trace on cpuhotplug

Nest/core pmu units are enabled only when it is used. A reference count is maintained for the events which uses the nest/core pmu units. Currently in *_imc_counters_release function a WARN() is used for notification of any underflow of ref count. Replace WARN() with a pr_info since it is an overkil

Re: [linux-next] [bisected a4615d11] Memory DLPAR triggers WARN_ONCE() in mm/page_vma_mapped.c

Hi Abdul, Can you try this patch below? I think I missed that pmd entries can be zapped, so the WARN_ONCE is unnecessary. Thanks. diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c index 6a03946469a9..eb462e7db0a9 100644 --- a/mm/page_vma_mapped.c +++ b/mm/page_vma_mapped.c @@ -167,8 +167,

[PATCH v1 0/4] Revisit MCE handling for UE Errors

This patch series is designed to hook up memory_failure on UE errors, this is specially helpful for user_mode UE errors. The first patch is a cleanup patch, it removes dead code. I could not find any users of get_mce_fault_addr(). The second patch walks kernel/user mode page tables in real mode to

[PATCH v1 1/4] powerpc/mce.c: Remove unused function get_mce_fault_addr()

There are no users of get_mce_fault_addr() Fixes: b63a0ff ("powerpc/powernv: Machine check exception handling.") Signed-off-by: Balbir Singh --- arch/powerpc/include/asm/mce.h | 2 -- arch/powerpc/kernel/mce.c | 39 --- 2 files changed, 41 deletions(-)

[PATCH v1 2/4] powerpc/mce: Hookup derror (load/store) UE errors

Extract physical_address for UE errors by walking the page tables for the mm and address at the NIP, to extract the instruction. Then use the instruction to find the effective address via analyse_instr(). We might have page table walking races, but we expect them to be rare, the physical address e

[PATCH v1 3/4] powerpc/mce: Hookup ierror (instruction) UE errors

Hookup instruction errors (UE) for memory offling via memory_failure() in a manner similar to load/store errors (derror). Since we have access to the NIP, the conversion is a one step process in this case. Signed-off-by: Balbir Singh --- arch/powerpc/kernel/mce_power.c | 23 -

[PATCH v1 4/4] powerpc/mce: hookup memory_failure for UE errors

If we are in user space and hit a UE error, we now have the basic infrastructure to walk the page tables and find out the effective address that was accessed, since the DAR is not valid. We use a work_queue content to hookup the bad pfn, any other context causes problems, since memory_failure itse

Re: [PATCH v1 0/4] Revisit MCE handling for UE Errors

Hi Balbir, Very cool. How are you testing it? Is it failing memory pages and poisoning them out properly? Looks like you have a printk in the machine_check_early path, which you shouldn't. I guess because we don't mark that context as an NMI. Which we could... but I think you want to put as littl