* Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE
From: Michael Ellerman @ 2017-12-21 12:10 UTC (permalink / raw)
To: Josh Poimboeuf, Torsten Duwe
Cc: Jiri Kosina, linuxppc-dev, linux-kernel, Nicholas Piggin,
live-patching
In-Reply-To: <20171219214652.u7qeb7fxov62ttke@treble>
Josh Poimboeuf <jpoimboe@redhat.com> writes:
> On Tue, Dec 19, 2017 at 12:28:33PM +0100, Torsten Duwe wrote:
>> On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote:
>> > On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote:
>> > > On Sun, 17 Dec 2017 20:58:54 -0600
>> > > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > >
>> > > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote:
>> > > > > On Tue, 12 Dec 2017 08:05:01 -0600
>> > > > > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > > > >
>> > > > > > What about leaf functions? If a leaf function doesn't establish a stack
>> > > > > > frame, and it has inline asm which contains a blr to another function,
>> > > > > > this ABI is broken.
>> > > >
>> > > > Oops, I meant to say "bl" instead of "blr".
>>
>> You need to save LR, one way or the other. If gcc thinks it's a leaf function and
>> does not do it, nor does your asm code, you'll return in an endless loop => bug.
>
> Ah, so the function's return path would be corrupted, and an unreliable
> stack trace would be the least of our problems.
That's mostly true.
It is possible to save LR somewhere other than the correct stack slot,
in which case you can return correctly but still confuse the unwinder. A
function can hide its caller that way.
It's stupid and we should never do it, but it's not impossible.
...
> So with your proposal, I think I'm convinced that we don't need objtool
> for ppc64le. Does anyone disagree?
I don't disagree, but I'd be happier if we did have objtool support.
Just because it would give us a lot more certainty that we're doing the
right thing everywhere, including in hand-coded asm and inline asm.
It's easy to write powerpc asm such that stack traces are reliable, but
it is *possible* to break them.
> There are still a few more things that need to be looked at:
>
> 1) With function graph tracing enabled, is the unwinder smart enough to
> get the original function return address, e.g. by calling
> ftrace_graph_ret_addr()?
No I don't think so.
> 2) Similar question for kretprobes.
>
> 3) Any other issues with generated code (e.g., bpf, ftrace trampolines),
> runtime patching (e.g., CPU feature alternatives), kprobes, paravirt,
> etc, that might confuse the unwinder?
We'll have to look, I can't be sure off the top of my head.
> 4) As a sanity check, it *might* be a good idea for
> save_stack_trace_tsk_reliable() to ensure that it always reaches the
> end of the stack. There are several ways to do that:
>
> - If the syscall entry stack frame is always the same size, then the
> "end" would simply mean that the stack pointer is at a certain
> offset from the end of the task stack page. However this might not
> work for kthreads and idle tasks, unless their stacks also start at
> the same offset. (On x86 we actually standardized the end of stack
> location for all tasks, both user and kernel.)
Yeah it differs between user and kernel.
> - If the unwinder can get to the syscall frame, it can presumably
> examine regs->msr to check the PR bit to ensure it got all the way
> to syscall entry. But again this might only work for user tasks,
> depending on how kernel task stacks are set up.
That sounds like a good idea. We could possibly mark the last frame of
kernel tasks somehow.
> - Or a different approach would be to do error checking along the
> way, and reporting an error for any unexpected conditions.
>
> However, given that backlink/LR corruption doesn't seem possible with
> this architecture, maybe #4 would be overkill. Personally I would
> feel more comfortable with an "end" check and a WARN() if it doesn't
> reach the end.
Yeah I agree.
cheers
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Michael Ellerman @ 2017-12-21 12:50 UTC (permalink / raw)
To: Matthew Wilcox, Ross Zwisler
Cc: Michal Hocko, Box, David E, Dave Hansen, Zheng, Lv, linux-nvdimm,
Verma, Vishal L, Rafael J. Wysocki, Anaczkowski, Lukasz,
Moore, Robert, linux-acpi, Odzioba, Lukasz, Schmauss, Erik,
Len Brown, John Hubbard, linuxppc-dev, Jerome Glisse,
Dan Williams, devel, Kogut, Jaroslaw, linux-mm, Koss, Marcin,
linux-api, Brice Goglin, Nachimuthu, Murugasamy,
Rafael J. Wysocki, linux-kernel, Koziej, Artur, Lahtinen, Joonas,
Andrew Morton, Tim Chen
In-Reply-To: <20171220181937.GB12236@bombadil.infradead.org>
Matthew Wilcox <willy@infradead.org> writes:
> On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
>> What I'm hoping to do with this series is to just provide a sysfs
>> representation of the HMAT so that applications can know which NUMA nodes to
>> select with existing utilities like numactl. This series does not currently
>> alter any kernel behavior, it only provides a sysfs interface.
>>
>> Say for example you had a system with some high bandwidth memory (HBM), and
>> you wanted to use it for a specific application. You could use the sysfs
>> representation of the HMAT to figure out which memory target held your HBM.
>> You could do this by looking at the local bandwidth values for the various
>> memory targets, so:
>>
>> # grep . /sys/devices/system/hmat/mem_tgt*/local_init/write_bw_MBps
>> /sys/devices/system/hmat/mem_tgt2/local_init/write_bw_MBps:81920
>> /sys/devices/system/hmat/mem_tgt3/local_init/write_bw_MBps:40960
>> /sys/devices/system/hmat/mem_tgt4/local_init/write_bw_MBps:40960
>> /sys/devices/system/hmat/mem_tgt5/local_init/write_bw_MBps:40960
>>
>> and look for the one that corresponds to your HBM speed. (These numbers are
>> made up, but you get the idea.)
>
> Presumably ACPI-based platforms will not be the only ones who have the
> ability to expose different bandwidth memories in the future. I think
> we need a platform-agnostic way ... right, PowerPC people?
Yes!
I don't have any detail at hand but will try and rustle something up.
cheers
^ permalink raw reply
* [PATCH 1/1] powerpc/pseries: Use the system workqueue as fallback to hotplug workqueue
From: Jose Ricardo Ziviani @ 2017-12-21 15:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mpe, david, benh
In-Reply-To: <20171221154448.22965-1-joserz@linux.vnet.ibm.com>
The hotplug engine uses its own workqueue to handle IRQ requests, the
problem is that such workqueue is initialized not so early in the boot
process.
Thus, when the kernel is ready to handle IRQ requests, after the system
workqueue is initialized, we have a timeframe where any hotplug issued
by the client will result in a kernel panic. That timeframe goes until
the hotplug workqueue is initialized.
It would be good to have the hotplug workqueue initialized as soon as
the system workqueue but I don't think it is possible. So, this patch
uses the system workqueue as a fallback the handle such IRQs.
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 6e35780c5962..0474aa14b5f6 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -399,7 +399,15 @@ void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog,
work->errlog = hp_errlog_copy;
work->hp_completion = hotplug_done;
work->rc = rc;
- queue_work(pseries_hp_wq, (struct work_struct *)work);
+
+ /* The hotplug workqueue may happen to be NULL at the moment
+ * this code is executed, during the boot phase. So, in this
+ * scenario, we can fallback to the system workqueue.
+ */
+ if (unlikely(pseries_hp_wq == NULL))
+ schedule_work((struct work_struct *)work);
+ else
+ queue_work(pseries_hp_wq, (struct work_struct *)work);
} else {
*rc = -ENOMEM;
kfree(hp_errlog_copy);
--
2.14.1
^ permalink raw reply related
* [PATCH 0/1] Uses the system workqueue as fallback
From: Jose Ricardo Ziviani @ 2017-12-21 15:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mpe, david, benh
In order to avoid kernel panic after memory hotplug in early stages of the boot
process (which the kernel is already able to handle IRQs), this patch uses the
system workqueue as a fallback to the hotplug workqueue.
After this patch I'm not able to reproduce the problem and the memory is
successfuly plugged at any stage in the boot process.
Thank you
Error scenario:
Booting Linux via __start() @ 0x0000000002000000 ...
[ 0.000000] Detected Power 8 processor
[ 0.000000] Warning: Processor - this hardware has not undergone testing by Red Hat and might not be certified. Please consult https://hardware.redhat.com for certified hardware.
-> smp_release_cpus()
spinning_secondaries = 3
<- smp_release_cpus()
Linux ppc64le
#1 SMP Wed Nov 2[ 0.021319] Unable to handle kernel paging request for data at address 0x00000100
[ 0.021379] Faulting instruction address: 0xc00000000015c420
[ 0.021423] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.021457] LE SMP NR_CPUS=2048 NUMA pSeries
[ 0.021493] Modules linked in:
[ 0.021522] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-9.el7a.ppc64le #1
[ 0.021572] task: c00000047bb80000 task.stack: c00000047bbc0000
[ 0.021615] NIP: c00000000015c420 LR: c00000000015cae4 CTR: 0000000000000000
[ 0.021666] REGS: c00000047ffeb920 TRAP: 0380 Not tainted (4.14.0-9.el7a.ppc64le)
[ 0.021715] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28000042 XER: 20000000
[ 0.021769] CFAR: c00000000015cae0 SOFTE: 0
[ 0.021769] GPR00: c00000000015cae4 c00000047ffebba0 c0000000014ca600 0000000000000800
[ 0.021769] GPR04: 0000000000000000 c00000047e1e5000 00000000000001a0 c0000000000e19e0
[ 0.021769] GPR08: 0000000fffffffe1 0000000000000000 0000000fffffffe0 0000000002001001
[ 0.021769] GPR12: c0000000000e0ea0 c000000007ac0000 c00000000000d0b8 0000000000000000
[ 0.021769] GPR16: 0000000000000000 c00000047e1e5000 0000000000000000 0000000000000000
[ 0.021769] GPR20: 0000000000000000 0000000000000001 0000000000000002 0000000000000015
[ 0.021769] GPR24: c0000001fdc075b8 0000000000000001 c0000001fdc07400 0000000000000000
[ 0.021769] GPR28: 0000000000000800 0000000000000000 0000000000000000 0000000000000800
[ 0.022196] NIP [c00000000015c420] __queue_work+0x80/0x690
[ 0.022231] LR [c00000000015cae4] queue_work_on+0xb4/0xf0
[ 0.022264] Call Trace:
[ 0.022283] [c00000047ffebba0] [c00000000017d948] ttwu_do_wakeup+0x228/0x290 (unreliable)
[ 0.022334] [c00000047ffebc90] [c00000000015cae4] queue_work_on+0xb4/0xf0
[ 0.022377] [c00000047ffebcd0] [c0000000000e36d0] queue_hotplug_event+0xe0/0x160
[ 0.022428] [c00000047ffebd20] [c0000000000e0fe0] ras_hotplug_interrupt+0x140/0x160
[ 0.022480] [c00000047ffebdb0] [c0000000001d0a20] __handle_irq_event_percpu+0xa0/0x330
...
[ 1.024963] Kernel panic - not syncing: Fatal exception in interrupt
[ 1.027080] Rebooting in 10 seconds..
Test case 1: Hotplug during the boot process, after the hotplug wq
initialization
0.554391] rtas_flash: no firmware flash support
[ 0.554464] >>>>>>>>>>>>>>>> [devlog pseries_hp_wq] ALLOCed
[ 0.555021] Initialise system trusted keyrings
...
...
Welcome to Red Hat Enterprise Linux Server 7.4 (Maipo) dracut-033-502.el7 (Initramfs)!
...
[ OK ] Started dracut cmdline hook.
Starting dracut pre-udev hook...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
[ 0.754432] >>>>>>>>>>>>>>>> [devlog pseries_hp_wq] 0xfec52400L
[ 0.765465] pseries-hotplug-mem: Attempting to hot-add 40 LMB(s) at index 80000010
[ 0.765710] radix-mmu: Mapped 0xc000000100000000-0xc000000110000000 with 2.00 MiB pages
...
(qemu) info memory-devices
Memory device [dimm]: "dimm1"
addr: 0x100000000
slot: 0
node: 0
size: 10737418240
memdev: /objects/mem1
hotplugged: true
hotpluggable: true
Test case 2: Hotplug during the boot process, before the hotplug wq
initialization
[ [ 0.028103] NET: Registered protocol family 1
[ 0.028745] Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
[ 0.407070] >>>>>>>>>>>>>>>> [devlog pseries_hp_wq] 0x0 (using system wq)
[ 0.407420] pseries-hotplug-mem: Attempting to hot-add 40 LMB(s) at index 80000010
[ 0.407749] radix-mmu: Mapped 0xc000000100000000-0xc000000110000000 with 2.00 MiB pages
... 0.627554] rtas_flash: no firmware flash support
[ 0.627674] >>>>>>>>>>>>>>>> [devlog pseries_hp_wq] ALLOCed
[ 0.628451] Initialise system trusted keyrings
...
(qemu) info memory-devices
Memory device [dimm]: "dimm1"
addr: 0x100000000
slot: 0
node: 0
size: 10737418240
memdev: /objects/mem1
hotplugged: true
hotpluggable: true
Jose Ricardo Ziviani (1):
powerpc/pseries: Use the system workqueue as fallback to hotplug
workqueue
arch/powerpc/platforms/pseries/dlpar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH v4 00/11] ASoC: fsl_ssi: Clean up - coding style level
From: Caleb Crome @ 2017-12-21 16:08 UTC (permalink / raw)
To: Arnaud Mouiche
Cc: Nicolin Chen, Mark Brown, Timur Tabi, linux-kernel, linuxppc-dev,
alsa-devel, Liam Girdwood, Fabio Estevam, mail, lukma,
Sascha Hauer
In-Reply-To: <4c727cc2-2338-4e99-df09-a088a72cfd61@invoxia.com>
[-- Attachment #1: Type: text/plain, Size: 3784 bytes --]
On Wed, Dec 20, 2017 at 3:40 AM, Arnaud Mouiche <arnaud.mouiche@invoxia.com>
wrote:
>
>
> On 19/12/2017 01:25, Caleb Crome wrote:
>
>> On Mon, Dec 18, 2017 at 3:02 PM, Nicolin Chen <nicoleotsuka@gmail.com>
>> wrote:
>>
>>> On Mon, Dec 18, 2017 at 02:19:08PM -0800, Caleb Crome wrote:
>>>
>>> Acked-by: Timur Tabi <timur@tabi.org>
>>>>>
>>>> --- To Mark ---
>>>
>>> Mark, can you still take these changes first? Since this failed
>>> test that Caleb reported here is already existing on the top of
>>> the mainline tree, I would like to treat this mail as a separate
>>> bug report and fix it with a separate patch.
>>>
>>> Besides, this series of changes don't change any function flow.
>>>
>>> Thank you
>>>
>>> Sorry! I should have created a separate thread for this subject. My
>> comments have *nothing* to do with this patch set, except they are
>> about the same source files.
>>
>> --- To Caleb ---
>>>
>>> I'm re-setting up my loopback test to try to verify these most recent
>>>> changes.
>>>>
>>> I really appreciate your verification and help.
>>>
>> Of course! I have this wandboard permanently set up for this
>> verification test, so that I can easily repeat whenever I touch our
>> kernel.
>>
>> It's a dead-simple hardware mod just to connect TX to RX.
>>
>> warn: 11a0 11a1 1160 11a3 11a4 11a5 11a6 11a7
>>>> warn: Valid frame after 1 invalid frames
>>>> warn: 11c0 11c1 11c2 11c3 11c4 11c5 11c6 11c7
>>>> warn: first invalid frame while expecting frame 0x00a0
>>>> warn: 13e7 1400 1401 1402 1403 1404 1405 1404
>>>> warn: 1407 1420 1421 1422 1423 1424 1425 1426
>>>> warn: 1427 1440 1441 1442 1443 1444 1445 1484
>>>> warn: 1447 1460 1461 1462 1463 1464 1465 1466
>>>>
>>>> Those last 4 lines are the channel slips -- the least significant
>>>> nibble should be the channel number: i.e. should go 0, 1, 2, 3, 4, 5,
>>>> 6, 7.
>>>>
>>>> Ugh, so it's basically quite broken again -- before these patches.
>>>>
>>> I remember Arnaud reviewed one of my changes back to September.
>>> So I suppose the test should be fine at that time -- so a change
>>> being merged recently might have impacted the test result.
>>>
>>
>> It's certainly possible that I'm doing something wrong again -- it
>> wouldn't be the first time :-)
>>
>
> Hi All,
>
> Sorry but I will be busy until mid January, I could help testing and
> fixing broken multi channel after.
> Anyway, I don't see specific issues with Nicolin patches.
> We can take time to fix what was broken before this patch set... after.
>
> Arnaud
>
>
>
>> I guess I need to go backwards in time and see what rev re-broke it.
>>>> I don't really have time to dig too deep on this again.
>>>>
>>>> I'd be happy to provide the hardware to anybody that can diagnose and
>>>> debug this more quickly than I can. I'm very inefficient at kernel
>>>> drivers I think. My day job is acoustical and electrical
>>>> engineering.
>>>>
>>>> Here's what the hardware looks like for anybody that's interested.
>>>> Just a single wire loopback on the wandboard header.
>>>>
>>> I would definitely like to take the hardware to debug it as long
>>> as you are willing to provide me. Can you send me a private mail
>>> to discuss about it?
>>>
>> Absolutely.
>> -Caleb
>>
>>
>> Thanks
>>> Nicolin
>>>
>>
>
Okay, operator error on my part. There was an old clock setting in my ssi3
dtsi file that (falsely) modified the ssi baud clock frequency. Nicolin's
patch
ASoC: fsl_ssi: Caculate bit clock rate using slot number and width
now properly computes the master clock, and the old dtsi settings that were
necessary to fake things into the right speed are now obsolete.
So... basically, everything is back to working properly. it wasn't broken
at all -- just my oversight on a ssi clock setting in the dtb.
-Caleb
[-- Attachment #2: Type: text/html, Size: 6475 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/11] ASoC: fsl_ssi: Clean up - coding style level
From: Caleb Crome @ 2017-12-21 16:10 UTC (permalink / raw)
To: Arnaud Mouiche
Cc: Nicolin Chen, Mark Brown, Timur Tabi, linux-kernel, linuxppc-dev,
alsa-devel, Liam Girdwood, Fabio Estevam, mail, lukma,
Sascha Hauer
In-Reply-To: <CAG5mAdwC8BjL9QmzoeqOLg8r9osJbbZBxb_oe6kJ2jy1wc6j3w@mail.gmail.com>
On Thu, Dec 21, 2017 at 8:08 AM, Caleb Crome <caleb@crome.org> wrote:
On Wed, Dec 20, 2017 at 3:40 AM, Arnaud Mouiche
<arnaud.mouiche@invoxia.com> wrote:
>
>
>
> On 19/12/2017 01:25, Caleb Crome wrote:
>
>> On Mon, Dec 18, 2017 at 3:02 PM, Nicolin Chen <nicoleotsuka@gmail.com> wrote:
>>>
>>> On Mon, Dec 18, 2017 at 02:19:08PM -0800, Caleb Crome wrote:
>>>
>>>
>>>>> Acked-by: Timur Tabi <timur@tabi.org>
>>>
>>> --- To Mark ---
>>>
>>>
>>> Mark, can you still take these changes first? Since this failed
>>>
>>> test that Caleb reported here is already existing on the top of
>>>
>>> the mainline tree, I would like to treat this mail as a separate
>>>
>>> bug report and fix it with a separate patch.
>>>
>>>
>>> Besides, this series of changes don't change any function flow.
>>>
>>>
>>> Thank you
>>>
>> Sorry! I should have created a separate thread for this subject. My
>>
>> comments have *nothing* to do with this patch set, except they are
>>
>> about the same source files.
>>
>>
>>> --- To Caleb ---
>>>
>>>
>>>> I'm re-setting up my loopback test to try to verify these most recent changes.
>>>
>>> I really appreciate your verification and help.
>>
>> Of course! I have this wandboard permanently set up for this
>>
>> verification test, so that I can easily repeat whenever I touch our
>>
>> kernel.
>>
>>
>> It's a dead-simple hardware mod just to connect TX to RX.
>>
>>
>>>> warn: 11a0 11a1 1160 11a3 11a4 11a5 11a6 11a7
>>>>
>>>> warn: Valid frame after 1 invalid frames
>>>>
>>>> warn: 11c0 11c1 11c2 11c3 11c4 11c5 11c6 11c7
>>>>
>>>> warn: first invalid frame while expecting frame 0x00a0
>>>>
>>>> warn: 13e7 1400 1401 1402 1403 1404 1405 1404
>>>>
>>>> warn: 1407 1420 1421 1422 1423 1424 1425 1426
>>>>
>>>> warn: 1427 1440 1441 1442 1443 1444 1445 1484
>>>>
>>>> warn: 1447 1460 1461 1462 1463 1464 1465 1466
>>>>
>>>>
>>>> Those last 4 lines are the channel slips -- the least significant
>>>>
>>>> nibble should be the channel number: i.e. should go 0, 1, 2, 3, 4, 5,
>>>>
>>>> 6, 7.
>>>>
>>>>
>>>> Ugh, so it's basically quite broken again -- before these patches.
>>>
>>> I remember Arnaud reviewed one of my changes back to September.
>>>
>>> So I suppose the test should be fine at that time -- so a change
>>> being merged recently might have impacted the test result.
>>
>>
>> It's certainly possible that I'm doing something wrong again -- it
>> wouldn't be the first time :-)
>
[resend -- previous wasn't in plain text mode]
Okay, operator error on my part. There was an old clock setting in my
ssi3 dtsi file that (falsely) modified the ssi baud clock frequency.
Nicolin's patch
ASoC: fsl_ssi: Caculate bit clock rate using slot number and width
now properly computes the master clock, and the old dtsi settings that
were necessary to fake things into the right speed are now obsolete.
So... basically, everything is back to working properly. it wasn't
broken at all -- just my oversight on a ssi clock setting in the dtb.
-Caleb
^ permalink raw reply
* Re: [PATCH v4 00/11] ASoC: fsl_ssi: Clean up - coding style level
From: Nicolin Chen @ 2017-12-21 16:21 UTC (permalink / raw)
To: Caleb Crome
Cc: Arnaud Mouiche, Mark Brown, Timur Tabi, linux-kernel,
linuxppc-dev, alsa-devel, Liam Girdwood, Fabio Estevam, mail,
lukma, Sascha Hauer
In-Reply-To: <CAG5mAdzZU34WX88fJgFAWXh+e3m9Ogc4PJs9UDNGCa7H3Dtvog@mail.gmail.com>
On Thu, Dec 21, 2017 at 08:10:07AM -0800, Caleb Crome wrote:
> >>> the mainline tree, I would like to treat this mail as a separate
> >>>
> >>> bug report and fix it with a separate patch.
> >>>> warn: 11a0 11a1 1160 11a3 11a4 11a5 11a6 11a7
> >>>>
> >>>> warn: Valid frame after 1 invalid frames
> >>>>
> >>>> warn: 11c0 11c1 11c2 11c3 11c4 11c5 11c6 11c7
> >>>>
> >>>> warn: first invalid frame while expecting frame 0x00a0
> >>>>
> >>>> warn: 13e7 1400 1401 1402 1403 1404 1405 1404
> >>>>
> >>>> warn: 1407 1420 1421 1422 1423 1424 1425 1426
> >>>>
> >>>> warn: 1427 1440 1441 1442 1443 1444 1445 1484
> >>>>
> >>>> warn: 1447 1460 1461 1462 1463 1464 1465 1466
> >>>>
> >>>>
> >>>> Those last 4 lines are the channel slips -- the least significant
> >>>>
> >>>> nibble should be the channel number: i.e. should go 0, 1, 2, 3, 4, 5,
> >>>>
> >>>> 6, 7.
> >>>>
> >>>>
> >>>> Ugh, so it's basically quite broken again -- before these patches.
> Okay, operator error on my part. There was an old clock setting in my
> ssi3 dtsi file that (falsely) modified the ssi baud clock frequency.
> Nicolin's patch
>
> ASoC: fsl_ssi: Caculate bit clock rate using slot number and width
>
> now properly computes the master clock, and the old dtsi settings that
> were necessary to fake things into the right speed are now obsolete.
>
> So... basically, everything is back to working properly. it wasn't
> broken at all -- just my oversight on a ssi clock setting in the dtb.
Well, that's a good news :) Thanks for the efforts during these days
to track back every corner.
Happy holiday.
Nicolin
^ permalink raw reply
* ASoC: fsl_ssi: Bringing up the SSI port in multi-channel TDM mode
From: Caleb Crome @ 2017-12-21 20:25 UTC (permalink / raw)
To: Timur Tabi
Cc: Nicolin Chen, Mark Brown, linux-kernel, linuxppc-dev, alsa-devel,
Liam Girdwood, Fabio Estevam, mail, Arnaud Mouiche, lukma,
Sascha Hauer
Hi,
I just posted a little write up for helping people get started with
the Freescale SSI port in TDM mode.
https://medium.com/@caleb_22836/how-to-get-the-mx6-ssi-port-up-and-running-in-tdm-mode-dbce02a15e81
I'm just posting here in case anybody is searching the google for this
information and finds this post.
(Also, it assumes that v4.15 will be released by the time anybody
actually uses it...)
-Caleb
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Brice Goglin @ 2017-12-21 20:31 UTC (permalink / raw)
To: Ross Zwisler, Dan Williams
Cc: Matthew Wilcox, Dave Hansen, Michal Hocko,
linux-kernel@vger.kernel.org, Anaczkowski, Lukasz, Box, David E,
Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur, Lahtinen, Joonas,
Moore, Robert, Nachimuthu, Murugasamy, Odzioba, Lukasz,
Rafael J. Wysocki, Rafael J. Wysocki, Schmauss, Erik,
Verma, Vishal L, Zheng, Lv, Andrew Morton, Balbir Singh,
Jerome Glisse, John Hubbard, Len Brown, Tim Chen, devel,
Linux ACPI, Linux MM, linux-nvdimm@lists.01.org, Linux API,
linuxppc-dev
In-Reply-To: <20171220224105.GA27258@linux.intel.com>
Le 20/12/2017 à 23:41, Ross Zwisler a écrit :
> On Wed, Dec 20, 2017 at 02:29:56PM -0800, Dan Williams wrote:
>> On Wed, Dec 20, 2017 at 1:24 PM, Ross Zwisler
>> <ross.zwisler@linux.intel.com> wrote:
>>> On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
>>>> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
>>>>> On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
>>>>>> I don't know what the right interface is, but my laptop has a set of
>>>>>> /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
>>>>>> right place to expose write_bw (etc).
>>>>> Those directories are already too redundant and wasteful. I think we'd
>>>>> really rather not add to them. In addition, it's technically possible
>>>>> to have a memory section span NUMA nodes and have different performance
>>>>> properties, which make it impossible to represent there.
>>>>>
>>>>> In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
>>>>> uniform performance properties in the HMAT, and we just so happen to
>>>>> always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
>>>> I think you're missing my larger point which is that I don't think this
>>>> should be exposed to userspace as an ACPI feature. Because if you do,
>>>> then it'll also be exposed to userspace as an openfirmware feature.
>>>> And sooner or later a devicetree feature. And then writing a portable
>>>> program becomes an exercise in suffering.
>>>>
>>>> So, what's the right place in sysfs that isn't tied to ACPI? A new
>>>> directory or set of directories under /sys/devices/system/memory/ ?
>>> Oh, the current location isn't at all tied to acpi except that it happens to
>>> be named 'hmat'. When it was all named 'hmem' it was just:
>>>
>>> /sys/devices/system/hmem
>>>
>>> Which has no ACPI-isms at all. I'm happy to move it under
>>> /sys/devices/system/memory/hmat if that's helpful, but I think we still have
>>> the issue that the data represented therein is still pulled right from the
>>> HMAT, and I don't know how to abstract it into something more platform
>>> agnostic until I know what data is provided by those other platforms.
>>>
>>> For example, the HMAT provides latency information and bandwidth information
>>> for both reads and writes. Will the devicetree/openfirmware/etc version have
>>> this same info, or will it be just different enough that it won't translate
>>> into whatever I choose to stick in sysfs?
>> For the initial implementation do we need to have a representation of
>> all the performance data? Given that
>> /sys/devices/system/node/nodeX/distance is the only generic
>> performance attribute published by the kernel today it is already the
>> case that applications that need to target specific memories need to
>> go parse information that is not provided by the kernel by default.
>> The question is can those specialized applications stay special and go
>> parse the platform specific data sources, like raw HMAT, directly, or
>> do we expect general purpose applications to make use of this data? I
>> think a firmware-id to numa-node translation facility
>> (/sys/devices/system/node/nodeX/fwid) is a simple start that we can
>> build on with more information as specific use cases arise.
> We don't represent all the performance data, we only represent the data for
> local initiator/target pairs. I do think that this is useful to have in sysfs
> because it provides a way to easily answer the most commonly asked questions
> (or at least what I'm guessing will be the most commmonly asked queststions),
> i.e. "given a CPU, what are the speeds of the various types of memory attached
> to it", and "given a chunk of memory, how fast is it and to which CPU is it
> local"? By providing this base level of information I'm hoping to prevent
> most applications from having to parse the HMAT directly.
>
> The question of whether or not to include this local performance information
> was one of the main questions of the initial RFC patch series, and I did get
> feedback (albiet off-list) that the local performance information was
> valuable to at least some users. I did intentionally structure my (now very
> short) set so that the performance information was added as a separate patch,
> so we can get to the place you're talking about where we only provide firmware
> id <=> proximity domain mappings by just leaving off the last patch in the
> series.
>
Hello
I can confirm that HPC runtimes are going to use these patches (at least
all runtimes that use hwloc for topology discovery, but that's the vast
majority of HPC anyway).
We really didn't like KNL exposing a hacky SLIT table [1]. We had to
explicitly detect that specific crazy table to find out which NUMA nodes
were local to which cores, and to find out which NUMA nodes were
HBM/MCDRAM or DDR. And then we had to hide the SLIT values to the
application because the reported latencies didn't match reality. Quite
annoying.
With Ross' patches, we can easily get what we need:
* which NUMA nodes are local to which CPUs? /sys/devices/system/node/
can only report a single local node per CPU (doesn't work for KNL and
upcoming architectures with HBM+DDR+...)
* which NUMA nodes are slow/fast (for both bandwidth and latency)
And we can still look at SLIT under /sys/devices/system/node if really
needed.
And of course having this in sysfs is much better than parsing ACPI
tables that are only accessible to root :)
Regards
Brice
[1] local DDR = 10, remote DDR = 20, local HBM = 31, remote HBM = 41
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/pseries: Use the system workqueue as fallback to hotplug workqueue
From: David Gibson @ 2017-12-22 0:54 UTC (permalink / raw)
To: Jose Ricardo Ziviani; +Cc: linuxppc-dev, mpe, benh
In-Reply-To: <20171221154448.22965-2-joserz@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]
On Thu, Dec 21, 2017 at 01:44:48PM -0200, Jose Ricardo Ziviani wrote:
> The hotplug engine uses its own workqueue to handle IRQ requests, the
> problem is that such workqueue is initialized not so early in the boot
> process.
>
> Thus, when the kernel is ready to handle IRQ requests, after the system
> workqueue is initialized, we have a timeframe where any hotplug issued
> by the client will result in a kernel panic. That timeframe goes until
> the hotplug workqueue is initialized.
>
> It would be good to have the hotplug workqueue initialized as soon as
> the system workqueue but I don't think it is possible. So, this patch
> uses the system workqueue as a fallback the handle such IRQs.
>
> Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
I don't think this is the right approach.
It seems to me the bug is that the hotplug interrupt is registered in
init_ras_IRQ(), before the work queue is initialized in
pseries_dlpar_init(). We need to correct that ordering.
> ---
> arch/powerpc/platforms/pseries/dlpar.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
> index 6e35780c5962..0474aa14b5f6 100644
> --- a/arch/powerpc/platforms/pseries/dlpar.c
> +++ b/arch/powerpc/platforms/pseries/dlpar.c
> @@ -399,7 +399,15 @@ void queue_hotplug_event(struct pseries_hp_errorlog *hp_errlog,
> work->errlog = hp_errlog_copy;
> work->hp_completion = hotplug_done;
> work->rc = rc;
> - queue_work(pseries_hp_wq, (struct work_struct *)work);
> +
> + /* The hotplug workqueue may happen to be NULL at the moment
> + * this code is executed, during the boot phase. So, in this
> + * scenario, we can fallback to the system workqueue.
> + */
> + if (unlikely(pseries_hp_wq == NULL))
> + schedule_work((struct work_struct *)work);
> + else
> + queue_work(pseries_hp_wq, (struct work_struct *)work);
> } else {
> *rc = -ENOMEM;
> kfree(hp_errlog_copy);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: Michael Ellerman @ 2017-12-22 4:22 UTC (permalink / raw)
To: Rasmus Villemoes, Michael Ellerman
Cc: Jouni Malinen, netdev@vger.kernel.org, Johannes Berg,
linuxppc-dev@lists.ozlabs.org, Johannes Berg
In-Reply-To: <87efnpnf8b.fsf@rasmusvillemoes.dk>
Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote:
>>> From: Johannes Berg <johannes.berg@intel.com>
>>>
>>> This reverts commit d6f295e9def0; some userspace (in the case
>>
>> This revert seems to have broken networking on one of my powerpc
>> machines, according to git bisect.
>>
>> The symptom is DHCP fails and I don't get a link, I didn't dig any
>> further than that. I can if it's helpful.
>>
>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
>> is now the same as dev_alloc_name_ns") only makes sense while
>> d6f295e9def0 remains in the tree.
>
> I'm sorry about all of this, I really didn't think there would be such
> consequences of changing an errno return. Indeed, d6f29 was preparation
> for unifying the two functions that do the exact same thing (and how we
> ever got into that situation is somewhat unclear), except for
> their behaviour in the case the requested name already exists. So one of
> the two interfaces had to change its return value, and as I wrote, I
> thought EEXIST was the saner choice when an explicit name (no %d) had
> been requested.
No worries.
>> ie. before the entire series, dev_get_valid_name() would return EEXIST,
>> and that was retained when 87c320e51519 was merged, but now that
>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
>>
>> I can get the network up again if I also revert 87c320e51519 ("net:
>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
>> the gross patch below.
>
> I don't think changing -ENFILE to -EEXIST would be right either, since
> dev_get_valid_name() used to be able to return both (-EEXIST in the case
> where there's no %d, -ENFILE in the case where we end up calling
> dev_alloc_name_ns()). If anything, we could do the check for the old
> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
> fine with reverting.
Yeah I think a revert would be best, given it's nearly rc5.
My userspace is not exotic AFAIK, just debian something, so presumably
this will affect other people too.
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: fix XIVE migration of pending interrupts
From: Michael Ellerman @ 2017-12-22 4:34 UTC (permalink / raw)
To: Laurent Vivier, Cédric Le Goater, kvm-ppc, Paul Mackerras,
Benjamin Herrenschmidt
Cc: linuxppc-dev
In-Reply-To: <4be897d4-2d54-305b-8416-b32384de73a9@redhat.com>
Laurent Vivier <lvivier@redhat.com> writes:
> On 12/12/2017 13:02, C=C3=A9dric Le Goater wrote:
>> When restoring a pending interrupt, we are setting the Q bit to force
>> a retrigger in xive_finish_unmask(). But we also need to force an EOI
>> in this case to reach the same initial state : P=3D1, Q=3D0.
>>=20
>> This can be done by not setting 'old_p' for pending interrupts which
>> will inform xive_finish_unmask() that an EOI needs to be sent.
>>=20
>> Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: C=C3=A9dric Le Goater <clg@kaod.org>
>> ---
>>=20
>> Tested with a guest running iozone.
>>=20
>> arch/powerpc/kvm/book3s_xive.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> We really need this patch to fix VM migration on POWER9.
> When will it be merged?
Paul is away, so I'll merge it via the powerpc tree.
I'll mark it:
Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE inter=
rupt controller")
Cc: stable@vger.kernel.org # v4.12+
cheers
^ permalink raw reply
* Re: powerpc/perf: Fix nest-imc cpuhotplug callback failure
From: Michael Ellerman @ 2017-12-22 4:43 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: maddy, linuxppc-dev, anju, linux-kernel
In-Reply-To: <1512451838-10456-1-git-send-email-anju@linux.vnet.ibm.com>
On Tue, 2017-12-05 at 05:30:38 UTC, Anju T Sudhakar wrote:
> Call trace observed during boot:
>
> Faulting instruction address: 0xc000000000248340
> cpu 0x0: Vector: 380 (Data Access Out of Range) at [c000000ff66fb850]
> pc: c000000000248340: event_function_call+0x50/0x1f0
> lr: c00000000024878c: perf_remove_from_context+0x3c/0x100
> sp: c000000ff66fbad0
> msr: 9000000000009033
> dar: 7d20e2a6f92d03c0
> current = 0xc000000ff6679200
> paca = 0xc00000000fd40000 softe: 0 irq_happened: 0x01
> pid = 14, comm = cpuhp/0
> Linux version 4.14.0-rc2-42789-ge8eae4b (rgrimm@XXXX) (gcc version 5.4.0
> 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4)) #1 SMP Thu Nov 16 14:35:14 CST
> 2017
> enter ? for help
> [c000000ff66fbb80] c00000000024878c perf_remove_from_context+0x3c/0x100
> [c000000ff66fbbc0] c00000000024e84c perf_pmu_migrate_context+0x10c/0x380
> [c000000ff66fbc60] c0000000000ca050 ppc_nest_imc_cpu_offline+0x1b0/0x210
> [c000000ff66fbcb0] c0000000000d5d54 cpuhp_invoke_callback+0x194/0x620
> [c000000ff66fbd20] c0000000000d702c cpuhp_thread_fun+0x7c/0x1b0
> [c000000ff66fbd60] c00000000010ad90 smpboot_thread_fn+0x290/0x2a0
> [c000000ff66fbdc0] c000000000104818 kthread+0x168/0x1b0
> [c000000ff66fbe30] c00000000000b5a0 ret_from_kernel_thread+0x5c/0xbc
>
> While registering the cpuhotplug callbacks for nest-imc, if we fail in the
> cpuhotplug online path for any random node in a multi node system (because
> the opal call to stop nest-imc counters fails for that node),
> ppc_nest_imc_cpu_offline() will get invoked for other nodes who successfully
> returned from cpuhotplug online path.
>
> This call trace is generated since in the ppc_nest_imc_cpu_offline()
> path we are trying to migrate the event context, when nest-imc counters are
> not even initialized.
>
> Patch to add a check to ensure that nest-imc is registered before migrating
> the event context.
>
> Note:
> Madhavan Srinivasan has recently send a skiboot patch to have a check in the
> skiboot code to make sure that the microcode is initialized in all the chips,
> before enabling the nest units.
> https://patchwork.ozlabs.org/patch/844047/ (v2)
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/ad2b6e01024ef23bddc3ce0bcb115e
cheers
^ permalink raw reply
* Re: powerpc/perf: Fix kfree memory allocated for nest pmus
From: Michael Ellerman @ 2017-12-22 4:43 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: maddy, linuxppc-dev, anju
In-Reply-To: <1512667407-30067-1-git-send-email-anju@linux.vnet.ibm.com>
On Thu, 2017-12-07 at 17:23:27 UTC, Anju T Sudhakar wrote:
> imc_common_cpuhp_mem_free() is the common function for all IMC (In-memory
> Collection counters) domains to unregister cpuhotplug callback and free memory.
> Since kfree of memory allocated for nest-imc (per_nest_pmu_arr) is in the common
> code, all domains (core/nest/thread) can do the kfree in the failure case.
>
> This could potentially create a call trace as shown below, where core(/thread/nest)
> imc pmu initialization fails and in the failure path imc_common_cpuhp_mem_free()
> free the memory(per_nest_pmu_arr), which is allocated by successfully registered
> nest units.
>
>
> The call trace is generated in a scenario where core-imc initialization is
> made to fail and a cpuhotplug is performed in a p9 system.
> During cpuhotplug ppc_nest_imc_cpu_offline() tries to access per_nest_pmu_arr,
> which is already freed by core-imc.
>
> [ 136.563618] NIP [c000000000cb6a94] mutex_lock+0x34/0x90
> [ 136.563653] LR [c000000000cb6a88] mutex_lock+0x28/0x90
> [ 136.563687] Call Trace:
> [ 136.563707] [c0000016b7a93b90] [c000000000cb6a88] mutex_lock+0x28/0x90 (unreliable)
> [ 136.563762] [c0000016b7a93bc0] [c0000000002bc720] perf_pmu_migrate_context+0x90/0x3a0
> [ 136.563814] [c0000016b7a93c60] [c0000000000f7a40] ppc_nest_imc_cpu_offline+0x190/0x1f0
> [ 136.563867] [c0000016b7a93cb0] [c000000000108140] cpuhp_invoke_callback+0x160/0x820
> [ 136.563918] [c0000016b7a93d30] [c00000000010939c] cpuhp_thread_fun+0x1bc/0x270
> [ 136.563970] [c0000016b7a93d60] [c00000000013d2b0] smpboot_thread_fn+0x250/0x290
> [ 136.564022] [c0000016b7a93dc0] [c000000000136f18] kthread+0x1a8/0x1b0
> [ 136.564067] [c0000016b7a93e30] [c00000000000b4e8] ret_from_kernel_thread+0x5c/0x74
>
> To address this scenario do the kfree(per_nest_pmu_arr) only in case of
> nest-imc initialization failure, and when there is no other nest units registered.
>
>
> Fixes: 73ce9aec65b1 ("powerpc/perf: Fix IMC_MAX_PMU macro")
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/110df8bd3e418b3476cae80babe8ad
cheers
^ permalink raw reply
* Re: powerpc/perf: Dereference bhrb entries safely
From: Michael Ellerman @ 2017-12-22 4:43 UTC (permalink / raw)
To: Ravi Bangoria
Cc: maddy, linux-kernel, kamalesh, paulus, kan.liang, Ravi Bangoria,
tglx, linuxppc-dev, naveen.n.rao
In-Reply-To: <20171212122915.20338-1-ravi.bangoria@linux.vnet.ibm.com>
On Tue, 2017-12-12 at 12:29:15 UTC, Ravi Bangoria wrote:
> It may very well happen that branch instructions recorded by
> bhrb entries already get unmapped before they get processed by
> the kernel. Hence, trying to dereference such memory location
> will endup in a crash. Ex,
>
> Unable to handle kernel paging request for data at address 0xc008000019c41764
> Faulting instruction address: 0xc000000000084a14
> NIP [c000000000084a14] branch_target+0x4/0x70
> LR [c0000000000eb828] record_and_restart+0x568/0x5c0
> Call Trace:
> [c0000000000eb3b4] record_and_restart+0xf4/0x5c0 (unreliable)
> [c0000000000ec378] perf_event_interrupt+0x298/0x460
> [c000000000027964] performance_monitor_exception+0x54/0x70
> [c000000000009ba4] performance_monitor_common+0x114/0x120
>
> Fix this by deferefencing them safely.
>
> Suggested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/f41d84dddc66b164ac16acf3f584c2
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Increase memory block size to 1GB on radix
From: Michael Ellerman @ 2017-12-22 5:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david, anton, aneesh.kumar
In-Reply-To: <20171220042520.7946-1-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> When we're using the Radix MMU we map the kernel linear mapping with
> 1G pages. That means we must do memory hot remove in blocks of at
> least that size. Otherwise the linear mapping can end up not mapping
> all of memory because we've removed part of a 1G region but unmapped
> the entire 1G region from the linear mapping.
>
> Currently on pseries we consult the device tree to find out the the
> "LMB" (Logical Memory Block) size. This is the unit of memory hotplug
> communicated to us by the hypervisor, but it does not take into
> account anything the kernel has done itself, such as use 1G pages for
> the linear mapping.
This patch failed to survive contact with reality. ie. it doesn't work.
NAK.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Increase memory block size to 1GB on radix
From: Balbir Singh @ 2017-12-22 5:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Aneesh Kumar KV, Anton Blanchard, David Gibson
In-Reply-To: <87608zpd10.fsf@concordia.ellerman.id.au>
On Fri, Dec 22, 2017 at 4:06 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
>
>> When we're using the Radix MMU we map the kernel linear mapping with
>> 1G pages. That means we must do memory hot remove in blocks of at
>> least that size. Otherwise the linear mapping can end up not mapping
>> all of memory because we've removed part of a 1G region but unmapped
>> the entire 1G region from the linear mapping.
>>
>> Currently on pseries we consult the device tree to find out the the
>> "LMB" (Logical Memory Block) size. This is the unit of memory hotplug
>> communicated to us by the hypervisor, but it does not take into
>> account anything the kernel has done itself, such as use 1G pages for
>> the linear mapping.
>
> This patch failed to survive contact with reality. ie. it doesn't work.
>
> NAK.
I have patches to split the size of a region, I guess the right thing to do is
to split the size of mapping during hotplug. I can look at doing that once I
am back. What broke for you during testing?
Balbir Singh.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: fix XIVE migration of pending interrupts
From: Paul Mackerras @ 2017-12-22 7:54 UTC (permalink / raw)
To: Michael Ellerman
Cc: Laurent Vivier, Cédric Le Goater, kvm-ppc,
Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <878tdvpeib.fsf@concordia.ellerman.id.au>
On Fri, Dec 22, 2017 at 03:34:20PM +1100, Michael Ellerman wrote:
> Laurent Vivier <lvivier@redhat.com> writes:
>
> > On 12/12/2017 13:02, Cédric Le Goater wrote:
> >> When restoring a pending interrupt, we are setting the Q bit to force
> >> a retrigger in xive_finish_unmask(). But we also need to force an EOI
> >> in this case to reach the same initial state : P=1, Q=0.
> >>
> >> This can be done by not setting 'old_p' for pending interrupts which
> >> will inform xive_finish_unmask() that an EOI needs to be sent.
> >>
> >> Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >> ---
> >>
> >> Tested with a guest running iozone.
> >>
> >> arch/powerpc/kvm/book3s_xive.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > We really need this patch to fix VM migration on POWER9.
> > When will it be merged?
>
> Paul is away, so I'll merge it via the powerpc tree.
>
> I'll mark it:
>
> Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
> Cc: stable@vger.kernel.org # v4.12+
Thanks for doing that.
If you felt like merging Alexey's patch "KVM: PPC: Book3S PR: Fix WIMG
handling under pHyp" with my acked-by, that would be fine too. The
commit message needs a little work - the reason for using HPTE_R_M is
not just because it seems to work, but because current POWER
processors require M set on mappings for normal pages, and pHyp
enforces that.
Cheers,
Paul.
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S: fix XIVE migration of pending interrupts
From: Laurent Vivier @ 2017-12-22 7:57 UTC (permalink / raw)
To: Paul Mackerras, Michael Ellerman
Cc: Cédric Le Goater, kvm-ppc, Benjamin Herrenschmidt,
linuxppc-dev
In-Reply-To: <20171222075430.GB6945@fergus.ozlabs.ibm.com>
On 22/12/2017 08:54, Paul Mackerras wrote:
> On Fri, Dec 22, 2017 at 03:34:20PM +1100, Michael Ellerman wrote:
>> Laurent Vivier <lvivier@redhat.com> writes:
>>
>>> On 12/12/2017 13:02, Cédric Le Goater wrote:
>>>> When restoring a pending interrupt, we are setting the Q bit to force
>>>> a retrigger in xive_finish_unmask(). But we also need to force an EOI
>>>> in this case to reach the same initial state : P=1, Q=0.
>>>>
>>>> This can be done by not setting 'old_p' for pending interrupts which
>>>> will inform xive_finish_unmask() that an EOI needs to be sent.
>>>>
>>>> Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>>> ---
>>>>
>>>> Tested with a guest running iozone.
>>>>
>>>> arch/powerpc/kvm/book3s_xive.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> We really need this patch to fix VM migration on POWER9.
>>> When will it be merged?
>>
>> Paul is away, so I'll merge it via the powerpc tree.
>>
>> I'll mark it:
>>
>> Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
>> Cc: stable@vger.kernel.org # v4.12+
>
> Thanks for doing that.
>
> If you felt like merging Alexey's patch "KVM: PPC: Book3S PR: Fix WIMG
> handling under pHyp" with my acked-by, that would be fine too. The
> commit message needs a little work - the reason for using HPTE_R_M is
> not just because it seems to work, but because current POWER
> processors require M set on mappings for normal pages, and pHyp
> enforces that.
We also need:
KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp()
Thanks,
Laurent
^ permalink raw reply
* Re: WARNING: CPU: 0 PID: 2777 at arch/powerpc/mm/hugetlbpage.c:354 h,ugetlb_free_pgd_range+0xc8/0x1e4
From: Christophe LEROY @ 2017-12-22 9:32 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <d569112a-2d43-c77e-3579-a8a2176ddcf7@c-s.fr>
Le 20/12/2017 à 13:17, Christophe LEROY a écrit :
> Trying to malloc() with libhugetlbfs, it runs indefinitly doing page
> faults in do_page_fault()/hugetlb_fault().
> When interrupting the blocked app with CTRL+C, I get the following WARNING:
>
> Any idea of what can be wrong ? I'm on a 8xx with 512k huge pages.
It looks like something goes wrong when the app tries to mmap a
hugetlbpage at a given address.
When it requests the page with a NULL address, it works well.
Any idea ?
Christophe
>
> [162980.035629] WARNING: CPU: 0 PID: 2777 at
> arch/powerpc/mm/hugetlbpage.c:354 h
> ugetlb_free_pgd_range+0xc8/0x1e4
> [162980.035699] CPU: 0 PID: 2777 Comm: malloc Tainted: G W 4.14.6-s
> 3k-dev-ga8e8e8b176-svn9134 #85
> [162980.035744] task: c67e2c00 task.stack: c668e000
> [162980.035783] NIP: c000fe18 LR: c00e1eec CTR: c00f90c0
> [162980.035830] REGS: c668fc20 TRAP: 0700 Tainted: G W (4.14.6-s
> 3k-dev-ga8e8e8b176-svn9134)
> [162980.035854] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24044224 XER: 20000000
> [162980.036003]
> [162980.036003] GPR00: c00e1eec c668fcd0 c67e2c00 00000010 c6869410
> 10080000 000
> 00000 77fb4000
> [162980.036003] GPR08: ffff0001 0683c001 00000000 ffffff80 44028228
> 10018a34 000
> 04008 418004fc
> [162980.036003] GPR16: c668e000 00040100 c668e000 c06c0000 c668fe78
> c668e000 c68
> 35ba0 c668fd48
> [162980.036003] GPR24: 00000000 73ffffff 74000000 00000001 77fb4000
> 100fffff 101
> 00000 10100000
> [162980.036743] NIP [c000fe18] hugetlb_free_pgd_range+0xc8/0x1e4
> [162980.036839] LR [c00e1eec] free_pgtables+0x12c/0x150
> [162980.036861] Call Trace:
> [162980.036939] [c668fcd0] [c00f0774] unlink_anon_vmas+0x1c4/0x214
> (unreliable)
> [162980.037040] [c668fd10] [c00e1eec] free_pgtables+0x12c/0x150
> [162980.037118] [c668fd40] [c00eabac] exit_mmap+0xe8/0x1b4
> [162980.037210] [c668fda0] [c0019710] mmput.part.9+0x20/0xd8
> [162980.037301] [c668fdb0] [c001ecb0] do_exit+0x1f0/0x93c
> [162980.037386] [c668fe00] [c001f478] do_group_exit+0x40/0xcc
> [162980.037479] [c668fe10] [c002a76c] get_signal+0x47c/0x614
> [162980.037570] [c668fe70] [c0007840] do_signal+0x54/0x244
> [162980.037654] [c668ff30] [c0007ae8] do_notify_resume+0x34/0x88
> [162980.037744] [c668ff40] [c000dae8] do_user_signal+0x74/0xc4
> [162980.037781] Instruction dump:
> [162980.037821] 7fdff378 81370000 54a3463a 80890020 7d24182e 7c841a14
> 712a0004 4
> 082ff94
> [162980.038014] 2f890000 419e0010 712a0ff0 408200e0 <0fe00000> 54a9000a
> 7f984840
> 419d0094
> [162980.038216] ---[ end trace c0ceeca8e7a5800a ]---
> [162980.038754] BUG: non-zero nr_ptes on freeing mm: 1
> [162985.363322] BUG: non-zero nr_ptes on freeing mm: -1
>
> Christophe
^ permalink raw reply
* [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus
From: Christian Zigotzky @ 2017-12-22 9:57 UTC (permalink / raw)
To: Bjorn Helgaas, Michael Ellerman, Darren Stevens,
linux-pci@vger.kernel.org, Bjorn Helgaas, Olof Johansson,
linuxppc-dev
In-Reply-To: <6326d79e-405b-2ae8-5295-97bf11219b81@xenosoft.de>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
Hi Bjorn,
Sorry I'm bothering you again. Is this small out of tree init routine in
the Nemo patch? I haven't get an answer from Darren yet and I didn't
found the small out of tree init routine in the Nemo patch. Please find
attached the Nemo patch. Maybe you can find this small out of tree init
routine.
What do you think of this following code?
if (sb600_bus == -1)
+ {
+ busp = pci_find_bus(0, 0);
+ pa_pxp_read_config(busp, PCI_DEVFN(17,0),
PCI_SECONDARY_BUS, 1, &val);
+
+ sb600_bus = val;
+
+ printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
+ }
Thanks,
Christian
On 04 December 2017 at 12:40PM, Darren Stevens wrote:
> Hello Bjorn
>
> Firstly sorry for not being able to join in this discussion, I have been
> moving house and only got my X1000 set up again yesterday..
>
> On 30/11/2017, Bjorn Helgaas wrote:
>> I *think* something like the patch below should make this work if you
>> use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
>> that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
>> something similar on powerpc, but maybe you do?
>
> Actually the root ports on the Nemo's PA6T processor don't respond to the
> SB600 unless we turn on a special 'relax pci-e' bit in one of its control
> registers. We use a small out of tree init routine to do this, and there
> would be the ideal place to put a call to
> pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
>
> This patch fixes the last major hurdle to getting the X1000 fully
supported in
> the linux kernel, so thanks very much for that.
>
> Regards
> Darren
>
>
[-- Attachment #2: nemo_4.14-1.patch --]
[-- Type: text/x-patch, Size: 10795 bytes --]
diff -rupN a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
--- a/arch/powerpc/platforms/pasemi/pci.c 2017-09-11 17:04:18.257586417 +0200
+++ b/arch/powerpc/platforms/pasemi/pci.c 2017-09-11 17:03:43.040599938 +0200
@@ -27,6 +27,7 @@
#include <linux/pci.h>
#include <asm/pci-bridge.h>
+#include <asm/isa-bridge.h>
#include <asm/machdep.h>
#include <asm/ppc-pci.h>
@@ -108,6 +109,69 @@ static int workaround_5945(struct pci_bu
return 1;
}
+#ifdef CONFIG_PPC_PASEMI_NEMO
+static int sb600_bus = 5;
+static void __iomem *iob_mapbase = NULL;
+
+static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val);
+
+static void sb600_set_flag(int bus)
+{
+ struct resource res;
+ struct device_node *dn;
+ struct pci_bus *busp;
+ u32 val;
+ int err;
+
+ if (sb600_bus == -1)
+ {
+ busp = pci_find_bus(0, 0);
+ pa_pxp_read_config(busp, PCI_DEVFN(17,0), PCI_SECONDARY_BUS, 1, &val);
+
+ sb600_bus = val;
+
+ printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
+ }
+
+ if (iob_mapbase == NULL)
+ {
+ dn = of_find_compatible_node(NULL, "isa", "pasemi,1682m-iob");
+ if (!dn)
+ {
+ printk(KERN_CRIT "NEMO SB600 missing iob node\n");
+ return;
+ }
+
+ err = of_address_to_resource(dn, 0, &res);
+ of_node_put(dn);
+
+ if (err)
+ {
+ printk(KERN_CRIT "NEMO SB600 missing resource\n");
+ return;
+ }
+
+ printk(KERN_CRIT "NEMO SB600 IOB base %08lx\n",res.start);
+
+ iob_mapbase = ioremap(res.start + 0x100, 0x94);
+ }
+
+ if (iob_mapbase != NULL)
+ {
+ if (bus == sb600_bus)
+ {
+ out_le32(iob_mapbase + 4, in_le32(iob_mapbase + 4) | 0x800);
+ }
+ else
+ {
+ out_le32(iob_mapbase + 4, in_le32(iob_mapbase + 4) & ~0x800);
+ }
+ }
+}
+#endif
+
+
static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
{
@@ -126,6 +190,10 @@ static int pa_pxp_read_config(struct pci
addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ sb600_set_flag(bus->number);
+#endif
+
/*
* Note: the caller has already checked that offset is
* suitably aligned and that len is 1, 2 or 4.
@@ -210,6 +278,9 @@ static int __init pas_add_bridge(struct
/* Interpret the "ranges" property */
pci_process_bridge_OF_ranges(hose, dev, 1);
+ /* Scan for an isa bridge. */
+ isa_bridge_find_early(hose);
+
return 0;
}
diff -rupN a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
--- a/arch/powerpc/platforms/pasemi/setup.c 2017-09-11 17:04:18.256586450 +0200
+++ b/arch/powerpc/platforms/pasemi/setup.c 2017-09-11 17:03:43.042599888 +0200
@@ -34,6 +34,7 @@
#include <asm/prom.h>
#include <asm/iommu.h>
#include <asm/machdep.h>
+#include <asm/i8259.h>
#include <asm/mpic.h>
#include <asm/smp.h>
#include <asm/time.h>
@@ -72,6 +73,17 @@ static void __noreturn pas_restart(char
out_le32(reset_reg, 0x6000000);
}
+#ifdef CONFIG_PPC_PASEMI_NEMO
+void pas_shutdown(void)
+{
+ /* (added by DStevens 19/06/13)
+ Set the PLD bit that makes the SB600 think the power button is being pressed */
+ void __iomem *pld_map = ioremap(0xf5000000,4096);
+ while (1)
+ out_8(pld_map+7,0x01);
+}
+#endif
+
#ifdef CONFIG_SMP
static arch_spinlock_t timebase_lock;
static unsigned long timebase;
@@ -183,16 +195,30 @@ static int __init pas_setup_mce_regs(voi
}
machine_device_initcall(pasemi, pas_setup_mce_regs);
+#ifdef CONFIG_PPC_PASEMI_NEMO
+static void sb600_8259_cascade(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int cascade_irq = i8259_irq();
+
+ if (cascade_irq !=NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ chip->irq_eoi(&desc->irq_data);
+}
+#endif
+
static __init void pas_init_IRQ(void)
{
struct device_node *np;
- struct device_node *root, *mpic_node;
+ struct device_node *root, *mpic_node, *i8259_node;
unsigned long openpic_addr;
const unsigned int *opprop;
int naddr, opplen;
int mpic_flags;
const unsigned int *nmiprop;
struct mpic *mpic;
+ int gpio_virq;
mpic_node = NULL;
@@ -244,6 +270,22 @@ static __init void pas_init_IRQ(void)
mpic_unmask_irq(irq_get_irq_data(nmi_virq));
}
+
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ // Connect legacy i8259 controller in SB600
+ i8259_node = of_find_node_by_path("/pxp@0,e0000000");
+ printk("Init i8259\n");
+ i8259_init(i8259_node, 0);
+ of_node_put(i8259_node);
+
+ gpio_virq = irq_create_mapping(NULL, 3);
+ irq_set_irq_type(gpio_virq, IRQ_TYPE_LEVEL_HIGH);
+ irq_set_chained_handler(gpio_virq, sb600_8259_cascade);
+ mpic_unmask_irq(irq_get_irq_data(gpio_virq));
+
+ irq_set_default_host(mpic->irqhost);
+
+#endif
of_node_put(mpic_node);
of_node_put(root);
}
@@ -398,6 +440,18 @@ static const struct of_device_id pasemi_
{},
};
+static struct resource rtc_resource[] = {{
+ .name = "rtc",
+ .start = 0x70,
+ .end = 0x71,
+ .flags = IORESOURCE_IO,
+}, {
+ .name = "rtc",
+ .start = 8,
+ .end = 8,
+ .flags = IORESOURCE_IRQ,
+}};
+
static int __init pasemi_publish_devices(void)
{
pasemi_pcmcia_init();
@@ -405,6 +459,10 @@ static int __init pasemi_publish_devices
/* Publish OF platform devices for SDC and other non-PCI devices */
of_platform_bus_probe(NULL, pasemi_bus_ids, NULL);
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ platform_device_register_simple("rtc_cmos", -1, rtc_resource, 2);
+#endif
+
return 0;
}
machine_device_initcall(pasemi, pasemi_publish_devices);
@@ -421,9 +479,13 @@ static int __init pas_probe(void)
iommu_init_early_pasemi();
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ pm_power_off = pas_shutdown; // Varisys provided a way to turn us off
+#endif
return 1;
}
+
define_machine(pasemi) {
.name = "PA Semi PWRficient",
.probe = pas_probe,
@@ -435,4 +497,7 @@ define_machine(pasemi) {
.calibrate_decr = generic_calibrate_decr,
.progress = pas_progress,
.machine_check_exception = pas_machine_check_handler,
+#if 0 // def CONFIG_PPC_PASEMI_NEMO
+ .pci_probe_mode = sb600_pci_probe_mode,
+#endif
};
diff -rupN a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
--- a/drivers/ata/pata_atiixp.c 2017-09-11 17:04:26.591307805 +0200
+++ b/drivers/ata/pata_atiixp.c 2017-09-11 17:03:43.043599863 +0200
@@ -278,6 +278,12 @@ static int atiixp_init_one(struct pci_de
};
const struct ata_port_info *ppi[] = { &info, &info };
+ /* SB600 on the Nemo board doesn't have secondary port wired */
+ #ifdef CONFIG_PPC_PASEMI_NEMO
+ if((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE))
+ ppi[1] = &ata_dummy_port_info;
+ #endif
+
return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
ATA_HOST_PARALLEL_SCAN);
}
diff -rupN a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
--- a/drivers/ata/pata_of_platform.c 2017-09-11 17:04:26.565308689 +0200
+++ b/drivers/ata/pata_of_platform.c 2017-09-11 17:03:43.044599838 +0200
@@ -40,14 +40,36 @@ static int pata_of_platform_probe(struct
return -EINVAL;
}
- ret = of_address_to_resource(dn, 1, &ctl_res);
- if (ret) {
- dev_err(&ofdev->dev, "can't get CTL address from "
- "device tree\n");
- return -EINVAL;
+ if (of_device_is_compatible(dn, "electra-ide")) {
+ /* Altstatus is really at offset 0x3f6 from the primary window
+ * on electra-ide. Adjust ctl_res and io_res accordingly.
+ */
+ ctl_res = io_res;
+ ctl_res.start = ctl_res.start+0x3f6;
+ io_res.end = ctl_res.start-1;
+
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ } else if (of_device_is_compatible(dn, "electra-cf")) {
+ /* Task regs are at 0x800, with alt status @ 0x80e in the primary window
+ * on electra-cf. Adjust ctl_res and io_res accordingly.
+ */
+ ctl_res = io_res;
+ io_res.start += 0x800;
+ ctl_res.start = ctl_res.start + 0x80e;
+ io_res.end = ctl_res.start-1;
+#endif
+ } else {
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
}
irq_res = platform_get_resource(ofdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = 0;
of_property_read_u32(dn, "reg-shift", ®_shift);
@@ -60,6 +82,11 @@ static int pata_of_platform_probe(struct
dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
}
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ irq_res = 0; // force irq off (doesn't seem to work)
+#endif
+
+
pio_mask = 1 << pio_mode;
pio_mask |= (1 << pio_mode) - 1;
@@ -69,6 +96,10 @@ static int pata_of_platform_probe(struct
static const struct of_device_id pata_of_platform_match[] = {
{ .compatible = "ata-generic", },
+ { .compatible = "electra-ide", },
+#ifdef CONFIG_PPC_PASEMI_NEMO
+ { .compatible = "electra-cf",},
+#endif
{ },
};
MODULE_DEVICE_TABLE(of, pata_of_platform_match);
diff -rupN a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
--- a/drivers/i2c/busses/i2c-pasemi.c 2017-09-11 17:04:23.084427043 +0200
+++ b/drivers/i2c/busses/i2c-pasemi.c 2017-09-11 17:03:43.045599813 +0200
@@ -365,7 +365,6 @@ static int pasemi_smb_probe(struct pci_d
smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
smbus->adapter.algo = &smbus_algorithm;
smbus->adapter.algo_data = smbus;
- smbus->adapter.nr = PCI_FUNC(dev->devfn);
/* set up the sysfs linkage to our parent device */
smbus->adapter.dev.parent = &dev->dev;
@@ -373,7 +372,7 @@ static int pasemi_smb_probe(struct pci_d
reg_write(smbus, REG_CTL, (CTL_MTR | CTL_MRR |
(CLK_100K_DIV & CTL_CLK_M)));
- error = i2c_add_numbered_adapter(&smbus->adapter);
+ error = i2c_add_adapter(&smbus->adapter);
if (error)
goto out_release_region;
diff -rupN a/drivers/pci/probe.c b/drivers/pci/probe.c
--- a/drivers/pci/probe.c 2017-09-11 17:04:23.683406677 +0200
+++ b/drivers/pci/probe.c 2017-09-11 17:03:43.050599688 +0200
@@ -2177,6 +2177,8 @@ static int only_one_child(struct pci_bus
if (!parent || !pci_is_pcie(parent))
return 0;
+ #ifndef CONFIG_PPC_PASEMI_NEMO
+ // SB600 has non-zero devices on non-root bus.
if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT)
return 1;
@@ -2189,6 +2191,7 @@ static int only_one_child(struct pci_bus
if (parent->has_secondary_link &&
!pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
return 1;
+ #endif
return 0;
}
^ permalink raw reply
* [PATCH] SB600 for the Nemo board has non-zero devices on non-root bus
From: Christian Zigotzky @ 2017-12-22 10:22 UTC (permalink / raw)
To: Bjorn Helgaas, Michael Ellerman, Darren Stevens,
linux-pci@vger.kernel.org, Bjorn Helgaas, Olof Johansson,
linuxppc-dev
In-Reply-To: <af18fb51-a0bc-68e2-7594-5583e3090f98@xenosoft.de>
I mean: I haven't gotten an answer from Darren yet. Sorry because of my
English. I am still learning.
-- Christian
On 22 December 2017 at 10:57AM, Christian Zigotzky wrote:
> Hi Bjorn,
>
> Sorry I'm bothering you again. Is this small out of tree init routine
in the Nemo patch? I haven't get an answer from Darren yet and I didn't
found the small out of tree init routine in the Nemo patch. Please find
attached the Nemo patch. Maybe you can find this small out of tree init
routine.
>
> What do you think of this following code?
>
> if (sb600_bus == -1)
> + {
> + busp = pci_find_bus(0, 0);
> + pa_pxp_read_config(busp, PCI_DEVFN(17,0),
PCI_SECONDARY_BUS, 1, &val);
> +
> + sb600_bus = val;
> +
> + printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
> + }
>
> Thanks,
> Christian
>
>
> On 04 December 2017 at 12:40PM, Darren Stevens wrote:
> > Hello Bjorn
> >
> > Firstly sorry for not being able to join in this discussion, I have
been
> > moving house and only got my X1000 set up again yesterday..
> >
> > On 30/11/2017, Bjorn Helgaas wrote:
> >> I *think* something like the patch below should make this work if you
> >> use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
> >> that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
> >> something similar on powerpc, but maybe you do?
> >
> > Actually the root ports on the Nemo's PA6T processor don't respond
to the
> > SB600 unless we turn on a special 'relax pci-e' bit in one of its
control
> > registers. We use a small out of tree init routine to do this, and
there
> > would be the ideal place to put a call to
> > pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
> >
> > This patch fixes the last major hurdle to getting the X1000 fully
supported in
> > the linux kernel, so thanks very much for that.
> >
> > Regards
> > Darren
> >
> >
>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-4.15-5 tag
From: Michael Ellerman @ 2017-12-22 11:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: anju, benh, clg, linux-kernel, linuxppc-dev, lvivier,
ravi.bangoria, paulus
[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]
Hi Linus,
Please pull some more powerpc fixes for 4.15.
This is all fairly boring, except that there's two KVM fixes that you'd
normally get via Paul's kvm-ppc tree. He's away so I picked them up. I
was waiting to see if he would apply them, which is why they have only
been in my tree since today. But they were on the list for a while and
have been tested on the relevant hardware.
cheers
The following changes since commit d8104182087319fd753d6d8e0afcd95d84c2aa2f:
powerpc/xmon: Don't print hashed pointers in xmon (2017-12-07 00:27:01 +1100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.15-5
for you to fetch changes up to 7333b5aca412d6ad02667b5a513485838a91b136:
KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp() (2017-12-22 15:36:24 +1100)
----------------------------------------------------------------
powerpc fixes for 4.15 #5
Of note is two fixes for KVM XIVE (Power9 interrupt controller). These would
normally go via the KVM tree but Paul is away so I've picked them up.
Other than that, two fixes for error handling in the IMC driver, and one for a
potential oops in the BHRB code if the hardware records a branch address that
has subsequently been unmapped, and finally a s/%p/%px/ in our oops code.
Thanks to:
Anju T Sudhakar, Cédric Le Goater, Laurent Vivier, Madhavan Srinivasan, Naveen
N. Rao, Ravi Bangoria.
----------------------------------------------------------------
Anju T Sudhakar (2):
powerpc/perf/imc: Fix nest-imc cpuhotplug callback failure
powerpc/perf: Fix kfree memory allocated for nest pmus
Cédric Le Goater (1):
KVM: PPC: Book3S: fix XIVE migration of pending interrupts
Laurent Vivier (1):
KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp()
Michael Ellerman (1):
powerpc/kernel: Print actual address of regs when oopsing
Ravi Bangoria (1):
powerpc/perf: Dereference BHRB entries safely
arch/powerpc/kernel/process.c | 2 +-
arch/powerpc/kvm/book3s_xive.c | 7 ++++---
arch/powerpc/perf/core-book3s.c | 8 ++++++--
arch/powerpc/perf/imc-pmu.c | 17 ++++++++++++++++-
4 files changed, 27 insertions(+), 7 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [PATCH 0/9] modernize early memory allocation limits and
From: Nicholas Piggin @ 2017-12-22 11:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, Aneesh Kumar K . V
This series improves (mostly relaxes) limits on early memory
allocations for stacks, pacas, etc. on 64s.
It also avoids allocating lppacas for bare metal, and it changes
allocation of paca and lppaca from single big arrays to inividual
allocations.
The main goal of this is toward allocating these basic structures
per-node. We're not there yet, but closer.
Thanks,
Nick
Nicholas Piggin (9):
powerpc/powernv: Remove real mode access limit for early allocations
powerpc/pseries: radix is not subject to RMA limit, remove it
powerpc/64: rtas avoid accessing paca in 32-bit mode
powerpc/pseries: lift RTAS limit for radix
powerpc/pseries: lift RTAS limit for hash
powerpc/64s: Relax PACA address limitations
powerpc/64s: do not allocate lppaca if we are not virtualized
powerpc/64: Use array of paca pointers and allocate pacas individually
powerpc/64s: Use array of lppaca pointers and allocate lppacas
individually
arch/powerpc/include/asm/kvm_ppc.h | 8 +-
arch/powerpc/include/asm/lppaca.h | 26 ++--
arch/powerpc/include/asm/paca.h | 12 +-
arch/powerpc/include/asm/pmc.h | 13 +-
arch/powerpc/include/asm/smp.h | 4 +-
arch/powerpc/kernel/asm-offsets.c | 5 +
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/entry_64.S | 17 ++-
arch/powerpc/kernel/head_64.S | 19 +--
arch/powerpc/kernel/machine_kexec_64.c | 37 +++---
arch/powerpc/kernel/paca.c | 174 ++++++++++++++-------------
arch/powerpc/kernel/setup.h | 4 +
arch/powerpc/kernel/setup_64.c | 40 +++---
arch/powerpc/kernel/smp.c | 10 +-
arch/powerpc/kernel/sysfs.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 34 +++---
arch/powerpc/kvm/book3s_hv_builtin.c | 2 +-
arch/powerpc/kvm/book3s_hv_interrupts.S | 3 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 3 +-
arch/powerpc/mm/hash_utils_64.c | 24 ++--
arch/powerpc/mm/numa.c | 4 +-
arch/powerpc/mm/pgtable-radix.c | 17 +--
arch/powerpc/mm/tlb-radix.c | 2 +-
arch/powerpc/platforms/85xx/smp.c | 8 +-
arch/powerpc/platforms/cell/smp.c | 4 +-
arch/powerpc/platforms/powernv/idle.c | 13 +-
arch/powerpc/platforms/powernv/setup.c | 4 +-
arch/powerpc/platforms/powernv/smp.c | 2 +-
arch/powerpc/platforms/powernv/subcore.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +-
arch/powerpc/platforms/pseries/kexec.c | 7 +-
arch/powerpc/platforms/pseries/lpar.c | 4 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
arch/powerpc/platforms/pseries/smp.c | 4 +-
arch/powerpc/sysdev/xics/icp-native.c | 2 +-
arch/powerpc/xmon/xmon.c | 2 +-
36 files changed, 289 insertions(+), 229 deletions(-)
--
2.15.0
^ permalink raw reply
* [PATCH 1/9] powerpc/powernv: Remove real mode access limit for early allocations
From: Nicholas Piggin @ 2017-12-22 11:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin, Aneesh Kumar K . V
In-Reply-To: <20171222111716.13101-1-npiggin@gmail.com>
This removes the RMA limit on powernv platform, which constrains
early allocations such as PACAs and stacks. There are still other
restrictions that must be followed, such as bolted SLB limits, but
real mode addressing has no constraints.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/hash_utils_64.c | 20 +++++++++++++-------
arch/powerpc/mm/pgtable-radix.c | 37 +++++++++++++++++++++----------------
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 655a5a9a183d..8922e069b073 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1825,16 +1825,22 @@ void hash__setup_initial_memory_limit(phys_addr_t first_memblock_base,
*/
BUG_ON(first_memblock_base != 0);
- /* On LPAR systems, the first entry is our RMA region,
- * non-LPAR 64-bit hash MMU systems don't have a limitation
- * on real mode access, but using the first entry works well
- * enough. We also clamp it to 1G to avoid some funky things
+ /*
+ * On virtualized systems the first entry is our RMA region aka VRMA,
+ * non-virtualized 64-bit hash MMU systems don't have a limitation
+ * on real mode access.
+ *
+ * We also clamp it to 1G to avoid some funky things
* such as RTAS bugs etc...
*/
- ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
+ if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
+ ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
- /* Finally limit subsequent allocations */
- memblock_set_current_limit(ppc64_rma_size);
+ /* Finally limit subsequent allocations */
+ memblock_set_current_limit(ppc64_rma_size);
+ } else {
+ ppc64_rma_size = ULONG_MAX;
+ }
}
#ifdef CONFIG_DEBUG_FS
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index cfbbee941a76..d73816960825 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -622,22 +622,27 @@ void radix__setup_initial_memory_limit(phys_addr_t first_memblock_base,
* physical on those processors
*/
BUG_ON(first_memblock_base != 0);
- /*
- * We limit the allocation that depend on ppc64_rma_size
- * to first_memblock_size. We also clamp it to 1GB to
- * avoid some funky things such as RTAS bugs.
- *
- * On radix config we really don't have a limitation
- * on real mode access. But keeping it as above works
- * well enough.
- */
- ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
- /*
- * Finally limit subsequent allocations. We really don't want
- * to limit the memblock allocations to rma_size. FIXME!! should
- * we even limit at all ?
- */
- memblock_set_current_limit(first_memblock_base + first_memblock_size);
+
+ if (!early_cpu_has_feature(CPU_FTR_HVMODE)) {
+ /*
+ * We limit the allocation that depend on ppc64_rma_size
+ * to first_memblock_size. We also clamp it to 1GB to
+ * avoid some funky things such as RTAS bugs.
+ *
+ * On radix config we really don't have a limitation
+ * on real mode access. But keeping it as above works
+ * well enough.
+ */
+ ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
+ /*
+ * Finally limit subsequent allocations. We really don't want
+ * to limit the memblock allocations to rma_size. FIXME!! should
+ * we even limit at all ?
+ */
+ memblock_set_current_limit(first_memblock_base + first_memblock_size);
+ } else {
+ ppc64_rma_size = ULONG_MAX;
+ }
}
#ifdef CONFIG_MEMORY_HOTPLUG
--
2.15.0
^ 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