[v2 PATCH] powerpc: hugetlb: replace __get_cpu_var with get_cpu_var
Replace __get_cpu_var safely with get_cpu_var to avoid
the following call trace:
[ 7253.637591] BUG: using smp_processor_id() in preemptible [ ]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
Signed-off-by: Tiejun Chen
---
v2:
Just fix some style problems.
arch/powerpc/mm/hugetlbpage.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 90bb6d9..0e9eff8 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -472,12 +472,13 @@ static void hugepd_free(struct mmu_gather *tlb, void
*hugepte)
{
struct hugepd_freelist **batchp;
- batchp = &__get_cpu_var(hugepd_freelist_cur);
+ batchp = &get_cpu_var(hugepd_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm),
cpumask_of(smp_processor_id( {
kmem_cache_free(hugepte_cache, hugepte);
+ put_cpu_var(hugepd_freelist_cur);
return;
}
@@ -491,6 +492,8 @@ static void hugepd_free(struct mmu_gather *tlb, void
*hugepte)
call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
+
+ put_cpu_var(hugepd_freelist_cur);
}
#endif
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: KGDB panics on p2020 target
On 01/21/2014 02:04 PM, Arun Chandran wrote:
On Mon, Jan 20, 2014 at 1:55 PM, "�tiejun.chen�"
wrote:
On 01/17/2014 03:52 PM, Arun Chandran wrote:
Hi,
I am testing kgdb on freescale p2020 target.
In target
1)
root@freescale-p2020ds:~# uname -a
Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST 2014
ppc GNU/Linux
2)
root@freescale-p2020ds:~# cat /proc/cpuinfo
processor : 0
cpu : e500v2
clock : 999.990008MHz
revision: 4.0 (pvr 8021 1040)
bogomips: 124.99
processor : 1
cpu : e500v2
clock : 999.990008MHz
revision: 4.0 (pvr 8021 1040)
bogomips: 124.99
total bogomips : 249.99
timebase: 62499376
platform: P2020 DS
model : fsl,P2020DS
Memory : 768 MB
3)
freescale-p2020ds:~# echo "ttyS1,115200" >
/sys/module/kgdboc/parameters/kgdoc
4) I set up host (settings given below); Then I send "SysRq : DEBUG"
In host
--
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
kgdb_breakpoint () at kernel/debug/debug_core.c:1013
1013 arch_kgdb_breakpoint();
(gdb) b sys_sync
Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.
(gdb) c
Continuing.
I am able to take control in host; after that I am setting breakpoint at
"sys_sync"
In target
root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9
do
sync
done
In host
--
Breakpoint 1, sys_sync () at fs/sync.c:103
103 {
(gdb) c
Continuing.
Breakpoint is hit only one time instead of 9 times; after that target
hangs.
I recommend you try upstream to take a further look at this, instead of
that Freescale distribution. As I recall currently KGDB works well in 85xx
case in ML.
Many thanks for your suggestion.
I tested the same thing on linux-3.12.y (
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=refs%2Ftags%2Fv3.12.8&h=linux-3.12.y
).
Please go powerpc tree,
git clone git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
git checkout next
root@p2020ds:~# uname -a
Linux freescale-p2020ds 3.12.8 #136 SMP Tue Jan 21 11:14:13 IST 2014 ppc
GNU/Linux
The breakpoint I placed at "sys_sync" is hit only once. After that my gdb
command "continue" does not make further
hits. And the target is hung. It is not even responding to my further
sending of "SysRq : DEBUG"
I have attached my .config
Then i tried to send "SysRq : DEBUG" in target kernel panics.
I have pasted the panic below.
#
SysRq : DEBUG
Kernel panic - not syncing: Recursive entry to debugger
The kernel already trap into kgdb_handle_exception() with the debug
exception while triggering that break point, but again you trigger another
debug exception by SysRq. Actually KGDB can't handle such this recursive
behavior, so KGDB always call kgdb_reenter_check() to prevent this scenario
with this call trace.
I am doing it because the target is hung after the initial breakpoint is
hit.
This is just what I mean. Although looks your kernel is hung, actually your
kernel is already in kgdb exception handler previously. So after you send break
by SysRq to debug, its not allowed by current kgdb scheme as I said. The
following call trace also show this path explicitly.
Tiejun
static int kgdb_reenter_check(struct kgdb_state *ks)
{
unsigned long addr;
if (atomic_read(&kgdb_active) != raw_smp_processor_id())
return 0;
...
if (exception_level > 1) {
dump_stack();
panic("Recursive entry to debugger");
}
Tiejun
CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
Call Trace:
[effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)
[effe5d50] [c0588878] panic+0xe4/0x224
[effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
[effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
[effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
[effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
--- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
LR = __handle_sysrq+0x154/0x1cc
[effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
[effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
[effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
[effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
[effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
[effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
[effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
[effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
[c4f91b10] [c0004f60] do_IRQ+0x150/0x224
[c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
--- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
LR = rpcauth_lookup_credcache+0xb8/0x2a4
[c4f91c00] [24002424] 0x24002424 (unreliable)
[c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
[c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
[c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
[c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
[c4f9
RE: [PATCH 2/2] fsl/pci: The new pci suspend/resume implementation
Any more comments? :) Thanks, -Dongsheng > -Original Message- > From: Linuxppc-dev [mailto:linuxppc-dev- > bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of > dongsheng.w...@freescale.com > Sent: Wednesday, January 08, 2014 3:13 PM > To: Rafael J. Wysocki > Cc: linuxppc-dev@lists.ozlabs.org; ga...@codeaurora.org; Wood Scott-B07421; > linux-...@vger.kernel.org; bhelg...@google.com > Subject: RE: [PATCH 2/2] fsl/pci: The new pci suspend/resume implementation > > > > > -Original Message- > > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > > Sent: Wednesday, January 08, 2014 4:42 AM > > To: Wang Dongsheng-B40534 > > Cc: bhelg...@google.com; Wood Scott-B07421; ga...@codeaurora.org; Zang Roy- > > R61911; linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > > Subject: Re: [PATCH 2/2] fsl/pci: The new pci suspend/resume implementation > > > > On Tuesday, January 07, 2014 04:04:08 PM Dongsheng Wang wrote: > > > From: Wang Dongsheng > > > > > > The new suspend/resume implementation, send pme turnoff message > > > in suspend, and send pme exit message in resume. > > > > > > Add a PME handler, to response PME & message interrupt. > > > > > > Change platform_driver->suspend/resume to syscore->suspend/resume. > > > > Can you please first describe the problem you're trying to address? > > > If we do nothing in suspend/resume, some platform PCIe ip-block can't > guarantee > the link back to L0 state from sleep, then, when we read the EP device will > hang. > Only we send pme turnoff message in pci controller suspend, and send pme exit > message in resume, the link state will be normal. > > When we send pme turnoff message in pci controller suspend, the links will > into > l2/l3 > ready, then, host cannot communicate with ep device, but pci-driver will call > back EP > device to save them state. So we need to change > platform_driver->suspend/resume > to > syscore->suspend/resume. > > Thanks, > -Dongsheng > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] rtc/ds3232: Enable ds3232 to work as wakeup source
From: Wang Dongsheng
Add suspend/resume and device_init_wakeup to enable ds3232 as
wakeup source, /sys/class/rtc/rtcX/wakealarm for set wakeup alarm.
Signed-off-by: Wang Dongsheng
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index b83bb5a5..a3c40d5 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -57,6 +57,7 @@ struct ds3232 {
* in the remove function.
*/
struct mutex mutex;
+ bool suspended;
int exiting;
};
@@ -345,7 +346,15 @@ static irqreturn_t ds3232_irq(int irq, void *dev_id)
struct ds3232 *ds3232 = i2c_get_clientdata(client);
disable_irq_nosync(irq);
- schedule_work(&ds3232->work);
+
+ /*
+* If rtc as a wakeup source, can't schedule the work
+* at system resume flow, because at this time the i2c bus
+* has not been resumed.
+*/
+ if (!ds3232->suspended)
+ schedule_work(&ds3232->work);
+
return IRQ_HANDLED;
}
@@ -363,22 +372,26 @@ static void ds3232_work(struct work_struct *work)
if (stat & DS3232_REG_SR_A1F) {
control = i2c_smbus_read_byte_data(client, DS3232_REG_CR);
- if (control < 0)
- goto out;
- /* disable alarm1 interrupt */
- control &= ~(DS3232_REG_CR_A1IE);
- i2c_smbus_write_byte_data(client, DS3232_REG_CR, control);
-
- /* clear the alarm pend flag */
- stat &= ~DS3232_REG_SR_A1F;
- i2c_smbus_write_byte_data(client, DS3232_REG_SR, stat);
-
- rtc_update_irq(ds3232->rtc, 1, RTC_AF | RTC_IRQF);
+ if (control < 0) {
+ pr_warn("Read DS3232 Control Register error."
+ "Disable IRQ%d.\n", client->irq);
+ } else {
+ /* disable alarm1 interrupt */
+ control &= ~(DS3232_REG_CR_A1IE);
+ i2c_smbus_write_byte_data(client, DS3232_REG_CR,
+ control);
+
+ /* clear the alarm pend flag */
+ stat &= ~DS3232_REG_SR_A1F;
+ i2c_smbus_write_byte_data(client, DS3232_REG_SR, stat);
+
+ rtc_update_irq(ds3232->rtc, 1, RTC_AF | RTC_IRQF);
+
+ if (!ds3232->exiting)
+ enable_irq(client->irq);
+ }
}
-out:
- if (!ds3232->exiting)
- enable_irq(client->irq);
unlock:
mutex_unlock(&ds3232->mutex);
}
@@ -411,23 +424,21 @@ static int ds3232_probe(struct i2c_client *client,
if (ret)
return ret;
- ds3232->rtc = devm_rtc_device_register(&client->dev, client->name,
- &ds3232_rtc_ops, THIS_MODULE);
- if (IS_ERR(ds3232->rtc)) {
- dev_err(&client->dev, "unable to register the class device\n");
- return PTR_ERR(ds3232->rtc);
- }
-
- if (client->irq >= 0) {
+ if (client->irq != NO_IRQ) {
ret = devm_request_irq(&client->dev, client->irq, ds3232_irq, 0,
"ds3232", client);
if (ret) {
dev_err(&client->dev, "unable to request IRQ\n");
return ret;
}
+
+ device_init_wakeup(&client->dev, 1);
+
}
- return 0;
+ ds3232->rtc = devm_rtc_device_register(&client->dev, client->name,
+ &ds3232_rtc_ops, THIS_MODULE);
+ return PTR_ERR_OR_ZERO(ds3232->rtc);
}
static int ds3232_remove(struct i2c_client *client)
@@ -446,6 +457,42 @@ static int ds3232_remove(struct i2c_client *client)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int ds3232_suspend(struct device *dev)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ struct i2c_client *client = to_i2c_client(dev);
+
+ if (device_can_wakeup(dev)) {
+ ds3232->suspended = true;
+ irq_set_irq_wake(client->irq, 1);
+ }
+
+ return 0;
+}
+
+static int ds3232_resume(struct device *dev)
+{
+ struct ds3232 *ds3232 = dev_get_drvdata(dev);
+ struct i2c_client *client = to_i2c_client(dev);
+
+ if (ds3232->suspended) {
+ ds3232->suspended = false;
+
+ /* Clear the hardware alarm pend flag */
+ schedule_work(&ds3232->work);
+
+ irq_set_irq_wake(client->irq, 0);
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops ds3232_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(ds3232_suspend, ds3232_resume)
+};
+
static const struct i2c_device_id ds3232_id[] = {
{ "ds3232", 0 },
{ }
@@ -456,6 +503,7 @@ static struct i2c_driver ds3232_driver = {
.driver = {
.name = "rtc-ds3232",
[PATCH] selftests: powerpc: Import Anton's memcpy / copy_tofrom_user tests
Turn Anton's memcpy / copy_tofrom_user test into something that can live in tools/testing/selftests. It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's pretty harmless IMHO. We are sailing very close to the wind with the feature macros. We define them to nothing, which currently means we get a few extra nops and include the unaligned calls. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman --- arch/powerpc/lib/memcpy_64.S | 2 + tools/testing/selftests/powerpc/Makefile | 2 +- tools/testing/selftests/powerpc/copyloops/Makefile | 29 +++ .../selftests/powerpc/copyloops/asm/ppc_asm.h | 86 +++ .../selftests/powerpc/copyloops/asm/processor.h| 0 .../selftests/powerpc/copyloops/copyuser_64.S | 1 + .../selftests/powerpc/copyloops/copyuser_power7.S | 1 + .../selftests/powerpc/copyloops/memcpy_64.S| 1 + .../selftests/powerpc/copyloops/memcpy_power7.S| 1 + .../testing/selftests/powerpc/copyloops/validate.c | 99 ++ tools/testing/selftests/powerpc/utils.h| 3 + 11 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/powerpc/copyloops/Makefile create mode 100644 tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h create mode 100644 tools/testing/selftests/powerpc/copyloops/asm/processor.h create mode 12 tools/testing/selftests/powerpc/copyloops/copyuser_64.S create mode 12 tools/testing/selftests/powerpc/copyloops/copyuser_power7.S create mode 12 tools/testing/selftests/powerpc/copyloops/memcpy_64.S create mode 12 tools/testing/selftests/powerpc/copyloops/memcpy_power7.S create mode 100644 tools/testing/selftests/powerpc/copyloops/validate.c diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S index d2bbbc8..72ad055 100644 --- a/arch/powerpc/lib/memcpy_64.S +++ b/arch/powerpc/lib/memcpy_64.S @@ -14,7 +14,9 @@ _GLOBAL(memcpy) BEGIN_FTR_SECTION std r3,48(r1) /* save destination pointer for return value */ FTR_SECTION_ELSE +#ifndef SELFTEST b memcpy_power7 +#endif ALT_FTR_SECTION_END_IFCLR(CPU_FTR_VMX_COPY) PPC_MTOCRF(0x01,r5) cmpldi cr1,r5,16 diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile index bd24ae5..316194f 100644 --- a/tools/testing/selftests/powerpc/Makefile +++ b/tools/testing/selftests/powerpc/Makefile @@ -13,7 +13,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror -DGIT_VERSION='"$(GIT_VERSION)"' -I$(CUR export CC CFLAGS -TARGETS = pmu +TARGETS = pmu copyloops endif diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile b/tools/testing/selftests/powerpc/copyloops/Makefile new file mode 100644 index 000..6f2d3be --- /dev/null +++ b/tools/testing/selftests/powerpc/copyloops/Makefile @@ -0,0 +1,29 @@ +# The loops are all 64-bit code +CFLAGS += -m64 +CFLAGS += -I$(CURDIR) +CFLAGS += -D SELFTEST + +# Use our CFLAGS for the implicit .S rule +ASFLAGS = $(CFLAGS) + +PROGS := copyuser_64 copyuser_power7 memcpy_64 memcpy_power7 +EXTRA_SOURCES := validate.c ../harness.c + +all: $(PROGS) + +copyuser_64: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_base +copyuser_power7: CPPFLAGS += -D COPY_LOOP=test___copy_tofrom_user_power7 +memcpy_64: CPPFLAGS += -D COPY_LOOP=test_memcpy +memcpy_power7: CPPFLAGS += -D COPY_LOOP=test_memcpy_power7 + +$(PROGS): $(EXTRA_SOURCES) + +run_tests: all + @-for PROG in $(PROGS); do \ + ./$$PROG; \ + done; + +clean: + rm -f $(PROGS) *.o + +.PHONY: all run_tests clean diff --git a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h new file mode 100644 index 000..ccd9c84 --- /dev/null +++ b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h @@ -0,0 +1,86 @@ +#include + +#define CONFIG_ALTIVEC + +#define r1 1 + +#define vr0 0 +#define vr1 1 +#define vr2 2 +#define vr3 3 +#define vr4 4 +#define vr5 5 +#define vr6 6 +#define vr7 7 +#define vr8 8 +#define vr9 9 +#define vr1010 +#define vr1111 +#define vr1212 +#define vr1313 +#define vr1414 +#define vr1515 +#define vr1616 +#define vr1717 +#define vr1818 +#define vr1919 +#define vr2020 +#define vr2121 +#define vr2222 +#define vr2323 +#define vr2424 +#define vr2525 +#define vr2626 +#define vr2727 +#define vr2828 +#define vr2929 +#define vr3030 +#define vr3131 + +#define R14 r14 +#define R15 r15 +#define R16 r16 +#define R17 r17 +#define R18 r18 +#define R19 r19 +#define R20 r20 +#define R21 r21 +#define R22 r22 + +#define STACKFRAMESIZE 256 +#define STK_PARAM(i) (48 + ((i)-3)*8) +#define STK_REG(i) (112 + ((i)-14)*8) + +#define _GLOBAL(A) FUNC_START(test_ ## A) + +#define PPC_MTOCRF(A, B) mtocrf A, B + +FUNC_START(enter_vmx_usercopy) +
Re: [PATCH 0/4] powernv: kvm: numa fault improvement
Liu ping fan writes: > On Mon, Jan 20, 2014 at 11:45 PM, Aneesh Kumar K.V > wrote: >> Liu ping fan writes: >> >>> On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf wrote: On 11.12.2013, at 09:47, Liu Ping Fan wrote: > This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: > Numa faults support for ppc64" > > For this series, I apply the same idea from the previous thread "[PATCH > 0/3] optimize for powerpc _PAGE_NUMA" > (for which, I still try to get a machine to show nums) > > But for this series, I think that I have a good justification -- the fact > of heavy cost when switching context between guest and host, > which is well known. This cover letter isn't really telling me anything. Please put a proper description of what you're trying to achieve, why you're trying to achieve what you're trying and convince your readers that it's a good idea to do it the way you do it. >>> Sorry for the unclear message. After introducing the _PAGE_NUMA, >>> kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it >>> should rely on host's kvmppc_book3s_hv_page_fault() to call >>> do_numa_page() to do the numa fault check. This incurs the overhead >>> when exiting from rmode to vmode. My idea is that in >>> kvmppc_do_h_enter(), we do a quick check, if the page is right placed, >>> there is no need to exit to vmode (i.e saving htab, slab switching) >> >> Can you explain more. Are we looking at hcall from guest and >> hypervisor handling them in real mode ? If so why would guest issue a >> hcall on a pte entry that have PAGE_NUMA set. Or is this about >> hypervisor handling a missing hpte, because of host swapping this page >> out ? In that case how we end up in h_enter ? IIUC for that case we >> should get to kvmppc_hpte_hv_fault. >> > After setting _PAGE_NUMA, we should flush out all hptes both in host's > htab and guest's. So when guest tries to access memory, host finds > that there is not hpte ready for guest in guest's htab. And host > should raise dsi to guest. Now guest receive that fault, removes the PAGE_NUMA bit and do an hpte_insert. So before we do an hpte_insert (or H_ENTER) we should have cleared PAGE_NUMA bit. >This incurs that guest ends up in h_enter. > And you can see in current code, we also try this quick path firstly. > Only if fail, we will resort to slow path -- kvmppc_hpte_hv_fault. hmm ? hpte_hv_fault is the hypervisor handling the fault. -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: T4240: Add ina220 node in dts
From: Tang Yuantian
Add power sensor chip ina220 node in dts to support
power monitor
Signed-off-by: Tang Yuantian
---
arch/powerpc/boot/dts/t4240qds.dts | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 63e81b0..97683f6 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -159,6 +159,48 @@
interrupts = <0x1 0x1 0 0>;
};
};
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220@41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220@45 {
+ compatible = "ti,ina220";
+ reg = <0x45>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220@46 {
+ compatible = "ti,ina220";
+ reg = <0x46>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220@47 {
+ compatible = "ti,ina220";
+ reg = <0x47>;
+ shunt-resistor = <1000>;
+ };
+ };
};
};
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] clk: corenet: Update the clock bindings
From: Tang Yuantian
Main changs include:
- Clarified the clock nodes' version number
- Fixed a issue in example
Singed-off-by: Tang Yuantian
---
Documentation/devicetree/bindings/clock/corenet-clock.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
b/Documentation/devicetree/bindings/clock/corenet-clock.txt
index 24711af..d6cadef 100644
--- a/Documentation/devicetree/bindings/clock/corenet-clock.txt
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -54,6 +54,8 @@ Required properties:
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
+ Note: v1.0 and v2.0 are clock version which should align to
+ clockgen node's they belong to which is chassis version.
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
@@ -85,7 +87,7 @@ Example for clock block and clock provider:
#clock-cells = <0>;
compatible = "fsl,qoriq-sysclk-1.0";
clock-output-names = "sysclk";
- }
+ };
pll0: pll0@800 {
#clock-cells = <1>;
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the core registers
> -Original Message- > From: Wood Scott-B07421 > Sent: Tuesday, January 21, 2014 9:06 AM > To: Wang Dongsheng-B40534 > Cc: b...@kernel.crashing.org; Zhao Chenhui-B35336; an...@enomsg.org; linuxppc- > d...@lists.ozlabs.org > Subject: Re: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore > the > core registers > > On Mon, 2014-01-20 at 00:03 -0600, Wang Dongsheng-B40534 wrote: > > > > > > + /* > > > > > > +* Need to save float-point registers if MSR[FP] = 1. > > > > > > +*/ > > > > > > + mfmsr r12 > > > > > > + andi. r12, r12, MSR_FP > > > > > > + beq 1f > > > > > > + do_sr_fpr_regs(save) > > > > > > > > > > C code should have already ensured that MSR[FP] is not 1 (and thus the > FP > > > > > context has been saved). > > > > > > > > > > > > > Yes, right. But I mean if the FP still use in core save flow, we need to > save > > > it. > > > > In this process, i don't care what other code do, we need to focus on > > > > not > > > losing > > > > valuable data. > > > > > > It is not allowed to use FP at that point. > > > > > If MSR[FP] not active, that is FP not allowed to use. > > But here is a normal judgment, if MSR[FP] is active, this means that the > floating > > point module is being used. I offer is a function of the interface, we don't > know > > where is the function will be called. Just because we call this function in > the > > context of uncertainty, we need this judgment to ensure that no data is > > lost. > > The whole point of calling enable_kernel_fp() in C code before > suspending is to ensure that the FP state gets saved. If FP is used > after that point it is a bug. If you're worried about such bugs, then > clear MSR[FP] after calling enable_kernel_fp(), rather than adding > redundant state saving. > enable_kernel_fp() calling in MEM suspend flow. Hibernation is different with MEM suspend, and I'm not sure where will call this interface, so we need to ensure the integrity of the core saving. I don't think this code is *redundant*. I trust that the kernel can keep the FP related operations, that's why a judgment is here. :) Thanks, -Dongsheng ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] clk: mpc85xx: Update the driver to align to new clock bindings
From: Tang Yuantian
The clock bindings for Freescale CoreNet platform are updated.
So, the driver needs to be updated accordingly.
The main changes include:
- Added a new node to present the input system clock
- Changed PLL and MUX's compatible string
Signed-off-by: Tang Yuantian
---
drivers/clk/clk-ppc-corenet.c | 70 +--
1 file changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index c4f76ed..8b284be 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -27,7 +27,6 @@ struct cmux_clk {
#define CLKSEL_ADJUST BIT(0)
#define to_cmux_clk(p) container_of(p, struct cmux_clk, hw)
-static void __iomem *base;
static unsigned int clocks_per_pll;
static int cmux_set_parent(struct clk_hw *hw, u8 idx)
@@ -100,7 +99,11 @@ static void __init core_mux_init(struct device_node *np)
pr_err("%s: could not allocate cmux_clk\n", __func__);
goto err_name;
}
- cmux_clk->reg = base + offset;
+ cmux_clk->reg = of_iomap(np, 0);
+ if (!cmux_clk->reg) {
+ pr_err("%s: could not map register\n", __func__);
+ goto err_clk;
+ }
node = of_find_compatible_node(NULL, NULL, "fsl,p4080-clockgen");
if (node && (offset >= 0x80))
@@ -143,38 +146,39 @@ err_name:
static void __init core_pll_init(struct device_node *np)
{
- u32 offset, mult;
+ u32 mult;
int i, rc, count;
const char *clk_name, *parent_name;
struct clk_onecell_data *onecell_data;
struct clk **subclks;
+ void __iomem *base;
- rc = of_property_read_u32(np, "reg", &offset);
- if (rc) {
- pr_err("%s: could not get reg property\n", np->name);
+ base = of_iomap(np, 0);
+ if (!base) {
+ pr_err("clk-ppc: iomap error\n");
return;
}
/* get the multiple of PLL */
- mult = ioread32be(base + offset);
+ mult = ioread32be(base);
/* check if this PLL is disabled */
if (mult & PLL_KILL) {
pr_debug("PLL:%s is disabled\n", np->name);
- return;
+ goto err_map;
}
mult = (mult >> 1) & 0x3f;
parent_name = of_clk_get_parent_name(np, 0);
if (!parent_name) {
pr_err("PLL: %s must have a parent\n", np->name);
- return;
+ goto err_map;
}
count = of_property_count_strings(np, "clock-output-names");
if (count < 0 || count > 4) {
pr_err("%s: clock is not supported\n", np->name);
- return;
+ goto err_map;
}
/* output clock number per PLL */
@@ -183,7 +187,7 @@ static void __init core_pll_init(struct device_node *np)
subclks = kzalloc(sizeof(struct clk *) * count, GFP_KERNEL);
if (!subclks) {
pr_err("%s: could not allocate subclks\n", __func__);
- return;
+ goto err_map;
}
onecell_data = kzalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
@@ -230,30 +234,52 @@ static void __init core_pll_init(struct device_node *np)
goto err_cell;
}
+ iounmap(base);
return;
err_cell:
kfree(onecell_data);
err_clks:
kfree(subclks);
+err_map:
+ iounmap(base);
+}
+
+static void __init sysclk_init(struct device_node *node)
+{
+ struct clk *clk;
+ const char *clk_name = node->name;
+ struct device_node *np = of_get_parent(node);
+ u32 rate;
+
+ if (!np) {
+ pr_err("ppc-clk: could not get parent node\n");
+ return;
+ }
+
+ if (of_property_read_u32(np, "clock-frequency", &rate)) {
+ of_node_put(node);
+ return;
+ }
+
+ of_property_read_string(np, "clock-output-names", &clk_name);
+
+ clk = clk_register_fixed_rate(NULL, clk_name, NULL, CLK_IS_ROOT, rate);
+ if (!IS_ERR(clk))
+ of_clk_add_provider(np, of_clk_src_simple_get, clk);
}
static const struct of_device_id clk_match[] __initconst = {
- { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
- { .compatible = "fsl,core-pll-clock", .data = core_pll_init, },
- { .compatible = "fsl,core-mux-clock", .data = core_mux_init, },
+ { .compatible = "fsl,qoriq-sysclk-1.0", .data = sysclk_init, },
+ { .compatible = "fsl,qoriq-sysclk-2.0", .data = sysclk_init, },
+ { .compatible = "fsl,qoriq-core-pll-1.0", .data = core_pll_init, },
+ { .compatible = "fsl,qoriq-core-pll-2.0", .data = core_pll_init, },
+ { .compatible = "fsl,qoriq-core-mux-1.0", .data = core_mux_init, },
+ { .compatible = "fsl,qoriq-core-mux-2.0", .data = core_mux_init, },
{}
};
static int __init ppc_corenet_clk_probe(
Re: [PATCH 0/4] powernv: kvm: numa fault improvement
On Mon, Jan 20, 2014 at 11:45 PM, Aneesh Kumar K.V wrote: > Liu ping fan writes: > >> On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf wrote: >>> >>> On 11.12.2013, at 09:47, Liu Ping Fan wrote: >>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa faults support for ppc64" For this series, I apply the same idea from the previous thread "[PATCH 0/3] optimize for powerpc _PAGE_NUMA" (for which, I still try to get a machine to show nums) But for this series, I think that I have a good justification -- the fact of heavy cost when switching context between guest and host, which is well known. >>> >>> This cover letter isn't really telling me anything. Please put a proper >>> description of what you're trying to achieve, why you're trying to achieve >>> what you're trying and convince your readers that it's a good idea to do it >>> the way you do it. >>> >> Sorry for the unclear message. After introducing the _PAGE_NUMA, >> kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it >> should rely on host's kvmppc_book3s_hv_page_fault() to call >> do_numa_page() to do the numa fault check. This incurs the overhead >> when exiting from rmode to vmode. My idea is that in >> kvmppc_do_h_enter(), we do a quick check, if the page is right placed, >> there is no need to exit to vmode (i.e saving htab, slab switching) > > Can you explain more. Are we looking at hcall from guest and > hypervisor handling them in real mode ? If so why would guest issue a > hcall on a pte entry that have PAGE_NUMA set. Or is this about > hypervisor handling a missing hpte, because of host swapping this page > out ? In that case how we end up in h_enter ? IIUC for that case we > should get to kvmppc_hpte_hv_fault. > After setting _PAGE_NUMA, we should flush out all hptes both in host's htab and guest's. So when guest tries to access memory, host finds that there is not hpte ready for guest in guest's htab. And host should raise dsi to guest. This incurs that guest ends up in h_enter. And you can see in current code, we also try this quick path firstly. Only if fail, we will resort to slow path -- kvmppc_hpte_hv_fault. Thanks and regards, Fan > >> If my suppose is correct, will CCing k...@vger.kernel.org from next version. >>> >>> This translates to me as "This is an RFC"? >>> >> Yes, I am not quite sure about it. I have no bare-metal to verify it. >> So I hope at least, from the theory, it is correct. >> > > -aneesh > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
On Mon, Jan 20, 2014 at 04:13:30PM -0600, Christoph Lameter wrote:
>On Mon, 20 Jan 2014, Wanpeng Li wrote:
>
>> >+ enum zone_type high_zoneidx = gfp_zone(flags);
>> >
>> >+ if (!node_present_pages(searchnode)) {
>> >+ zonelist = node_zonelist(searchnode, flags);
>> >+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
>> >+ searchnode = zone_to_nid(zone);
>> >+ if (node_present_pages(searchnode))
>> >+ break;
>> >+ }
>> >+ }
>> >object = get_partial_node(s, get_node(s, searchnode), c, flags);
>> >if (object || node != NUMA_NO_NODE)
>> >return object;
>> >
>>
>> The patch fix the bug. However, the kernel crashed very quickly after running
>> stress tests for a short while:
>
>This is not a good way of fixing it. How about not asking for memory from
>nodes that are memoryless? Use numa_mem_id() which gives you the next node
>that has memory instead of numa_node_id() (gives you the current node
>regardless if it has memory or not).
Thanks for your pointing out, I will do it and retest it later.
Regards,
Wanpeng Li
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/85xx: Provide two functions to save/restore the core registers
On Mon, 2014-01-20 at 00:03 -0600, Wang Dongsheng-B40534 wrote: > > > > > + /* > > > > > + * Need to save float-point registers if MSR[FP] = 1. > > > > > + */ > > > > > + mfmsr r12 > > > > > + andi. r12, r12, MSR_FP > > > > > + beq 1f > > > > > + do_sr_fpr_regs(save) > > > > > > > > C code should have already ensured that MSR[FP] is not 1 (and thus the > > > > FP > > > > context has been saved). > > > > > > > > > > Yes, right. But I mean if the FP still use in core save flow, we need to > > > save > > it. > > > In this process, i don't care what other code do, we need to focus on not > > losing > > > valuable data. > > > > It is not allowed to use FP at that point. > > > If MSR[FP] not active, that is FP not allowed to use. > But here is a normal judgment, if MSR[FP] is active, this means that the > floating > point module is being used. I offer is a function of the interface, we don't > know > where is the function will be called. Just because we call this function in > the > context of uncertainty, we need this judgment to ensure that no data is lost. The whole point of calling enable_kernel_fp() in C code before suspending is to ensure that the FP state gets saved. If FP is used after that point it is a bug. If you're worried about such bugs, then clear MSR[FP] after calling enable_kernel_fp(), rather than adding redundant state saving. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
On Sat, 2014-01-18 at 09:16 +0530, Prabhakar Kushwaha wrote: > On 1/18/2014 12:19 AM, Scott Wood wrote: > > On Fri, 2014-01-17 at 11:02 -0600, Kumar Gala wrote: > >> On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha > >> wrote: > >> > >>> Currently IFC NAND driver is enabled in corenet32smp_defconfig. But IFC > >>> controller is not enabled > >>> > >>> So, Enable IFC controller in corenet32smp_defconfig. > >>> > >>> Signed-off-by: Prabhakar Kushwaha > >>> --- > >>> Based upon > >>> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git > >>> branch master > >>> > >>> arch/powerpc/configs/corenet32_smp_defconfig |1 + > >>> 1 file changed, 1 insertion(+) > >> Shouldn’t the NAND driver get the IFC controller enabled by Kconfig > >> dependancies? > > Yes (by select, not dependencies). > > > > Prabhakar, was there an actual problem you saw before? Did you run > > savedefconfig after making this change? > > > > CONFIG_FSL_IFC isn't even user-selectable (though it probably should be, > > as how else would it get enabled in the absence of NAND for catching NOR > > errors?). > > > > Thanks Kumar and Scott for reviewing this patch. > > Yes, it should be enabled by Kconfig dependency. as we have > config FSL_IFC > bool > depends on FSL_SOC > > The only reason I changed this code because i wanted all powerpc/configs > to be similar as they have CONFIG_FSL_IFC enabled by default. > > arch/powerpc/configs/mpc85xx_smp_defconfig:54:CONFIG_FSL_IFC=y > arch/powerpc/configs/corenet64_smp_defconfig:29:CONFIG_FSL_IFC=y > arch/powerpc/configs/mpc85xx_defconfig:51:CONFIG_FSL_IFC=y > > So either I should add in corenet32smp_defconfig to make similar to others. > or > remove from all. > > I chose first option. Those other defconfigs are wrong, since they differ from what you'd get after running "make savedefconfig". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
On Mon, 2014-01-20 at 17:38 +0100, Valentin Longchamp wrote:
> On 01/17/2014 10:48 PM, Scott Wood wrote:
> > On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
> >> Hi Scott,
> >>
> >> Thanks for you feedback.
> >>
> >> On 01/17/2014 12:35 AM, Scott Wood wrote:
> >>> On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
> This patch introduces the support for Keymile's kmp204x reference
> design. This design is based on Freescale's P2040/P2041 SoC.
>
> The peripherals used by this design are:
> - SPI NOR Flash as bootloader medium
> - NAND Flash with a ubi partition
> - 2 PCIe busses (hosts 1 and 3)
> - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
> - 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
> FPGA
> - 2 HW I2C busses
> - last but not least, the mandatory serial port
>
> The patch also adds a defconfig file for this reference design and a DTS
> file for the kmcoge4 board which is the first one based on this
> reference design.
>
> To try to avoid code duplication, the support was added directly to the
> corenet_generic.c file.
>
> Signed-off-by: Valentin Longchamp
> ---
> arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
> arch/powerpc/configs/85xx/kmp204x_defconfig | 231
> ++
> arch/powerpc/platforms/85xx/Kconfig | 14 ++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
> 5 files changed, 463 insertions(+)
> create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
> create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
>
> diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
> b/arch/powerpc/boot/dts/kmcoge4.dts
> new file mode 100644
> index 000..c10df6d
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/kmcoge4.dts
> @@ -0,0 +1,165 @@
> +/*
> + * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
> + *
> + * (C) Copyright 2014
> + * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
> + *
> + * Copyright 2011 Freescale Semiconductor Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms of the GNU General Public License as published by
> the
> + * Free Software Foundation; either version 2 of the License, or (at
> your
> + * option) any later version.
> + */
> +
> +/include/ "fsl/p2041si-pre.dtsi"
> +
> +/ {
> +model = "keymile,kmcoge4";
> +compatible = "keymile,kmp204x";
> >>>
> >>> Don't put wildcards in compatible.
> >>
> >> Well it's a wildcard in the sense that we support both the p2040 and the
> >> p2041,
> >> but it's also the name of the plaftorm, similarly to names like '85xx' or
> >> 'tqm85xx'.
> >
> > Names like 85xx are not allowed in device trees.
> >
> > With "p204x", what would happen if a p2042 were introduced, that were
> > not compatible?
>
> What would you suggest as a generic name for the architecture that supports
> both ?
>
> >
> > Why isn't the compatible "keymile,kmcoge4", like the model?
>
> Because kmcoge4 is the board that is based on the kmp204x architecture/design.
> We expect other boards (kmcoge7 for instance) based on the same kmp204x
> design.
The top-level compatible isn't for the "architecture" or the "design".
It's for the board. Surely there's something different about kmcoge7
versus kmcoge4 -- is it visible to software?
> You would prefer that I have the model and compatible stricly the same and add
> any future board into the compatible boards[] from corenet_generic ?
That's how it's usually done. Or, at least provide the board
architecture name as a secondary compatible after the board name.
> If possible I would like to be able to see the boards that are based on a
> similar design, that's what I wanted to achieve with this kmp204x name.
Is "kmp204x" an official name of the architecture, rather than a
generalization of "kmp2040" and "kmp2041"? If there were a p2042, and
you made a board for it, is there any chance it would be called kmp204x
even if it were very different from the p2040/p2041 board?
> +zl30343@1 {
> +compatible = "gen,spidev";
> >>>
> >>> Node names are supposed to be generic. Compatibles are supposed to be
> >>> specific.
> >>
> >> That's a very specific device for which we only have a userspace driver
> >> and for
> >> which we must use the generic kernel spidev driver.
> >
> > The device tree describes the hardware, not what driver you want to use.
> >
> > Plus, I don't see any driver that matches "gen,spidev" nor any binding
> > for it, and "gen" doesn't make sense as a vendor
Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
On Mon, 20 Jan 2014, Wanpeng Li wrote:
> >+ enum zone_type high_zoneidx = gfp_zone(flags);
> >
> >+ if (!node_present_pages(searchnode)) {
> >+ zonelist = node_zonelist(searchnode, flags);
> >+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
> >+ searchnode = zone_to_nid(zone);
> >+ if (node_present_pages(searchnode))
> >+ break;
> >+ }
> >+ }
> >object = get_partial_node(s, get_node(s, searchnode), c, flags);
> >if (object || node != NUMA_NO_NODE)
> >return object;
> >
>
> The patch fix the bug. However, the kernel crashed very quickly after running
> stress tests for a short while:
This is not a good way of fixing it. How about not asking for memory from
nodes that are memoryless? Use numa_mem_id() which gives you the next node
that has memory instead of numa_node_id() (gives you the current node
regardless if it has memory or not).
[ 287.464285] Unable to handle kernel paging request for data at address
0x0001
[ 287.464289] Faulting instruction address: 0xc0445af8
[ 287.464294] Oops: Kernel access of bad area, sig: 11 [#1]
[ 287.464296] SMP NR_CPUS=2048 NUMA pSeries
[ 287.464301] Modules linked in: btrfs raid6_pq xor dm_service_time sg nfsv3
arc4 md4 rpcsec_gss_krb5 nfsv4 nls_utf8 cifs nfs fscache dns_resolver
nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT
ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc
ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter
ip_tables ext4 mbcache jbd2 ibmvfc scsi_transport_fc ibmveth nx_crypto
pseries_rng nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc uinput
dm_multipath xfs libcrc32c sd_mod crc_t10dif crct10dif_common ibmvscsi
scsi_transport_srp scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[ 287.464374] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.10.0-71.el7.91831.ppc64 #1
[ 287.464378] task: c0fde590 ti: c001fffd task.ti:
c10a4000
[ 287.464382] NIP: c0445af8 LR: c0445bcc CTR: c0445b90
[ 287.464385] REGS: c001fffd38e0 TRAP: 0300 Not tainted
(3.10.0-71.el7.91831.ppc64)
[ 287.464388] MSR: 80009032 CR: 88002084 XER:
0001
[ 287.464397] SOFTE: 0
[ 287.464398] CFAR: c000908c
[ 287.464401] DAR: 0001, DSISR: 4000
[ 287.464403]
GPR00: d3649a04 c001fffd3b60 c10a94d0 0003
GPR04: c0018d841048 c001fffd3bd0 0012 d364eff0
GPR08: c001fffd3bd0 0001 d364d688 c0445b90
GPR12: d364b960 c7e0 042ac510 0060
GPR16: 0020 fb19 c1122100
GPR20: c0a94680 c1122180 c0a94680 000a
GPR24: 0100 0001 c001ef90
GPR28: c001d6c066f0 c001aea03520 c001bc9a2640 c0018d841680
[ 287.464447] NIP [c0445af8] .__dev_printk+0x28/0xc0
[ 287.464450] LR [c0445bcc] .dev_printk+0x3c/0x50
[ 287.464453] PACATMSCRATCH [80009032]
[ 287.464455] Call Trace:
[ 287.464458] [c001fffd3b60] [c001fffd3c00] 0xc001fffd3c00
(unreliable)
[ 287.464467] [c001fffd3bf0] [d3649a04]
.ibmvfc_scsi_done+0x334/0x3e0 [ibmvfc]
[ 287.464474] [c001fffd3cb0] [d36495b8]
.ibmvfc_handle_crq+0x2e8/0x320 [ibmvfc]
[ 287.464488] [c001fffd3d30] [d3649fe4] .ibmvfc_tasklet+0xd4/0x250
[ibmvfc]
[ 287.464494] [c001fffd3de0] [c009b46c] .tasklet_action+0xcc/0x1b0
[ 287.464498] [c001fffd3e90] [c009a668] .__do_softirq+0x148/0x360
[ 287.464503] [c001fffd3f90] [c00218a8] .call_do_softirq+0x14/0x24
[ 287.464507] [c001fffcfdf0] [c00107e0] .do_softirq+0xd0/0x100
[ 287.464511] [c001fffcfe80] [c009aba8] .irq_exit+0x1b8/0x1d0
[ 287.464514] [c001fffcff10] [c0010410] .__do_irq+0xc0/0x1e0
[ 287.464518] [c001fffcff90] [c00218cc] .call_do_irq+0x14/0x24
[ 287.464522] [c10a76d0] [c00105bc] .do_IRQ+0x8c/0x100
[ 287.464527] --- Exception: 501 at 0x
[ 287.464527] LR = .arch_local_irq_restore+0x74/0x90
[ 287.464533] [c10a7770] [c0002494]
hardware_interrupt_common+0x114/0x180 (unreliable)
[ 287.464540] --- Exception: 501 at .plpar_hcall_norets+0x84/0xd4
[ 287.464540] LR = .check_and_cede_processor+0x24/0x40
[ 287.464546] [c10a7a60] [0001] 0x1 (unreliable)
[ 287.464550] [c10a7ad0] [c0074ecc] .shared_cede_loop+0x2c/0x70
[ 287.464555] [c10a7b50] [c0553
Re: [PATCH] powerpc: hugetlb: replace __get_cpu_var with get_cpu_var
On Mon, 2014-01-20 at 16:39 +0800, Tiejun Chen wrote:
> if (atomic_read(&tlb->mm->mm_users) < 2 ||
> cpumask_equal(mm_cpumask(tlb->mm),
> cpumask_of(smp_processor_id( {
> kmem_cache_free(hugepte_cache, hugepte);
> +put_cpu_var(hugepd_freelist_cur);
> return;
> }
>
Whitespace
> @@ -491,6 +492,7 @@ static void hugepd_free(struct mmu_gather *tlb, void
> *hugepte)
> call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
> *batchp = NULL;
> }
> + put_cpu_var(hugepd_freelist_cur);
> }
A blank line before "put_cpu_var" would be nice.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kconfig: Remove TSI108_BRIDGE duplicates
The MPC7448HPC2 and PPC_HOLLY config options contain TSI108_BRIDGE duplicates since commit: commit 3490cba56f7f8a78ef4c94814c3181f09ce1e2ef Author: Jon Loeliger Date: Wed Jan 23 12:42:50 2008 -0600 [POWERPC] Add initial iomega StorCenter board port. This patch cleans these duplicates. Signed-off-by: Luis Henriques --- arch/powerpc/platforms/embedded6xx/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig index 302ba43..59bd9cd 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -34,7 +34,6 @@ config MPC7448HPC2 select TSI108_BRIDGE select DEFAULT_UIMAGE select PPC_UDBG_16550 - select TSI108_BRIDGE help Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga) platform @@ -44,7 +43,6 @@ config PPC_HOLLY depends on EMBEDDED6xx select TSI108_BRIDGE select PPC_UDBG_16550 - select TSI108_BRIDGE help Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval Board with TSI108/9 bridge (Hickory/Holly) -- 1.8.3.2 Cheers, -- Luis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpic: Fix build errors for CONFIG_MPIC_WEIRD
When CONFIG_MPIC_WEIRD is defined, the following build error occurs:
arch/powerpc/sysdev/mpic.c: In function 'mpic_set_irq_type':
arch/powerpc/sysdev/mpic.c:892:9: error: case label does not reduce to an
integer constant
MPIC_INFO(VECPRI_POLARITY_POSITIVE):
^
arch/powerpc/sysdev/mpic.c:896:9: error: case label does not reduce to an
integer constant
MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
^
arch/powerpc/sysdev/mpic.c:900:9: error: case label does not reduce to an
integer constant
MPIC_INFO(VECPRI_POLARITY_POSITIVE):
^
arch/powerpc/sysdev/mpic.c:904:9: error: case label does not reduce to an
integer constant
MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
^
This is because the case labels are built by accessing mpic->hw_set, and not an
integer constant.
Fixes: 446f6d06fab0 ("powerpc/mpic: Properly set default triggers")
Cc: (3.4+)
Signed-off-by: Luis Henriques
---
arch/powerpc/sysdev/mpic.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 0e166ed..e7bf1a2 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -886,25 +886,21 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int
flow_type)
/* Default: read HW settings */
if (flow_type == IRQ_TYPE_DEFAULT) {
- switch(vold & (MPIC_INFO(VECPRI_POLARITY_MASK) |
- MPIC_INFO(VECPRI_SENSE_MASK))) {
- case MPIC_INFO(VECPRI_SENSE_EDGE) |
-MPIC_INFO(VECPRI_POLARITY_POSITIVE):
- flow_type = IRQ_TYPE_EDGE_RISING;
- break;
- case MPIC_INFO(VECPRI_SENSE_EDGE) |
-MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
- flow_type = IRQ_TYPE_EDGE_FALLING;
- break;
- case MPIC_INFO(VECPRI_SENSE_LEVEL) |
-MPIC_INFO(VECPRI_POLARITY_POSITIVE):
- flow_type = IRQ_TYPE_LEVEL_HIGH;
- break;
- case MPIC_INFO(VECPRI_SENSE_LEVEL) |
-MPIC_INFO(VECPRI_POLARITY_NEGATIVE):
- flow_type = IRQ_TYPE_LEVEL_LOW;
- break;
- }
+ unsigned int info;
+ info = vold & (MPIC_INFO(VECPRI_POLARITY_MASK) |
+ MPIC_INFO(VECPRI_SENSE_MASK));
+ if (info == (MPIC_INFO(VECPRI_SENSE_EDGE) |
+MPIC_INFO(VECPRI_POLARITY_POSITIVE)))
+ flow_type = IRQ_TYPE_EDGE_RISING;
+ else if (info == (MPIC_INFO(VECPRI_SENSE_EDGE) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE)))
+ flow_type = IRQ_TYPE_EDGE_FALLING;
+ else if (info == (MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_POSITIVE)))
+ flow_type = IRQ_TYPE_LEVEL_HIGH;
+ else if (info == (MPIC_INFO(VECPRI_SENSE_LEVEL) |
+ MPIC_INFO(VECPRI_POLARITY_NEGATIVE)))
+ flow_type = IRQ_TYPE_LEVEL_LOW;
}
/* Apply to irq desc */
--
1.8.3.2
Cheers,
--
Luis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix build dependencies for storcenter
This fixes a build failure that seems to be present since commit
commit b81f18e55e9f4ea81759bcb00fea295de679bbe8
Author: Tony Breeds
Date: Tue Apr 3 15:00:39 2012 +
powerpc/boot: Only build board support files when required.
This is easily reproducible my using the storcenter_defconfig config file:
arch/powerpc/boot/cuboot-pq2.o: In function `pq2_platform_fixups':
cuboot-pq2.c:(.text+0x30c): undefined reference to `fsl_get_immr'
make[1]: *** [arch/powerpc/boot/cuImage.storcenter] Error 1
Fixes: b81f18e55e9f ("powerpc/boot: Only build board support files when
required.")
Cc: Tony Breeds
Cc: (3.6+)
Signed-off-by: Luis Henriques
---
arch/powerpc/boot/Makefile | 2 +-
arch/powerpc/boot/wrapper | 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 981d418..cf8e5db 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -95,7 +95,7 @@ src-plat-$(CONFIG_FSL_SOC_BOOKE) += cuboot-85xx.c
cuboot-85xx-cpm2.c
src-plat-$(CONFIG_EMBEDDED6xx) += cuboot-pq2.c cuboot-mpc7448hpc2.c \
cuboot-c2k.c gamecube-head.S \
gamecube.c wii-head.S wii.c holly.c \
- prpmc2800.c
+ prpmc2800.c fsl-soc.c
src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c epapr-wrapper.c
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 2e1af74..4d90b98 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -190,9 +190,12 @@ cuboot*)
*5200*|*-motionpro)
platformo=$object/cuboot-52xx.o
;;
-*-pq2fads|*-ep8248e|*-mpc8272*|*-storcenter)
+*-pq2fads|*-ep8248e|*-mpc8272*)
platformo=$object/cuboot-pq2.o
;;
+*-storcenter)
+ platformo="$object/cuboot-pq2.o $object/fsl-soc.o"
+ ;;
*-mpc824*)
platformo=$object/cuboot-824x.o
;;
--
1.8.3.2
Cheers,
--
Luis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix build dependencies for ep88xc
This fixes a build failure that seems to be present since commit
commit b81f18e55e9f4ea81759bcb00fea295de679bbe8
Author: Tony Breeds
Date: Tue Apr 3 15:00:39 2012 +
powerpc/boot: Only build board support files when required.
This is easily reproducible my using the ep88xc_defconfig config file:
arch/powerpc/boot/wrapper.a(mpc8xx.o): In function `mpc885_get_clock':
/home/henrix/src/linux/arch/powerpc/boot/mpc8xx.c:30: undefined reference to
`fsl_get_immr'
make[1]: *** [arch/powerpc/boot/dtbImage.ep88xc] Error 1
Fixes: b81f18e55e9f ("powerpc/boot: Only build board support files when
required.")
Cc: Tony Breeds
Cc: (3.6+)
Signed-off-by: Luis Henriques
---
arch/powerpc/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ca7f08c..981d418 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -71,7 +71,7 @@ src-wlib-y := string.S crt0.S crtsavres.S stdio.c main.c \
uartlite.c mpc52xx-psc.c
src-wlib-$(CONFIG_40x) += 4xx.c planetcore.c
src-wlib-$(CONFIG_44x) += 4xx.c ebony.c bamboo.c
-src-wlib-$(CONFIG_8xx) += mpc8xx.c planetcore.c
+src-wlib-$(CONFIG_8xx) += mpc8xx.c fsl-soc.c planetcore.c
src-wlib-$(CONFIG_PPC_82xx) += pq2.c fsl-soc.c planetcore.c
src-wlib-$(CONFIG_EMBEDDED6xx) += mv64x60.c mv64x60_i2c.c ugecon.c
--
1.8.3.2
Cheers,
--
Luis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: 85xx: EDAC PCI: request irq as IRQF_SHARED
On Mon, 2014-01-20 at 16:39 +0800, Tiejun Chen wrote:
> AER driver needs to share this PCI err irq with EDAC, otherwise
> we can't register AER driver successfully as follows:
>
> genirq: Flags mismatch irq 482. 0080 (aerdrv) vs. 0020 ([EDAC] PCI
> err)
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
> Call Trace:
> [ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
> [ee063cf0] [c055fac4] dump_stack+0x78/0xa0
> [ee063d00] [c006e16c] __setup_irq+0x51c/0x540
> [ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
> [ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
> [ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
> [ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
> [ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
> [ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
> [ee063e30] [c02c1f94] driver_attach+0x24/0x40
> [ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
> [ee063e60] [c02c2d98] driver_register+0x88/0x140
> [ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
> [ee063e80] [c06fb14c] aer_service_init+0x28/0x38
> [ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
> [ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
> [ee063f30] [c0002ac4] kernel_init+0x14/0x130
> [ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
> aer: probe of :00:00.0:pcie02 failed with error -16
> genirq: Flags mismatch irq 480. 0080 (aerdrv) vs. 0020 ([EDAC] PCI
> err)
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
> Call Trace:
> [ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
> [ee063cf0] [c055fac4] dump_stack+0x78/0xa0
> [ee063d00] [c006e16c] __setup_irq+0x51c/0x540
> [ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
> [ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
> [ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
> [ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
> [ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
> [ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
> [ee063e30] [c02c1f94] driver_attach+0x24/0x40
> [ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
> [ee063e60] [c02c2d98] driver_register+0x88/0x140
> [ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
> [ee063e80] [c06fb14c] aer_service_init+0x28/0x38
> [ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
> [ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
> [ee063f30] [c0002ac4] kernel_init+0x14/0x130
> [ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
> aer: probe of 0001:02:00.0:pcie02 failed with error -16
>
> Signed-off-by: Tiejun Chen
> ---
> drivers/edac/mpc85xx_edac.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
This patch should be sent to the maintainer and list specified under
EDAC-MPC85XX.
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index fd46b0b..0dda7c4 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -297,7 +297,8 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
> if (edac_op_state == EDAC_OPSTATE_INT) {
> pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
> res = devm_request_irq(&op->dev, pdata->irq,
> -mpc85xx_pci_isr, IRQF_DISABLED,
> +mpc85xx_pci_isr, IRQF_SHARED |
> +IRQF_DISABLED,
> "[EDAC] PCI err", pci);
> if (res < 0) {
> printk(KERN_ERR
While you're touching this, perhaps remove IRQF_DISABLED which is a
deprecated no-op and will eventually be removed.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/13] ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd()
Hi, Le lundi 13 janvier 2014 à 10:30 +0100, Yann Droneaud a écrit : > Le lundi 13 janvier 2014 à 10:06 +1100, Benjamin Herrenschmidt a écrit : > > On Tue, 2013-07-02 at 18:39 +0200, Yann Droneaud wrote: > > > Macro get_unused_fd() is used to allocate a file descriptor with > > > default flags. Those default flags (0) can be "unsafe": > > > O_CLOEXEC must be used by default to not leak file descriptor > > > across exec(). > > > > > > Instead of macro get_unused_fd(), functions anon_inode_getfd() > > > or get_unused_fd_flags() should be used with flags given by userspace. > > > If not possible, flags should be set to O_CLOEXEC to provide userspace > > > with a default safe behavor. > > > > > > In a further patch, get_unused_fd() will be removed so that > > > new code start using anon_inode_getfd() or get_unused_fd_flags() > > > with correct flags. > > > > > > This patch replaces calls to get_unused_fd() with equivalent call to > > > get_unused_fd_flags(0) to preserve current behavor for existing code. > > > > > > The hard coded flag value (0) should be reviewed on a per-subsystem basis, > > > and, if possible, set to O_CLOEXEC. > > > > > > Signed-off-by: Yann Droneaud > > > > Should I merge this (v5 on patchwork) or let Al do it ? > > > > Please merge it directly: patches from the previous patchsets were > picked individually by each subsystem maintainer after proper review > regarding setting close on exec flag by default. > > > Acked-by: Benjamin Herrenschmidt > > > > Thanks a lot. > Note: > latest patch (from v5 patchset) is at > http://lkml.kernel.org/r/fe27abcfab5563d36a3e5e58ff36e5500c39be6a.1388952061.git.ydrone...@opteya.com > v5 patchset is at > http://lkml.kernel.org/r/cover.1388952061.git.ydrone...@opteya.com > I have not yet seen the patch in your trees at https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/ I hope you would pick the patch, if possible in its latest version (unfortunately I'm not able to give the link to the astest patch in patchwork). Regards. -- Yann Droneaud OPTEYA ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC] powerpc/mpc85xx: add support for the kmp204x reference board
On 01/17/2014 10:48 PM, Scott Wood wrote:
> On Fri, 2014-01-17 at 13:51 +0100, Valentin Longchamp wrote:
>> Hi Scott,
>>
>> Thanks for you feedback.
>>
>> On 01/17/2014 12:35 AM, Scott Wood wrote:
>>> On Thu, 2014-01-16 at 14:38 +0100, Valentin Longchamp wrote:
This patch introduces the support for Keymile's kmp204x reference
design. This design is based on Freescale's P2040/P2041 SoC.
The peripherals used by this design are:
- SPI NOR Flash as bootloader medium
- NAND Flash with a ubi partition
- 2 PCIe busses (hosts 1 and 3)
- 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5)
- 4 Local Bus windows, with one dedicated to the QRIO reset/power mgmt
FPGA
- 2 HW I2C busses
- last but not least, the mandatory serial port
The patch also adds a defconfig file for this reference design and a DTS
file for the kmcoge4 board which is the first one based on this
reference design.
To try to avoid code duplication, the support was added directly to the
corenet_generic.c file.
Signed-off-by: Valentin Longchamp
---
arch/powerpc/boot/dts/kmcoge4.dts | 165 ++
arch/powerpc/configs/85xx/kmp204x_defconfig | 231
++
arch/powerpc/platforms/85xx/Kconfig | 14 ++
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/corenet_generic.c | 52 ++
5 files changed, 463 insertions(+)
create mode 100644 arch/powerpc/boot/dts/kmcoge4.dts
create mode 100644 arch/powerpc/configs/85xx/kmp204x_defconfig
diff --git a/arch/powerpc/boot/dts/kmcoge4.dts
b/arch/powerpc/boot/dts/kmcoge4.dts
new file mode 100644
index 000..c10df6d
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmcoge4.dts
@@ -0,0 +1,165 @@
+/*
+ * Keymile kmcoge4 Device Tree Source, based on the P2041RDB DTS
+ *
+ * (C) Copyright 2014
+ * Valentin Longchamp, Keymile AG, valentin.longch...@keymile.com
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
+
+/include/ "fsl/p2041si-pre.dtsi"
+
+/ {
+ model = "keymile,kmcoge4";
+ compatible = "keymile,kmp204x";
>>>
>>> Don't put wildcards in compatible.
>>
>> Well it's a wildcard in the sense that we support both the p2040 and the
>> p2041,
>> but it's also the name of the plaftorm, similarly to names like '85xx' or
>> 'tqm85xx'.
>
> Names like 85xx are not allowed in device trees.
>
> With "p204x", what would happen if a p2042 were introduced, that were
> not compatible?
What would you suggest as a generic name for the architecture that supports
both ?
>
> Why isn't the compatible "keymile,kmcoge4", like the model?
Because kmcoge4 is the board that is based on the kmp204x architecture/design.
We expect other boards (kmcoge7 for instance) based on the same kmp204x design.
You would prefer that I have the model and compatible stricly the same and add
any future board into the compatible boards[] from corenet_generic ?
If possible I would like to be able to see the boards that are based on a
similar design, that's what I wanted to achieve with this kmp204x name.
>
>>> I realize it's common practice, but it would be good to get away from
>>> putting partition layouts in the dts file. Alternatives include using
>>> mtdparts on the command line, or having U-Boot put the partition info
>>> into the dtb based on the mtdparts environment variable (there is
>>> existing code for this).
>>
>> I agree that u-boot also has to know about the addresses because it also
>> accesses these partitions.
>>
>> But I think it is clearer to have this in the device tree: I try to keep the
>> kernel command line small and I don't like having u-boot "fixing" the dtb at
>> runtime.
>
> The problem is that the dts source is often far removed from the actual
> programming of flash, and the partitioning can vary based on use case,
> or change for other reasons (e.g. there have been requests to change
> existing partition layouts to accommodate growth in U-Boot size).
>
> Ideally it wouldn't be in the device tree at all, but having U-Boot fix
> it up based on an environment variable is better than statically
> defining it in a file in the Linux tree.
>
+ zl30343@1 {
+ compatible = "gen,spidev";
>>>
>>> Node names are supposed to be generic. Compatibles are supposed to be
>>> specific.
>>
>> That's a very specific device for which we only have a userspace driver and
>> for
>> which we must use the generic kernel spidev driver.
>
>
RE: [PATCH][v2] powerpc/pci: Fix IMMRBAR address
> -Original Message- > From: Minghuan Lian [mailto:minghuan.l...@freescale.com] > Sent: Monday, January 20, 2014 4:54 AM > To: linuxppc-dev@lists.ozlabs.org > Cc: Zang Roy-R61911; Wood Scott-B07421; Kumar Gala; Lian Minghuan-B31939 > Subject: [PATCH][v2] powerpc/pci: Fix IMMRBAR address > > For PEXCSRBAR, bit 3-0 indicate prefetchable and address type. > So when getting base address, these bits should be masked, > otherwise we may get incorrect base address. > > Signed-off-by: Minghuan Lian Acked. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] powernv: kvm: numa fault improvement
Liu ping fan writes: > On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf wrote: >> >> On 11.12.2013, at 09:47, Liu Ping Fan wrote: >> >>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa >>> faults support for ppc64" >>> >>> For this series, I apply the same idea from the previous thread "[PATCH >>> 0/3] optimize for powerpc _PAGE_NUMA" >>> (for which, I still try to get a machine to show nums) >>> >>> But for this series, I think that I have a good justification -- the fact >>> of heavy cost when switching context between guest and host, >>> which is well known. >> >> This cover letter isn't really telling me anything. Please put a proper >> description of what you're trying to achieve, why you're trying to achieve >> what you're trying and convince your readers that it's a good idea to do it >> the way you do it. >> > Sorry for the unclear message. After introducing the _PAGE_NUMA, > kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it > should rely on host's kvmppc_book3s_hv_page_fault() to call > do_numa_page() to do the numa fault check. This incurs the overhead > when exiting from rmode to vmode. My idea is that in > kvmppc_do_h_enter(), we do a quick check, if the page is right placed, > there is no need to exit to vmode (i.e saving htab, slab switching) Can you explain more. Are we looking at hcall from guest and hypervisor handling them in real mode ? If so why would guest issue a hcall on a pte entry that have PAGE_NUMA set. Or is this about hypervisor handling a missing hpte, because of host swapping this page out ? In that case how we end up in h_enter ? IIUC for that case we should get to kvmppc_hpte_hv_fault. > >>> If my suppose is correct, will CCing k...@vger.kernel.org from next version. >> >> This translates to me as "This is an RFC"? >> > Yes, I am not quite sure about it. I have no bare-metal to verify it. > So I hope at least, from the theory, it is correct. > -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] powernv: kvm: make _PAGE_NUMA take effect
Liu Ping Fan writes:
> To make _PAGE_NUMA take effect, we should force the checking when
> guest uses hypercall to setup hpte.
>
> Signed-off-by: Liu Ping Fan
> ---
> arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> index 9c51544..af8602d 100644
> --- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> +++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
> @@ -232,7 +232,7 @@ long kvmppc_do_h_enter(struct kvm *kvm, unsigned long
> flags,
> /* Look up the Linux PTE for the backing page */
> pte_size = psize;
> pte = lookup_linux_pte(pgdir, hva, writing, &pte_size);
> - if (pte_present(pte)) {
> + if (pte_present(pte) && !pte_numa(pte)) {
> if (writing && !pte_write(pte))
> /* make the actual HPTE be read-only */
> ptel = hpte_make_readonly(ptel);
How did we end up doing h_enter on a pte entry with pte_numa bit set ?
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] powernv: kvm: numa fault improvement
On 15.01.2014, at 07:36, Liu ping fan wrote: > On Thu, Jan 9, 2014 at 8:08 PM, Alexander Graf wrote: >> >> On 11.12.2013, at 09:47, Liu Ping Fan wrote: >> >>> This series is based on Aneesh's series "[PATCH -V2 0/5] powerpc: mm: Numa >>> faults support for ppc64" >>> >>> For this series, I apply the same idea from the previous thread "[PATCH >>> 0/3] optimize for powerpc _PAGE_NUMA" >>> (for which, I still try to get a machine to show nums) >>> >>> But for this series, I think that I have a good justification -- the fact >>> of heavy cost when switching context between guest and host, >>> which is well known. >> >> This cover letter isn't really telling me anything. Please put a proper >> description of what you're trying to achieve, why you're trying to achieve >> what you're trying and convince your readers that it's a good idea to do it >> the way you do it. >> > Sorry for the unclear message. After introducing the _PAGE_NUMA, > kvmppc_do_h_enter() can not fill up the hpte for guest. Instead, it > should rely on host's kvmppc_book3s_hv_page_fault() to call > do_numa_page() to do the numa fault check. This incurs the overhead > when exiting from rmode to vmode. My idea is that in > kvmppc_do_h_enter(), we do a quick check, if the page is right placed, > there is no need to exit to vmode (i.e saving htab, slab switching) > >>> If my suppose is correct, will CCing k...@vger.kernel.org from next version. >> >> This translates to me as "This is an RFC"? >> > Yes, I am not quite sure about it. I have no bare-metal to verify it. > So I hope at least, from the theory, it is correct. Paul, could you please give this some thought and maybe benchmark it? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: 85xx: EDAC PCI: request irq as IRQF_SHARED
AER driver needs to share this PCI err irq with EDAC, otherwise
we can't register AER driver successfully as follows:
genirq: Flags mismatch irq 482. 0080 (aerdrv) vs. 0020 ([EDAC] PCI err)
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
Call Trace:
[ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
[ee063cf0] [c055fac4] dump_stack+0x78/0xa0
[ee063d00] [c006e16c] __setup_irq+0x51c/0x540
[ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
[ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
[ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
[ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
[ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
[ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
[ee063e30] [c02c1f94] driver_attach+0x24/0x40
[ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
[ee063e60] [c02c2d98] driver_register+0x88/0x140
[ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
[ee063e80] [c06fb14c] aer_service_init+0x28/0x38
[ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
[ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
[ee063f30] [c0002ac4] kernel_init+0x14/0x130
[ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
aer: probe of :00:00.0:pcie02 failed with error -16
genirq: Flags mismatch irq 480. 0080 (aerdrv) vs. 0020 ([EDAC] PCI err)
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
Call Trace:
[ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
[ee063cf0] [c055fac4] dump_stack+0x78/0xa0
[ee063d00] [c006e16c] __setup_irq+0x51c/0x540
[ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
[ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
[ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
[ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
[ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
[ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
[ee063e30] [c02c1f94] driver_attach+0x24/0x40
[ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
[ee063e60] [c02c2d98] driver_register+0x88/0x140
[ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
[ee063e80] [c06fb14c] aer_service_init+0x28/0x38
[ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
[ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
[ee063f30] [c0002ac4] kernel_init+0x14/0x130
[ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
aer: probe of 0001:02:00.0:pcie02 failed with error -16
Signed-off-by: Tiejun Chen
---
drivers/edac/mpc85xx_edac.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fd46b0b..0dda7c4 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -297,7 +297,8 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr, IRQF_SHARED |
+ IRQF_DISABLED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH][v2] powerpc/pci: Fix IMMRBAR address
For PEXCSRBAR, bit 3-0 indicate prefetchable and address type. So when getting base address, these bits should be masked, otherwise we may get incorrect base address. Signed-off-by: Minghuan Lian --- Change log: v2: Use PCI_BASE_ADDRESS_MEM_MASK instead of 0xfff0 arch/powerpc/sysdev/fsl_pci.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 4dfd61d..252716d 100644 --- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -868,6 +868,14 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose) pci_bus_read_config_dword(hose->bus, PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, &base); + + /* +* For PEXCSRBAR, bit 3-0 indicate prefetchable and +* address type. So when getting base address, these +* bits should be masked +*/ + base &= PCI_BASE_ADDRESS_MEM_MASK; + return base; } #endif -- 1.8.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: 85xx: EDAC PCI: request irq as IRQF_SHARED
On Mon, Jan 20, 2014 at 04:56:15PM +0800, Tiejun Chen wrote:
> AER driver needs to share this PCI err irq with EDAC, otherwise
> we can't register AER driver successfully as follows:
>
> genirq: Flags mismatch irq 482. 0080 (aerdrv) vs. 0020 ([EDAC] PCI
> err)
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
> Call Trace:
> [ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
> [ee063cf0] [c055fac4] dump_stack+0x78/0xa0
> [ee063d00] [c006e16c] __setup_irq+0x51c/0x540
> [ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
> [ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
> [ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
> [ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
> [ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
> [ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
> [ee063e30] [c02c1f94] driver_attach+0x24/0x40
> [ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
> [ee063e60] [c02c2d98] driver_register+0x88/0x140
> [ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
> [ee063e80] [c06fb14c] aer_service_init+0x28/0x38
> [ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
> [ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
> [ee063f30] [c0002ac4] kernel_init+0x14/0x130
> [ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
> aer: probe of :00:00.0:pcie02 failed with error -16
> genirq: Flags mismatch irq 480. 0080 (aerdrv) vs. 0020 ([EDAC] PCI
> err)
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
> Call Trace:
> [ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
> [ee063cf0] [c055fac4] dump_stack+0x78/0xa0
> [ee063d00] [c006e16c] __setup_irq+0x51c/0x540
> [ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
> [ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
> [ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
> [ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
> [ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
> [ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
> [ee063e30] [c02c1f94] driver_attach+0x24/0x40
> [ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
> [ee063e60] [c02c2d98] driver_register+0x88/0x140
> [ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
> [ee063e80] [c06fb14c] aer_service_init+0x28/0x38
> [ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
> [ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
> [ee063f30] [c0002ac4] kernel_init+0x14/0x130
> [ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
> aer: probe of 0001:02:00.0:pcie02 failed with error -16
>
> Signed-off-by: Tiejun Chen
> ---
> drivers/edac/mpc85xx_edac.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index fd46b0b..0dda7c4 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -297,7 +297,8 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
> if (edac_op_state == EDAC_OPSTATE_INT) {
> pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
> res = devm_request_irq(&op->dev, pdata->irq,
> -mpc85xx_pci_isr, IRQF_DISABLED,
> +mpc85xx_pci_isr, IRQF_SHARED |
> +IRQF_DISABLED,
> "[EDAC] PCI err", pci);
> if (res < 0) {
> printk(KERN_ERR
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tiejun,
This is already floating around in linux-next and will hopefully be merged in
3.14.
Hope this helps.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc85xx: Update clock nodes in device tree
From: Tang Yuantian
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian
Signed-off-by: Li Yang
---
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 36 +
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 36 +
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 60 +++
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 61 +++
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 113
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 ++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 43 +++
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 61 +++
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 86 +
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12 +++
16 files changed, 536 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 5a6615d..60566f99 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -86,6 +86,42 @@
clockgen: global-utilities@e1000 {
compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
+ ranges = <0x0 0xe1000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysclk: sysclk {
+ #clock-cells = <0>;
+ compatible = "fsl,qoriq-sysclk-2.0";
+ clock-output-names = "sysclk";
+ };
+
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 0x4>;
+ compatible = "fsl,qoriq-core-pll-2.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 0x4>;
+ compatible = "fsl,qoriq-core-pll-2.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ };
+
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 0x4>;
+ compatible = "fsl,qoriq-core-mux-2.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0", "pll0-div2", "pll0-div4",
+ "pll1", "pll1-div2", "pll1-div4";
+ clock-output-names = "cmux0";
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index c6e451a..2419731 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -64,11 +64,13 @@
cpu0: PowerPC,e6500@0 {
device_type = "cpu";
reg = <0 1>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
cpu1: PowerPC,e6500@2 {
device_type = "cpu";
reg = <2 3>;
+ clocks = <&mux0>;
next-level-cache = <&L2>;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 9813975..cbc354b 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -130,6 +130,42 @@
clockgen: global-utilities@e1000 {
compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2.0";
+ ranges = <0x0 0xe1000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysclk: sysclk {
+ #clock-cells = <0>;
+ compatible = "fsl,qoriq-sysclk-2.0";
+ clock-output-names = "sysclk";
+ };
+
+ pll0: pll0@800 {
+ #clock-cells = <1>;
+ reg = <0x800 0x4>;
+ compatible = "fsl,qoriq-core-pll-2.0";
+ clocks = <&sysclk>;
+ clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ };
+
+ pll1: pll1@820 {
+ #clock-cells = <1>;
+ reg = <0x820 0x
Re: [PATCH] slub: Don't throw away partial remote slabs if there is no local memory
Hi Joonsoo,
On Tue, Jan 07, 2014 at 04:41:36PM +0900, Joonsoo Kim wrote:
[...]
>
>->8
>diff --git a/mm/slub.c b/mm/slub.c
>index c3eb3d3..a1f6dfa 100644
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -1672,7 +1672,19 @@ static void *get_partial(struct kmem_cache *s, gfp_t
>flags, int node,
> {
>void *object;
>int searchnode = (node == NUMA_NO_NODE) ? numa_node_id() : node;
>+ struct zonelist *zonelist;
>+ struct zoneref *z;
>+ struct zone *zone;
>+ enum zone_type high_zoneidx = gfp_zone(flags);
>
>+ if (!node_present_pages(searchnode)) {
>+ zonelist = node_zonelist(searchnode, flags);
>+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
>+ searchnode = zone_to_nid(zone);
>+ if (node_present_pages(searchnode))
>+ break;
>+ }
>+ }
>object = get_partial_node(s, get_node(s, searchnode), c, flags);
>if (object || node != NUMA_NO_NODE)
>return object;
>
The patch fix the bug. However, the kernel crashed very quickly after running
stress tests for a short while:
[ 287.464285] Unable to handle kernel paging request for data at address
0x0001
[ 287.464289] Faulting instruction address: 0xc0445af8
[ 287.464294] Oops: Kernel access of bad area, sig: 11 [#1]
[ 287.464296] SMP NR_CPUS=2048 NUMA pSeries
[ 287.464301] Modules linked in: btrfs raid6_pq xor dm_service_time sg nfsv3
arc4 md4 rpcsec_gss_krb5 nfsv4 nls_utf8 cifs nfs fscache dns_resolver
nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT
ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc
ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter
ip_tables ext4 mbcache jbd2 ibmvfc scsi_transport_fc ibmveth nx_crypto
pseries_rng nfsd auth_rpcgss nfs_acl lockd binfmt_misc sunrpc uinput
dm_multipath xfs libcrc32c sd_mod crc_t10dif crct10dif_common ibmvscsi
scsi_transport_srp scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[ 287.464374] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.10.0-71.el7.91831.ppc64 #1
[ 287.464378] task: c0fde590 ti: c001fffd task.ti:
c10a4000
[ 287.464382] NIP: c0445af8 LR: c0445bcc CTR: c0445b90
[ 287.464385] REGS: c001fffd38e0 TRAP: 0300 Not tainted
(3.10.0-71.el7.91831.ppc64)
[ 287.464388] MSR: 80009032 CR: 88002084 XER:
0001
[ 287.464397] SOFTE: 0
[ 287.464398] CFAR: c000908c
[ 287.464401] DAR: 0001, DSISR: 4000
[ 287.464403]
GPR00: d3649a04 c001fffd3b60 c10a94d0 0003
GPR04: c0018d841048 c001fffd3bd0 0012 d364eff0
GPR08: c001fffd3bd0 0001 d364d688 c0445b90
GPR12: d364b960 c7e0 042ac510 0060
GPR16: 0020 fb19 c1122100
GPR20: c0a94680 c1122180 c0a94680 000a
GPR24: 0100 0001 c001ef90
GPR28: c001d6c066f0 c001aea03520 c001bc9a2640 c0018d841680
[ 287.464447] NIP [c0445af8] .__dev_printk+0x28/0xc0
[ 287.464450] LR [c0445bcc] .dev_printk+0x3c/0x50
[ 287.464453] PACATMSCRATCH [80009032]
[ 287.464455] Call Trace:
[ 287.464458] [c001fffd3b60] [c001fffd3c00] 0xc001fffd3c00
(unreliable)
[ 287.464467] [c001fffd3bf0] [d3649a04]
.ibmvfc_scsi_done+0x334/0x3e0 [ibmvfc]
[ 287.464474] [c001fffd3cb0] [d36495b8]
.ibmvfc_handle_crq+0x2e8/0x320 [ibmvfc]
[ 287.464488] [c001fffd3d30] [d3649fe4] .ibmvfc_tasklet+0xd4/0x250
[ibmvfc]
[ 287.464494] [c001fffd3de0] [c009b46c] .tasklet_action+0xcc/0x1b0
[ 287.464498] [c001fffd3e90] [c009a668] .__do_softirq+0x148/0x360
[ 287.464503] [c001fffd3f90] [c00218a8] .call_do_softirq+0x14/0x24
[ 287.464507] [c001fffcfdf0] [c00107e0] .do_softirq+0xd0/0x100
[ 287.464511] [c001fffcfe80] [c009aba8] .irq_exit+0x1b8/0x1d0
[ 287.464514] [c001fffcff10] [c0010410] .__do_irq+0xc0/0x1e0
[ 287.464518] [c001fffcff90] [c00218cc] .call_do_irq+0x14/0x24
[ 287.464522] [c10a76d0] [c00105bc] .do_IRQ+0x8c/0x100
[ 287.464527] --- Exception: 501 at 0x
[ 287.464527] LR = .arch_local_irq_restore+0x74/0x90
[ 287.464533] [c10a7770] [c0002494]
hardware_interrupt_common+0x114/0x180 (unreliable)
[ 287.464540] --- Exception: 501 at .plpar_hcall_norets+0x84/0xd4
[ 287.464540] LR = .check_and_cede_processor+0x24/0x40
[ 287.464546] [c00
[PATCH] powerpc: 85xx: EDAC PCI: request irq as IRQF_SHARED
AER driver needs to share this PCI err irq with EDAC, otherwise
we can't register AER driver successfully as follows:
genirq: Flags mismatch irq 482. 0080 (aerdrv) vs. 0020 ([EDAC] PCI err)
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
Call Trace:
[ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
[ee063cf0] [c055fac4] dump_stack+0x78/0xa0
[ee063d00] [c006e16c] __setup_irq+0x51c/0x540
[ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
[ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
[ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
[ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
[ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
[ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
[ee063e30] [c02c1f94] driver_attach+0x24/0x40
[ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
[ee063e60] [c02c2d98] driver_register+0x88/0x140
[ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
[ee063e80] [c06fb14c] aer_service_init+0x28/0x38
[ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
[ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
[ee063f30] [c0002ac4] kernel_init+0x14/0x130
[ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
aer: probe of :00:00.0:pcie02 failed with error -16
genirq: Flags mismatch irq 480. 0080 (aerdrv) vs. 0020 ([EDAC] PCI err)
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc1-148346-g2513817 #69
Call Trace:
[ee063cb0] [c00070c4] show_stack+0x44/0x160 (unreliable)
[ee063cf0] [c055fac4] dump_stack+0x78/0xa0
[ee063d00] [c006e16c] __setup_irq+0x51c/0x540
[ee063d40] [c006e264] request_threaded_irq+0xd4/0x150
[ee063d70] [c0280d10] aer_probe+0xe0/0x2a0
[ee063da0] [c027e590] pcie_port_probe_service+0x40/0x90
[ee063dc0] [c02c253c] driver_probe_device+0x8c/0x250
[ee063de0] [c02c27bc] __driver_attach+0xbc/0xc0
[ee063e00] [c02c0760] bus_for_each_dev+0x70/0xb0
[ee063e30] [c02c1f94] driver_attach+0x24/0x40
[ee063e40] [c02c1aec] bus_add_driver+0xfc/0x210
[ee063e60] [c02c2d98] driver_register+0x88/0x140
[ee063e70] [c027e4b4] pcie_port_service_register+0x64/0x80
[ee063e80] [c06fb14c] aer_service_init+0x28/0x38
[ee063e90] [c0002468] do_one_initcall+0x158/0x1b0
[ee063f00] [c06e291c] kernel_init_freeable+0x128/0x1d4
[ee063f30] [c0002ac4] kernel_init+0x14/0x130
[ee063f40] [c000f84c] ret_from_kernel_thread+0x5c/0x64
aer: probe of 0001:02:00.0:pcie02 failed with error -16
Signed-off-by: Tiejun Chen
---
drivers/edac/mpc85xx_edac.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fd46b0b..0dda7c4 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -297,7 +297,8 @@ int mpc85xx_pci_err_probe(struct platform_device *op)
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata->irq = irq_of_parse_and_map(op->dev.of_node, 0);
res = devm_request_irq(&op->dev, pdata->irq,
- mpc85xx_pci_isr, IRQF_DISABLED,
+ mpc85xx_pci_isr, IRQF_SHARED |
+ IRQF_DISABLED,
"[EDAC] PCI err", pci);
if (res < 0) {
printk(KERN_ERR
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DMA: Freescale: change BWC from 256 bytes to 1024 bytes
On Thu, Jan 16, 2014 at 02:10:53PM +0800, hongbo.zh...@freescale.com wrote: > From: Hongbo Zhang > > Freescale DMA has a feature of BandWidth Control (ab. BWC), which is currently > 256 bytes and should be changed to 1024 bytes for best DMA throughput. > Changing BWC from 256 to 1024 will improve DMA performance much, in cases > whatever one channel is running or multi channels are running simultanously, > large or small buffers are copied. And this change doesn't impact memory > access performance remarkably, lmbench tests show that for some cases the > memory performance are decreased very slightly, while the others are even > better. > Tested on T4240. Applied, thanks -- ~Vinod ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: hugetlb: replace __get_cpu_var with get_cpu_var
Replace __get_cpu_var safely with get_cpu_var to avoid
the following call trace:
[ 7253.637591] BUG: using smp_processor_id() in preemptible [ ]
code: hugemmap01/9048
[ 7253.637601] caller is free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637605] CPU: 1 PID: 9048 Comm: hugemmap01 Not tainted 3.10.20-rt14+ #114
[ 7253.637606] Call Trace:
[ 7253.637617] [cb049d80] [c0007ea4] show_stack+0x4c/0x168 (unreliable)
[ 7253.637624] [cb049dc0] [c031c674] debug_smp_processor_id+0x114/0x134
[ 7253.637628] [cb049de0] [c0016d28] free_hugepd_range.constprop.25+0x88/0x1a8
[ 7253.637632] [cb049e00] [c001711c] hugetlb_free_pgd_range+0x6c/0x168
[ 7253.637639] [cb049e40] [c0117408] free_pgtables+0x12c/0x150
[ 7253.637646] [cb049e70] [c011ce38] unmap_region+0xa0/0x11c
[ 7253.637671] [cb049ef0] [c011f03c] do_munmap+0x224/0x3bc
[ 7253.637676] [cb049f20] [c011f2e0] vm_munmap+0x38/0x5c
[ 7253.637682] [cb049f40] [c000ef88] ret_from_syscall+0x0/0x3c
[ 7253.637686] --- Exception: c01 at 0xff16004
Signed-off-by: Tiejun Chen
---
arch/powerpc/mm/hugetlbpage.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 90bb6d9..eb92365 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -472,12 +472,13 @@ static void hugepd_free(struct mmu_gather *tlb, void
*hugepte)
{
struct hugepd_freelist **batchp;
- batchp = &__get_cpu_var(hugepd_freelist_cur);
+ batchp = &get_cpu_var(hugepd_freelist_cur);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpumask_equal(mm_cpumask(tlb->mm),
cpumask_of(smp_processor_id( {
kmem_cache_free(hugepte_cache, hugepte);
+put_cpu_var(hugepd_freelist_cur);
return;
}
@@ -491,6 +492,7 @@ static void hugepd_free(struct mmu_gather *tlb, void
*hugepte)
call_rcu_sched(&(*batchp)->rcu, hugepd_free_rcu_callback);
*batchp = NULL;
}
+ put_cpu_var(hugepd_freelist_cur);
}
#endif
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: KGDB panics on p2020 target
On 01/17/2014 03:52 PM, Arun Chandran wrote:
Hi,
I am testing kgdb on freescale p2020 target.
In target
1)
root@freescale-p2020ds:~# uname -a
Linux freescale-p2020ds 3.10.20-rt14+ #9 SMP Thu Jan 16 16:32:15 IST 2014
ppc GNU/Linux
2)
root@freescale-p2020ds:~# cat /proc/cpuinfo
processor : 0
cpu : e500v2
clock : 999.990008MHz
revision: 4.0 (pvr 8021 1040)
bogomips: 124.99
processor : 1
cpu : e500v2
clock : 999.990008MHz
revision: 4.0 (pvr 8021 1040)
bogomips: 124.99
total bogomips : 249.99
timebase: 62499376
platform: P2020 DS
model : fsl,P2020DS
Memory : 768 MB
3)
freescale-p2020ds:~# echo "ttyS1,115200" >
/sys/module/kgdboc/parameters/kgdoc
4) I set up host (settings given below); Then I send "SysRq : DEBUG"
In host
--
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
kgdb_breakpoint () at kernel/debug/debug_core.c:1013
1013 arch_kgdb_breakpoint();
(gdb) b sys_sync
Breakpoint 1 at 0xc0167288: file fs/sync.c, line 103.
(gdb) c
Continuing.
I am able to take control in host; after that I am setting breakpoint at
"sys_sync"
In target
root@freescale-p2020ds:~# for i in 1 2 3 4 5 6 7 8 9
do
sync
done
In host
--
Breakpoint 1, sys_sync () at fs/sync.c:103
103 {
(gdb) c
Continuing.
Breakpoint is hit only one time instead of 9 times; after that target hangs.
I recommend you try upstream to take a further look at this, instead of that
Freescale distribution. As I recall currently KGDB works well in 85xx case in ML.
Then i tried to send "SysRq : DEBUG" in target kernel panics.
I have pasted the panic below.
#
SysRq : DEBUG
Kernel panic - not syncing: Recursive entry to debugger
The kernel already trap into kgdb_handle_exception() with the debug exception
while triggering that break point, but again you trigger another debug exception
by SysRq. Actually KGDB can't handle such this recursive behavior, so KGDB
always call kgdb_reenter_check() to prevent this scenario with this call trace.
static int kgdb_reenter_check(struct kgdb_state *ks)
{
unsigned long addr;
if (atomic_read(&kgdb_active) != raw_smp_processor_id())
return 0;
...
if (exception_level > 1) {
dump_stack();
panic("Recursive entry to debugger");
}
Tiejun
CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
Call Trace:
[effe5d10] [c0008060] show_stack+0x4c/0x168 (unreliable)
[effe5d50] [c0588878] panic+0xe4/0x224
[effe5da0] [c00b2cbc] kgdb_handle_exception+0x1d4/0x1f8
[effe5df0] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
[effe5e00] [c057e7e0] program_check_exception+0x10c/0x264
[effe5e10] [c000f660] ret_from_except_full+0x0/0x4c
--- Exception: 700 at sysrq_handle_dbg+0x3c/0xc8
LR = __handle_sysrq+0x154/0x1cc
[effe5ed0] [c033df5c] __handle_sysrq+0x140/0x1cc (unreliable)
[effe5f00] [c0353ef8] serial8250_rx_chars+0xe8/0x218
[effe5f30] [c0359644] fsl8250_handle_irq+0xac/0x174
[effe5f50] [c0352f9c] serial8250_interrupt+0x40/0xe8
[effe5f70] [c00b5500] handle_irq_event_percpu+0xcc/0x2a8
[effe5fc0] [c00b5720] handle_irq_event+0x44/0x74
[effe5fe0] [c00b8e14] handle_fasteoi_irq+0xd0/0x17c
[effe5ff0] [c000d58c] call_handle_irq+0x18/0x28
[c4f91b10] [c0004f60] do_IRQ+0x150/0x224
[c4f91b40] [c000f6ac] ret_from_except+0x0/0x18
--- Exception: 501 at rpcauth_lookup_credcache+0x138/0x2a4
LR = rpcauth_lookup_credcache+0xb8/0x2a4
[c4f91c00] [24002424] 0x24002424 (unreliable)
[c4f91c50] [c055cb84] rpcauth_lookupcred+0x64/0xac
[c4f91c80] [c055ce2c] rpcauth_refreshcred+0x11c/0x124
[c4f91cc0] [c055ac80] __rpc_execute+0x8c/0x330
[c4f91d10] [c05540b8] rpc_run_task+0x9c/0xc4
[c4f91d20] [c0554204] rpc_call_sync+0x50/0xb8
[c4f91d50] [c0257164] nfs_proc_getattr+0x48/0x5c
[c4f91d70] [c024aaa4] __nfs_revalidate_inode+0xa8/0x168
[c4f91d90] [c024ac1c] nfs_revalidate_mapping+0xb8/0x194
[c4f91da0] [c0251f00] nfs_follow_link+0x24/0xc8
[c4f91dc0] [c0145280] path_lookupat+0x2f4/0x824
[c4f91e10] [c01457dc] filename_lookup.isra.33+0x2c/0x8c
[c4f91e30] [c0147a74] user_path_at_empty+0x58/0x9c
[c4f91eb0] [c013d5bc] vfs_fstatat+0x54/0xb4
[c4f91ee0] [c013d93c] SyS_stat64+0x1c/0x44
[c4f91f40] [c000eec0] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xff08a98
LR = 0xfed53e8
CPU: 1 PID: 2266 Comm: cron Not tainted 3.10.20-rt14+ #6
Call Trace:
[effe5bb0] [c0008060] show_stack+0x4c/0x168 (unreliable)
[effe5bf0] [c00b2cac] kgdb_handle_exception+0x1c4/0x1f8
[effe5c40] [c0010038] kgdb_handle_breakpoint+0x4c/0x80
[effe5c50] [c057e7e0] program_check_exception+0x10c/0x264
[effe5c60] [c000f660] ret_from_except_full+0x0/0x4c
--- Exception: 700 at kgdb_panic_event+0x1c/0x3c
LR = notifier_call_chain+0x60/0xb0
[effe5d20] [](nil) (unreliable)
[effe5d40] [c05819dc] __atomic_notifier_call_chain+0x14/0x24
[effe5d50] [c05888a8] panic+0x114/
