I may have been unclear in my postings about PCI bridges that donnot
flush posted transactions as PCI specifications required them to do.
The sym and ncr drivers perform a single read (from SCRIPTS for the sym
and (from the CPU for the ncr) in order to synchronize correctly when
compliant bridges are used.
When flushing of posted writes by the bridge do not happen as expected due
to some bridge quirk, it may exist a small window where a completion may
be lost (I can describe the scenario if needed).
Compared to other PCI device drivers I am able to understand the code,
most of them may lose a completion even when conformant bridges are used.
But the ncr and sym drivers require a non conformant bridge to run the
same risk and are quite safe when the bridge is correct.
The reasons we donnot experience problems are the following:
1. There is a small window, basically the PCI device completing an IO
at the moment the C code deals with corresponding flags in IO
registers, where the problem may occur.
2. Bridges are generally fast to flush buffers and the interrupt latency
is generally very short. So sitution (1) above is very unlikely
to happen.
3. If situation (1) occurs and the PCI device is able to accept several
concurrent IOs, a subsequent completion will wake up the IRQ handler
and the CPU will reap the lost completion. So, the problem will not
be visible.
Even, if completion/interrupt lossage is very unlikely to happen here,
since Murphy's law is defeated due to 1+2+3, I did want the ncr/sym
drivers not to be confused by non PCI conformant bridges when it is
possible.
There are some other broken bridge implementations for which the ncr/sym
driver and very probably most of other PCI device drivers may experience
consistency problems. Just think to the following:
A) Bridges that reorder (DMA) writes to memory.
B) Systems bridges that donnot ensure cache coherency.
For these ones, drivers must probably limit themselves to the following:
1. Perform one IO at a time. I mean only queue 1 IO at a time to the
controller and let the controller wait for the CPU to restart
operation from the interrupt handler.
2. Ensure from the CPU by some hardware mechanism that _all_ writes are
flushed prior to signal completion to user.
I also intend to provide changes that will allow some support for so
broken bridges if I discover some existing ones.
All the coherency problems that may occur due to non compliant bridges are
not fixable generically for all PCI device drivers at the same time. The
work-arounds, when possible, are to be implemented in each driver and may
differs due to hardware or driver differences.
Have I been clear this time ?
Regards,
Gérard.
On Sun, 25 Jul 1999, Barrett G. Lyon wrote:
> At 07:57 PM 7/25/99 +0200, you wrote:
> >
> >I can propose a small preliminary patch that may be useful for ensuring
> >that the ncr/sym drivers will not lose completions with some not PCI
> >compliant bridges regarding flushing of posted write transactions.
> >
> >For now, the changes consist in the following:
> >
> >- Intel and IBM bridges are assumed fine.
> >
> >- Alpha bridges (21172 and friends) is ok for the sym53c8xx driver by just
> > adding a dummy read in the interrupt handler. (The ncr53c8xx requires
> > a minor change in the SCRIPTS in order to be ok for the 21172 and I will
> > provide such a change after my vacations).
> >
> >- For other cases (ncr53c8xx under alpha included), the drivers may have
> > to reap completions from its timer (ncr_timeout) handler.
> > For the history, the original FreeBSD ncr.c still run such an handler
> > and I donnot know of any other driver reaping interrupts this way.:)
> >
> >By the way, I cannot beleive some other drivers I know a bit to be really
> >100% sure of not losing completions with some bridges I read about.
> >
> >The patch should apply to everything as ncr53c8xx-3.2* + sym53c8xx-1.3*
> >up to latest.
> >
> >I am in vacation for the first half of August. Will refine the change
> >as necessary after my vacation.
> >
> >I cannot test the patch since I only have x86 boxes, assumed ok.
> >You may want to let me know asap if the patch makes problems.
>
> With this patch I still get:
>
> PYXIS machine check NOT expected on the SYM driver in 2.2.10-ac12 + your
> patch.
>
> In 2.2.10 I do not get the PYXIS errors.. I really need to move off of
> 2.2.10 because it has some serious problems.
>
> -Barrett
>
>
>
> ___________________________________________________________________
> / Barrett G. Lyon PGP: www.netpr.com/pgpkeys \
> | Data & Network Security Consultant Fax: (520) 441-5959 |
> | Network Presence, LLC Email: blyon@netpr.com |
> \___________________________________________________________________/
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/