On 3/6/2024 14:34, Sébastien Chaumat wrote:
Le mer. 6 mars 2024 à 19:51, Mario Limonciello
<mario.limoncie...@amd.com <mailto:mario.limoncie...@amd.com>> a écrit :
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>
<mailto: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>>
> <mailto: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>>
> >
>
<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
<https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py>
in the hypervisor to find out what's wrong.
It fails with xen (not bare metal) during the prerequisite tests :
The script might need some modifications for tests that don't make sense
in the context of Xen.
✅ GPIO driver `pinctrl_amd` available
Traceback (most recent call last):
File "/home/sch/Downloads/amd_s2idle.py", line 2447, in <module>
test = app.prerequisites()
^^^^^^^^^^^^^^^^^^^
File "/home/sch/Downloads/amd_s2idle.py", line 1938, in prerequisites
if not check():
^^^^^^^
File "/home/sch/Downloads/amd_s2idle.py", line 826, in check_msr
val = read_msr(reg, 0)
^^^^^^^^^^^^^^^^
File "/home/sch/Downloads/amd_s2idle.py", line 813, in read_msr
val = struct.unpack("Q", os.read(f, 8))[0]
^^^^^^^^^^^^^
OSError: [Errno 5] Input/output error
Last line in the log is :
2024-03-06 21:29:33,146 DEBUG: Lockdown: [none] integrity confidentiality
Do you have userspace MSR support compiled in? If not; that could
explain that problem. But it's very unlikely you changed the MSRs.
For the purpose of finding where the suspend problem is, I'd comment out
that specific check for now.
