linaro-kernel

linaro-kernel@lists.linaro.org

10095 discussions

[PATCH v7 0/5] Add ST-Ericsson AB8500 HWMON driver

by Hongbo Zhang

Guenter and Anton, Only one minor update as Guenter mentioned for v6, thank you. v6 -> v7 changes: - move exporting symbols from [5/5] to [4/5], which was a mistake. v5 -> v6 changes: - add depend on AB8500_BM in Kconfig - fix wrong usage of clamp_val() - export symbols for module compiling v4 -> v5 changes: - split the old [2/3]-ab8500-re-arrange-ab8500-power-and-temperature-data into new three [2/5], [3/5] and [4/5] patches. - hwmon driver minor coding style clean ups: - {} usage in if-else statement in ab8500_read_sensor function - index error fix in gpadc_monitor function - fix issue of clamp_val() usage - remove unnecessary else in function abx500_attrs_visible - remove redundant print message about irq set up - return the calling function return value directly in probe function v3 -> v4 changes: for patch [3/3] - define delays in HZ - update ab8500_read_sensor function, returning temp by parameter - remove ab8500_is_visible function - use clamp_val in set_min and set_max callback - remove unnecessary locks in remove and suspend functions - let abx500 and ab8500 use its own data structure for patch [2/3] - move the data tables from driver/power/ab8500_bmdata.c to include/linux/power/ab8500.h - rename driver/power/ab8500_bmdata.c to driver/power/ab8500_bm.c - rename these variable names to eliminate CamelCase warnings - add const attribute to these data v2 -> v3 changes: - Add interface for converting voltage to temperature - Remove temp5 sensor since we cannot offer temperature read interface of it - Update hyst to use absolute temperature instead of a difference - Add the 3/3 patch v1 -> v2 changes: - Add Documentation/hwmon/abx500 and Documentation/hwmon/abx500 - Make devices which cannot report milli-Celsius invisible - Add temp5_crit interface - Re-work the old find_active_thresholds() to threshold_updated() - Reset updated_min_alarm and updated_max_alarm at the end of each loop - Update the hyst mechamisn to make it works as real hyst - Remove non-stand attributes - Re-order the operations sequence inside probe and remove functions - Update all the lock usages to eliminate race conditions - Make attibutes index starts from 0 also changes: - Since the old [1/2] "ARM: ux500: rename ab8500 to abx500 for hwmon driver" has been merged by Samuel, so won't send it again. - Add another new patch "ab8500_btemp: export two symblols" as [2/2] of this patch set. Hongbo Zhang (5): ab8500_btemp: make ab8500_btemp_get* interfaces public ab8500: power: eliminate CamelCase warning of some variables ab8500: power: add const attributes to some data arrays ab8500: power: export abx500_res_to_temp tables for hwmon hwmon: add ST-Ericsson ABX500 hwmon driver Documentation/hwmon/ab8500 | 22 ++ Documentation/hwmon/abx500 | 28 ++ drivers/hwmon/Kconfig | 13 + drivers/hwmon/Makefile | 1 + drivers/hwmon/ab8500.c | 206 +++++++++++++++ drivers/hwmon/abx500.c | 491 +++++++++++++++++++++++++++++++++++ drivers/hwmon/abx500.h | 69 +++++ drivers/power/ab8500_bmdata.c | 42 +-- drivers/power/ab8500_btemp.c | 5 +- drivers/power/ab8500_fg.c | 4 +- include/linux/mfd/abx500.h | 6 +- include/linux/mfd/abx500/ab8500-bm.h | 5 + include/linux/power/ab8500.h | 16 ++ 13 files changed, 885 insertions(+), 23 deletions(-) create mode 100644 Documentation/hwmon/ab8500 create mode 100644 Documentation/hwmon/abx500 create mode 100644 drivers/hwmon/ab8500.c create mode 100644 drivers/hwmon/abx500.c create mode 100644 drivers/hwmon/abx500.h create mode 100644 include/linux/power/ab8500.h -- 1.8.0

12 years, 3 months

[ACTIVITY] 2013-03-23 - 2012-03-29

by David Long

=== David Long === === Highlights === * I returned to and fixed the uprobe xol issue in my upleveled version of Rabin's patches. * Thanks to Rabin for offering to look at the above problem, although I was able to fix it without his help. * I've updated my Ubuntu PC and I have been using that for comparisons of uprobes behavior. === Plans === * Switch back to working on the code restructuring, === Issues === === Travel/Time Off === * I unexpectedly had to take vacation on Monday and Tuesday for personal business. -dl

12 years, 3 months

[PATCH] cpufreq: cpufreq-cpu0: Call CPUFREQ_POSTCHANGE notifier for failure cases too

by Viresh Kumar

Currently we are simply returning from target() if we encounter some error after broadcasting CPUFREQ_PRECHANGE notifier. Which looks to be wrong as others might depend on POSTCHANGE notifier for their functioning. So, better broadcast CPUFREQ_POSTCHANGE notifier for these failure cases too, but with old frequency. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq-cpu0.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index 1cab820..6561853 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -74,7 +74,9 @@ static int cpu0_set_target(struct cpufreq_policy *policy, if (IS_ERR(opp)) { rcu_read_unlock(); pr_err("failed to find OPP for %ld\n", freq_Hz); - return PTR_ERR(opp); + freqs.new = freqs.old; + ret = PTR_ERR(opp); + goto post_notify; } volt = opp_get_voltage(opp); rcu_read_unlock(); @@ -92,7 +94,7 @@ static int cpu0_set_target(struct cpufreq_policy *policy, if (ret) { pr_err("failed to scale voltage up: %d\n", ret); freqs.new = freqs.old; - return ret; + goto post_notify; } } @@ -101,7 +103,8 @@ static int cpu0_set_target(struct cpufreq_policy *policy, pr_err("failed to set clock rate: %d\n", ret); if (cpu_reg) regulator_set_voltage_tol(cpu_reg, volt_old, tol); - return ret; + freqs.new = freqs.old; + goto post_notify; } /* scaling down? scale voltage after frequency */ @@ -111,13 +114,13 @@ static int cpu0_set_target(struct cpufreq_policy *policy, pr_err("failed to scale voltage down: %d\n", ret); clk_set_rate(cpu_clk, freqs.old * 1000); freqs.new = freqs.old; - return ret; } } +post_notify: cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); - return 0; + return ret; } static int cpu0_cpufreq_init(struct cpufreq_policy *policy) -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[PATCH] cpufreq: cpufreq-cpu0: No need to check cpu number in init()

by Viresh Kumar

It is not possible for init() to be called for any cpu other than cpu0. During bootup whatever cpu is used to boot system will be assigned as cpu0. And later on policy->cpu can only change if we hotunplug all cpus first and then hotplug them back in different order, which isn't possible (system requires atleast one cpu to be up always :)). Though I can see one situation where policy->cpu can be different then zero. - Hot-unplug cpu 0. - rmmod cpufreq-cpu0 module - insmod it back - hotplug cpu 0 again. Here, policy->cpu would be different. But the driver doesn't have any dependency on cpu0 as such. We don't mind which cpu of a system is policy->cpu and so this check is just not required. Remove it. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/cpufreq-cpu0.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index 0f16267..1cab820 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -124,9 +124,6 @@ static int cpu0_cpufreq_init(struct cpufreq_policy *policy) { int ret; - if (policy->cpu != 0) - return -EINVAL; - ret = cpufreq_frequency_table_cpuinfo(policy, freq_table); if (ret) { pr_err("invalid frequency table: %d\n", ret); -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[PATCH V4 0/4] Queue work on UNBOUND wq

by Viresh Kumar

This patchset was called: "Create sched_select_cpu() and use it for workqueues" for the first three versions. Earlier discussions over v3, v2 and v1 can be found here: https://lkml.org/lkml/2013/3/18/364 http://lists.linaro.org/pipermail/linaro-dev/2012-November/014344.html http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13342.html For power saving it is better to schedule work on cpus that aren't idle, as bringing a cpu/cluster from idle state can be very costly (both performance and power wise). Earlier we tried to use timer infrastructure to take this decision but we found out later that scheduler gives even better results and so we should use scheduler for choosing cpu for scheduling work. In workqueue subsystem workqueues with flag WQ_UNBOUND are the ones which uses cpu to select target cpu. Here we are migrating few users of workqueues to WQ_UNBOUND. These drivers are found to be very much active on idle or lightly busy system and using WQ_UNBOUND for these gave impressive results. Setup: ----- - ARM Vexpress TC2 - big.LITTLE CPU - Core 0-1: A15, 2-4: A7 - rootfs: linaro-ubuntu-devel This patchset has been tested on a big LITTLE system (heterogeneous) but is useful for all other homogeneous systems as well. During these tests audio was played in background using aplay. Results: ------- Cluster A15 Energy Cluster A7 Energy Total ------------------------- ----------------------- ------ Without this patchset (Energy in Joules): --------------------------------------------------- 0.151162 2.183545 2.334707 0.223730 2.687067 2.910797 0.289687 2.732702 3.022389 0.454198 2.745908 3.200106 0.495552 2.746465 3.242017 Average: 0.322866 2.619137 2.942003 With this patchset (Energy in Joules): ----------------------------------------------- 0.226421 2.283658 2.510079 0.151361 2.236656 2.388017 0.197726 2.249849 2.447575 0.221915 2.229446 2.451361 0.347098 2.257707 2.604805 Average: 0.2289042 2.2514632 2.4803674 Above tests are repeated multiple times and events are tracked using trace-cmd and analysed using kernelshark. And it was easily noticeable that idle time for many cpus has increased considerably, which eventually saved some power. PS: All the earlier Acks we got for drivers are reverted here as patches have been updated significantly. V3->V4: ------- - Dropped changes to kernel/sched directory and hence sched_select_non_idle_cpu(). - Dropped queue_work_on_any_cpu() - Created system_freezable_unbound_wq - Changed all patches accordingly. V2->V3: ------- - Dropped changes into core queue_work() API, rather create *_on_any_cpu() APIs - Dropped running timers migration patch as that was broken - Migrated few users of workqueues to use *_on_any_cpu() APIs. Viresh Kumar (4): workqueue: Add system wide system_freezable_unbound_wq PHYLIB: queue work on unbound wq block: queue work on unbound wq fbcon: queue work on unbound wq block/blk-core.c | 3 ++- block/blk-ioc.c | 2 +- block/genhd.c | 10 ++++++---- drivers/net/phy/phy.c | 9 +++++---- drivers/video/console/fbcon.c | 2 +- include/linux/workqueue.h | 4 ++++ kernel/workqueue.c | 7 ++++++- 7 files changed, 25 insertions(+), 12 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[PATCH V4 0/2] Implement per policy instance of governor

by Viresh Kumar

Hi Guys, All patches are pushed here for others to apply (you can apply from mail to): http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/h… Currently, there can't be multiple instances of single governor_type. If we have a multi-package system, where we have multiple instances of struct policy (per package), we can't have multiple instances of same governor. i.e. We can't have multiple instances of ondemand governor for multiple packages. Governors directory in sysfs is created at /sys/devices/system/cpu/cpufreq/ governor-name/. Which again reflects that there can be only one instance of a governor_type in the system. This is a bottleneck for multicluster system, where we want different packages to use same governor type, but with different tunables. This patchset is inclined towards fixing this issue. Now we will create governors directory in cpu/cpu*/cpufreq/<gov> for platforms which have multiple struct policy alive at any moment. Platform drivers requiring this feature must set have_governor_per_policy variable in their instance of cpufreq_driver. For others the interface is kept same: cpu/cpufreq/<gov>. This is V4 of this patchset. V3 is already applied by Rafael in his linux-next branch. Jacob Shin reported some regressions with this patchset and when I went into testing it with his configuration I found more issues then what he reported. To test these over linux-next you need to revert following first: db9baec cpufreq: Get rid of "struct global_attr" 86bd6f0 cpufreq: governor: Implement per policy instances of governors 8ae67b1 cpufreq: Add per policy governor-init/exit infrastructure I have tested this for following now and believe there are no more regressions with it: - platform with a single policy instance or single group of cpu - platform with multiple policies but which don't want per policy instance of governor - platform with multiple policies and which want per policy instance of governor I have tried with different settings and combinations of governors. @Rafael: To simplify your life I have sorted out your branch and you can simply pickup the complete branch that I have pushed. V3->V4: - We have two instances of all show/store routines for ondemand/conservative governor. One for per-policy instance of governor and other for one governor instance for all policies. - Dropped: db9baec cpufreq: Get rid of "struct global_attr". - Fixed cpufreq_governor_dbs for multiple policies using same governor instance. - Implemented few macro's in cpufreq_governor.h to make above stuff clean. - Renamed have_multiple_policies to have_governor_per_policy - Some more minor cleanups Viresh Kumar (2): cpufreq: Add per policy governor-init/exit infrastructure cpufreq: governor: Implement per policy instances of governors drivers/cpufreq/cpufreq.c | 36 ++++- drivers/cpufreq/cpufreq_conservative.c | 193 ++++++++++++++---------- drivers/cpufreq/cpufreq_governor.c | 212 +++++++++++++++++--------- drivers/cpufreq/cpufreq_governor.h | 117 +++++++++++++-- drivers/cpufreq/cpufreq_ondemand.c | 263 ++++++++++++++++++++------------- include/linux/cpufreq.h | 17 ++- 6 files changed, 562 insertions(+), 276 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[PATCH] cpufreq: Documentation: Fix cpufreq_frequency_table name

by Viresh Kumar

At few places in documentation cpufreq_frequency_table is written as cpufreq_freq_table. Fix these. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- Documentation/cpu-freq/cpu-drivers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index c94383f..a3585ea 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -185,10 +185,10 @@ the reference implementation in drivers/cpufreq/longrun.c As most cpufreq processors only allow for being set to a few specific frequencies, a "frequency table" with some functions might assist in some work of the processor driver. Such a "frequency table" consists -of an array of struct cpufreq_freq_table entries, with any value in +of an array of struct cpufreq_frequency_table entries, with any value in "index" you want to use, and the corresponding frequency in "frequency". At the end of the table, you need to add a -cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And +cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And if you want to skip one entry in the table, set the frequency to CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending order. -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[PATCH V3 0/7] Create sched_select_cpu() and use it for workqueues

by Viresh Kumar

In order to save power, it would be useful to schedule light weight work on cpus that aren't IDLE instead of waking up an IDLE one. By idle cpu (from scheduler's perspective) we mean: - Current task is idle task - nr_running == 0 - wake_list is empty This is already implemented for timers as get_nohz_timer_target(). We can figure out few more users of this feature, like workqueues. This patchset converts get_nohz_timer_target() into a generic API sched_select_cpu() so that other frameworks (like workqueue) can also use it. This routine returns the cpu which is non-idle. It accepts a bitwise OR of SD_* flags present in linux/sched.h. If the local CPU isn't idle OR all cpus are idle, local cpu is returned back. If local cpu is idle, then we must look for another CPU which have all the flags passed as argument as set and isn't idle. This patchset in first two patches creates generic API sched_select_cpu(). In the third patch we create a new set of APIs for workqueues to queue work on any cpu. All other patches migrate some of the users of workqueues which showed up significantly on my setup. Others can be migrated later. Earlier discussions over v1 and v2 can be found here: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg13342.html http://lists.linaro.org/pipermail/linaro-dev/2012-November/014344.html Earlier discussions over this concept were done at last LPC: http://summit.linuxplumbersconf.org/lpc-2012/meeting/90/lpc2012-sched-timer… Setup: ----- - ARM Vexpress TC2 - big.LITTLE CPU - Core 0-1: A15, 2-4: A7 - rootfs: linaro-ubuntu-devel This patchset has been tested on a big LITTLE system (heterogeneous) but is useful for all other homogeneous systems as well. During these tests audio was played in background using aplay. Results: ------- Cluster A15 Energy Cluster A7 Energy Total ------------------ ----------------- ----- Without this patchset (Energy in Joules): --------------------- 0.151162 2.183545 2.334707 0.223730 2.687067 2.910797 0.289687 2.732702 3.022389 0.454198 2.745908 3.200106 0.495552 2.746465 3.242017 Average: 0.322866 2.619137 2.942003 With this patchset (Energy in Joules): --------------------- 0.133361 2.267822 2.401183 0.260626 2.833389 3.094015 0.142365 2.277929 2.420294 0.246793 2.582550 2.829343 0.130462 2.257033 2.387495 Average: 0.182721 2.443745 2.626466 Above tests are repeated multiple times and events are tracked using trace-cmd and analysed using kernelshark. And it was easily noticeable that idle time for many cpus has increased considerably, which eventually saved some power. These patches are applied here for others to test: http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/h… Viresh Kumar (7): sched: Create sched_select_cpu() to give preferred CPU for power saving timer: hrtimer: Don't check idle_cpu() before calling get_nohz_timer_target() workqueue: Add helpers to schedule work on any cpu PHYLIB: queue work on any cpu mmc: queue work on any cpu block: queue work on any cpu fbcon: queue work on any cpu block/blk-core.c | 6 +- block/blk-ioc.c | 2 +- block/genhd.c | 9 ++- drivers/mmc/core/core.c | 2 +- drivers/net/phy/phy.c | 9 +-- drivers/video/console/fbcon.c | 2 +- include/linux/sched.h | 21 +++++- include/linux/workqueue.h | 5 ++ kernel/hrtimer.c | 2 +- kernel/sched/core.c | 63 +++++++++------- kernel/timer.c | 2 +- kernel/workqueue.c | 163 +++++++++++++++++++++++++++++------------- 12 files changed, 192 insertions(+), 94 deletions(-) -- 1.7.12.rc2.18.g61b472e

12 years, 3 months

[ACTIVITY] (John Stultz) March 25-29

by John Stultz

=== Highlights === * Sent out ntp locking change patches to lkml, didn't get any objections * Opened bug to track alarmdev unit test failures * Reviewed blueprints and had biweekly android upstreaming subteam hangout. * Provided DmitryP with instructions for submitting kernel changes to AOSP (he created a wiki with them - http://wiki.linaro.org/Process/PushingBitsToAndroid ) * Sent in expense reports for Linaro Connect. * Had some discussions with Jesse Barker and Serban about ION (both upstreaming and build issues for non-arm). * Had some discussions on the list about the future of drivers/clocksource maintenance * Worked with Appala (who was working very late nights) on some issues on the binder testing. * Sent Dmitry's sync compat_ioctl fixes to lkml/gregkh. Are queued for 3.10 * Sent tglx git pull request with my timekeeping changes for 3.10 * Sent Minchan my current work on making his volatile range patches more generic === Plans === * Focus on volatile range work in prep for lsf-mm * Still need to work on earlysuspend blog post * If tglx agrees, push timekeeping lock hold reductions to him. === Issues === * Caught a cold, so I've been a bit slow and foggy this week.

12 years, 3 months

Re: [Bug 55411] sysfs per-cpu cpufreq subdirs/symlinks screwed up after s2ram

by Viresh Kumar

Hi Guys, We are talking here about a bug reported by Duncan here. His cpu/cpu*/cpufreq directory are getting corrupted with 3.9-rc3 and was working well with 3.8 https://bugzilla.kernel.org/show_bug.cgi?id=55411 On his AMD bulldozer tri-cluster/6-core system he doesn't see affected and related cpus set correctly after off-lining 1-5 and bringing them back with: for i in 1 2 3 4 5; do echo 0 > /sys/devices/system/cpu/cpu$i/online ; done for i in 1 2 3 4 5; do echo 1 > /sys/devices/system/cpu/cpu$i/online ; done Before running above two, cpufreq-info gave: https://bugzilla.kernel.org/attachment.cgi?id=95701 And after running above it gave: https://bugzilla.kernel.org/attachment.cgi?id=95711 Clearly it got corrupted. Somehow cpu 3 showed up in related cpus field of cpu 5. I suspect following patches behind this: commit fcf8058296edbc3de43adf095824fc32b067b9f8 Author: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Tue Jan 29 14:39:08 2013 +0000 cpufreq: Simplify cpufreq_add_dev() Currently cpufreq_add_dev() firsts allocates policy, calls driver->init() and then checks if this CPU is already managed or not. And if it is already managed, its policy is freed. We can save all this if we somehow know that CPU is managed or not in advance. policy->related_cpus contains the list of all valid sibling CPUs of policy->cpu. We can check this to see if the current CPU is already managed. 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 a 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, though, as we don't override anything. [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Tested-by: Shawn Guo <shawn.guo(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> AND commit 643ae6e81dd65b333a13259852405fc9f764ac76 Author: Viresh Kumar <viresh.kumar(a)linaro.org> Date: Sat Jan 12 05:14:38 2013 +0000 cpufreq: Manage only online cpus cpufreq core doesn't manage offline cpus and if driver->init() has returned mask including offline cpus, it may result in unwanted behavior by cpufreq core or governors. We need to get only online cpus in this mask. There are two places to fix this mask, cpufreq core and cpufreq driver. It makes sense to do this at common place and hence is done in core. Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> And this is the latest piece of documentation available: SMP systems normally have same clock source for a group of cpus. For these the .init() would be called only once for the first online cpu. Here the .init() routine must initialize policy->cpus with mask of all possible cpus (Online + Offline) that share the clock. Then the core would copy this mask onto policy->related_cpus and will reset policy->cpus to carry only online cpus. I saw acpi-cpufreq drivers driver->init() code and found it is not yet aligned to this theory and probably that is causing these failures. I don't have enough knowledge about this driver and how is it used for all x86 systems and so want somebody else (who has some prior experience with it) to check how policy->cpus and policy->related_cpus must be set from driver->init(). -- viresh ---------- Forwarded message ---------- From: <bugzilla-daemon(a)bugzilla.kernel.org> Date: 19 March 2013 13:19 Subject: [Bug 55411] sysfs per-cpu cpufreq subdirs/symlinks screwed up after s2ram To: viresh.kumar(a)linaro.org https://bugzilla.kernel.org/show_bug.cgi?id=55411 --- Comment #9 from Duncan <1i5t5.duncan(a)cox.net> 2013-03-19 07:49:53 --- (In reply to comment #8) > (In reply to comment #0) >> After a s2ram/resume cycle (now bad): >> >> /sys/devices/system/cpu/cpu0/cpufreq/ >> /sys/devices/system/cpu/cpu1/cpufreq -> ../cpu0/cpufreq/ >> /sys/devices/system/cpu/cpu3/cpufreq/ >> /sys/devices/system/cpu/cpu5/cpufreq/ > > Can you try this rather than s2r: > > for i in 1 2 3 4 5; do echo 0 > /sys/devices/system/cpu/cpu$i/online ; done > for i in 1 2 3 4 5; do echo 1 > /sys/devices/system/cpu/cpu$i/online ; done > > and check the status if things are still corrupted for you? > Above doesn't corrupt anything for me Atleast. That's a nice easy test; no rebuild and reboot needed. =:^) Tho I had to change the > to >| as I have bash noclobber set and the files obviously already exist... Uncorrupted before the test, corrupted after. So just cycling the cpus off and then back online *DOES* corrupt cpufreq, thus a much simpler reproducer! =:^) Exact same ls results as the above. > And my system doesn't have S2R support for now. My old system didn't support s2ram reliably; it would work occasionally but mostly it didn't. But s2disk was workable for awhile, until the fact that I was running mdraid and the disks didn't always return in the same sdX slots due to hardware wakeup issues complicated things, so eventually I didn't use that much either. The new system's great with s2ram, sans this bug of course; s2disk didn't work at all at first, but last time I tried it /almost/ worked so there has been improvement. But I don't like to take unnecessary chances with filesystem log replay and thankfully wall power's good enough around here that I can s2ram for a day and come back and wiggle the mouse and all's fine (with a couple pre-suspend syncs thrown into my script just in case), so I tend to use it a LOT, even more than I'd use s2disk due to the speed. =:^) But I'd love to have s2both working reliably; for all I know it's actually working now; it was pretty close. But I prefer not to test the reiserfs log replay (even with pre-suspend syncs I worry, tho as I said reiserfs has actually been very good to me even thru faulty ram, a power supply blowing up on me, a mobo dying, etc, since 2.6.16 or whenever it was that it got ordered journaling by default) when it doesn't work, so knowing s2disk didn't work well when I tested it and with s2ram working SO well, I don't tend to test s2disk/s2both too often. Meanwhile, thanks for the cpuinfo_cur_freq explanation. If that actually real-time touches the hardware to get the data as you say, that does explain the root privs. Maybe that bit of extra info could be added to the documentation? I could propose some new wording and open a new bug on cpu-freq/user-guide.txt for it if appropriate. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

12 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel