lkml.org 
[lkml]   [2013]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/8] Cpufreq, cpu hotplug, suspend/resume related fixes
On 07/13/2013 07:20 PM, Toralf Förster wrote:
> On 07/13/2013 11:23 AM, Toralf Förster wrote:
>> On 07/12/2013 12:15 AM, Srivatsa S. Bhat wrote:
>>> And I'd of course appreciate to hear from Dirk, Tianyu and Toralf to know
>>> whether their systems work fine after:
>>> a. applying only the first commit (this is what gets backported to stable)
>>
>> applied on top of straight 3.10 .0 : Breaks my system completely -
>
> overlooked, that the 8 patches are 3.11/3.12 material - but nevertheless :
>

Let me clarify where to apply these patches:

Assuming that you are using mainline (not -stable) for your testing, this is how
it goes:

For mainline v3.10 (final release, commit 8bb495e3f):

You need to apply 2 patches, in the order mentioned below:
1. Commit f51e1eb63d (cpufreq: Fix cpufreq regression after suspend/resume)
2. Patch 1/8 in this patchset. https://lkml.org/lkml/2013/7/11/661

Those 2 together, should be able to fix all the cpufreq regression you
originally saw with commit a66b2e (cpufreq: Preserve sysfs files across
suspend/resume).

------

Now, coming to current mainline, ie., 3.10+ (after 3.10, in-between the merge
window), you need to test two different things:

Scenario 1:
Apply only patch 1/8 in this patchset. https://lkml.org/lkml/2013/7/11/661
Check if cpufreq behaves fine after suspend/resume.

Scenario 2:
Apply all the 8 patches in this patchset, and check if cpufreq still
works fine after suspend/resume.


Important note:
--------------

This patchset and any of the patches/commits I mentioned above *do* *not* try
to fix any core suspend/resume regression. They only try to fix the *cpufreq*
regression related to suspend/resume, which commit a66b2e (cpufreq: Preserve
sysfs files across suspend/resume) had caused.

In other words, if basic suspend/resume itself is not working even before you
apply any of the patches mentioned above, then something *else* is totally
broken, and we need to address that separately.


> Applied 1/8 on top of v3.10-9289-g9903883 brought same bad picture as
> described for 3.10.0
>
> And applying patches 1-8 on top of that commit id just gives the same
> pciture - systems hangs during s2ram completly
>

Please verify whether suspend/resume works fine before applying any of the
patches. That's an important baseline. This patchset tries to fix only the
cpufreq regression, and not all the suspend/resume related problems (which
might have creeped in during the merge window).

>
>> trying s2ram just blanks the console, lets the power led blinking,
>> neither sys-rq nor anything else worked now, no output to console nor to
>> syslog
>>
>>> b. applying all the commits
>> patch 2#8 doesn't apply at 3.10.0 (neither after patch 1#8 nor directly)
>
> I attached the .config I'm using for my tests
> (/me wonders if it is worth to notice, that it is a 32bit system booted
> from an external USB drive ?)
>


Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-07-15 09:21    [W:0.057 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site