Re: [PATCH v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
Any updates on the patch. - Neelesh On 05/19/2014 07:56 PM, Neelesh Gupta wrote: This patch adds basic kernel enablement for reading power values, fan speed rpm and temperature values on powernv platforms which will be exported to user space through sysfs interface. Test results: - [root@tul163p1 ~]# sensors ibmpowernv-isa- Adapter: ISA adapter fan1:5487 RPM (min =0 RPM) fan2:5152 RPM (min =0 RPM) fan3:5590 RPM (min =0 RPM) fan4:4963 RPM (min =0 RPM) fan5: 0 RPM (min =0 RPM) fan6: 0 RPM (min =0 RPM) fan7:7488 RPM (min =0 RPM) fan8:7944 RPM (min =0 RPM) temp1:+39.0°C (high = +0.0°C) power1: 192.00 W [root@tul163p1 ~]# ls /sys/devices/platform/ alarmtimer ibmpowernv.0 rtc-generic serial8250 uevent [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/ driver/hwmon/ modalias subsystem/ uevent [root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/hwmon/hwmon0/ device fan2_minfan4_minfan6_minfan8_min power1_input fan1_fault fan3_fault fan5_fault fan7_fault in1_fault subsystem fan1_input fan3_input fan5_input fan7_input in2_fault temp1_input fan1_minfan3_minfan5_minfan7_minin3_fault temp1_max fan2_fault fan4_fault fan6_fault fan8_fault in4_fault uevent fan2_input fan4_input fan6_input fan8_input name [root@tul163p1 ~]# [root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/ device fan2_minfan4_minfan6_minfan8_min power1_input fan1_fault fan3_fault fan5_fault fan7_fault in1_fault subsystem fan1_input fan3_input fan5_input fan7_input in2_fault temp1_input fan1_minfan3_minfan5_minfan7_minin3_fault temp1_max fan2_fault fan4_fault fan6_fault fan8_fault in4_fault uevent fan2_input fan4_input fan6_input fan8_input name [root@tul163p1 ~]# Signed-off-by: Neelesh Gupta --- Changes in v2 = - Generic use of devm_* functions in hwmon like using devm_kzalloc() for dynamic memory request, avoiding the need to explicit free of memory. Adding 'struct attribute_group' as member of platform data structure to be populated and then passed to devm_hwmon_device_register_with_groups(). Note: Having an array of pointers of 'attribute_group' and each group corresponds to 'enum sensors' type. Not completely sure, if it's ideal or could have just one group populated with attributes of sensor types? - 'ibmpowernv' is not hot-pluggable device so moving 'platform_driver' callback function (probe) as part of __init code. - Fixed issues related to coding style. - Other general comments in v1. drivers/hwmon/Kconfig |8 + drivers/hwmon/Makefile |1 drivers/hwmon/ibmpowernv.c | 368 3 files changed, 377 insertions(+) create mode 100644 drivers/hwmon/ibmpowernv.c diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index bc196f4..3e308fa 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -554,6 +554,14 @@ config SENSORS_IBMPEX This driver can also be built as a module. If so, the module will be called ibmpex. +config SENSORS_IBMPOWERNV + tristate "IBM POWERNV platform sensors" + depends on PPC_POWERNV + default y + help + If you say yes here you get support for the temperature/fan/power + sensors on your platform. + config SENSORS_IIO_HWMON tristate "Hwmon driver that uses channels specified via iio maps" depends on IIO diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index c48f987..199c401 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o +obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o obj-$(CONFIG_SENSORS_INA209) += ina209.o obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c new file mode 100644 index 000..afce620 --- /dev/null +++ b/drivers/hwmon/ibmpowernv.c @@ -0,0 +1,368 @@ +/* + * IBM PowerNV platform sensors for temperature/fan/power + * Copyright (C) 2014 IBM + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public Lic
[PATCH] xmon: Fix up xmon format strings
There are a couple of places where xmon is using %x to print values that
are unsigned long.
I found this out the hard way recently:
0:mon> p c0d0e7c8 c0033dc9 a089 c000
return value is 0x96300500
Which is calling find_linux_pte_or_hugepte(), the result should be a
kernel pointer. After decoding the page tables by hand I discovered the
correct value was c00396300500.
So fix up that case and a few others.
We also use a mix of 0x%x, %x and %u to print cpu numbers. So
standardise on 0x%x.
Signed-off-by: Michael Ellerman
---
arch/powerpc/xmon/xmon.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 08504e7..3fd1d9a 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -419,7 +419,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
get_output_lock();
excprint(regs);
if (bp) {
- printf("cpu 0x%x stopped at breakpoint 0x%x (",
+ printf("cpu 0x%x stopped at breakpoint 0x%lx (",
cpu, BP_NUM(bp));
xmon_print_symbol(regs->nip, " ", ")\n");
}
@@ -513,7 +513,7 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
excprint(regs);
bp = at_breakpoint(regs->nip);
if (bp) {
- printf("Stopped at breakpoint %x (", BP_NUM(bp));
+ printf("Stopped at breakpoint %lx (", BP_NUM(bp));
xmon_print_symbol(regs->nip, " ", ")\n");
}
if (unrecoverable_excp(regs))
@@ -997,14 +997,14 @@ static int cpu_cmd(void)
last_cpu = cpu;
} else {
if (last_cpu != first_cpu)
- printf("-%lx", last_cpu);
+ printf("-0x%lx", last_cpu);
last_cpu = first_cpu = cpu;
- printf(" %lx", cpu);
+ printf(" 0x%lx", cpu);
}
}
}
if (last_cpu != first_cpu)
- printf("-%lx", last_cpu);
+ printf("-0x%lx", last_cpu);
printf("\n");
return 0;
}
@@ -1024,7 +1024,7 @@ static int cpu_cmd(void)
/* take control back */
mb();
xmon_owner = smp_processor_id();
- printf("cpu %u didn't take control\n", cpu);
+ printf("cpu 0x%x didn't take control\n", cpu);
return 0;
}
barrier();
@@ -1086,7 +1086,7 @@ csum(void)
fcs = 0x;
for (i = 0; i < ncsum; ++i) {
if (mread(adrs+i, &v, 1) == 0) {
- printf("csum stopped at %x\n", adrs+i);
+ printf("csum stopped at "REG"\n", adrs+i);
break;
}
fcs = FCS(fcs, v);
@@ -1202,12 +1202,12 @@ bpt_cmds(void)
/* assume a breakpoint address */
bp = at_breakpoint(a);
if (bp == NULL) {
- printf("No breakpoint at %x\n", a);
+ printf("No breakpoint at %lx\n", a);
break;
}
}
- printf("Cleared breakpoint %x (", BP_NUM(bp));
+ printf("Cleared breakpoint %lx (", BP_NUM(bp));
xmon_print_symbol(bp->address, " ", ")\n");
bp->enabled = 0;
break;
@@ -1746,7 +1746,7 @@ mwrite(unsigned long adrs, void *buf, int size)
__delay(200);
n = size;
} else {
- printf("*** Error writing address %x\n", adrs + n);
+ printf("*** Error writing address "REG"\n", adrs + n);
}
catch_memory_errors = 0;
return n;
@@ -2435,7 +2435,7 @@ static void proccall(void)
ret = func(args[0], args[1], args[2], args[3],
args[4], args[5], args[6], args[7]);
sync();
- printf("return value is %x\n", ret);
+ printf("return value is 0x%lx\n", ret);
} else {
printf("*** %x exception occurred\n", fault_except);
}
@@ -2700,7 +2700,7 @@ static void dump_slb(void)
unsigned long esid,vsid,valid;
unsigned long llp;
- printf("SLB contents of cpu %x\n", smp_processor_id());
+ printf("SLB contents of cpu 0x%x\n", smp_processor_id());
Re: [RFT PATCH -next ] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
> initalizing its blacklist, it fails and reports many errors
> as below.
>
> Failed to find blacklist 000101316830
> Failed to find blacklist 0001013000f0a000
> Failed to find blacklist 000101315f70a000
> Failed to find blacklist 000101324c80a000
> Failed to find blacklist 0001013063f0a000
> Failed to find blacklist 000101327800a000
> Failed to find blacklist 0001013277f0a000
> Failed to find blacklist 000101315a70a000
> Failed to find blacklist 0001013277e0a000
> Failed to find blacklist 000101305a20a000
> Failed to find blacklist 0001013277d0a000
> Failed to find blacklist 00010130bdc0a000
> Failed to find blacklist 00010130dc20a000
> Failed to find blacklist 000101309a00a000
> Failed to find blacklist 0001013277c0a000
> Failed to find blacklist 0001013277b0a000
> Failed to find blacklist 0001013277a0a000
> Failed to find blacklist 000101327790a000
> Failed to find blacklist 000101303140a000
> Failed to find blacklist 0001013a3280a000
>
> To fix this bug, this introduces function_entry() macro to
> retrieve the entry address from the given function pointer,
> and uses it in NOKPROBE_SYMBOL().
>
>
> Signed-off-by: Masami Hiramatsu
> Reported-by: Tony Luck
> Cc: Tony Luck
> Cc: Fenghua Yu
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Ananth N Mavinakayanahalli
> Cc: Kevin Hao
> Cc: linux-i...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> ---
> arch/ia64/include/asm/types.h|2 ++
> arch/powerpc/include/asm/types.h | 11 +++
> include/linux/kprobes.h |3 ++-
> include/linux/types.h|4
> 4 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
> index 4c351b1..6ab7b6c 100644
> --- a/arch/ia64/include/asm/types.h
> +++ b/arch/ia64/include/asm/types.h
> @@ -27,5 +27,7 @@ struct fnptr {
> unsigned long gp;
> };
>
> +#define constant_function_entry(fn) (((struct fnptr *)(fn))->ip)
> +
> #endif /* !__ASSEMBLY__ */
> #endif /* _ASM_IA64_TYPES_H */
> diff --git a/arch/powerpc/include/asm/types.h
> b/arch/powerpc/include/asm/types.h
> index bfb6ded..fd297b8 100644
> --- a/arch/powerpc/include/asm/types.h
> +++ b/arch/powerpc/include/asm/types.h
> @@ -25,6 +25,17 @@ typedef struct {
> unsigned long env;
> } func_descr_t;
>
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address of the function text.
> + */
> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
> +#else
> +#define constant_function_entry(fn) ((unsigned long)(fn))
> +#endif
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* _ASM_POWERPC_TYPES_H */
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index e059507..637eafe 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_KPROBES
> #include
> @@ -485,7 +486,7 @@ static inline int enable_jprobe(struct jprobe *jp)
> #define __NOKPROBE_SYMBOL(fname) \
> static unsigned long __used \
> __attribute__((section("_kprobe_blacklist"))) \
> - _kbl_addr_##fname = (unsigned long)fname;
> + _kbl_addr_##fname = constant_function_entry(fname);
> #define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname)
Throws up build errors for me :
CC kernel/notifier.o
kernel/notifier.c:105:1: error: initializer element is not constant
NOKPROBE_SYMBOL(notifier_call_chain);
^
kernel/notifier.c:188:1: error: initializer element is not constant
NOKPROBE_SYMBOL(__atomic_notifier_call_chain);
^
kernel/notifier.c:196:1: error: initializer element is not constant
NOKPROBE_SYMBOL(atomic_notifier_call_chain);
^
kernel/notifier.c:546:1: error: initializer element is not constant
NOKPROBE_SYMBOL(notify_die);
^
make[1]: *** [kernel/notifier.o] Error 1
make: *** [kernel] Error 2
Thanks
Suzuki
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc: Add cpu family documentation
This patch adds some documentation on the different cpu families supported by arch/powerpc. Signed-off-by: Michael Ellerman --- Please send any further corrections as patches :) v3: Dropped 740, don't need that level of detail. Don't list 850 separately from 8xx. Rename 8xx to MPC8xx Core as per James. Moved Book3e to e500mc. Add e300 and e600. Show ambiguous Cell/Power6 relationship. v2: Reworked formatting to avoid wrapping. Fixed up Freescale details. --- Documentation/powerpc/cpu_families.txt | 221 + 1 file changed, 221 insertions(+) create mode 100644 Documentation/powerpc/cpu_families.txt diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt new file mode 100644 index 000..fc08e22 --- /dev/null +++ b/Documentation/powerpc/cpu_families.txt @@ -0,0 +1,221 @@ +CPU Families + + +This document tries to summarise some of the different cpu families that exist +and are supported by arch/powerpc. + + +Book3S (aka sPAPR) +-- + + - Hash MMU + - Mix of 32 & 64 bit + + +--+ ++ + | Old POWER | --> | RS64 (threads) | + +--+ ++ + | + | + v + +--+ ++ +--+ + | 601 | --> | 603 | ---> | e300 | + +--+ ++ +--+ + | | + | | + v v + +--+ ++ +---+ + | 604 | |750 (G3)| ---> | 750CX | + +--+ ++ +---+ + | | | + | | | + v v v + +--+ ++ +---+ + | 620 (64 bit) | | 7400 | | 750CL | + +--+ ++ +---+ + | | | + | | | + v v v + +--+ ++ +---+ + | POWER3/630 | | 7410 | | 750FX | + +--+ ++ +---+ + | | + | | + v v + +--+ ++ + | POWER3+| | 7450 | + +--+ ++ + | | + | | + v v + +--+ ++ + |POWER4| | 7455 | + +--+ ++ + | | + | | + v v + +--+ +---+ ++ + | POWER4+| --> | 970 | | 7447 | + +--+ +---+ ++ + | | | + | | | + v v v + +--+ +---+ ++ + |POWER5| | 970FX | | 7448 | + +--+ +---+ ++ + | | | + | | | + v v v + +--+ +---+ ++ + | POWER5+| | 970MP | | e600 | + +--+ +---+ ++ + | + | + v + +--+ + | POWER5++ | + +--+ + | + | + v + +--+ +---+ + |POWER6| <-?-> | Cell | + +--+ +---+ + | + | + v + +--+ + |POWER7| + +--+ + | + | + v + +--+ + | POWER7+| + +--+ + | + | + v + +--+ + |POWER8| + +--+ + + + +---+ + | PA6T (64 bit) | + +---+ + + +IBM BookE +- + + - Software loaded TLB. + - All 32 bit + + +--+ + | 401 | +
Re: [RFT PATCH -next ] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
(2014/05/26 20:25), Suzuki K. Poulose wrote:
> On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
>> On ia64 and ppc64, the function pointer does not point the
>> entry address of the function, but the address of function
>> discriptor (which contains the entry address and misc
>> data.) Since the kprobes passes the function pointer stored
>> by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
>> initalizing its blacklist, it fails and reports many errors
>> as below.
>>
>> Failed to find blacklist 000101316830
>> Failed to find blacklist 0001013000f0a000
>> Failed to find blacklist 000101315f70a000
>> Failed to find blacklist 000101324c80a000
>> Failed to find blacklist 0001013063f0a000
>> Failed to find blacklist 000101327800a000
>> Failed to find blacklist 0001013277f0a000
>> Failed to find blacklist 000101315a70a000
>> Failed to find blacklist 0001013277e0a000
>> Failed to find blacklist 000101305a20a000
>> Failed to find blacklist 0001013277d0a000
>> Failed to find blacklist 00010130bdc0a000
>> Failed to find blacklist 00010130dc20a000
>> Failed to find blacklist 000101309a00a000
>> Failed to find blacklist 0001013277c0a000
>> Failed to find blacklist 0001013277b0a000
>> Failed to find blacklist 0001013277a0a000
>> Failed to find blacklist 000101327790a000
>> Failed to find blacklist 000101303140a000
>> Failed to find blacklist 0001013a3280a000
>>
>> To fix this bug, this introduces function_entry() macro to
>> retrieve the entry address from the given function pointer,
>> and uses it in NOKPROBE_SYMBOL().
>>
>>
>> Signed-off-by: Masami Hiramatsu
>> Reported-by: Tony Luck
>> Cc: Tony Luck
>> Cc: Fenghua Yu
>> Cc: Benjamin Herrenschmidt
>> Cc: Paul Mackerras
>> Cc: Ananth N Mavinakayanahalli
>> Cc: Kevin Hao
>> Cc: linux-i...@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linuxppc-dev@lists.ozlabs.org
>> ---
>> arch/ia64/include/asm/types.h|2 ++
>> arch/powerpc/include/asm/types.h | 11 +++
>> include/linux/kprobes.h |3 ++-
>> include/linux/types.h|4
>> 4 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
>> index 4c351b1..6ab7b6c 100644
>> --- a/arch/ia64/include/asm/types.h
>> +++ b/arch/ia64/include/asm/types.h
>> @@ -27,5 +27,7 @@ struct fnptr {
>> unsigned long gp;
>> };
>>
>> +#define constant_function_entry(fn) (((struct fnptr *)(fn))->ip)
>> +
>> #endif /* !__ASSEMBLY__ */
>> #endif /* _ASM_IA64_TYPES_H */
>> diff --git a/arch/powerpc/include/asm/types.h
>> b/arch/powerpc/include/asm/types.h
>> index bfb6ded..fd297b8 100644
>> --- a/arch/powerpc/include/asm/types.h
>> +++ b/arch/powerpc/include/asm/types.h
>> @@ -25,6 +25,17 @@ typedef struct {
>> unsigned long env;
>> } func_descr_t;
>>
>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
>> +/*
>> + * On PPC64 ABIv1 the function pointer actually points to the
>> + * function's descriptor. The first entry in the descriptor is the
>> + * address of the function text.
>> + */
>> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
>> +#else
>> +#define constant_function_entry(fn) ((unsigned long)(fn))
>> +#endif
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif /* _ASM_POWERPC_TYPES_H */
>> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
>> index e059507..637eafe 100644
>> --- a/include/linux/kprobes.h
>> +++ b/include/linux/kprobes.h
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #ifdef CONFIG_KPROBES
>> #include
>> @@ -485,7 +486,7 @@ static inline int enable_jprobe(struct jprobe *jp)
>> #define __NOKPROBE_SYMBOL(fname)\
>> static unsigned long __used \
>> __attribute__((section("_kprobe_blacklist"))) \
>> -_kbl_addr_##fname = (unsigned long)fname;
>> +_kbl_addr_##fname = constant_function_entry(fname);
>> #define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname)
>
>
> Throws up build errors for me :
>
> CC kernel/notifier.o
> kernel/notifier.c:105:1: error: initializer element is not constant
> NOKPROBE_SYMBOL(notifier_call_chain);
> ^
> kernel/notifier.c:188:1: error: initializer element is not constant
> NOKPROBE_SYMBOL(__atomic_notifier_call_chain);
> ^
> kernel/notifier.c:196:1: error: initializer element is not constant
> NOKPROBE_SYMBOL(atomic_notifier_call_chain);
> ^
> kernel/notifier.c:546:1: error: initializer element is not constant
> NOKPROBE_SYMBOL(notify_die);
> ^
> make[1]: *** [kernel/notifier.o] Error 1
> make: *** [kernel] Error 2
Thanks for the test!
>> +#define constant_function_entry(fn) (((func_descr_t *)(fn))->entry)
Ah! right, This is not allowed for initialization...
I'll update it to deref pointer when it is used.
Thank you again!
>
> Thanks
> Suzuki
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Techn
Re: Boot problems with a PA6T board
On Tue, 2014-05-13 at 14:06 +0200, Christian Zigotzky wrote: > On 05.05.2014 07:48, Michael Ellerman wrote: > > On Sun, 2014-05-04 at 18:02 +0200, Christian Zigotzky wrote: > >> Hi All, > >> > >> The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a > >> Radeon HD 6870 graphics card. > >> > >> Screenshot: > >> http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view > >> > >> The kernel 3.14 starts without any problems. Has anyone a tip for me, > >> please? > > The line that says "starting cpu hw idx 0... failed" looks a little > > worrying. > > Do you see that on 3.14 as well? > > > > Otherwise bisection is probably your best bet. > Hi All, > > I have found out which patch is responsible for the boot problems. It's > patch 9000c17dc0f9c910267d2661225c9d33a227b27e. Link: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9000c17dc0f9c910267d2661225c9d33a227b27e Hi Christian, I'm almost certain that is not the commit which breaks your machine. Or if it is, something *really* weird is going on. The code changed in that commit should never run on a PA6T. > Experimental protocol: > > git checkout -f 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44; git clean -fdx > (from 02/04/14) -> Kernel boots > git checkout -f f1553174a207f68a4ec19d436003097e0a4dc405; git clean -fdx > (from 03/04/14) -> Kernel boots > git checkout -f d40326f4b9f9617cdfd30f83a2db57d47e9c5bac; git clean -fdx > (from 04/04/14) -> Kernel boots > git checkout -f 930b440cd8256f3861bdb0a59d26efaadac7941a; git clean -fdx > (from 05/04/14) -> doesn't boot (rtc error) > git checkout -f 2b3a8fd735f86ebeb2b9d061054003000c36b654; git clean -fdx > (from 06/04/14) -> doesn't boot (rtc error) > git checkout -f 26c12d93348f0bda0756aff83f4867d9ae58a5a6; git clean -fdx > (from 07/04/14) -> doesn't boot (rtc error) > git checkout -f a6c8aff022d4d06e4b41455ae9b2a5d3d503bf76; git clean -fdx > (from 08/04/14) -> Kernel boots > git checkout -f 035328c202d26a824b8632fd3b00635db5aee5a2; git clean -fdx > (from 08/04/14) -> Kernel boots > git checkout -f 9000c17dc0f9c910267d2661225c9d33a227b27e; git clean -fdx > (from 08/04/14) powerpc/powernv: Fix endian issues with sensor code > One OPAL call and one device tree property needed byte swapping. -> > doesn't boot (prom_init) > git checkout -f d3d35d957a9d0733dc51f14b5abc0bff5d3c5f3a; git clean -fdx > (from 08/04/14) -> doesn't boot (prom_init) > git checkout -f c4586256f0c440bc2bdb29d2cbb915f0ca785d26; git clean -fdx > (from 09/04/14) -> doesn't boot (prom_init) So it looks like you manually picked commits based on the date? That's a good start, but if you want to find the actual problem commit you need to do a proper bisect. > I'm not a programmer but what can I do to solve this boot problem? To start with you can probably narrow it down a bit by testing the following commits: 18a1a7a1d862ae0794a0179473d08a414dd49234 d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b 0f5a869600141a0d5575e3190af01a050c081b07 c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac d3e144532703fe2454b56eddb56f30d2d620187b cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
On 05/25/2014 11:22 PM, Neelesh Gupta wrote: Any updates on the patch. Not yet, I have been too busy with other stuff. That happens, unfortunately. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Introduce the use of the managed version of kzalloc
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfree in probe function.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(&pdev->dev, e1, e2)
...
?-kfree(e);
...+>
}
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
Not compile tested
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 6929982..37343a6 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -724,7 +724,7 @@ static int mpc52xx_gpt_probe(struct platform_device *ofdev)
{
struct mpc52xx_gpt_priv *gpt;
- gpt = kzalloc(sizeof *gpt, GFP_KERNEL);
+ gpt = devm_kzalloc(&ofdev->dev, sizeof *gpt, GFP_KERNEL);
if (!gpt)
return -ENOMEM;
@@ -732,10 +732,8 @@ static int mpc52xx_gpt_probe(struct platform_device *ofdev)
gpt->dev = &ofdev->dev;
gpt->ipb_freq = mpc5xxx_get_bus_frequency(ofdev->dev.of_node);
gpt->regs = of_iomap(ofdev->dev.of_node, 0);
- if (!gpt->regs) {
- kfree(gpt);
+ if (!gpt->regs)
return -ENOMEM;
- }
dev_set_drvdata(&ofdev->dev, gpt);
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] booke/watchdog: refine and clean up the codes
Hi Tang, > From: Tang Yuantian > > Basically, this patch does the following: > 1. Move the codes of parsing boot parameters from setup-common.c >to driver. In this way, code reader can know directly that >there are boot parameters that can change the timeout. > 2. Make boot parameter 'booke_wdt_period' effective. >currently, when driver is loaded, default timeout is always >being used in stead of booke_wdt_period. > 3. Wrap up the watchdog timeout in device struct and clean up >unnecessary codes. > > Signed-off-by: Tang Yuantian > Acked-by: Scott Wood > --- > resend to watchdog maintainer > > arch/powerpc/kernel/setup-common.c | 27 > drivers/watchdog/booke_wdt.c | 51 > -- > 2 files changed, 33 insertions(+), 45 deletions(-) Patch has been added to linux-watchdog-next. Kind regards, Wim. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
shiva7 wrote > Thanks again Scott. / >> Any idea whether the DBCR0 BRT bit actually works(??), > >> Do you have reason to believe that it might not? / > > I'm facing a strange problem which was not there on server processor. Let > me try to give brief flow. > > Server : > > Set BE bit (thru system call or sigreturn) for specific thread -> for > every branch -> trace exception -> Normal exception prolog > (STD_EXCEPTION_COMMON) SRR0 and SRR1 > > Embedded/BOOKE: > > Set DE & BRT bit (thru system call or sigreturn) for specific thread -> > for every branch taken -> Debug exception -> DEBUG_DEBUG prolog -> > return_dbg_except DSRR0 & DSRR1 > > In server case, able to capture the branches as expected, but wherein > BOOKE though branch taken exception are generated, at the certain stage > (mostly after turn on BRT & DE bit) user process is deviated (not taking > the same flow as like server) and leading to different > corruption/unexpected behavior. / >> And also, anything special required for "server" family application code >> porting here ?? as because in server family the trace exception used to >> viz >> NORMAL exception proglog and uses SRR0 and SRR1 but in this ISA/embedded >> case have dedicated DEBUG_DEBUG prolog and dedicated registers DSRR0 and >> DSRR1. > >> IIRC the branch taken mechanism does have different semantics than the >> equivalent mechanism on server. You can find discussion of this in the >> archives. :-) / > > Most of the discussions so far I have surfed are related to branch > taken/fall through(not taken) semantics related. But, in general, if I > have an application running on server where tracing was based on BE bit > and same can run on e500mc with DE & BRT combination? > > > Thanks In Advance. Could someone help on this regard? -- View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p82686.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
On Tuesday 20 May 2014 03:57 PM, Kirill A. Shutemov wrote:
> Rusty Russell wrote:
>> "Kirill A. Shutemov" writes:
>>> Andrew Morton wrote:
On Mon, 19 May 2014 16:23:07 -0700 (PDT) Hugh Dickins
wrote:
> Shouldn't FAULT_AROUND_ORDER and fault_around_order be changed to be
> the order of the fault-around size in bytes, and fault_around_pages()
> use 1UL << (fault_around_order - PAGE_SHIFT)
Yes. And shame on me for missing it (this time!) at review.
There's still time to fix this. Patches, please.
>>>
>>> Here it is. Made at 3.30 AM, build tested only.
>>
>> Prefer on top of Maddy's patch which makes it always a variable, rather
>> than CONFIG_DEBUG_FS. It's got enough hair as it is.
>
> Something like this?
>
> From: "Kirill A. Shutemov"
> Date: Tue, 20 May 2014 13:02:03 +0300
> Subject: [PATCH] mm: nominate faultaround area in bytes rather then page order
>
> There are evidences that faultaround feature is less relevant on
> architectures with page size bigger then 4k. Which makes sense since
> page fault overhead per byte of mapped area should be less there.
>
> Let's rework the feature to specify faultaround area in bytes instead of
> page order. It's 64 kilobytes for now.
>
> The patch effectively disables faultaround on architectures with
> page size >= 64k (like ppc64).
>
> It's possible that some other size of faultaround area is relevant for a
> platform. We can expose `fault_around_bytes' variable to arch-specific
> code once such platforms will be found.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> mm/memory.c | 62
> +++--
> 1 file changed, 23 insertions(+), 39 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 037b812a9531..252b319e8cdf 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3402,63 +3402,47 @@ void do_set_pte(struct vm_area_struct *vma, unsigned
> long address,
> update_mmu_cache(vma, address, pte);
> }
>
> -#define FAULT_AROUND_ORDER 4
> +static unsigned long fault_around_bytes = 65536;
> +
> +static inline unsigned long fault_around_pages(void)
> +{
> + return rounddown_pow_of_two(fault_around_bytes) / PAGE_SIZE;
> +}
> +
> +static inline unsigned long fault_around_mask(void)
> +{
> + return ~(rounddown_pow_of_two(fault_around_bytes) - 1) & PAGE_MASK;
> +}
>
> -#ifdef CONFIG_DEBUG_FS
> -static unsigned int fault_around_order = FAULT_AROUND_ORDER;
>
> -static int fault_around_order_get(void *data, u64 *val)
> +#ifdef CONFIG_DEBUG_FS
> +static int fault_around_bytes_get(void *data, u64 *val)
> {
> - *val = fault_around_order;
> + *val = fault_around_bytes;
> return 0;
> }
>
> -static int fault_around_order_set(void *data, u64 val)
> +static int fault_around_bytes_set(void *data, u64 val)
> {
Kindly ignore the question if not relevant. Even though we need root
access to alter the value, will we be fine with
negative value?.
Regards
Maddy
> - BUILD_BUG_ON((1UL << FAULT_AROUND_ORDER) > PTRS_PER_PTE);
> - if (1UL << val > PTRS_PER_PTE)
> + if (val / PAGE_SIZE > PTRS_PER_PTE)
> return -EINVAL;
> - fault_around_order = val;
> + fault_around_bytes = val;
> return 0;
> }
> -DEFINE_SIMPLE_ATTRIBUTE(fault_around_order_fops,
> - fault_around_order_get, fault_around_order_set, "%llu\n");
> +DEFINE_SIMPLE_ATTRIBUTE(fault_around_bytes_fops,
> + fault_around_bytes_get, fault_around_bytes_set, "%llu\n");
>
> static int __init fault_around_debugfs(void)
> {
> void *ret;
>
> - ret = debugfs_create_file("fault_around_order", 0644, NULL, NULL,
> - &fault_around_order_fops);
> + ret = debugfs_create_file("fault_around_bytes", 0644, NULL, NULL,
> + &fault_around_bytes_fops);
> if (!ret)
> - pr_warn("Failed to create fault_around_order in debugfs");
> + pr_warn("Failed to create fault_around_bytes in debugfs");
> return 0;
> }
> late_initcall(fault_around_debugfs);
> -
> -static inline unsigned long fault_around_pages(void)
> -{
> - return 1UL << fault_around_order;
> -}
> -
> -static inline unsigned long fault_around_mask(void)
> -{
> - return ~((1UL << (PAGE_SHIFT + fault_around_order)) - 1);
> -}
> -#else
> -static inline unsigned long fault_around_pages(void)
> -{
> - unsigned long nr_pages;
> -
> - nr_pages = 1UL << FAULT_AROUND_ORDER;
> - BUILD_BUG_ON(nr_pages > PTRS_PER_PTE);
> - return nr_pages;
> -}
> -
> -static inline unsigned long fault_around_mask(void)
> -{
> - return ~((1UL << (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
> -}
> #endif
>
> static void do_fault_around(struct vm_area_struct *vma, unsigned long
> address,
> @@ -3515,7 +3499,7 @@ static int do_read_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
>* if page by the offset is not ready to be mapped (cold cache or
>* something).
>*/
> -
[RFT PATCH -next v2] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizing its blacklist, it fails and reports many errors
as below.
Failed to find blacklist 000101316830
Failed to find blacklist 0001013000f0a000
Failed to find blacklist 000101315f70a000
Failed to find blacklist 000101324c80a000
Failed to find blacklist 0001013063f0a000
Failed to find blacklist 000101327800a000
Failed to find blacklist 0001013277f0a000
Failed to find blacklist 000101315a70a000
Failed to find blacklist 0001013277e0a000
Failed to find blacklist 000101305a20a000
Failed to find blacklist 0001013277d0a000
Failed to find blacklist 00010130bdc0a000
Failed to find blacklist 00010130dc20a000
Failed to find blacklist 000101309a00a000
Failed to find blacklist 0001013277c0a000
Failed to find blacklist 0001013277b0a000
Failed to find blacklist 0001013277a0a000
Failed to find blacklist 000101327790a000
Failed to find blacklist 000101303140a000
Failed to find blacklist 0001013a3280a000
To fix this bug, this introduces function_entry() macro to
retrieve the entry address from the given function pointer,
and uses for kallsyms_lookup_size_offset() while initializing
blacklist.
Changes in V2:
- Use function_entry() macro when lookin up symbols instead
of storing it.
- Update for the latest -next.
Signed-off-by: Masami Hiramatsu
Reported-by: Tony Luck
Cc: Suzuki K. Poulose
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Ananth N Mavinakayanahalli
Cc: Kevin Hao
Cc: linux-i...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/ia64/include/asm/types.h|2 ++
arch/powerpc/include/asm/types.h | 11 +++
include/linux/types.h|4
kernel/kprobes.c |4 +++-
4 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
index 4c351b1..95279dd 100644
--- a/arch/ia64/include/asm/types.h
+++ b/arch/ia64/include/asm/types.h
@@ -27,5 +27,7 @@ struct fnptr {
unsigned long gp;
};
+#define function_entry(fn) (((struct fnptr *)(fn))->ip)
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_IA64_TYPES_H */
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index bfb6ded..8b89d65 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -25,6 +25,17 @@ typedef struct {
unsigned long env;
} func_descr_t;
+#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
+#define function_entry(fn) (((func_descr_t *)(fn))->entry)
+#else
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/linux/types.h b/include/linux/types.h
index a0bb704..3b95369 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -213,5 +213,9 @@ struct callback_head {
};
#define rcu_head callback_head
+#ifndef function_entry
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_TYPES_H */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2ac9f13..3859c88 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
* added function-return probes.
*/
#include
+#include
#include
#include
#include
@@ -2042,7 +2043,8 @@ static int __init populate_kprobe_blacklist(unsigned long
*start,
unsigned long offset = 0, size = 0;
for (iter = start; iter < end; iter++) {
- if (!kallsyms_lookup_size_offset(*iter, &size, &offset)) {
+ if (!kallsyms_lookup_size_offset(function_entry(*iter),
+&size, &offset)) {
pr_err("Failed to find blacklist %p\n", (void *)*iter);
continue;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
