Re: System will not suspend with highest numbered CPU offline [REGRESSION][BISECTED]

[Viresh Kumar <viresh.kumar@linaro.org>]

On 05-09-15, 00:46, Doug Smythies wrote:
> > It is not clear to me why that echo line (there is only one)
> > would fail.

To me it is clear now :)

> The echo line fails because the related CPU is offline.
> If the failed echo is the last pass through the loop,
> then the script interprets the overall execution of
> 94cpufreq as a failure and aborts the suspend. If the
> failed echo is not the last pass through the loop, then
> the bad exit code gets overwritten with a good one before
> the loop exits.
> 
> Since the loop is merely setting a temporary governor,
> to test I just used performance mode anyway, and commented
> out the echo. pm-suspend with CPU 7 offline then worked fine.
> 
> I have not yet gone back to any before the patch kernel
> to determine why it used to work (it is late in my time zone).
> However, I would have to assume that before the commit in
> question, the echo worked even if the CPU was offline.

So here is the story behind it.
- In your system all CPUs are independent, that is there are no links
  to cpufreq directory, so that check in the script is useless for
  you.
- The $COMMIT in question did a significant change. Earlier, while
  offlining the CPU, we used to remove the cpufreq directory from
  sysfs, which is not the case any more.

- So to be precise, following lines came to your rescue earlier:

# if we do not have a scaling_governor file, skip.
# [ -f "$gov" ] || continue

- But they don't after the patch, as the file and directory are
  present even if the CPU is offline.
- But because the CPU is offline, writing to those files isn't allowed
  and so the echo failed.

Solution to that is that we check for CPU offline as well in the
beginning of the script, and skip if the CPU is offline.

-- 
viresh