Date: Wed, 10 May 2000 11:23:05 -0400 (EDT) From: Simon Shapiro <shimon@simon-shapiro.org> To: Mike Smith <msmith@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: EVENTHANDLER_DECLARE Message-ID: <XFMail.000510112305.shimon@simon-shapiro.org> In-Reply-To: <200005100215.TAA21503@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, \\ msmith@freebsd.org
> \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.000510112305.shimon>