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

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55411





--- Comment #22 from Thomas Renninger <trenn@suse.de>  2013-03-22 14:04:09 ---
On Friday, March 22, 2013 07:13:33 PM Viresh Kumar wrote:
> Hi guys,
> 
> I will answer to questions of both of you in this mail.
> 
> On 22 March 2013 18:23, Thomas Renninger <trenn@suse.de> wrote:
> > Is this all to try to fix "cpufreq driver gets loaded while some cores
> > were set offline before"?
> 
> Not really. There are problems with acpi-cpufreq without that case too.
> 
> > I wonder how you run into "cpufreq is initialized with offlined cpus"
> > case.
> > I remember that there were problems, but it's nearly impossible to run
> > into this if the cpufreq driver is loaded early at boot.
> 
> I always thought there is a way not to boot all cpus by passing stuff in
> command line and so this is a easy case to reproduce.
I am pretty sure cpuidle states won't initialize and in best case you never
get them working on the offlined cpus.
Local APICs won't be set up, ...

Such a parameter will never exist for x86.

> > cpufreq_add_dev() and friends are complicated.
> 
> Not anymore, they are hugely simplified now.
They were hugely simplified and things are not working anymore and you
do not know why...

> > Those init functions got split some time ago and there also slipped
> > in a bug even it was simple splitting of functions.
> > 
> > I do not have time to look at fcf8058296edbc3de43adf095824fc32b067b9f8
> > right now. Don't know how much other stuff depends on it and how
> > sever it is on ARM that cpufreq does not correctly initialize with
> > offlined
> > cpus..., I would revert this patch.
> 
> Let me clear it to everybody. There isn't/shouldn't be a bug in cpufreq
> core, its just that acpi-cpufreq driver isn't adapted well with the changes
> related to affected_cpus and related_cpus.
And powernow-k8 driver is broken.
The others are not tested that often, I expect they broke as well, right?

> I have never gone into coding for any non-ARM platform and am really not
> aware of acpi-cpufreq driver and its users. That's why i told everybody
> where the issue is, and they just need to fix acpi-cpufreq driver with
> right values of policy->cpus (affected_cpus) and everything else would work
> after that.

Sorry, I cannot look into this due to lack of time, but I remember that
there were reasons why cpufreq_add_dev() was complicated.
Or that it's really easy to mess it up and it's not easy to fix it again.

     Thomas

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.