On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote:
On 9/20/21 7:39 PM, Diederik de Haas wrote:
On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote:
Merely having the path is a sufficiently strong indicator for me to
simply wave it past. I though would suggest Debian should instead
cherry-pick commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8.
This is available as a patch at:
https://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=0f089bbf43ecce6f27576cb548ba4341d0ec46a8
You probably then also want the following commit, which is a fix on that patch:
https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b
Found that via the following url/query:
https://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=commit&s=x86%2FACPI
I don't know whether others should be used from that as well.
I tried these two commits (adapted for the xen-4.14 branch) but this
approach did not fix the bug - with these patches applied the dom0
did not power down.
My advice for the Debian Xen Team is to consult with upstream and
get their advice on whether or not it is advisable for Debian to
retain the patches from the Xen-4.16 branch that have been
added to the Debian 4.14 package in an attempt to support
some arm devices that panic during on an unpatched Xen-4.14.
If upstream cannot help Debian backport fixes for arm panics
from Xen-4.16/unstable to Xen-4.14 stable, I think the Debian
Xen team should remove aggressive patches that really have now
turned the Debian Xen-4.14 package into a Frankenstein version
that is a mixture of Xen-4.14 and Xen-4.16, and decide that support
for those arm devices must wait until Debian gets Xen 4.16 up
and running on the unstable and hopefully soon, testing distribution.
It is still not established you're running into #991967. Unless the one
you're pointing towards was backported to the Xen 4.11 packages (which I
doubt) it cannot explain #991967, since at the time 4.11 was in use.
Could be this is a second bug with symptoms similar to #991967. Now
that a fix for the second bug has been identified, you might try a
4.19.181-1 kernel and see whether that fixes things.