I put "*ERROR* Failed to wait for idle; VT'd may hang" into a search engine and found the following:
Second result was https://bugs.archlinux.org/task/65362 which said: "The change to CONFIG_INTEL_IOMMU_DEFAULT_ON=yes on 5.5.1.arch1-1 causes random system freezes" and a possible workaround is: "Adding intel_iommu=off or intel_iommu=igfx_off seem to solve the issue" (seems more like hiding to me though) and mentioned a potential upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=197029 I didn't read them all, but seems various people are affected. Comment 21, dd 2020-02-03 by Lu Baolu, mentioned the commit that seems to have caused it: commit 422eac3f7deae34dbaffd08e03e27f37a5394a56 Author: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> Date: Tue Apr 19 12:54:18 2016 +0300 tpm_crb: fix mapping of the buffers Comment 30 is an attempt at a revert of 422eac3f7, but seems not to be the fix. That bug report ends/stalls (at msg #31) at the point where the request is made to forward it to linux-integrity ML, which results in https:// lore.kernel.org/linux-integrity/06299499-45d0-23e7-45da-7dbe71ff7...@gmail.com/ To which the single response by Jarkko is: "This a bit out of my scope albeit concerns TPM." And IOMMU list was CC-ed https://lists.linuxfoundation.org/pipermail/iommu/2020-September/ thread.html#48894 did not receive a reply ... Searching for "intel_iommu=on breaks resume from suspend site:https:// lists.linuxfoundation.org/pipermail/iommu/" oddly enough doesn't return the mail from September 2020 ... There is a Debian patch related to IOMMU, but I'm highly doubtful it is relevant to the cause of this issue as many OS's have come by in my searches. debian/patches/features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by- default.patch as a fix for https://bugs.debian.org/935270 Putting "intel_iommu=on breaks resume from suspend" in a search engine gave https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024383.html which indicates this problem has been present since kernel 4.13 and references the earlier mentioned https://bugzilla.kernel.org/show_bug.cgi?id=197029 It also has this 'interesting' tidbit: ==================================================== > has it worked ever with intel_iommu=on? Good point. I just tested that by rolling back to 4.12.13-1 and manually activating `intel_iommu=on`. As expected, no, resume is similarly broken. `intel_iommu={on, igfx_on}` probably have been breaking resume for a long time on my system, I just happened to notice it now due to being `on` by default. ==================================================== Summary: It seems to me that quite a few people are affected by this. It also seems to exist for quite some years and brought to 'light' for many people when IOMMU got enabled by default. (and virtualization becoming popular?) https://bugzilla.kernel.org/show_bug.cgi?id=197029 looked the most promising, but the not unreasonable request to forward it to the IOMMU mailing list seems to have stalled/ended any progress on it as *in my search* I didn't find any follow up. But my search may be at fault as it didn't find the 2020-09 msg ... HTH (a bit), Diederik Honorable mention for this one (from 2009-04-10): http://lkml.iu.edu/hypermail/linux/kernel/0904.1/01834.html "RE: 2.6.29: can't resume from suspend with DMAR (intel iommu)enabled" I don't know if it's relevant, but the title and reference to kernel 2.6.29 caught my eye ;) (and DMAR is mentioned in the Debian patch)
signature.asc
Description: This is a digitally signed message part.
