On 13.05.19 09:48, David Hildenbrand wrote:
> On 07.05.19 23:02, Dan Williams wrote:
>> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>>
>>> Let's prepare for better error handling while adding memory by allowing
>>> to use arch_remove_memory() and __remove_pages() even if
>>>
On 11/05/2019 08:41, Thiago Jung Bauermann wrote:
>
> Hello Alexey,
>
> Thanks!
>
> I have similar changes in my "Secure Virtual Machine Enablement"
> patches, which I am currently preparing for posting again real soon now.
>
> This is the last version:
>
>
On 11/05/2019 08:36, Thiago Jung Bauermann wrote:
>
> Alexey Kardashevskiy writes:
>
>> The commit 8617a5c5bc00 ("powerpc/dma: handle iommu bypass in
>> dma_iommu_ops") merged direct DMA ops into the IOMMU DMA ops allowing
>> SWIOTLB as well but only for mapping; the unmapping and bouncing
Michael Ellerman wrote:
Nicholas Piggin writes:
The new mprofile-kernel mcount sequence is
mflr r0
bl_mcount
Dynamic ftrace patches the branch instruction with a noop, but leaves
the mflr. mflr is executed by the branch unit that can only execute one
per cycle on POWER9 and shared
On Fri, 2019-05-10 at 17:34 +0300, andriy.shevche...@linux.intel.com wrote:
> [External]
>
>
> On Fri, May 10, 2019 at 09:15:27AM +, Ardelean, Alexandru wrote:
> > On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> > > On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> > > > On
On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
> Add a check for sample_period value sent from userspace. Negative
> value does not make sense. And in powerpc arch code this could cause
> a recursive PMI leading to a hang (reported when running perf-fuzzer).
>
> Signed-off-by:
On Sun, Apr 28, 2019 at 09:45:15PM +1000, Nicholas Piggin wrote:
> This is the KVM update to the new idle code. A few improvements:
>
> - Idle sleepers now always return to caller rather than branch out
> to KVM first.
> - This allows optimisations like very fast return to caller when no
>
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference to
`dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add force enable of
DAWR on P9 option").
This puts more
On 5/13/19 7:39 AM, Michael Neuling wrote:
> commit 243e25112d06 ("powerpc/xive: Native exploitation of the XIVE
> interrupt controller") added an option to turn off Linux native XIVE
> usage via the xive=off kernel command line option.
>
> This documents this option.
>
> Signed-off-by: Michael
On 07.05.19 23:02, Dan Williams wrote:
> On Tue, May 7, 2019 at 11:38 AM David Hildenbrand wrote:
>>
>> Let's prepare for better error handling while adding memory by allowing
>> to use arch_remove_memory() and __remove_pages() even if
>> CONFIG_MEMORY_HOTREMOVE is not set.
The local variable snum_init has no reason to have static storage duration.
Reviewed-by: Christophe Leroy
Reviewed-by: Qiang Zhao
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/qe.c
On Mon, 2019-05-13 at 11:14 +, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Reading table 4-30, and its footnotes, of the QUICC
Herbert Xu writes:
> On Mon, May 06, 2019 at 08:53:17AM -0700, Eric Biggers wrote:
>>
>> Any progress on this? Someone just reported this again here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=203515
>
> Guys if I don't get a fix for this soon I'll have to disable CTR
> in vmx.
No objection
On Mon 2019-05-13 12:13:20, Andy Shevchenko wrote:
> On Mon, May 13, 2019 at 08:52:41AM +, David Laight wrote:
> > From: christophe leroy
> > > Sent: 10 May 2019 18:35
> > > Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > > > On Fri, 10 May 2019 10:42:13 +0200
> > > > Petr Mladek wrote:
>
From: christophe leroy
> Sent: 10 May 2019 18:35
> Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > On Fri, 10 May 2019 10:42:13 +0200
> > Petr Mladek wrote:
> >
> >> static const char *check_pointer_msg(const void *ptr)
> >> {
> >> - char byte;
> >> -
> >>if (!ptr)
> >>
On 05/08/2019 10:29 AM, Nicholas Piggin wrote:
Abhishek Goel's on April 22, 2019 4:32 pm:
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect,
Reading table 4-30, and its footnotes, of the QUICC Engine Block
Reference Manual shows that the set of snum _values_ is not
necessarily just a function of the _number_ of snums, as given in the
fsl,qe-num-snums property.
As an alternative, to make it easier to add support for other variants
of
Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
with -j 1") was also wrong.
Check-in source files never ever depend on build artifacts.
The correct dependency is:
$(obj)/serial.o: $(obj)/autoconf.h
Le 13/05/2019 à 09:17, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined reference
to `dawr_force_enable'
This was caused by commit c1fe190c0672 ("powerpc: Add
On Mon, May 13, 2019 at 08:52:41AM +, David Laight wrote:
> From: christophe leroy
> > Sent: 10 May 2019 18:35
> > Le 10/05/2019 à 18:24, Steven Rostedt a écrit :
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek wrote:
> > >> -if (probe_kernel_address(ptr, byte))
> > >> +
Add driver support for the newly introduced fsl,qe-snums property.
Conveniently, of_property_read_variable_u8_array does exactly what we
need: If the property fsl,qe-snums is found (and has an allowed size),
the array of values get copied to snums, and the return value is the
number of snums - we
Shawn Landden writes:
> It is safe to do SIMD in an interrupt on PowerPC.
No it's not sorry :)
> Only disable when there is no SIMD available
> (and this is a static branch).
>
> Tested and works with the WireGuard (Zinc) patch I wrote that needs this.
> Also improves performance of the crypto
The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
MPC8309 has 14. The code path returning -EINVAL is also a recipe for
instant disaster, since the caller (qe_snums_init) uncritically
assigns the return value to the unsigned qe_num_of_snum, and would
thus proceed to attempt to
On Fri 2019-05-10 12:40:58, Steven Rostedt wrote:
> On Fri, 10 May 2019 18:32:58 +0200
> Martin Schwidefsky wrote:
>
> > On Fri, 10 May 2019 12:24:01 -0400
> > Steven Rostedt wrote:
> >
> > > On Fri, 10 May 2019 10:42:13 +0200
> > > Petr Mladek wrote:
> > >
> > > > static const char
https://bugzilla.kernel.org/show_bug.cgi?id=203571
--- Comment #2 from Shawn Landden (sland...@gmail.com) ---
X86 manages to allow SIMD in interrupts through some very careful code in
arch/x86/kernel/fpu/core.c (starting with irq_fpu_usable())
PowerPC can do the same.
--
You are receiving this
On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
> > Add a check for sample_period value sent from userspace. Negative
> > value does not make sense. And in powerpc arch code this could cause
> > a recursive PMI
On 5/13/19 2:26 PM, Peter Zijlstra wrote:
> On Mon, May 13, 2019 at 09:42:13AM +0200, Peter Zijlstra wrote:
>> On Sat, May 11, 2019 at 08:12:16AM +0530, Ravi Bangoria wrote:
>>> Add a check for sample_period value sent from userspace. Negative
>>> value does not make sense. And in powerpc arch
The current array of struct qe_snum use 256*4 bytes for just keeping
track of the free/used state of each index, and the struct layout
means there's another 768 bytes of padding. If we just unzip that
structure, the array of snum values just use 256 bytes, while the
free/inuse state can be tracked
The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
of_find_node_by_type(NULL, "qe")' pattern is repeated five
times. Factor it into a common helper.
Reviewed-by: Christophe Leroy
Reviewed-by: Qiang Zhao
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 71
quad.o is only for PPC64, and already included in obj64-y,
so it doesn't have to be in obj-y
Fixes: 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to
handle alignment faults")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/Makefile | 2 +-
1 file changed, 1
The entire code in ldstfp.o is enclosed into #ifdef CONFIG_PPC_FPU,
so there is no point in building it when this config is not selected.
Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/Makefile | 3 ++-
arch/powerpc/lib/ldstfp.S | 4
This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of
"Naveen N. Rao" writes:
> Michael Ellerman wrote:
>> Nicholas Piggin writes:
>>> The new mprofile-kernel mcount sequence is
>>>
>>> mflr r0
>>> bl_mcount
>>>
>>> Dynamic ftrace patches the branch instruction with a noop, but leaves
>>> the mflr. mflr is executed by the branch
Dmitry Vyukov writes:
> From: Arnd Bergmann
> Date: Sat, May 11, 2019 at 2:51 AM
> To: Dmitry Vyukov
> Cc: Nick Kossifidis, Christoph Hellwig, Linus Torvalds, Andrew Morton,
> linux-arch, Linux Kernel Mailing List, linuxppc-dev
>
>> On Fri, May 10, 2019 at 6:53 AM Dmitry Vyukov wrote:
>> > >
>>
On Mon, May 13, 2019 at 01:50:19PM +0200, Dmitry Vyukov wrote:
> > We did have some bugs in the past (~1-2 y/ago) but AFAIK they are all
> > fixed now. These days I build most of my kernels with a bi-endian 64-bit
> > toolchain, and switching endian without running `make clean` also works.
>
>
On 5/13/2019 12:40 PM, Joakim Tjernlund wrote:
> On Mon, 2019-05-13 at 16:09 +, Roy Pledge wrote:
>> The index value should be passed to the of_parse_phandle()
>> function to ensure the correct property is read.
> Is this a bug fix? Maybe for stable too?
>
> Jocke
Yes this could go to stable.
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Bug ID: 203597
Summary: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at
early stage
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 4.9.175
https://bugzilla.kernel.org/show_bug.cgi?id=203597
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 282745
--> https://bugzilla.kernel.org/attachment.cgi?id=282745=edit
bisect.log
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, 13 May 2019 11:14:58 +, Rasmus Villemoes wrote:
> Reading table 4-30, and its footnotes, of the QUICC Engine Block
> Reference Manual shows that the set of snum _values_ is not
> necessarily just a function of the _number_ of snums, as given in the
> fsl,qe-num-snums property.
>
> As
Michael,
Any comments on this patch ? Should I repost with a shorter comment
as suggested by Alexey ?
Cheers,
--
Greg
On Mon, 29 Apr 2019 12:36:59 +0200
Greg Kurz wrote:
> On Mon, 29 Apr 2019 16:01:29 +1000
> Alexey Kardashevskiy wrote:
>
> > On 20/04/2019 01:34, Greg Kurz wrote:
> > >
On 2019/5/8 17:42, John Garry wrote:
> On 18/04/2019 14:57, Zhen Lei wrote:
>> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
>> opportunity to set {lazy|strict} mode as default at build time. Then put
>> the three config options in an choice, make people can only
Rework QBMan private memory setup so that the areas are not
zeroed if the device was previously initialized
If the QMan private memory was already initialized skip the PFDR
initialization.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman_ccsr.c | 26 --
The drain_mr_fqni() function may be called fron uninterruptable
context so convert the msleep() to an mdelay(). Also ensure that
the valid bit is updated while polling.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
with -j 1") was also wrong.
The correct dependency is:
$(obj)/serial.o: $(obj)/autoconf.h
However, I do not see the reason why we need to copy
Clean the BMan buffer pools if the device had been initialized
previously. This will ensure a consistent state if the kernel
was soft restarted (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/bman.c| 17 +
drivers/soc/fsl/qbman/bman_ccsr.c | 10
"Naveen N. Rao" writes:
> When CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is enabled, we always initialize
> DTL enable mask to DTL_LOG_PREEMPT (0x2). There are no other places
> where the mask is changed. As such, when reading the DTL log buffer
> through debugfs, there is no need to save and restore
On Mon, May 13, 2019 at 9:33 PM Masahiro Yamada
wrote:
>
> Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> with -j 1") was also wrong.
>
> Check-in source files never ever depend on build artifacts.
On Mon, 13 May 2019 14:42:20 +0200
Petr Mladek wrote:
> > The "(null)" is good enough by itself and already an established
> > practice..
>
> (efault) made more sense with the probe_kernel_read() that
> checked wide range of addresses. Well, I still think that
> it makes sense to distinguish
"Naveen N. Rao" writes:
> Introduce macros to encode the DTL enable mask fields and use those
> instead of hardcoding numbers.
This is a good cleanup on its own.
Acked-by: Nathan Lynch
The index value should be passed to the of_parse_phandle()
function to ensure the correct property is read.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/dpaa_sys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/dpaa_sys.c
On Mon, 2019-05-13 at 16:09 +, Roy Pledge wrote:
>
> The index value should be passed to the of_parse_phandle()
> function to ensure the correct property is read.
Is this a bug fix? Maybe for stable too?
Jocke
>
> Signed-off-by: Roy Pledge
> ---
> drivers/soc/fsl/qbman/dpaa_sys.c | 2
On Mon, May 13, 2019 at 11:56 PM Masahiro Yamada
wrote:
>
> On Mon, May 13, 2019 at 9:33 PM Masahiro Yamada
> wrote:
> >
> > Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> > was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> > with -j 1") was also
Most DPAA1 devices do not support a soft reset which is an issue if
Kexec starts a new kernel. This patch series allows Kexec to function
by detecting that the QBMan device was previously initialized.
The patches fix some issues with device cleanup as well as ensuring
that the location of the
When shutting down a FQ on a dedicated channel only the
SW portal associated with that channel can dequeue from it.
Make sure the correct portal is use.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 53 +++-
1 file changed, 42
When using the reserved memory node in the device tree there are
two options - dynamic or static. If a dynamic allocation was
selected (where the kernel selects the address for the allocation)
convert it to a static allocation by inserting the reg property.
This will ensure the same memory is
On Mon, May 13, 2019 at 9:23 PM Masahiro Yamada
wrote:
>
> Commit 5e9dcb6188a4 ("powerpc/boot: Expose Kconfig symbols to wrapper")
> was wrong, but commit e41b93a6be57 ("powerpc/boot: Fix build failures
> with -j 1") was also wrong.
>
> Check-in source files never ever depend on build artifacts.
If the QMan device was previously initialized make sure all the
frame queues are out of service once all the portals are probed.
This handles the case where the kernel is restarted without the
SoC being reset (kexec for example)
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c
Disable the QBMan interrupts during recovery.
Signed-off-by: Roy Pledge
---
drivers/soc/fsl/qbman/qman.c | 22 +++---
drivers/soc/fsl/qbman/qman_ccsr.c | 1 +
drivers/soc/fsl/qbman/qman_priv.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git
This second patch is separate because it could be wrong,
like I am not sure about how kernel thread migration works,
and it is even allowing simd in preemptible kernel code.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 8 +
arch/powerpc/include/asm/switch_to.h |
On 05/14/2019 08:23 AM, Aneesh Kumar K.V wrote:
> When we initialize the namespace, if we support altmap, we don't initialize
> all the
> backing struct page where as while releasing the namespace we look at some of
> these uninitilized struct page. This results in a kernel crash as below.
Yes
On 5/14/19 9:59 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
wrote:
We already add the start_pad to the resource->start but fails to section
align the start. This make sure with altmap we compute the right first
pfn when start_pad is zero and we are doing an align
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC|
Hi Greg,
Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9
since 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought
marked for #4.13+
Thanks
Christophe
Le 13/05/2019 à 22:18, bugzilla-dae...@bugzilla.kernel.org a écrit :
On 5/8/19 4:30 PM, Sachin Sant wrote:
While running LTP tests (specifically futex_wake04) against next-20199597
build with 4K page size on a POWER8 LPAR following crash is observed.
[ 4233.214876] BUG: Kernel NULL pointer dereference at 0x001c
[ 4233.214898] Faulting instruction address:
On (05/13/19 14:42), Petr Mladek wrote:
> > The "(null)" is good enough by itself and already an established
> > practice..
>
> (efault) made more sense with the probe_kernel_read() that
> checked wide range of addresses. Well, I still think that
> it makes sense to distinguish a pure NULL. And
This second patch is separate because it could be wrong,
like I am not sure about how kernel thread migration works,
and it is even allowing simd in preemptible kernel code.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/switch_to.h | 15 ++-
arch/powerpc/kernel/process.c
Based off the x86 one.
WireGuard really wants to be able to do SIMD in interrupts,
so it can accelerate its in-bound path.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 10 ++
arch/powerpc/kernel/process.c | 30 ++
2 files changed, 40
On 5/14/19 9:45 AM, Dan Williams wrote:
[ add Keith who was looking at something similar ]
On Mon, May 13, 2019 at 7:54 PM Aneesh Kumar K.V
wrote:
When we initialize the namespace, if we support altmap, we don't initialize all
the
backing struct page where as while releasing the namespace
On Mon, 2019-05-13 at 17:40 +, Roy Pledge wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 5/13/2019 12:40 PM, Joakim Tjernlund wrote:
> > On Mon,
Based off the x86 one.
WireGuard really wants to be able to do SIMD in interrupts,
so it can accelerate its in-bound path.
Signed-off-by: Shawn Landden
---
arch/powerpc/include/asm/simd.h | 13 +
arch/powerpc/kernel/process.c | 30 ++
2 files changed,
We already add the start_pad to the resource->start but fails to section
align the start. This make sure with altmap we compute the right first
pfn when start_pad is zero and we are doing an align down of start address.
Signed-off-by: Aneesh Kumar K.V
---
kernel/memremap.c | 4 ++--
1 file
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled
When we initialize the namespace, if we support altmap, we don't initialize all
the
backing struct page where as while releasing the namespace we look at some of
these uninitilized struct page. This results in a kernel crash as below.
kernel BUG at include/linux/mm.h:1034!
cpu 0x2: Vector: 700
[ add Keith who was looking at something similar ]
On Mon, May 13, 2019 at 7:54 PM Aneesh Kumar K.V
wrote:
>
> When we initialize the namespace, if we support altmap, we don't initialize
> all the
> backing struct page where as while releasing the namespace we look at some of
> these
This fix the below crash that arise due to not handling page table allocation
failures while allocating hugetlb page table.
BUG: Kernel NULL pointer dereference at 0x001c
Faulting instruction address: 0xc1d1e58c
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=4K
On (05/14/19 11:07), Sergey Senozhatsky wrote:
> How about this:
>
> if ptr < PAGE_SIZE -> "(null)"
No, this is totally stupid. Forget about it. Sorry.
> if IS_ERR_VALUE(ptr)-> "(fault)"
But Steven's "(fault)" is nice.
-ss
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
>
> The nfpn related change is needed to fix the kernel message
>
> "number of pfns truncated from 2617344 to 163584"
>
> The change makes sure the nfpns stored in the superblock is right value.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
>
On 5/14/19 9:28 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
wrote:
>
> We already add the start_pad to the resource->start but fails to section
> align the start. This make sure with altmap we compute the right first
> pfn when start_pad is zero and we are doing an align down of start address.
>
>
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from 2617344 to 163584"
The change makes sure the nfpns stored in the superblock is right value.
Signed-off-by: Aneesh Kumar K.V
---
drivers/nvdimm/pfn_devs.c| 6 +++---
drivers/nvdimm/region_devs.c | 8
On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
wrote:
>
> On 5/14/19 9:28 AM, Dan Williams wrote:
> > On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
> > wrote:
> >>
> >> The nfpn related change is needed to fix the kernel message
> >>
> >> "number of pfns truncated from 2617344 to 163584"
>
On Mon, 2019-05-13 at 11:08 +0200, Christophe Leroy wrote:
>
> Le 13/05/2019 à 09:17, Michael Neuling a écrit :
> > If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
> > at linking with:
> >arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x708): undefined
> > reference to
On 5/14/19 9:42 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 9:05 PM Aneesh Kumar K.V
wrote:
On 5/14/19 9:28 AM, Dan Williams wrote:
On Mon, May 13, 2019 at 7:56 PM Aneesh Kumar K.V
wrote:
The nfpn related change is needed to fix the kernel message
"number of pfns truncated from
On Mon, 2019-05-13 at 22:44 -0300, Shawn Landden wrote:
> +
> +/*
> + * Were we in user mode when we were
> + * interrupted?
> + *
> + * Doing kernel_altivec/vsx_begin/end() is ok if we are running
> + * in an interrupt context from user mode - we'll just
> + * save the FPU state as required.
> +
Le 14/05/2019 à 06:47, Michael Neuling a écrit :
On Mon, 2019-05-13 at 11:08 +0200, Christophe Leroy wrote:
Le 13/05/2019 à 09:17, Michael Neuling a écrit :
If you compile with KVM but without CONFIG_HAVE_HW_BREAKPOINT you fail
at linking with:
85 matches
Mail list logo
