On 2015/3/9 12:06, Viresh Kumar wrote:
On 9 March 2015 at 07:04, Ethan Zhao wrote:
Viresh,
Got that box and did some debug, found the policy->kobj is not initialized.
So the race happened between cpufreq_cpu_get() and
__cpufreq_add_dev(), and verified 'this' race could be fixed by commit
On 9 March 2015 at 07:04, Ethan Zhao wrote:
> Viresh,
> Got that box and did some debug, found the policy->kobj is not
> initialized.
> So the race happened between cpufreq_cpu_get() and
> __cpufreq_add_dev(), and verified 'this' race could be fixed by commit
>
> 6d4e81e cpufreq: Ref the poli
Viresh,
Got that box and did some debug, found the policy->kobj is not initialized.
So the race happened between cpufreq_cpu_get() and
__cpufreq_add_dev(), and verified 'this' race could be fixed by commit
6d4e81e cpufreq: Ref the policy object sooner
I have reboot the box with crond for
On 2/24/2015 9:47 PM, Ethan Zhao wrote:
Viresh,
Will do that when I get the test box.
Thanks Ethan.
On Wed, Feb 25, 2015 at 12:35 PM, viresh kumar wrote:
On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote:
Viresh,
With this patch applied, still got the following warning and
Viresh,
Will do that when I get the test box.
Thanks,
Ethan
On Wed, Feb 25, 2015 at 12:35 PM, viresh kumar wrote:
> On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote:
>> Viresh,
>> With this patch applied, still got the following warning and panic,
>> seems it needs more care.
>>
>
On Wednesday 25 February 2015 08:54 AM, Ethan Zhao wrote:
> Viresh,
> With this patch applied, still got the following warning and panic,
> seems it needs more care.
>
> 54.474618] [ cut here ]
> [ 54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47
> ko
Viresh,
With this patch applied, still got the following warning and panic,
seems it needs more care.
54.474618] [ cut here ]
[ 54.545816] WARNING: CPU: 0 PID: 213 at include/linux/kref.h:47
kobject_get+0x41/0x50()
[ 54.642595] Modules linked in: i2c_i801(+) mfd_
On 2015/2/2 12:54, Viresh Kumar wrote:
On 2 February 2015 at 10:15, ethan zhao wrote:
On 2015/2/2 12:26, Viresh Kumar wrote:
But there is no checking against refcount in or before
cpufreq_policy_free(), that is one issue I mentioned.
As I said earlier, the completion will only fire once
On 2 February 2015 at 10:15, ethan zhao wrote:
> On 2015/2/2 12:26, Viresh Kumar wrote:
> But there is no checking against refcount in or before
>
> cpufreq_policy_free(), that is one issue I mentioned.
As I said earlier, the completion will only fire once the refcount
is zero. And so there is
On 2015/2/2 12:26, Viresh Kumar wrote:
On 2 February 2015 at 09:46, ethan zhao wrote:
We am talking about the policy allocation and de-allocation. right ?
I showed you the cpufreq_policy_free(policy) doesn't check kobject
refcount as above.
Hmmm, you are still sleeping in the kobject
On 2 February 2015 at 09:46, ethan zhao wrote:
> We am talking about the policy allocation and de-allocation. right ?
> I showed you the cpufreq_policy_free(policy) doesn't check kobject
> refcount as above.
>
> Hmmm, you are still sleeping in the kobject, wake up and don't mix
> water anymo
On 2015/2/2 12:09, Viresh Kumar wrote:
On 2 February 2015 at 09:36, ethan zhao wrote:
Is that an idea it supposed to be or fact ?
if (!cpufreq_suspended)
cpufreq_policy_free(policy);
static void cpufreq_policy_free(struct cpufreq_policy *policy)
{
free_cpumask_var(polic
On 2 February 2015 at 09:36, ethan zhao wrote:
> Is that an idea it supposed to be or fact ?
>
> if (!cpufreq_suspended)
> cpufreq_policy_free(policy);
>
> static void cpufreq_policy_free(struct cpufreq_policy *policy)
> {
> free_cpumask_var(policy->related_cpus);
> free_cpum
On 2015/2/2 11:59, Viresh Kumar wrote:
On 2 February 2015 at 09:26, ethan zhao wrote:
How to prevent the policy to be freed between
cpufreq_cpu_get() and cpufreq_cpu_put() ?
kobject_get() increases the reference count of a policy and the policy
will only be freed when this is zero. And i
On 2 February 2015 at 09:26, ethan zhao wrote:
> How to prevent the policy to be freed between
>
> cpufreq_cpu_get() and cpufreq_cpu_put() ?
kobject_get() increases the reference count of a policy and the policy
will only be freed when this is zero. And it will only be zero once all
cpufreq_cpu
On 2015/2/2 11:43, Viresh Kumar wrote:
On 2 February 2015 at 09:08, ethan zhao wrote:
We take cpufreq_driver_lock() here, and so this will
block thread B.
No, there is no cpufreq_driver_lock acquired between
cpufreq_cpu_get() and cpufreq_cpu_put()
I am not saying that the lock is take
On 2 February 2015 at 09:08, ethan zhao wrote:
>> We take cpufreq_driver_lock() here, and so this will
>> block thread B.
>
> No, there is no cpufreq_driver_lock acquired between
>
> cpufreq_cpu_get() and cpufreq_cpu_put()
I am not saying that the lock is taken between them. But within
cpufre
On 2015/2/2 11:24, Viresh Kumar wrote:
On 2 February 2015 at 08:50, ethan zhao wrote:
This seems couldn't prevent all the 'bad thing' from happening, E.G.
Thread A: Workqueue: kacpi_notify
acpi_processor_notify()
acpi_processor_ppc_has_changed()
cpufreq_update_policy()
18 matches
Mail list logo
