On 25 April 2013 08:16, Tang Yuantian-B29983 B29983@freescale.com wrote:
It happened when policy->cpus contains *MORE THEN ONE CPU*. Taking my board T4240 for example, it has 3 cluster, 8 CPUs for each cluster. The log is: # insmod ppc-corenet-cpufreq.ko ppc_corenet_cpufreq: Freescale PowerPC corenet CPU frequency scaling driver # rmmod ppc-corenet-cpufreq.ko ERROR: Module ppc_corenet_cpufreq is in use # lsmod Module Size Used by ppc_corenet_cpufreq 6542 9 # uname -a Linux T4240 3.9.0-rc1-11081-g34642bb-dirty #44 SMP Thu Apr 25 08:58:26 CST 2013 ppc64 unknown
I am not using the newest kernel (since new t4240 board has not included yet), but the issue is still there. The reason is just like what I said in patch.
I believed what you said is correct and went on testing this on my platform. 2 clusters with 2 and 3 cpus... And so i have multiple cpus per cluster or policy structure.
insmod/rmmod worked as expected without any issues.
So, for me there are no such issues. BTW, i tested this on latest rc from Linus and also on latest code from linux-next.
I am sure the counts are very well balanced and there are no issues in the latest code Atleast.
That's wired. I will have more tests on this. Thanks.
I found another bug you can try. It is also found on multiple cpus per cluster. Test step: 1. compile the driver as module. 2. hot-unplug one cpu( any one is OK) 3. insmod module 4. hot-plug the cpu ----> will cause error.
Or test step also can be: 1. hot-unplug all the cpus in one cluster 2. hot-plug the cpus in this cluster. When the second cpu gets hot-pluged, error will occur.
That's because the second cpu will call the cpufreq_add_dev_symlink() to Create the first cpu's "cpufreq link" which is already created. That needs more work to make a patch, hope you can fix it.
Thanks, Yuantian
-----Original Message----- From: cpufreq-owner@vger.kernel.org [mailto:cpufreq-owner@vger.kernel.org] On Behalf Of Viresh Kumar Sent: 2013年4月25日 15:47 To: Tang Yuantian-B29983 Cc: rjw@sisk.pl; cpufreq@vger.kernel.org; linux-pm@vger.kernel.org; Lists linaro-kernel Subject: Re: [PATCH] cpufreq: Fix the driver can not be unloaded issue
On 25 April 2013 08:16, Tang Yuantian-B29983 B29983@freescale.com wrote:
It happened when policy->cpus contains *MORE THEN ONE CPU*. Taking my board T4240 for example, it has 3 cluster, 8 CPUs for each
cluster.
The log is: # insmod ppc-corenet-cpufreq.ko ppc_corenet_cpufreq: Freescale PowerPC corenet CPU frequency scaling driver # rmmod ppc-corenet-cpufreq.ko ERROR: Module ppc_corenet_cpufreq is in use # lsmod Module Size Used by ppc_corenet_cpufreq 6542 9 # uname -a Linux T4240 3.9.0-rc1-11081-g34642bb-dirty #44 SMP Thu Apr 25 08:58:26 CST 2013 ppc64 unknown
I am not using the newest kernel (since new t4240 board has not included yet), but the issue is still there. The reason is just like what I said in patch.
I believed what you said is correct and went on testing this on my platform. 2 clusters with 2 and 3 cpus... And so i have multiple cpus per cluster or policy structure.
insmod/rmmod worked as expected without any issues.
So, for me there are no such issues. BTW, i tested this on latest rc from Linus and also on latest code from linux-next.
I am sure the counts are very well balanced and there are no issues in the latest code Atleast. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 25 April 2013 16:08, Tang Yuantian-B29983 B29983@freescale.com wrote:
That's wired. I will have more tests on this. Thanks.
I found another bug you can try. It is also found on multiple cpus per cluster. Test step:
- compile the driver as module.
- hot-unplug one cpu( any one is OK)
- insmod module
- hot-plug the cpu ----> will cause error.
Or test step also can be:
- hot-unplug all the cpus in one cluster
- hot-plug the cpus in this cluster. When the second cpu gets hot-pluged, error will occur.
That's because the second cpu will call the cpufreq_add_dev_symlink() to Create the first cpu's "cpufreq link" which is already created. That needs more work to make a patch, hope you can fix it.
Haven't tested it now but i know why that can happen. It will happen only if driver->init() isn't setting policy->cpus correctly. You need to set both online & offline cpus, but in your setup it looks you are setting only online cpus and so cpufreq core isn't able to use the earlier policy struct for offline cpus.
And so it created a new struct cpufreq_policy for second cpu and trying to add links for all other cpus too... (which share this policy)..
-----Original Message----- From: cpufreq-owner@vger.kernel.org [mailto:cpufreq-owner@vger.kernel.org] On Behalf Of Viresh Kumar Sent: 2013年4月25日 19:27 To: Tang Yuantian-B29983 Cc: rjw@sisk.pl; cpufreq@vger.kernel.org; linux-pm@vger.kernel.org; Lists linaro-kernel Subject: Re: [PATCH] cpufreq: Fix the driver can not be unloaded issue
On 25 April 2013 16:08, Tang Yuantian-B29983 B29983@freescale.com wrote:
That's wired. I will have more tests on this. Thanks.
I found another bug you can try. It is also found on multiple cpus per cluster. Test step:
- compile the driver as module.
- hot-unplug one cpu( any one is OK)
- insmod module
- hot-plug the cpu ----> will cause error.
Or test step also can be:
- hot-unplug all the cpus in one cluster 2. hot-plug the cpus in this
cluster. When the second cpu gets hot-pluged, error will occur.
That's because the second cpu will call the cpufreq_add_dev_symlink() to Create the first cpu's "cpufreq link" which is already created. That needs more work to make a patch, hope you can fix it.
Haven't tested it now but i know why that can happen. It will happen only if driver->init() isn't setting policy->cpus correctly. You need to set both online & offline cpus, but in your setup it looks you are setting only online cpus and so cpufreq core isn't able to use the earlier policy struct for offline cpus.
And so it created a new struct cpufreq_policy for second cpu and trying to add links for all other cpus too... (which share this policy)..
Exactly. Currently, we don't consider the offline cpus when setting policy->cpus. Probably other platforms do the same thing.
Thanks, Yuantian
-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 April 2013 07:09, Tang Yuantian-B29983 B29983@freescale.com wrote:
Exactly. Currently, we don't consider the offline cpus when setting policy->cpus. Probably other platforms do the same thing.
But this is a requirement of cpufreq framework and drivers must adapt to it. Let me know which drivers don't meet this requirement and i will get them fixed.
-----Original Message----- From: cpufreq-owner@vger.kernel.org [mailto:cpufreq-owner@vger.kernel.org] On Behalf Of Viresh Kumar Sent: 2013年4月26日 12:41 To: Tang Yuantian-B29983 Cc: rjw@sisk.pl; cpufreq@vger.kernel.org; linux-pm@vger.kernel.org; Lists linaro-kernel Subject: Re: [PATCH] cpufreq: Fix the driver can not be unloaded issue
On 26 April 2013 07:09, Tang Yuantian-B29983 B29983@freescale.com wrote:
Exactly. Currently, we don't consider the offline cpus when setting policy->cpus. Probably other platforms do the same thing.
But this is a requirement of cpufreq framework and drivers must adapt to it. Let me know which drivers don't meet this requirement and i will get them fixed.
OK, I will take care of this in my driver. I have no idea about other drivers.
Regards, Yuantian
-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linaro-kernel@lists.linaro.org
-
Tang Yuantian-B29983 -
Viresh Kumar