| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Delete-config.sub-and-config.guess.patch | Delete config.sub and config.guess dh_autoreconf will provide these back. If this patch does not apply when rebasing, you can simply delete the files again. |
Ian Jackson <ian.jackson@citrix.com> | no | 2018-09-19 | ||
| 0002-Delete-configure-output.patch | Delete configure output These autogenerated files are not useful in Debian; dh_autoreconf will regenerate them. If this patch does not apply when rebasing, you can simply delete the files again. |
Ian Jackson <ian.jackson@citrix.com> | no | 2018-09-19 | ||
| 0003-version.patch | version | Bastian Blank <waldi@debian.org> | no | 2014-07-05 | ||
| prefix-abiname/config-prefix.diff | config-prefix.diff | Bastian Blank <waldi@debian.org> | no | 2014-07-05 | ||
| 0005-Do-not-ship-COPYING-into-usr-include.patch | Do not ship COPYING into /usr/include This is not wanted in Debian. COPYING ends up in /usr/share/doc/xen-*copyright. |
Bastian Blank <waldi@debian.org> | no | 2014-07-05 | ||
| misc/tools-pygrub-remove-static-solaris-support | Remove static solaris support from pygrub | Bastian Blank <waldi@debian.org> | no | 2014-07-05 | ||
| misc/toolstestsx86_emulator-pass--no-pie--fno.patch | tools/tests/x86_emulator: Pass -no-pie -fno-pic to gcc on x86_32 The current build fails with GCC6 on Debian sid i386 (unstable): /tmp/ccqjaueF.s: Assembler messages: /tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression `vmovd_to_reg_len@GOT' This is due to the combination of GCC6, and Debian's decision to enable some hardening flags by default (to try to make runtime addresses less predictable): https://wiki.debian.org/Hardening/PIEByDefaultTransition This is of no benefit for the x86 instruction emulator test, which is a rebuild of the emulator code for testing purposes only. So pass options to disable this. These options will be no-ops if they are the same as the compiler default. On amd64, the -fno-pic breaks the build in a different way. So do this only on i386. |
Ian Jackson <ian.jackson@citrix.com> | no | 2016-11-01 | ||
| 0008-Do-not-build-the-instruction-emulator.patch | Do not build the instruction emulator | Ian Jackson <ian.jackson@citrix.com> | no | 2018-09-20 | ||
| 0009-tools-libfsimage-prefix.diff.patch | tools-libfsimage-prefix.diff \o/ |
Hans van Kranenburg <hans@knorrie.org> | no | 2020-05-25 | ||
| 0010-autoconf-Provide-libexec_libdir_suffix.patch | autoconf: Provide libexec_libdir_suffix This is going to be used to put libfsimage.so into a path containing the multiarch triplet. |
Ian Jackson <ian.jackson@citrix.com> | no | 2018-10-03 | ||
| 0011-.gitignore-Add-configure-output-which-we-always-dele.patch | .gitignore: Add configure output which we always delete and regenerate | Ian Jackson <ian.jackson@citrix.com> | no | 2018-10-05 | ||
| 0012-Revert-pvshim-make-PV-shim-build-selectable-from-con.patch | Revert "pvshim: make PV shim build selectable from configure" This reverts commit 8845155c831c59e867ee3dd31ee63e0cc6c7dcf2. This upstream change changes stuff that breaks our very fragile mess that builds the shim when it needs to, and doesn't when it should not. The result is that it's missing in the end for the i386 build... :| dh_install: warning: Cannot find (any matches for) "usr/lib/debug/usr/lib/xen-*/boot/*" (tried in ., debian/tmp) dh_install: warning: xen-utils-4.14 missing files: usr/lib/debug/usr/lib/xen-*/boot/* dh_install: error: missing files, aborting |
Hans van Kranenburg <hans@knorrie.org> | no | 2020-11-22 | ||
| 0013-tools-firmware-Makfile-Respect-caller-s-CONFIG_PV_SH.patch | tools/firmware/Makfile: Respect caller's CONFIG_PV_SHIM This makes it easier to disable the shim build. (In Debian we need to build the shim separately because it needs different compiler flags and a different XEN_COMPILE_ARCH. |
Ian Jackson <iwj@barriere.debian.org> | no | 2018-10-12 | ||
| 0014-tools-firmware-Makefile-CONFIG_PV_SHIM-enable-only-o.patch | tools/firmware/Makefile: CONFIG_PV_SHIM: enable only on x86_64 Previously this was *dis*abled for x86_*32*. But if someone should run some of this Makefile on ARM, say, it ought not to be built either. |
Ian Jackson <iwj@amdahl.debian.org> | no | 2018-10-12 | ||
| 0015-shim-Provide-separate-install-shim-target.patch | shim: Provide separate install-shim target When building on a 32-bit userland, the user wants to build 32-bit tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH to different values for the tools build and the hypervisor build. So the user must invoke the tools build and the hypervisor build separately. However, although the shim is done by the tools/firmware Makefile, its bitness needs to be the same as the hypervisor, not the same as the tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is wrong. So the user must invoke the shim build separately. This can be done with make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64 However, tools/firmware/xen-dir has no `install' target. The installation of all `firmware' is done in tools/firmware/Makefile. It might be possible to fix this, but it is not trivial. For example, the definitions of INST_DIR and DEBG_DIR would need to be copied, as would an appropriate $(INSTALL_DIR) call. For now, provide an `install-shim' target in tools/firmware/Makefile. This has to be called from `install' of course. We can't make it a dependency of `install' because it might be run before `all' has completed. We could make it depend on a `shim' target but such a target is nearly impossible to write because everything is done by the inflexible subdir-$@ machinery. The overally result of this patch is that existing make invocations work as before. But additionally, the user can say make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64 to install the shim. The user must have built it already. Unlike the build rune, this install-rune is properly conditional so it is OK to call on ARM. What a mess. |
Ian Jackson <iwj@barriere.debian.org> | no | 2018-10-12 | ||
| 0016-docs-man-xen-vbd-interface.7-Provide-properly-format.patch | docs/man/xen-vbd-interface.7: Provide properly-formatted NAME section This manpage was omitted from docs/man: Provide properly-formatted NAME sections because I was previously building with markdown not installed. |
Ian Jackson <ian.jackson@citrix.com> | no | 2018-10-12 | ||
| 0017-Fix-empty-fields-in-first-hypervisor-log-line.patch | Fix empty fields in first hypervisor log line Instead of: (XEN) Xen version 4.11.1 (Debian ) (@) (gcc (Debian 8.2.0-13) 8.2.0) debug=n Thu Jan 3 19:08:37 UTC 2019 I'd like to see: (XEN) Xen version 4.11.1 (Debian 4.11.1-1~) (pkg-xen-devel@lists.alioth.debian.org) (gcc (Debian 8.2.0-13) 8.2.0) debug=n Thu Jan 3 22:44:00 CET 2019 The substitution was broken since the great packaging refactoring, because the directory in which the build is done changed. Also, use the Maintainer address from debian/control instead of the most recent changelog entry. If someone wants to use the address to ask a question, they will end up at the team mailing list, which is better than an individual person. |
Hans van Kranenburg <hans@knorrie.org> | no | 2019-01-03 | ||
| 0018-vif-common-disable-handle_iptable.patch | vif-common: disable handle_iptable Also see Debian bug #894013. The current attempt at providing anti-spoofing rules results in a situation that does not have any effect. Also note that forwarding bridged traffic to iptables is not enabled by default, and that for openvswitch users it does not make any sense. So, stop cluttering the live iptables ruleset. This functionality seems to be introduced before 2004 and since then it has never got some additional love. It would be nice to have a proper discussion upstream about how Xen could provide some anti mac/ip spoofing in the dom0. It does not seem to be a trivial thing to do, since it requires having quite some knowledge about what the domU is allowed to do or not (e.g. a domU can be a router...). |
Hans van Kranenburg <hans@knorrie.org> | no | 2019-01-04 | ||
| 0019-sysconfig.xencommons.in-Strip-and-debianize.patch | sysconfig.xencommons.in: Strip and debianize Strip all options that are for stuff we don't ship, which is 1) xenstored as stubdom and 2) xenbackendd, which seems to be dead code anyway. [1] It seems useful to give the user the option to revert to xenstored instead of the default oxenstored if they really want. [1] https://lists.xen.org/archives/html/xen-devel/2015-07/msg04427.html |
Hans van Kranenburg <hans@knorrie.org> | no | 2019-02-09 | ||
| 0020-hotplug-common-Do-not-adjust-LD_LIBRARY_PATH.patch | hotplug-common: Do not adjust LD_LIBRARY_PATH This is in the upstream script because on non-Debian systems, the default install locations in /usr/local/lib might not be on the linker path, and as a result the hotplug scripts would break. A reason we might need it in Debian is our multiple version coinstallation scheme. However, the hotplug scripts all call the utilities via the wrappers, and the binaries are configured to load from the right place anyway. This setting is an annoyance because it requires libdir, which is an arch-specific path but comes from a file we want to put in xen-utils-common, an arch:all package. So drop this setting. |
Ian Jackson <ian.jackson@citrix.com> | no | 2019-02-21 | ||
| 0021-pygrub-Set-sys.path.patch | pygrub: Set sys.path We install libfsimage in a non-standard path for Reasons. (See debian/rules.) This patch was originally part of `tools-pygrub-prefix.diff' (eg commit 51657319be54) and included changes to the Makefile to change the installation arrangements (we do that part in the rules now since that is a lot less prone to conflicts when we update) and to shared library rpath (which is now done in a separate patch). (Commit message rewritten by Ian Jackson.) squash! pygrub: Set sys.path and rpath |
Bastian Blank <waldi@debian.org> | no | 2014-07-05 | ||
| 0022-pygrub-Specify-rpath-LIBEXEC_LIB-when-building-fsima.patch | pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so If LIBEXEC_LIB is not on the default linker search path, the python fsimage.so module fails to find libfsimage.so. Add the relevant directory to the rpath explicitly. (This situation occurs in the Debian package, where --with-libexec-libdir is used to put each Xen version's libraries and utilities in their own directory, to allow them to be coinstalled.) |
Ian Jackson <ian.jackson@citrix.com> | no | 2019-02-22 | ||
| 0023-tools-xl-bash-completion-also-complete-xen.patch | tools/xl/bash-completion: also complete 'xen' We have the `xen` alias for xl in Debian, since in the past it was a command that could execute either xl or xm. Now, it always does xl, so, complete the same stuff for it as we have for xl. [git-debrebase split: mixed commit: upstream part] |
Hans van Kranenburg <hans@knorrie.org> | no | 2019-02-10 | ||
| 0024-tools-don-t-build-ship-xenmon.patch | tools: don't build/ship xenmon It can't run with Python 3, and I'm not going to fix it. |
Hans van Kranenburg <hans@knorrie.org> | no | 2020-09-05 | ||
| 0025-tools-Partially-revert-Cross-compilation-fixes.patch | tools: Partially revert "Cross-compilation fixes." This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7. Doesn't look like much of 16504669c5cbb8b195d20412aadc838da5c428f7 actually remains due to passage of time. Of the 3, both Python and pygrub appear to mostly be building just fine cross-compiling. The OCAML portion is being troublesome, this is going to cause bug reports elsewhere soon. The OCAML portion though can already be disabled by setting OCAML_TOOLS=n and shouldn't have this extra form of disabling. (cherry picked from commit 69953e2856382274749b617125cc98ce38198463) |
Elliott Mitchell <ehem+xen@m5p.com> | no | 2020-07-17 | ||
| 0026-t-h-L-vif-common.sh-fix-handle_iptable-return-value.patch | t/h/L/vif-common.sh: fix handle_iptable return value A return statement without explicit value will return the value of the last command executed before this line with return was encountered. This is not what we want. return 0. |
Hans van Kranenburg <hans@knorrie.org> | no | 2020-11-26 | ||
| 0027-xen-rpi4-implement-watchdog-based-reset.patch | xen/rpi4: implement watchdog-based reset The preferred method to reboot RPi4 is PSCI. If it is not available, touching the watchdog is required to be able to reboot the board. The implementation is based on drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux v5.9-rc7. (cherry picked from commit 25849c8b16f2a5b7fcd0a823e80a5f1b590291f9) |
Stefano Stabellini <sstabellini@kernel.org> | no | 2020-10-02 | ||
| 0028-tools-python-Pass-linker-to-Python-build-process.patch | tools/python: Pass linker to Python build process Unexpectedly the environment variable which needs to be passed is $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead of the host `ld`. Replace $(LDFLAGS) with $(SHLIB_LDFLAGS) as Python needs shared objects it can load at runtime, not executables. This uses $(CC) instead of $(LD) since Python distutils appends $CFLAGS to $LDFLAGS which breaks many linkers. (cherry picked from commit 17d192e0238d6c714e9f04593b59597b7090be38) [ Hans van Kranenburg ] Fixed cherry-pick conflict because we have LIBEXEC_LIB=$(LIBEXEC_LIB) in between in the same lines. The line wrap mess makes it a bit hard to follow. |
Elliott Mitchell <ehem+xen@m5p.com> | no | 2020-10-11 | ||
| 0029-xen-arm-acpi-Don-t-fail-if-SPCR-table-is-absent.patch | xen/arm: acpi: Don't fail if SPCR table is absent Absence of a SPCR table likely means the console is a framebuffer. In such case acpi_iomem_deny_access() should NOT fail. (cherry picked from commit 861f0c110976fa8879b7bf63d9478b6be83d4ab6) |
Elliott Mitchell <ehem+xen@m5p.com> | no | 2020-10-21 | ||
| 0030-xen-acpi-Rework-acpi_os_map_memory-and-acpi_os_unmap.patch | xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory() The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic while the __acpi_os_{un,}map_memory() are meant to be arch-specific. Currently, the former are still containing x86 specific code. To avoid this rather strange split, the generic helpers are reworked so they are arch-agnostic. This requires the introduction of a new helper __acpi_os_unmap_memory() that will undo any mapping done by __acpi_os_map_memory(). Currently, the arch-helper for unmap is basically a no-op so it only returns whether the mapping was arch specific. But this will change in the future. Note that the x86 version of acpi_os_map_memory() was already able to able the 1MB region. Hence why there is no addition of new code. (cherry picked from commit 1c4aa69ca1e1fad20b2158051eb152276d1eb973) |
Julien Grall <jgrall@amazon.com> | no | 2020-09-26 | ||
| 0031-xen-arm-acpi-The-fixmap-area-should-always-be-cleare.patch | xen/arm: acpi: The fixmap area should always be cleared during failure/unmap Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in {set, clear}_fixmap()" enforced that each set_fixmap() should be paired with a clear_fixmap(). Any failure to follow the model would result to a platform crash. Unfortunately, the use of fixmap in the ACPI code was overlooked as it is calling set_fixmap() but not clear_fixmap(). The function __acpi_os_map_table() is reworked so: - We know before the mapping whether the fixmap region is big enough for the mapping. - It will fail if the fixmap is already in use. This is not a change of behavior but clarifying the current expectation to avoid hitting a BUG(). The function __acpi_os_unmap_table() will now call clear_fixmap(). (cherry picked from commit 4d625ff3c3a939dc270b03654337568c30c5ab6e) |
Julien Grall <jgrall@amazon.com> | no | 2020-09-26 | ||
| 0032-xen-arm-Check-if-the-platform-is-not-using-ACPI-befo.patch | xen/arm: Check if the platform is not using ACPI before initializing Dom0less Dom0less requires a device-tree. However, since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree later on in the boot", the device-tree will not get unflatten when using ACPI. This will lead to a crash during boot. Given the complexity to setup dom0less with ACPI (for instance how to assign device?), we should skip any code related to Dom0less when using ACPI. (cherry picked from commit dac867bf9adc1562a4cf9db5f89726597af13ef8) |
Julien Grall <jgrall@amazon.com> | no | 2020-09-26 | ||
| 0033-xen-arm-Introduce-fw_unreserved_regions-and-use-it.patch | xen/arm: Introduce fw_unreserved_regions() and use it Since commit 6e3e77120378 "xen/arm: setup: Relocate the Device-Tree later on in the boot", the device-tree will not be kept mapped when using ACPI. However, a few places are calling dt_unreserved_regions() which expects a valid DT. This will lead to a crash. As the DT should not be used for ACPI (other than for detecting the modules), a new function fw_unreserved_regions() is introduced. It will behave the same way on DT system. On ACPI system, it will unreserve the whole region. Take the opportunity to clarify that bootinfo.reserved_mem is only used when booting using Device-Tree. (cherry picked from commit 9c2bc0f24b2ba7082df408b3c33ec9a86bf20cf0) |
Julien Grall <jgrall@amazon.com> | no | 2020-09-26 | ||
| 0034-xen-arm-acpi-add-BAD_MADT_GICC_ENTRY-macro.patch | xen/arm: acpi: add BAD_MADT_GICC_ENTRY() macro Imported from Linux commit b6cfb277378ef831c0fa84bcff5049307294adc6: The BAD_MADT_ENTRY() macro is designed to work for all of the subtables of the MADT. In the ACPI 5.1 version of the spec, the struct for the GICC subtable (struct acpi_madt_generic_interrupt) is 76 bytes long; in ACPI 6.0, the struct is 80 bytes long. But, there is only one definition in ACPICA for this struct -- and that is the 6.0 version. Hence, when BAD_MADT_ENTRY() compares the struct size to the length in the GICC subtable, it fails if 5.1 structs are in use, and there are systems in the wild that have them. This patch adds the BAD_MADT_GICC_ENTRY() that checks the GICC subtable only, accounting for the difference in specification versions that are possible. The BAD_MADT_ENTRY() will continue to work as is for all other MADT subtables. This code is being added to an arm64 header file since that is currently the only architecture using the GICC subtable of the MADT. As a GIC is specific to ARM, it is also unlikely the subtable will be used elsewhere. Fixes: aeb823bbacc2 ("ACPICA: ACPI 6.0: Add changes for FADT table.") Signed-off-by: Al Stone <al.stone@linaro.org> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net> [catalin.marinas@arm.com: extra brackets around macro arguments] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 7056f2f89f03f2f804ac7e776c7b2b000cd716cd) |
Julien Grall <julien.grall@arm.com> | no | 2020-09-30 | ||
| 0035-xen-arm-traps-Don-t-panic-when-receiving-an-unknown-.patch | xen/arm: traps: Don't panic when receiving an unknown debug trap Even if debug trap are only meant for debugging purpose, it is quite harsh to crash Xen if one of the trap sent by the guest is not handled. So switch from a panic() to a printk(). (cherry picked from commit 957708c2d1ae25d7375abd5e5e70c3043d64f1f1) |
Julien Grall <jgrall@amazon.com> | no | 2020-11-05 | ||
| 0036-fix-spelling-errors.patch | fix spelling errors Only spelling errors; no functional changes. In docs/misc/dump-core-format.txt there are a few more instances of 'informations'. I'll leave that up to someone who can properly determine how those sentences should be constructed. (cherry picked from commit ba6e78f0db820fbeea4df41fde4655020ca05928) |
Diederik de Haas <didi.debian@cknow.org> | no | 2020-12-04 | ||
| 0037-xen-don-t-have-timestamp-inserted-in-config.gz.patch | xen: don't have timestamp inserted in config.gz This is for improving reproducible builds. (cherry picked from commit 5816d327e44ab37ae08730f4c54a80835998f31f) |
=?utf-8?b?IkZyw6lkw6lyaWMgUGllcnJldCAoZmVwaXRyZSki?= | no | 2020-11-04 | ||
| 0038-x86-EFI-don-t-insert-timestamp-when-SOURCE_DATE_EPOC.patch | x86/EFI: don't insert timestamp when SOURCE_DATE_EPOCH is defined By default a timestamp gets added to the xen efi binary. Unfortunately ld doesn't seem to provide a way to set a custom date, like from SOURCE_DATE_EPOCH, so set a zero value for the timestamp (option --no-insert-timestamp) if SOURCE_DATE_EPOCH is defined. This makes reproducible builds possible. This is an alternative to the patch suggested in [1]. This patch only omits the timestamp when SOURCE_DATE_EPOCH is defined. [1] https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg02161.html (cherry picked from commit ee41b5c450032ae7f2531e18cd0a73bf5fb48803) |
Maximilian Engelhardt <maxi@daemonizer.de> | no | 2020-12-22 | ||
| 0039-docs-use-predictable-ordering-in-generated-documenta.patch | docs: use predictable ordering in generated documentation When the seq number is equal, sort by the title to get predictable output ordering. This is useful for reproducible builds. (cherry picked from commit e18dadc5b709290b8038a1cacb52bc3b3b69cf21) |
Maximilian Engelhardt <maxi@daemonizer.de> | no | 2020-12-18 | ||
| 0040-docs-set-date-to-SOURCE_DATE_EPOCH-if-available.patch | docs: set date to SOURCE_DATE_EPOCH if available Use the solution described in [1] to replace the call to the 'date' command with a version that uses SOURCE_DATE_EPOCH if available. This is needed for reproducible builds. [1] https://reproducible-builds.org/docs/source-date-epoch/ [Hans van Kranenburg] expect that it gets in. Otherwise, we don't wait and already have it here because I want to have the reproducible build work completed. |
Maximilian Engelhardt <maxi@daemonizer.de> | no | 2020-12-18 | ||
| 0041-x86-ACPI-fix-mapping-of-FACS.patch | x86/ACPI: fix mapping of FACS acpi_fadt_parse_sleep_info() runs when the system is already in SYS_STATE_boot. Hence its direct call to __acpi_map_table() won't work anymore. This call should probably have been replaced long ago already, as the layering violation hasn't been necessary for quite some time. (cherry picked from commit 8b6d55c1261820bb9db8d867ce9ee77397d05203) |
Jan Beulich <jbeulich@suse.com> | no | 2020-11-24 | ||
| 0042-x86-DMI-fix-table-mapping-when-one-lives-above-1Mb.patch | x86/DMI: fix table mapping when one lives above 1Mb Use of __acpi_map_table() is kind of an abuse here, and doesn't work anymore for the majority of cases if any of the tables lives outside the low first Mb. Keep this (ab)use only prior to reaching SYS_STATE_boot, primarily to avoid needing to audit whether any of the calls here can happen this early in the first place; quite likely this isn't necessary at all - at least dmi_scan_machine() gets called late enough. For the "normal" case, call __vmap() directly, despite effectively duplicating acpi_os_map_memory(). There's one difference though: We shouldn't need to establish UC- mappings, WP or r/o WB mappings ought to be fine, as the tables are going to live in either RAM or ROM. Short of having PAGE_HYPERVISOR_WP and wanting to map the tables r/o anyway, use the latter of the two options. The r/o mapping implies some constification of code elsewhere in the file. For code touched anyway also switch to void (where possible) or uint8_t. (cherry picked from commit f390941a92f102ebbbbce1b54be206a602187fd7) |
Jan Beulich <jbeulich@suse.com> | no | 2020-11-24 | ||
| 0043-x86-ACPI-fix-S3-wakeup-vector-mapping.patch | x86/ACPI: fix S3 wakeup vector mapping Use of __acpi_map_table() here was at least close to an abuse already before, but it will now consistently return NULL here. Drop the layering violation and use set_fixmap() directly. Re-use of the ACPI fixmap area is hopefully going to remain "fine" for the time being. Add checks to acpi_enter_sleep(): The vector now needs to be contained within a single page, but the ACPI spec requires 64-byte alignment of FACS anyway. Also bail if no wakeup vector was determined in the first place, in part as preparation for a subsequent relaxation change. (cherry picked from commit 0f089bbf43ecce6f27576cb548ba4341d0ec46a8) |
Jan Beulich <jbeulich@suse.com> | no | 2021-01-05 | ||
| 0044-x86-ACPI-don-t-invalidate-S5-data-when-S3-wakeup-vec.patch | x86/ACPI: don't invalidate S5 data when S3 wakeup vector cannot be determined We can be more tolerant as long as the data collected from FACS is only needed to enter S3. A prior change already added suitable checking to acpi_enter_sleep(). (cherry picked from commit 16ca5b3f873f17f4fbdaecf46c133e1aa3d623b2) |
Jan Beulich <jbeulich@suse.com> | no | 2021-01-05 |