> The I-pipe virtualizes all IOAPIC and ISA interrupts upon startup. Then,
> any code calling pci_msi_enable() would end up allocating a new MSI
> interrupt vector.
I see. So in fact, at least for the Linux domain, which indeed registers all
interrupts upon initialization, every newly created MSI vector should be
> > Currently it looks like every PCI config space access instruction in
> > read_msi_msg() (used to perform set_msi_irq_affinity) freezes the
> > machine. I have absolutely no clue yet why this happens.
> Wild trivial guess, is the irq parameter the expected one, since the
> rest depends on it?
You mean the one passed into xnarch_set_irq_affinity ? Yes, it is
consistently 219 and the mask is 0x3. In set_msi_irq_affinity(), the
associated vector is calculated as 225. I'm not sure the latter one is
correct, but at least it shouldn't freeze the machine upon a PCI config
Could there be any reason why e.g. a pci_config_read_dword() call would in
Xenomai context (because when still in the module probe code, I can perform
the call correctly - in both cases I checked the dev->bus->ops->read/write
pointers and they are identical) ?
Xenomai-core mailing list