more eeh

[Nathan Fontenot]

Well, lets see if I can fill everyones mailbox with some more
lively eeh discussions again today. :)

I decided to follow Paul's suggestion and use a workqueue to handle
the hotplug remove of the device.  This was before I saw Greg's reply
about using kobject_hotplug with a user-space script.  The relevant
piece is in eeh.c in the attached patch.

Greg, you're right that this is a harsh policy.  In this case I
think it's the right thing.  When an EEH event happens the
slot is basically, device stores will fail and all reads will
return all F's.  The idea with this code is to avoid a panic() call and
hopefully allow some time to do any cleanup before shutting down.  Also,
this is why we want to limit this to network devices.  This kind of
policy for a hard disk would just be begging for data corruption.

So, bring on the comments.  at least I now know you guys aren't shy.

thanks. again.
-Nathan F.

On Wed, 2004-03-17 at 05:07, Paul Mackerras wrote:

> Is this potentially calling disable_slot() at interrupt level (e.g. if
> the driver is doing a readl() at interrupt level)?  If so, I think
> that's probably a bad idea.  I think it would be better to do it at
> process level, using a workqueue or something similar.
>
> Paul.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eeh_khp.patch
Type: text/x-patch
Size: 7859 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20040317/9d868079/attachment.bin