[Xenomai-core] About Xenomai test framework and publishing
Hi all, FYI: as I mentioned to Philippe yesterday, the initiative concerning Xenomai test framework and test campaign in order to publish results on our website is not dead! Unfortunately my Xenomai bandwidth is limited and it is not going very fast :/ I worked on it during the past few days and I am currently finishing implementing a quick and dirty tcl script that will allow to generate automatically gnuplot diagrams from the latency test results. I am jointly working on another script to automatically determine static memory overhead induced by Xenomai. Nothing complicated, just a way to automate compilation process of a kernel with and without Xenomai to determine the overhead. I plan to edit a wiki page soon in order to give some ideas about what this framework could be and also to summarize the different ideas that will hopefully be raised on the mailing list from discussions about this topic. I will take the risk to make suggestions first to produce the first draft, you'll have the right to shoot when I'm finished ;) I should be back within a week to give you some more news about it. Cheers! -- Bruno Rouchouse [EMAIL PROTECTED] ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails
> > 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 revirtualized. > > 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 read. 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) ? Jeroen. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails
Jeroen Van den Keybus wrote: > > arch_setup_msi_irq() creates an IRQ on-the-fly from the current > descriptor which is being converted to an MSI interrupt using > pci_msi_enable(). From that point, the I-pipe might have an obsolete > view of the interrupt map. I suspect an I-pipe issue here. > > > > I think the I-pipe is alright. It only cares for the actual interrupt > numbers and irq_desc[] should be current with these numbers upon the > ipipe_virtualize_irq call, which occurs only after enabling MSI, right ? > 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. > 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? > Jeroen. > > > -- > Philippe. > > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Registering MSI interrupt with Xenomai fails
> > > arch_setup_msi_irq() creates an IRQ on-the-fly from the current > descriptor which is being converted to an MSI interrupt using > pci_msi_enable(). From that point, the I-pipe might have an obsolete > view of the interrupt map. I suspect an I-pipe issue here. I think the I-pipe is alright. It only cares for the actual interrupt numbers and irq_desc[] should be current with these numbers upon the ipipe_virtualize_irq call, which occurs only after enabling MSI, right ? 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. Jeroen. -- > Philippe. > ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
