EEH/Hotplug (was Re: [PATCH] rpaphp broken in ameslab)

[linas at austin.ibm.com]

On Fri, Jul 02, 2004 at 03:57:41PM +1000, Paul Mackerras wrote:
> > > I want to see a notifier list exported by eeh.c as I proposed in a
> > > previous email before that goes upstream.
> >
> > Its currently implemented as a work queue. Is that acceptable?
> > To keep gregkh happy, I'll move the work-queue to
> > drivers/pci/hotplug/rpaphp_eeh.c, will this work?
>
> It's not the work queue that is the problem, it is that the EEH code
> is taking a decision about what hotplug should do.  I am saying that
> the EEH code should offer to provide notifications to any interested
> code about slot isolation events.  The slot isolation event is a fact,
> the request to do an unplug operation is policy.  Let's leave the
> policy up to the rpaphp driver and/or userspace.

I'm not yet convinced that hotplug should be the focal point for
device driver policy decisions, but I'll go ahead and implement the
notifier chain for now, and see what happens.

Note that the scsi generic layer implements a bunch of policy
almost the same kind of thing, except that its for the scsi bus,
and not for the pci bus.   Not all scsi device drivers use the
scsi-generic layer, but those that do get a reset sequence something
like the following:

-- if device not responding, reset device
-- if above failed, retry a few times.
-- if still failed, reset scsi bus
-- if still failed, retry a few times ...
-- if above failed, reset scsi controller

For pci bus disconnection events that affected scsi devices, I was
going to tap into that 'policy' code.  I'm not sure I want to comment
more until I try the prototype.

I'm not sure if anyone is thinking about i/o fabrics yet, or how
that policy gets done ... for example, one disk is attached to
two scsi controllers, and there was an eeh event on one of the
controllers; where is the failover policy implemented?  Currently,
I think all the device drivers that do this are all proprietary ...

--linas

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