linaro-kernel October 2013

linaro-kernel@lists.linaro.org

87 participants
222 discussions

arm-soc boot: 33 pass, 0 fail (v3.12-rc4-623-g3edf397)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: arm-soc Git describe: v3.12-rc4-623-g3edf397 Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 29.1 sec omap3-beagle-xm PASS: 0 min 52.7 sec am335x-bone PASS: 0 min 26.7 sec omap3-tobi,3530overo PASS: 0 min 21.3 sec omap4-panda PASS: 1 min 3.5 sec omap4-panda-es PASS: 1 min 0.4 sec omap3-tobi,3730storm PASS: 0 min 23.3 sec omap3-beagle PASS: 0 min 56.1 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 24.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.2 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.1 sec imx6q-wandboard PASS: 0 min 14.7 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.8 sec armada-370-mirabox PASS: 0 min 20.0 sec exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 29.0 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 28.0 sec tegra30-beaver PASS: 0 min 16.4 sec am335x-boneblack PASS: 0 min 34.9 sec omap3-beagle-xm PASS: 0 min 52.5 sec armada-370-mirabox PASS: 0 min 20.7 sec omap4-panda PASS: 1 min 11.5 sec omap4-panda-es PASS: 1 min 6.0 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.6 sec sun4i-a10-cubieboard PASS: 0 min 13.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec omap3-tobi,3530overo PASS: 0 min 20.1 sec am335x-bone PASS: 0 min 33.6 sec imx6q-wandboard PASS: 0 min 15.7 sec omap3-tobi,3730storm PASS: 0 min 22.0 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec omap3-beagle PASS: 0 min 48.1 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 33.5 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.4 sec cat: v3.12-rc4-623-g3edf397-boot-report.log: No such file or directory msmtp: no recipients found Traceback (most recent call last): File "/home/khilman/bin/boot-report.py", line 191, in <module> subprocess.check_output('cat %s | msmtp --read-envelope-from -t --' %maillog, shell=True) File "/usr/lib/python2.7/subprocess.py", line 544, in check_output raise CalledProcessError(retcode, cmd, output=output) subprocess.CalledProcessError: Command 'cat v3.12-rc4-623-g3edf397-boot-report.log | msmtp --read-envelope-from -t --' returned non-zero exit status 64

11 years, 4 months

Re: .align may cause data to be interpreted as instructions

by Dave Martin

On Fri, Oct 18, 2013 at 03:36:38PM +0300, Taras Kondratiuk wrote: > On 10/18/2013 02:03 PM, Jon Medhurst (Tixy) wrote: > > On Thu, 2013-10-17 at 13:55 +0100, Dave Martin wrote: > >> On Thu, Oct 17, 2013 at 01:17:23PM +0100, Jon Medhurst (Tixy) wrote: > >>> I'll send a patch proposing that fix after I've worked out how to test > >>> it on a big-endian kernel. Or if someone else sends a patch for that > >>> with a good commit message that explains what's going on I'll happily > >>> ack that. > >> > >> Disassemble-testing may be enough -- but I advise to dump the relevant > >> code section with objdump -s as well as reading the code disassembly. > >> The hex dump does not lie, whereas the disassembler does sometimes get > >> confused in cases like this. > >> > >> Building and disassembling in BE8 and LE configurations will exercise > >> the two main cases (linker swabbing versus no swabbing) -- comparing > >> the dump of vmlinux with the dump of the .o file shows what the linker > >> is doing. > > > > Thanks, that's the clue I was missing. I was looking at objdumps of .o > > files and wasn't seeing any byte changes caused by this bug, just the > > disassembler treating data as code. Doing a dump of the final linked > > vmlinux I now see that exactly because the data is being treated as > > code, the linking is swapping the byte order of the data, (because ARM > > instructions are always little-endian and need to be fixed from their > > big-endian representation in the .o file?). > > > > In another branch of this thread, Taras said he had patches that were > > tested, so I'll wait for those rather than doing one myself. Taras > > should get the main credit for this investigation anyway :-) > > > > I've just sent patches to Ben. > > I was looking into gas code and found an opposite bug: > If NOP-padding is used to align data it can be treated as data > and saved in BE format. > So we definitely have to explicitly specify fill value for data > alignment in code section. I included that in my original report to the gas folks, so hopefully that should get fixed too. But specifying the padding value definitely seems the way to go here. Cheers ---Dave

11 years, 4 months

arm-soc boot: 33 pass, 0 fail (v3.12-rc4-621-g04cc381)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: arm-soc Git describe: v3.12-rc4-621-g04cc381 Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 28.1 sec omap3-beagle-xm PASS: 0 min 51.1 sec am335x-bone PASS: 0 min 26.8 sec omap3-tobi,3530overo PASS: 0 min 21.3 sec omap4-panda PASS: 1 min 9.1 sec omap4-panda-es PASS: 1 min 3.6 sec omap3-tobi,3730storm PASS: 0 min 23.5 sec omap3-beagle PASS: 0 min 52.3 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.2 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.2 sec imx6q-wandboard PASS: 0 min 14.8 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 22.1 sec armada-370-mirabox PASS: 0 min 20.0 sec exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 30.4 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 25.3 sec tegra30-beaver PASS: 0 min 16.4 sec am335x-boneblack PASS: 0 min 34.8 sec omap3-beagle-xm PASS: 0 min 49.9 sec armada-370-mirabox PASS: 0 min 20.6 sec omap4-panda PASS: 1 min 20.6 sec omap4-panda-es PASS: 1 min 7.0 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.6 sec sun4i-a10-cubieboard PASS: 0 min 13.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec omap3-tobi,3530overo PASS: 0 min 20.1 sec am335x-bone PASS: 0 min 33.7 sec imx6q-wandboard PASS: 0 min 15.7 sec omap3-tobi,3730storm PASS: 0 min 22.5 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec omap3-beagle PASS: 0 min 54.4 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 28.2 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.3 sec cat: v3.12-rc4-621-g04cc381-boot-report.log: No such file or directory msmtp: no recipients found Traceback (most recent call last): File "/home/khilman/bin/boot-report.py", line 191, in <module> subprocess.check_output('cat %s | msmtp --read-envelope-from -t --' %maillog, shell=True) File "/usr/lib/python2.7/subprocess.py", line 544, in check_output raise CalledProcessError(retcode, cmd, output=output) subprocess.CalledProcessError: Command 'cat v3.12-rc4-621-g04cc381-boot-report.log | msmtp --read-envelope-from -t --' returned non-zero exit status 64

11 years, 4 months

[RFC PATCH] of/base: add helper of_property_read_u32_array_index

by zhangfei

Here is one question, is there any existing API could get nth array from arrays table? For example: tune-table = <26000000 1 1 3 3 13000000>, <360000000 6 3 3 1 50000000>, <0 0 0 0 0 0>, <0 0 0 0 0 0>, <26000000 1 1 3 3 13000000>, <360000000 6 3 3 1 50000000>, <0 0 0 0 0 0>, <720000000 6 4 8 4 100000000>; Can we get nth array with index? Like: u32 table[6]; ret = of_property_read_u32_array_index(np, "tune-table", table, 6, index); Thanks On 10/18/2013 09:45 PM, Zhangfei Gao wrote: > of_property_read_u32_array_index is added for read nth array values from u32 arrays > > Signed-off-by: Zhangfei Gao <zhangfei.gao(a)linaro.org> > --- > drivers/of/base.c | 35 +++++++++++++++++++++++++++++++++++ > include/linux/of.h | 12 ++++++++++++ > 2 files changed, 47 insertions(+) > > diff --git a/drivers/of/base.c b/drivers/of/base.c > index 865d3f6..5c5f877 100644 > --- a/drivers/of/base.c > +++ b/drivers/of/base.c > @@ -1002,6 +1002,41 @@ int of_property_read_u32_array(const struct device_node *np, > EXPORT_SYMBOL_GPL(of_property_read_u32_array); > > /** > + * of_property_read_u32_array_index - Find and read an array of 32 bit integers > + * pointed by index from a property. > + * > + * @np: device node from which the property value is to be read. > + * @propname: name of the property to be searched. > + * @out_values: pointer to return value, modified only if return value is 0. > + * @sz: number of array elements to read > + * @index: index of the u32 array in the list of values > + * > + * Search for a property in a device node and read nth 32-bit value(s) from > + * it. Returns 0 on success, -EINVAL if the property does not exist, > + * -ENODATA if property does not have a value, and -EOVERFLOW if the > + * property data isn't large enough. > + * > + * The out_values is modified only if a valid u32 value can be decoded. > + */ > +int of_property_read_u32_array_index(const struct device_node *np, > + const char *propname, u32 *out_values, > + size_t sz, u32 index) > +{ > + const __be32 *val = of_find_property_value_of_size(np, propname, > + (index + 1) * (sz * sizeof(*out_values))); > + > + if (IS_ERR(val)) > + return PTR_ERR(val); > + > + while (index--) > + val += sz; > + while (sz--) > + *out_values++ = be32_to_cpup(val++); > + return 0; > +} > +EXPORT_SYMBOL_GPL(of_property_read_u32_array_index); > + > +/** > * of_property_read_u64 - Find and read a 64 bit integer from a property > * @np: device node from which the property value is to be read. > * @propname: name of the property to be searched. > diff --git a/include/linux/of.h b/include/linux/of.h > index f95aee3..7103983 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -246,6 +246,10 @@ extern int of_property_read_u32_array(const struct device_node *np, > const char *propname, > u32 *out_values, > size_t sz); > +extern int of_property_read_u32_array_index(const struct device_node *np, > + const char *propname, > + u32 *out_values, > + size_t sz, u32 index); > extern int of_property_read_u64(const struct device_node *np, > const char *propname, u64 *out_value); > > @@ -427,6 +431,14 @@ static inline int of_property_read_u32_array(const struct device_node *np, > return -ENOSYS; > } > > +static inline int of_property_read_u32_array_index(const struct device_node *np, > + const char *propname, > + u32 *out_values, > + size_t sz, u32 index) > +{ > + return -ENOSYS; > +} > + > static inline int of_property_read_string(struct device_node *np, > const char *propname, > const char **out_string) >

11 years, 4 months

[RFC][PATCH 0/7] Power-aware scheduling v2

by Morten Rasmussen

Hi, I have revised the previous power scheduler proposal[1] trying to address as many of the comments as possible. The overall idea was discussed at LPC[2,3]. The revised design has removed the power scheduler and replaced it with a high level power driver interface. An interface that allows the scheduler to query the power driver for information and provide hints to guide power management decisions in the power driver. The power driver is going to be a unified platform power driver that can replace cpufreq and cpuidle drivers. Generic power policies will be optional helper functions called from the power driver. Platforms may choose to implement their own policies as part of their power driver. This RFC series prototypes a part of the power driver interface (cpu capacity hints) and shows how they can be used from the scheduler. More extensive use of the power driver hints and queries is left for later. The focus for now is the power driver interface. The patch series includes a power driver/cpufreq governor that can use existing cpufreq drivers as backend. It has been tested (not thoroughly) on ARM TC2. The cpufreq governor power driver implementation is rather horrible, but it illustrates how the power driver interface can be used. Native power drivers is on the todo list. The power driver interface is still missing quite a few calls to handle: Idle, adding extra information to the sched_domain hierarchy to guide scheduling decisions (packing), and possibly scaling of tracked load to compensate for frequency changes and asymmetric systems (big.LITTLE). This set is based on 3.11. I have done ARM TC2 testing based on linux-linaro 2013.08[4] to get cpufreq support for TC2. Morten [1] https://lkml.org/lkml/2013/7/9/314 [2] http://etherpad.osuosl.org/lpc2013-power-efficient-scheduling [3] http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1263/origin… [4] http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git Morten Rasmussen (7): Initial power driver interface infrastructure sched: power: Power driver late callback interface sched: power: go_faster/slower power driver hints sched: power: Remove power capacity hints for kworker threads sched: power: Increase cpu capacity based on rq tracked load sched: power: cpufreq: Initial schedpower cpufreq governor/power driver sched: power: Let the power driver choose the best wake-up cpu arch/arm/Kconfig | 4 + drivers/cpufreq/Kconfig | 11 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cpufreq_schedpower.c | 218 ++++++++++++++++++++++++++++++++++ include/linux/sched/power.h | 37 ++++++ kernel/sched/Makefile | 1 + kernel/sched/core.c | 1 + kernel/sched/fair.c | 53 ++++++++- kernel/sched/power.c | 73 ++++++++++++ kernel/sched/sched.h | 32 +++++ 10 files changed, 430 insertions(+), 1 deletion(-) create mode 100644 drivers/cpufreq/cpufreq_schedpower.c create mode 100644 include/linux/sched/power.h create mode 100644 kernel/sched/power.c -- 1.7.9.5

11 years, 4 months

Re: .align may cause data to be interpreted as instructions

by Dave Martin

On Thu, Oct 17, 2013 at 01:17:23PM +0100, Jon Medhurst (Tixy) wrote: > On Wed, 2013-10-16 at 01:38 +0300, Taras Kondratiuk wrote: > > Hi > > > > I was debugging kprobes-test for BE8 and noticed that some data fields > > are stored in LE instead of BE. It happens because these data fields > > get interpreted as instructions. > > > > Is it a known issue? > > > > For example: > > test_align_fail_data: > > bx lr > > .byte 0xaa > > .align > > .word 0x12345678 > > > > I would expect to see something like this: > > 00000000 <test_align_fail_data>: > > 0: e12fff1e bx lr > > 4: aa .byte 0xaa > > 5: 00 .byte 0x00 > > 6: 0000 .short 0x0000 > > 8: 12345678 .word 0x12345678 > > > > But instead I have: > > 00000000 <test_align_fail_data>: > > 0: e12fff1e bx lr > > 4: aa .byte 0xaa > > 5: 00 .byte 0x00 > > 6: 0000 .short 0x0000 > > 8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000 > > > > As a result the word 0x12345678 will be stored in LE. > > > > I've run several tests and here are my observations: > > - Double ".align" fixes the issue :) > > - Behavior is the same for LE/BE, ARM/Thumb, GCC 4.4.1/4.6.x/4.8.2 > > - Size of alignment doesn't matter. > > - Issue happens only if previous data is not instruction-aligned and > > 0's are added before NOPs. > > - Explicit filling with 0's (.align , 0) fixes the issue, but as a side > > effect data @0x4 is interpreted as a single ".word 0xaa000000" > > instead of ".byte .byte .short". I'm not sure if there can be any > > functional difference because of this. > > After thinking about things overnight, I believe that this is the fix we > should go with. We want to stick alignment padding between data laid > down with .byte and .word so it makes sense to explicitly ask the > toolchain to pad with zeros rather than leaving it the opportunity to > get confused. (.align in the text section probably means it wants to > align with nops, but then sees the initial alignment and/or surrounding > statements look like binary data, not code, and then...) I believe this workaround will work. Looking at the gas code, if .align is given an explicit fill value, the special NOP-padding code in gas is bypassed, and padding works just the same as it would in a data section. Obviously, this only works in situations where the bytes emitted by .align are never executed by the CPU. > I'll send a patch proposing that fix after I've worked out how to test > it on a big-endian kernel. Or if someone else sends a patch for that > with a good commit message that explains what's going on I'll happily > ack that. Disassemble-testing may be enough -- but I advise to dump the relevant code section with objdump -s as well as reading the code disassembly. The hex dump does not lie, whereas the disassembler does sometimes get confused in cases like this. Building and disassembling in BE8 and LE configurations will exercise the two main cases (linker swabbing versus no swabbing) -- comparing the dump of vmlinux with the dump of the .o file shows what the linker is doing. Cheers ---Dave

11 years, 4 months

[RFC][PATCH v5 02/14] ARM: sched: clear SD_SHARE_POWERDOMAIN

by Vincent Guittot

The ARM platforms take advantage of packing tasks on few cores if the latters can be powergated independantly. We use DT and the cpu topology descirption to define at which level a core can be independantly powergated to the others and the SD_SHARE_POWERDOMAIN will be set accordingly at MC and CPU sched_domain level. The power-gate properties should be added with the value 1 in cpu and cluster node when then can power gate independantly from the other. As an example of a quad cores system which can power gate each core independantly, we should have a DT similar to the example below cpus { #address-cells = <1>; #size-cells = <0>; cpu-map { cluster0 { power-gate = <1>; core0 { cpu = <&cpu0>; power-gate = <1>; }; core1 { cpu = <&cpu1>; power-gate = <1>; }; core2 { cpu = <&cpu2>; power-gate = <1>; }; core3 { cpu = <&cpu3>; power-gate = <1>; }; }; }; ... }; Signed-off-by: Vincent Guittot <vincent.guittot(a)linaro.org> --- arch/arm/include/asm/topology.h | 4 ++++ arch/arm/kernel/topology.c | 50 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 53 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h index 58b8b84..5102847 100644 --- a/arch/arm/include/asm/topology.h +++ b/arch/arm/include/asm/topology.h @@ -5,12 +5,16 @@ #include <linux/cpumask.h> +#define CPU_CORE_GATE 0x1 +#define CPU_CLUSTER_GATE 0x2 + struct cputopo_arm { int thread_id; int core_id; int socket_id; cpumask_t thread_sibling; cpumask_t core_sibling; + int flags; }; extern struct cputopo_arm cpu_topology[NR_CPUS]; diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 85a8737..f38f1f9 100644 --- a/arch/arm/kernel/topology.c +++ b/arch/arm/kernel/topology.c @@ -24,6 +24,7 @@ #include <asm/cputype.h> #include <asm/topology.h> +#include <asm/smp_plat.h> /* * cpu power scale management @@ -79,6 +80,51 @@ unsigned long *__cpu_capacity; unsigned long middle_capacity = 1; +static int __init get_dt_power_topology(struct device_node *topo) +{ + const u32 *reg; + int len, power = 0; + int flag = CPU_CORE_GATE; + + for (; topo; topo = of_get_next_parent(topo)) { + reg = of_get_property(topo, "power-gate", &len); + if (reg && len == 4 && be32_to_cpup(reg)) + power |= flag; + flag <<= 1; + } + + return power; +} + +#define for_each_subnode_with_property(dn, pn, prop_name) \ + for (dn = of_find_node_with_property(pn, prop_name); dn; \ + dn = of_find_node_with_property(dn, prop_name)) + +static void __init init_dt_power_topology(void) +{ + struct device_node *cn, *topo; + + /* Get power domain topology information */ + cn = of_find_node_by_path("/cpus/cpu-map"); + if (!cn) { + pr_warn("Missing cpu-map node, bailing out\n"); + return; + } + + for_each_subnode_with_property(topo, cn, "cpu") { + struct device_node *cpu; + + cpu = of_parse_phandle(topo, "cpu", 0); + if (cpu) { + u32 hwid; + + of_property_read_u32(cpu, "reg", &hwid); + cpu_topology[get_logical_index(hwid)].flags = get_dt_power_topology(topo); + + } + } +} + /* * Iterate all CPUs' descriptor in DT and compute the efficiency * (as per table_efficiency). Also calculate a middle efficiency @@ -151,6 +197,8 @@ static void __init parse_dt_topology(void) middle_capacity = ((max_capacity / 3) >> (SCHED_POWER_SHIFT-1)) + 1; + /* Retrieve power topology information from DT */ + init_dt_power_topology(); } /* @@ -283,7 +331,7 @@ void __init init_cpu_topology(void) cpu_topo->socket_id = -1; cpumask_clear(&cpu_topo->core_sibling); cpumask_clear(&cpu_topo->thread_sibling); - + cpu_topo->flags = 0; set_power_scale(cpu, SCHED_POWER_SCALE); } smp_wmb(); -- 1.7.9.5

11 years, 4 months

mainline boot: 33 pass, 0 fail (v3.12-rc5-123-g04919af)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: mainline Git describe: v3.12-rc5-123-g04919af Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 30.3 sec omap3-beagle-xm PASS: 0 min 51.8 sec am335x-bone PASS: 0 min 26.1 sec omap3-tobi,3530overo PASS: 0 min 21.1 sec omap4-panda PASS: 1 min 4.8 sec omap4-panda-es PASS: 1 min 7.3 sec omap3-tobi,3730storm PASS: 0 min 23.4 sec omap3-beagle PASS: 0 min 51.2 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 16.9 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.3 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.0 sec imx6q-wandboard PASS: 0 min 14.7 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.8 sec armada-370-mirabox PASS: 0 min 19.9 sec exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 35.0 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 25.1 sec tegra30-beaver PASS: 0 min 17.1 sec am335x-boneblack PASS: 0 min 34.4 sec omap3-beagle-xm PASS: 0 min 50.1 sec armada-370-mirabox PASS: 0 min 20.5 sec omap4-panda PASS: 1 min 2.7 sec omap4-panda-es PASS: 0 min 59.9 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.9 sec sun4i-a10-cubieboard PASS: 0 min 13.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec omap3-tobi,3530overo PASS: 0 min 20.2 sec am335x-bone PASS: 0 min 33.2 sec imx6q-wandboard PASS: 0 min 15.7 sec omap3-tobi,3730storm PASS: 0 min 22.6 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.6 sec omap3-beagle PASS: 0 min 54.1 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 34.0 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.3 sec

11 years, 4 months

[RFC PATCH 0/5] PSCI system off and reset for KVM ARM/ARM64

by Anup Patel

The Power State and Coordination Interface (PSCI) specification defines SYSTEM_OFF and SYSTEM_RESET functions for system poweroff and reboot. This patchset adds: 1. Emulation of PSCI SYSTEM_OFF and SYSTEM_RESET functions in KVM ARM/ARM64 by forwarding them to user space (QEMU or KVMTOOL) 2. System poweroff and reboot using PSCI for ARM/ARM64 kernel Anup Patel (5): ARM/ARM64: KVM: Update user space API header for PSCI emulation ARM/ARM64: KVM: Forward PSCI SYSTEM_OFF and SYSTEM_RESET to user space KVM: Add documentation for KVM_EXIT_PSCI exit reason ARM: psci: Add support for system reboot and poweroff ARM64: psci: Add support for system reboot and poweroff Documentation/virtual/kvm/api.txt | 13 +++++++++ arch/arm/include/asm/kvm_psci.h | 25 +++++++++++++++- arch/arm/include/uapi/asm/kvm.h | 2 ++ arch/arm/kernel/psci.c | 36 +++++++++++++++++++++++ arch/arm/kvm/arm.c | 12 ++++++-- arch/arm/kvm/handle_exit.c | 12 ++++++-- arch/arm/kvm/psci.c | 57 ++++++++++++++++++++++++++++++++++--- arch/arm64/include/asm/kvm_psci.h | 25 +++++++++++++++- arch/arm64/include/uapi/asm/kvm.h | 2 ++ arch/arm64/kernel/psci.c | 36 +++++++++++++++++++++++ arch/arm64/kvm/handle_exit.c | 24 ++++++++++++---- include/uapi/linux/kvm.h | 7 +++++ 12 files changed, 233 insertions(+), 18 deletions(-) -- 1.7.9.5

11 years, 4 months

next-thierry boot: 27 pass, 6 fail (next-20131017)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: next-thierry Git describe: next-20131017 Failed boot tests (console logs at the end) =========================================== imx6q-wandboard: FAIL: imx_v6_v7_defconfig armada-xp-openblocks-ax3-4: FAIL: mvebu_defconfig exynos5250-arndale: FAIL: exynos_defconfig ste-snowball: FAIL: multi_v7_defconfig armada-xp-openblocks-ax3-4: FAIL: multi_v7_defconfig ste-snowball: FAIL: u8500_defconfig Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 28.0 sec omap3-beagle-xm PASS: 0 min 51.7 sec am335x-bone PASS: 0 min 31.8 sec omap3-tobi,3530overo PASS: 0 min 21.3 sec omap4-panda PASS: 1 min 5.7 sec omap4-panda-es PASS: 1 min 5.2 sec omap3-tobi,3730storm PASS: 0 min 20.3 sec omap3-beagle PASS: 1 min 4.0 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.3 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.3 sec imx6q-wandboard FAIL: 0 min 10.4 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 FAIL: 0 min 20.1 sec armada-370-mirabox PASS: 0 min 20.0 sec exynos_defconfig ---------------- exynos5250-arndale FAIL: 0 min 33.4 sec multi_v7_defconfig ------------------ ste-snowball FAIL: 0 min 23.3 sec tegra30-beaver PASS: 0 min 17.1 sec am335x-boneblack PASS: 0 min 34.9 sec omap3-beagle-xm PASS: 0 min 48.2 sec armada-370-mirabox PASS: 0 min 20.6 sec omap4-panda PASS: 1 min 2.4 sec omap4-panda-es PASS: 1 min 4.8 sec armada-xp-openblocks-ax3-4 FAIL: 0 min 21.3 sec sun4i-a10-cubieboard PASS: 0 min 13.8 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.4 sec omap3-tobi,3530overo PASS: 0 min 20.0 sec am335x-bone PASS: 0 min 33.7 sec imx6q-wandboard PASS: 0 min 16.8 sec omap3-tobi,3730storm PASS: 0 min 22.5 sec imx6dl-wandboard,wand-dual PASS: 0 min 17.9 sec omap3-beagle PASS: 0 min 53.3 sec u8500_defconfig --------------- ste-snowball FAIL: 0 min 19.2 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.4 sec Console logs for failures ========================= imx_v6_v7_defconfig ------------------- imx6q-wandboard: FAIL: last 24 lines of boot log: ------------------------------------------------- r6:807ffdb8 r5:00000000 r4:8081fff0 r3:00000000 [<800120fc>] (show_stack+0x0/0x1c) from [<805dcbc0>] (dump_stack+0x84/0x9c) [<805dcb3c>] (dump_stack+0x0/0x9c) from [<8001435c>] (handle_IPI+0x134/0x180) r5:8080ab80 r4:00000000 [<80014228>] (handle_IPI+0x0/0x180) from [<80008668>] (gic_handle_irq+0x5c/0x64) r8:8084aaee r7:f4000100 r6:80803f40 r5:8080acd0 r4:f400010c r3:8000f58c [<8000860c>] (gic_handle_irq+0x0/0x64) from [<80012d00>] (__irq_svc+0x40/0x54) Exception stack(0x80803f40 to 0x80803f88) 3f40: 81fa2778 00000000 000009bc 8001de20 80802000 80802000 8080a908 805e6414 3f60: 8084aaee 8084aaee 80802000 80803f94 80803f98 80803f88 8000f58c 8000f590 3f80: 60000113 ffffffff r7:80803f74 r6:ffffffff r5:60000113 r4:8000f590 [<8000f558>] (arch_cpu_idle+0x0/0x44) from [<80060250>] (cpu_startup_entry+0x110/0x160) [<80060140>] (cpu_startup_entry+0x0/0x160) from [<805d719c>] (rest_init+0x68/0x80) r7:81f9f680 r3:00000000 [<805d7134>] (rest_init+0x0/0x80) from [<807b0b00>] (start_kernel+0x2d0/0x330) [<807b0830>] (start_kernel+0x0/0x330) from [<10008074>] (0x10008074) r7:8080ebb8 r6:807f2cfc r5:8080a8a8 r4:10c53c7d ~$off # PYBOOT: Exception: kernel: Unable to handle kernel paging request at virtual address ffffffff # PYBOOT: Time: 10.40 seconds. # PYBOOT: Result: FAIL mvebu_defconfig --------------- armada-xp-openblocks-ax3-4: FAIL: last 24 lines of boot log: ------------------------------------------------------------ [<c04a6c04>] (kernel_init_freeable+0x138/0x1d8) from [<c03810d0>] (kernel_init+0x8/0x158) [<c03810d0>] (kernel_init+0x8/0x158) from [<c000e278>] (ret_from_fork+0x14/0x3c) Code: 05121008 05031004 e15c0003 8afffff8 (e59440f0) ---[ end trace 203bd907c847398c ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.12.0-rc5-next-20131017 #1 [<c0015844>] (unwind_backtrace+0x0/0xf4) from [<c00116c0>] (show_stack+0x10/0x14) [<c00116c0>] (show_stack+0x10/0x14) from [<c0385b40>] (dump_stack+0x80/0x90) [<c0385b40>] (dump_stack+0x80/0x90) from [<c0014130>] (handle_IPI+0x134/0x15c) [<c0014130>] (handle_IPI+0x134/0x15c) from [<c00085ac>] (armada_370_xp_handle_irq+0xac/0xb0) [<c00085ac>] (armada_370_xp_handle_irq+0xac/0xb0) from [<c00121c0>] (__irq_svc+0x40/0x50) Exception stack(0xef077fa0 to 0xef077fe8) 7fa0: c0fa05f8 00000000 000008f0 000008f0 ef076000 c04d8458 c038c744 ef076000 7fc0: c04ff0ed 00000001 c04ff0ed ef076000 00000000 ef077fe8 c000f40c c0052474 7fe0: 60000113 ffffffff [<c00121c0>] (__irq_svc+0x40/0x50) from [<c0052474>] (cpu_startup_entry+0x10c/0x14c) [<c0052474>] (cpu_startup_entry+0x10c/0x14c) from [<00008644>] (0x8644) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel paging request at virtual address 11014702 # PYBOOT: Time: 20.05 seconds. # PYBOOT: Result: FAIL exynos_defconfig ---------------- exynos5250-arndale: FAIL: last 24 lines of boot log: ---------------------------------------------------- tftp 0x407c0000 tmp/arndale-zyGoxU/exynos5250-arndale.dtb Waiting for Ethernet connection... done. Using asx0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.171 Filename 'tmp/arndale-zyGoxU/exynos5250-arndale.dtb'. Load address: 0x407c0000 Loading: *### done Bytes transferred = 32949 (80b5 hex) ARNDALE5250 # printenv bootargs printenv bootargs bootargs=console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 rootwait rootfstype=ext4 ip=192.168.1.171:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none ARNDALE5250 # bootz 0x40800000 - 0x407c0000 bootz 0x40800000 - 0x407c0000 ## Flattened Device Tree blob at 407c0000 Booting using the fdt blob at 0x407c0000 Using Device Tree in place at 407c0000, end 407cb0b4 Starting kernel ... ~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 33.38 seconds. # PYBOOT: Result: FAIL multi_v7_defconfig ------------------ ste-snowball: FAIL: last 24 lines of boot log: ---------------------------------------------- [ 1.019500] [<c04ae4f4>] (kernel_init+0x8/0x158) from [<c000e3f8>] (ret_from_fork+0x14/0x3c) [ 1.027954] Code: ebfffd0b e3500000 e589000c 0a000059 (e5903038) [ 1.034057] ---[ end trace 85dc55f280751189 ]--- [ 1.038696] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.038696] [ 1.047821] CPU1: stopping [ 1.050537] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.12.0-rc5-next-20131017 #1 [ 1.058990] [<c0014e34>] (unwind_backtrace+0x0/0xf4) from [<c0011810>] (show_stack+0x10/0x14) [ 1.067504] [<c0011810>] (show_stack+0x10/0x14) from [<c04b255c>] (dump_stack+0x84/0x94) [ 1.075592] [<c04b255c>] (dump_stack+0x84/0x94) from [<c00130f4>] (handle_IPI+0x138/0x160) [ 1.083862] [<c00130f4>] (handle_IPI+0x138/0x160) from [<c00087a8>] (gic_handle_irq+0x58/0x5c) [ 1.092468] [<c00087a8>] (gic_handle_irq+0x58/0x5c) from [<c0012340>] (__irq_svc+0x40/0x50) [ 1.100799] Exception stack(0xee89ff98 to 0xee89ffe0) [ 1.105834] ff80: c12db5f0 00000000 [ 1.114013] ffa0: 0000053e c0019c60 ee89e000 c06c6478 c04bc538 ee89e000 c0750c96 00000001 [ 1.122192] ffc0: c0750c96 ee89e000 00000000 ee89ffe0 c000f570 c000f574 60000113 ffffffff [ 1.130371] [<c0012340>] (__irq_svc+0x40/0x50) from [<c000f574>] (arch_cpu_idle+0x38/0x3c) [ 1.138641] [<c000f574>] (arch_cpu_idle+0x38/0x3c) from [<c0079adc>] (cpu_startup_entry+0x118/0x158) [ 1.147766] [<c0079adc>] (cpu_startup_entry+0x118/0x158) from [<000088e4>] (0x88e4) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel paging request at virtual address fde00033 # PYBOOT: Time: 23.32 seconds. # PYBOOT: Result: FAIL armada-xp-openblocks-ax3-4: FAIL: last 24 lines of boot log: ------------------------------------------------------------ [ 159.689030] [<c0645d70>] (kernel_init_freeable+0x13c/0x1dc) from [<c04ae4f4>] (kernel_init+0x8/0x158) [ 159.698279] [<c04ae4f4>] (kernel_init+0x8/0x158) from [<c000e3f8>] (ret_from_fork+0x14/0x3c) [ 159.706742] Code: eaff2e33 e92d4038 e2505000 08bd8038 (e59530f0) [ 159.712864] ---[ end trace 6b597c9b29bc0bf4 ]--- [ 159.717527] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 159.717527] [ 159.726687] CPU1: stopping [ 159.729405] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.12.0-rc5-next-20131017 #1 [ 159.737877] [<c0014e34>] (unwind_backtrace+0x0/0xf4) from [<c0011810>] (show_stack+0x10/0x14) [ 159.746430] [<c0011810>] (show_stack+0x10/0x14) from [<c04b255c>] (dump_stack+0x84/0x94) [ 159.754545] [<c04b255c>] (dump_stack+0x84/0x94) from [<c00130f4>] (handle_IPI+0x138/0x160) [ 159.762834] [<c00130f4>] (handle_IPI+0x138/0x160) from [<c0008700>] (armada_370_xp_handle_irq+0xac/0xb0) [ 159.772341] [<c0008700>] (armada_370_xp_handle_irq+0xac/0xb0) from [<c0012340>] (__irq_svc+0x40/0x50) [ 159.781582] Exception stack(0xee877fa0 to 0xee877fe8) [ 159.786648] 7fa0: c12d65f0 00000000 000009ce 000009ce ee876000 c06c6478 c04bc538 ee876000 [ 159.794849] 7fc0: c0750c96 00000001 c0750c96 ee876000 c0709100 ee877fe8 c000f570 c0079adc [ 159.803046] 7fe0: 60000113 ffffffff [ 159.806552] [<c0012340>] (__irq_svc+0x40/0x50) from [<c0079adc>] (cpu_startup_entry+0x118/0x158) [ 159.815362] [<c0079adc>] (cpu_startup_entry+0x118/0x158) from [<000088e4>] (0x88e4) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel paging request at virtual address efe7c0ef # PYBOOT: Time: 21.31 seconds. # PYBOOT: Result: FAIL u8500_defconfig --------------- ste-snowball: FAIL: last 24 lines of boot log: ---------------------------------------------- [<c02b6fe0>] (__clk_lookup_subtree+0x18/0x68) from [<c02b7008>] (__clk_lookup_subtree+0x40/0x68) Code: 1afffffb e12fff1e e1a03000 eafffff8 (e4d03001) ---[ end trace a610b44b4df3a2a2 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU1: stopping CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.12.0-rc5-next-20131017 #1 [<c001547c>] (unwind_backtrace+0x0/0xf4) from [<c00118a8>] (show_stack+0x10/0x14) [<c00118a8>] (show_stack+0x10/0x14) from [<c03a7800>] (dump_stack+0x98/0xc4) [<c03a7800>] (dump_stack+0x98/0xc4) from [<c00138f4>] (handle_IPI+0x130/0x144) [<c00138f4>] (handle_IPI+0x130/0x144) from [<c0008578>] (gic_handle_irq+0x58/0x5c) [<c0008578>] (gic_handle_irq+0x58/0x5c) from [<c00123c0>] (__irq_svc+0x40/0x70) Exception stack(0xef07ff98 to 0xef07ffe0) ff80: ffffffed 00b08000 ffa0: c053ad6c 00000000 ef07e000 c053a428 c03adaa4 ef07e000 c0564067 00000001 ffc0: c0564067 ef07e000 00000000 ef07ffe0 c000f600 c000f5f8 60000113 ffffffff [<c00123c0>] (__irq_svc+0x40/0x70) from [<c000f5f8>] (arch_cpu_idle+0x2c/0x38) [<c000f5f8>] (arch_cpu_idle+0x2c/0x38) from [<c005257c>] (cpu_startup_entry+0x114/0x154) [<c005257c>] (cpu_startup_entry+0x114/0x154) from [<00008604>] (0x8604) ~$off # PYBOOT: Exception: kernel: Unable to handle kernel NULL pointer dereference at virtual address 000003e8 # PYBOOT: Time: 19.24 seconds. # PYBOOT: Result: FAIL

11 years, 4 months

← Newer
1
...
6
7
8
9
10
11
12
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel October 2013