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
404.664.6401
Simon Shapiro Research Fellow, Earthlink Inc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
