<div>Patrick,</div><div>I also faced BMC hang but in my case it wasn't related to OS on host.</div><div>I've already found:</div><div>1. Dead cycle in phosphor-networkd (<a href="https://github.com/openbmc/phosphor-networkd/issues/36)">https://github.com/openbmc/phosphor-networkd/issues/36)</a></div><div>2. LPC IRQ storm caused by bug in BIOS (discovered by  watch -n 1 "cat /proc/interrupts" with following host power up). This case is similar to yours as whole BMC becomes unresponsive</div><div>3. The one I still fighting with: dbus-broker is starting to consume CPU and the normal sequence of systemd units start just stops, systemctl -a doesn't work, etc. The cure is to kill dbus-broker, after that all services are restarted and BMC works properly.</div><div> </div><div>In theory host can write to AST2500 registers via P2A, try disabling it.</div><div> </div><div>11.12.2020, 04:15, "Patrick Voelker" <patrick_voelker@phoenix.com>:</div><blockquote><p>I gave disabling the cpusensor service a try and it didn't make a difference. The BMC still goes out to lunch. Thanks for the suggestion.<br /><br />I tried disabling all the IPMI handlers but that didn't seem to help either:<br />systemctl stop <a href="mailto:phosphor-ipmi-kcs@ipmi_kcs3" rel="noopener noreferrer">phosphor-ipmi-kcs@ipmi_kcs3</a><br />systemctl stop <a href="mailto:phosphor-ipmi-kcs@ipmi_kcs4" rel="noopener noreferrer">phosphor-ipmi-kcs@ipmi_kcs4</a><br />systemctl stop <a href="mailto:phosphor-ipmi-net@eth0.socket" rel="noopener noreferrer">phosphor-ipmi-net@eth0.socket</a><br />systemctl stop <a href="mailto:phosphor-ipmi-net@eth1.socket" rel="noopener noreferrer">phosphor-ipmi-net@eth1.socket</a><br />systemctl stop phosphor-ipmi-host<br /><br />I think my next step will be to try disabling kernel config options that are related to things that can be influenced by the host.<br /> </p><blockquote> -----Original Message-----<br /> From: openbmc [<a href="mailto:openbmc" rel="noopener noreferrer">mailto:openbmc</a>-<br /> <a href="mailto:bounces+patrick_voelker=phoenix.com@lists.ozlabs.org" rel="noopener noreferrer">bounces+patrick_voelker=phoenix.com@lists.ozlabs.org</a>] On Behalf Of<br /> Andrew Jeffery<br /> Sent: Monday, November 30, 2020 4:47 PM<br /> To: <a href="mailto:openbmc@lists.ozlabs.org" rel="noopener noreferrer">openbmc@lists.ozlabs.org</a><br /> Subject: Re: Unresponsive BMC after booting into Ubuntu<br /> <br /> <br /> <br /> On Tue, 24 Nov 2020, at 18:05, Patrick Voelker wrote:<br /> > Hm. Sounds like a different issue. I don't think this solution will<br /> > help me since I can't access the serial console.<br /> <br /> I'm not Andrei, but my understanding was that he wasn't suggesting you try<br /> to<br /> apply the change after the lockup occurred, but rather before. And then if<br /> you<br /> don't see lockups with the change applied, then it might be the same<br /> problem.<br /> It wasn't about recovering the BMC from the lockup context.<br /> <br /> But yeah, hopefully I'm not adding to the confusion here!<br /> <br /> Andrew</blockquote></blockquote><div> </div><div> </div><div>-- </div><div>Best regards,</div><div>Konstantin Klubnichkin,</div><div>lead firmware engineer,</div><div>server hardware R&D group,</div><div>Yandex Moscow office.</div><div>tel: +7-903-510-33-33</div><div> </div>