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

[Diederik de Haas]

Control: tag -1 -newcomer 
Control: tag -1 -upstream

On woensdag 22 september 2021 21:50:16 CEST Chuck Zmudzinski wrote:
> Finally, I tag the bug newcomer simply because there is a known solution but

That's what the 'patch' tag is for. 'newcomer' is similar to 'good first issue', 
which this is not. Hence removing the 'newcomer' tag.

> 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.

You're claiming, possibly correctly, that the issue is with the Debian Xen
package, not with the upstream code, so removing the 'upstream' tag as well.


It's good that you filed this bug against the Debian Xen package because it's 
(quite) possible that there is both an issue with the Linux kernel which 
#991976 is about and with the Xen package, what this issue will be about.

They way you went about it ... not so good.

By filing a bug you want others to spend their free time to (help) fix an issue
you are having (and in this case, me too). To make the best use of their time
and your chances of it being fixed, you should state the problem as short and 
succinct as possible.
And in the case of a 'patch' as may be the case here, the actual patch.

You did neither.

You did go on a rant where you made (incorrect) claims and accusations.
I don't think that helps your goal, which is getting this issue fixed. Do you?

F.e. you make claims on the Debian Xen package maintainers' position, while 
this is the first time they've been made (explicitly) aware of this issue. 
So they did not have a chance to (formulate and) state their position.

I had written a point-by-point description of what *I* think was wrong with
your bug report, but that would only keep the negative cycle in place.
FTR: I'm just a contributor to Debian (by participating in this bug), just 
like you are (by submitting a bug). And so is Elliot.

For uploading packages to the Debian archive you *do* need special 
permissions. For almost all other things, everyone can contribute.

> Package: xen-hypervisor-4.14-amd64
> Version: 4.14.3-1~deb11u1
> Severity: important
> 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.

https://www.debian.org/Bugs/Developer#severities explains what the severity
levels entail. There is no correlation between severity and some (claimed) role
within the project. IMO this bug is *at most* important.
Let's leave it to the Debian Xen package maintainers to change the severity 
if they think that's appropriate.

> 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

IMO, this is just wrong.
You've filed a new bug so make the exact problem the primary part of this bug.
Don't ask of others to read a '50 page document' and expect them to distill 
YOUR problem themselves.
Doing a copy+paste of the *relevant* part is absolutely fine.

So please reply to this with the following (minimal) info:
- Your hardware
- Whether you use BIOS or UEFI
- Your init system
- What you did and what the result of that was.

Item 2 & 3 may seem 'odd' at first, but should become clear later on.

> another Debian user confirmed the bug on bullseye:

Yep. If I do 'poweroff' on my Xen server, it looks like it does the whole 
shutdown procedure correctly, but it doesn't actually poweroff the machine.

> I can drill down the cause of this bug in the stable version of debian to
> a series of nine commits from upstream in order to improve Raspberry Pi 4
> support in version 4.14.0+88-g1d1d1f5391-1.

Do those 9 commits correspond to 9 patches from the 
<debian-xen-repo>/debian/patches/ directory? If so, which 9?
If you add the 'patch' tag, do indeed include the patch in the bug report.

I built Xen packages based on 4.14.3-1~deb11u1 but remove patches 0029-0034, 
but after installing those packages and rebooting into my patched version, my 
Xen server still did NOT power off. Other patches didn't seem relevant *to me*,
but I can be wrong. If you share your changes, I can try whether that will fix 
the problem with me (too).
My Xen server uses BIOS (not UEFI, which I think you do) and has sysv-init 
as init system. That may be relevant as well.

> So the bug was introduced in the Debian Xen unstable/testing package on 
> 15 Dec 2020 according to the changelog.

You *think* that was the case? Or did your Bullseye system actually poweroff 
correctly when installing version 4.14.0+80-gd101b417b7-1 or earlier?
That was the version before the RPi4 related patches were added.
Version N-1=good, version N=bad is very useful and relevant info.

> 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. 

Can you do a test with the upstream Xen-4.14 code?
It *can* actually be an upstream bug present in the 4.14 code which has been 
fixed in the Xen-4.16-unstable 'branch'.

If you compare the following 2 branches, there are quite some differences:
https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=refs/heads/stable-4.14
https://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/acpi;hb=HEAD
And that's only for the 'xen/arch/x86/acpi/' folder.

> 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

The whole existence of the [debian/]patches directory makes it not identical
to upstream's code. I'm quite sure upstream Xen is already aware of that, 
but it's also none of their concern/business.
As said earlier, the 'upstream' tag is entirely incorrect.

While I *personally* do agree that grabbing 'random' upstream patches should
not be done or with extreme caution (in the case of Xen), that decision is 
actually up to the maintainers of the Debian package(s).

In this case Elliot made a *suggestion* and until now, no one had reported
a problem with it, so there was no reason to *assume* it was harmful.

Evidence and proof are much better arguments then (vague) speculation.
I'm quite certain you're very capable of the former, so let's see more of that.

> 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>

You seem to NOT have installed Recommended packages, which is generally
a bad thing. In case of xen-hypervisor-common possibly harmful and relevant.

Cheers,
  Diederik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20210923/ac8fee27/attachment.sig>