All of lore.kernel.org
 help / color / mirror / Atom feed
* Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
@ 2020-07-22  2:26 Miao, Jun
  2020-07-22  2:40   ` Lu Baolu
  0 siblings, 1 reply; 9+ messages in thread
From: Miao, Jun @ 2020-07-22  2:26 UTC (permalink / raw)
  To: baolu.lu; +Cc: iommu, linux-kernel, stable


[-- Attachment #1.1: Type: text/plain, Size: 10342 bytes --]

Hi Lu,  limonciello.

Yestoday i just verified the issue with the patch. and just iommu Subscription today.This is my test log.

[Hardware info]

 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz           1.20GHz
 ICLSFWR1.R00.3162.A00.1904162000
 BIOS Information

 BIOS Vendo Intel

       Core Version                     1.5.2.0 RP01
       Client Silicon Version           0.2.0.15
       Project Version                  ICLSFWR1.R00.3162.A00.1904162000
       Build Date                       20:00 04/16/2019

       Board Name                       IceLake U DDR4 SODIMM PD RVP TLC

       Processor Information
       Name                             IceLake UL

[S3(mem) failed]

$ echo deep > /sys/power/mem_sleep

$ rtcwake -m mem -s 10

ACPI: EC: interrupt blocked
e1000e 0000:00:1f.6: pci_pm_suspend_noirq+0x0/0x250 returned 0 after 14317
usecs
ec PNP0C09:00: acpi_ec_suspend_noirq+0x0/0x50 returned 0 after 355319 usecs
wdat_wdt wdat_wdt: calling wdat_wdt_suspend_noirq+0x0/0x66 [wdat_wdt] @ 347,
parent: platform
ahci 0000:00:17.0: pci_pm_suspend_noirq+0x0/0x250 returned 0 after 383843
usecs
intel-lpss 0000:00:1e.3: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
384062 usecs
wdat_wdt wdat_wdt: wdat_wdt_suspend_noirq+0x0/0x66 [wdat_wdt] returned 0
after 11 usecs
intel-lpss 0000:00:1e.0: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
414466 usecs
xhci_hcd 0000:00:14.0: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
414023 usecs
sdhci-pci 0000:00:14.5: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
429325 usecs
pcieport 0000:00:07.3: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
429026 usecs
pcieport 0000:00:07.1: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
429675 usecs
pcieport 0000:00:07.2: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
430309 usecs
pcieport 0000:00:07.0: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
430213 usecs
thunderbolt 0000:00:0d.2: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
432523 usecs
thunderbolt 0000:00:0d.3: pci_pm_suspend_noirq+0x0/0x250 returned 0 after
432815 usecs
ACPI: Preparing to enter system sleep state S3
ACPI: EC: event blocked
ACPI: EC: EC stopped
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
smpboot: CPU 1 is now offline
smpboot: CPU 2 is now offline
smpboot: CPU 3 is now offline
smpboot: CPU 4 is now offline
smpboot: CPU 5 is now offline
smpboot: CPU 6 is now offline
smpboot: CPU 7 is now offline
PM: Calling mce_syscore_suspend+0x0/0x20
PM: Calling nmi_suspend+0x0/0x20
PM: Calling timekeeping_suspend+0x0/0x2d0
PM: Calling save_ioapic_entries+0x0/0x90
PM: Calling i8259A_suspend+0x0/0x30
PM: Calling iommu_suspend+0x0/0x1b0
Kernel panic - not syncing: DMAR hardware is malfunctioning
CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4
SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
Call Trace:
  dump_stack+0x59/0x75
  panic+0xff/0x2d4
  iommu_disable_translation+0x88/0x90
  iommu_suspend+0x12f/0x1b0
  syscore_suspend+0x6c/0x220
  suspend_devices_and_enter+0x313/0x840
  pm_suspend+0x30d/0x390
  state_store+0x82/0xf0
  kobj_attr_store+0x12/0x20
  sysfs_kf_write+0x3c/0x50
  kernfs_fop_write+0x11d/0x190
  __vfs_write+0x1b/0x40
  vfs_write+0xc6/0x1d0
  ksys_write+0x5e/0xe0
  __x64_sys_write+0x1a/0x20
  do_syscall_64+0x4d/0x150
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f97b8080113
Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00
64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff
77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---

[S3 successfully with the patch]

sh-5.0# uname -a
Linux intel-x86-64 5.8.0-rc6-yoctodev-standard+ #128 SMP PREEMPT Tue Jul 21 12:14:39 CST 2020 x86_64 x86_64 x86_64 GNU/Linux
sh-5.0#

sh-5.0# lsmod |grep -i thunderbolt
intel_wmi_thunderbolt    16384  0
thunderbolt           167936  0
wmi                    24576  2 intel_wmi_thunderbolt,wmi_bmof
sh-5.0#
sh-5.0#
sh-5.0#
sh-5.0# modinfo thunderbolt
filename: /lib/modules/5.8.0-rc6-yoctodev-standard+/kernel/drivers/thunderbolt/thunderbolt.ko
license:        GPL
alias:          pci:v*d*sv*sd*bc0Csc03i40*
alias:          pci:v00008086d00009A1Dsv*sd*bc*sc*i*
alias:          pci:v00008086d00009A1Bsv*sd*bc*sc*i*
alias:          pci:v00008086d00008A0Dsv*sd*bc*sc*i*
alias:          pci:v00008086d00008A17sv*sd*bc*sc*i*
alias:          pci:v00008086d000015EBsv*sd*bc*sc*i*
alias:          pci:v00008086d000015E8sv*sd*bc*sc*i*
alias:          pci:v00008086d000015DEsv*sd*bc*sc*i*
alias:          pci:v00008086d000015D2sv*sd*bc*sc*i*
alias:          pci:v00008086d000015D9sv*sd*bc*sc*i*
alias:          pci:v00008086d000015DCsv*sd*bc*sc*i*
alias:          pci:v00008086d000015BFsv*sd*bc*sc*i*
alias:          pci:v00008086d000015DDsv*sd*bc*sc*i*
alias:          pci:v00008086d00001577sv*sd*bc*sc*i*
alias:          pci:v00008086d00001575sv*sd*bc*sc*i*
alias:          pci:v00008086d0000156Csv*sd*bc08sc80i00*
alias:          pci:v00008086d0000156Asv*sd*bc08sc80i00*
alias: pci:v00008086d00001547sv00002222sd00001111bc08sc80i00*
alias: pci:v00008086d00001513sv00002222sd00001111bc08sc80i00*
depends:
retpoline:      Y
intree:         Y
name:           thunderbolt
vermagic:       5.8.0-rc6-yoctodev-standard+ SMP preempt mod_unload
parm:           start_icm:start ICM firmware if it is not running (default: false) (bool)
sh-5.0#
sh-5.0#
sh-5.0# echo deep  > /sys/power/mem_sleep
sh-5.0#
sh-5.0# rtcwake -m mem -s 10
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Mon Jul 20 21:13:04 2020
PM: suspend entry (deep)
Filesystems sync: 0.000 seconds
Freezing user space processes ... (elapsed 0.014 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
input input14: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input14: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input13: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input13: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input12: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input12: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input11: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input11: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input10: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input10: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input9: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input9: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input8: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input8: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input7: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0
input input7: input_dev_suspend+0x0/0x40 returned 0 after 0 usecs
input input6: calling input_dev_suspend+0x0/0x40 @ 310, parent: card0

... ...

input input13: input_dev_resume+0x0/0x40 returned 0 after 0 usecs
input input14: calling input_dev_resume+0x0/0x40 @ 310, parent: card0
input input14: input_dev_resume+0x0/0x40 returned 0 after 0 usecs
atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
e1000e 0000:00:1f.6: pci_pm_resume+0x0/0x90 returned 0 after 1003573 usecs
atkbd serio0: Failed to enable keyboard on isa0060/serio0
acpi LNXPOWER:03: Turning OFF
OOM killer enabled.
Restarting tasks ...
systemd-journald[174]: /dev/kmsg buffer overrun, some messages lost.
done.
PM: suspend exit
e1000e 0000:00:1f.6 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
e1000e 0000:00:1f.6 eth0: 10/100 speed: disabling TSO
sh-5.0#
sh-5.0#



[EXTERNAL EMAIL]
>
> Hi Limonciello,
>
> On 7/21/20 10:44 PM, Limonciello, Mario wrote:
> >> -----Original Message-----
> >> From: iommu<iommu-bounces@lists.linux-foundation.org>  On Behalf Of Lu
> >> Baolu
> >> Sent: Monday, July 20, 2020 7:17 PM
> >> To: Joerg Roedel
> >> Cc: Ashok Raj;linux-kernel@vger.kernel.org;stable@vger.kernel.org; Koba
> >> Ko;iommu@lists.linux-foundation.org
> >> Subject: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated
> >> iommu
> >>
> >> The VT-d spec requires (10.4.4 Global Command Register, TE field) that:
> >>
> >> Hardware implementations supporting DMA draining must drain any in-flight
> >> DMA read/write requests queued within the Root-Complex before completing
> >> the translation enable command and reflecting the status of the command
> >> through the TES field in the Global Status register.
> >>
> >> Unfortunately, some integrated graphic devices fail to do so after some
> >> kind of power state transition. As the result, the system might stuck in
> >> iommu_disable_translation(), waiting for the completion of TE transition.
> >>
> >> This provides a quirk list for those devices and skips TE disabling if
> >> the qurik hits.
> >>
> >> Fixes:https://bugzilla.kernel.org/show_bug.cgi?id=208363
> > That one is for TGL.
> >
> > I think you also want to add this one for ICL:
> > Fixes:https://bugzilla.kernel.org/show_bug.cgi?id=206571
> >
>
> Do you mean someone have tested that this patch also fixes the problem
> described in 206571?
>

Yes, confusingly https://bugzilla.kernel.org/show_bug.cgi?id=208363#c31 actually
is the XPS 9300 ICL system and issue.

I also have a private confirmation from another person that it resolves it for
them on another ICL platform.

Christian, maybe you can add a tested by clause for the ICL testing.


[-- Attachment #1.2: Type: text/html, Size: 58911 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
  2020-07-22  2:26 Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu Miao, Jun
@ 2020-07-22  2:40   ` Lu Baolu
  0 siblings, 0 replies; 9+ messages in thread
From: Lu Baolu @ 2020-07-22  2:40 UTC (permalink / raw)
  To: Miao, Jun; +Cc: baolu.lu, linux-kernel, iommu, stable

Hi Jun,

On 7/22/20 10:26 AM, Miao, Jun wrote:
>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4
>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>> Call Trace:
>>>    dump_stack+0x59/0x75
>>>    panic+0xff/0x2d4
>>>    iommu_disable_translation+0x88/0x90
>>>    iommu_suspend+0x12f/0x1b0
>>>    syscore_suspend+0x6c/0x220
>>>    suspend_devices_and_enter+0x313/0x840
>>>    pm_suspend+0x30d/0x390
>>>    state_store+0x82/0xf0
>>>    kobj_attr_store+0x12/0x20
>>>    sysfs_kf_write+0x3c/0x50
>>>    kernfs_fop_write+0x11d/0x190
>>>    __vfs_write+0x1b/0x40
>>>    vfs_write+0xc6/0x1d0
>>>    ksys_write+0x5e/0xe0
>>>    __x64_sys_write+0x1a/0x20
>>>    do_syscall_64+0x4d/0x150
>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> RIP: 0033:0x7f97b8080113
>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00
>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff
>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>> 0xffffffff80000000-0xffffffffbfffffff)
>>> ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
>

Do you mean that system hangs in iommu_disable_translation() without 
this fix.

> [S3 successfully with the patch]

And, this failure disappeared after you applied this fix?

Best regards,
baolu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
@ 2020-07-22  2:40   ` Lu Baolu
  0 siblings, 0 replies; 9+ messages in thread
From: Lu Baolu @ 2020-07-22  2:40 UTC (permalink / raw)
  To: Miao, Jun; +Cc: iommu, linux-kernel, stable

Hi Jun,

On 7/22/20 10:26 AM, Miao, Jun wrote:
>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4
>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>> Call Trace:
>>>    dump_stack+0x59/0x75
>>>    panic+0xff/0x2d4
>>>    iommu_disable_translation+0x88/0x90
>>>    iommu_suspend+0x12f/0x1b0
>>>    syscore_suspend+0x6c/0x220
>>>    suspend_devices_and_enter+0x313/0x840
>>>    pm_suspend+0x30d/0x390
>>>    state_store+0x82/0xf0
>>>    kobj_attr_store+0x12/0x20
>>>    sysfs_kf_write+0x3c/0x50
>>>    kernfs_fop_write+0x11d/0x190
>>>    __vfs_write+0x1b/0x40
>>>    vfs_write+0xc6/0x1d0
>>>    ksys_write+0x5e/0xe0
>>>    __x64_sys_write+0x1a/0x20
>>>    do_syscall_64+0x4d/0x150
>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> RIP: 0033:0x7f97b8080113
>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00
>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff
>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>> 0xffffffff80000000-0xffffffffbfffffff)
>>> ---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
>

Do you mean that system hangs in iommu_disable_translation() without 
this fix.

> [S3 successfully with the patch]

And, this failure disappeared after you applied this fix?

Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
  2020-07-22  2:40   ` Lu Baolu
@ 2020-07-22  3:03     ` Jun Miao
  -1 siblings, 0 replies; 9+ messages in thread
From: Jun Miao @ 2020-07-22  3:03 UTC (permalink / raw)
  To: Lu Baolu; +Cc: linux-kernel, iommu, stable

On 7/22/20 10:40 AM, Lu Baolu wrote:
> Hi Jun,
>
> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U 
>>>> DDR4
>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>> Call Trace:
>>>>    dump_stack+0x59/0x75
>>>>    panic+0xff/0x2d4
>>>>    iommu_disable_translation+0x88/0x90
>>>>    iommu_suspend+0x12f/0x1b0
>>>>    syscore_suspend+0x6c/0x220
>>>>    suspend_devices_and_enter+0x313/0x840
>>>>    pm_suspend+0x30d/0x390
>>>>    state_store+0x82/0xf0
>>>>    kobj_attr_store+0x12/0x20
>>>>    sysfs_kf_write+0x3c/0x50
>>>>    kernfs_fop_write+0x11d/0x190
>>>>    __vfs_write+0x1b/0x40
>>>>    vfs_write+0xc6/0x1d0
>>>>    ksys_write+0x5e/0xe0
>>>>    __x64_sys_write+0x1a/0x20
>>>>    do_syscall_64+0x4d/0x150
>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>> RIP: 0033:0x7f97b8080113
>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>> 0f 1f 00
>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
>>>> f0 ff ff
>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>> malfunctioning ]---
>>
>
> Do you mean that system hangs in iommu_disable_translation() without 
> this fix.
>
Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
without this patch.
>> [S3 successfully with the patch]
>
> And, this failure disappeared after you applied this fix?
>
> Best regards,
> baolu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
@ 2020-07-22  3:03     ` Jun Miao
  0 siblings, 0 replies; 9+ messages in thread
From: Jun Miao @ 2020-07-22  3:03 UTC (permalink / raw)
  To: Lu Baolu; +Cc: iommu, linux-kernel, stable

On 7/22/20 10:40 AM, Lu Baolu wrote:
> Hi Jun,
>
> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U 
>>>> DDR4
>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>> Call Trace:
>>>>    dump_stack+0x59/0x75
>>>>    panic+0xff/0x2d4
>>>>    iommu_disable_translation+0x88/0x90
>>>>    iommu_suspend+0x12f/0x1b0
>>>>    syscore_suspend+0x6c/0x220
>>>>    suspend_devices_and_enter+0x313/0x840
>>>>    pm_suspend+0x30d/0x390
>>>>    state_store+0x82/0xf0
>>>>    kobj_attr_store+0x12/0x20
>>>>    sysfs_kf_write+0x3c/0x50
>>>>    kernfs_fop_write+0x11d/0x190
>>>>    __vfs_write+0x1b/0x40
>>>>    vfs_write+0xc6/0x1d0
>>>>    ksys_write+0x5e/0xe0
>>>>    __x64_sys_write+0x1a/0x20
>>>>    do_syscall_64+0x4d/0x150
>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>> RIP: 0033:0x7f97b8080113
>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>> 0f 1f 00
>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
>>>> f0 ff ff
>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>> malfunctioning ]---
>>
>
> Do you mean that system hangs in iommu_disable_translation() without 
> this fix.
>
Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
without this patch.
>> [S3 successfully with the patch]
>
> And, this failure disappeared after you applied this fix?
>
> Best regards,
> baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
  2020-07-22  3:03     ` Jun Miao
@ 2020-07-22  3:07       ` Lu Baolu
  -1 siblings, 0 replies; 9+ messages in thread
From: Lu Baolu @ 2020-07-22  3:07 UTC (permalink / raw)
  To: Jun Miao; +Cc: baolu.lu, linux-kernel, iommu, stable

On 7/22/20 11:03 AM, Jun Miao wrote:
> On 7/22/20 10:40 AM, Lu Baolu wrote:
>> Hi Jun,
>>
>> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U 
>>>>> DDR4
>>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>>> Call Trace:
>>>>>    dump_stack+0x59/0x75
>>>>>    panic+0xff/0x2d4
>>>>>    iommu_disable_translation+0x88/0x90
>>>>>    iommu_suspend+0x12f/0x1b0
>>>>>    syscore_suspend+0x6c/0x220
>>>>>    suspend_devices_and_enter+0x313/0x840
>>>>>    pm_suspend+0x30d/0x390
>>>>>    state_store+0x82/0xf0
>>>>>    kobj_attr_store+0x12/0x20
>>>>>    sysfs_kf_write+0x3c/0x50
>>>>>    kernfs_fop_write+0x11d/0x190
>>>>>    __vfs_write+0x1b/0x40
>>>>>    vfs_write+0xc6/0x1d0
>>>>>    ksys_write+0x5e/0xe0
>>>>>    __x64_sys_write+0x1a/0x20
>>>>>    do_syscall_64+0x4d/0x150
>>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>> RIP: 0033:0x7f97b8080113
>>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>>> 0f 1f 00
>>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
>>>>> f0 ff ff
>>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>>> malfunctioning ]---
>>>
>>
>> Do you mean that system hangs in iommu_disable_translation() without 
>> this fix.
>>
> Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
> without this patch.

Okay! Thanks a lot for confirming this.

Best regards,
baolu

>>> [S3 successfully with the patch]
>>
>> And, this failure disappeared after you applied this fix?
>>
>> Best regards,
>> baolu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
@ 2020-07-22  3:07       ` Lu Baolu
  0 siblings, 0 replies; 9+ messages in thread
From: Lu Baolu @ 2020-07-22  3:07 UTC (permalink / raw)
  To: Jun Miao; +Cc: iommu, linux-kernel, stable

On 7/22/20 11:03 AM, Jun Miao wrote:
> On 7/22/20 10:40 AM, Lu Baolu wrote:
>> Hi Jun,
>>
>> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U 
>>>>> DDR4
>>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>>> Call Trace:
>>>>>    dump_stack+0x59/0x75
>>>>>    panic+0xff/0x2d4
>>>>>    iommu_disable_translation+0x88/0x90
>>>>>    iommu_suspend+0x12f/0x1b0
>>>>>    syscore_suspend+0x6c/0x220
>>>>>    suspend_devices_and_enter+0x313/0x840
>>>>>    pm_suspend+0x30d/0x390
>>>>>    state_store+0x82/0xf0
>>>>>    kobj_attr_store+0x12/0x20
>>>>>    sysfs_kf_write+0x3c/0x50
>>>>>    kernfs_fop_write+0x11d/0x190
>>>>>    __vfs_write+0x1b/0x40
>>>>>    vfs_write+0xc6/0x1d0
>>>>>    ksys_write+0x5e/0xe0
>>>>>    __x64_sys_write+0x1a/0x20
>>>>>    do_syscall_64+0x4d/0x150
>>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>> RIP: 0033:0x7f97b8080113
>>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>>> 0f 1f 00
>>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
>>>>> f0 ff ff
>>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
>>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>>> malfunctioning ]---
>>>
>>
>> Do you mean that system hangs in iommu_disable_translation() without 
>> this fix.
>>
> Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
> without this patch.

Okay! Thanks a lot for confirming this.

Best regards,
baolu

>>> [S3 successfully with the patch]
>>
>> And, this failure disappeared after you applied this fix?
>>
>> Best regards,
>> baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
  2020-07-22  3:07       ` Lu Baolu
@ 2020-07-22  3:17         ` Jun Miao
  -1 siblings, 0 replies; 9+ messages in thread
From: Jun Miao @ 2020-07-22  3:17 UTC (permalink / raw)
  To: Lu Baolu; +Cc: linux-kernel, iommu, stable

On 7/22/20 11:07 AM, Lu Baolu wrote:
> On 7/22/20 11:03 AM, Jun Miao wrote:
>> On 7/22/20 10:40 AM, Lu Baolu wrote:
>>> Hi Jun,
>>>
>>> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake 
>>>>>> U DDR4
>>>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>>>> Call Trace:
>>>>>>    dump_stack+0x59/0x75
>>>>>>    panic+0xff/0x2d4
>>>>>>    iommu_disable_translation+0x88/0x90
>>>>>>    iommu_suspend+0x12f/0x1b0
>>>>>>    syscore_suspend+0x6c/0x220
>>>>>>    suspend_devices_and_enter+0x313/0x840
>>>>>>    pm_suspend+0x30d/0x390
>>>>>>    state_store+0x82/0xf0
>>>>>>    kobj_attr_store+0x12/0x20
>>>>>>    sysfs_kf_write+0x3c/0x50
>>>>>>    kernfs_fop_write+0x11d/0x190
>>>>>>    __vfs_write+0x1b/0x40
>>>>>>    vfs_write+0xc6/0x1d0
>>>>>>    ksys_write+0x5e/0xe0
>>>>>>    __x64_sys_write+0x1a/0x20
>>>>>>    do_syscall_64+0x4d/0x150
>>>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>>> RIP: 0033:0x7f97b8080113
>>>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>>>> 0f 1f 00
>>>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 
>>>>>> 00 f0 ff ff
>>>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 
>>>>>> 0000000000000001
>>>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>>>> malfunctioning ]---
>>>>
>>>
>>> Do you mean that system hangs in iommu_disable_translation() without 
>>> this fix.
>>>
>> Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
>> without this patch.
>
> Okay! Thanks a lot for confirming this.
>
> Best regards,
> baolu
>
>>>> [S3 successfully with the patch]
>>>
>>> And, this failure disappeared after you applied this fix?
YES     , the log is too long , only head and tail . this failure 
disappereared.
>>>
>>> Best regards,
>>> baolu

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu
@ 2020-07-22  3:17         ` Jun Miao
  0 siblings, 0 replies; 9+ messages in thread
From: Jun Miao @ 2020-07-22  3:17 UTC (permalink / raw)
  To: Lu Baolu; +Cc: iommu, linux-kernel, stable

On 7/22/20 11:07 AM, Lu Baolu wrote:
> On 7/22/20 11:03 AM, Jun Miao wrote:
>> On 7/22/20 10:40 AM, Lu Baolu wrote:
>>> Hi Jun,
>>>
>>> On 7/22/20 10:26 AM, Miao, Jun wrote:
>>>>>> Kernel panic - not syncing: DMAR hardware is malfunctioning
>>>>>> CPU: 0 PID: 347 Comm: rtcwake Not tainted 5.4.0-yocto-standard #124
>>>>>> Hardware name: Intel Corporation Ice Lake Client Platform/IceLake 
>>>>>> U DDR4
>>>>>> SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3162.A00.1904162000 04/16/2019
>>>>>> Call Trace:
>>>>>>    dump_stack+0x59/0x75
>>>>>>    panic+0xff/0x2d4
>>>>>>    iommu_disable_translation+0x88/0x90
>>>>>>    iommu_suspend+0x12f/0x1b0
>>>>>>    syscore_suspend+0x6c/0x220
>>>>>>    suspend_devices_and_enter+0x313/0x840
>>>>>>    pm_suspend+0x30d/0x390
>>>>>>    state_store+0x82/0xf0
>>>>>>    kobj_attr_store+0x12/0x20
>>>>>>    sysfs_kf_write+0x3c/0x50
>>>>>>    kernfs_fop_write+0x11d/0x190
>>>>>>    __vfs_write+0x1b/0x40
>>>>>>    vfs_write+0xc6/0x1d0
>>>>>>    ksys_write+0x5e/0xe0
>>>>>>    __x64_sys_write+0x1a/0x20
>>>>>>    do_syscall_64+0x4d/0x150
>>>>>>    entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>>>>> RIP: 0033:0x7f97b8080113
>>>>>> Code: 8b 15 81 bd 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 
>>>>>> 0f 1f 00
>>>>>> 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 
>>>>>> 00 f0 ff ff
>>>>>> 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
>>>>>> RSP: 002b:00007ffcfa6f48b8 EFLAGS: 00000246 ORIG_RAX: 
>>>>>> 0000000000000001
>>>>>> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f97b8080113
>>>>>> RDX: 0000000000000004 RSI: 000055e7db03b700 RDI: 0000000000000004
>>>>>> RBP: 000055e7db03b700 R08: 000055e7db03b700 R09: 0000000000000004
>>>>>> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000004
>>>>>> R13: 000055e7db039380 R14: 0000000000000004 R15: 00007f97b814d700
>>>>>> Kernel Offset: 0x38a00000 from 0xffffffff81000000 (relocation range:
>>>>>> 0xffffffff80000000-0xffffffffbfffffff)
>>>>>> ---[ end Kernel panic - not syncing: DMAR hardware is 
>>>>>> malfunctioning ]---
>>>>
>>>
>>> Do you mean that system hangs in iommu_disable_translation() without 
>>> this fix.
>>>
>> Yes ,From the call trace and i also read the DMARD_GCMD_RGS is wrong 
>> without this patch.
>
> Okay! Thanks a lot for confirming this.
>
> Best regards,
> baolu
>
>>>> [S3 successfully with the patch]
>>>
>>> And, this failure disappeared after you applied this fix?
YES     , the log is too long , only head and tail . this failure 
disappereared.
>>>
>>> Best regards,
>>> baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-07-22 10:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-22  2:26 Subject: Re: [PATCH 1/1] iommu/vt-d: Skip TE disabling on quirky gfx dedicated iommu Miao, Jun
2020-07-22  2:40 ` Lu Baolu
2020-07-22  2:40   ` Lu Baolu
2020-07-22  3:03   ` Jun Miao
2020-07-22  3:03     ` Jun Miao
2020-07-22  3:07     ` Lu Baolu
2020-07-22  3:07       ` Lu Baolu
2020-07-22  3:17       ` Jun Miao
2020-07-22  3:17         ` Jun Miao

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.