From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:39:47 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 4F32516A4CE; Fri, 16 Jan 2004 08:39:47 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E0A43D31; Fri, 16 Jan 2004 08:39:42 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i0GGdQN1046543 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 16 Jan 2004 17:39:32 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i0GGdG4H029312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2004 17:39:17 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i0GGdGBE042003; Fri, 16 Jan 2004 17:39:16 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i0GGdDQm042002; Fri, 16 Jan 2004 17:39:13 +0100 (CET) (envelope-from ticso) Date: Fri, 16 Jan 2004 17:39:13 +0100 From: Bernd Walter To: Julian Elischer Message-ID: <20040116163912.GK24203@cicely12.cicely.de> References: <20040113235511.GB39353@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: hackers@freebsd.org cc: imp@freebsd.org Subject: Re: PCI interrupt allocation question.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 16:39:47 -0000 On Tue, Jan 13, 2004 at 04:14:10PM -0800, Julian Elischer wrote: > > > On Wed, 14 Jan 2004, Stijn Hoop wrote: > > > On Tue, Jan 13, 2004 at 03:26:00PM -0800, Julian Elischer wrote: > > > The kernel includes teh ichsmb driver to try access the SMBus > > > for temperature reading reasons (yes I know I can do it other ways..) > > > > > > Any thoughts that move me towards getting th eichsmb driver working on > > > this machine are welcome. > > > > Make sure that the mainboard really does support SMBus -- it turns out that > > this is optional. The ICH docs talk about a bit that should be enabled in the > > PCI config when SMB is present. I ran into this once, it should be documented > > in the archives (of -current off the top of my head). OTOH, I didn't even > > succeed in getting an ichsmb device probed so this might be something totally > > unrelated. SMBus is absolutely not optional because it's required for SPD eeproms. > > FWIW, I had to try other ways to get the temperature (xmbmon & related). I > > don't have the box anymore or I'd show you the exact config... > > xmbmon uses the SMBus to read the temperatures but it does it from > userland using direct read and write operations > and when there are timing glitches caused by the process not getting > scheduled quite quick enough you get garbage results.. > teh theory is that the kernel driver wouldn't be susceptible to this > but it looks like unless I resort to polling I will not be able to use > it because it relies on the interrupts and they are not being delivered. ichsmb(4) does a different addressing on smbus as other smbus drivers. I'm about to validate all SMBus drivers to harmonise this point. Also software regulary forgets about different smb.h include path on 5.x > ASUS motherboards actually turn off the SMBus. (why?) A very good question - I'm in tight contact with Asus germany to get that answered, but even they doesn't seem to get a satisfying answer from taiwan. It seems that they don't want customers to tamper with SMBus :( > So you need to turn it back on before you can read the temperatures.. Use ACPI... Well - it's evil after all, because I sell add on products for SMBus for which ACPI is not an option. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de