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+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
