From owner-freebsd-hackers Thu Sep 12 9: 9:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDEA037B42A for ; Thu, 12 Sep 2002 09:09:24 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FD0743ED1 for ; Thu, 12 Sep 2002 09:07:15 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g8CG3Dn43523; Thu, 12 Sep 2002 09:03:13 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200209121603.g8CG3Dn43523@ambrisko.com> Subject: Re: Supporting HW_WDOG? In-Reply-To: <20020912134302.GJ2420@spc.org> To: Bruce M Simpson Date: Thu, 12 Sep 2002 09:03:13 -0700 (PDT) Cc: hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce M Simpson writes: | Mainly interested in exploring this with a view to implementing capabilities | a bit like the LOM chip found in Sun Netras on an i386 box. | | What I'd like to do is modify a Soekris net4501 for this. The Sun LOM | chip handles things like serial console capabilities, environmentals, | and provides a means of executing memory tests, etc; it's able to issue | notifications to the OS running on the machine, I believe using traps or | an NMI mechanism. | | Come to think of it, has anybody seen anything like this in the Intel | IPMI specification? Just a thought. We have implemented a SW & HW watchdog here. The HW support is based on the reboot timers in the Intel ICH and SIS 630 chips. Our scheme is to implement a SW watchdog in hard clock that is controlled via a sysctl. Then we enforce the SW watchdog via the HW watchdog (ie if the SW watch dog doesn't reset the HW watchdog then the machine reboots). This gives us more flexibility then the HW watchdog does since they have a limited and non-standard amount of time they can wait for. This way only sysctl's are used an no /dev entries are needed. I did add a kernel sysctl function so that I could call another sysctl easily. This let me "dynamically" link in the HW watchdog if a kldload was loaded that implemented the HW watchdog sysctl. I kldunload would disable the HW watchdog and unlink it from the SW one. We also added code that if the machine panic'ed or dropped into the debugger with DDB not set as unattended then the watchdogs would get turned off (also we disable consmute at the same time). We have this working on generic PC motherboards with no custom hardware. The user-land tickler just does a syctl to set the ticks that SW watchdog should wait for before it calls panic and gives you a kernel core. Unfortunately the ICH reboot timer cannot generate an NMI. That would have been better so we could get a core. Note at a prior company we needed the tickler since the HW watchdog could not be deactivated until it went off :-( Smarter watchdogs can be turned off and then ticklers are not needed. If anyone it interested with playing with the code and getting it into shape to put into -current I can send it to you. It needs to be cleaned up. The kernel sysctl function needs to be added properly to the sysctl file etc. I can help with testing, reviews and questions. I just don't have time for polishing right now. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message