On 5/14/2019 12:04 PM, Dan Williams wrote:
On Tue, May 14, 2019 at 11:53 AM Jane Chu wrote:
On 5/13/2019 12:22 PM, Logan Gunthorpe wrote:
On 2019-05-08 11:05 a.m., Logan Gunthorpe wrote:
On 2019-05-07 5:55 p.m., Dan Williams wrote:
Changes since v1 [1]:
- Fix a NULL-pointer deref crash
On 1/25/2019 11:15 AM, Dan Williams wrote:
On Fri, Jan 25, 2019 at 11:10 AM Jane Chu wrote:
On 1/25/2019 10:20 AM, Verma, Vishal L wrote:
On Fri, 2019-01-25 at 09:18 -0800, Dan Williams wrote:
On Fri, Jan 25, 2019 at 12:20 AM Du, Fan wrote:
Dan
Thanks for the insights!
Can I say
On 1/25/2019 10:20 AM, Verma, Vishal L wrote:
On Fri, 2019-01-25 at 09:18 -0800, Dan Williams wrote:
On Fri, Jan 25, 2019 at 12:20 AM Du, Fan wrote:
Dan
Thanks for the insights!
Can I say, the UCE is delivered from h/w to OS in a single way in
case of machine
check, only PMEM/DAX stuff
Hi, Dave,
While chatting with my colleague Erwin about the patchset, it occurred
that we're not clear about the error handling part. Specifically,
1. If an uncorrectable error is detected during a 'load' in the hot
plugged pmem region, how will the error be handled? will it be
handled like
On 1/16/2019 3:32 PM, Naoya Horiguchi wrote:
Hi Jane,
On Wed, Jan 16, 2019 at 09:56:02AM -0800, Jane Chu wrote:
Hi, Naoya,
On 1/16/2019 1:30 AM, Naoya Horiguchi wrote:
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 7c72f2a95785..831be5ff5f4d 100644
--- a/mm
Hi, Alex,
On 11/08/2018 10:06 AM, Alexander Duyck wrote:
+/*
+ * __device_driver_lock - release locks needed to manipulate dev->drv
You meant to say __device_driver_unlock, right?
+ * @dev: Device we will update driver info for
+ * @parent: Parent device. Needed if the bus requires parent
Hi, Alex,
On 11/08/2018 10:06 AM, Alexander Duyck wrote:
+/*
+ * __device_driver_lock - release locks needed to manipulate dev->drv
You meant to say __device_driver_unlock, right?
+ * @dev: Device we will update driver info for
+ * @parent: Parent device. Needed if the bus requires parent
1 retries,
if the receiver has stopped making forward progress, the sender declares
send-mondo-timeout and panic; otherwise, the receiver is allowed to keep
making forward progress.
Orabug: 25476541
Signed-off-by: Jane Chu <jane@oracle.com>
Reviewed-by: Steve Sistare <st
1 retries,
if the receiver has stopped making forward progress, the sender declares
send-mondo-timeout and panic; otherwise, the receiver is allowed to keep
making forward progress.
Orabug: 25476541
Signed-off-by: Jane Chu
Reviewed-by: Steve Sistare
Reviewed-by: Anthony Yznaga
Reviewed-by: Rob
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu <jane@oracle.com>
Reviewed-by: Bob Picco <bob.pi...@oracle.com>
Reviewed-by:
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu
Reviewed-by: Bob Picco
Reviewed-by: Atish Patra
---
arch/sparc/Kconfig |4
On 06/05/2017 08:27 PM, David Miller wrote:
From: jane@oracle.com
Date: Mon, 5 Jun 2017 20:03:28 -0700
On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up
allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated
by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so
On 06/05/2017 08:27 PM, David Miller wrote:
From: jane@oracle.com
Date: Mon, 5 Jun 2017 20:03:28 -0700
On sun4v sparc, it looks like kzalloc(64, GFP_KERNEL) ends up
allocating from kmalloc_caches[6] - a 64-byte kmem-cache allocated
by kmem_cache_init() with SLAB_HWCACHE_ALIGN flag set, so
On 06/05/2017 05:57 PM, David Miller wrote:
From: Jane Chu <jane@oracle.com>
Date: Mon, 5 Jun 2017 16:48:31 -0600
Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info()
only allocates a single page for NR_CPUS mondo entries. Thus we cannot
use all 4096 CPUs on some
On 06/05/2017 05:57 PM, David Miller wrote:
From: Jane Chu
Date: Mon, 5 Jun 2017 16:48:31 -0600
Linux SPARC64 limits NR_CPUS to 4064 because init_cpu_send_mondo_info()
only allocates a single page for NR_CPUS mondo entries. Thus we cannot
use all 4096 CPUs on some SPARC platforms.
To fix
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu <jane@oracle.com>
Reviewed-by: Bob Picco <bob.pi...@oracle.com>
Reviewed-by:
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu
Reviewed-by: Bob Picco
Reviewed-by: Atish Patra
---
arch/sparc/Kconfig |4
t;4096
but num_possible_cpus() < 4096 -- a scenario I think we'd prefer to reject.
Is it okay to ignore the checkpatch.pl warning in this case?
thanks,
-jane
On 06/04/2017 04:46 PM, David Miller wrote:
From: Jane Chu <jane@oracle.com>
Date: Thu, 1 Jun 2017 15:39:13 -0600
diff --git a/arch/sparc/ke
t;4096
but num_possible_cpus() < 4096 -- a scenario I think we'd prefer to reject.
Is it okay to ignore the checkpatch.pl warning in this case?
thanks,
-jane
On 06/04/2017 04:46 PM, David Miller wrote:
From: Jane Chu
Date: Thu, 1 Jun 2017 15:39:13 -0600
diff --git a/arch/sparc/kernel/irq_64.c b/arch/spa
Hi, David,
On 06/04/2017 04:46 PM, David Miller wrote:
From: Jane Chu <jane@oracle.com>
Date: Thu, 1 Jun 2017 15:39:13 -0600
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 4d0248a..5b19108 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/
Hi, David,
On 06/04/2017 04:46 PM, David Miller wrote:
From: Jane Chu
Date: Thu, 1 Jun 2017 15:39:13 -0600
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 4d0248a..5b19108 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -1034,12
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu <jane@oracle.com>
Reviewed-by: Bob Picco <bob.pi...@oracle.com>
Reviewed-by:
cpu_list_pa and cpu_mondo_block_pa
are not used in asm code, there are no imm13 offsets from the base PA
that will break because they can only reach one page.
Orabug: 25505750
Signed-off-by: Jane Chu
Reviewed-by: Bob Picco
Reviewed-by: Atish Patra
---
arch/sparc/Kconfig |4
SPARC M6-32 platform has (2^5) NUMA nodes, so need to bump up the
CONFIG_NODES_SHIFT to 5.
Orabug: 25577754
Signed-off-by: Jane Chu <jane@oracle.com>
Reviewed-by: Bob Picco <bob.pi...@oracle.com>
Reviewed-by: Atish Patra <atish.pa...@oracle.com>
---
arch/sparc/Kconfig
SPARC M6-32 platform has (2^5) NUMA nodes, so need to bump up the
CONFIG_NODES_SHIFT to 5.
Orabug: 25577754
Signed-off-by: Jane Chu
Reviewed-by: Bob Picco
Reviewed-by: Atish Patra
---
arch/sparc/Kconfig |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch
101 - 125 of 125 matches
Mail list logo
