[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD
On 3/6/2024 12:49, Sébastien Chaumat wrote:
>
>
> Le mer. 6 mars 2024 à 19:08, Mario Limonciello
> <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>> a écrit :
>
> On 3/6/2024 12:05, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 6 mars 2024 à 18:33, Mario Limonciello
> > <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>
> <mailto:mario.limonciello@xxxxxxx
> <mailto:mario.limonciello@xxxxxxx>>> 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.
It fails with xen (not bare metal) during the prerequisite tests :
✅ 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
|
