more eeh

Greg KH greg at
Thu Mar 18 04:23:27 EST 2004

On Tue, Mar 16, 2004 at 06:40:53PM -0600, Nathan Fontenot wrote:
> Hope I don't spoil anyones dinner with another dose of eeh :)
> I have attached a patch that generates the hotplug event in the
> kernel. At least it's supposed to do that.  This eliminates the
> need for any kind of an eeh daemon and any /proc usage (two good
> things).

No, you aren't generating a hotplug event here, you are instantly
shutting the power to the device off, after telling the driver bound to
the device to disconnect.  Is that what you really want to do?  It's
quite severe, and is a pretty harsh policy.

Think scsi devices with lots of filesystems mounted.  boom.
Think multiport ethernet devices with loads of network traffic going
over the other ethernet devices.  boom.

Both of those are not very "robust" solutions I might point out :)

It's also not going to work, as you are doing this from interrupt
context, and the pci disconnect sequence is expecting to have a task
context and will sleep.

Why not do this (as this is what I think Anton was suggesting you do):
	- get eeh event
	- determine which pci_dev this happened to.
	- switch back to a task context
	- call kobject_hotplug for the pci_dev with the action="fault"
	- put a script in /etc/hotplug.d/pci/ that catches all
	  ACTION=fault events and decides what to do with them.  You
	  have a full pointer to the sysfs directory of the pci device
	  at this moment in time, so you can see what driver is bound to
	  the device, and if you really want to, you can turn the device
	  off (after bringing down the network connection or unmounting
	  any attached filesystems.)

This pushes all of your policy to userspace, allows you to fit into the
proper kernel event notifier, and allows you to write a shell script if
you want to do so.

And it makes the kernel code a whole lot smaller and simpler.

Sound good?


greg k-h

** Sent via the linuxppc64-dev mail list. See

More information about the Linuxppc64-dev mailing list