[Pkg-xen-devel] Bug#994899: xen-hypervisor-4.14-amd64 breaks system poweroff on bullseye

[Chuck Zmudzinski]

Package: xen-hypervisor-4.14-amd64
Version: 4.14.3-1~deb11u1
Severity: important
Tags: patch newcomer upstream

Dear Maintainer,

This bug is related to #991976, reported by Elliott Mitchell,
who happens to be the person who requested the patches
that are causing this bug. I understand he is a Debian Xen
developer.

Since I am not a developer, I only tagged this bug
important, but if I were a developer, I would tag it
serious and implement a fix that does what I will
propose below.

I hereby humbly request that you elevate this bug to
serious, since it is entirely wrong to release software
that causes a modern workstation/server to not power down
properly and renders it unable to be managed remotely,
which is what this bug does. A bug like this is
normal on an unstable or testing distribution, but
unacceptable/serious on the current stable release.

I refer you here for my first description of the problem
to the Debian Bug System:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#34

I also point out that another Debian user confirmed the
bug on bullseye:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991967#54

Elliott is of the opinion that what I am seeing is a
bug distinct from #991976. I am inclined to agree, as I
have not been able to reproduce it the way he describes
it, although the symptoms he sees are very similar.
That is why I am submitting a new report.

I can drill down the cause of this bug in the stable
version of debian to the Debian Xen Team's decision to
include a series of nine commits from upstream in order
to improve Raspberry Pi 4 support in version
4.14.0+88-g1d1d1f5391-1. So the bug was introduced in
the Debian Xen unstable/testing package on 15 Dec 2020
according to the changelog.

I understand the original reporter of #991976 wants to
keep these patches in the stable version of Xen to
better support the Raspberry Pi 4, and that he is
a Debian Xen developer. But I will strenuously and
respectfully disagree with any decision by the Debian
Xen Team to not apply a very reasonable compromise
solution.

Over on #991967, I argued passionately for removing
the nine Raspberry Pi 4 patches from the stable Xen
version because, and it is still my opinion that
experiments with patches from unstable upstream
branches is not appropriate for a package in a
stable version. That is why I would expect the
release team to tag this bug as serious even if
the Debian Xen Team refuses to tag it as serious.

Nevertheless, I propose the following compromise:

Simply ship a package for the stable version that
omits the nine Raspberry Pi 4 patches from unstable
upstream while building for the amd64|i386
architectures. I was able to implement such a fix
even though I am not an official developer in
just a few hours. It is really a trivial fix,
all I did was add a rule in debian/rules to use
quilt to disable the nine patches on amd64|i386.
I made it easy by moving the nine RP4 patches
from debian/patches to debian/patches/rpi4
and so could I use sed s/rpi4/#rpi4/ debian/series
to disable the patches for the amd64|i386 case.

I am sure there are other ways to implement the
fix, and it really is trivial, it would fix
this bug and still allow for the Raspberry Pi 4
patches to be included where they are needed
which I believe is in the arm64 architecture.

I also tested the current unstable branch from
Xen upstream, which is xen-c76cfad, which
unstable calls Xen-4.16-unstable. I tested
the current bullseye kernel as a dom0 on that
upstream Xen-4.16 hypervisor and did not
see the bug, so this most definetely is
NOT an upstream bug. It is a Debian Xen
packaging bug. I expect that perhaps some
commits on the Xen-4.16 upstream branch
that are missing on the Xen-4.14 branch might
also fix this bug, but until such a solution
is found, I suggest the aforementioned solution
as a workaround. The reason I tagged this bug
as upstream is that I think it would be
adviseable to make upstream aware that our
current xen-4.14 package is not really a
true Xen-4.14 but one with some patches from
Xen-unstable that are causing this bug, and
perhaps they can help eventually find the best
solution for their Xen-4.14 stable branch.

Finally, I tag the bug newcomer simply because
there is a known solution but the Debian Xen
package maintainer seems to want the Debian
Kernel Team to find a way to fix the bug
in the Linux kernel, as evidenced by the
recent discussion over at #991976, instead
of implementing the fix in the Xen hypervisor
as proposed here.

Regards,

Chuck Zmudzinski


*** Reporter, please consider answering these questions, where 
appropriate ***

    * What led up to the situation?
    * What exactly did you do (or not do) that was effective (or
      ineffective)?
    * What was the outcome of this action?
    * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.0
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8.1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

xen-hypervisor-4.14-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.14-amd64 recommends:
pn  xen-hypervisor-common  <none>
pn  xen-utils-4.14         <none>

xen-hypervisor-4.14-amd64 suggests no packages.