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.sakkinen@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-7dbe71ff7a53@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)
Attachment:
signature.asc
Description: This is a digitally signed message part.