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>> 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>).
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?
