Currently when an EEH error is detected, the system log receives the
same (or almost the same) message twice:
EEH: PHB#0 failure detected, location: N/A
EEH: PHB#0 failure detected, location: N/A
or
EEH: eeh_dev_check_failure: Frozen PHB#0-PE#0 detected
EEH: Frozen PHB#0-PE#0 detected
This looks
On Thu, Oct 17, 2019 at 1:01 PM Yi Li wrote:
>
> Hi,
*snip*
> The kernel module can be insert correctly, and we mount a tmpfs, then umount.
> Kernel panic when doing umount:
> "
> [ 148.569777] umount /home/adam/test 0x0
> [ 148.608227] umount2 returned 0
> [ 148.608268] Unable to handle
On Wed, Oct 16, 2019 at 06:28:33PM +0200, Frederic Barrat wrote:
> Recent cleanup in the way EEH support is added to a device causes a
> kernel oops when the cxl driver probes a device and creates virtual
> devices discovered on the FPGA:
>
> BUG: Kernel NULL pointer dereference at 0x00a0
On 2019/10/15 下午3:35, Christoph Hellwig wrote:
On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
From: Thiago Jung Bauermann
Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
be set by both device and guest driver. However, as a hack, when DMA API
returns
On Wed, 2019-10-16 at 20:30 +1100, Michael Ellerman wrote:
> I think the main reason is that in some configurations we can't use 64K
> pages for MMIO, so the 64K vmalloc mappings and 4K MMIO mappings need to
> be in different segments.
>
> It's possible that's no longer true on modern configs.
On Wed, 2019-10-16 at 15:19 +0200, Carlo Pisani wrote:
> hi
> I am a student, I represent a group of friends running a couple of
> opensource projects(1), and we are lost with this(2) problem.
>
> I wrote here(2) a couple of years ago, we are still working with
> kernel
> 4.11.0 and there is
Hi,
We tried to replace the umount system call with our own code. Bellow is the
simplified test case.
When doing umount, there is kernel panic (on centos7
4.14.0-115.10.1.el7a.ppc64le kernel) on P9 OpenPOWER machine.
Could you please give suggestions on how to make the system call hook work
On 2019/10/17 0:44, Florian Fainelli wrote:
> On 10/16/19 3:46 AM, YueHaibing wrote:
>> devm_platform_ioremap_resource() internally have platform_get_resource()
>> and devm_ioremap_resource() in it. So instead of calling them separately
>> use devm_platform_ioremap_resource() directly.
>
> Did
Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan/vmalloc_shadow_pages.
Signed-off-by: Daniel Axtens
---
v8: rename kasan_vmalloc/shadow_pages -> kasan/vmalloc_shadow_pages
On v4 (no dynamic freeing), I saw the following approximate figures
on my test VM:
- fresh
In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.
We prepopulate pgds/p4ds for the range that would otherwise be empty.
This is required to get it synced to hardware on boot, allowing the
lower levels of the page tables to be filled
Supporting VMAP_STACK with KASAN_VMALLOC is straightforward:
- clear the shadow region of vmapped stacks when swapping them in
- tweak Kconfig to allow VMAP_STACK to be turned on with KASAN
Reviewed-by: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
arch/Kconfig | 9 +
Test kasan vmalloc support by adding a new test to the module.
Signed-off-by: Daniel Axtens
--
v5: split out per Christophe Leroy
---
lib/test_kasan.c | 26 ++
1 file changed, 26 insertions(+)
diff --git lib/test_kasan.c lib/test_kasan.c
index
Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different
Currently, vmalloc space is backed by the early shadow page. This
means that kasan is incompatible with VMAP_STACK.
This series provides a mechanism to back vmalloc space with real,
dynamically allocated memory. I have only wired up x86, because that's
the only currently supported arch I can work
https://bugzilla.kernel.org/show_bug.cgi?id=205201
--- Comment #1 from Christian Zigotzky (chzigot...@xenosoft.de) ---
I have the same problem with my analog PCI TV card Typhoon TView RDS + FM
Stereo (BT878 chip) in my AmigaOne X5000. It only works with reducing the mem
size to 3500MB
On Fri, 27 Sep 2019 13:53:32 +0200
Greg Kurz wrote:
> This brings some fixes and allows to start more VMs with an in-kernel
> XIVE or XICS-on-XIVE device.
>
> Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
> - drop a useless patch
> - add a patch to show VP ids in debugfs
> -
Nathan Lynch writes:
> Move dlpar_offline_cpu() before dlpar_online_cpu() so the latter can
> use the former to re-offline any threads it has onlined when it
> encounters an error.
Since moving this code yields a few valid checkpatch warnings, I've
submitted a v2 which cleans these up first.
Remove some stray blank lines, convert a printk to pr_warn, and
address a line length violation.
One functional change: use WARN_ON instead of BUG_ON in case H_PROD of
a ceded thread yields an unexpected result from the platform. We can
expect this code path to get uninterruptibly stuck in
This is a respin of https://patchwork.ozlabs.org/patch/1164930/.
Changes since v1:
* Address checkpatch warnings in dlpar_offline_cpu before moving it.
* Add Fixes: tags.
Nathan Lynch (2):
powerpc/pseries: address checkpatch warnings in dlpar_offline_cpu
powerpc/pseries: safely roll back
dlpar_online_cpu() attempts to online all threads of a core that has
been added to an LPAR. If onlining a non-primary thread
fails (e.g. due to an allocation failure), the core is left with at
least one thread online. dlpar_cpu_add() attempts to roll back the
whole operation, releasing the core
On Wed, Oct 16, 2019 at 06:50:30PM +0300, Sergey Miroshnichenko wrote:
> On 10/16/19 1:14 AM, Bjorn Helgaas wrote:
> > On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
> > > On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
> > > > It's possible that a hot-add will trigger this
On 10/16/19 3:46 AM, YueHaibing wrote:
> devm_platform_ioremap_resource() internally have platform_get_resource()
> and devm_ioremap_resource() in it. So instead of calling them separately
> use devm_platform_ioremap_resource() directly.
Did your coccinelle script not cover
On 10/16/19 3:46 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Florian Fainelli
--
Florian
Recent cleanup in the way EEH support is added to a device causes a
kernel oops when the cxl driver probes a device and creates virtual
devices discovered on the FPGA:
BUG: Kernel NULL pointer dereference at 0x00a0
Faulting instruction address: 0xc0048070
Oops: Kernel
YueHaibing writes:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Reviewed-by: Kevin Hilman
Seems to work for me so far! I've tried successfully against 5.2.21 and
5.3.6.
Thanks!
-Cameron
On 10/15/19 10:51 PM, Aneesh Kumar K.V wrote:
With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
regions in the same 0xc range"), kernel now split the 64TB address range
into 4
The Scheduled Process Area, located in system momory, contains a list of
Scheduled Processes (Structure of Process Element) to be serviced by the
AFUs. The process elements contain the address context and other state
information for the processes scheduled to run on the AFUs.
Update, rename and
Specifies the templates in the Transaction Layer that the OpenCAPI
device/host support when transmitting/receiving DL/DLX frames to or
from the OpenCAPI device/host.
Update, rename and create new few platform-specific calls which can
be used by drivers.
No functional change.
Signed-off-by:
This series moves the definition and the management of scheduled process
area (SPA) and of the templates (Transaction Layer) for an ocxl card,
using the OCAPI interface. The code is now located in the specific arch
powerpc platform.
These patches will help for a futur implementation of the ocxl
On 10/16/19 1:14 AM, Bjorn Helgaas wrote:
On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
Hello Bjorn,
On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
When hot-adding a device, the bridge may have windows
Le 15/10/2019 à 21:41, Frederic Barrat a écrit :
Le 15/10/2019 à 07:42, Sam Bobroff a écrit :
On Fri, Sep 27, 2019 at 02:45:10PM +0200, Frederic Barrat wrote:
Recent cleanup in the way EEH support is added to a device causes a
kernel oops when the cxl driver probes a device and creates
On 06.10.19 10:56, David Hildenbrand wrote:
Let's poison the pages similar to when adding new memory in
sparse_add_section(). Also call remove_pfn_range_from_zone() from
memunmap_pages(), so we can poison the memmap from there as well.
While at it, calculate the pfn in memunmap_pages() only
Hi Andrey,
On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote:
> On 10/14/19 4:57 PM, Daniel Axtens wrote:
> >>> + /*
> >>> + * Ensure poisoning is visible before the shadow is made visible
> >>> + * to other CPUs.
> >>> + */
> >>> + smp_wmb();
> >>
> >> I'm not quite understand
hi
I am a student, I represent a group of friends running a couple of
opensource projects(1), and we are lost with this(2) problem.
I wrote here(2) a couple of years ago, we are still working with kernel
4.11.0 and there is broken support for initializing the PCI.
The PCI initialization of the
hi
I am a student, I represent a group of friends running a couple of
opensource projects(1), and we are lost with this(2) problem.
I wrote here(2) a couple of years ago, we are still working with kernel
4.11.0 and there is broken support for initializing the PCI.
The PCI initialization of the
Hi
On 10/16/19 12:46 PM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
> ---
> drivers/char/hw_random/st-rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git
On 10/14/19 4:57 PM, Daniel Axtens wrote:
> Hi Andrey,
>
>
>>> + /*
>>> +* Ensure poisoning is visible before the shadow is made visible
>>> +* to other CPUs.
>>> +*/
>>> + smp_wmb();
>>
>> I'm not quite understand what this barrier do and why it needed.
>> And if it's really
On 2019/10/16 0:58, Greg KH wrote:
> On Tue, Oct 15, 2019 at 06:40:29PM +0800, Yunsheng Lin wrote:
>> On 2019/10/14 17:25, Greg KH wrote:
>>> On Mon, Oct 14, 2019 at 04:00:46PM +0800, Yunsheng Lin wrote:
On 2019/10/12 18:47, Greg KH wrote:
> On Sat, Oct 12, 2019 at 12:40:01PM +0200, Greg
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/pasemi-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/tx4939-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/tx4939-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/xgene-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/xgene-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/st-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/pic32-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/pic32-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/omap-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/npcm-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/npcm-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/meson-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/meson-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/hisi-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/hisi-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/ks-sa-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/ks-sa-rng.c
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
YueHaibing (13):
hwrng: atmel - use devm_platform_ioremap_resource() to simplify code
hwrng: bcm2835
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/bcm2835-rng.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/bcm2835-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/exynos-trng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/exynos-trng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/atmel-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/atmel-rng.c
On 10/15/2019 11:39 PM, Qian Cai wrote:
> On Tue, 2019-10-15 at 14:51 +0530, Anshuman Khandual wrote:
>> +static unsigned long __init get_random_vaddr(void)
>> +{
>> +unsigned long random_vaddr, random_pages, total_user_pages;
>> +
>> +total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS)
On 2019-10-16 20:33:08 [+1100], Michael Ellerman wrote:
> Christophe Leroy writes:
> > Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
> >> From: Thomas Gleixner
> >>
> >> CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> >> Both PREEMPT and PREEMPT_RT
Christophe Leroy writes:
> Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
>> From: Thomas Gleixner
>>
>> CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
>> Both PREEMPT and PREEMPT_RT require the same functionality which today
>> depends on CONFIG_PREEMPT.
Christoph Hellwig writes:
> On Wed, Oct 16, 2019 at 11:21:30AM +0530, Aneesh Kumar K.V wrote:
>> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
>> regions in the same 0xc range"), kernel now split the 64TB address range
>> into 4 contexts each of 16TB. That implies we can do
On 10/16/2019 12:12 AM, Qian Cai wrote:
> On Tue, 2019-10-15 at 20:51 +0530, Anshuman Khandual wrote:
>>
>> On 10/15/2019 08:11 PM, Qian Cai wrote:
>>> The x86 will crash with linux-next during boot due to this series (v5) with
>>> the
>>> config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not
On 10/16/19 11:35 AM, Christoph Hellwig wrote:
On Wed, Oct 16, 2019 at 11:21:30AM +0530, Aneesh Kumar K.V wrote:
With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
regions in the same 0xc range"), kernel now split the 64TB address range
into 4 contexts each of 16TB. That implies
On Thu, Oct 10, 2019 at 05:05:40PM -0700, Kees Cook wrote:
> Arch maintainers: please send Acks (if you haven't already) for your
> respective linker script changes; the intention is for this series to
> land via -tip.
>
> v1:
On Thu, Oct 10, 2019 at 05:05:46PM -0700, Kees Cook wrote:
> In preparation for moving NOTES into RO_DATA, move RO_DATA back into the
> "text" PT_LOAD Program Header, as done with other architectures. The
> "data" PT_LOAD now starts with the writable data section.
>
> Signed-off-by: Kees Cook
>
On Tue 15-10-19 20:51:11, Anshuman Khandual wrote:
>
>
> On 10/15/2019 08:11 PM, Qian Cai wrote:
> > The x86 will crash with linux-next during boot due to this series (v5) with
> > the
> > config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure if v6 would
> > address
> > it.
> >
> >
On Tue, Oct 15, 2019 at 09:35:01AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> > From: Thiago Jung Bauermann
> >
> > Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> > be set by both device and guest driver. However, as
On 2019-10-16 06:57:48 [+0200], Christophe Leroy wrote:
>
>
> Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
> > From: Thomas Gleixner
> >
> > CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> > Both PREEMPT and PREEMPT_RT require the same functionality
On Wed, Oct 16, 2019 at 11:21:30AM +0530, Aneesh Kumar K.V wrote:
> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
> regions in the same 0xc range"), kernel now split the 64TB address range
> into 4 contexts each of 16TB. That implies we can do only 16TB linear
> mapping. This
64 matches
Mail list logo
