On 3/6/2024 12:49, Sébastien Chaumat wrote:


Le mer. 6 mars 2024 à 19:08, Mario Limonciello <mario.limoncie...@amd.com <mailto:mario.limoncie...@amd.com>> a écrit :

    On 3/6/2024 12:05, Sébastien Chaumat wrote:
     >
     >
     > Le mer. 6 mars 2024 à 18:33, Mario Limonciello
     > <mario.limoncie...@amd.com <mailto:mario.limoncie...@amd.com>
    <mailto:mario.limoncie...@amd.com
    <mailto:mario.limoncie...@amd.com>>> a écrit :
     >
     >     On 3/6/2024 11:28, Sébastien Chaumat wrote:
     >      >
     >      >
     >      >
     >      >
     >      >     Reasoning backward  (using a  kernel without the
    pinctrl_amd
     >     driver
     >      >     to ensure xen only is at stake) :
     >      >       checking the diff in IOAPIC  between bare metal and xen
     >     (IRQ7 is
     >      >     on pin07 on APIC )
     >      >
     >      >     using kernel argument : apic=debug
     >      >
     >      >     bare metal :
     >      >     [    0.715330] fedora kernel: ... APIC VERSION: 81050010
     >      >     ...
     >      >     [    0.715433] fedora kernel:  pin07, disabled, edge ,
    high,
     >     V(00),
     >      >     IRR(0), S(0), physical, D(0000), M(0)
     >      >
     >      >     xen :
     >      >     [    2.249582] fedora kernel: ... APIC VERSION: 00000014
     >      >     ...
     >      >     [    2.249730] fedora kernel:  pin07, disabled, level,
    low ,
     >     V(60),
     >      >     IRR(0), S(0), physical, D(0000), M(0)
     >      >
     >      >     So the APIC table is not the same.
     >      >
     >      >     As strange as it looks the  (IOAPIC 0) pin07 is correctly
     >     described
     >      >     by the APIC in xen but yet differently than in baremetal.
     >      >     But the APIC message comes long after the
     >      >     [    1.833145] fedora kernel: xen: registering gsi 7
    triggering 0
     >      >     polarity 1
     >      >
     >      >     so I wonder if the APIC pin07 info had any influence.
     >      >
     >      > Finally found the fix : adding ioapic_ack=new to xen boot
    parameters.
     >      > Not only the trackpad is now working but also the ACPI
    Embedded
     >      > Controller which is completely disabled.
     >      >
     >      > Sébastien
     >      >
     >     That's great news!  I'm personally totally unfamiliar with
     >     ioapic_ack=new, so I did a quick search and found out it's a Xen
     >     parameter (I came across
     >
    https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html
    <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>
>  <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html <https://xenbits.xen.org/docs/4.5-testing/misc/xen-command-line.html>>).
     >
     >     This mentions that "new" should be the default, so why isn't
    it the
     >     case?
     >
     >
     >   "This is the the default unless directed-EOI is supported"
     > xl dmesg without forcing the parameters shows :
     >
     > (XEN) Enabled directed EOI with ioapic_ack_old on!

    Got it; it sounds to me like a logic mismatch in Xen then.

     >
     >     Also; I'd be really interested to hear what happens with
    s2idle with
     >     Xen
     >     now (if it works).
     >
     >
     > suspend to RAM now works :)

    Do you see /sys/power/suspend_stats/last_hw_sleep increasing with your
    suspend cycle?


No,  it does not increase (0).


OK, then in that case I suggest you run https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py in the hypervisor to find out what's wrong.


Reply via email to