* [PATCH] soc/fsl/qbman: Use index when accessing device tree properties
From: Roy Pledge @ 2019-06-27 15:17 UTC (permalink / raw)
To: Leo Li, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Roy Pledge, stable@vger.kernel.org
The index value should be passed to the of_parse_phandle()
function to ensure the correct property is read.
Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
---
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 b/drivers/soc/fsl/qbman/dpaa_sys.c
index 3e0a7f3..0b901a8 100644
--- a/drivers/soc/fsl/qbman/dpaa_sys.c
+++ b/drivers/soc/fsl/qbman/dpaa_sys.c
@@ -49,7 +49,7 @@ int qbman_init_private_mem(struct device *dev, int idx, dma_addr_t *addr,
idx, ret);
return -ENODEV;
}
- mem_node = of_parse_phandle(dev->of_node, "memory-region", 0);
+ mem_node = of_parse_phandle(dev->of_node, "memory-region", idx);
if (mem_node) {
ret = of_property_read_u64(mem_node, "size", &size64);
if (ret) {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel
From: Naveen N. Rao @ 2019-06-27 15:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, Nicholas Piggin, Masami Hiramatsu, linuxppc-dev,
Ingo Molnar
In-Reply-To: <20190627110819.4892780f@gandalf.local.home>
Hi Steven,
Thanks for the review!
Steven Rostedt wrote:
> On Thu, 27 Jun 2019 16:53:52 +0530
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
>> With -mprofile-kernel, gcc emits 'mflr r0', followed by 'bl _mcount' to
>> enable function tracing and profiling. So far, with dynamic ftrace, we
>> used to only patch out the branch to _mcount(). However, mflr is
>> executed by the branch unit that can only execute one per cycle on
>> POWER9 and shared with branches, so it would be nice to avoid it where
>> possible.
>>
>> We cannot simply nop out the mflr either. When enabling function
>> tracing, there can be a race if tracing is enabled when some thread was
>> interrupted after executing a nop'ed out mflr. In this case, the thread
>> would execute the now-patched-in branch to _mcount() without having
>> executed the preceding mflr.
>>
>> To solve this, we now enable function tracing in 2 steps: patch in the
>> mflr instruction, use 'smp_call_function(isync);
>> synchronize_rcu_tasks()' to ensure all existing threads make progress,
>> and then patch in the branch to _mcount(). We override
>> ftrace_replace_code() with a powerpc64 variant for this purpose.
>
> You may want to explain that you do the reverse when patching it out.
> That is, patch out the "bl _mcount" into a nop and then patch out the
> "mflr r0".
Sure. I think we can add:
"When disabling function tracing, we can nop out the two instructions
without need for any synchronization in between, as long as we nop out
the branch to ftrace first. The lone 'mflr r0' is harmless. Finally,
with FTRACE_UPDATE_MODIFY_CALL, no changes are needed since we are
simply changing where the branch to ftrace goes."
> But interesting, I don't see a synchronize_rcu_tasks() call
> there.
We felt we don't need it in this case. We patch the branch to ftrace
with a nop first. Other cpus should see that first. But, now that I
think about it, should we add a memory barrier to ensure the writes get
ordered properly?
>
>
>>
>> Suggested-by: Nicholas Piggin <npiggin@gmail.com>
>> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/kernel/trace/ftrace.c | 258 ++++++++++++++++++++++++++---
>> 1 file changed, 236 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
>> index 517662a56bdc..86c2b50dcaa9 100644
>> --- a/arch/powerpc/kernel/trace/ftrace.c
>> +++ b/arch/powerpc/kernel/trace/ftrace.c
>> @@ -125,7 +125,7 @@ __ftrace_make_nop(struct module *mod,
>> {
>> unsigned long entry, ptr, tramp;
>> unsigned long ip = rec->ip;
>> - unsigned int op, pop;
>> + unsigned int op;
>>
>> /* read where this goes */
>> if (probe_kernel_read(&op, (void *)ip, sizeof(int))) {
>> @@ -160,8 +160,6 @@ __ftrace_make_nop(struct module *mod,
>>
>> #ifdef CONFIG_MPROFILE_KERNEL
>> /* When using -mkernel_profile there is no load to jump over */
>> - pop = PPC_INST_NOP;
>> -
>> if (probe_kernel_read(&op, (void *)(ip - 4), 4)) {
>> pr_err("Fetching instruction at %lx failed.\n", ip - 4);
>> return -EFAULT;
>> @@ -169,26 +167,23 @@ __ftrace_make_nop(struct module *mod,
>>
>> /* We expect either a mflr r0, or a std r0, LRSAVE(r1) */
>> if (op != PPC_INST_MFLR && op != PPC_INST_STD_LR) {
>> - pr_err("Unexpected instruction %08x around bl _mcount\n", op);
>> + pr_err("Unexpected instruction %08x before bl _mcount\n", op);
>> return -EINVAL;
>> }
>> -#else
>> - /*
>> - * Our original call site looks like:
>> - *
>> - * bl <tramp>
>> - * ld r2,XX(r1)
>> - *
>> - * Milton Miller pointed out that we can not simply nop the branch.
>> - * If a task was preempted when calling a trace function, the nops
>> - * will remove the way to restore the TOC in r2 and the r2 TOC will
>> - * get corrupted.
>> - *
>> - * Use a b +8 to jump over the load.
>> - */
>>
>> - pop = PPC_INST_BRANCH | 8; /* b +8 */
>> + /* We should patch out the bl to _mcount first */
>> + if (patch_instruction((unsigned int *)ip, PPC_INST_NOP)) {
>> + pr_err("Patching NOP failed.\n");
>> + return -EPERM;
>> + }
>>
>> + /* then, nop out the preceding 'mflr r0' as an optimization */
>> + if (op == PPC_INST_MFLR &&
>> + patch_instruction((unsigned int *)(ip - 4), PPC_INST_NOP)) {
>> + pr_err("Patching NOP failed.\n");
>> + return -EPERM;
>> + }
>> +#else
>> /*
>> * Check what is in the next instruction. We can see ld r2,40(r1), but
>> * on first pass after boot we will see mflr r0.
>> @@ -202,12 +197,25 @@ __ftrace_make_nop(struct module *mod,
>> pr_err("Expected %08x found %08x\n", PPC_INST_LD_TOC, op);
>> return -EINVAL;
>> }
>> -#endif /* CONFIG_MPROFILE_KERNEL */
>>
>> - if (patch_instruction((unsigned int *)ip, pop)) {
>> + /*
>> + * Our original call site looks like:
>> + *
>> + * bl <tramp>
>> + * ld r2,XX(r1)
>> + *
>> + * Milton Miller pointed out that we can not simply nop the branch.
>> + * If a task was preempted when calling a trace function, the nops
>> + * will remove the way to restore the TOC in r2 and the r2 TOC will
>> + * get corrupted.
>> + *
>> + * Use a b +8 to jump over the load.
>> + */
>> + if (patch_instruction((unsigned int *)ip, PPC_INST_BRANCH | 8)) {
>> pr_err("Patching NOP failed.\n");
>> return -EPERM;
>> }
>> +#endif /* CONFIG_MPROFILE_KERNEL */
>>
>> return 0;
>> }
>> @@ -421,6 +429,26 @@ static int __ftrace_make_nop_kernel(struct dyn_ftrace *rec, unsigned long addr)
>> return -EPERM;
>> }
>>
>> +#ifdef CONFIG_MPROFILE_KERNEL
>
> I would think you need to break this up into two parts as well, with a
> synchronize_rcu_tasks() in between.
>
> Imagine this scenario:
>
> <func>:
> nop <-- interrupt comes here, and preempts the task
> nop
>
> First change.
>
> <func>:
> mflr r0
> nop
>
> Second change.
>
> <func>:
> mflr r0
> bl _mcount
>
> Task returns from interrupt
>
> <func>:
> mflr r0
> bl _mcount <-- executes here
>
> It never did the mflr r0, because the last command that was executed
> was a nop before it was interrupted. And yes, it can be interrupted
> on a nop!
We are handling this through ftrace_replace_code() and
__ftrace_make_call_prep() below. For FTRACE_UPDATE_MAKE_CALL, we patch
in the mflr, followed by smp_call_function(isync) and
synchronize_rcu_tasks() before we proceed to patch the branch to ftrace.
I don't see any other scenario where we end up in
__ftrace_make_nop_kernel() without going through ftrace_replace_code().
For kernel modules, this can happen during module load/init and so, I
patch out both instructions in __ftrace_make_call() above without any
synchronization.
Am I missing anything?
Thanks,
Naveen
>
> -- Steve
>
>
>> + /* Nop out the preceding 'mflr r0' as an optimization */
>> + if (probe_kernel_read(&op, (void *)(ip - 4), 4)) {
>> + pr_err("Fetching instruction at %lx failed.\n", ip - 4);
>> + return -EFAULT;
>> + }
>> +
>> + /* We expect either a mflr r0, or a std r0, LRSAVE(r1) */
>> + if (op != PPC_INST_MFLR && op != PPC_INST_STD_LR) {
>> + pr_err("Unexpected instruction %08x before bl _mcount\n", op);
>> + return -EINVAL;
>> + }
>> +
>> + if (op == PPC_INST_MFLR &&
>> + patch_instruction((unsigned int *)(ip - 4), PPC_INST_NOP)) {
>> + pr_err("Patching NOP failed.\n");
>> + return -EPERM;
>> + }
>> +#endif
>> +
>> return 0;
>> }
>>
>> @@ -429,6 +457,7 @@ int ftrace_make_nop(struct module *mod,
>> {
>> unsigned long ip = rec->ip;
>> unsigned int old, new;
>> + int rc;
>>
>> /*
>> * If the calling address is more that 24 bits away,
>> @@ -439,7 +468,34 @@ int ftrace_make_nop(struct module *mod,
>> /* within range */
>> old = ftrace_call_replace(ip, addr, 1);
>> new = PPC_INST_NOP;
>> - return ftrace_modify_code(ip, old, new);
>> + rc = ftrace_modify_code(ip, old, new);
>> +#ifdef CONFIG_MPROFILE_KERNEL
>> + if (rc)
>> + return rc;
>> +
>> + /*
>> + * For -mprofile-kernel, we patch out the preceding 'mflr r0'
>> + * instruction, as an optimization. It is important to nop out
>> + * the branch to _mcount() first, as a lone 'mflr r0' is
>> + * harmless.
>> + */
>> + if (probe_kernel_read(&old, (void *)(ip - 4), 4)) {
>> + pr_err("Fetching instruction at %lx failed.\n", ip - 4);
>> + return -EFAULT;
>> + }
>> +
>> + /* We expect either a mflr r0, or a std r0, LRSAVE(r1) */
>> + if (old != PPC_INST_MFLR && old != PPC_INST_STD_LR) {
>> + pr_err("Unexpected instruction %08x before bl _mcount\n",
>> + old);
>> + return -EINVAL;
>> + }
>> +
>> + if (old == PPC_INST_MFLR)
>> + rc = patch_instruction((unsigned int *)(ip - 4),
>> + PPC_INST_NOP);
>> +#endif
>> + return rc;
>> } else if (core_kernel_text(ip))
>> return __ftrace_make_nop_kernel(rec, addr);
>>
>> @@ -567,6 +623,37 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
>> return -EINVAL;
>> }
>>
>> +#ifdef CONFIG_MPROFILE_KERNEL
>> + /*
>> + * We could end up here without having called __ftrace_make_call_prep()
>> + * if function tracing is enabled before a module is loaded.
>> + *
>> + * ftrace_module_enable() --> ftrace_replace_code_rec() -->
>> + * ftrace_make_call() --> __ftrace_make_call()
>> + *
>> + * In this scenario, the previous instruction will be a NOP. It is
>> + * safe to patch it with a 'mflr r0' since we know for a fact that
>> + * this code is not yet being run.
>> + */
>> + ip -= MCOUNT_INSN_SIZE;
>> +
>> + /* read where this goes */
>> + if (probe_kernel_read(op, ip, MCOUNT_INSN_SIZE))
>> + return -EFAULT;
>> +
>> + /*
>> + * nothing to do if this is using the older -mprofile-kernel
>> + * instruction sequence
>> + */
>> + if (op[0] != PPC_INST_NOP)
>> + return 0;
>> +
>> + if (patch_instruction((unsigned int *)ip, PPC_INST_MFLR)) {
>> + pr_err("Patching MFLR failed.\n");
>> + return -EPERM;
>> + }
>> +#endif
>> +
>> return 0;
>> }
>>
>> @@ -863,6 +950,133 @@ void arch_ftrace_update_code(int command)
>> ftrace_modify_all_code(command);
>> }
>>
>> +#ifdef CONFIG_MPROFILE_KERNEL
>> +/* Returns 1 if we patched in the mflr */
>> +static int __ftrace_make_call_prep(struct dyn_ftrace *rec)
>> +{
>> + void *ip = (void *)rec->ip - MCOUNT_INSN_SIZE;
>> + unsigned int op[2];
>> +
>> + /* read where this goes */
>> + if (probe_kernel_read(op, ip, sizeof(op)))
>> + return -EFAULT;
>> +
>> + if (op[1] != PPC_INST_NOP) {
>> + pr_err("Unexpected call sequence at %p: %x %x\n",
>> + ip, op[0], op[1]);
>> + return -EINVAL;
>> + }
>> +
>> + /*
>> + * nothing to do if this is using the older -mprofile-kernel
>> + * instruction sequence
>> + */
>> + if (op[0] != PPC_INST_NOP)
>> + return 0;
>> +
>> + if (patch_instruction((unsigned int *)ip, PPC_INST_MFLR)) {
>> + pr_err("Patching MFLR failed.\n");
>> + return -EPERM;
>> + }
>> +
>> + return 1;
>> +}
>> +
>> +static void do_isync(void *info __maybe_unused)
>> +{
>> + isync();
>> +}
>> +
>> +/*
>> + * When enabling function tracing for -mprofile-kernel that uses a
>> + * 2-instruction sequence of 'mflr r0, bl _mcount()', we use a 2 step process:
>> + * 1. Patch in the 'mflr r0' instruction
>> + * 1a. flush icache on all cpus, so that the updated instruction is seen
>> + * 1b. synchronize_rcu_tasks() to ensure that any cpus that had executed
>> + * the earlier nop there make progress (and hence do not branch into
>> + * ftrace without executing the preceding mflr)
>> + * 2. Patch in the branch to ftrace
>> + */
>> +void ftrace_replace_code(int mod_flags)
>> +{
>> + int enable = mod_flags & FTRACE_MODIFY_ENABLE_FL;
>> + int schedulable = mod_flags & FTRACE_MODIFY_MAY_SLEEP_FL;
>> + int ret, failed, make_call = 0;
>> + struct ftrace_rec_iter *iter;
>> + struct dyn_ftrace *rec;
>> +
>> + if (unlikely(!ftrace_enabled))
>> + return;
>> +
>> + for_ftrace_rec_iter(iter) {
>> + rec = ftrace_rec_iter_record(iter);
>> +
>> + if (rec->flags & FTRACE_FL_DISABLED)
>> + continue;
>> +
>> + failed = 0;
>> + ret = ftrace_test_record(rec, enable);
>> + if (ret == FTRACE_UPDATE_MAKE_CALL) {
>> + failed = __ftrace_make_call_prep(rec);
>> + if (failed < 0) {
>> + ftrace_bug(failed, rec);
>> + return;
>> + } else if (failed == 1)
>> + make_call++;
>> + }
>> +
>> + if (!failed) {
>> + /* We can patch the record directly */
>> + failed = ftrace_replace_code_rec(rec, enable);
>> + if (failed) {
>> + ftrace_bug(failed, rec);
>> + return;
>> + }
>> + }
>> +
>> + if (schedulable)
>> + cond_resched();
>> + }
>> +
>> + if (!make_call)
>> + /* No records needed patching a preceding mflr */
>> + return;
>> +
>> + /* Make sure all cpus see the new instruction */
>> + smp_call_function(do_isync, NULL, 1);
>> +
>> + /*
>> + * We also need to ensure that all cpus make progress:
>> + * - With !CONFIG_PREEMPT, we want to be sure that cpus return from
>> + * any interrupts they may be handling, and make progress.
>> + * - With CONFIG_PREEMPT, we want to be additionally sure that there
>> + * are no pre-empted tasks that have executed the earlier nop, and
>> + * might end up executing the subsequently patched branch to ftrace.
>> + */
>> + synchronize_rcu_tasks();
>> +
>> + for_ftrace_rec_iter(iter) {
>> + rec = ftrace_rec_iter_record(iter);
>> +
>> + if (rec->flags & FTRACE_FL_DISABLED)
>> + continue;
>> +
>> + ret = ftrace_test_record(rec, enable);
>> + if (ret == FTRACE_UPDATE_MAKE_CALL)
>> + failed = ftrace_replace_code_rec(rec, enable);
>> +
>> + if (failed) {
>> + ftrace_bug(failed, rec);
>> + return;
>> + }
>> +
>> + if (schedulable)
>> + cond_resched();
>> + }
>> +
>> +}
>> +#endif
>> +
>> #ifdef CONFIG_PPC64
>> #define PACATOC offsetof(struct paca_struct, kernel_toc)
>>
>
>
^ permalink raw reply
* Re: [PATCH v2 4/7] powerpc/ftrace: Additionally nop out the preceding mflr with -mprofile-kernel
From: Steven Rostedt @ 2019-06-27 16:13 UTC (permalink / raw)
To: Naveen N. Rao
Cc: linux-kernel, Nicholas Piggin, Masami Hiramatsu, linuxppc-dev,
Ingo Molnar
In-Reply-To: <1561648598.uvetvkj39x.naveen@linux.ibm.com>
On Thu, 27 Jun 2019 20:58:20 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
>
> > But interesting, I don't see a synchronize_rcu_tasks() call
> > there.
>
> We felt we don't need it in this case. We patch the branch to ftrace
> with a nop first. Other cpus should see that first. But, now that I
> think about it, should we add a memory barrier to ensure the writes get
> ordered properly?
Do you send an ipi to the other CPUs. I would just to be safe.
> >> - if (patch_instruction((unsigned int *)ip, pop)) {
> >> + /*
> >> + * Our original call site looks like:
> >> + *
> >> + * bl <tramp>
> >> + * ld r2,XX(r1)
> >> + *
> >> + * Milton Miller pointed out that we can not simply nop the branch.
> >> + * If a task was preempted when calling a trace function, the nops
> >> + * will remove the way to restore the TOC in r2 and the r2 TOC will
> >> + * get corrupted.
> >> + *
> >> + * Use a b +8 to jump over the load.
> >> + */
> >> + if (patch_instruction((unsigned int *)ip, PPC_INST_BRANCH | 8)) {
> >> pr_err("Patching NOP failed.\n");
> >> return -EPERM;
> >> }
> >> +#endif /* CONFIG_MPROFILE_KERNEL */
> >>
> >> return 0;
> >> }
> >> @@ -421,6 +429,26 @@ static int __ftrace_make_nop_kernel(struct dyn_ftrace *rec, unsigned long addr)
> >> return -EPERM;
> >> }
> >>
> >> +#ifdef CONFIG_MPROFILE_KERNEL
> >
> > I would think you need to break this up into two parts as well, with a
> > synchronize_rcu_tasks() in between.
> >
> > Imagine this scenario:
> >
> > <func>:
> > nop <-- interrupt comes here, and preempts the task
> > nop
> >
> > First change.
> >
> > <func>:
> > mflr r0
> > nop
> >
> > Second change.
> >
> > <func>:
> > mflr r0
> > bl _mcount
> >
> > Task returns from interrupt
> >
> > <func>:
> > mflr r0
> > bl _mcount <-- executes here
> >
> > It never did the mflr r0, because the last command that was executed
> > was a nop before it was interrupted. And yes, it can be interrupted
> > on a nop!
>
> We are handling this through ftrace_replace_code() and
> __ftrace_make_call_prep() below. For FTRACE_UPDATE_MAKE_CALL, we patch
> in the mflr, followed by smp_call_function(isync) and
> synchronize_rcu_tasks() before we proceed to patch the branch to ftrace.
>
> I don't see any other scenario where we end up in
> __ftrace_make_nop_kernel() without going through ftrace_replace_code().
> For kernel modules, this can happen during module load/init and so, I
> patch out both instructions in __ftrace_make_call() above without any
> synchronization.
>
> Am I missing anything?
>
No, I think I got confused ;-), it's the patch out that I was worried
about, but when I was going through the scenario, I somehow turned it
into the patching in (which I already audited :-p). I was going to
reply with just the top part of this email, but then the confusion
started :-/
OK, yes, patching out should be fine, and you already covered the
patching in. Sorry for the noise.
Just to confirm and totally remove the confusion, the patch does:
<func>:
mflr r0 <-- preempt here
bl _mcount
<func>:
mflr r0
nop
And this is fine regardless.
OK, Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [PATCH 3/4] powerpc/powernv: remove unused NPU DMA code
From: Greg Kroah-Hartman @ 2019-06-27 16:51 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, Oliver O'Halloran, Frederic Barrat,
Paul Mackerras, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20190627072240.GA9916@lst.de>
On Thu, Jun 27, 2019 at 09:22:40AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 27, 2019 at 10:21:55AM +1000, Alexey Kardashevskiy wrote:
> > > Which comment? Last time I asked you complaint "it is still used in
> > > exactly the same way as before" which you later clarified that you
> > > have a hidden out of tree user somewhere, and you only objected to
> >
> > It is not hidden, anyone can download and inspect that GPL driver.
>
> For one no one has ever posted a link. And second as mentioned
> countless times it doesn't matter, it only matters if it is in mainline,
> or as a special exception actively trying to go mainline.
>
> > > the word "dead". That has been fixed and there were no further
> > > comments.
> >
> > You still have it in the cover letter so at very least 3/4 is not a part
> > of this patchset then.
> >
> > And I still want to see a formal statement about out-of-tree drivers
> > support/tolerance. If you manage to remove this code, I'll have to post
> > a revert (again and again) but I would rather know the exact list of
> > what we do and what we do not do about such drivers and if the list 1)
> > exists 2) is reasonable then I could try to come up with a better
> > solution or point others to the policy and push them to do the right
> > thing. Right now it is just you pretending that the nVidia driver does
> > not exist, this is not helping. Thanks,
>
> We had that discussion at kernel summit and it was reported. Anyway,
> adding Greg, who usually has some pretty good prewritten letters for
> this kind of thing.
I used to have one but it's been so long since anyone tried to even
think about defending the removal of functions that are not used in the
kernel tree anymore, that I can't seem to find it anymore :)
Christoph is completely correct here, if it isn't in the tree, it
doesn't matter. We have made this "formal" statement again and again
over the years, starting with the old "stable api nonsense" document
that is in the kernel tree itself.
And he is also correct in that we talked about this specific issue, in
detail, at the maintainers summit last year, see lwn.net for the details
if you somehow missed it then.
thanks,
greg k-h
^ permalink raw reply
* [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Thomas Falcon @ 2019-06-27 17:09 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon, linuxppc-dev, bjking1, dnbanerg
This patch resolves an issue with sensitive bonding modes
that require valid speed and duplex settings to function
properly. Currently, the adapter will report that device
speed and duplex is unknown if the communication link
with firmware is unavailable. This decision can break LACP
configurations if the timing is right.
For example, if invalid speeds are reported, the slave
device's link state is set to a transitional "fail" state
and the LACP port is disabled. However, if valid speeds
are reported later but the link state has not been altered,
the LACP port will remain disabled. If the link state then
transitions back to "up" from "fail," it results in a state
such that the slave reports valid speed/duplex and is up,
but the LACP port will remain disabled.
Workaround this by reporting the last recorded speed
and duplex settings unless the device has never been
activated. In that case or when the hypervisor gives
invalid values, continue to report unknown speed or
duplex to ethtool.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 3da6800..7c14e33 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2276,10 +2276,8 @@ static int ibmvnic_get_link_ksettings(struct net_device *netdev,
int rc;
rc = send_query_phys_parms(adapter);
- if (rc) {
- adapter->speed = SPEED_UNKNOWN;
- adapter->duplex = DUPLEX_UNKNOWN;
- }
+ if (rc)
+ netdev_warn(netdev, "Device query of current speed and duplex settings failed; reported values may be stale.\n");
cmd->base.speed = adapter->speed;
cmd->base.duplex = adapter->duplex;
cmd->base.port = PORT_FIBRE;
@@ -4834,6 +4832,8 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
dev_set_drvdata(&dev->dev, netdev);
adapter->vdev = dev;
adapter->netdev = netdev;
+ adapter->speed = SPEED_UNKNOWN;
+ adapter->duplex = DUPLEX_UNKNOWN;
ether_addr_copy(adapter->mac_addr, mac_addr_p);
ether_addr_copy(netdev->dev_addr, adapter->mac_addr);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Andrew Lunn @ 2019-06-27 17:57 UTC (permalink / raw)
To: Thomas Falcon; +Cc: netdev, linuxppc-dev, bjking1, dnbanerg
In-Reply-To: <1561655353-17114-1-git-send-email-tlfalcon@linux.ibm.com>
On Thu, Jun 27, 2019 at 12:09:13PM -0500, Thomas Falcon wrote:
> This patch resolves an issue with sensitive bonding modes
> that require valid speed and duplex settings to function
> properly. Currently, the adapter will report that device
> speed and duplex is unknown if the communication link
> with firmware is unavailable.
Dumb question. If you cannot communicate with the firmware, isn't the
device FUBAR? So setting the LACP port to disabled is the correct
things to do.
Andrew
^ permalink raw reply
* Re: [PATCH v2] PCI: rpaphp: Avoid a sometimes-uninitialized warning
From: Nathan Chancellor @ 2019-06-27 19:18 UTC (permalink / raw)
To: Tyrel Datwyler, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linux-pci, Nick Desaulniers, linux-kernel, clang-built-linux,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <20190603221157.58502-1-natechancellor@gmail.com>
On Mon, Jun 03, 2019 at 03:11:58PM -0700, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
> if (fndit)
> ^~~~~
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
> for (j = 0; j < entries; j++) {
> ^~~~~~~~~~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
> int j, fndit;
> ^
> = 0
>
> fndit is only used to gate a sprintf call, which can be moved into the
> loop to simplify the code and eliminate the local variable, which will
> fix this warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info property")
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v1 -> v2:
>
> * Eliminate fndit altogether by shuffling the sprintf call into the for
> loop and changing the if conditional, as suggested by Nick.
>
> drivers/pci/hotplug/rpaphp_core.c | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/hotplug/rpaphp_core.c b/drivers/pci/hotplug/rpaphp_core.c
> index bcd5d357ca23..c3899ee1db99 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct device_node *dn, char *drc_name,
> struct of_drc_info drc;
> const __be32 *value;
> char cell_drc_name[MAX_DRC_NAME_LEN];
> - int j, fndit;
> + int j;
>
> info = of_find_property(dn->parent, "ibm,drc-info", NULL);
> if (info == NULL)
> @@ -245,17 +245,13 @@ static int rpaphp_check_drc_props_v2(struct device_node *dn, char *drc_name,
>
> /* Should now know end of current entry */
>
> - if (my_index > drc.last_drc_index)
> - continue;
> -
> - fndit = 1;
> - break;
> + /* Found it */
> + if (my_index <= drc.last_drc_index) {
> + sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
> + my_index);
> + break;
> + }
> }
> - /* Found it */
> -
> - if (fndit)
> - sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
> - my_index);
>
> if (((drc_name == NULL) ||
> (drc_name && !strcmp(drc_name, cell_drc_name))) &&
> --
> 2.22.0.rc3
>
Gentle ping, can someone pick this up?
Cheers,
Nathan
^ permalink raw reply
* [PATCH 1/2] powerpc: reserve memory for capture kernel after hugepages init
From: Hari Bathini @ 2019-06-27 19:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mahesh J Salgaonkar, Ananth N Mavinakayanahalli
Sometimes, memory reservation for KDump/FADump can overlap with memory
marked for hugepages. This overlap leads to error, hang in KDump case
and copy error reported by f/w in case of FADump, while trying to
capture dump. Report error while setting up memory for the capture
kernel instead of running into issues while capturing dump, by moving
KDump/FADump reservation below MMU early init and failing gracefully
when hugepages memory overlaps with capture kernel memory.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/kernel/prom.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 7159e79..454e19cf 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -731,14 +731,6 @@ void __init early_init_devtree(void *params)
if (PHYSICAL_START > MEMORY_START)
memblock_reserve(MEMORY_START, 0x8000);
reserve_kdump_trampoline();
-#ifdef CONFIG_FA_DUMP
- /*
- * If we fail to reserve memory for firmware-assisted dump then
- * fallback to kexec based kdump.
- */
- if (fadump_reserve_mem() == 0)
-#endif
- reserve_crashkernel();
early_reserve_mem();
/* Ensure that total memory size is page-aligned. */
@@ -777,6 +769,14 @@ void __init early_init_devtree(void *params)
#endif
mmu_early_init_devtree();
+#ifdef CONFIG_FA_DUMP
+ /*
+ * If we fail to reserve memory for firmware-assisted dump then
+ * fallback to kexec based kdump.
+ */
+ if (fadump_reserve_mem() == 0)
+#endif
+ reserve_crashkernel();
#ifdef CONFIG_PPC_POWERNV
/* Scan and build the list of machine check recoverable ranges */
^ permalink raw reply related
* [PATCH 2/2] powerpc: avoid adjusting memory_limit for capture kernel memory reservation
From: Hari Bathini @ 2019-06-27 19:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mahesh J Salgaonkar, Ananth N Mavinakayanahalli
In-Reply-To: <156166326909.13320.3330203549978146193.stgit@hbathini.in.ibm.com>
Currently, if memory_limit is specified and it overlaps with memory to
be reserved for capture kernel, memory_limit is adjusted to accommodate
capture kernel. With memory reservation for capture kernel moved later
(after enforcing memory limit), this adjustment no longer holds water.
So, avoid adjusting memory_limit and error out instead.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/kernel/fadump.c | 16 ----------------
arch/powerpc/kernel/machine_kexec.c | 22 +++++++++++-----------
2 files changed, 11 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab972..a784695 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -476,22 +476,6 @@ int __init fadump_reserve_mem(void)
#endif
}
- /*
- * Calculate the memory boundary.
- * If memory_limit is less than actual memory boundary then reserve
- * the memory for fadump beyond the memory_limit and adjust the
- * memory_limit accordingly, so that the running kernel can run with
- * specified memory_limit.
- */
- if (memory_limit && memory_limit < memblock_end_of_DRAM()) {
- size = get_fadump_area_size();
- if ((memory_limit + size) < memblock_end_of_DRAM())
- memory_limit += size;
- else
- memory_limit = memblock_end_of_DRAM();
- printk(KERN_INFO "Adjusted memory_limit for firmware-assisted"
- " dump, now %#016llx\n", memory_limit);
- }
if (memory_limit)
memory_boundary = memory_limit;
else
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index c4ed328..fc5533b 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -125,10 +125,8 @@ void __init reserve_crashkernel(void)
crashk_res.end = crash_base + crash_size - 1;
}
- if (crashk_res.end == crashk_res.start) {
- crashk_res.start = crashk_res.end = 0;
- return;
- }
+ if (crashk_res.end == crashk_res.start)
+ goto error_out;
/* We might have got these values via the command line or the
* device tree, either way sanitise them now. */
@@ -170,15 +168,13 @@ void __init reserve_crashkernel(void)
if (overlaps_crashkernel(__pa(_stext), _end - _stext)) {
printk(KERN_WARNING
"Crash kernel can not overlap current kernel\n");
- crashk_res.start = crashk_res.end = 0;
- return;
+ goto error_out;
}
/* Crash kernel trumps memory limit */
if (memory_limit && memory_limit <= crashk_res.end) {
- memory_limit = crashk_res.end + 1;
- printk("Adjusted memory limit for crashkernel, now 0x%llx\n",
- memory_limit);
+ pr_err("Crash kernel size can't exceed memory_limit\n");
+ goto error_out;
}
printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
@@ -190,9 +186,13 @@ void __init reserve_crashkernel(void)
if (!memblock_is_region_memory(crashk_res.start, crash_size) ||
memblock_reserve(crashk_res.start, crash_size)) {
pr_err("Failed to reserve memory for crashkernel!\n");
- crashk_res.start = crashk_res.end = 0;
- return;
+ goto error_out;
}
+
+ return;
+error_out:
+ crashk_res.start = crashk_res.end = 0;
+ return;
}
int overlaps_crashkernel(unsigned long start, unsigned long size)
^ permalink raw reply related
* Re: [PATCH v2] powerpc/setup_64: fix -Wempty-body warnings
From: Qian Cai @ 2019-06-27 19:52 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, paulus, tyreld, linux-kernel
In-Reply-To: <1559768018-7665-1-git-send-email-cai@lca.pw>
Ping.
On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
> arch/powerpc/kernel/setup_64.c: In function 'initialize_cache_info':
> arch/powerpc/kernel/setup_64.c:579:49: warning: suggest braces around
> empty body in an 'if' statement [-Wempty-body]
> DBG("Argh, can't find dcache properties !\n");
> ^
> arch/powerpc/kernel/setup_64.c:582:49: warning: suggest braces around
> empty body in an 'if' statement [-Wempty-body]
> DBG("Argh, can't find icache properties !\n");
>
> Suggested-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
>
> v2: fix it by using a NOP while loop.
>
> arch/powerpc/kernel/setup_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 44b4c432a273..bed4ae8d338c 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -71,7 +71,7 @@
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> -#define DBG(fmt...)
> +#define DBG(fmt...) do { } while (0)
> #endif
>
> int spinning_secondaries;
^ permalink raw reply
* Re: [PATCH] powerpc/cacheflush: fix variable set but not used
From: Qian Cai @ 2019-06-27 19:54 UTC (permalink / raw)
To: mpe; +Cc: akpm, paulus, linuxppc-dev, linux-kernel
In-Reply-To: <1559829493-28457-1-git-send-email-cai@lca.pw>
Ping.
On Thu, 2019-06-06 at 09:58 -0400, Qian Cai wrote:
> The powerpc's flush_cache_vmap() is defined as a macro and never use
> both of its arguments, so it will generate a compilation warning,
>
> lib/ioremap.c: In function 'ioremap_page_range':
> lib/ioremap.c:203:16: warning: variable 'start' set but not used
> [-Wunused-but-set-variable]
>
> Fix it by making it an inline function.
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/include/asm/cacheflush.h | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cacheflush.h
> b/arch/powerpc/include/asm/cacheflush.h
> index 74d60cfe8ce5..fd318f7c3eed 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -29,9 +29,12 @@
> * not expect this type of fault. flush_cache_vmap is not exactly the right
> * place to put this, but it seems to work well enough.
> */
> -#define flush_cache_vmap(start, end) do { asm
> volatile("ptesync" ::: "memory"); } while (0)
> +static inline void flush_cache_vmap(unsigned long start, unsigned long end)
> +{
> + asm volatile("ptesync" ::: "memory");
> +}
> #else
> -#define flush_cache_vmap(start, end) do { } while (0)
> +static inline void flush_cache_vmap(unsigned long start, unsigned long end) {
> }
> #endif
>
> #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
^ permalink raw reply
* Re: [PATCH] powerpc/eeh_cache: fix a W=1 kernel-doc warning
From: Qian Cai @ 2019-06-27 19:55 UTC (permalink / raw)
To: mpe; +Cc: sbobroff, linux-kernel, oohall, paulus, linuxppc-dev
In-Reply-To: <1559767579-7151-1-git-send-email-cai@lca.pw>
Ping.
On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand function
> prototype: 'struct pci_io_addr_range
>
> Since this is not a kernel-doc for the struct below, but rather an
> overview of this source eeh_cache.c, just use the free-form comments
> kernel-doc syntax instead.
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/powerpc/kernel/eeh_cache.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
> index 320472373122..05ffd32b3416 100644
> --- a/arch/powerpc/kernel/eeh_cache.c
> +++ b/arch/powerpc/kernel/eeh_cache.c
> @@ -18,6 +18,8 @@
>
>
> /**
> + * DOC: Overview
> + *
> * The pci address cache subsystem. This subsystem places
> * PCI device address resources into a red-black tree, sorted
> * according to the address range, so that given only an i/o
> @@ -34,6 +36,7 @@
> * than any hash algo I could think of for this problem, even
> * with the penalty of slow pointer chases for d-cache misses).
> */
> +
> struct pci_io_addr_range {
> struct rb_node rb_node;
> resource_size_t addr_lo;
^ permalink raw reply
* Re: [PATCH v2] powerpc/setup_64: fix -Wempty-body warnings
From: Joe Perches @ 2019-06-27 20:08 UTC (permalink / raw)
To: Qian Cai, mpe; +Cc: linuxppc-dev, paulus, tyreld, linux-kernel
In-Reply-To: <1561665166.5154.90.camel@lca.pw>
On Thu, 2019-06-27 at 15:52 -0400, Qian Cai wrote:
> On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> > At the beginning of setup_64.c, it has,
> >
> > #ifdef DEBUG
> > #define DBG(fmt...) udbg_printf(fmt)
> > #else
> > #define DBG(fmt...)
> > #endif
> >
> > where DBG() could be compiled away, and generate warnings,
> >
> > arch/powerpc/kernel/setup_64.c: In function 'initialize_cache_info':
> > arch/powerpc/kernel/setup_64.c:579:49: warning: suggest braces around
> > empty body in an 'if' statement [-Wempty-body]
> > DBG("Argh, can't find dcache properties !\n");
> > ^
> > arch/powerpc/kernel/setup_64.c:582:49: warning: suggest braces around
> > empty body in an 'if' statement [-Wempty-body]
> > DBG("Argh, can't find icache properties !\n");
[]
> > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
[]
> > @@ -71,7 +71,7 @@
> > #ifdef DEBUG
> > #define DBG(fmt...) udbg_printf(fmt)
> > #else
> > -#define DBG(fmt...)
> > +#define DBG(fmt...) do { } while (0)
I suggest
#define DBG(fmt...) do { if (0) udbg_printf(fmt); } while (0)
so that format and argument are always verified by the compiler.
I would also prefer a more generic form using ##__VA_ARGS__
#ifdef DEBUG
#define DBG(fmt, ...) udbg_printf(fmt, ##__VA_ARGS__)
#else
#define DBG(fmt, ...) do { if (0) udbg_printf(fmt, ##__VA_ARGS__); } while (0)
#endif
or maybe use the no_printk macro like
#ifdef DEBUG
#define DBG(fmt, ...) udbg_printf(fmt, ##__VA_ARGS__)
#else
#define DBG(fmt, ...) no_printk(fmt, ##__VA_ARGS__)
#endif
^ permalink raw reply
* Re: [PATCH net] net/ibmvnic: Report last valid speed and duplex values to ethtool
From: Thomas Falcon @ 2019-06-27 20:56 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linuxppc-dev, bjking1, dnbanerg
In-Reply-To: <20190627175715.GP27733@lunn.ch>
On 6/27/19 12:57 PM, Andrew Lunn wrote:
> On Thu, Jun 27, 2019 at 12:09:13PM -0500, Thomas Falcon wrote:
>> This patch resolves an issue with sensitive bonding modes
>> that require valid speed and duplex settings to function
>> properly. Currently, the adapter will report that device
>> speed and duplex is unknown if the communication link
>> with firmware is unavailable.
> Dumb question. If you cannot communicate with the firmware, isn't the
> device FUBAR? So setting the LACP port to disabled is the correct
> things to do.
>
> Andrew
>
Yes, I think that is correct too. The problem is that the link is only
down temporarily. In this case - we are testing with a pseries logical
partition - the partition is migrated to another server. The driver must
wait for a signal from the hypervisor to resume operation with the new
device. Once it resumes, we see that the device reboots and gets
correct speed settings, but the port flag (AD_LACP_PORT_ENABLED) is
still cleared.
Tom
^ permalink raw reply
* power9 NUMA crash while reading debugfs imc_cmd
From: Qian Cai @ 2019-06-27 21:21 UTC (permalink / raw)
To: Aneesh Kumar K.V, Michael Ellerman, Anju T Sudhakar
Cc: linuxppc-dev, linux-kernel
Read of debugfs imc_cmd file for a memory-less node will trigger a crash below
on this power9 machine which has the following NUMA layout. I don't understand
why I only saw it recently on linux-next where it was tested everyday. I can
reproduce it back to 4.20 where 4.18 seems work fine.
# cat /sys/kernel/debug/powerpc/imc/imc_cmd_252 (On a 4.18-based kernel)
0x0000000000000000
# numactl -H
available: 6 nodes (0,8,252-255)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
53 54 55 56 57 58 59 60 61 62 63
node 0 size: 130210 MB
node 0 free: 128406 MB
node 8 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85
86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108
109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
node 8 size: 130784 MB
node 8 free: 130051 MB
node 252 cpus:
node 252 size: 0 MB
node 252 free: 0 MB
node 253 cpus:
node 253 size: 0 MB
node 253 free: 0 MB
node 254 cpus:
node 254 size: 0 MB
node 254 free: 0 MB
node 255 cpus:
node 255 size: 0 MB
node 255 free: 0 MB
node distances:
node 0 8 252 253 254 255
0: 10 40 80 80 80 80
8: 40 10 80 80 80 80
252: 80 80 10 80 80 80
253: 80 80 80 10 80 80
254: 80 80 80 80 10 80
255: 80 80 80 80 80 10
# cat /sys/kernel/debug/powerpc/imc/imc_cmd_252
[ 1139.415461][ T5301] Faulting instruction address: 0xc0000000000d0d58
[ 1139.415492][ T5301] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1139.415509][ T5301] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=256
DEBUG_PAGEALLOC NUMA PowerNV
[ 1139.415542][ T5301] Modules linked in: i2c_opal i2c_core ip_tables x_tables
xfs sd_mod bnx2x mdio ahci libahci tg3 libphy libata firmware_class dm_mirror
dm_region_hash dm_log dm_mod
[ 1139.415595][ T5301] CPU: 67 PID: 5301 Comm: cat Not tainted 5.2.0-rc6-next-
20190627+ #19
[ 1139.415634][ T5301] NIP: c0000000000d0d58 LR: c00000000049aa18 CTR:
c0000000000d0d50
[ 1139.415675][ T5301] REGS: c00020194548f9e0 TRAP: 0300 Not tainted (5.2.0-
rc6-next-20190627+)
[ 1139.415705][ T5301] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR:
28022822 XER: 00000000
[ 1139.415777][ T5301] CFAR: c00000000049aa14 DAR: 000000000003fc08 DSISR:
40000000 IRQMASK: 0
[ 1139.415777][ T5301] GPR00: c00000000049aa18 c00020194548fc70 c0000000016f8b00
000000000003fc08
[ 1139.415777][ T5301] GPR04: c00020194548fcd0 0000000000000000 0000000014884e73
ffffffff00011eaa
[ 1139.415777][ T5301] GPR08: 000000007eea5a52 c0000000000d0d50 0000000000000000
0000000000000000
[ 1139.415777][ T5301] GPR12: c0000000000d0d50 c000201fff7f8c00 0000000000000000
0000000000000000
[ 1139.415777][ T5301] GPR16: 000000000000000d 00007fffeb0c3368 ffffffffffffffff
0000000000000000
[ 1139.415777][ T5301] GPR20: 0000000000000000 0000000000000000 0000000000000000
0000000000020000
[ 1139.415777][ T5301] GPR24: 0000000000000000 0000000000000000 0000000000020000
000000010ec90000
[ 1139.415777][ T5301] GPR28: c00020194548fdf0 c00020049a584ef8 0000000000000000
c00020049a584ea8
[ 1139.416116][ T5301] NIP [c0000000000d0d58] imc_mem_get+0x8/0x20
[ 1139.416143][ T5301] LR [c00000000049aa18] simple_attr_read+0x118/0x170
[ 1139.416158][ T5301] Call Trace:
[ 1139.416182][ T5301] [c00020194548fc70] [c00000000049a970]
simple_attr_read+0x70/0x170 (unreliable)
[ 1139.416255][ T5301] [c00020194548fd10] [c00000000054385c]
debugfs_attr_read+0x6c/0xb0
[ 1139.416305][ T5301] [c00020194548fd60] [c000000000454c1c]
__vfs_read+0x3c/0x70
[ 1139.416363][ T5301] [c00020194548fd80] [c000000000454d0c] vfs_read+0xbc/0x1a0
[ 1139.416392][ T5301] [c00020194548fdd0] [c00000000045519c]
ksys_read+0x7c/0x140
[ 1139.416434][ T5301] [c00020194548fe20] [c00000000000b108]
system_call+0x5c/0x70
[ 1139.416473][ T5301] Instruction dump:
[ 1139.416511][ T5301] 4e800020 60000000 7c0802a6 60000000 7c801d28 38600000
4e800020 60000000
[ 1139.416572][ T5301] 60000000 60000000 7c0802a6 60000000 <7d201c28> 38600000
f9240000 4e800020
[ 1139.416636][ T5301] ---[ end trace c44d1fb4ace04784 ]---
[ 1139.520686][ T5301]
[ 1140.520820][ T5301] Kernel panic - not syncing: Fatal exception
^ permalink raw reply
* Re: [PATCH] powerpc/rtas: retry when cpu offline races with suspend/migration
From: Juliet Kim @ 2019-06-27 21:59 UTC (permalink / raw)
To: Michael Ellerman, Nathan Lynch; +Cc: ego, mmc, linuxppc-dev
In-Reply-To: <875zortydg.fsf@concordia.ellerman.id.au>
On 6/27/19 12:01 AM, Michael Ellerman wrote:
> Juliet Kim <julietk@linux.vnet.ibm.com> writes:
>> On 6/25/19 1:51 PM, Nathan Lynch wrote:
>>> Juliet Kim <julietk@linux.vnet.ibm.com> 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.
>> For instance, system admin runs a script that picks and offlines CPUs in a
>> loop to keep a certain rate of onlined CPUs for energy saving. If LPM keeps
>> putting CPUs back online, that would never finish, and would keepgenerating
>> new offline requests
>>
>>> Second, Linux checks the H_VASI_STATE result on every retry. If the
>>> platform wants to terminate the migration (say, if it imposes a
>>> timeout), Linux will abandon it when H_VASI_STATE fails to return
>>> H_VASI_SUSPENDING. And it seems incorrect to bail out before that
>>> happens, absent hard errors on the Linux side such as allocation
>>> failures.
>> I confirmed with the PHYP and HMC folks that they wouldn't time out the LPM
>> request including H_VASI_STATE, so if the LPM retries were unlucky enough to
>> encounter repeated CPU offline attempts (maybe some customer code retrying
>> that), then the retries could continue indefinitely, or until some manual
>> intervention. And in the mean time, the LPM delay here would cause PHYP to
>> block other operations.
> That sounds like a PHYP bug to me.
>
> cheers
PHYP doesn’t time out because they have no idea how long it will take for OS to
get to the point that it suspends. Other OS allows application to prepare for LPM.
They cannot predict the length of time that is appropriate in all cases and in any
case, it’s unlikely they’d make a change to that would come in time to help with
the current issue.
^ permalink raw reply
* Re: [PATCH v2] powerpc/power: Expose pfn_is_nosave prototype
From: Rafael J. Wysocki @ 2019-06-27 22:00 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Len Brown, linux-s390, linux-pm, Heiko Carstens, linux-kernel,
Paul Mackerras, Pavel Machek, Martin Schwidefsky, linuxppc-dev
In-Reply-To: <20190524104418.17194-1-malat@debian.org>
On Friday, May 24, 2019 12:44:18 PM CEST Mathieu Malaterre wrote:
> The declaration for pfn_is_nosave is only available in
> kernel/power/power.h. Since this function can be override in arch,
> expose it globally. Having a prototype will make sure to avoid warning
> (sometime treated as error with W=1) such as:
>
> arch/powerpc/kernel/suspend.c:18:5: error: no previous prototype for 'pfn_is_nosave' [-Werror=missing-prototypes]
>
> This moves the declaration into a globally visible header file and add
> missing include to avoid a warning on powerpc. Also remove the
> duplicated prototypes since not required anymore.
>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: As suggestion by christophe remove duplicates prototypes
>
> arch/powerpc/kernel/suspend.c | 1 +
> arch/s390/kernel/entry.h | 1 -
> include/linux/suspend.h | 1 +
> kernel/power/power.h | 2 --
> 4 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/suspend.c b/arch/powerpc/kernel/suspend.c
> index a531154cc0f3..9e1b6b894245 100644
> --- a/arch/powerpc/kernel/suspend.c
> +++ b/arch/powerpc/kernel/suspend.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/mm.h>
> +#include <linux/suspend.h>
> #include <asm/page.h>
> #include <asm/sections.h>
>
> diff --git a/arch/s390/kernel/entry.h b/arch/s390/kernel/entry.h
> index 20420c2b8a14..b2956d49b6ad 100644
> --- a/arch/s390/kernel/entry.h
> +++ b/arch/s390/kernel/entry.h
> @@ -63,7 +63,6 @@ void __init startup_init(void);
> void die(struct pt_regs *regs, const char *str);
> int setup_profiling_timer(unsigned int multiplier);
> void __init time_init(void);
> -int pfn_is_nosave(unsigned long);
> void s390_early_resume(void);
> unsigned long prepare_ftrace_return(unsigned long parent, unsigned long sp, unsigned long ip);
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 6b3ea9ea6a9e..e8b8a7bede90 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -395,6 +395,7 @@ extern bool system_entering_hibernation(void);
> extern bool hibernation_available(void);
> asmlinkage int swsusp_save(void);
> extern struct pbe *restore_pblist;
> +int pfn_is_nosave(unsigned long pfn);
> #else /* CONFIG_HIBERNATION */
> static inline void register_nosave_region(unsigned long b, unsigned long e) {}
> static inline void register_nosave_region_late(unsigned long b, unsigned long e) {}
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 9e58bdc8a562..44bee462ff57 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -75,8 +75,6 @@ static inline void hibernate_reserved_size_init(void) {}
> static inline void hibernate_image_size_init(void) {}
> #endif /* !CONFIG_HIBERNATION */
>
> -extern int pfn_is_nosave(unsigned long);
> -
> #define power_attr(_name) \
> static struct kobj_attribute _name##_attr = { \
> .attr = { \
>
Applied, thanks!
^ permalink raw reply
* [PATCH 41/87] sound: ppc: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:40 UTC (permalink / raw)
Cc: Rob Herring, alsa-devel, Greg Kroah-Hartman, Takashi Iwai,
Jaroslav Kysela, Paul Mackerras, Fuqian Huang, Thomas Gleixner,
linuxppc-dev, linux-kernel
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
sound/ppc/pmac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/ppc/pmac.c b/sound/ppc/pmac.c
index 1b11e53f6a62..1ab12f4f8631 100644
--- a/sound/ppc/pmac.c
+++ b/sound/ppc/pmac.c
@@ -56,7 +56,6 @@ static int snd_pmac_dbdma_alloc(struct snd_pmac *chip, struct pmac_dbdma *rec, i
if (rec->space == NULL)
return -ENOMEM;
rec->size = size;
- memset(rec->space, 0, rsize);
rec->cmds = (void __iomem *)DBDMA_ALIGN(rec->space);
rec->addr = rec->dma_base + (unsigned long)((char *)rec->cmds - (char *)rec->space);
--
2.11.0
^ permalink raw reply related
* pata-macio on PowerBook G3: stuck interrupt with MATSHITA CR-174 CD-ROM
From: Finn Thain @ 2019-06-28 0:13 UTC (permalink / raw)
To: linuxppc-dev, linux-ide; +Cc: Stan
Hi All,
I've received a bug report concerning the pata-macio driver, when running
on a PowerBook G3 (Wallstreet).
With CONFIG_PATA_MACIO=n && CONFIG_BLK_DEV_IDE_PMAC=y, everything works.
With CONFIG_PATA_MACIO=y && CONFIG_BLK_DEV_IDE_PMAC=n, the CD-ROM fails.
When the CD-ROM mediabay module is swapped for a DVD-ROM mediabay module,
everything works (either pata-macio or ide-pmac driver works fine).
I'm not familiar with ATA device drivers or the "Heathrow" chipset and its
ATA interfaces so any hints as to how to debug this would be appreciated.
Here's the log from the CONFIG_PATA_MACIO=y kernel with CD-ROM fitted:
[ 0.016446] printk: console [ttyS0] enabled
[ 0.064507] printk: bootconsole [udbg0] disabled
[ 0.119973] pid_max: default: 32768 minimum: 301
[ 0.175852] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.254862] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.343822] rcu: Hierarchical SRCU implementation.
[ 0.400629] smp: Bringing up secondary CPUs ...
[ 0.453605] smp: Brought up 1 node, 1 CPU
[ 0.501683] Using standard scheduler topology
[ 0.555151] devtmpfs: initialized
[ 0.594335] Duplicate name in PowerPC,750, renamed to "l2-cache#1"
[ 0.671377] Duplicate name in pci, renamed to "mac-io#1"
[ 0.734879] Duplicate name in pci, renamed to "pccard#1"
[ 0.798672] random: get_random_u32 called from bucket_table_alloc+0x90/0x1a4 with crng_init=0
[ 0.900756] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 1.018102] futex hash table entries: 512 (order: 2, 16384 bytes)
[ 1.091844] NET: Registered protocol family 16
[ 1.149658] PMU i2c /pci/mac-io/via-pmu
[ 1.194834] channel 1 bus <multibus>
[ 1.237542] channel 2 bus <multibus>
[ 1.283706] PCI: Probing PCI hardware
[ 1.326481] PCI host bridge to bus 0000:00
[ 1.374850] pci_bus 0000:00: root bus resource [io 0x0000-0x7fffff]
[ 1.451111] pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff] (bus address [0x00000000-0x00ffffff])
[ 1.573579] pci_bus 0000:00: root bus resource [mem 0x80000000-0xfcffffff]
[ 1.656035] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.721896] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
[ 1.801465] pci 0000:00:00.0: [1057:0002] type 00 class 0x060000
[ 1.875076] pci 0000:00:0d.0: [106b:0017] type 00 class 0xff0000
[ 1.945684] pci 0000:00:0d.0: reg 0x10: [mem 0xf4000000-0xf407ffff]
[ 2.021957] pci 0000:00:10.0: [106b:0017] type 00 class 0xff0000
[ 2.093150] pci 0000:00:10.0: reg 0x10: [mem 0xf3000000-0xf307ffff]
[ 2.169344] pci 0000:00:11.0: [1002:4c50] type 00 class 0x038000
[ 2.240603] pci 0000:00:11.0: reg 0x10: [mem 0x82000000-0x82ffffff]
[ 2.315852] pci 0000:00:11.0: reg 0x14: [io 0x0400-0x04ff]
[ 2.382757] pci 0000:00:11.0: reg 0x18: [mem 0x82fff000-0x82ffffff]
[ 2.458076] pci 0000:00:11.0: reg 0x30: [mem 0xfd000000-0xfd01ffff pref]
[ 2.538627] pci 0000:00:11.0: supports D1 D2
[ 2.590881] pci 0000:00:13.0: [104c:ac15] type 02 class 0x060700
[ 2.662054] pci 0000:00:13.0: reg 0x10: [mem 0x81803000-0x81803fff]
[ 2.738090] pci 0000:00:13.1: [104c:ac15] type 02 class 0x060700
[ 2.809506] pci 0000:00:13.1: reg 0x10: [mem 0x81802000-0x81802fff]
[ 2.886775] pci_bus 0000:01: extended config space not accessible
[ 2.958551] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
[ 3.037665] pci_bus 0000:05: extended config space not accessible
[ 3.111056] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 08
[ 3.190143] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 08
[ 3.269804] PCI: Cannot allocate resource region 2 of device 0000:00:11.0, will remap
[ 3.363779] PCI 0000:00 Cannot reserve Legacy IO [io 0x0000-0x0fff]
[ 3.440211] pci 0000:00:13.0: BAR 9: assigned [mem 0x84000000-0x87ffffff pref]
[ 3.526840] pci 0000:00:13.0: BAR 10: assigned [mem 0x88000000-0x8bffffff]
[ 3.609575] pci 0000:00:13.1: BAR 9: assigned [mem 0x8c000000-0x8fffffff pref]
[ 3.696208] pci 0000:00:13.1: BAR 10: assigned [mem 0x90000000-0x93ffffff]
[ 3.778818] pci 0000:00:11.0: BAR 6: assigned [mem 0xfd000000-0xfd01ffff pref]
[ 3.865615] pci 0000:00:11.0: BAR 2: assigned [mem 0xfd020000-0xfd020fff]
[ 3.947184] pci 0000:00:13.0: BAR 7: assigned [io 0x1000-0x10ff]
[ 4.020382] pci 0000:00:13.0: BAR 8: assigned [io 0x1100-0x11ff]
[ 4.093579] pci 0000:00:13.1: BAR 7: assigned [io 0x1200-0x12ff]
[ 4.166780] pci 0000:00:13.1: BAR 8: assigned [io 0x1300-0x13ff]
[ 4.239996] pci 0000:00:13.0: CardBus bridge to [bus 01-04]
[ 4.306908] pci 0000:00:13.0: bridge window [io 0x1000-0x10ff]
[ 4.380112] pci 0000:00:13.0: bridge window [io 0x1100-0x11ff]
[ 4.453316] pci 0000:00:13.0: bridge window [mem 0x84000000-0x87ffffff pref]
[ 4.540112] pci 0000:00:13.0: bridge window [mem 0x88000000-0x8bffffff]
[ 4.621825] pci 0000:00:13.1: CardBus bridge to [bus 05-08]
[ 4.688605] pci 0000:00:13.1: bridge window [io 0x1200-0x12ff]
[ 4.761808] pci 0000:00:13.1: bridge window [io 0x1300-0x13ff]
[ 4.835013] pci 0000:00:13.1: bridge window [mem 0x8c000000-0x8fffffff pref]
[ 4.921808] pci 0000:00:13.1: bridge window [mem 0x90000000-0x93ffffff]
[ 5.003378] pci_bus 0000:00: resource 4 [io 0x0000-0x7fffff]
[ 5.072394] pci_bus 0000:00: resource 5 [mem 0xfd000000-0xfdffffff]
[ 5.147683] pci_bus 0000:00: resource 6 [mem 0x80000000-0xfcffffff]
[ 5.222977] pci_bus 0000:01: resource 0 [io 0x1000-0x10ff]
[ 5.289904] pci_bus 0000:01: resource 1 [io 0x1100-0x11ff]
[ 5.356832] pci_bus 0000:01: resource 2 [mem 0x84000000-0x87ffffff pref]
[ 5.437356] pci_bus 0000:01: resource 3 [mem 0x88000000-0x8bffffff]
[ 5.512651] pci_bus 0000:05: resource 0 [io 0x1200-0x12ff]
[ 5.579721] pci_bus 0000:05: resource 1 [io 0x1300-0x13ff]
[ 5.646508] pci_bus 0000:05: resource 2 [mem 0x8c000000-0x8fffffff pref]
[ 5.727027] pci_bus 0000:05: resource 3 [mem 0x90000000-0x93ffffff]
[ 5.872416] vgaarb: loaded
[ 5.905009] SCSI subsystem initialized
[ 5.949546] libata version 3.00 loaded.
[ 5.995113] usbcore: registered new interface driver usbfs
[ 6.060468] usbcore: registered new interface driver hub
[ 6.123972] usbcore: registered new device driver usb
[ 6.189339] clocksource: Switched to clocksource timebase
[ 6.297751] NET: Registered protocol family 2
[ 6.350946] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[ 6.441481] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[ 6.526053] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[ 6.603397] TCP: Hash tables configured (established 4096 bind 4096)
[ 6.679605] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 6.749530] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 6.825109] NET: Registered protocol family 1
[ 6.878013] RPC: Registered named UNIX socket transport module.
[ 6.948055] RPC: Registered udp transport module.
[ 7.004495] RPC: Registered tcp transport module.
[ 7.060966] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 7.138531] PCI: CLS 32 bytes, default 32
[ 7.187936] Thermal assist unit
[ 7.187943] using timers,
[ 7.225198] shrink_timer: 200 jiffies
[ 7.305453] Initialise system trusted keyrings
[ 7.358204] workingset: timestamp_bits=30 max_order=17 bucket_order=0
[ 7.435216] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 19.503576] Key type asymmetric registered
[ 19.550921] Asymmetric key parser 'x509' registered
[ 19.609752] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 19.698127] io scheduler noop registered
[ 19.745121] io scheduler deadline registered (default)
[ 19.806812] io scheduler mq-deadline registered (default)
[ 19.871649] io scheduler kyber registered
[ 19.920630] pci 0000:00:11.0: enabling device (0086 -> 0087)
[ 19.987955] Using unsupported 1024x768 (null) at 82800800, depth=15, pitch=2048
[ 20.138881] Console: switching to colour frame buffer device 128x48
[ 20.272868] fb0: Open Firmware frame buffer device on /pci/ATY,RageLTPro
[ 20.353884] pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
[ 20.441579] Generic non-volatile memory driver v1.1
[ 20.509574] brd: module loaded
[ 20.569033] loop: module loaded
[ 20.605484] MacIO PCI driver attached to Gatwick chipset
[ 20.668887] MacIO PCI driver attached to Heathrow chipset
[ 20.740980] swim3 0.00015000:floppy: [fd0] SWIM3 floppy controller in media bay
[ 20.830812] 0.00013020:ch-a: ttyS0 at MMIO 0xf3013020 (irq = 16, base_baud = 230400) is a Z85c30 ESCC - Serial port
[ 20.956536] 0.00013000:ch-b: ttyS1 at MMIO 0xf3013000 (irq = 17, base_baud = 230400) is a Z85c30 ESCC - Infrared port
[ 21.084616] macio: fixed media-bay irq on gatwick
[ 21.140299] macio: fixed left floppy irqs
[ 21.188187] swim3 1.00015000:floppy: [fd1] Couldn't request interrupt
[ 21.265200] swim3: probe of 1.00015000:floppy failed with error -16
[ 21.340262] macio: fixed left ide irqs
[ 21.385328] macio: fixed SCC irqs on gatwick
[ 21.436648] 1.00013020:ch-a: ttyS2 at MMIO 0xf4013020 (irq = 79, base_baud = 230400) is a Z85c30 ESCC - Internal modem
[ 21.566575] mediabay0: Registered Heathrow media-bay
[ 21.838834] mediabay1: Registered Heathrow media-bay
[ 21.896380] mediabay0: Bay contains an ATA device
[ 22.109857] PMU Backlight initialized (pmubl)
[ 22.162624] mesh: configured for synchronous 5 MB/s
[ 22.438399] mesh: performing initial bus reset...
[ 24.343361] random: fast init done
[ 24.456353] adb device [2]: 2 0xC3
[ 24.500269] adb device [3]: 3 0x1
[ 24.541280] adb device [7]: 7 0x1F
[ 24.594110] ADB keyboard at 2 has handler 0xC3
[ 24.645403] Detected ADB keyboard, type ANSI.
[ 24.698338] input: ADB keyboard as /devices/virtual/input/input0
[ 24.770609] input: ADB Powerbook buttons as /devices/virtual/input/input1
[ 24.916367] ADB mouse (trackpad) at 3 has handler 0x4
[ 24.975478] input: ADB mouse as /devices/virtual/input/input2
[ 26.538410] scsi host0: MESH
[ 29.898319] pata-macio 0.00020000:ata0: Activating pata-macio chipset Heathrow ATA, Apple bus ID 0
[ 30.006876] scsi host1: pata_macio
[ 30.046460] ata1: PATA max MWDMA2 irq 30
[ 30.288858] ata1.00: ATA-7: SAMSUNG HM100JC, YN100-08, max UDMA/100
[ 30.362073] ata1.00: 195371568 sectors, multi 8: LBA48
[ 30.428801] scsi 1:0:0:0: Direct-Access ATA SAMSUNG HM100JC 0-08 PQ: 0 ANSI: 5
[ 30.526375] sd 1:0:0:0: [sda] 195371568 512-byte logical blocks: (100 GB/93.2 GiB)
[ 30.616461] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 30.681190] sd 1:0:0:0: [sda] Write Protect is off
[ 30.736732] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 30.797599] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 31.178323] pata-macio 0.00021000:ata1: Activating pata-macio chipset Heathrow ATA, Apple bus ID 1
[ 31.399429] random: crng init done
[ 31.542666] scsi host2: pata_macio
[ 32.291454] irq 36: nobody cared (try booting with the "irqpoll" option)
[ 32.291484] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-pmac-00001-g2e01b2069c9c #1
[ 32.291493] Call Trace:
[ 32.291561] [dfff3f20] [c051a01c] dump_stack+0x88/0xb4 (unreliable)
[ 32.291611] [dfff3f30] [c0078504] __report_bad_irq+0x34/0xe8
[ 32.291631] [dfff3f50] [c0078880] note_interrupt+0x1fc/0x2c0
[ 32.291652] [dfff3f80] [c00758cc] handle_irq_event_percpu+0x50/0x68
[ 32.291670] [dfff3fa0] [c0075928] handle_irq_event+0x44/0x78
[ 32.291693] [dfff3fc0] [c0079830] handle_level_irq+0xd0/0x154
[ 32.291713] [dfff3fd0] [c0074ac8] generic_handle_irq+0x28/0x40
[ 32.291745] [dfff3fe0] [c0006f70] __do_irq+0x2c/0x74
[ 32.291785] [dfff3ff0] [c000f5d8] call_do_irq+0x24/0x3c
[ 32.291803] [df43b7d0] [c0007044] do_IRQ+0x8c/0xe4
[ 32.291822] [df43b7f0] [c000be70] timer_interrupt+0x2a4/0x2e8
[ 32.291853] [df43b830] [c00124a8] ret_from_except+0x0/0x1c
[ 32.291919] --- interrupt: 901 at __do_softirq+0xbc/0x27c
[ 32.291919] LR = irq_exit+0xd4/0xfc
[ 32.291931] [df43b8f0] [2163ea80] 0x2163ea80 (unreliable)
[ 32.291952] [df43b960] [c00349b8] irq_exit+0xd4/0xfc
[ 32.291969] [df43b970] [c000bde4] timer_interrupt+0x218/0x2e8
[ 32.291989] [df43b9b0] [c00124a8] ret_from_except+0x0/0x1c
[ 32.292013] --- interrupt: 901 at console_unlock+0x98/0x4dc
[ 32.292013] LR = console_unlock+0x428/0x4dc
[ 32.292026] [df43ba70] [c0071e7c] console_unlock+0x274/0x4dc (unreliable)
[ 32.292046] [df43bad0] [c0073950] vprintk_emit+0x128/0x1e8
[ 32.292084] [df43bb10] [c0323dd4] dev_vprintk_emit+0xd4/0x1ac
[ 32.292102] [df43bbc0] [c0323ef4] dev_printk_emit+0x48/0x58
[ 32.292121] [df43bbf0] [c0324a04] dev_printk+0x54/0x64
[ 32.292144] [df43bc30] [c0358764] scsi_add_host_with_dma+0x54/0x318
[ 32.292171] [df43bc50] [c038d0e4] ata_scsi_add_hosts+0x98/0x13c
[ 32.292216] [df43bc90] [c0386a98] ata_host_register+0x14c/0x2ec
[ 32.292236] [df43bcd0] [c0386d44] ata_host_activate+0x10c/0x144
[ 32.292281] [df43bcf0] [c03990e8] pata_macio_common_init+0x2f4/0x4e4
[ 32.292301] [df43bd50] [c03993b4] pata_macio_attach+0xdc/0x16c
[ 32.292330] [df43bd70] [c034d8f0] macio_device_probe+0x58/0x98
[ 32.292351] [df43bd90] [c0328c8c] really_probe+0x1e8/0x2e0
[ 32.292368] [df43bdc0] [c0328fd8] driver_probe_device+0x68/0x238
[ 32.292385] [df43bde0] [c03292c4] __driver_attach+0x11c/0x120
[ 32.292410] [df43be00] [c0326f24] bus_for_each_dev+0x70/0xa0
[ 32.292433] [df43be30] [c0328494] driver_attach+0x24/0x34
[ 32.292453] [df43be40] [c03280b0] bus_add_driver+0x100/0x214
[ 32.292472] [df43be60] [c0329d30] driver_register+0x88/0x14c
[ 32.292492] [df43be70] [c034d7bc] macio_register_driver+0x24/0x34
[ 32.292516] [df43be80] [c06b2960] pata_macio_init+0x5c/0x84
[ 32.292536] [df43bea0] [c0004ab0] do_one_initcall+0x44/0x188
[ 32.292563] [df43bf00] [c068f300] kernel_init_freeable+0x130/0x1e0
[ 32.292581] [df43bf30] [c0004ccc] kernel_init+0x18/0x108
[ 32.292604] [df43bf40] [c00121e4] ret_from_kernel_thread+0x14/0x1c
[ 32.292612] handlers:
[ 32.292645] [<f9be8b69>] ata_bmdma_interrupt
[ 32.292654] Disabling IRQ #36
[ 35.660004] sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
[ 35.772832] ata2: PATA max MWDMA2 irq 36
[ 35.831382] sd 1:0:0:0: [sda] Attached SCSI disk
[ 35.884892] pata-macio 1.00021000:ata4: Activating pata-macio chipset Heathrow ATA, Apple bus ID 4
[ 35.994210] genirq: Flags mismatch irq 36. 00000000 (pata-macio[1.00021000:ata4]) vs. 00000000 (pata-macio[0.00021000:ata1])
[ 36.127937] ata2.00: ATAPI: MATSHITA CR-174, A011, max MWDMA2
[ 36.196720] pata-macio: probe of 1.00021000:ata4 failed with error -16
[ 36.829435] eth0: BMAC at 00:05:02:07:5a:a6
[ 36.829444]
[ 36.901341] aoe: cannot create debugfs directory
[ 36.956514] aoe: AoE v85 initialised.
[ 36.998695] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 37.077387] ehci-pci: EHCI PCI platform driver
[ 37.130898] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 37.205376] ohci-pci: OHCI PCI platform driver
[ 37.258919] usbcore: registered new interface driver uas
[ 37.322501] usbcore: registered new interface driver usb-storage
[ 37.397618] mousedev: PS/2 mouse device common for all mice
[ 37.466368] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[ 37.551836] i2c /dev entries driver
[ 37.593743] PowerMac i2c bus pmu 2 registered
[ 37.645820] PowerMac i2c bus pmu 1 registered
[ 37.703111] usbcore: registered new interface driver usbhid
[ 37.768093] usbhid: USB HID core driver
[ 37.817288] NET: Registered protocol family 17
[ 37.869296] drmem: No dynamic reconfiguration memory found
[ 37.936690] Loading compiled-in X.509 certificates
[ 41.898356] ata2.00: qc timeout (cmd 0xa0)
[ 41.945423] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 47.258317] ata2.00: qc timeout (cmd 0xa0)
[ 47.305462] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 47.371256] ata2.00: limiting speed to MWDMA2:PIO3
[ 52.698307] ata2.00: qc timeout (cmd 0xa0)
[ 52.745460] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
[ 52.811220] ata2.00: disabled
[ 53.440411] EXT4-fs (sda11): mounting ext3 file system using the ext4 subsystem
[ 53.562314] EXT4-fs (sda11): mounted filesystem with ordered data mode. Opts: (null)
[ 53.653604] VFS: Mounted root (ext3 filesystem) readonly on device 8:11.
[ 53.736762] Freeing unused kernel memory: 272K
[ 53.788126] This architecture does not have kernel memory protection.
[ 53.865357] Run /bin/sh as init process
/bin/sh: 0: can't access tty; job control turned off
# mount -t proc none /proc
# cat /proc/interrupts
CPU0
16: 158 PMAC-PIC 15 Level ttyS0
18: 1691 PMAC-PIC 18 Level VIA-PMU
19: 15 PMAC-PIC 12 Level MESH
27: 0 PMAC-PIC 27 Level cascade
30: 144 PMAC-PIC 13 Level pata-macio[0.00020000:ata0]
32: 0 PMAC-PIC 32 Level BMAC-txdma
33: 1 PMAC-PIC 33 Level BMAC-rxdma
34: 0 PMAC-PIC 19 Level SWIM3
36: 100000 PMAC-PIC 14 Level pata-macio[0.00021000:ata1]
42: 0 PMAC-PIC 42 Level BMAC-misc
LOC: 4408 Local timer interrupts for timer event device
BCT: 0 Broadcast timer interrupts for timer event device
LOC: 99943 Local timer interrupts for others
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
NMI: 0 System Reset interrupts
#
Here's the same kernel build with DVD-ROM fitted:
[ 0.016447] printk: console [ttyS0] enabled
[ 0.064513] printk: bootconsole [udbg0] disabled
[ 0.119974] pid_max: default: 32768 minimum: 301
[ 0.175854] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.254864] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.343829] rcu: Hierarchical SRCU implementation.
[ 0.400636] smp: Bringing up secondary CPUs ...
[ 0.453612] smp: Brought up 1 node, 1 CPU
[ 0.501690] Using standard scheduler topology
[ 0.555165] devtmpfs: initialized
[ 0.594342] Duplicate name in PowerPC,750, renamed to "l2-cache#1"
[ 0.671384] Duplicate name in pci, renamed to "mac-io#1"
[ 0.734886] Duplicate name in pci, renamed to "pccard#1"
[ 0.798679] random: get_random_u32 called from bucket_table_alloc+0x90/0x1a4 with crng_init=0
[ 0.900758] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 1.018110] futex hash table entries: 512 (order: 2, 16384 bytes)
[ 1.091846] NET: Registered protocol family 16
[ 1.149663] PMU i2c /pci/mac-io/via-pmu
[ 1.194832] channel 1 bus <multibus>
[ 1.237546] channel 2 bus <multibus>
[ 1.283712] PCI: Probing PCI hardware
[ 1.326491] PCI host bridge to bus 0000:00
[ 1.374860] pci_bus 0000:00: root bus resource [io 0x0000-0x7fffff]
[ 1.451121] pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff] (bus address [0x00000000-0x00ffffff])
[ 1.573433] pci_bus 0000:00: root bus resource [mem 0x80000000-0xfcffffff]
[ 1.656045] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.721906] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
[ 1.801476] pci 0000:00:00.0: [1057:0002] type 00 class 0x060000
[ 1.875080] pci 0000:00:0d.0: [106b:0017] type 00 class 0xff0000
[ 1.945694] pci 0000:00:0d.0: reg 0x10: [mem 0xf4000000-0xf407ffff]
[ 2.021965] pci 0000:00:10.0: [106b:0017] type 00 class 0xff0000
[ 2.093317] pci 0000:00:10.0: reg 0x10: [mem 0xf3000000-0xf307ffff]
[ 2.169364] pci 0000:00:11.0: [1002:4c50] type 00 class 0x038000
[ 2.240612] pci 0000:00:11.0: reg 0x10: [mem 0x82000000-0x82ffffff]
[ 2.315861] pci 0000:00:11.0: reg 0x14: [io 0x0400-0x04ff]
[ 2.382773] pci 0000:00:11.0: reg 0x18: [mem 0x82fff000-0x82ffffff]
[ 2.458092] pci 0000:00:11.0: reg 0x30: [mem 0xfd000000-0xfd01ffff pref]
[ 2.538638] pci 0000:00:11.0: supports D1 D2
[ 2.590731] pci 0000:00:13.0: [104c:ac15] type 02 class 0x060700
[ 2.662067] pci 0000:00:13.0: reg 0x10: [mem 0x81803000-0x81803fff]
[ 2.738101] pci 0000:00:13.1: [104c:ac15] type 02 class 0x060700
[ 2.809517] pci 0000:00:13.1: reg 0x10: [mem 0x81802000-0x81802fff]
[ 2.886781] pci_bus 0000:01: extended config space not accessible
[ 2.958562] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 04
[ 3.037843] pci_bus 0000:05: extended config space not accessible
[ 3.111076] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 08
[ 3.190152] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 08
[ 3.269815] PCI: Cannot allocate resource region 2 of device 0000:00:11.0, will remap
[ 3.363790] PCI 0000:00 Cannot reserve Legacy IO [io 0x0000-0x0fff]
[ 3.440216] pci 0000:00:13.0: BAR 9: assigned [mem 0x84000000-0x87ffffff pref]
[ 3.526852] pci 0000:00:13.0: BAR 10: assigned [mem 0x88000000-0x8bffffff]
[ 3.609426] pci 0000:00:13.1: BAR 9: assigned [mem 0x8c000000-0x8fffffff pref]
[ 3.696214] pci 0000:00:13.1: BAR 10: assigned [mem 0x90000000-0x93ffffff]
[ 3.778824] pci 0000:00:11.0: BAR 6: assigned [mem 0xfd000000-0xfd01ffff pref]
[ 3.865621] pci 0000:00:11.0: BAR 2: assigned [mem 0xfd020000-0xfd020fff]
[ 3.947191] pci 0000:00:13.0: BAR 7: assigned [io 0x1000-0x10ff]
[ 4.020389] pci 0000:00:13.0: BAR 8: assigned [io 0x1100-0x11ff]
[ 4.093715] pci 0000:00:13.1: BAR 7: assigned [io 0x1200-0x12ff]
[ 4.166835] pci 0000:00:13.1: BAR 8: assigned [io 0x1300-0x13ff]
[ 4.240008] pci 0000:00:13.0: CardBus bridge to [bus 01-04]
[ 4.306915] pci 0000:00:13.0: bridge window [io 0x1000-0x10ff]
[ 4.380124] pci 0000:00:13.0: bridge window [io 0x1100-0x11ff]
[ 4.453324] pci 0000:00:13.0: bridge window [mem 0x84000000-0x87ffffff pref]
[ 4.540120] pci 0000:00:13.0: bridge window [mem 0x88000000-0x8bffffff]
[ 4.621691] pci 0000:00:13.1: CardBus bridge to [bus 05-08]
[ 4.688612] pci 0000:00:13.1: bridge window [io 0x1200-0x12ff]
[ 4.761815] pci 0000:00:13.1: bridge window [io 0x1300-0x13ff]
[ 4.835019] pci 0000:00:13.1: bridge window [mem 0x8c000000-0x8fffffff pref]
[ 4.921814] pci 0000:00:13.1: bridge window [mem 0x90000000-0x93ffffff]
[ 5.003389] pci_bus 0000:00: resource 4 [io 0x0000-0x7fffff]
[ 5.072433] pci_bus 0000:00: resource 5 [mem 0xfd000000-0xfdffffff]
[ 5.147742] pci_bus 0000:00: resource 6 [mem 0x80000000-0xfcffffff]
[ 5.223073] pci_bus 0000:01: resource 0 [io 0x1000-0x10ff]
[ 5.289917] pci_bus 0000:01: resource 1 [io 0x1100-0x11ff]
[ 5.356846] pci_bus 0000:01: resource 2 [mem 0x84000000-0x87ffffff pref]
[ 5.437365] pci_bus 0000:01: resource 3 [mem 0x88000000-0x8bffffff]
[ 5.512659] pci_bus 0000:05: resource 0 [io 0x1200-0x12ff]
[ 5.579586] pci_bus 0000:05: resource 1 [io 0x1300-0x13ff]
[ 5.646514] pci_bus 0000:05: resource 2 [mem 0x8c000000-0x8fffffff pref]
[ 5.727038] pci_bus 0000:05: resource 3 [mem 0x90000000-0x93ffffff]
[ 5.872120] vgaarb: loaded
[ 5.904625] SCSI subsystem initialized
[ 5.949238] libata version 3.00 loaded.
[ 5.994759] usbcore: registered new interface driver usbfs
[ 6.060358] usbcore: registered new interface driver hub
[ 6.123632] usbcore: registered new device driver usb
[ 6.188887] clocksource: Switched to clocksource timebase
[ 6.296678] NET: Registered protocol family 2
[ 6.350210] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
[ 6.440553] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[ 6.525256] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[ 6.602621] TCP: Hash tables configured (established 4096 bind 4096)
[ 6.678909] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 6.748808] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 6.824441] NET: Registered protocol family 1
[ 6.877302] RPC: Registered named UNIX socket transport module.
[ 6.947321] RPC: Registered udp transport module.
[ 7.003760] RPC: Registered tcp transport module.
[ 7.060303] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 7.137908] PCI: CLS 32 bytes, default 32
[ 7.187200] Thermal assist unit
[ 7.187207] using timers,
[ 7.224462] shrink_timer: 200 jiffies
[ 7.304729] Initialise system trusted keyrings
[ 7.357457] workingset: timestamp_bits=30 max_order=17 bucket_order=0
[ 7.434540] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 19.502582] Key type asymmetric registered
[ 19.549744] Asymmetric key parser 'x509' registered
[ 19.608748] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[ 19.697133] io scheduler noop registered
[ 19.744128] io scheduler deadline registered (default)
[ 19.805819] io scheduler mq-deadline registered (default)
[ 19.870657] io scheduler kyber registered
[ 19.919636] pci 0000:00:11.0: enabling device (0086 -> 0087)
[ 19.986966] Using unsupported 1024x768 (null) at 82800800, depth=15, pitch=2048
[ 20.138112] Console: switching to colour frame buffer device 128x48
[ 20.272118] fb0: Open Firmware frame buffer device on /pci/ATY,RageLTPro
[ 20.353061] pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
[ 20.440771] Generic non-volatile memory driver v1.1
[ 20.508590] brd: module loaded
[ 20.567330] loop: module loaded
[ 20.603794] MacIO PCI driver attached to Gatwick chipset
[ 20.667286] MacIO PCI driver attached to Heathrow chipset
[ 20.739360] swim3 0.00015000:floppy: [fd0] SWIM3 floppy controller in media bay
[ 20.829332] 0.00013020:ch-a: ttyS0 at MMIO 0xf3013020 (irq = 16, base_baud = 230400) is a Z85c30 ESCC - Serial port
[ 20.954804] 0.00013000:ch-b: ttyS1 at MMIO 0xf3013000 (irq = 17, base_baud = 230400) is a Z85c30 ESCC - Infrared port
[ 21.083058] macio: fixed media-bay irq on gatwick
[ 21.138903] macio: fixed left floppy irqs
[ 21.186505] swim3 1.00015000:floppy: [fd1] Couldn't request interrupt
[ 21.263513] swim3: probe of 1.00015000:floppy failed with error -16
[ 21.338784] macio: fixed left ide irqs
[ 21.383768] macio: fixed SCC irqs on gatwick
[ 21.435035] 1.00013020:ch-a: ttyS2 at MMIO 0xf4013020 (irq = 79, base_baud = 230400) is a Z85c30 ESCC - Internal modem
[ 21.564741] mediabay0: Registered Heathrow media-bay
[ 21.838379] mediabay1: Registered Heathrow media-bay
[ 21.895924] mediabay0: Bay contains an ATA device
[ 22.109476] PMU Backlight initialized (pmubl)
[ 22.162145] mesh: configured for synchronous 5 MB/s
[ 22.437939] mesh: performing initial bus reset...
[ 24.343027] random: fast init done
[ 24.456666] adb device [2]: 2 0xC3
[ 24.500569] adb device [3]: 3 0x1
[ 24.541463] adb device [7]: 7 0x1F
[ 24.594345] ADB keyboard at 2 has handler 0xC3
[ 24.645640] Detected ADB keyboard, type ANSI.
[ 24.698540] input: ADB keyboard as /devices/virtual/input/input0
[ 24.770862] input: ADB Powerbook buttons as /devices/virtual/input/input1
[ 24.916625] ADB mouse (trackpad) at 3 has handler 0x4
[ 24.975731] input: ADB mouse as /devices/virtual/input/input2
[ 26.537947] scsi host0: MESH
[ 29.897854] pata-macio 0.00020000:ata0: Activating pata-macio chipset Heathrow ATA, Apple bus ID 0
[ 30.006366] scsi host1: pata_macio
[ 30.046658] ata1: PATA max MWDMA2 irq 30
[ 30.288389] ata1.00: ATA-7: SAMSUNG HM100JC, YN100-08, max UDMA/100
[ 30.361602] ata1.00: 195371568 sectors, multi 8: LBA48
[ 30.428381] scsi 1:0:0:0: Direct-Access ATA SAMSUNG HM100JC 0-08 PQ: 0 ANSI: 5
[ 30.525903] sd 1:0:0:0: [sda] 195371568 512-byte logical blocks: (100 GB/93.2 GiB)
[ 30.615759] sd 1:0:0:0: Attached scsi generic sg0 type 0
[ 30.680652] sd 1:0:0:0: [sda] Write Protect is off
[ 30.736160] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 30.797029] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 31.177863] pata-macio 0.00021000:ata1: Activating pata-macio chipset Heathrow ATA, Apple bus ID 1
[ 31.286351] scsi host2: pata_macio
[ 31.325979] ata2: PATA max MWDMA2 irq 36
[ 31.397880] pata-macio 1.00021000:ata4: Activating pata-macio chipset Heathrow ATA, Apple bus ID 4
[ 31.503611] genirq: Flags mismatch irq 36. 00000000 (pata-macio[1.00021000:ata4]) vs. 00000000 (pata-macio[0.00021000:ata1])
[ 31.638844] pata-macio: probe of 1.00021000:ata4 failed with error -16
[ 31.717410] ata2.00: ATAPI: MATSHITADVD-ROM SR-8182, AC1b, max MWDMA2
[ 32.347546] eth0: BMAC at 00:05:02:07:5a:a6
[ 32.347554]
[ 32.418641] scsi 2:0:0:0: CD-ROM MATSHITA DVD-ROM SR-8182 AC1b PQ: 0 ANSI: 5
[ 32.517598] aoe: cannot create debugfs directory
[ 32.572596] aoe: AoE v85 initialised.
[ 32.614952] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 32.693848] ehci-pci: EHCI PCI platform driver
[ 32.748873] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 32.821763] ohci-pci: OHCI PCI platform driver
[ 32.875962] usbcore: registered new interface driver uas
[ 32.938307] sr 2:0:0:0: [sr0] scsi3-mmc drive: 12x/12x cd/rw xa/form2 cdda tray
[ 33.025980] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 33.090467] sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15
[ 33.202913] usbcore: registered new interface driver usb-storage
[ 33.278754] mousedev: PS/2 mouse device common for all mice
[ 33.346294] sr 2:0:0:0: Attached scsi CD-ROM sr0
[ 33.411980] sd 1:0:0:0: [sda] Attached SCSI disk
[ 33.469421] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[ 33.554914] sr 2:0:0:0: Attached scsi generic sg1 type 5
[ 33.618673] i2c /dev entries driver
[ 33.660307] PowerMac i2c bus pmu 2 registered
[ 33.712587] PowerMac i2c bus pmu 1 registered
[ 33.769516] usbcore: registered new interface driver usbhid
[ 33.834423] usbhid: USB HID core driver
[ 33.883600] NET: Registered protocol family 17
[ 33.935581] drmem: No dynamic reconfiguration memory found
[ 34.002902] Loading compiled-in X.509 certificates
[ 34.139360] EXT4-fs (sda11): mounting ext3 file system using the ext4 subsystem
[ 34.261224] EXT4-fs (sda11): mounted filesystem with ordered data mode. Opts: (null)
[ 34.352405] VFS: Mounted root (ext3 filesystem) readonly on device 8:11.
[ 34.436039] Freeing unused kernel memory: 272K
[ 34.487304] This architecture does not have kernel memory protection.
[ 34.564637] Run /bin/sh as init process
/bin/sh: 0: can't access tty; job control turned off
# mount -t proc none /proc
# cat /proc/interrupts
CPU0
16: 155 PMAC-PIC 15 Level ttyS0
18: 1096 PMAC-PIC 18 Level VIA-PMU
19: 15 PMAC-PIC 12 Level MESH
27: 0 PMAC-PIC 27 Level cascade
30: 144 PMAC-PIC 13 Level pata-macio[0.00020000:ata0]
32: 0 PMAC-PIC 32 Level BMAC-txdma
33: 1 PMAC-PIC 33 Level BMAC-rxdma
34: 0 PMAC-PIC 19 Level SWIM3
36: 14 PMAC-PIC 14 Level pata-macio[0.00021000:ata1]
42: 0 PMAC-PIC 42 Level BMAC-misc
LOC: 2518 Local timer interrupts for timer event device
BCT: 0 Broadcast timer interrupts for timer event device
LOC: 40 Local timer interrupts for others
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
NMI: 0 System Reset interrupts
#
These logs are from v4.20 but the problem is the same in v5.2-rc2.
--
^ permalink raw reply
* Re: [PATCH] recordmcount: Fix spurious mcount entries on powerpc
From: Michael Ellerman @ 2019-06-28 1:36 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Naveen N. Rao, linuxppc-dev, linux-kernel
In-Reply-To: <20190627091739.15a51a35@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Thu, 27 Jun 2019 15:55:47 +1000
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> Steve are you OK if I merge this via the powerpc tree? I'll reword the
>> commit message so that it makes sense coming prior to the commit
>> mentioned above.
>
> Yes, please add:
>
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Thanks.
cheers
^ permalink raw reply
* Re: [PATCH] recordmcount: Fix spurious mcount entries on powerpc
From: Michael Ellerman @ 2019-06-28 1:38 UTC (permalink / raw)
To: Satheesh Rajendran, Naveen N. Rao
Cc: linuxppc-dev, linux-kernel, Steven Rostedt
In-Reply-To: <20190627102358.GA5974@sathnaga86>
Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> writes:
> On Thu, Jun 27, 2019 at 12:08:01AM +0530, Naveen N. Rao wrote:
>> 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 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2
>> NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30
>> REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942)
>> MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228222 XER: 00000000
>> CFAR: c0000000002642fc IRQMASK: 0
>> <snip>
>> NIP [c000000000264318] ftrace_bug+0x90/0x318
>> LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
>> Call Trace:
>> [c000000001f2ba40] [0000000000000004] 0x4 (unreliable)
>> [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
>> [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0
>> [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130
>> [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70
>> Instruction dump:
>> 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96
>> 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96
>> ---[ end trace 4c438d5cebf78381 ]---
>> ftrace failed to modify
>> [<c0080000012a0008>] 0xc0080000012a0008
>> actual: 01:00:4c:3c
>> Initializing ftrace call sites
>> ftrace record flags: 2000000
>> (0)
>> expected tramp: c00000000006af4c
>>
>> Looking at the relocation records in __mcount_loc showed a few spurious
>> entries:
>> RELOCATION RECORDS FOR [__mcount_loc]:
>> OFFSET TYPE VALUE
>> 0000000000000000 R_PPC64_ADDR64 .text.unlikely+0x0000000000000008
>> 0000000000000008 R_PPC64_ADDR64 .text.unlikely+0x0000000000000014
>> 0000000000000010 R_PPC64_ADDR64 .text.unlikely+0x0000000000000060
>> 0000000000000018 R_PPC64_ADDR64 .text.unlikely+0x00000000000000b4
>> 0000000000000020 R_PPC64_ADDR64 .init.text+0x0000000000000008
>> 0000000000000028 R_PPC64_ADDR64 .init.text+0x0000000000000014
>>
>> The first entry in each section is incorrect. Looking at the relocation
>> records, the spurious entries correspond to the R_PPC64_ENTRY records:
>> RELOCATION RECORDS FOR [.text.unlikely]:
>> OFFSET TYPE VALUE
>> 0000000000000000 R_PPC64_REL64 .TOC.-0x0000000000000008
>> 0000000000000008 R_PPC64_ENTRY *ABS*
>> 0000000000000014 R_PPC64_REL24 _mcount
>> <snip>
>>
>> The problem is that we are not validating the return value from
>> get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0,
>> but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring mcountsym
>> is valid before processing the entry.
>>
>> Fixes: c7d64b560ce80 ("powerpc/ftrace: Enable C Version of recordmcount")
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> scripts/recordmcount.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
> Hi,
>
> linuxppc/merge branch latest commit 850f6274c5b5 was failing to boot IBM
> Power8 Box, and the failure got resolved with this patch.
> https://github.com/linuxppc/issues/issues/254
>
> # git log -2 --oneline
> 0e0f55b31ea8 (HEAD -> issue_254) recordmcount: Fix spurious mcount entries on powerpc
> 850f6274c5b5 (origin/merge, merge) Automatic merge of branches 'master', 'next' and 'fixes' into merge
> # uname -r
> 5.2.0-rc6-00123-g0e0f55b31ea8
>
> Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Thanks. I've pulled the broken commit out of merge for now.
The fix and the original commit will show up in merge later today
probably.
cheers
^ permalink raw reply
* Re: [PATCH V2] crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
From: Michael Ellerman @ 2019-06-28 1:43 UTC (permalink / raw)
To: Herbert Xu, Haren Myneni; +Cc: linuxppc-dev, linux-crypto, stable
In-Reply-To: <20190627062610.olw3ojckkwil4jlk@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> Haren Myneni <haren@linux.vnet.ibm.com> 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 credits.
>>
>> Fixes: b0d6c9bab5e4 ("crypto/nx: Add P9 NX support for 842 compression engine")
>> CC: stable@vger.kernel.org # v4.14+
>> Signed-off-by:Haren Myneni <haren@us.ibm.com>
>
> I presume this is being picked up by the powerpc tree?
No. I assumed you'd take it because it's in drivers/crypto.
If you want me to take it that's fine, just let me know.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Disable /dev/port in skiroot defconfig
From: Michael Ellerman @ 2019-06-28 1:45 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev; +Cc: Daniel Axtens
In-Reply-To: <20190627053008.29315-1-dja@axtens.net>
Daniel Axtens <dja@axtens.net> writes:
> 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.
Why don't we need it? :)
cheers
> diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
> index 5ba131c30f6b..b2e8f37156eb 100644
> --- a/arch/powerpc/configs/skiroot_defconfig
> +++ b/arch/powerpc/configs/skiroot_defconfig
> @@ -212,6 +212,7 @@ CONFIG_IPMI_WATCHDOG=y
> CONFIG_HW_RANDOM=y
> CONFIG_TCG_TPM=y
> CONFIG_TCG_TIS_I2C_NUVOTON=y
> +# CONFIG_DEVPORT is not set
> CONFIG_I2C=y
> # CONFIG_I2C_COMPAT is not set
> CONFIG_I2C_CHARDEV=y
> --
> 2.20.1
^ permalink raw reply
* [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Xiaowei Bao @ 2019-06-28 1:38 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
roy.zang, kstewart, pombredanne, shawn.lin, linux-pci, devicetree,
linux-kernel, linux-arm-kernel, linuxppc-dev
Cc: Xiaowei Bao
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 <xiaowei.bao@nxp.com>
---
v2:
- Replace value 0x14 with a macro.
v3:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index be61d96..227c33b 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = false,
+ .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
};
static const struct pci_epc_features*
--
1.7.1
^ permalink raw reply related
* [PATCHv3 2/2] PCI: layerscape: Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately
From: Xiaowei Bao @ 2019-06-28 1:38 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
roy.zang, kstewart, pombredanne, shawn.lin, linux-pci, devicetree,
linux-kernel, linux-arm-kernel, linuxppc-dev
Cc: Xiaowei Bao
In-Reply-To: <20190628013826.4705-1-xiaowei.bao@nxp.com>
Add CONFIG_PCI_LAYERSCAPE_EP to build EP/RC separately.
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
---
v2:
- No change.
v3:
- modify the commit message.
drivers/pci/controller/dwc/Kconfig | 20 ++++++++++++++++++--
drivers/pci/controller/dwc/Makefile | 3 ++-
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index a6ce1ee..a41ccf5 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -131,13 +131,29 @@ config PCI_KEYSTONE_EP
DesignWare core functions to implement the driver.
config PCI_LAYERSCAPE
- bool "Freescale Layerscape PCIe controller"
+ bool "Freescale Layerscape PCIe controller - Host mode"
depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
depends on PCI_MSI_IRQ_DOMAIN
select MFD_SYSCON
select PCIE_DW_HOST
help
- Say Y here if you want PCIe controller support on Layerscape SoCs.
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Host mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
+
+config PCI_LAYERSCAPE_EP
+ bool "Freescale Layerscape PCIe controller - Endpoint mode"
+ depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want to enable PCIe controller support on Layerscape
+ SoCs to work in Endpoint mode.
+ This controller can work either as EP or RC. The RCW[HOST_AGT_PEX]
+ determines which PCIe controller works in EP mode and which PCIe
+ controller works in RC mode.
config PCI_HISI
depends on OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index b085dfd..824fde7 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone.o
-obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o pci-layerscape-ep.o
+obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
+obj-$(CONFIG_PCI_LAYERSCAPE_EP) += pci-layerscape-ep.o
obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox