Created attachment 289919 [details] kernel log with patches as described. Restart failure with iommu error needs Intel i915 driver support. We found a restart failure issue on Tigerlake platform and after debugging, we need Intel to support with i915 driver. Reproduce Steps: 1.Suspend the system 2.press power button to wake up system 3.Restart the system 4.System will hang and can’t boot to user login screen. Fail Rate: 100% TGL platform OS: Ubuntu 20.04 Related kernel log: Jun 3 22:00:30 kernel: [ 117.686352] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) Jun 3 22:00:30 kernel: [ 117.690538] done. Jun 3 22:00:30 kernel: [ 117.712034] nvme nvme0: 8/0/0 default/read/poll queues Jun 3 22:00:30 kernel: [ 117.741473] PM: suspend exit Jun 3 22:00:39 kernel: [ 126.457779] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Jun 3 22:00:44 kernel: [ 132.024069] rfkill: input handler enabled Jun 3 22:00:45 kernel: [ 132.293626] sof-audio-pci 0000:00:1f.3: firmware boot complete The fan keeps running, and the only way to power off system is long pressing the power button. We also tried the kernel parameters below (3 tests) and the reboot failure cannot be reproduce: nomodeset i915.modeset=0 intel_iommu=igfx_off Based on Intel suggestion, we patched: Patch 1: https://patchwork.freedesktop.org/patch/355270/ Patch 2: https://patchwork.freedesktop.org/patch/365227/ Same as previous situation. System restart successfully but wait a long time to shutdown. The waiting point is still at iommu_disable_translation()@intel-iommu.c.
More observation: When we mark iommu_disable_translation()@intel-iommu.c, reboot is good and go into OS soon.
Created attachment 289955 [details] A test change
Can anybody help to test whether attached change help here?
We are checking and will update you.
@Lu Baolu, We test your test change on comment 2, the system would not stuck and can restart okay. May I know is there any side effect for this change? We found it also skip iommu as a workaround. Thank you for your effort.
@ Hsiao-Ting Wang I'm not sure about the side effect hence I need to do more tests before posting it to upstream. Thanks a lot for your test.
Can you also test kexec with the latest patch from Baolu?
@Ashok, What's different between install a kernel and kexec!? The waiting point is in kernel(iommu_disable_translation()@intel-iommu.c).
Is this possibly the same root cause as https://bugzilla.kernel.org/show_bug.cgi?id=206571 ?
(In reply to Hsiao-Ting Wang from comment #5) > @Lu Baolu, > We test your test change on comment 2, the system would not stuck and can > restart okay. > May I know is there any side effect for this change? > We found it also skip iommu as a workaround. > > Thank you for your effort. Can you please let me know the pci vendor/device ids of the integrated graphic device? Best regards, baolu
＠Baolu, It's a Intel's gpu(i915).
vendor id/device id = 0086:9a49
0086 isn't the vendor id for Intel. Can you please double check?
sorry my fault, correct the information vendor id/device id = 8086:9a49
@KobaKo since you're not in the CC list on https://bugzilla.kernel.org/show_bug.cgi?id=206571 there was a proposed patch. Can you see if it helps for the TGL case?
@Mario, Tried the patch and it doesn't work. The machine still hang on iommu_disable_translation()@intel-iommu.c.
Created attachment 290317 [details] A potential fix patch ask for test Hi, can anybody help to test the patch attached (A potential fix patch ask for test)? Best regards, baolu
＠Baolu, Could you explain more why gfx would be ignore to disable TE!?
@Kobako, I have explained in the commit message. Is that sufficient for you? I am not sure whether it's the root cause of the issue reported here, hence ask for some tests.
@Baolu, It's nice and the information is very detail in the patch. Thanks
@Baolu, With the test patch I tried the multiple times(around 6) and the machine(TGL) wouldn't hang during the shutdown and wouldn't wait a long time(*). *With the previous patch, the machine wouldn't hang but wait a long time to restart.
@Kobako, thanks for the testing. Can I add your test-by when I submit this patch to upstream linux kernel?
@Baolu, Can we reset the iommu during resume!? After the power state transition is triggered, is the dma translation in a corrupted status? if it is and you don't recover it, does dma translation work well in the following time!?
@Baolu, yes, please take it tested-by: koba.ko@canonical.com
@Baolu, Will you refine something in the patch!? Is the last patch you provided a final version!?
(In reply to KobaKo from comment #23) > @Baolu, > Can we reset the iommu during resume!? > After the power state transition is triggered, is the dma translation in a > corrupted status? if it is and you don't recover it, does dma translation > work well in the following time!? The same thing happens during iommu suspend/resume. https://bugzilla.kernel.org/show_bug.cgi?id=206571 The patch is aking for test for this issue.
(In reply to KobaKo from comment #25) > @Baolu, > Will you refine something in the patch!? Is the last patch you provided a > final version!? It should be if it passes the test for 206571. Do you have any review comments?
(In reply to Lu Baolu from comment #26) > (In reply to KobaKo from comment #23) > > @Baolu, > > Can we reset the iommu during resume!? > > After the power state transition is triggered, is the dma translation in a > > corrupted status? if it is and you don't recover it, does dma translation > > work well in the following time!? > > The same thing happens during iommu suspend/resume. > > https://bugzilla.kernel.org/show_bug.cgi?id=206571 > > The patch is aking for test for this issue. On my side, the issue must trigger the suspend before reboot, that means the iommu is in the corrupted status after suspend? Should we recover/reset the iommu that the machine comes from the suspend!?
@Baolu, Would you please share the official patch once you push it to upstream!? Thanks
sure! I will update here.
I put the patch into the current rawhide kernel (kernel-5.8.0-0.rc5.20200715gite9919e11e219) for a user, who currently has shutdown issues on his Dell XPS 9300 (Ice Lake IIRC), to test and they report that "Both shutdown and reboot are working."
@Baolu, what is the status of this issue?
It has been upstreamed. Is this issue still there?
Bug closed as the fix is already in upstream.