Re: [PATCH 1/2] cpufreq: Set policy->related_cpus to atleast policy->cpus
On 29 January 2013 10:09, Viresh Kumar wrote: > With the addition of following patch, related_cpus is required to be set by > cpufreq platform drivers: > > commit c1070fd743533efb54e98142252283583f379190 > Author: Viresh Kumar > Date: Mon Jan 14 13:23:04 2013 + > > cpufreq: Simplify cpufreq_add_dev() > > Because this change is required by all platform drivers, why not do this in > the > core itself. Hence, this patch is an attempt towards fixing all broken > drivers. > > From now on, platforms don't really need to set related_cpus from their init() > routines, as the same work is done by core too. > > If platform driver needs to set the related_cpus mask with some additional > cpus, > other than cpus present in policy->cpus, they are free to do it as we aren't > overriding anything. > > Signed-off-by: Viresh Kumar > --- > Inderpal, > > Can you please add your tested-by for this patch? And this will require you to > drop your patch for exynos-cpufreq.c :) ARM mail servers are broken. Patches attached. 0001-cpufreq-Set-policy-related_cpus-to-atleast-policy-cp.patch Description: Binary data 0002-Revert-cpufreq-Don-t-use-cpu-removed-during-cpufreq_.patch Description: Binary data ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] cpufreq: Set policy->related_cpus to atleast policy->cpus
With the addition of following patch, related_cpus is required to be set by
cpufreq platform drivers:
commit c1070fd743533efb54e98142252283583f379190
Author: Viresh Kumar
Date: Mon Jan 14 13:23:04 2013 +
cpufreq: Simplify cpufreq_add_dev()
Because this change is required by all platform drivers, why not do this in the
core itself. Hence, this patch is an attempt towards fixing all broken drivers.
>From now on, platforms don't really need to set related_cpus from their init()
routines, as the same work is done by core too.
If platform driver needs to set the related_cpus mask with some additional cpus,
other than cpus present in policy->cpus, they are free to do it as we aren't
overriding anything.
Signed-off-by: Viresh Kumar
---
Inderpal,
Can you please add your tested-by for this patch? And this will require you to
drop your patch for exynos-cpufreq.c :)
drivers/cpufreq/cpufreq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f5dc02b..db81382 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -554,8 +554,6 @@ static ssize_t show_cpus(const struct cpumask *mask, char
*buf)
*/
static ssize_t show_related_cpus(struct cpufreq_policy *policy, char *buf)
{
- if (cpumask_empty(policy->related_cpus))
- return show_cpus(policy->cpus, buf);
return show_cpus(policy->related_cpus, buf);
}
@@ -945,6 +943,9 @@ static int cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif)
goto err_unlock_policy;
}
+ /* related cpus should atleast have policy->cpus */
+ cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
+
/*
* affected cpus must always be the one, which are online. We aren't
* managing offline cpus here.
--
1.7.12.rc2.18.g61b472e
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] Revert "cpufreq: Don't use cpu removed during cpufreq_driver_unregister"
This reverts commit 956f33948b95aa91f6cbc6860087671c6ac1de4b. With the addition of following patch, this change/variable is not required: commit b9ba2725343ae57add3f324dfa5074167f48de96 Author: Viresh Kumar Date: Mon Jan 14 13:23:03 2013 + cpufreq: Simplify __cpufreq_remove_dev() Signed-off-by: Viresh Kumar --- drivers/cpufreq/cpufreq.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index db81382..8d521422 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -47,9 +47,6 @@ static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor); #endif static DEFINE_SPINLOCK(cpufreq_driver_lock); -/* Used when we unregister cpufreq driver */ -static struct cpumask cpufreq_online_mask; - /* * cpu_policy_rwsem is a per CPU reader-writer semaphore designed to cure * all cpufreq/hotplug/workqueue/etc related lock issues. @@ -951,7 +948,6 @@ static int cpufreq_add_dev(struct device *dev, struct subsys_interface *sif) * managing offline cpus here. */ cpumask_and(policy->cpus, policy->cpus, cpu_online_mask); - cpumask_and(policy->cpus, policy->cpus, &cpufreq_online_mask); policy->user_policy.min = policy->min; policy->user_policy.max = policy->max; @@ -1133,7 +1129,6 @@ static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif) if (unlikely(lock_policy_rwsem_write(cpu))) BUG(); - cpumask_clear_cpu(cpu, &cpufreq_online_mask); retval = __cpufreq_remove_dev(dev, sif); return retval; } @@ -1875,8 +1870,6 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data) cpufreq_driver = driver_data; spin_unlock_irqrestore(&cpufreq_driver_lock, flags); - cpumask_setall(&cpufreq_online_mask); - ret = subsys_interface_register(&cpufreq_interface); if (ret) goto err_null_driver; -- 1.7.12.rc2.18.g61b472e ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kernel NULL pointer dereference
On 28 January 2013 14:17, Andy Green wrote: > No, "blowing chunks" (slang for vomiting) is different than "blowing > up"... the 4460 has a separate comparator that is able to reset the SoC if > it gets really too hot. > Ah, another term for my collection of disgusting things to talk about during lunch. ;) It will crash colourfully before then is what I mean, unless one of these > thermal mechanisms is helping. It varies by chip actually, some can idle > at 1.2GHz for a long time before choking others crash in a few seconds. > Not sure it adds anything, but I had a Panda here at home (room temperature between 18 and 21 Celsius) running Ubuntu 12.04 desktop version referred from the Panda wiki (with GUI and everything) for 6 days building LLVM 24/7 without a single glitch. The moment I put on the LAVA rack, it failed before the end of the first build. I then remove all GUI packages, useless services, kernel modules (left only the LED driver) and it went back to almost-normal. It failed only once since then. The failure is simple: it freezes. I haven't seen anything on the screen (it blacks out), or over serial and the machine stops responding to ping. Dead. But on. And hot. It looks as though it hit an area outside the system and is running the same NOPs over and over. Some say there was an Indian cemetery in that land before The Quorum was built, it could be a curse, ghosts or even leprechauns. Scratch that, there isn't a single pub nearby, probably ghosts, then. cheers, --renato ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Tools of updating kernel related files for android
Hi, All Android team now has tools for updating the kernel related files without recreating the sdcard. The detail information about the tools is described here: https://wiki.linaro.org/Platform/Android/KernelUpdateTools And here just list some examples: 1. update all the kernel related files with boot.tar.bz2 ./update-android.sh out/target/product/pandaboard/boot.tar.bz2 2. only update one file that will be in the boot.tar.bz2 when packaged, Like board.dtb/uImage/cmdline ./update-android.sh out/target/product/pandaboard/boot/board.dtb ./update-android.sh out/target/product/pandaboard/boot/uImage ./update-android.sh out/target/product/pandaboard/boot/cmdline 3. update all kernel modules. ./update-android.sh out/target/product/pandaboard/obj/kernel 4. update files in uInitrd ./update-uInitrd.sh /tmp/init.rc this will replace the /ini.rc file in uInitrd with the passed /tmp/init.rc Hope these tools will be helpful during your development of android. Any comments/suggestion, please feel free to send to me. Thanks, Yongqin Liu --- #mailing list linaro-andr...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validat...@lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kernel NULL pointer dereference
On 28/01/13 21:10, the mail apparently from Renato Golin included: On 28 January 2013 12:43, Andy Green mailto:andy.gr...@linaro.org>> wrote: Without this or something doing a similar deal, a Panda ES will blow chunks after a short period at 1.2GHz. Hi Andy, I agree kernel panic is better than blowing up the board, but that might indicate the scaling is not working very well. Also, does that mean I should not use the 12.02 image because the risk of blowing up my board? No, "blowing chunks" (slang for vomiting) is different than "blowing up"... the 4460 has a separate comparator that is able to reset the SoC if it gets really too hot. It will crash colourfully before then is what I mean, unless one of these thermal mechanisms is helping. It varies by chip actually, some can idle at 1.2GHz for a long time before choking others crash in a few seconds. I can't really remember the status a year ago, we had it working a while before Panda ES was available IIRC. I did not hear of any actually burned 4460, I think the reset mechanism will save it. Tilt-3.3 and -3.4 should be fine at least. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kernel NULL pointer dereference
On 28 January 2013 12:43, Andy Green wrote: > Without this or something doing a similar deal, a Panda ES will blow > chunks after a short period at 1.2GHz. Hi Andy, I agree kernel panic is better than blowing up the board, but that might indicate the scaling is not working very well. Also, does that mean I should not use the 12.02 image because the risk of blowing up my board? cheers, --renato ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kernel NULL pointer dereference
On 26/01/13 06:06, the mail apparently from Renato Golin included: Hi folks, I'm testing different kernels with the LLVM LAVA job and the latest one segfaulted. If you search for the phrase on the subject on the URL below: https://validation.linaro.org/lava-server/scheduler/job/46067/log_file You'll see the stack trace and memory dump. These are the tar balls I used: "rootfs": "http://releases.linaro.org/12.12/ubuntu/quantal-images/nano/linaro-quantal-nano-20121217-210.tar.gz";, "hwpack": "http://releases.linaro.org/12.12/ubuntu/quantal-hwpacks/hwpack_linaro-panda_20121217-20_armhf_supported.tar.gz"; Is this the right place to report this kind of stuff? Hi - We added a bunch of thermal-related bits (different from the thermal bits that Linaro PM guys got upstream) to the tilt- kernels. It's support for their thermal sensor and TI's "thermal framework" which monitors it and messes with the cpu frequency limit. Without this or something doing a similar deal, a Panda ES will blow chunks after a short period at 1.2GHz. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PM-QA PATCH 5/8] thermal: add switch for thermal_06.sh
On 28 January 2013 18:16, Amit Kucheria wrote: > On Mon, Jan 28, 2013 at 11:38 AM, Hongbo Zhang > wrote: >> This script aims at testing all the trip points are crossed or not, since the >> trip points are usually very high and can be reached only in extreme >> conditions >> like high environment temerature etc, in normal conditions they cannot be all >> crossed even if the CPU load is high, so failures will be reported and this >> will introduce a mess. >> Add this switch to switch off this test by default, anyone who wants to do >> this >> test still can enable it manually. > > NACK to this implementation. It should be possible to enable/disable > default tests in a single file in the top-level directory. It > shouldn't be required to go to each test script to set a variable > enable/disabling a test. > Good suggestion. There are also some other switches besides this one, I will collect them into one top level config file. >> Signed-off-by: Hongbo Zhang >> --- >> thermal/thermal_06.sh | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/thermal/thermal_06.sh b/thermal/thermal_06.sh >> index 13f695d..28fdaec 100755 >> --- a/thermal/thermal_06.sh >> +++ b/thermal/thermal_06.sh >> @@ -28,6 +28,13 @@ >> source ../include/functions.sh >> source ../include/thermal_functions.sh >> >> +# test_switch: switch on/off this test >> +test_switch=0 >> +if [ "$test_switch" -eq 0 ]; then >> +log_skip "test of trip points being crossed" >> +exit 0 >> +fi >> + >> TEST_LOOP=100 >> CPU_HEAT_BIN=../utils/heat_cpu >> cpu_pid=0 >> -- >> 1.8.0 >> >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PM-QA PATCH 5/8] thermal: add switch for thermal_06.sh
On Mon, Jan 28, 2013 at 11:38 AM, Hongbo Zhang wrote: > This script aims at testing all the trip points are crossed or not, since the > trip points are usually very high and can be reached only in extreme > conditions > like high environment temerature etc, in normal conditions they cannot be all > crossed even if the CPU load is high, so failures will be reported and this > will introduce a mess. > Add this switch to switch off this test by default, anyone who wants to do > this > test still can enable it manually. NACK to this implementation. It should be possible to enable/disable default tests in a single file in the top-level directory. It shouldn't be required to go to each test script to set a variable enable/disabling a test. > Signed-off-by: Hongbo Zhang > --- > thermal/thermal_06.sh | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/thermal/thermal_06.sh b/thermal/thermal_06.sh > index 13f695d..28fdaec 100755 > --- a/thermal/thermal_06.sh > +++ b/thermal/thermal_06.sh > @@ -28,6 +28,13 @@ > source ../include/functions.sh > source ../include/thermal_functions.sh > > +# test_switch: switch on/off this test > +test_switch=0 > +if [ "$test_switch" -eq 0 ]; then > +log_skip "test of trip points being crossed" > +exit 0 > +fi > + > TEST_LOOP=100 > CPU_HEAT_BIN=../utils/heat_cpu > cpu_pid=0 > -- > 1.8.0 > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: kernel NULL pointer dereference
On 27 January 2013 23:30, Michael Hudson-Doyle wrote: > In the past hasn't this sort of problem usually turned out to be heat > related? Or is this something else? > Hi Michael, It could very well be, I don't know how the heating problem used to manifest before... However, the original kernel I was using (12.02) had no problem whatsoever, and I ran it many many times on the same set of boards, without an issue. "rootfs": " http://releases.linaro.org/12.02/ubuntu/oneiric-images/nano/linaro-o-nano-tar-20120221-0.tar.gz ", "hwpack": " http://releases.linaro.org/12.02/ubuntu/oneiric-images/nano/hwpack_linaro-lt-panda_20120221-1_armel_supported.tar.gz " Maybe it's the conjunction of heating up + some change with newer kernels... I'll keep downgrading until it starts working again and will let you know. cheers, --renato ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
