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

Thu Sep 23 20:54:49 BST 2021

On 9/23/2021 12:49 PM, Diederik de Haas wrote:
> 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

Wow! I am not going to bother defending myself except by stating
the author of this message made several false assumptions about
me in his attack on my character and good reputation. While I
did respond point by point privately to the author, in the
interest of avoiding further negativity I am not going to respond
further to this message in this public forum.

Regards,

Chuck Zmudzinski