Subject: Re: NetBSD + PCI: questions & concerns
To: Thor Lancelot Simon <tls@rek.tjls.com>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 01/28/2007 21:47:10
On Sun, Jan 28, 2007 at 08:30:01AM -0500, Thor Lancelot Simon wrote:
> On Sun, Jan 28, 2007 at 01:52:15PM +0100, Jachym Holecek wrote:
> > # 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).

This is my understanding, fortunately you can also rely on the PCI bridge
sequencing writes - so the read-back can be from a later address.
(I also remember suggesting that somone 'humour me' by adding a read-back to
see if it solved a problem - which is did.)

> Some devices (due to their design) are particularly sensitive to this.
Almost all device drivers are subject to this problem - especially on sparc
systems.  So you get a splurious interrupt because the interrupt return
sequence completes before the last write that would remove the IRQ request
fails to complete before ISR exits - and another interrupt is serviced.

> A good example is the bge driver, where synchronizing reads are needed
> all over the place to ensure that control registers don't get out of
> sync between the chip and driver.

Hmmm....  Sounds like a badly written driver to me :-)

> An example of another technique
> (which might look cleaner but is really, I think, pretty ugly) is the
> Intel if_em driver for the hardware we support with if_wm, which is
> sprinkled with delay loops to ensure that bus transactions are complete.

Unfortunately that is a bug, delay loops MUST NOT be used for that purpose.
In the presence of other bus masters the initial write can be delayed by
(almost) arbitrary amounts.  So no amount of delay can be guaranteed to be
enough.
 
> It's not pretty any way you look at it.  From a naive software guy's
> point of view, these registers really ought to be kept in a region
> to which the bus is not allowed to delay writes.

That isn't gping to happen either.  Writes get delayed several times, not
only by bus bridges.

	David

-- 
David Laight: david@l8s.co.uk