From owner-freebsd-current@FreeBSD.ORG Tue Mar 17 14:19:58 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 CDEB51065670 for ; Tue, 17 Mar 2009 14:19:58 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5AD8FC21 for ; Tue, 17 Mar 2009 14:19:57 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA24443; Tue, 17 Mar 2009 16:07:46 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <49BFAEB1.1010800@freebsd.org> Date: Tue, 17 Mar 2009 16:07:45 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: Mike Tancsa , Harald Schmalzbauer 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> In-Reply-To: <49BE81DB.6040208@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org 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 14:19:59 -0000 on 16/03/2009 18:44 Andriy Gapon said the following: > http://lists.freebsd.org/pipermail/freebsd-acpi/2009-January/005419.html 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. 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 probably only observable to SMM code), all status bits remain cleared (from non-SMM observer's point of view). Because TCO_TMR still has 0x1C value, I believe that 4 is a default internal value for "second" timeout. 2. I also observe behavior of another status bit, PERIODIC_STS, that supports my theory that SMI handler simply clears all SMI-related status bits. Normally PERIODIC_STS is set to 1, because on my system periodic SMI timer is enabled but actual SMI generation by this timer is disabled. So it sets the bit to 1 on teh first timeout, but SMI handler is never run, so there is nobody to clear this bit. On the other hand, when watchdogd is killed, SMIs are egenrated regularly by watchdog hw and the handler seems to clear all SMI status bits, including this one. Maybe it's possible to somehow ask BIOS to do something useful on watchdog SMI, 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. -- Andriy Gapon