Re: unclean yanking out of device?

[Greg KH <greg@kroah.com>]

On Wed, Jan 14, 2004 at 07:16:04PM -0600, linas@austin.ibm.com wrote:
> On Wed, Jan 14, 2004 at 04:19:39PM -0800, Greg KH wrote:
> > 
> > What kind of hardware base is this?  (PPC64, ia64, etc.)?
> 
> ppc64

The ppc64 pci hotplug driver that is currently in the ppc64 cvs tree
should already work for your hardware, right?  Or is this for iSeries
machines?  Some other hardware?

Seriously, that driver, or another one like it is what you need to use
to tell the pci card that it needs to disable the device and unbind from
it, even if the slot power has for some reason been removed.

> > What specific drivers?
> 
> pcnet32 ethernet, some gigabit ethernet cards, some fibre-channel cards,
> and the symbios-2 scsi driver.

None of these should need to be modified.

> > > Hmm.  Let me point out that other operating systems already do this
> > > (and have been doing so for a while).   The chipset I'm working with
> > > has been shipping for, I dunno, a couple of years or something like 
> > > that.
> > 
> > What chipset?
> 
> The one in the ppc64 mainframes.

Which ppc64 mainframes exactly?  iSeries?  pSeries?  Model numbers?  I
seem to have access to quite a lot of different ppc hardware through my
employer :)

> It shows up in the ppc64 arch code 
> under the name of "phb", and its eeh.c that deals with configing the
> support I'm talking about.  Right now, eeh.c calls panic() when things
> go kaboom, and my goal is to replace the panic with a graceful recovery.

Ok, it shouldn't call panic().  No driver should ever call panic().
That's just bad coding...

> > I think you just need to change the way you are thinking about this.
> > Linux already has a pci hotplug framework.  Just implement your specific
> > pci controller into this framework.  That way you will not have to
> > modify any specific PCI card device drivers.  If you do this, then all
> > of the existing userspace tools will work for your hardware.
> 
> I really really wasn't joking about the cosmic ray.  It hits. There
> is an unrecoverable parity error.  What do I do?  

Ah, ok, I've talked to Paul M. and others at IBM you are probably
working with a lot about this.  They have tried to come up with a way
for a write or read to be notified that an error just occurred, right?

> Lets assume the adapter is in the middle of a dma when this happens.
> Do I pass the known-bad garbled data to the device driver, possibly
> corupting the file system, etc?  Suppose the bad data was something
> that trashed a pointer; some million or billion cpu cycles later
> the kernel oopses for some mystery reason.   Instead of allowing
> this kind of 'silent corruption' to occur, the current ppc64
> code for this simply halts the system, it calls panic (in eeh.c), 
> and that's that.

Again, it should not do that.  We need to have a way to notify that the
write or read failed.  Work on fixing that, and then modify the driver
to gracefully recover is the proper sequence.  If you really want to,
tell the pci slot controller that it now needs to disable that slot,
which will cause the driver to shut down the device.

I seem to remember the proposal was quite complex last time I saw it,
has it been cleaned up any since?

If you don't know of any such proposal, I suggest you look into it, as
you don't want to duplicate the work others are already doing.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel