> Date: Sun, 12 Feb 2012 10:25:10 +0100 (CET)
> From: Mark Kettenis <[email protected]>
>
> > Date: Thu, 9 Feb 2012 17:14:41 +0000
> > From: Miod Vallat <[email protected]>
> >
> > Could people with ahc(4) SCSI controllers give the following diff a try
> > and report whether this causes any difference in behaviour? This diff
> > seems to do wonders on alpha, but I'd like reports from other platforms
> > (such as i386, amd64 and macppc) before considering putting it in.
>
> I'm not sure this is a good idea. Writes on the PCI bus may be
> posted. The ahc_inb() call makes sure that any preceding (posted)
> writes have indeed completed. By replacing this with a
> bus_space_barrier() you no longer guarantee completion of the writes,
> but instead guarantee that the CPU (or the compiler) doesn't reorder
> the writes. So it's not the same thing.
>
> I don't know what the ahc(4) driver/hardware requires here. Could be
> that posted writes are not an issue at all. But if they are, we
> probably need to keep that ahc_inb() call around. So it would be
> safer to just add the bus_space_barrier() call before the ahc_inb()
> call.
Ok, aic7xxx_inline.h has the following comment:
/*
* Ensure that the chip sees that we've cleared
* this interrupt before we walk the output fifo.
* Otherwise, we may, due to posted bus writes,
* clear the interrupt after we finish the scan,
* and after the sequencer has added new entries
* and asserted the interrupt again.
*/
ahc_flush_device_writes(ahc);
ahc_run_qoutfifo(ahc);
so ahc_flush_devoice_writes() is supposed to properly guard against
uncompleted posted bus writes. In other words, I think we need to put
that ahc_inb(ahc, INTSTAT) call back (after the bus_space_barrier()
that miod@ introduced).
