<html><body><p><font size="2">What you have tells me that pdbg stop is already doing what I suggested you do I think since it shows the wakeup bit getting set. Note though that it is a core reg, so you need to read 200F010B on every core. Does pdbg have a "-call" option?</font><br><br><font size="2">I also don't know what pdbg threadstatus is actually looking at. There are requested states and actual states. Wakeup would only change the actual state. Also, it might not block STOP1 since that doesn't affect any pervasive accesses, but that is just speculation.</font><br><br><tt><font size="2">> It looks like 0 bit in SPECIAL_WKUP_FSP_REG takes the thread out of "quiesced" state, but do not set it as active.</font></tt><br><font size="2">Correct. Wakeup only prevents the core from going through the stop state transitions. The thread still thinks it is in those states. It should look similar to what you'd see if a single thread were to execute STOP5 but the other threads are still active. In that case, the core can't do anything because there are some active threads.</font><br><font size="2"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><img width="16" height="16" src="cid:1__=09BB0F3CDFE50B518f9e8a93df938690918c09B@" border="0" alt="Inactive hide details for Artem Senichev ---07/24/2020 12:31:19 PM---Hi Dan, Thank you for quick reply!"><font size="2" color="#424282">Artem Senichev ---07/24/2020 12:31:19 PM---Hi Dan, Thank you for quick reply!</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Artem Senichev <a.senichev@yadro.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Daniel M Crowell <dcrowell@us.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"openpower-firmware@lists.ozlabs.org" <openpower-firmware@lists.ozlabs.org>, Alexander Amelkin <a.amelkin@yadro.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">07/24/2020 12:31 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [OpenPower-Firmware] SRESET and idle CPU</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Hi Dan,<br><br>Thank you for quick reply!<br><br>I tried to use SPECIAL_WKUP_FSP_REG register, but it does not work as expected for me.<br>Maybe I am using this incorrectly?<br><br># current state<br>bmc:~ # pdbg -p0 -c0 -t0-3 threadstatus<br>p0t: 0 1 2 3<br>c00: .S. .S. .S. .S.<br><br># read SPECIAL_WKUP_FSP_REG<br>bmc:~ # pdbg -p0 getscom 0x200F010B<br>p0: 0x00000000200f010b = 0x0000000000000000 (/proc0/pib)<br><br># stop the first thread<br>bmc:~ # pdbg -p0 -c0 -t0 stop<br><br># SPECIAL_WKUP_FSP_REG has changed<br>bmc:~ # pdbg -p0 getscom 0x200F010B<br>p0: 0x00000000200f010b = 0x8000000000000000 (/proc0/pib)<br><br># thread now in quiesced state<br>bmc:~ # pdbg -p0 -c0 -t0-3 threadstatus<br>p0t: 0 1 2 3<br>c00: .SQ .S. .S. .S.<br><br># force set 0 bit (addr value mask)<br>bmc:~ # pdbg -p0 putscom 0x200F010B 0x8000000000000000 0x8000000000000000<br><br># state still inactive<br>bmc:~ # pdbg -p0 -c0 -t0-3 threadstatus<br>p0t: 0 1 2 3<br>c00: .SQ .S. .S. .S.<br><br># read SPECIAL_WKUP_FSP_REG<br>bmc:~ # pdbg -p0 getscom 0x200F010B<br>p0: 0x00000000200f010b = 0x8000000000000000 (/proc0/pib)<br><br># reset 0 bit<br>bmc:~ # pdbg -p0 putscom 0x200F010B 0 0x8000000000000000<br><br># no quiesced state for now<br>bmc:~ # pdbg -p0 -c0 -t0-3 threadstatus<br>p0t: 0 1 2 3<br>c00: .S. .S. .S. .S.<br><br># read SPECIAL_WKUP_FSP_REG<br>bmc:~ # pdbg -p0 getscom 0x200F010B<br>p0: 0x00000000200f010b = 0x0000000000000000 (/proc0/pib)<br><br>It looks like 0 bit in SPECIAL_WKUP_FSP_REG takes the thread out of "quiesced" state, but do not set it as active.<br><br>If I disable cpuidle on the host, I see something like this (which is what I expect):<br>bmc:~ # pdbg -p0 -c0 -t0-3 threadstatus<br>p0t: 0 1 2 3<br>c00: A.. .S. .S. .S.<br><br>--<br>Regards,<br>Artem Senichev<br>Software Engineer, YADRO.<br><br><br>________________________________________<br>From: Daniel M Crowell <dcrowell@us.ibm.com><br>Sent: 24 July 2020 18:04<br>To: Artem Senichev<br>Cc: openpower-firmware@lists.ozlabs.org<br>Subject: Re: [OpenPower-Firmware] SRESET and idle CPU<br><br>I think that you might be able to initiate a 'special wakeup' via scom from the BMC. I'm a little surprised that pdbg doesn't have that built in to the stop function already like we do in some similar tooling (but I have no visibility to pdbg's goals). Enabling special wakeup forces a core to exit the idle state and prevents it from going idle. Instructions aren't executed, but pervasively the core is alive. That should allow the scoms to trigger stop/sreset/etc to work.<br><br>For P9 there are 3 sets of wakeup registers, each with a different owner:<br>- 200F010A = SPECIAL_WKUP_OTR_REG - Used by the PM Complex itself internally<br>- 200F010B = SPECIAL_WKUP_FSP_REG - Used by FSP when we have one, or by HBRT/opal-prd on these boxes<br>- 200F010C = SPECIAL_WKUP_OCC_REG - Used by OCC<br>- 200F010D = SPECIAL_WKUP_HYP_REG - Used by OPAL/PHYP<br><br>I would recommend that you use 200F010B for this purpose. You just need to set bit 0 to trigger it, though there is a non-zero time for it to take effect. See <a href="https://github.com/open-power/hostboot/blob/master/src/import/chips/p9/procedures/hwp/pm/p9_cpu_special_wakeup.C">https://github.com/open-power/hostboot/blob/master/src/import/chips/p9/procedures/hwp/pm/p9_cpu_special_wakeup.C</a> for the details.<br><br>You'll need to set it on every functional core. You could probably get fancy and use multicasts to do it with a single scom using group 1. And don't forget to clear it later so that you can use idle states again later.<br><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com<br><br>[Inactive hide details for Artem Senichev ---07/24/2020 07:03:58 AM---Hi all, Our customers want to be able to initiate kdump on]Artem Senichev ---07/24/2020 07:03:58 AM---Hi all, Our customers want to be able to initiate kdump on a POWER9 host system from BMC console.<br><br>From: Artem Senichev <a.senichev@yadro.com><br>To: "openpower-firmware@lists.ozlabs.org" <openpower-firmware@lists.ozlabs.org><br>Date: 07/24/2020 07:03 AM<br>Subject: [EXTERNAL] [OpenPower-Firmware] SRESET and idle CPU<br>Sent by: "OpenPower-Firmware" <openpower-firmware-bounces+dcrowell=us.ibm.com@lists.ozlabs.org><br><br>________________________________<br><br><br><br>Hi all,<br><br>Our customers want to be able to initiate kdump on a POWER9 host system from BMC console.<br>I tried to implement this functionality with an SRESET signal sent through the pdbg utility, but it turned out that when the CPU is in an idle state (sleep), the signal could not be delivered.<br><br>I can disable the idle state on a host:<br><br>for i in /sys/devices/system/cpu/cpu0/cpuidle/state*/disable; do<br> echo 1 > $i<br>done<br><br>and then send SRESET from BMC:<br><br>pdbg -p0 -c0 -t0 stop<br>pdbg -p0 -c0 -t0 sreset<br><br>This solution works fine, but I need to do it without interfering with the host system.<br>Is it possible?<br><br>--<br>Regards,<br>Artem Senichev<br>Software Engineer, YADRO.<br><br>_______________________________________________<br>OpenPower-Firmware mailing list<br>OpenPower-Firmware@lists.ozlabs.org<br><a href="https://lists.ozlabs.org/listinfo/openpower-firmware">https://lists.ozlabs.org/listinfo/openpower-firmware</a> <br><br><br><br><br></font></tt><br><br><BR>
</body></html>