From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 18:17:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FA35106564A for ; Tue, 17 Mar 2009 18:17:26 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id DBB048FC0A for ; Tue, 17 Mar 2009 18:17:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from [172.25.1.16] (atip.spsnetz.de [82.135.45.118]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n2HIHN4V066275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Mar 2009 19:17:24 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host atip.spsnetz.de [82.135.45.118] claimed to be [172.25.1.16] Message-ID: <49BFE933.9040706@omnilan.de> Date: Tue, 17 Mar 2009 19:17:23 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Andriy Gapon References: <200810011405.m91E5ugg028685@lava.sentex.ca> <200810011121.21908.jhb@freebsd.org> <49BD0943.3000400@OmniLAN.de> <200903161501.n2GF1bNw090788@lava.sentex.ca> <49BE81DB.6040208@icyb.net.ua> <49BFAEB1.1010800@freebsd.org> In-Reply-To: <49BFAEB1.1010800@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: Re: ichwd on ich9 attach failing ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 18:17:26 -0000 Andriy Gapon schrieb: ... > BTW, Harald, I found your older report: > http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076381.html > I wonder if that was with the same HW as now. Hello, thanks all for your answers. This is different hardware. Unfortuantely that box went in production, but I'll see if I can fix another maschine, I have the S3200 Server board in spare. > I think that I got some additional evidence that SMI handler just clears timeout > status bit and doesn't do anything else. > > 1. When watchdogd is running TCO_RLD has value very close to value of TCO_TMR, > e.g. TCO_TMR has 0x1C and TCO_RLD oscillates from 0x1C to 0x1A. > When I kill -9 watchdogd then TCO_RLD value cycles from 4 to 1 (zero value is [snip] > but I do not see any options in my (Intel's actually) BIOS nor do I know of any > other way. > > Fortunately GBL_SMI_EN bit is not locked on my system as I have discovered, so I > will try tonight to let watchdog timer expire with SMIs disabled. > This is quite a sledge-hummer approach. I'll try to understand that in a quiet minute, which won't happen before next week :( One thing which is also new to me is an attached IPMI wtachdog. No idea about IPMI (yet) but maybe the wd-timer is just occupated by BMC/IPMI?! ipmi0: IPMI device rev. 1, firmware rev. 0.2, version 2.0 ipmi0: Number of channels 2 ipmi0: Attached watchdog Best regards, -Harry