Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> On Sat, 11 Sep 2021 13:29:12 +0200 Salvatore Bonaccorso
> <carnil@debian.org> wrote:
> >
> > On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > > An experiment lead to a potential alternative explanation for #991967.
> > > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
> > > 4.19.194-3. Presence of Xen on the system may be unrelated.
> > >
> > > Failing that, it could be Xen and non-UEFI systems are effected. (Xen
> > > was tried on a UEFI system and the issue wasn't observed)
> >
> > Following up on https://bugs.debian.org/991967#12
> >
> > Did you succeeded in bisecting the issue as you seem to have it
> > reproducible?
>
> I noticed this bug on bullseye ever since I have been
> running bullseye as a dom0, but my testing indicates
> there is no problem with src:linux but the problem
> appeared in src:xen with the 4.14 version of xen on
> bullseye.
>
> I ask Elliott if you are only seeing the problem on Debian's
> xen-4.14 hypervisor? Also, which architecture, arm or
> amd64? I only see the problem on the Debian xen-4.14
> hypervisor, and I have only tested on amd64, and I
> have found a fix for my amd64 system which is as
> follows:
>
> Motherboard: ASRock B85M Pro4, BIOS P2.50 12/11/2015,
> with a Haswell CPU (core i5-4590S)
>
> xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64
>
> linux kernel version: 5.10.46-4 (the current amd64 kernel
> for bullseye)
Nope. As per the report the problem appeared with kernel 4.19.194-3 and
at the time using Xen 4.11.
The kernel you're listing is rather more recent, which might suggest a
patch which had been backported from 5.x to 4.19.
I could believe a Xen security update being the trigger though (I don't
recall there being one at the right time, but I wouldn't rule it out).
> Boot system: EFI, not using secure boot, booting xen
> hypervisor and dom0 bullseye with grub-efi package for
> bullseye, and it boots the xen-4.14-amd64.gz file, not
> the xen-4.14-amd64.efi file.
>
> I also tested a buster dom0 with the 4.19 series kernel
> on the xen-4.14 hypervisor from bullseye and saw the
> problem, but I did not see the problem with either
> a buster (linux 4.19) or bullseye (linux 5.10) dom0 on
> the xen-4.11 hypervisor, so I think the problem is
> with the Debian version of the xen-4.14 hypervisor,
> not with src:linux.
Just to make sure, the kernel you were testing was 4.19.194-3? The
issue didn't manifest with kernels earlier than that.
Could be we're seeing distinct bugs.
> This patch does affect amd64 acpi code, and is probably causing
> the problem on my amd64 system, so my build of the xen-4.14
> hypervisor without this patch fixed the problem.
While that commit modifies the code path the processor takes, the
modified path appears identical.
> I also would inquire with the Debian Xen Team about why they
> are backporting patches from the upstream xen unstable
> branch into Debian's 4.14 package that is currently shipping
> on Debian stable (bullseye). IMHO, the aforementioned
> patches that are not in the stable 4.14 branch upstream
> should not be included in the xen package for Debian stable.
Some people are asking for those. Those are bugfixes for an extremely
popular device which panics on boot without the patches.
Meanwhile turned out between 5.10.0 and 5.10.30 the ARM64 device-trees
were modified in a way which broke Xen 4.14 on ARM64. The change
violated Linux's own standards for device-trees, yet still appeared in a
stable branch.
In other news, if you see device-trees compared to ACPI tables, they're
not very comparable. 99% of ACPI tables work for all versions of all
OSes. Any given device-tree is only likely to work for a single version
of a single OS. While a useful abstraction for portions of kernel code,
device-trees are utter garbage compared to ACPI tables.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Reply to: