Works better with a subject! ;)
Hey guys,
This is a question for Brendan Jackman but feel free to chime in if you know the answer.
I am having an issue when pulling in the new EAS 1.4 changes from ACK4.4. Mainly, I am getting a warning from:
https://android.googlesource.com/kernel/common.git/+/a21299785a502ca4b3592a0...
You can see the warning below:
c0 1865 [20171029_10:29:47.834626]@0 PC is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834632]@0 LR is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834637]@0 pc : [<ffffff84000d2758>] lr : [<ffffff84000d2758>] pstate: 60000145 c0 1865 [20171029_10:29:47.834641]@0 sp : ffffffcac19b3800 c0 1865 [20171029_10:29:47.834645]@0 x29: ffffffcac19b3800 x28: ffffff8401df7ee4 c0 1865 [20171029_10:29:47.834652]@0 x27: ffffffcae6626480 x26: ffffff8401e08858 c0 1865 [20171029_10:29:47.834658]@0 x25: ffffffcaf35fc780 x24: ffffff8400f77238 c0 1865 [20171029_10:29:47.834665]@0 x23: ffffff8401df85a0 x22: ffffff8401777400 c0 1865 [20171029_10:29:47.834672]@0 x21: 0000000000000008 x20: ffffff8401777400 c0 1865 [20171029_10:29:47.834678]@0 x19: ffffff8401df7ee4 x18: 00000000ffffffe8 c0 1865 [20171029_10:29:47.834684]@0 x17: 0000000000000000 x16: 0000000000000000 c0 1865 [20171029_10:29:47.834691]@0 x15: ffffff8401e16850 x14: 6465686373206572 c0 1865 [20171029_10:29:47.834697]@0 x13: 6177612079677265 x12: 6e6520726f662061 c0 1865 [20171029_10:29:47.834703]@0 x11: 74616420676e6973 x10: 73694d2030405d35 c0 1865 [20171029_10:29:47.834709]@0 x9 : 37353433382e3734 x8 : ffffffcaf46402ab c0 1865 [20171029_10:29:47.834715]@0 x7 : 0000000000000000 x6 : 000002257b061a96 c0 1865 [20171029_10:29:47.834721]@0 x5 : 00ffffffffffffff x4 : 0000000000000000 c0 1865 [20171029_10:29:47.834727]@0 x3 : 0000000000000140 x2 : a2032cf00b50bf18 c0 1865 [20171029_10:29:47.834734]@0 x1 : 0000000000000000 x0 : 0000000000000045 c0 1865 [20171029_10:29:47.834740]@0 c0 1865 PC: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834744]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834756]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834767]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834778]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834790]@0 c0 1865 LR: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834794]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834806]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834817]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834828]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834840]@0 c0 1865 SP: 0xffffffcac19b37c0: c0 1865 [20171029_10:29:47.834844]@0 37c0 000d2758 ffffff84 c19b3800 ffffffca 000d2758 ffffff84 60000145 00000000 c0 1865 [20171029_10:29:47.834855]@0 37e0 00000008 00000000 000000ff 00000000 00000000 00000080 f3405d50 ffffffca c0 1865 [20171029_10:29:47.834867]@0 3800 c19b38f0 ffffffca 000d2bbc ffffff84 00000000 00000000 01feacd0 ffffff84 c0 1865 [20171029_10:29:47.834878]@0 3820 01feab00 ffffff84 00000000 00000000 01feab00 ffffff84 00000004 00000000 c0 1865 [20171029_10:29:47.834890]@0 c0 1865 [20171029_10:29:47.834894]@0 ---[ end trace f7934377fe8659bc ]--- c0 1865 [20171029_10:29:47.834899]@0 Call trace: c0 1865 [20171029_10:29:47.834904]@0 Exception stack(0xffffffcac19b3610 to 0xffffffcac19b3740) c0 1865 [20171029_10:29:47.834910]@0 3600: ffffff8401df7ee4 0000008000000000 c0 1865 [20171029_10:29:47.834917]@0 3620: ffffffcac19b3800 ffffff84000d2758 0000000060000145 ffffff8401777400 c0 1865 [20171029_10:29:47.834923]@0 3640: ffffff8401df85a0 ffffff8400f77238 ffffffcaf35fc780 ffffff8401e08858 c0 1865 [20171029_10:29:47.834930]@0 3660: ffffffcae6626480 ffffff8401df7ee4 ffffffcac19b36c0 ffffff8401fecb90 c0 1865 [20171029_10:29:47.834937]@0 3680: 0000000000000000 00004d1712d78a33 ffffff8401fed000 00000000fcbeb400 c0 1865 [20171029_10:29:47.834943]@0 36a0: ffffff8401fed550 0000000000000140 ffffffcac19b3800 ffffffcac19b3800 c0 1865 [20171029_10:29:47.834950]@0 36c0: ffffffcac19b37c0 a2032cf00b50bf18 0000000000000045 0000000000000000 c0 1865 [20171029_10:29:47.834957]@0 36e0: a2032cf00b50bf18 0000000000000140 0000000000000000 00ffffffffffffff c0 1865 [20171029_10:29:47.834964]@0 3700: 000002257b061a96 0000000000000000 ffffffcaf46402ab 37353433382e3734 c0 1865 [20171029_10:29:47.834970]@0 3720: 73694d2030405d35 74616420676e6973 6e6520726f662061 6177612079677265 c0 1865 [20171029_10:29:47.834977]@0 [<ffffff84000d2758>] build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834983]@0 [<ffffff84000d2bbc>] partition_sched_domains+0x35c/0x410 c0 1865 [20171029_10:29:47.834990]@0 [<ffffff84000d2cb0>] cpuset_cpu_active+0x40/0x78 c0 1865 [20171029_10:29:47.834997]@0 [<ffffff84000c0a80>] notifier_call_chain+0x50/0x90 c0 1865 [20171029_10:29:47.835005]@0 [<ffffff84000c0be4>] __raw_notifier_call_chain+0xc/0x18 c0 1865 [20171029_10:29:47.835013]@0 [<ffffff84000a16e8>] cpu_notify+0x28/0x48 c0 1865 [20171029_10:29:47.835019]@0 [<ffffff84000a200c>] _cpu_up+0x23c/0x250 c0 1865 [20171029_10:29:47.835026]@0 [<ffffff84000a25cc>] enable_nonboot_cpus+0xc4/0x258 c0 1865 [20171029_10:29:47.835032]@0 [<ffffff84000fcb84>] suspend_enter+0x304/0x5f8 c0 1865 [20171029_10:29:47.835038]@0 [<ffffff84000fcf4c>] suspend_devices_and_enter+0xd4/0x310 c0 1865 [20171029_10:29:47.835045]@0 [<ffffff84000fd630>] pm_suspend+0x4a8/0x640 c0 1865 [20171029_10:29:47.835051]@0 [<ffffff84000fba84>] state_store+0x94/0xa8 c0 1865 [20171029_10:29:47.835058]@0 [<ffffff84003b642c>] kobj_attr_store+0x14/0x28 c0 1865 [20171029_10:29:47.835066]@0 [<ffffff8400243178>] sysfs_kf_write+0x48/0x58 c0 1865 [20171029_10:29:47.835073]@0 [<ffffff840024258c>] kernfs_fop_write+0xbc/0x190 c0 1865 [20171029_10:29:47.835080]@0 [<ffffff84001d2bb4>] __vfs_write+0x34/0xf8 c0 1865 [20171029_10:29:47.835086]@0 [<ffffff84001d34cc>] vfs_write+0x8c/0x178 c0 1865 [20171029_10:29:47.835093]@0 [<ffffff84001d3f64>] SyS_write+0x5c/0xc8 c0 1865 [20171029_10:29:47.835100]@0 [<ffffff8400084630>] el0_svc_naked+0x24/0x28 c0 1865 [20171029_10:29:47.836943]@0 Missing data for energy aware scheduling c0 1865 [20171029_10:29:47.836950]@0 ------------[ cut here ]------------
The error only occurs during suspend or if I manually set a core(s) to offline. This just floods the log during suspend. Is this the expected behavior?
Kind Regards, Zachariah Kennedy
Thanks for the report. For now I have reverted this from the 4.4 branch since its not critical. Once the issue is root caused, we can merge it again.
On Mon, Oct 30, 2017 at 1:50 PM, Zachariah Kennedy zkennedy87@gmail.com wrote:
Works better with a subject! ;)
Hey guys,
This is a question for Brendan Jackman but feel free to chime in if you know the answer.
I am having an issue when pulling in the new EAS 1.4 changes from ACK4.4. Mainly, I am getting a warning from:
https://android.googlesource.com/kernel/common.git/+/a21299785a502ca4b3592a0...
You can see the warning below:
c0 1865 [20171029_10:29:47.834626]@0 PC is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834632]@0 LR is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834637]@0 pc : [<ffffff84000d2758>] lr : [<ffffff84000d2758>] pstate: 60000145 c0 1865 [20171029_10:29:47.834641]@0 sp : ffffffcac19b3800 c0 1865 [20171029_10:29:47.834645]@0 x29: ffffffcac19b3800 x28: ffffff8401df7ee4 c0 1865 [20171029_10:29:47.834652]@0 x27: ffffffcae6626480 x26: ffffff8401e08858 c0 1865 [20171029_10:29:47.834658]@0 x25: ffffffcaf35fc780 x24: ffffff8400f77238 c0 1865 [20171029_10:29:47.834665]@0 x23: ffffff8401df85a0 x22: ffffff8401777400 c0 1865 [20171029_10:29:47.834672]@0 x21: 0000000000000008 x20: ffffff8401777400 c0 1865 [20171029_10:29:47.834678]@0 x19: ffffff8401df7ee4 x18: 00000000ffffffe8 c0 1865 [20171029_10:29:47.834684]@0 x17: 0000000000000000 x16: 0000000000000000 c0 1865 [20171029_10:29:47.834691]@0 x15: ffffff8401e16850 x14: 6465686373206572 c0 1865 [20171029_10:29:47.834697]@0 x13: 6177612079677265 x12: 6e6520726f662061 c0 1865 [20171029_10:29:47.834703]@0 x11: 74616420676e6973 x10: 73694d2030405d35 c0 1865 [20171029_10:29:47.834709]@0 x9 : 37353433382e3734 x8 : ffffffcaf46402ab c0 1865 [20171029_10:29:47.834715]@0 x7 : 0000000000000000 x6 : 000002257b061a96 c0 1865 [20171029_10:29:47.834721]@0 x5 : 00ffffffffffffff x4 : 0000000000000000 c0 1865 [20171029_10:29:47.834727]@0 x3 : 0000000000000140 x2 : a2032cf00b50bf18 c0 1865 [20171029_10:29:47.834734]@0 x1 : 0000000000000000 x0 : 0000000000000045 c0 1865 [20171029_10:29:47.834740]@0 c0 1865 PC: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834744]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834756]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834767]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834778]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834790]@0 c0 1865 LR: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834794]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834806]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834817]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834828]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834840]@0 c0 1865 SP: 0xffffffcac19b37c0: c0 1865 [20171029_10:29:47.834844]@0 37c0 000d2758 ffffff84 c19b3800 ffffffca 000d2758 ffffff84 60000145 00000000 c0 1865 [20171029_10:29:47.834855]@0 37e0 00000008 00000000 000000ff 00000000 00000000 00000080 f3405d50 ffffffca c0 1865 [20171029_10:29:47.834867]@0 3800 c19b38f0 ffffffca 000d2bbc ffffff84 00000000 00000000 01feacd0 ffffff84 c0 1865 [20171029_10:29:47.834878]@0 3820 01feab00 ffffff84 00000000 00000000 01feab00 ffffff84 00000004 00000000 c0 1865 [20171029_10:29:47.834890]@0 c0 1865 [20171029_10:29:47.834894]@0 ---[ end trace f7934377fe8659bc ]--- c0 1865 [20171029_10:29:47.834899]@0 Call trace: c0 1865 [20171029_10:29:47.834904]@0 Exception stack(0xffffffcac19b3610 to 0xffffffcac19b3740) c0 1865 [20171029_10:29:47.834910]@0 3600: ffffff8401df7ee4 0000008000000000 c0 1865 [20171029_10:29:47.834917]@0 3620: ffffffcac19b3800 ffffff84000d2758 0000000060000145 ffffff8401777400 c0 1865 [20171029_10:29:47.834923]@0 3640: ffffff8401df85a0 ffffff8400f77238 ffffffcaf35fc780 ffffff8401e08858 c0 1865 [20171029_10:29:47.834930]@0 3660: ffffffcae6626480 ffffff8401df7ee4 ffffffcac19b36c0 ffffff8401fecb90 c0 1865 [20171029_10:29:47.834937]@0 3680: 0000000000000000 00004d1712d78a33 ffffff8401fed000 00000000fcbeb400 c0 1865 [20171029_10:29:47.834943]@0 36a0: ffffff8401fed550 0000000000000140 ffffffcac19b3800 ffffffcac19b3800 c0 1865 [20171029_10:29:47.834950]@0 36c0: ffffffcac19b37c0 a2032cf00b50bf18 0000000000000045 0000000000000000 c0 1865 [20171029_10:29:47.834957]@0 36e0: a2032cf00b50bf18 0000000000000140 0000000000000000 00ffffffffffffff c0 1865 [20171029_10:29:47.834964]@0 3700: 000002257b061a96 0000000000000000 ffffffcaf46402ab 37353433382e3734 c0 1865 [20171029_10:29:47.834970]@0 3720: 73694d2030405d35 74616420676e6973 6e6520726f662061 6177612079677265 c0 1865 [20171029_10:29:47.834977]@0 [<ffffff84000d2758>] build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834983]@0 [<ffffff84000d2bbc>] partition_sched_domains+0x35c/0x410 c0 1865 [20171029_10:29:47.834990]@0 [<ffffff84000d2cb0>] cpuset_cpu_active+0x40/0x78 c0 1865 [20171029_10:29:47.834997]@0 [<ffffff84000c0a80>] notifier_call_chain+0x50/0x90 c0 1865 [20171029_10:29:47.835005]@0 [<ffffff84000c0be4>] __raw_notifier_call_chain+0xc/0x18 c0 1865 [20171029_10:29:47.835013]@0 [<ffffff84000a16e8>] cpu_notify+0x28/0x48 c0 1865 [20171029_10:29:47.835019]@0 [<ffffff84000a200c>] _cpu_up+0x23c/0x250 c0 1865 [20171029_10:29:47.835026]@0 [<ffffff84000a25cc>] enable_nonboot_cpus+0xc4/0x258 c0 1865 [20171029_10:29:47.835032]@0 [<ffffff84000fcb84>] suspend_enter+0x304/0x5f8 c0 1865 [20171029_10:29:47.835038]@0 [<ffffff84000fcf4c>] suspend_devices_and_enter+0xd4/0x310 c0 1865 [20171029_10:29:47.835045]@0 [<ffffff84000fd630>] pm_suspend+0x4a8/0x640 c0 1865 [20171029_10:29:47.835051]@0 [<ffffff84000fba84>] state_store+0x94/0xa8 c0 1865 [20171029_10:29:47.835058]@0 [<ffffff84003b642c>] kobj_attr_store+0x14/0x28 c0 1865 [20171029_10:29:47.835066]@0 [<ffffff8400243178>] sysfs_kf_write+0x48/0x58 c0 1865 [20171029_10:29:47.835073]@0 [<ffffff840024258c>] kernfs_fop_write+0xbc/0x190 c0 1865 [20171029_10:29:47.835080]@0 [<ffffff84001d2bb4>] __vfs_write+0x34/0xf8 c0 1865 [20171029_10:29:47.835086]@0 [<ffffff84001d34cc>] vfs_write+0x8c/0x178 c0 1865 [20171029_10:29:47.835093]@0 [<ffffff84001d3f64>] SyS_write+0x5c/0xc8 c0 1865 [20171029_10:29:47.835100]@0 [<ffffff8400084630>] el0_svc_naked+0x24/0x28 c0 1865 [20171029_10:29:47.836943]@0 Missing data for energy aware scheduling c0 1865 [20171029_10:29:47.836950]@0 ------------[ cut here ]------------
The error only occurs during suspend or if I manually set a core(s) to offline. This just floods the log during suspend. Is this the expected behavior?
Kind Regards, Zachariah Kennedy _______________________________________________ eas-dev mailing list eas-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/eas-dev
On Mon, Oct 30, 2017 at 2:17 PM, Joel Fernandes joelaf@google.com wrote:
Thanks for the report. For now I have reverted this from the 4.4 branch since its not critical. Once the issue is root caused, we can merge it again.
On Mon, Oct 30, 2017 at 1:50 PM, Zachariah Kennedy zkennedy87@gmail.com wrote:
Works better with a subject! ;)
Hey guys,
This is a question for Brendan Jackman but feel free to chime in if you know the answer.
I am having an issue when pulling in the new EAS 1.4 changes from ACK4.4. Mainly, I am getting a warning from:
https://android.googlesource.com/kernel/common.git/+/a21299785a502ca4b3592a0...
You can see the warning below:
c0 1865 [20171029_10:29:47.834626]@0 PC is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834632]@0 LR is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834637]@0 pc : [<ffffff84000d2758>] lr : [<ffffff84000d2758>] pstate: 60000145 c0 1865 [20171029_10:29:47.834641]@0 sp : ffffffcac19b3800 c0 1865 [20171029_10:29:47.834645]@0 x29: ffffffcac19b3800 x28: ffffff8401df7ee4 c0 1865 [20171029_10:29:47.834652]@0 x27: ffffffcae6626480 x26: ffffff8401e08858 c0 1865 [20171029_10:29:47.834658]@0 x25: ffffffcaf35fc780 x24: ffffff8400f77238 c0 1865 [20171029_10:29:47.834665]@0 x23: ffffff8401df85a0 x22: ffffff8401777400 c0 1865 [20171029_10:29:47.834672]@0 x21: 0000000000000008 x20: ffffff8401777400 c0 1865 [20171029_10:29:47.834678]@0 x19: ffffff8401df7ee4 x18: 00000000ffffffe8 c0 1865 [20171029_10:29:47.834684]@0 x17: 0000000000000000 x16: 0000000000000000 c0 1865 [20171029_10:29:47.834691]@0 x15: ffffff8401e16850 x14: 6465686373206572 c0 1865 [20171029_10:29:47.834697]@0 x13: 6177612079677265 x12: 6e6520726f662061 c0 1865 [20171029_10:29:47.834703]@0 x11: 74616420676e6973 x10: 73694d2030405d35 c0 1865 [20171029_10:29:47.834709]@0 x9 : 37353433382e3734 x8 : ffffffcaf46402ab c0 1865 [20171029_10:29:47.834715]@0 x7 : 0000000000000000 x6 : 000002257b061a96 c0 1865 [20171029_10:29:47.834721]@0 x5 : 00ffffffffffffff x4 : 0000000000000000 c0 1865 [20171029_10:29:47.834727]@0 x3 : 0000000000000140 x2 : a2032cf00b50bf18 c0 1865 [20171029_10:29:47.834734]@0 x1 : 0000000000000000 x0 : 0000000000000045 c0 1865 [20171029_10:29:47.834740]@0 c0 1865 PC: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834744]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834756]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834767]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834778]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834790]@0 c0 1865 LR: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834794]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834806]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834817]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834828]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834840]@0 c0 1865 SP: 0xffffffcac19b37c0: c0 1865 [20171029_10:29:47.834844]@0 37c0 000d2758 ffffff84 c19b3800 ffffffca 000d2758 ffffff84 60000145 00000000 c0 1865 [20171029_10:29:47.834855]@0 37e0 00000008 00000000 000000ff 00000000 00000000 00000080 f3405d50 ffffffca c0 1865 [20171029_10:29:47.834867]@0 3800 c19b38f0 ffffffca 000d2bbc ffffff84 00000000 00000000 01feacd0 ffffff84 c0 1865 [20171029_10:29:47.834878]@0 3820 01feab00 ffffff84 00000000 00000000 01feab00 ffffff84 00000004 00000000 c0 1865 [20171029_10:29:47.834890]@0 c0 1865 [20171029_10:29:47.834894]@0 ---[ end trace f7934377fe8659bc ]--- c0 1865 [20171029_10:29:47.834899]@0 Call trace: c0 1865 [20171029_10:29:47.834904]@0 Exception stack(0xffffffcac19b3610 to 0xffffffcac19b3740) c0 1865 [20171029_10:29:47.834910]@0 3600: ffffff8401df7ee4 0000008000000000 c0 1865 [20171029_10:29:47.834917]@0 3620: ffffffcac19b3800 ffffff84000d2758 0000000060000145 ffffff8401777400 c0 1865 [20171029_10:29:47.834923]@0 3640: ffffff8401df85a0 ffffff8400f77238 ffffffcaf35fc780 ffffff8401e08858 c0 1865 [20171029_10:29:47.834930]@0 3660: ffffffcae6626480 ffffff8401df7ee4 ffffffcac19b36c0 ffffff8401fecb90 c0 1865 [20171029_10:29:47.834937]@0 3680: 0000000000000000 00004d1712d78a33 ffffff8401fed000 00000000fcbeb400 c0 1865 [20171029_10:29:47.834943]@0 36a0: ffffff8401fed550 0000000000000140 ffffffcac19b3800 ffffffcac19b3800 c0 1865 [20171029_10:29:47.834950]@0 36c0: ffffffcac19b37c0 a2032cf00b50bf18 0000000000000045 0000000000000000 c0 1865 [20171029_10:29:47.834957]@0 36e0: a2032cf00b50bf18 0000000000000140 0000000000000000 00ffffffffffffff c0 1865 [20171029_10:29:47.834964]@0 3700: 000002257b061a96 0000000000000000 ffffffcaf46402ab 37353433382e3734 c0 1865 [20171029_10:29:47.834970]@0 3720: 73694d2030405d35 74616420676e6973 6e6520726f662061 6177612079677265 c0 1865 [20171029_10:29:47.834977]@0 [<ffffff84000d2758>] build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834983]@0 [<ffffff84000d2bbc>] partition_sched_domains+0x35c/0x410 c0 1865 [20171029_10:29:47.834990]@0 [<ffffff84000d2cb0>] cpuset_cpu_active+0x40/0x78 c0 1865 [20171029_10:29:47.834997]@0 [<ffffff84000c0a80>] notifier_call_chain+0x50/0x90 c0 1865 [20171029_10:29:47.835005]@0 [<ffffff84000c0be4>] __raw_notifier_call_chain+0xc/0x18 c0 1865 [20171029_10:29:47.835013]@0 [<ffffff84000a16e8>] cpu_notify+0x28/0x48 c0 1865 [20171029_10:29:47.835019]@0 [<ffffff84000a200c>] _cpu_up+0x23c/0x250 c0 1865 [20171029_10:29:47.835026]@0 [<ffffff84000a25cc>] enable_nonboot_cpus+0xc4/0x258 c0 1865 [20171029_10:29:47.835032]@0 [<ffffff84000fcb84>] suspend_enter+0x304/0x5f8 c0 1865 [20171029_10:29:47.835038]@0 [<ffffff84000fcf4c>] suspend_devices_and_enter+0xd4/0x310 c0 1865 [20171029_10:29:47.835045]@0 [<ffffff84000fd630>] pm_suspend+0x4a8/0x640 c0 1865 [20171029_10:29:47.835051]@0 [<ffffff84000fba84>] state_store+0x94/0xa8 c0 1865 [20171029_10:29:47.835058]@0 [<ffffff84003b642c>] kobj_attr_store+0x14/0x28 c0 1865 [20171029_10:29:47.835066]@0 [<ffffff8400243178>] sysfs_kf_write+0x48/0x58 c0 1865 [20171029_10:29:47.835073]@0 [<ffffff840024258c>] kernfs_fop_write+0xbc/0x190 c0 1865 [20171029_10:29:47.835080]@0 [<ffffff84001d2bb4>] __vfs_write+0x34/0xf8 c0 1865 [20171029_10:29:47.835086]@0 [<ffffff84001d34cc>] vfs_write+0x8c/0x178 c0 1865 [20171029_10:29:47.835093]@0 [<ffffff84001d3f64>] SyS_write+0x5c/0xc8 c0 1865 [20171029_10:29:47.835100]@0 [<ffffff8400084630>] el0_svc_naked+0x24/0x28 c0 1865 [20171029_10:29:47.836943]@0 Missing data for energy aware scheduling c0 1865 [20171029_10:29:47.836950]@0 ------------[ cut here ]------------
The error only occurs during suspend or if I manually set a core(s) to offline. This just floods the log during suspend. Is this the expected behavior?
So my suspicion is that the energy model isn't present on your system, so when the sched domain hierarchy is rebuilt during hotplug/suspend, this path screams.
Probably you have CONFIG_DEFAULT_USE_ENERGY_AWARE set but no energy model available in your Device Tree config?
thanks,
- Joel
I do have an EM. I am developing for the OnePlus 5 with the same SD835 as the Pixel 2s. So I am using the same EM as the Pixel 2. I can even check proc/sys/kernel/sched_domain and see the EM data per core. I am guessing that during suspend, certain cores are offlined and the sched_domain data is cleared for those cores thus providing the warning. It splats about 20 times a second during suspend.
So another question I am unsure of is:
Is the sched_domain data supposed to stick around even during suspend? If you dont know, that's OK. I just appreciate you getting with me.
Lastly, on a different note while I have ya, will the Pixel 2 eventually get EAS 1.4 and so on? I know on the Pixel, you guys opted to stick with EAS 1.1 for stability and performance on 3.18. So I was curious how far you guys were planning on pushing EAS on the new Pixel 2s.
Keep up the great work. Not only have I been following y'alls work, but I am part of the XDA Developer community and there are a large number of others interested in the future of EAS.
Kind Regards, Zachariah Kennedy
On Mon, Oct 30, 2017 at 4:21 PM, Joel Fernandes joelaf@google.com wrote:
On Mon, Oct 30, 2017 at 2:17 PM, Joel Fernandes joelaf@google.com wrote:
Thanks for the report. For now I have reverted this from the 4.4 branch since its not critical. Once the issue is root caused, we can merge it again.
On Mon, Oct 30, 2017 at 1:50 PM, Zachariah Kennedy zkennedy87@gmail.com
wrote:
Works better with a subject! ;)
Hey guys,
This is a question for Brendan Jackman but feel free to chime in if you know the answer.
I am having an issue when pulling in the new EAS 1.4 changes from
ACK4.4.
Mainly, I am getting a warning from:
a21299785a502ca4b3592a0f977aa1202b105260
You can see the warning below:
c0 1865 [20171029_10:29:47.834626]@0 PC is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834632]@0 LR is at build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834637]@0 pc : [<ffffff84000d2758>] lr : [<ffffff84000d2758>] pstate: 60000145 c0 1865 [20171029_10:29:47.834641]@0 sp : ffffffcac19b3800 c0 1865 [20171029_10:29:47.834645]@0 x29: ffffffcac19b3800 x28: ffffff8401df7ee4 c0 1865 [20171029_10:29:47.834652]@0 x27: ffffffcae6626480 x26: ffffff8401e08858 c0 1865 [20171029_10:29:47.834658]@0 x25: ffffffcaf35fc780 x24: ffffff8400f77238 c0 1865 [20171029_10:29:47.834665]@0 x23: ffffff8401df85a0 x22: ffffff8401777400 c0 1865 [20171029_10:29:47.834672]@0 x21: 0000000000000008 x20: ffffff8401777400 c0 1865 [20171029_10:29:47.834678]@0 x19: ffffff8401df7ee4 x18: 00000000ffffffe8 c0 1865 [20171029_10:29:47.834684]@0 x17: 0000000000000000 x16: 0000000000000000 c0 1865 [20171029_10:29:47.834691]@0 x15: ffffff8401e16850 x14: 6465686373206572 c0 1865 [20171029_10:29:47.834697]@0 x13: 6177612079677265 x12: 6e6520726f662061 c0 1865 [20171029_10:29:47.834703]@0 x11: 74616420676e6973 x10: 73694d2030405d35 c0 1865 [20171029_10:29:47.834709]@0 x9 : 37353433382e3734 x8 : ffffffcaf46402ab c0 1865 [20171029_10:29:47.834715]@0 x7 : 0000000000000000 x6 : 000002257b061a96 c0 1865 [20171029_10:29:47.834721]@0 x5 : 00ffffffffffffff x4 : 0000000000000000 c0 1865 [20171029_10:29:47.834727]@0 x3 : 0000000000000140 x2 : a2032cf00b50bf18 c0 1865 [20171029_10:29:47.834734]@0 x1 : 0000000000000000 x0 : 0000000000000045 c0 1865 [20171029_10:29:47.834740]@0 c0 1865 PC: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834744]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834756]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834767]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834778]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834790]@0 c0 1865 LR: 0xffffff84000d2718: c0 1865 [20171029_10:29:47.834794]@0 2718 9120bc21 39402424 35ffec84 d4210000 52800024 39002424 17ffff60 d503201f c0 1865 [20171029_10:29:47.834806]@0 2738 9400e4a6 d503201f 97ffdcfc 72001c1f 54ffe501 b0009ac0 911a8000 9402a9cb c0 1865 [20171029_10:29:47.834817]@0 2758 d4210000 17ffff23 aa1403e0 9403d705 12800160 f9006fbf b90067a0 17ffff20 c0 1865 [20171029_10:29:47.834828]@0 2778 97ff3ab2 b9401005 b9401321 6b0100bf 54fffa81 34fff6a5 f9400c02 f9400f21 c0 1865 [20171029_10:29:47.834840]@0 c0 1865 SP: 0xffffffcac19b37c0: c0 1865 [20171029_10:29:47.834844]@0 37c0 000d2758 ffffff84 c19b3800 ffffffca 000d2758 ffffff84 60000145 00000000 c0 1865 [20171029_10:29:47.834855]@0 37e0 00000008 00000000 000000ff 00000000 00000000 00000080 f3405d50 ffffffca c0 1865 [20171029_10:29:47.834867]@0 3800 c19b38f0 ffffffca 000d2bbc ffffff84 00000000 00000000 01feacd0 ffffff84 c0 1865 [20171029_10:29:47.834878]@0 3820 01feab00 ffffff84 00000000 00000000 01feab00 ffffff84 00000004 00000000 c0 1865 [20171029_10:29:47.834890]@0 c0 1865 [20171029_10:29:47.834894]@0 ---[ end trace f7934377fe8659bc
]---
c0 1865 [20171029_10:29:47.834899]@0 Call trace: c0 1865 [20171029_10:29:47.834904]@0 Exception stack(0xffffffcac19b3610 to 0xffffffcac19b3740) c0 1865 [20171029_10:29:47.834910]@0 3600: ffffff8401df7ee4 0000008000000000 c0 1865 [20171029_10:29:47.834917]@0 3620: ffffffcac19b3800 ffffff84000d2758 0000000060000145 ffffff8401777400 c0 1865 [20171029_10:29:47.834923]@0 3640: ffffff8401df85a0 ffffff8400f77238 ffffffcaf35fc780 ffffff8401e08858 c0 1865 [20171029_10:29:47.834930]@0 3660: ffffffcae6626480 ffffff8401df7ee4 ffffffcac19b36c0 ffffff8401fecb90 c0 1865 [20171029_10:29:47.834937]@0 3680: 0000000000000000 00004d1712d78a33 ffffff8401fed000 00000000fcbeb400 c0 1865 [20171029_10:29:47.834943]@0 36a0: ffffff8401fed550 0000000000000140 ffffffcac19b3800 ffffffcac19b3800 c0 1865 [20171029_10:29:47.834950]@0 36c0: ffffffcac19b37c0 a2032cf00b50bf18 0000000000000045 0000000000000000 c0 1865 [20171029_10:29:47.834957]@0 36e0: a2032cf00b50bf18 0000000000000140 0000000000000000 00ffffffffffffff c0 1865 [20171029_10:29:47.834964]@0 3700: 000002257b061a96 0000000000000000 ffffffcaf46402ab 37353433382e3734 c0 1865 [20171029_10:29:47.834970]@0 3720: 73694d2030405d35 74616420676e6973 6e6520726f662061 6177612079677265 c0 1865 [20171029_10:29:47.834977]@0 [<ffffff84000d2758>] build_sched_domains+0xc00/0xcc8 c0 1865 [20171029_10:29:47.834983]@0 [<ffffff84000d2bbc>] partition_sched_domains+0x35c/0x410 c0 1865 [20171029_10:29:47.834990]@0 [<ffffff84000d2cb0>] cpuset_cpu_active+0x40/0x78 c0 1865 [20171029_10:29:47.834997]@0 [<ffffff84000c0a80>] notifier_call_chain+0x50/0x90 c0 1865 [20171029_10:29:47.835005]@0 [<ffffff84000c0be4>] __raw_notifier_call_chain+0xc/0x18 c0 1865 [20171029_10:29:47.835013]@0 [<ffffff84000a16e8>] cpu_notify+0x28/0x48 c0 1865 [20171029_10:29:47.835019]@0 [<ffffff84000a200c>] _cpu_up+0x23c/0x250 c0 1865 [20171029_10:29:47.835026]@0 [<ffffff84000a25cc>] enable_nonboot_cpus+0xc4/0x258 c0 1865 [20171029_10:29:47.835032]@0 [<ffffff84000fcb84>] suspend_enter+0x304/0x5f8 c0 1865 [20171029_10:29:47.835038]@0 [<ffffff84000fcf4c>] suspend_devices_and_enter+0xd4/0x310 c0 1865 [20171029_10:29:47.835045]@0 [<ffffff84000fd630>] pm_suspend+0x4a8/0x640 c0 1865 [20171029_10:29:47.835051]@0 [<ffffff84000fba84>] state_store+0x94/0xa8 c0 1865 [20171029_10:29:47.835058]@0 [<ffffff84003b642c>] kobj_attr_store+0x14/0x28 c0 1865 [20171029_10:29:47.835066]@0 [<ffffff8400243178>] sysfs_kf_write+0x48/0x58 c0 1865 [20171029_10:29:47.835073]@0 [<ffffff840024258c>] kernfs_fop_write+0xbc/0x190 c0 1865 [20171029_10:29:47.835080]@0 [<ffffff84001d2bb4>] __vfs_write+0x34/0xf8 c0 1865 [20171029_10:29:47.835086]@0 [<ffffff84001d34cc>] vfs_write+0x8c/0x178 c0 1865 [20171029_10:29:47.835093]@0 [<ffffff84001d3f64>] SyS_write+0x5c/0xc8 c0 1865 [20171029_10:29:47.835100]@0 [<ffffff8400084630>] el0_svc_naked+0x24/0x28 c0 1865 [20171029_10:29:47.836943]@0 Missing data for energy aware scheduling c0 1865 [20171029_10:29:47.836950]@0 ------------[ cut here
]------------
The error only occurs during suspend or if I manually set a core(s) to offline. This just floods the log during suspend. Is this the expected behavior?
So my suspicion is that the energy model isn't present on your system, so when the sched domain hierarchy is rebuilt during hotplug/suspend, this path screams.
Probably you have CONFIG_DEFAULT_USE_ENERGY_AWARE set but no energy model available in your Device Tree config?
thanks,
- Joel
Hi Zachariah,
On Mon, Oct 30, 2017 at 2:41 PM, Zachariah Kennedy zkennedy87@gmail.com wrote:
I do have an EM. I am developing for the OnePlus 5 with the same SD835 as the Pixel 2s. So I am using the same EM as the Pixel 2. I can even check proc/sys/kernel/sched_domain and see the EM data per core. I am guessing that during suspend, certain cores are offlined and the sched_domain data is cleared for those cores thus providing the warning. It splats about 20 times a second during suspend.
This could be a sign of a bigger problem then and I'm curious to know what Brendan thinks since he added the warning patch.
So another question I am unsure of is:
Is the sched_domain data supposed to stick around even during suspend? If you dont know, that's OK. I just appreciate you getting with me.
Here's what I understand: During boot, the energy data is read from DT and store into an sge_array global data on boot up. Then when CPUs are brought online/offline - build_sched_domains calls init_sched_energy and stores a pointer to the sched_group_energy (depending on whether the domain is at cluster or core level). I suspect something is messed up here for your kernel.
Lastly, on a different note while I have ya, will the Pixel 2 eventually get EAS 1.4 and so on? I know on the Pixel, you guys opted to stick with EAS 1.1 for stability and performance on 3.18. So I was curious how far you guys were planning on pushing EAS on the new Pixel 2s.
I really don't know the answer to that at the moment.
Keep up the great work. Not only have I been following y'alls work, but I am part of the XDA Developer community and there are a large number of others interested in the future of EAS.
Nice to know. Thanks. Developers are welcome to participate.
- Joel
[..]
On Tue, Oct 31 2017 at 03:57, Joel Fernandes wrote:
Hi Zachariah,
On Mon, Oct 30, 2017 at 2:41 PM, Zachariah Kennedy zkennedy87@gmail.com wrote:
I do have an EM. I am developing for the OnePlus 5 with the same SD835 as the Pixel 2s. So I am using the same EM as the Pixel 2. I can even check proc/sys/kernel/sched_domain and see the EM data per core. I am guessing that during suspend, certain cores are offlined and the sched_domain data is cleared for those cores thus providing the warning. It splats about 20 times a second during suspend.
Yes, this would definitely be explained by cores being hotplugged out - I haven't looked into the details but a simple example is that if all the cores but one are hotplugged out, then there won't be _any_ sched_domains (IIUC), so the checks introduced by the patch in question will definitely fail.
I'm happy to leave the patch reverted - I wrote it a long time ago to to simplify asking the question "are you sure you actually have an EM loaded?" when our synthetic tests failed. We now have a check in LISA's 'preliminary' suite that tells you the answer to that, and it doesn't require carrying a kernel patch, so I'd say it's a simpler solution. And in the end, when you're testing real Android platforms, there isn't really an avenue for make the mistake of missing out an EM.
Thanks for the report!
This could be a sign of a bigger problem then and I'm curious to know what Brendan thinks since he added the warning patch.
So another question I am unsure of is:
Is the sched_domain data supposed to stick around even during suspend? If you dont know, that's OK. I just appreciate you getting with me.
Here's what I understand: During boot, the energy data is read from DT and store into an sge_array global data on boot up. Then when CPUs are brought online/offline - build_sched_domains calls init_sched_energy and stores a pointer to the sched_group_energy (depending on whether the domain is at cluster or core level). I suspect something is messed up here for your kernel.
Lastly, on a different note while I have ya, will the Pixel 2 eventually get EAS 1.4 and so on? I know on the Pixel, you guys opted to stick with EAS 1.1 for stability and performance on 3.18. So I was curious how far you guys were planning on pushing EAS on the new Pixel 2s.
I really don't know the answer to that at the moment.
Keep up the great work. Not only have I been following y'alls work, but I am part of the XDA Developer community and there are a large number of others interested in the future of EAS.
Nice to know. Thanks. Developers are welcome to participate.
- Joel
[..]
Always glad to help. Thanks for confirming me suspicions.
Kind Regards, Zachariah Kennedy
On Tue, Oct 31, 2017 at 5:01 AM, Brendan Jackman brendan.jackman@arm.com wrote:
On Tue, Oct 31 2017 at 03:57, Joel Fernandes wrote:
Hi Zachariah,
On Mon, Oct 30, 2017 at 2:41 PM, Zachariah Kennedy zkennedy87@gmail.com
wrote:
I do have an EM. I am developing for the OnePlus 5 with the same SD835
as
the Pixel 2s. So I am using the same EM as the Pixel 2. I can even check proc/sys/kernel/sched_domain and see the EM data per core. I am guessing that during suspend, certain cores are offlined and the sched_domain
data is
cleared for those cores thus providing the warning. It splats about 20
times
a second during suspend.
Yes, this would definitely be explained by cores being hotplugged out - I haven't looked into the details but a simple example is that if all the cores but one are hotplugged out, then there won't be _any_ sched_domains (IIUC), so the checks introduced by the patch in question will definitely fail.
I'm happy to leave the patch reverted - I wrote it a long time ago to to simplify asking the question "are you sure you actually have an EM loaded?" when our synthetic tests failed. We now have a check in LISA's 'preliminary' suite that tells you the answer to that, and it doesn't require carrying a kernel patch, so I'd say it's a simpler solution. And in the end, when you're testing real Android platforms, there isn't really an avenue for make the mistake of missing out an EM.
Thanks for the report!
This could be a sign of a bigger problem then and I'm curious to know what Brendan thinks since he added the warning patch.
So another question I am unsure of is:
Is the sched_domain data supposed to stick around even during suspend?
If
you dont know, that's OK. I just appreciate you getting with me.
Here's what I understand: During boot, the energy data is read from DT and store into an sge_array global data on boot up. Then when CPUs are brought online/offline - build_sched_domains calls init_sched_energy and stores a pointer to the sched_group_energy (depending on whether the domain is at cluster or core level). I suspect something is messed up here for your kernel.
Lastly, on a different note while I have ya, will the Pixel 2
eventually get
EAS 1.4 and so on? I know on the Pixel, you guys opted to stick with
EAS 1.1
for stability and performance on 3.18. So I was curious how far you guys were planning on pushing EAS on the new Pixel 2s.
I really don't know the answer to that at the moment.
Keep up the great work. Not only have I been following y'alls work, but
I am
part of the XDA Developer community and there are a large number of
others
interested in the future of EAS.
Nice to know. Thanks. Developers are welcome to participate.
- Joel
[..]
-
Brendan Jackman -
Joel Fernandes -
Zachariah Kennedy