[lkml]   [2004]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRace in PCI probing vs. IRQs
    An old problem, though I suppose the actual race window is very

    The PCI code, when probing for a device will write the the BARs to
    get the size, then restore the BAR to their original state. It does
    that with interrupts enabled on all CPUs of course.

    That mean that for a short window of time, we have the device no longer
    accessible on the PCI bus.

    However, that device may be a system device of some kind which may be
    involved in the interrupt processing.

    An example is PowerMacs. Their main interrupt controller is on the
    MacIO PCI ASIC. We "probe" it using the OF device-tree, and IRQs are
    initialized before PCI. We have a couple of other system devices like
    the Power Manager unit which we communicate to via interfaces in
    this ASIC, and those are setup & initialized before PCI is probed.

    That means that we have potential driver activity and interrupts
    going on during the PCI probe. So there is a window where the MacIO
    ASIC may be temporarily inaccessible on the PCI bus during boot,
    and thus the PIC and some other device, while we can actually take
    an interrupt and try to tap them.... bad...

    I don't think the "other" CPUs during boot are much active during
    the PCI probe, but they might well take interrupts too...

    What would be a good fix for that ? I'd hate to have to use an IPI
    to gather all CPUs into some wait loop with IRQs off and do all of
    the PCI probe with IRQs off, but that may be the best solution if we
    want to be completely safe...


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:00    [W:0.032 / U:6.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site