* patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
@ 2015-10-09 16:48 Dario Faggioli
2015-10-09 20:00 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 9+ messages in thread
From: Dario Faggioli @ 2015-10-09 16:48 UTC (permalink / raw)
To: xen-devel@lists.xenproject.org; +Cc: Wei Wang, Jan Beulich
[-- Attachment #1.1: Type: text/plain, Size: 3872 bytes --]
Hey,
As far as my bisection goes, commit
49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
driver register function" prevents me from hot unplugging pCPUs.
Xen does not crash or anything, but dom0 is stalled. In fact, with
current staging, here's what I see:
root@Zhaman:~# echo 0 > /sys/devices/system/xen_cpu/xen_cpu6/online
[ 81.583001] INFO: rcu_sched detected stalls on CPUs/tasks: { 12} (detected by 3, t=5252 jiffies, g=1691, c=1690, q=76)
[ 81.583036] Task dump for CPU 12:
[ 81.583044] bash R running task 0 1347 1094 0x00000008
[ 81.583056] ffffffff00000000 0000000000000000 0000000000000000 ffff8800192c2e38
[ 81.583070] ffff8800008472e8 0000000000000002 ffff8800008472e8 ffff880013817858
[ 81.583082] 0000000000000000 00000000000081a4 ffffffff811e8137 ffff8800192c2e38
[ 81.583095] Call Trace:
[ 81.583110] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
[ 81.583148] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
[ 81.583158] [<ffffffff811e2866>] ? dput+0x26/0x230
[ 81.583167] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
[ 81.583176] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
[ 81.583188] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
[ 81.583199] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
[ 81.583210] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
[ 81.583220] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
[ 81.583230] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
[ 81.583241] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
[ 81.583250] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
[ 81.583259] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
[ 81.583268] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
[ 81.583277] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
[ 81.583287] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
[ 144.555020] INFO: rcu_sched detected stalls on CPUs/tasks: { 12} (detected by 4, t=21007 jiffies, g=1691, c=1690, q=244)
[ 144.555046] Task dump for CPU 12:
[ 144.555051] bash R running task 0 1347 1094 0x00000008
[ 144.555059] ffffffff00000000 0000000000000000 0000000000000000 ffff8800192c2e38
[ 144.555068] ffff8800008472e8 0000000000000002 ffff8800008472e8 ffff880013817858
[ 144.555076] 0000000000000000 00000000000081a4 ffffffff811e8137 ffff8800192c2e38
[ 144.555084] Call Trace:
[ 144.555096] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
[ 144.555105] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
[ 144.555112] [<ffffffff811e2866>] ? dput+0x26/0x230
[ 144.555118] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
[ 144.555124] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
[ 144.555164] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
[ 144.555172] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
[ 144.555179] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
[ 144.555186] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
[ 144.555192] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
[ 144.555200] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
[ 144.555206] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
[ 144.555212] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
[ 144.555217] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
[ 144.555223] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
[ 144.555230] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
If I revert that patch, the issue goes away.
Any ideas?
Regards,
Dario
PS. yes, I'll implement a cpu hotplug/unplug testcase ASAP. :-)
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-09 16:48 patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug Dario Faggioli
@ 2015-10-09 20:00 ` Konrad Rzeszutek Wilk
2015-10-10 1:38 ` Wang, Wei W
2015-10-12 13:19 ` Jan Beulich
0 siblings, 2 replies; 9+ messages in thread
From: Konrad Rzeszutek Wilk @ 2015-10-09 20:00 UTC (permalink / raw)
To: Dario Faggioli; +Cc: xen-devel@lists.xenproject.org, Wei Wang, Jan Beulich
On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
> Hey,
>
> As far as my bisection goes, commit
> 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
> driver register function" prevents me from hot unplugging pCPUs.
>
> Xen does not crash or anything, but dom0 is stalled. In fact, with
> current staging, here's what I see:
>
> root@Zhaman:~# echo 0 > /sys/devices/system/xen_cpu/xen_cpu6/online
> [ 81.583001] INFO: rcu_sched detected stalls on CPUs/tasks: { 12} (detected by 3, t=5252 jiffies, g=1691, c=1690, q=76)
> [ 81.583036] Task dump for CPU 12:
> [ 81.583044] bash R running task 0 1347 1094 0x00000008
> [ 81.583056] ffffffff00000000 0000000000000000 0000000000000000 ffff8800192c2e38
> [ 81.583070] ffff8800008472e8 0000000000000002 ffff8800008472e8 ffff880013817858
> [ 81.583082] 0000000000000000 00000000000081a4 ffffffff811e8137 ffff8800192c2e38
> [ 81.583095] Call Trace:
> [ 81.583110] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
> [ 81.583148] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
> [ 81.583158] [<ffffffff811e2866>] ? dput+0x26/0x230
> [ 81.583167] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
> [ 81.583176] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
> [ 81.583188] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
> [ 81.583199] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
> [ 81.583210] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
> [ 81.583220] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
> [ 81.583230] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
> [ 81.583241] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
> [ 81.583250] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
> [ 81.583259] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
> [ 81.583268] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
> [ 81.583277] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
> [ 81.583287] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
> [ 144.555020] INFO: rcu_sched detected stalls on CPUs/tasks: { 12} (detected by 4, t=21007 jiffies, g=1691, c=1690, q=244)
> [ 144.555046] Task dump for CPU 12:
> [ 144.555051] bash R running task 0 1347 1094 0x00000008
> [ 144.555059] ffffffff00000000 0000000000000000 0000000000000000 ffff8800192c2e38
> [ 144.555068] ffff8800008472e8 0000000000000002 ffff8800008472e8 ffff880013817858
> [ 144.555076] 0000000000000000 00000000000081a4 ffffffff811e8137 ffff8800192c2e38
> [ 144.555084] Call Trace:
> [ 144.555096] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
> [ 144.555105] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
> [ 144.555112] [<ffffffff811e2866>] ? dput+0x26/0x230
> [ 144.555118] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
> [ 144.555124] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
> [ 144.555164] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
> [ 144.555172] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
> [ 144.555179] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
> [ 144.555186] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
> [ 144.555192] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
> [ 144.555200] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
> [ 144.555206] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
> [ 144.555212] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
> [ 144.555217] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
> [ 144.555223] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
> [ 144.555230] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
>
> If I revert that patch, the issue goes away.
>
> Any ideas?
I think it is due to xen-acpi-processor re-uploading the C and P states
whenever an CPU goes up. It also does this after S3 suspend.
Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
'__init' If you remove that little thing would it work?
>
> Regards,
> Dario
>
> PS. yes, I'll implement a cpu hotplug/unplug testcase ASAP. :-)
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-09 20:00 ` Konrad Rzeszutek Wilk
@ 2015-10-10 1:38 ` Wang, Wei W
2015-10-12 13:22 ` Jan Beulich
2015-10-12 13:19 ` Jan Beulich
1 sibling, 1 reply; 9+ messages in thread
From: Wang, Wei W @ 2015-10-10 1:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Dario Faggioli
Cc: xen-devel@lists.xenproject.org, Jan Beulich
On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
> > Hey,
> >
> > As far as my bisection goes, commit
> > 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
> > driver register function" prevents me from hot unplugging pCPUs.
> >
> > Xen does not crash or anything, but dom0 is stalled. In fact, with
> > current staging, here's what I see:
> >
> > root@Zhaman:~# echo 0 > /sys/devices/system/xen_cpu/xen_cpu6/online
> > [ 81.583001] INFO: rcu_sched detected stalls on CPUs/tasks: { 12} (detected
> by 3, t=5252 jiffies, g=1691, c=1690, q=76)
> > [ 81.583036] Task dump for CPU 12:
> > [ 81.583044] bash R running task 0 1347 1094 0x00000008
> > [ 81.583056] ffffffff00000000 0000000000000000 0000000000000000
> ffff8800192c2e38
> > [ 81.583070] ffff8800008472e8 0000000000000002 ffff8800008472e8
> ffff880013817858
> > [ 81.583082] 0000000000000000 00000000000081a4 ffffffff811e8137
> ffff8800192c2e38
> > [ 81.583095] Call Trace:
> > [ 81.583110] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
> > [ 81.583148] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
> > [ 81.583158] [<ffffffff811e2866>] ? dput+0x26/0x230
> > [ 81.583167] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
> > [ 81.583176] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
> > [ 81.583188] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
> > [ 81.583199] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
> > [ 81.583210] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
> > [ 81.583220] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
> > [ 81.583230] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
> > [ 81.583241] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
> > [ 81.583250] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
> > [ 81.583259] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
> > [ 81.583268] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
> > [ 81.583277] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
> > [ 81.583287] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
> > [ 144.555020] INFO: rcu_sched detected stalls on CPUs/tasks: { 12}
> > (detected by 4, t=21007 jiffies, g=1691, c=1690, q=244) [ 144.555046] Task
> dump for CPU 12:
> > [ 144.555051] bash R running task 0 1347 1094 0x00000008
> > [ 144.555059] ffffffff00000000 0000000000000000 0000000000000000
> > ffff8800192c2e38 [ 144.555068] ffff8800008472e8 0000000000000002
> > ffff8800008472e8 ffff880013817858 [ 144.555076] 0000000000000000
> > 00000000000081a4 ffffffff811e8137 ffff8800192c2e38 [ 144.555084] Call
> Trace:
> > [ 144.555096] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390 [
> > 144.555105] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90 [
> > 144.555112] [<ffffffff811e2866>] ? dput+0x26/0x230 [ 144.555118]
> > [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40 [ 144.555124]
> > [<ffffffff811d92b1>] ? do_last+0x621/0x12c0 [ 144.555164]
> > [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70 [ 144.555172]
> > [<ffffffff8156c64d>] ? store_online+0x9d/0xb0 [ 144.555179]
> > [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180 [ 144.555186]
> > [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0 [ 144.555192]
> > [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0 [ 144.555200]
> > [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
> > [ 144.555206] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0 [
> > 144.555212] [<ffffffff811c828f>] ? filp_close+0x4f/0x70 [
> > 144.555217] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0 [ 144.555223]
> > [<ffffffff811e9031>] ? __close_fd+0x71/0xb0 [ 144.555230]
> > [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
> >
> > If I revert that patch, the issue goes away.
> >
> > Any ideas?
Hi Dario,
Please also remove "register_cpu_notifier(&cpu_nfb)" in the cpufreq_register_driver function as well. (found that it has already been included in cpufreq_presmp_nfb()).
Best,
Wei
> I think it is due to xen-acpi-processor re-uploading the C and P states whenever
> an CPU goes up. It also does this after S3 suspend.
>
> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
> '__init' If you remove that little thing would it work?
>
> >
> > Regards,
> > Dario
> >
> > PS. yes, I'll implement a cpu hotplug/unplug testcase ASAP. :-)
> >
> > --
> > <<This happens because I choose it to happen!>> (Raistlin Majere)
> > -----------------------------------------------------------------
> > Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software
> > Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> >
>
>
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-10 1:38 ` Wang, Wei W
@ 2015-10-12 13:22 ` Jan Beulich
2015-10-12 13:34 ` Dario Faggioli
0 siblings, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2015-10-12 13:22 UTC (permalink / raw)
To: Dario Faggioli, Wei W Wang; +Cc: xen-devel@lists.xenproject.org
>>> On 10.10.15 at 03:38, <wei.w.wang@intel.com> wrote:
> On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 09, 2015 at 06:48:23PM +0200, Dario Faggioli wrote:
>> > Hey,
>> >
>> > As far as my bisection goes, commit
>> > 49388f11d512bb92706ce046643bfbb3c1d963c9 "x86/cpufreq: relocate the
>> > driver register function" prevents me from hot unplugging pCPUs.
>> >
>> > Xen does not crash or anything, but dom0 is stalled. In fact, with
>> > current staging, here's what I see:
>> >
>> > root@Zhaman:~# echo 0 > /sys/devices/system/xen_cpu/xen_cpu6/online
>> > [ 81.583001] INFO: rcu_sched detected stalls on CPUs/tasks: { 12}
> (detected
>> by 3, t=5252 jiffies, g=1691, c=1690, q=76)
>> > [ 81.583036] Task dump for CPU 12:
>> > [ 81.583044] bash R running task 0 1347 1094
> 0x00000008
>> > [ 81.583056] ffffffff00000000 0000000000000000 0000000000000000
>> ffff8800192c2e38
>> > [ 81.583070] ffff8800008472e8 0000000000000002 ffff8800008472e8
>> ffff880013817858
>> > [ 81.583082] 0000000000000000 00000000000081a4 ffffffff811e8137
>> ffff8800192c2e38
>> > [ 81.583095] Call Trace:
>> > [ 81.583110] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390
>> > [ 81.583148] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90
>> > [ 81.583158] [<ffffffff811e2866>] ? dput+0x26/0x230
>> > [ 81.583167] [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40
>> > [ 81.583176] [<ffffffff811d92b1>] ? do_last+0x621/0x12c0
>> > [ 81.583188] [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70
>> > [ 81.583199] [<ffffffff8156c64d>] ? store_online+0x9d/0xb0
>> > [ 81.583210] [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180
>> > [ 81.583220] [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0
>> > [ 81.583230] [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0
>> > [ 81.583241] [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
>> > [ 81.583250] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0
>> > [ 81.583259] [<ffffffff811c828f>] ? filp_close+0x4f/0x70
>> > [ 81.583268] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0
>> > [ 81.583277] [<ffffffff811e9031>] ? __close_fd+0x71/0xb0
>> > [ 81.583287] [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
>> > [ 144.555020] INFO: rcu_sched detected stalls on CPUs/tasks: { 12}
>> > (detected by 4, t=21007 jiffies, g=1691, c=1690, q=244) [ 144.555046] Task
>> dump for CPU 12:
>> > [ 144.555051] bash R running task 0 1347 1094
> 0x00000008
>> > [ 144.555059] ffffffff00000000 0000000000000000 0000000000000000
>> > ffff8800192c2e38 [ 144.555068] ffff8800008472e8 0000000000000002
>> > ffff8800008472e8 ffff880013817858 [ 144.555076] 0000000000000000
>> > 00000000000081a4 ffffffff811e8137 ffff8800192c2e38 [ 144.555084] Call
>> Trace:
>> > [ 144.555096] [<ffffffff811e8137>] ? notify_change+0x2f7/0x390 [
>> > 144.555105] [<ffffffff811c8c74>] ? do_truncate+0x74/0x90 [
>> > 144.555112] [<ffffffff811e2866>] ? dput+0x26/0x230 [ 144.555118]
>> > [<ffffffff811d53c5>] ? terminate_walk+0x35/0x40 [ 144.555124]
>> > [<ffffffff811d92b1>] ? do_last+0x621/0x12c0 [ 144.555164]
>> > [<ffffffff8139f0e7>] ? xen_pcpu_down+0x47/0x70 [ 144.555172]
>> > [<ffffffff8156c64d>] ? store_online+0x9d/0xb0 [ 144.555179]
>> > [<ffffffff81240bfc>] ? kernfs_fop_write+0x12c/0x180 [ 144.555186]
>> > [<ffffffff811ca513>] ? __vfs_write+0x23/0xf0 [ 144.555192]
>> > [<ffffffff811cd142>] ? __sb_start_write+0x42/0xf0 [ 144.555200]
>> > [<ffffffff8125f711>] ? security_file_permission+0x21/0xa0
>> > [ 144.555206] [<ffffffff811caea1>] ? vfs_write+0xa1/0x1c0 [
>> > 144.555212] [<ffffffff811c828f>] ? filp_close+0x4f/0x70 [
>> > 144.555217] [<ffffffff811cbb12>] ? SyS_write+0x42/0xb0 [ 144.555223]
>> > [<ffffffff811e9031>] ? __close_fd+0x71/0xb0 [ 144.555230]
>> > [<ffffffff815780f2>] ? system_call_fastpath+0x16/0x75
>> >
>> > If I revert that patch, the issue goes away.
>> >
>> > Any ideas?
>
> Please also remove "register_cpu_notifier(&cpu_nfb)" in the
> cpufreq_register_driver function as well. (found that it has already been
> included in cpufreq_presmp_nfb()).
Yes, I think this is it, and I seem to recall having complained about
this in an earlier version of the series (and I overlooked it now).
Dario, if could you let us know whether that helps?
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-12 13:22 ` Jan Beulich
@ 2015-10-12 13:34 ` Dario Faggioli
0 siblings, 0 replies; 9+ messages in thread
From: Dario Faggioli @ 2015-10-12 13:34 UTC (permalink / raw)
To: Jan Beulich, Wei W Wang; +Cc: xen-devel@lists.xenproject.org
[-- Attachment #1.1: Type: text/plain, Size: 1298 bytes --]
On Mon, 2015-10-12 at 07:22 -0600, Jan Beulich wrote:
> > > > On 10.10.15 at 03:38, <wei.w.wang@intel.com> wrote:
> > On 09/10/2015 04:01, Konrad Rzeszutek Wilk wrote:
> > Please also remove "register_cpu_notifier(&cpu_nfb)" in the
> > cpufreq_register_driver function as well. (found that it has
> > already been
> > included in cpufreq_presmp_nfb()).
>
> Yes, I think this is it, and I seem to recall having complained about
> this in an earlier version of the series (and I overlooked it now).
>
In fact, I did not spot it with `git diff' either (and the changelog
says "Move the driver register function"!).
> Dario, if could you let us know whether that helps?
>
Yep, I confirm that it was it. Avoiding calling register_cpu_notifier()
from cpufreq_register_driver(), I am able to put CPUs offline and then
back online again.
I've got to go AFK for a bit now, but I'm fine sending a patch later in
the afternoon. If someone wants to try beating me, no hard feelings.
:-)
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-09 20:00 ` Konrad Rzeszutek Wilk
2015-10-10 1:38 ` Wang, Wei W
@ 2015-10-12 13:19 ` Jan Beulich
2015-10-12 13:22 ` Dario Faggioli
2015-10-12 13:25 ` Andrew Cooper
1 sibling, 2 replies; 9+ messages in thread
From: Jan Beulich @ 2015-10-12 13:19 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org, Dario Faggioli, Wei Wang
>>> On 09.10.15 at 22:00, <konrad.wilk@oracle.com> wrote:
> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
> '__init' If you remove that little thing would it work?
Before adding this annotation I carefully check all callers, and both
which I could find are themselves __init. Did I overlook any?
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-12 13:19 ` Jan Beulich
@ 2015-10-12 13:22 ` Dario Faggioli
2015-10-12 13:25 ` Andrew Cooper
1 sibling, 0 replies; 9+ messages in thread
From: Dario Faggioli @ 2015-10-12 13:22 UTC (permalink / raw)
To: Jan Beulich, Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org, Wei Wang
[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]
On Mon, 2015-10-12 at 07:19 -0600, Jan Beulich wrote:
> > > > On 09.10.15 at 22:00, <konrad.wilk@oracle.com> wrote:
> > Anyhow it may be due to the fact that cpufreq_register_driver in
> > Xen is now
> > '__init' If you remove that little thing would it work?
>
> Before adding this annotation I carefully check all callers, and both
> which I could find are themselves __init. Did I overlook any?
>
No, I've just checked, and I also think __init is fine. And in fact, I
tried removing it, and the issue is still there.
I think the issue is the fact that we register the cpu notifier twice,
as an effect of 49388f11d512bb92706ce046643bfbb3c1d963c9, as Wei noted.
I'm just about try and confirm that...
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-12 13:19 ` Jan Beulich
2015-10-12 13:22 ` Dario Faggioli
@ 2015-10-12 13:25 ` Andrew Cooper
2015-10-12 13:29 ` Jan Beulich
1 sibling, 1 reply; 9+ messages in thread
From: Andrew Cooper @ 2015-10-12 13:25 UTC (permalink / raw)
To: Jan Beulich, Konrad Rzeszutek Wilk
Cc: xen-devel@lists.xenproject.org, Dario Faggioli, Wei Wang
On 12/10/15 14:19, Jan Beulich wrote:
>>>> On 09.10.15 at 22:00, <konrad.wilk@oracle.com> wrote:
>> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
>> '__init' If you remove that little thing would it work?
> Before adding this annotation I carefully check all callers, and both
> which I could find are themselves __init. Did I overlook any?
I agree that the __init status of the function is correct.
Other than the register_cpu_notifier() change, there is another change
which checks that !driver_data->target == !driver_data->setpolicy which
might be having an unintended side effect.
~Andrew
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug
2015-10-12 13:25 ` Andrew Cooper
@ 2015-10-12 13:29 ` Jan Beulich
0 siblings, 0 replies; 9+ messages in thread
From: Jan Beulich @ 2015-10-12 13:29 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel@lists.xenproject.org, DarioFaggioli, Wei Wang
>>> On 12.10.15 at 15:25, <andrew.cooper3@citrix.com> wrote:
> On 12/10/15 14:19, Jan Beulich wrote:
>>>>> On 09.10.15 at 22:00, <konrad.wilk@oracle.com> wrote:
>>> Anyhow it may be due to the fact that cpufreq_register_driver in Xen is now
>>> '__init' If you remove that little thing would it work?
>> Before adding this annotation I carefully check all callers, and both
>> which I could find are themselves __init. Did I overlook any?
>
> I agree that the __init status of the function is correct.
>
> Other than the register_cpu_notifier() change, there is another change
> which checks that !driver_data->target == !driver_data->setpolicy which
> might be having an unintended side effect.
Hardly, without anyone setting setpolicy to non-NULL so far.
Jan
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-10-12 13:34 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-09 16:48 patch "x86/cpufreq: relocate the driver register function" breaks cpu hot(un)plug Dario Faggioli
2015-10-09 20:00 ` Konrad Rzeszutek Wilk
2015-10-10 1:38 ` Wang, Wei W
2015-10-12 13:22 ` Jan Beulich
2015-10-12 13:34 ` Dario Faggioli
2015-10-12 13:19 ` Jan Beulich
2015-10-12 13:22 ` Dario Faggioli
2015-10-12 13:25 ` Andrew Cooper
2015-10-12 13:29 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.