Bug#991967: #991967: Simply ACPI powerdown/reset issue?
On Mon, Sep 20, 2021 at 06:29:49PM -0400, Chuck Zmudzinski wrote:
> On 9/20/21 1:43 PM, Chuck Zmudzinski wrote:
> >
> > On 9/20/21 12:27 AM, Elliott Mitchell wrote:
> >> On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> >>
> >>> I suspect the following patch is the culprit for problems
> >>> shutting down on the amd64 architecture:
> >>>
> >>> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> >>> 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.
> >> Of the ones listed that is the only one which has any overlap with x86
> >> code.?? The next reproduction step is `apt-get source xen &&
> >> patch -p1 -R <
> >> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> >> && dpkg-buildpackage -b`.?? Then try with this to confirm that patch
> >> is what does it.
> >>
> >> Thing is that delta is rather small.?? I don't have a simulator, but that
> >> is rather small to be the culprit.
> >
> > I just tested the build with
> > patch -p1 -R <
> > 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> > applied before building the package and I can confirm that this is the
> > patch
> > causing the trouble for dom0 poweroff on x86/amd64. Reverting this patch
> > fixes it on my amd64 system. But this would probably break the arm build.
> >
> > I think one possible fix would require modifying
> > 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
> > so it only applies at runtime to the arm architecture. I will try some
> > modifications to the patch instead of removing it, and if I get something
> > that works on amd64 and also might work on arm, I will post it
> > for Elliott to try.
>
> I have an encouraging result. I found a very simple patch
> to xen/arch/x86/acpi/lib.c that fixes the dom0 poweroff
> bug on my system and it should not affect the arm patches
> at all:
> --------------------------------------------------------------
> This patch partially reverts previous patch
> 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch
>
> This hopefully fixes #911976
>
> --- a/xen/arch/x86/acpi/lib.c?????? 2021-09-20 16:49:08.000000000 -0400
> +++ b/xen/arch/x86/acpi/lib.c?????? 2021-09-20 16:25:05.572038000 -0400
> @@ -46,10 +46,6 @@
> ???????? if ((phys + size) <= (1 * 1024 * 1024))
> ???????? ?????? return __va(phys);
>
> -?????? /* No further arch specific implementation after early boot */
> -?????? if (system_state >= SYS_STATE_boot)
> -?????? ?????? return NULL;
> -
> ???????? offset = phys & (PAGE_SIZE - 1);
> ???????? mapped_size = PAGE_SIZE - offset;
> ???????? set_fixmap(FIX_ACPI_END, phys);
> ----------------------------------------------------------------------
>
> Can you try this patch to src:xen and see if your
> arm devices are OK with it?
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
The other commit I would suggest being picked by src:xen is
5a4087004d1adbbb223925f3306db0e5824a2bdc
This is for device-tree funkiness which got added between linux-5.10.0
and linux-5.10.y (if the Debian kernel team wants to maintain a fix in
Debian's kernel source, that works too).
BTW have I mentioned I've become rather skeptical of device-trees being
a usable way of representing hardware information?
--
(\___(\___(\______ --=> 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: