From owner-freebsd-current Tue May 9 19:15:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id 6F7CF37B6C7 for ; Tue, 9 May 2000 19:15:34 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA21503; Tue, 9 May 2000 19:15:31 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005100215.TAA21503@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: shimon@simon-shapiro.org Cc: freebsd-current@freebsd.org Subject: Re: EVENTHANDLER_DECLARE In-reply-to: Your message of "Tue, 09 May 2000 22:02:52 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 May 2000 19:15:31 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On 10-May-00 Mike Smith wrote: > >> Sorry to bother y'll, but; > >> > >> Has anyone ever used that? I see no trace of any kernel > >> code calling it, and the at_shutdown code appears to be > >> gone. > > > > It's still used in the shutdown code; it was meant to be available for > > general use elsewhere, but I haven't seen anyone playing with it, so > > maybe the design tradeoffs were bad choices. > > I dunno. It seems to do anything I need; Call me with an argument. > I do not even need the priority. It won't notify you that your code is about to be removed from the kernel. > >> BTW, for all it is worth, any caching controller not using > >> this is guaranteed to lose data. > > > > Wrong layer. You should be using the bus shutdown method; look at eg. > > the Mylex driver to see how this is done. You should probably call your > > flush routine from the suspend method as well. > > 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. 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. You can veto your shutdown (by returning nonzero), which will fail a module unload, but _will_not_ fail a kernel shutdown. > 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? -- \\ 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