Date: Fri, 05 Dec 2008 00:10:52 -0800 From: perryh@pluto.rain.com To: avg@icyb.net.ua Cc: freebsd-hackers@freebsd.org Subject: Re: ichwd problem: watchdog doesn't "bark" Message-ID: <4938e20c.nP8q%2BJgDZ0gKUsAU%perryh@pluto.rain.com> In-Reply-To: <49382449.80002@icyb.net.ua> References: <49300020.6060603@icyb.net.ua> <49382449.80002@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
[dropped stable@ since I'm not on it and I suspect it may not accept non-member posts] > BTW, can someone knowledgeable tell me if watchdog better > be firing SMI or NMI when it runs down? > My bet is on NMI, but who knows. It may depend on whether you want the BIOS, or FreeBSD, handling the interrupt. Unless you are running *very* old h/w, there's a good chance the BIOS intercepts SMI, even with a protected-mode OS running, and I wouldn't be surprised if the BIOS' response to a watchdog timeout were an immediate reboot. It might be good to check the motherboard and/or BIOS manuals. > Or maybe I am trying to ask a different question. > I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and > our watchdog driver is careful to preserve this bit unmodified. > This means that watchdog would try to cause SMI instead of NMI. > On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to > zero, which means that chipset would never generate an SMI. > So I think this is why I don't see anything happening. > > Now, would should try first - reset NMI2SMI_EN to zero or set > GBL_SMI_EN to 1? If you want to handle the interrupt in FreeBSD, I'd try resetting NMI2SMI_EN to zero.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4938e20c.nP8q%2BJgDZ0gKUsAU%perryh>