I spotted the following warning for IRQ7 (along with IRQ6 and 10)
[ 0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type
function for IRQ 7 (IR-IO-APIC)
This comes from kernel/irq/manage.c
int __irq_set_trigger(struct irq_desc *desc, unsigned long flags)
{
struct irq_chip *chip = desc->irq_data.chip;
int ret, unmask = 0;
if (!chip || !chip->irq_set_type) {
/*
* IRQF_TRIGGER_* but the PIC does not support multiple
* flow-types?
*/
pr_debug("No set_type function for IRQ %d (%s)\n",
irq_desc_get_irq(desc),
chip ? (chip->name ? : "unknown") : "unknown");
return 0;
}
Could this have a role in the IRQ misconfiguration by xen ?
Le lun. 22 janv. 2024 à 21:59, Mario Limonciello <[email protected]>
a écrit :
> On 1/22/2024 11:06, Sébastien Chaumat wrote:
> >
> >
> > Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
> > <[email protected] <mailto:[email protected]>> a écrit :
> >
> > On 1/16/2024 10:18, Jan Beulich wrote:
> > > On 16.01.2024 16:52, Sébastien Chaumat wrote:
> > >> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat
> > <[email protected] <mailto:[email protected]>> a
> > >> écrit :
> > >>
> > >>>
> > >>> output of gpioinfo
> > >>>>
> > >>>> kernel alone :
> > >>>>
> > >>>> line 5: unnamed input active-low
> > consumer=interrupt
> > >>>> line 84: unnamed input active-low
> > consumer=interrupt
> > >>>>
> > >>>> xen:
> > >>>>
> > >>>> line 5: unnamed input active-low
> > >>>> line 84: unnamed input active-low
> > >>>>
> > >>>> xen with skipping IRQ7 double init :
> > >>>>
> > >>>> line 5: unnamed input active-low
> > consumer=interrupt
> > >>>> line 84: unnamed input active-low
> > >>>>
> > >>>>
> > >>>> So definitely progressing.
> > >>>>
> > >>>
> > >>> Checking /sys/kernel/irq/7
> > >>>
> > >>> kernel alone :
> > >>> actions: pinctrl_amd
> > >>> chip_name: IR-IO-APIC
> > >>> hwirq: 7
> > >>> name: fasteoi
> > >>> per_cpu_count: 0,0,0,0,0,20,0,0,0,0,0,0,0,0,0,0
> > >>> type: level
> > >>> wakeup: enabled
> > >>>
> > >>> xen skipping IRQ7 double init :
> > >>>
> > >>> actions: pinctrl_amd
> > >>> chip_name: xen-pirq
> > >>> hwirq:
> > >>> name: ioapic-level
> > >>> per_cpu_count: 0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0
> > >>> type: edge
> > >>> wakeup: disabled
> > >>>
> > >>> So the skip of IRQ7 in pci_xen_initial_domain() sets the
> > correct handler
> > >>> (IIUC xen uses the ioapic-level and handles the eoi
> > separately), but not
> > >>> the correct type (still edge).
> > >>> I guess this may explains the results above.
> > >>>
> > >>>
> > >> Mario (in CC) patched the pinctrl_amd to flush pending
> > interrupt before
> > >> starting the driver for the GPIO.
> > >>
> > >> This helped in the sense of there's no more pending interrupt
> > on IRQ7
> > >> (whatever the handler is, level or edge) but then the touchpad
> > is not
> > >> detected by i2c-hid.
> > >>
> > >> Is there any work in progress related to the incorrect IRQ
> > configuration ?
> > >
> > > I'm not aware of any. As per my recollection it's still not
> entirely
> > > clear where in the kernel things go astray. And to be honest I
> don't
> > > feel comfortable trying to half-blindly address this, e.g. by
> trying
> > > to circumvent / defer the early setting up of the low 16 IRQs.
> > >
> > > Jan
> >
> > Shot in the dark - but could this be a problem where PCAT_COMPAT from
> > the MADT is being ignored causing PIC not to be setup properly in the
> > Xen case?
> >
> > See https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/
> > <https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/> for some context.
> >
> > At least we know that no MADT override is found by xen for INT7 as no
> > INT_SRC_OVR message is printed.
> >
> > Do we expect one @Mario Limonciello <mailto:[email protected]>
> ?
>
> No; the INT_SRV_OVR you'll see on Framework 13 AMD is on IRQ 2 and IRQ 9.
>
>
