Re: unclean yanking out of device?

[Greg KH <greg@kroah.com>]

On Wed, Jan 14, 2004 at 05:57:48PM -0600, linas@austin.ibm.com wrote:
> On Wed, Jan 14, 2004 at 03:24:12PM -0800, Greg KH wrote:
> > On Wed, Jan 14, 2004 at 05:08:49PM -0600, linas@austin.ibm.com wrote:
> > > > > 
> > > > > What is supposed to happen if I just yank out a (network/scsi) device
> > > > > while it is being used, without calling any of the hotplug unregister
> > > > > remove etc. functions in advance?
> > > 
> > > Let me rephrase:  I want to make 'appropriate' changes to the 2.6/2.7
> > > kernel, and some selected device drivers, so that a sysadmin can 
> > > stupidly yank out an *ordinary* PCI card (not a pcmcia) without doing 
> > > an orderly shutdown in advance.
> > 
> > Hahahaha... no, PCI drivers can not handle that.  
> 
> Right. I've been tasked with modifying several specific drivers to 
> handle that.

What kind of hardware base is this?  (PPC64, ia64, etc.)?
What specific drivers?

> > See the PCI Hotplug
> > spec for why.  
> 
> You mean the spec that's avaialble from http://www.pcisig.com ?
> or a linux-specific spec?

The PCI SIG one.  Linux follows that spec, just like other operating
systems...

> > PCI drivers need to be told to shut down before removing
> > them.  And that will not change, sorry.
> 
> 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?

> They've already gone through a four or five engineering upgrades
> on the feature set.  So when you say you're sorry, did you mean 
> "its a bad idea, I will personally oppose it",  or do you mean 
> "you'll have to implement all of this by your lonesome"?

I (as the Linux kernel PCI and PCI Hotplug maintainer) oppose it.  :)

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.

> > > More specifically, I have a whiz-bang PCI controller that will
> > > shut down a PCI slot when it is hit by a cosmic ray (data/address 
> > > parity error, other error, etc.).  I want to be able to "recover"
> > > that slot, (if its recoverable), and get things going again.
> > 
> > That pci controller needs to tell the OS that it is going to shut down
> > that pci slot.  Otherwise that pci controller violates the PCI spec.
> 
> I was only half-joking about the cosmic ray.  The cosmic ray violated 
> the PCI spec.  boo hoo.  Now what?  Tell it to go back to the supernova 
> it came from?

No, tell the driver that it is going to be shut down.  The driver will
do so, and then you can safely yank it out.  That's what all pci hotplug
controller drivers do, why be different?

> > Note, yes I know that cPCI controllers do this, that's a totally
> > different story... the os still needs to know before turning off a slot.
> 
> This isn't a cPCI chipset.  The point is, the hardware went kaboom,
> the pci device is in some hopeless state, and further communication
> with it is impossible.  My goal is to clean up the kernel state and
> move on. 
> 
> Let me rephrase that: I could hack up some code that does this, but
> my goal is really to do it in such a way so that the patches are 
> accepted by Torvalds, etal.  Much of the code can be done in the 
> arch directories, but some of it needs to go into generic files,
> and into specific device drivers, and so its my interest to go as
> generic as possible before I have to retreat to a rats-nest of
> special-case code.

You should only have to implement a single, hardware specific driver for
this to work properly in Linux.  See the existing pci hotplug controller
drivers in drivers/pci/hotplug and the drivers/pci/hotplug/pci_hotplug.h
for the interface you need to implement.

Hope this helps,

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