>From: Kenji Kaneshige [mailto:kaneshige.kenji@xxxxxxxxxxxxxx] >Sent: 2006年4月14日 12:38 >Hi Kevin, > >> If two RTEs are from two different IOSAPIC, above code is >> meaningful to send two EOI to both IOSAPIC. However if two >> RTEs are in same IOSAPIC, then EOI are sent to same IOSAPIC >> twice. Will the 2nd EOI trigger duplicated notifications to CPU if >> some device has assertion on that irq line once after 1st EOI? >> > >I think it will, though I guess the 1st notification and 2nd >notification might be handled as one interrupt, if 2nd notification >was sent before reading IVR for 1st notification. On the other hand, >2nd interrupt would be handled like spurious interrupt, when 1st one >and 2nd one were handled separately. Anyway, 2nd EOI looks needless >and I think it should be fixed. Ah yes, normally it's harmless since CR.EOI is written after sending IOSAPIC.EOI which ensures two consequent notifications as one pending to processor. > > >> - iosapic_reassign_vector: >> It's only called by iosapic_register_platform_intr for PMI by >> far. >> When designated vector is already occupied, the rte list of that >> vector will be copied to a new vector. However there's no updates >> to physical RTEs within IOSAPIC to reflect this change. > >IIRC, vectors for PMI are 0 to 15 and any other external interrupts >don't use those vectors. So this code path is executed only if >multiple PMIs use the same vector number. Vector numbers for PMIs >are assigned by firmware, so OS cannot re-assign other vector. I >guess this is why there's no updates to physical RTES. But, I don't >know why we need iosapic_reassing_vector()... OK, I see. The name here is a bit misleading... :-) Thanks a lot, Kevin - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|