On Tue, 23 Nov 2021, Tim Woodall wrote:
I have an old machine that I've just upgraded to bullseye. Now that it's
upgraded it does not power off when I do halt -p.
I see the following error: (copied so hopefully no typos)
Will now halt.
[ 183.942475] ACPI BIOS Error (bug): Could not resolve symbol
[\_SB.PCI0.LPCB.TPM.PTS], AE_NOT_FOUND (20200925/psargs-330)
[ 183.942946] ACPI Error: Aborting method \_PTS due to previous error
(AE_NOT_FOUND) (20200925/psparse-529)
[ 183.943586] reboot: Power down
I found this old bug:
https://bugzilla.kernel.org/show_bug.cgi?id=199117
While this may well be a bios bug, I've never had this problem before.
Now I've got it on two different (older machines)
I'll try downgrading the kernel back to 4.19 but has anyone else seen
anything like this?
Tim.
Interestingly the other machine doesn't print any ACPI errors, it just
doesn't turn off.
But I've discovered that it's something to do with xen, not the kernel.
Booting exactly the same kernel outside of xen does power off
successfully with no errors.
And booting with the 4.19 kernel from buster doesn't turn off on the
4.14 hypervisor.
I'm not exactly sure how to roll back to the 4.11 hypervisor. Just
dpkg -i xen-hypervisor-4.11-amd64_4.11.4+107-gef32c7afa2-1_amd64.deb
is enough to get it to boot (although it complains about xen-utils being
the wrong version) and then halt -p does power off
(As expected poweroff behaves identically to halt -p)
And I find this bug has already been opened.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994899
Unfortunately, the bug isn't very easy to read but I think there might
already be a fix in the pipeline. If not it looks like I can build a
patched hypervisor that doesn't have this problem. I'll investigate
further another day.
Fortunately for me I've been using these machines to test a poor man's
IPMI that I've been developing using a Pi4. I can power them on and off
and watch the boot and shutdown sequence remotely and even tweak the
bios settings. One of the reasons for using these two old machines is
that one only has VGA output while the other has HDMI and also one of
them the normal keyboard gadget cannot control the bios - not sure why -
so I developed an ffs driver instead. So I had them setup specifically
for testing rebooting and power-cycling. Pure luck that I chose to
upgrade them to bullseye and found this issue there.
Tim.