On 11.12.2023 12:09, Sébastien Chaumat wrote: > Le lun. 11 déc. 2023 à 10:18, Sébastien Chaumat <euidz...@gmail.com> a écrit : >> >>> On 05.12.2023 21:31, Sébastien Chaumat wrote: >>>>> [ 2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt >>>> >>>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to >>>> ioapic-edge and IRQ9 to ioapic-level ? >>>> >>>> IR-IO-APIC 7-fasteoi pinctrl_amd >>>> IR-IO-APIC 9-fasteoi acpi >>>> >>>> to (xen 4.18.0) >>>> >>>> xen-pirq -ioapic-edge pinctrl_amd >>>> xen-pirq -ioapic-level acpi >>>> >>>> ? > > This look similar to > https://yhbt.net/lore/all/20201006044941.fdjsp346kc5thyzy@Rk/t/ > > This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi > (so level type) while in xen it is mapped to oapic-edge instead of > oapic-level > as the SSDT indicates : > > Device (GPIO) > > { > Name (_HID, "AMDI0030") // _HID: Hardware ID > Name (_CID, "AMDI0030") // _CID: Compatible ID > Name (_UID, Zero) // _UID: Unique ID > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Name (RBUF, ResourceTemplate () > { > Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) > { > 0x00000007, > } > Any idea why ?
Information coming from AML is required to be handed down by Dom0 to Xen. May want checking that (a) Dom0 properly does so and (b) Xen doesn't screw up in consuming that data. See PHYSDEVOP_setup_gsi. I wonder if this is specific to it being IRQ7 which GPIO uses, as at the (master) PIC IRQ7 is also the spurious vector. You may want to retry with the tip of the 4.17 branch (soon to become 4.17.3) - while it doesn't look very likely to me that recent backports there were related, it may still be that they make a difference. Jan
