From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 25 14:09:52 2004 Return-Path: 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 EFF5816A4CE; Thu, 25 Mar 2004 14:09:52 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB1C443D2D; Thu, 25 Mar 2004 14:09:51 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Mar 2004 17:09:49 -0500 Message-ID: From: Don Bowman To: 'Doug Ambrisko' , Scott Long Date: Thu, 25 Mar 2004 17:09:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-hackers@freebsd.org cc: "Wm. Daryl Hawkins" Subject: RE: Intel i8xx watchdog driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2004 22:09:53 -0000 From: Doug Ambrisko [mailto:ambrisko@ambrisko.com] > Scott Long writes: > | In reading the code, it appears that it is indeed an ICHx > service and > | not limited to just i8xx chipsets. I have a few issues with how the > | probe and attach are done, and I'm addressing these in a > private mail > | right now. It's funny that I was reading the Intel ICH5 > docs last night > | and didn't come across this feature at all. > > I haven't looked at the code but have worked with this feature. > The Intel ICH3 (and probably all) has the feature it can issue an SMI on first count-down to 0, then a hard reset on 2nd. What we did was implement an SMM handler (in bios) that, when called due to watchdog, issued an NMI and did a return from smm. In FreeBSD, an NMI handler caught this (sometimes :), poke around to send a bit of data out to serial, moved the timer to the maximum value without reseting it, and then called panic [after mucking with cpl etc to pretend to own all locks :] If the NMI handler didn't get run, the hardware counted to 0 again and reset. If the NMI handler did get run, and then wedged somehow in the panic or whatever, the hardware counted to 0, and the system reset. If all worked well, you got a core, but at a minimum the system reset, and usually you got at least the serial output of some of the 'why'. The SMI is non-maskable (and higher priority than NMI).