Haren Myneni wrote:
>
> System gets checkstop if RxFIFO overruns with more requests than the
> maximum possible number of CRBs in FIFO at the same time. The max number
> of requests per window is controlled by window credits. So find max
> CRBs from FIFO size and set it to receive window credi
"Naveen N. Rao" writes:
> The recent change enabling HAVE_C_RECORDMCOUNT on powerpc started
> showing the following issue:
>
> # modprobe kprobe_example
>ftrace-powerpc: Not expected bl: opcode is 3c4c0001
>WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001
> ftrace_bug+0x90/0x318
>
Mainly this produces better information about what's happening with
the device tree as a result of LPM or PRRN.
Nathan Lynch (2):
powerpc/pseries/mobility: set pr_fmt
powerpc/pseries/mobility: add pr_debug for device tree changes
arch/powerpc/platforms/pseries/mobility.c | 15 +--
The pr_err callsites in mobility.c already manually include a
"mobility:" prefix, let's make it official for the benefit of messages
to be added later.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/mobility.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --g
When investigating issues with partition migration or resource
reassignments it is helpful to have a log of which nodes and
properties in the device tree have changed. Use pr_debug() so it's
easy to enable these at runtime with the dynamic debug facility.
Signed-off-by: Nathan Lynch
---
arch/pow
While reviewing lockdown patches, I discovered that we still enable
/dev/port (CONFIG_DEVPORT) in skiroot.
We don't need it. Deselect CONFIG_DEVPORT for skiroot.
Signed-off-by: Daniel Axtens
---
arch/powerpc/configs/skiroot_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powe
This can catch cases where the device tree has gotten mishandled into
an inconsistent state at runtime, e.g. the cache nodes for both the
source and the destination are present after a migration.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/cacheinfo.c | 9 +
1 file changed, 9 ins
If we have a bug which causes us to start with the wrong kind of OF
node when linking up the cache tree, it's helpful for debugging to
print information about what we found vs what we expected. So replace
uses of WARN_ON_ONCE with WARN_ONCE, which lets us include an
informative message instead of a
A few changes that would have aided debugging this code's interactions
with partition migration, maybe they'll help with the next thing
(hibernation?).
Nathan Lynch (4):
powerpc/cacheinfo: set pr_fmt
powerpc/cacheinfo: name@unit instead of full DT path in debug messages
powerpc/cacheinfo: im
Set pr_fmt so we get a nice prefix on messages.
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/cacheinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 42c559efe060..295af19e00f0 100644
--- a/arch/powerpc/kerne
We know that every OF node we deal with in this code is under /cpus,
so we can make the debug messages a little less verbose without losing
information.
E.g.
cacheinfo: creating L1 dcache and icache for /cpus/PowerPC,POWER8@0
cacheinfo: creating L2 ucache for /cpus/l2-cache@2006
cacheinfo: creati
Juliet Kim writes:
> On 6/25/19 1:51 PM, Nathan Lynch wrote:
>> Juliet Kim writes:
>>
>>> There's some concern this could retry forever, resulting in live lock.
>> First of all the system will make progress in other areas even if there
>> are repeated retries; we're not indefinitely holding locks
Anshuman Khandual writes:
> Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
> provide arch_ioremap_p4d_supported() failing which will result in a build
> failure like the following.
>
> ld: lib/ioremap.o: in function `.ioremap_huge_init':
> ioremap.c:(.init.text+0x3c): un
On 06/26/2019 01:21 PM, Anshuman Khandual wrote:
Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
provide arch_ioremap_p4d_supported() failing which will result in a build
failure like the following.
ld: lib/ioremap.o: in function `.ioremap_huge_init':
ioremap.c:(.ini
Bharata B Rao writes:
> We hit the following BUG_ON when memory hotplugged before reboot
> is unplugged after reboot:
>
> kernel BUG at arch/powerpc/mm/pgtable-frag.c:113!
>
> remove_pagetable+0x594/0x6a0
> (unreliable)
> remove_pagetable+0x94/0x6a0
> vmemmap_free+0x394/0x410
> sparse_remove
On Thu, Jun 27, 2019 at 12:58 PM Aneesh Kumar K.V
wrote:
>
> "Oliver O'Halloran" writes:
>
> >> > + rc = drc_pmem_bind(p);
> >> > + }
> >> > +
> >> > if (rc)
> >> > goto err;
> >> >
> >>
> >> I am also not sure about the module reference count here. Should we
>
"Oliver O'Halloran" writes:
> As I said in the comments on v1, do we have any actual numbers on how
> long the bind step takes? From memory, you could bind ~32GB in a
> single bind h-call before phyp would hit it's time limit of 250us and
> return a continue token. Assuming that holds we'll be s
Hi Bjorn,
> -Original Message-
> From: Bjorn Helgaas
> Sent: 2019年6月27日 1:52
> To: Xiaowei Bao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> a...@arndb.de; gre...@linuxfoundation.org; M.h. Lian
> ; Mingkai Hu ;
On Thu, Jun 27, 2019 at 2:58 AM Aneesh Kumar K.V
wrote:
>
> Vaibhav Jain writes:
> > *snip*
> > + /* If phyp says drc memory still bound then force unbound and retry */
> > + if (rc == -EBUSY) {
> > + dev_warn(&pdev->dev, "Retrying bind after unbinding\n");
> > + d
On Thu, Jun 27, 2019 at 2:53 AM Aneesh Kumar K.V
wrote:
>
> Vaibhav Jain writes:
>
> > Update the hvcalls.h to include op-codes for new hcalls introduce to
> > manage SCM memory. Also update existing hcall definitions to reflect
> > current papr specification for SCM.
> >
> > Signed-off-by: Vaibh
From: Thomas Falcon
[ Upstream commit be32a24372cf162e825332da1a7ccef058d4f20b ]
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon
Signed-off-b
From: Thomas Falcon
[ Upstream commit 7c940b1a5291e5069d561f5b8f0e51db6b7a259a ]
The return values for these memory allocations are unchecked,
which may cause an oops if the driver does not handle them after
a failure. Fix by checking the function's return code.
Signed-off-by: Thomas Falcon
Si
From: Thomas Falcon
[ Upstream commit be32a24372cf162e825332da1a7ccef058d4f20b ]
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon
Signed-off-b
From: Thomas Falcon
[ Upstream commit 1f94608b0ce141be5286dde31270590bdf35b86a ]
Check driver state before halting it during a reset. If the driver is
not running, do nothing. Otherwise, a request to deactivate a down link
can cause an error and the reset will fail.
Signed-off-by: Thomas Falcon
From: Christoph Hellwig
[ Upstream commit 9739ab7eda459f0669ec9807e0d9be5020bab88c ]
With the strict dma mask checking introduced with the switch to
the generic DMA direct code common wifi chips on 32-bit powerbooks
stopped working. Add a 30-bit ZONE_DMA to the 32-bit pmac builds
to allow them
From: Thomas Falcon
[ Upstream commit 7c940b1a5291e5069d561f5b8f0e51db6b7a259a ]
The return values for these memory allocations are unchecked,
which may cause an oops if the driver does not handle them after
a failure. Fix by checking the function's return code.
Signed-off-by: Thomas Falcon
Si
From: Thomas Falcon
[ Upstream commit be32a24372cf162e825332da1a7ccef058d4f20b ]
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon
Signed-off-b
From: Thomas Falcon
[ Upstream commit 1f94608b0ce141be5286dde31270590bdf35b86a ]
Check driver state before halting it during a reset. If the driver is
not running, do nothing. Otherwise, a request to deactivate a down link
can cause an error and the reset will fail.
Signed-off-by: Thomas Falcon
On Wed, 26 Jun 2019, Christophe Leroy wrote:
> Hi Finn,
>
> On 06/26/2019 02:06 AM, Finn Thain wrote:
> > Hi Christophe,
> >
> > I received a report of a regression between v5.0 and v5.1 which causes
> > the current release to crash during boot with a machine check
> > exception. Please see co
On 26/06/2019 17:49, Christoph Hellwig wrote:
> On Wed, Jun 26, 2019 at 10:44:38AM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 26/06/2019 00:52, Christoph Hellwig wrote:
>>> None of these routines were ever used anywhere in the kernel tree
>>> since they were added to the kernel.
>>
>>
>> So
Hi Anshuman,
On Wed, 26 Jun 2019 18:51:00 +0530 Anshuman Khandual
wrote:
>
> Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
> provide arch_ioremap_p4d_supported() failing which will result in a build
> failure like the following.
>
> ld: lib/ioremap.o: in function `.i
Hi Juliet,
Juliet Kim writes:
> On 6/25/19 12:29 PM, Nathan Lynch wrote:
>> Juliet Kim writes:
>>>
>>> However, that fix failed to notify Hypervisor that the LPM attempted
>>> had been abandoned which results in a system hang.
>
>> It is surprising to me that leaving a migration unterminated wou
Aravinda Prasad writes:
> Calculating the maximum memory based on the number of lmbs
> and lmb size does not account for the RMA region. Hence
> use drmem_lmb_memory_max(), which already accounts for the
> RMA region, to fetch the maximum memory value.
>
> Fixes: 772b039fd9a7: ("powerpc/pseries: E
On 6/25/19 12:29 PM, Nathan Lynch wrote:
> Juliet Kim writes:
>> The commit
>> (“powerpc/rtas: Fix a potential race between CPU-Offline & Migration)
>> attempted to fix a hang in Live Partition Mobility(LPM) by abandoning
>> the LPM attempt if a race between LPM and concurrent CPU offline was
>> d
On 6/25/19 1:51 PM, Nathan Lynch wrote:
> Juliet Kim writes:
>
>> There's some concern this could retry forever, resulting in live lock.
> First of all the system will make progress in other areas even if there
> are repeated retries; we're not indefinitely holding locks or anything
> like that.
The recent change enabling HAVE_C_RECORDMCOUNT on powerpc started
showing the following issue:
# modprobe kprobe_example
ftrace-powerpc: Not expected bl: opcode is 3c4c0001
WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318
Modules linked in:
CPU: 0 PID: 227
If you post another revision for any reason, please change the subject
so it's worded as a command and mentions the new config options, e.g.,
PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
On Wed, Jun 26, 2019 at 07:11:39PM +0800, Xiaowei Bao wrote:
> Compile the EP and
Vaibhav Jain writes:
> In some cases initial bind of scm memory for an lpar can fail if
> previously it wasn't released using a scm-unbind hcall. This situation
> can arise due to panic of the previous kernel or forced lpar
> fadump. In such cases the H_SCM_BIND_MEM return a H_OVERLAP error.
>
>
Vaibhav Jain writes:
> Update the hvcalls.h to include op-codes for new hcalls introduce to
> manage SCM memory. Also update existing hcall definitions to reflect
> current papr specification for SCM.
>
> Signed-off-by: Vaibhav Jain
Why split this as a separate patch? You should fold this to t
Hi Sven,
On 06/25/2019 06:54 PM, Sven Schnelle wrote:
Hi List,
i recently started working on kexec for PA-RISC. While doing so, i figured
that powerpc already has support for reading ELF images inside of the Kernel.
My first attempt was to steal the source code and modify it for PA-RISC, but
it
On Wed, Jun 26, 2019 at 08:48:37AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 25, 2019 at 09:37:22AM -0700, Mark Greer wrote:
> > Yeah, the mpsc driver had lots of ugly cache related hacks because of
> > cache coherency bugs in the early version of the MV64x60 bridge chips
> > that it was embedd
On 6/26/19 7:34 PM, Vaibhav Jain wrote:
The new hcall named H_SCM_UNBIND_ALL has been introduce that can
unbind all or specific scm memory assigned to an lpar. This is
more efficient than using H_SCM_UNBIND_MEM as currently we don't
support partial unbind of scm memory.
Hence this patch proposes
In some cases initial bind of scm memory for an lpar can fail if
previously it wasn't released using a scm-unbind hcall. This situation
can arise due to panic of the previous kernel or forced lpar
fadump. In such cases the H_SCM_BIND_MEM return a H_OVERLAP error.
To mitigate such cases the patch u
Update the hvcalls.h to include op-codes for new hcalls introduce to
manage SCM memory. Also update existing hcall definitions to reflect
current papr specification for SCM.
Signed-off-by: Vaibhav Jain
---
Change-log:
v3:
* Added updated opcode for H_SCM_HEALTH [Oliver]
v2:
* None new patch in
The new hcall named H_SCM_UNBIND_ALL has been introduce that can
unbind all or specific scm memory assigned to an lpar. This is
more efficient than using H_SCM_UNBIND_MEM as currently we don't
support partial unbind of scm memory.
Hence this patch proposes following changes to drc_pmem_unbind():
Presently an error is returned in response to hcall H_SCM_BIND_MEM when a
new kernel boots on lpar via kexec. This prevents papr_scm from registering
drc memory regions with nvdimm. The error reported is of the form below:
"papr_scm ibm,persistent-memory:ibm,pmemory@4412: bind err: -68"
On in
On Thu 02-05-19 09:00:31, Michal Hocko wrote:
> On Wed 01-05-19 15:12:32, Barret Rhoden wrote:
> [...]
> > A more elegant solution may be to avoid registering with sysfs during early
> > boot, or something else entirely. But I figured I'd ask for help at this
> > point. =)
>
> Thanks for the rep
Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
provide arch_ioremap_p4d_supported() failing which will result in a build
failure like the following.
ld: lib/ioremap.o: in function `.ioremap_huge_init':
ioremap.c:(.init.text+0x3c): undefined reference to
`.arch_ioremap_p4
Compile the EP and RC drivers separately with different configuration
options, this looks clearer.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
drivers/pci/controller/dwc/Kconfig | 20 ++--
drivers/pci/controller/dwc/Makefile |3 ++-
2 files changed, 20 insertions(+),
The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1
is 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware,
so set the bar_fixed_64bit with 0x14.
Signed-off-by: Xiaowei Bao
---
v2:
- Replace value 0x14 with a macro.
drivers/pci/controller/dwc/pci-layerscape-ep.c |1
Masami Hiramatsu wrote:
On Tue, 18 Jun 2019 20:17:06 +0530
"Naveen N. Rao" wrote:
With KPROBES_ON_FTRACE, kprobe is allowed to be inserted on instructions
that branch to _mcount (referred to as ftrace location). With
-mprofile-kernel, we now include the preceding 'mflr r0' as being part
of the
Calculating the maximum memory based on the number of lmbs
and lmb size does not account for the RMA region. Hence
use drmem_lmb_memory_max(), which already accounts for the
RMA region, to fetch the maximum memory value.
Fixes: 772b039fd9a7: ("powerpc/pseries: Export maximum memory value")
Signed-
Hi Nick,
On 06/19/2019 03:39 PM, Nicholas Piggin wrote:
Abhishek's on June 19, 2019 7:08 pm:
Hi Nick,
Thanks for the review. Some replies below.
On 06/19/2019 09:53 AM, Nicholas Piggin wrote:
Abhishek Goel's on June 17, 2019 7:56 pm:
Currently, the cpuidle governors determine what idle sta
On Wed, Jun 26, 2019 at 10:44:38AM +1000, Alexey Kardashevskiy wrote:
>
>
> On 26/06/2019 00:52, Christoph Hellwig wrote:
> > None of these routines were ever used anywhere in the kernel tree
> > since they were added to the kernel.
>
>
> So none of my comments has been addressed. Nice.
Which
On 21/05/2019 14:49, Thiago Jung Bauermann wrote:
> From: Ram Pai
>
> Make the Enter-Secure-Mode (ESM) ultravisor call to switch the VM to secure
> mode. Add "svm=" command line option to turn off switching to secure mode.
> Introduce CONFIG_PPC_SVM to control support for secure guests.
>
> S
55 matches
Mail list logo
