From owner-freebsd-current Wed May 10 8:20:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org [207.69.194.51]) by hub.freebsd.org (Postfix) with SMTP id 5EE5537B7EA for ; Wed, 10 May 2000 08:20:24 -0700 (PDT) (envelope-from shimon@simon-shapiro.org) Received: (qmail 7987 invoked from network); 10 May 2000 16:12:01 -0000 Received: from nomis.simon-shapiro.org (209.86.126.163) by sendero.simon-shapiro.org with SMTP; 10 May 2000 16:12:01 -0000 Content-Length: 2859 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200005100215.TAA21503@mass.cdrom.com> Date: Wed, 10 May 2000 11:23:05 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: Simon's Garage From: Simon Shapiro To: Mike Smith Subject: Re: EVENTHANDLER_DECLARE Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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