Resending: [RFC/PATCH] Re: How to block pci config-reads during device self-test?

[Brian King]

> There are two possible solutions.  (1) block pci config-space i/o
> during a BIST, and (2) let the device driver detect that the card
> has been off-lined, and so reset the pci controller chip.
>
> I'm starting to think (2) is better, but this patch implements (1).
> Opinions?  Comments?

I do like the idea of 2, but have a couple comments. Often times an eeh
error will lead to the adapter being replaced, so we may need to be a
little sensitive regarding error logging. I wouldn't want hitting this
window to result in the adapter being replaced. Also, just doing 2 and
not 1 will still allow a potential problem to exist. If userspace was
constantly reading pci config space of the adapter while resetting it,
it could result in continual eeh errors, until the device driver gives
up trying to bring the adapter back to life and offlines it.

> ===== arch/ppc64/kernel/pSeries_pci.c 1.39 vs edited =====
> --- 1.39/arch/ppc64/kernel/pSeries_pci.c	Mon Jul 12 18:29:16 2004
> +++ edited/arch/ppc64/kernel/pSeries_pci.c	Tue Jul 13 15:46:08 2004
> @@ -76,14 +76,22 @@
>
>  	addr = (dn->busno << 16) | (dn->devfn << 8) | where;
>  	buid = dn->phb->buid;
> +
> +	if (in_interrupt()) {
> +		/* Driver should unplug interrupts during BIST */
> +		BUG_ON (down_read_trylock(&dn->bist_lock) != 1);
> +	} else {
> +		down_read (&dn->bist_lock);
> +	}

This does not work. Device drivers often read pci config space from
interrupt context. If userspace happened to be reading at the same time,
we could hit the BUG_ON.

Also, like we discussed before, these routines are called with the
pci_lock spinlock held, so we can't be using semaphores. I think the
best way to effectively do what this patch is trying to do is to have
the read routine return ff's and have the write routine bit bucket the
data.


--
Brian King
eServer Storage I/O
IBM Linux Technology Center

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/