# David Young 2007-01-28:
> 
> 2 Write-posting and interrupt handlers.
> 
>   IIUC, some PCI bus bridges buffer posted writes, which can delay
>   writes to PCI devices.  It seems to me that this can cause a system to
>   "double" the number of times it calls an interrupt service routine.
>   For example, consider some PCI NIC:
> 
>   [... failure scenario ...]

Hmm, you're right. Only subsequent read from written-to location
seems to enforce write completion, AFAIU [1] (though I may need to
re-read that section).

Additionaly [2] claims:

  Interrupt requests (that use INTx#) do not appear as transactions on the
  PCI bus (they are sideband signals) and, therefore, have no ordering
  relationship to any bus transactions. Furthermore, the system is not
  required to use the Interrupt Acknowledge bus transaction to service
  interrupts. So interrupts are not synchronizing events and device drivers
  cannot depend on them to flush posting buffers.

It is not entirely clear to me if non-prefetchable regions are handled
specially or not -- I would expect so, but couldn't verify.

>   Worse things could happen, but ... maybe they do.  Should NetBSD
>   provide bus_space_barrier for PCI, even on x86, and use it?

This would be doable for prefetchable regions, non-prefetchable ones
will just need to issue extra reads themselves. So I'm not sure how
useful would bus_space_barrier() be in practice.

	-- Jachym

References: PCI specification version 3.0,
[1] appendix E - "System Transaction Ordering"
[2] section 3.2.5.2. - "Transaction Ordering and Posting for Bridges"