On 10-May-00 Mike Smith wrote:


>> This is dangerous for the OSM.  When the i2o OSM shuts an IOP
>> down, it is history.  It will stop doing any work at all; network,
>> disk, console, mouse, whatever.  I reserve that for really, really
>> shutdown/reset.
> I'm not sure I understand what you mean by "dangerous".  When your 
> shutdown method is called, you're being told that you're about to stop 
> being able to control your hardware, either because your code is about to 
> be removed from the kernel (module unload) or because the system is being 
> shut down.

(perhaps) Dangerous in the sense that the i2o OSM handles multiple
diciplines.  It is not a disk-only driver.  It has a disk component
but if I shut down the IOPs more than just disks stop.
Thus I need to be sure the OSM is the very last to be called.

> Before you return success from your shutdown method, you must have 
> brought your hardware to a quiescent state, ready for immediate loss of 
> power.  It must not generate any more interrupts or access any more data 
> once you have returned.

That is already being done.  Thanx.

> You can veto your shutdown (by returning nonzero), which will fail a 
> module unload, but _will_not_ fail a kernel shutdown.

That is fine.

>> This needs to happen after all other shutdown work was done,
>> but before a physical reset is sent to the hardware.
>> There is no telling how long the IOP will take to return
>> from flush request.
> That's fine.  Again, the Mylex driver is doing exactly what you're 
> talking about; I've been down this path just a few times now. 8)
>> > (Note that the Mylex stuff doesn't correctly handle suspend/resume since 
>> >  we don't have a decent ACPI implementation yet)
>> I can emulate suspend/resume in the OSM easily.
>> Actually, it does that just before shutting down.
>> A single line of code.
> I'm assuming that you depend on the platform firmware to bring it out of 
> any of the deep sleep modes, re-enumerate the PCI bus and restore all of 
> its volatile state?

Nope.  I maintain a state machine in the OSM that makes sure
there is nothing pending on the IOP.  Shutting down the IOP
is a mess.  Bringing it back up is even bigger mess.  It is
simpler the way I do it.  Besides, different vendors implement
i2o in different ways.  Some do not even have a facility for
sane shutdown.

> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
> \\ and he'll hate you for a lifetime.             \\  [EMAIL PROTECTED]
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

Sincerely Yours
Simon Shapiro             Research Fellow, Earthlink Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to