Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> PS: We really do want to call mask/unmask instead of disable/enable in any >>> case, because ->disable() >>> became a nop in 2.6.21, so we just can't rely on its default action anyway. >>> This is a separate >>> issue, that caused rthal_irq_disable() not to actually mask the interrupt >>> when the I/O APIC is enabled. >> Hmmmm... That makes me scratch my head. Could this change have some >> impact on I-pipe as well? We are currently pulling hairs here as some >> SCSI adapter is flooding us with spurious IRQs during init, but only if >> I-pipe is enabled. >> > > __ipipe_enable_irq/__ipipe_disable_irq are not doing the right thing anymore, > but, AFAICT, this would only affect callers of ipipe_virtualize_irq and > ipipe_control_irq, using IPIPE_ENABLE_MASK. > > Btw, are those APIC-based SMP spurious interrupts, or 8259-based ones?
x86-64, APIC, fasteoi. But it is no SMP artifact (maxcpus=1 makes no difference). So far only one machine type is affected. And there is a higher chance to get over the initialization with kernel 2.6.23 than with .24. After that point, everything is fine. Unfortunately, the box is highly contended (and also horribly slow at boot), so testing and debugging is a lengthy process. Therefore, I'm primarily collecting ideas about potential reasons. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
