From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 08:30:15 2010 Return-Path: Delivered-To: hardware@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C634106566C; Mon, 6 Dec 2010 08:30:15 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE778FC13; Mon, 6 Dec 2010 08:30:15 +0000 (UTC) Received: from [192.168.1.8] ([unknown] [173.70.194.135]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LCZ0062LWU4Q5R0@vms173003.mailsrvcs.net>; Mon, 06 Dec 2010 01:30:04 -0600 (CST) Message-id: <4CFC910A.5090806@aldan.algebra.com> Date: Mon, 06 Dec 2010 02:30:18 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk-UA; rv:1.9.2.12) Gecko/20101114 Thunderbird/3.1.6 MIME-version: 1.0 To: hardware@FreeBSD.org, questions@FreeBSD.org Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 06 Dec 2010 12:11:04 +0000 Cc: netchild@FreeBSD.org Subject: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 08:30:15 -0000 Hello! I have a server (Dell Poweredge 2900), that's loaded with sensors. While it was in Windows-mode, a utility was able to tell me not only the temperature of each CPU-core, but also that of every DIMM!.. One of them was running far hotter than others, and I'd like to continue keeping an eye on it now that the box run FreeBSD. In FreeBSD there is coretemp(4), which is nice, but nothing else... There is no hw.acpi.thermal hierarchy either on this box... Yet, the box has 6 fans, two power-supplies, plus DIMMs -- all of them with sensors, that I can't read... It seems, in 2007, there was an attempt to introduce OpenBSD's sensor-framework: http://kerneltrap.org/OpenBSD/BSDCan_2008_Hardware_Sensors_Framework but it was backed-out after being declared a "pile of crap" and "festering junkpile" by our most mirthful contributor: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=193129+0+archive/2007/cvs-all/20071021.cvs-all "until a proper architectural solution has been found". Has that happened in the three years, that passed since that lovely discussion? Or are we still waiting for someone to design and implement it not merely "adequately", but "perfectly"? If the three other BSD-cousins have had this for a while (NetBSD -- for 10 years, apparently), continuing to insist on some future perfection seems wrong -- we should have this "adequate but imperfect" method if only for cross-BSD compatibility. Is there, perhaps, a set of patches still secretly maintained by some die-hard? I'd love to try it here, and will be very thankful, if it gives me the monitoring, that I can not obtain otherwise... Thanks! Yours, -mi From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 13:02:38 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF71106564A for ; Mon, 6 Dec 2010 13:02:38 +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 692368FC18 for ; Mon, 6 Dec 2010 13:02:37 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA09022; Mon, 06 Dec 2010 14:44:07 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPaQJ-000ChP-JN; Mon, 06 Dec 2010 14:44:07 +0200 Message-ID: <4CFCDA96.8040803@freebsd.org> Date: Mon, 06 Dec 2010 14:44:06 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> In-Reply-To: <4CFC910A.5090806@aldan.algebra.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netchild@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 13:02:38 -0000 on 06/12/2010 09:30 Mikhail T. said the following: > Hello! > > I have a server (Dell Poweredge 2900), that's loaded with sensors. > > While it was in Windows-mode, a utility was able to tell me not only the > temperature of each CPU-core, but also that of every DIMM!.. One of them was > running far hotter than others, and I'd like to continue keeping an eye on it > now that the box run FreeBSD. > > In FreeBSD there is coretemp(4), which is nice, but nothing else... There is no > hw.acpi.thermal hierarchy either on this box... Yet, the box has 6 fans, two > power-supplies, plus DIMMs -- all of them with sensors, that I can't read... > > It seems, in 2007, there was an attempt to introduce OpenBSD's sensor-framework: > > http://kerneltrap.org/OpenBSD/BSDCan_2008_Hardware_Sensors_Framework > > but it was backed-out after being declared a "pile of crap" and "festering > junkpile" by our most mirthful contributor: > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=193129+0+archive/2007/cvs-all/20071021.cvs-all > > > "until a proper architectural solution has been found". Has that happened in the > three years, that passed since that lovely discussion? Or are we still waiting > for someone to design and implement it not merely "adequately", but "perfectly"? My opinion: if that effort was not called "sensors framework", but some name less ambitious like "basic support for a few sensors on some desktop systems", then it would get far less attention and criticism :-) But I don't want to dig into this matter any deeper :-) > If the three other BSD-cousins have had this for a while (NetBSD -- for 10 > years, apparently), continuing to insist on some future perfection seems wrong > -- we should have this "adequate but imperfect" method if only for cross-BSD > compatibility. > > Is there, perhaps, a set of patches still secretly maintained by some die-hard? Not being a die-hard I do keep, not so secretly, that code in my tree. > I'd love to try it here, and will be very thankful, if it gives me the > monitoring, that I can not obtain otherwise... Thanks! Yours, Well, that code has support only for a few types of hardware monitoring chips (Super I/Os with hardware monitoring function). So, it greatly depends on exact kind of hardware and sensors that you have. First thing you should do to is to discover what kind of hardware is used for monitoring in your server. In your case that data might be provided via IPMI. Especially I am not sure about monitoring DIMM temperature - greatly depends on the way that it is actually done. Perhaps it's reported via SMBus by the DIMMs themselves, not sure... -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 18:36:18 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D89F1065673; Mon, 6 Dec 2010 18:36:18 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6818FC1B; Mon, 6 Dec 2010 18:36:18 +0000 (UTC) Received: from [192.168.1.8] ([unknown] [173.70.194.135]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LD0005UGRO7J774@vms173017.mailsrvcs.net>; Mon, 06 Dec 2010 12:36:12 -0600 (CST) Message-id: <4CFD2D25.8090607@aldan.algebra.com> Date: Mon, 06 Dec 2010 13:36:21 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk-UA; rv:1.9.2.12) Gecko/20101114 Thunderbird/3.1.6 MIME-version: 1.0 To: Andriy Gapon References: <4CFC910A.5090806@aldan.algebra.com> <4CFCDA96.8040803@freebsd.org> In-reply-to: <4CFCDA96.8040803@freebsd.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 06 Dec 2010 18:40:27 +0000 Cc: netchild@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 18:36:18 -0000 On 06.12.2010 07:44, Andriy Gapon wrote: > Well, that code has support only for a few types of hardware monitoring chips > (Super I/Os with hardware monitoring function). Damn, I wish I knew earlier... The machine I'm retiring now -- but which was my primary horse 3 years ago -- has "Super I/O" :-( > So, it greatly depends on exact kind of hardware and sensors that you have. > First thing you should do to is to discover what kind of hardware is used for > monitoring in your server. > In your case that data might be provided via IPMI. Thanks, I'll explore that pointer... > Especially I am not sure about monitoring DIMM temperature - greatly depends on > the way that it is actually done. Perhaps it's reported via SMBus by the DIMMs > themselves, not sure... Both NetBSD and OpenBSD (and, likely, DragonFly too) have something called sdtemp(4): http://fxr.watson.org/fxr/source/dev/i2c/sdtemp.c?v=NETBSD I thought, that driver would be part of the unfortunate "basic support for a few sensors"... Anyway, I'll try merging the http://people.freebsd.org/~avg/sensors9.diff, and see, what gives... Is not it just like Linux, that one needs to get patches from here and there to get going :-\ ? -mi From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 19:28:37 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BB2A106566B; Mon, 6 Dec 2010 19:28:37 +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 02DDD8FC1F; Mon, 6 Dec 2010 19:28:35 +0000 (UTC) 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 VAA14529; Mon, 06 Dec 2010 21:28:30 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CFD395E.8040901@freebsd.org> Date: Mon, 06 Dec 2010 21:28:30 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> <4CFCDA96.8040803@freebsd.org> <4CFD2D25.8090607@aldan.algebra.com> In-Reply-To: <4CFD2D25.8090607@aldan.algebra.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netchild@freebsd.org, hardware@freebsd.org, Andriy Gapon Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 19:28:37 -0000 on 06/12/2010 20:36 Mikhail T. said the following: > On 06.12.2010 07:44, Andriy Gapon wrote: >> Well, that code has support only for a few types of hardware monitoring chips >> (Super I/Os with hardware monitoring function). > Damn, I wish I knew earlier... The machine I'm retiring now -- but which was my > primary horse 3 years ago -- has "Super I/O" :-( Well, that fact alone doesn't mean anything. >> So, it greatly depends on exact kind of hardware and sensors that you have. >> First thing you should do to is to discover what kind of hardware is used for >> monitoring in your server. >> In your case that data might be provided via IPMI. > Thanks, I'll explore that pointer... >From what I googled about Dell servers this could be your best chance. Unfortunately they don't provide their OMSA/OpenManage for FreeBSD. They do for Linux however. >> Especially I am not sure about monitoring DIMM temperature - greatly depends on >> the way that it is actually done. Perhaps it's reported via SMBus by the DIMMs >> themselves, not sure... > Both NetBSD and OpenBSD (and, likely, DragonFly too) have something called sdtemp(4): > > http://fxr.watson.org/fxr/source/dev/i2c/sdtemp.c?v=NETBSD > > I thought, that driver would be part of the unfortunate "basic support for a few > sensors"... Not sure if it was included in that import, can't find it. > Anyway, I'll try merging the http://people.freebsd.org/~avg/sensors9.diff, and > see, what gives... The patch may be out of date. Let me know if you run into problems, I'll regenerate it. > Is not it just like Linux, that one needs to get patches from here and there to > get going :-\ ? No comment. -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 20:09:12 2010 Return-Path: Delivered-To: hardware@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AC510656F9; Mon, 6 Dec 2010 20:09:12 +0000 (UTC) (envelope-from michael@fuckner.net) Received: from dedihh.fuckner.net (dedihh.fuckner.net [81.209.183.161]) by mx1.freebsd.org (Postfix) with ESMTP id 410338FC16; Mon, 6 Dec 2010 20:09:12 +0000 (UTC) Received: from dedihh.fuckner.net (localhost [127.0.0.1]) by dedihh.fuckner.net (Postfix) with ESMTP id 5E5CD2B1F7; Mon, 6 Dec 2010 20:51:33 +0100 (CET) X-Virus-Scanned: amavisd-new at fuckner.net Received: from dedihh.fuckner.net ([127.0.0.1]) by dedihh.fuckner.net (dedihh.fuckner.net [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 2Q7vGjxeoCXB; Mon, 6 Dec 2010 20:51:27 +0100 (CET) Received: from c64.rebootking.de (e176141081.adsl.alicedsl.de [85.176.141.81]) by dedihh.fuckner.net (Postfix) with ESMTPA id F02482B1ED; Mon, 6 Dec 2010 20:51:26 +0100 (CET) Message-ID: <4CFD3EC0.1060600@fuckner.net> Date: Mon, 06 Dec 2010 20:51:28 +0100 From: Michael Fuckner User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101101 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> In-Reply-To: <4CFC910A.5090806@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: questions@FreeBSD.org, netchild@FreeBSD.org, hardware@FreeBSD.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 20:09:12 -0000 On 12/06/10 08:30, Mikhail T. wrote: Hi! > In FreeBSD there is coretemp(4), which is nice, but nothing else... > There is no hw.acpi.thermal hierarchy either on this box... Yet, the box > has 6 fans, two power-supplies, plus DIMMs -- all of them with sensors, > that I can't read... did you try to read the data via IPMI? kldload ipmi;ipmitool sdr Regards, Michael! From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 21:05:13 2010 Return-Path: Delivered-To: hardware@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC7811065741; Mon, 6 Dec 2010 21:05:13 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) by mx1.freebsd.org (Postfix) with ESMTP id BCB9F8FC13; Mon, 6 Dec 2010 21:05:13 +0000 (UTC) Received: from [192.168.1.8] ([unknown] [173.70.194.135]) by vms173013.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LD000905YK76754@vms173013.mailsrvcs.net>; Mon, 06 Dec 2010 15:05:00 -0600 (CST) Message-id: <4CFD5006.7010303@aldan.algebra.com> Date: Mon, 06 Dec 2010 16:05:10 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk-UA; rv:1.9.2.12) Gecko/20101114 Thunderbird/3.1.6 MIME-version: 1.0 To: Michael Fuckner References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> In-reply-to: <4CFD3EC0.1060600@fuckner.net> X-Mailman-Approved-At: Mon, 06 Dec 2010 22:15:27 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@FreeBSD.org, netchild@FreeBSD.org, hardware@FreeBSD.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:05:14 -0000 On 06.12.2010 14:51, Michael Fuckner wrote: > did you try to read the data via IPMI? > kldload ipmi;ipmitool sdr Interestingly, I was doing just that, when your e-mail arrived... ipmitool was impressive enough and I'm building openipmi to take a look at that too. I don't see information on each DIMM (yet?), but other information is quite useful... One of the fans, for example, was listed as "cr" (rather than "ok") -- which was, apparently, causing all other fans to run at maximum speed (*very* noisy fans in poweredge 2900). I reset it (by pulling it out and back again), and now the box is quieting back down... The sensors-patches did not add any new entries under hw.sensors hierarchy :( The coretemp(4) stopped functioning, unfortunately... Whereas before, when I simply kldload-ed it, it was reporting reasonable temperatures, now that I have the sensors-patch merged in, I see nonsense like: hw.sensors.cpu0.temp0: -1282,97 degC hw.sensors.cpu1.temp0: -1272,97 degC hw.sensors.cpu2.temp0: -1282,97 degC hw.sensors.cpu3.temp0: -1262,97 degC Seems like some kind of calibration issue -- the numbers differ from each other and change with time... I think, I'll back the patch out as it did not give me any new information -- the it- and lm-devices aren't found on this box :-( Anyway, sdtemp(4) -- or equivalent -- is something, I'd like to have... Thanks! Yours, -mi From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 23:03:06 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE67F106564A for ; Mon, 6 Dec 2010 23:03:06 +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 F305A8FC18 for ; Mon, 6 Dec 2010 23:03:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA16935; Tue, 07 Dec 2010 01:03:00 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPk5E-000DcF-9L; Tue, 07 Dec 2010 01:03:00 +0200 Message-ID: <4CFD6BA3.7070505@freebsd.org> Date: Tue, 07 Dec 2010 01:02:59 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> <4CFD5006.7010303@aldan.algebra.com> In-Reply-To: <4CFD5006.7010303@aldan.algebra.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:03:06 -0000 on 06/12/2010 23:05 Mikhail T. said the following: > The sensors-patches did not add any new entries under hw.sensors hierarchy :( Oh good, one less potential source of "sensors framework" flames :-) Seriously, the version that was ported to FreeBSD was very desktop-ish, so no miracle was expected and none happened. BTW, you could probably write a simple script employing smbmsg(1) to query the DIMMs based on logic in the sdtemp driver. -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 23:19:26 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B241065696; Mon, 6 Dec 2010 23:19:26 +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 1E7898FC25; Mon, 6 Dec 2010 23:19:24 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA17088; Tue, 07 Dec 2010 01:19:18 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPkL0-000Ddd-Aw; Tue, 07 Dec 2010 01:19:18 +0200 Message-ID: <4CFD6F75.10003@freebsd.org> Date: Tue, 07 Dec 2010 01:19:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> <4CFD5006.7010303@aldan.algebra.com> <4CFD6BA3.7070505@freebsd.org> <4CFD6D2F.6090304@aldan.algebra.com> In-Reply-To: <4CFD6D2F.6090304@aldan.algebra.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:19:26 -0000 on 07/12/2010 01:09 Mikhail T. said the following: > On 06.12.2010 18:02, Andriy Gapon wrote: >> BTW, you could probably write a simple script employing smbmsg(1) to query the >> DIMMs based on logic in the sdtemp driver. > From OpenBSD's sdtemp man-page, it would seem, the driver uses the iic framework > (if that's the right word, khmm...) > > And on this server I can't get /dev/iic* (nor smb*) to appear despite loading > everything I could think of (even the viapm): > > 3 1 0xffffffff80c23000 d22 iic.ko > 4 4 0xffffffff80c24000 10e7 iicbus.ko > 5 1 0xffffffff80c26000 f16 iicsmb.ko > 6 5 0xffffffff80c27000 819 smbus.ko > 7 1 0xffffffff80c28000 c02 smb.ko > 8 3 0xffffffff80c29000 114f iicbb.ko > 9 1 0xffffffff80c2b000 1df3 ichsmb.ko > 10 1 0xffffffff80c2d000 1aed intpm.ko > 11 1 0xffffffff80c2f000 e38 pcf.ko > 12 1 0xffffffff80c30000 b83 lpbb.ko > 13 1 0xffffffff80c31000 368b ppbus.ko > 14 1 0xffffffff80c35000 262a viapm.ko > > Could it be, that the motherboard simply does not have the iic-circuitry and > that some other method has to be used? Thanks! Yours, That's quite possible. Another possibility is that a driver that should be able to handle your hardwre just doesn't know the particular IDs. pciconf -lv output could shed some light. -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Mon Dec 6 23:09:31 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AAC106566C; Mon, 6 Dec 2010 23:09:31 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by mx1.freebsd.org (Postfix) with ESMTP id 665F78FC0A; Mon, 6 Dec 2010 23:09:30 +0000 (UTC) Received: from [192.168.1.8] ([unknown] [173.70.194.135]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LD100M844BJPC62@vms173007.mailsrvcs.net>; Mon, 06 Dec 2010 17:09:20 -0600 (CST) Message-id: <4CFD6D2F.6090304@aldan.algebra.com> Date: Mon, 06 Dec 2010 18:09:35 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk-UA; rv:1.9.2.12) Gecko/20101114 Thunderbird/3.1.6 MIME-version: 1.0 To: Andriy Gapon References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> <4CFD5006.7010303@aldan.algebra.com> <4CFD6BA3.7070505@freebsd.org> In-reply-to: <4CFD6BA3.7070505@freebsd.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 06 Dec 2010 23:30:24 +0000 Cc: questions@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 23:09:31 -0000 On 06.12.2010 18:02, Andriy Gapon wrote: > BTW, you could probably write a simple script employing smbmsg(1) to query the > DIMMs based on logic in the sdtemp driver. From OpenBSD's sdtemp man-page, it would seem, the driver uses the iic framework (if that's the right word, khmm...) And on this server I can't get /dev/iic* (nor smb*) to appear despite loading everything I could think of (even the viapm): 3 1 0xffffffff80c23000 d22 iic.ko 4 4 0xffffffff80c24000 10e7 iicbus.ko 5 1 0xffffffff80c26000 f16 iicsmb.ko 6 5 0xffffffff80c27000 819 smbus.ko 7 1 0xffffffff80c28000 c02 smb.ko 8 3 0xffffffff80c29000 114f iicbb.ko 9 1 0xffffffff80c2b000 1df3 ichsmb.ko 10 1 0xffffffff80c2d000 1aed intpm.ko 11 1 0xffffffff80c2f000 e38 pcf.ko 12 1 0xffffffff80c30000 b83 lpbb.ko 13 1 0xffffffff80c31000 368b ppbus.ko 14 1 0xffffffff80c35000 262a viapm.ko Could it be, that the motherboard simply does not have the iic-circuitry and that some other method has to be used? Thanks! Yours, -mi From owner-freebsd-hardware@FreeBSD.ORG Tue Dec 7 02:47:31 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA3C106566B; Tue, 7 Dec 2010 02:47:31 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id 260F08FC0A; Tue, 7 Dec 2010 02:47:30 +0000 (UTC) Received: from [192.168.1.8] ([unknown] [173.70.194.135]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LD100FFXEEGIXD4@vms173005.mailsrvcs.net>; Mon, 06 Dec 2010 20:47:10 -0600 (CST) Message-id: <4CFDA038.3010709@aldan.algebra.com> Date: Mon, 06 Dec 2010 21:47:20 -0500 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; uk-UA; rv:1.9.2.12) Gecko/20101114 Thunderbird/3.1.6 MIME-version: 1.0 To: Andriy Gapon References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> <4CFD5006.7010303@aldan.algebra.com> <4CFD6BA3.7070505@freebsd.org> <4CFD6D2F.6090304@aldan.algebra.com> <4CFD6F75.10003@freebsd.org> In-reply-to: <4CFD6F75.10003@freebsd.org> Content-type: multipart/mixed; boundary=------------070603080101070608030509 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: questions@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 02:47:31 -0000 This is a multi-part message in MIME format. --------------070603080101070608030509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06.12.2010 18:19, Andriy Gapon wrote: > Another possibility is that a driver that should be able to handle your hardwre > just doesn't know the particular IDs. > > pciconf -lv output could shed some light. Attached -- it is a "vanilla" PowerEdge 2900 with just one add-on card -- audio... Thanks! Yours, -mi --------------070603080101070608030509 Content-Type: text/plain; name="PowerEdge2900.pciconf-lv.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="PowerEdge2900.pciconf-lv.txt" hostb0@pci0:0:0:0: class=0x060000 card=0x80868086 chip=0x25c08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000X Chipset Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x25e28086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 2' class = bridge subclass = PCI-PCI pcib8@pci0:0:3:0: class=0x060400 card=0x00000000 chip=0x25e38086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 3' class = bridge subclass = PCI-PCI pcib9@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x25e48086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 4' class = bridge subclass = PCI-PCI pcib10@pci0:0:5:0: class=0x060400 card=0x00000000 chip=0x25e58086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 5' class = bridge subclass = PCI-PCI pcib12@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x25f98086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x8 Port 6-7' class = bridge subclass = PCI-PCI pcib13@pci0:0:7:0: class=0x060400 card=0x00000000 chip=0x25e78086 rev=0x12 hdr=0x01 vendor = 'Intel Corporation' device = '5000 Series Chipset PCIe x4 Port 7' class = bridge subclass = PCI-PCI none0@pci0:0:8:0: class=0x088000 card=0x80868086 chip=0x1a388086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset DMA Engine (5000P)' class = base peripheral hostb1@pci0:0:16:0: class=0x060000 card=0x01b11028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb2@pci0:0:16:1: class=0x060000 card=0x01b11028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb3@pci0:0:16:2: class=0x060000 card=0x01b11028 chip=0x25f08086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Error Reporting Registers' class = bridge subclass = HOST-PCI hostb4@pci0:0:17:0: class=0x060000 card=0x80868086 chip=0x25f18086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Reserved Registers' class = bridge subclass = HOST-PCI hostb5@pci0:0:19:0: class=0x060000 card=0x80868086 chip=0x25f38086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset Reserved Registers' class = bridge subclass = HOST-PCI hostb6@pci0:0:21:0: class=0x060000 card=0x80868086 chip=0x25f58086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset FBD Registers' class = bridge subclass = HOST-PCI hostb7@pci0:0:22:0: class=0x060000 card=0x80868086 chip=0x25f68086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = '5000 Series Chipset FBD Registers' class = bridge subclass = HOST-PCI pcib14@pci0:0:28:0: class=0x060400 card=0x01b11028 chip=0x26908086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 PCIe Root Port 1' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x01b11028 chip=0x26888086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller *1' class = serial bus subclass = USB uhci1@pci0:0:29:1: class=0x0c0300 card=0x01b11028 chip=0x26898086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller *2' class = serial bus subclass = USB uhci2@pci0:0:29:2: class=0x0c0300 card=0x01b11028 chip=0x268a8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller *3' class = serial bus subclass = USB uhci3@pci0:0:29:3: class=0x0c0300 card=0x01b11028 chip=0x268b8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB Universal Host Controller *4' class = serial bus subclass = USB ehci0@pci0:0:29:7: class=0x0c0320 card=0x01b11028 chip=0x268c8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Chipset USB2 Enhanced Host Controller' class = serial bus subclass = USB pcib16@pci0:0:30:0: class=0x060401 card=0x00000000 chip=0x244e8086 rev=0xd9 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x26708086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'LPC Interface Controller (631xESB/6321ESB/3100 )' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x01b11028 chip=0x269e8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Ultra ATA Storage Controller' class = mass storage subclass = ATA atapci1@pci0:0:31:2: class=0x01018f card=0x01b11028 chip=0x26808086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '631xESB/632xESB/3100 Serial ATA Storage Controller' class = mass storage subclass = ATA pcib2@pci0:5:0:0: class=0x060400 card=0x00000000 chip=0x35008086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Upstream Port' class = bridge subclass = PCI-PCI pcib7@pci0:5:0:3: class=0x060400 card=0x00000000 chip=0x350c8086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe to PCI-X Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:6:0:0: class=0x060400 card=0x00000000 chip=0x35108086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Downstream Port E1' class = bridge subclass = PCI-PCI pcib5@pci0:6:1:0: class=0x060400 card=0x00000000 chip=0x35148086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '631xESB/632xESB PCIe Downstream Port E2' class = bridge subclass = PCI-PCI pcib4@pci0:7:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xc2 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'EPB PCIe to PCI-X Bridge' class = bridge subclass = PCI-PCI bce0@pci0:8:0:0: class=0x020000 card=0x01b11028 chip=0x164c14e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' class = network subclass = ethernet pcib6@pci0:9:0:0: class=0x060400 card=0x00101102 chip=0x70061102 rev=0x00 hdr=0x01 vendor = 'Creative Technology LTD.' class = bridge subclass = PCI-PCI hdac0@pci0:10:0:0: class=0x040300 card=0x00181102 chip=0x00091102 rev=0x00 hdr=0x00 vendor = 'Creative Technology LTD.' class = multimedia subclass = HDA pcib11@pci0:1:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge (6702PXH)' class = bridge subclass = PCI-PCI mpt0@pci0:2:8:0: class=0x010000 card=0x1f061028 chip=0x00541000 rev=0x01 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'SAS 3000 series, 8-port with 1068 -StorPort' class = mass storage subclass = SCSI pcib15@pci0:3:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xc2 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'EPB PCIe to PCI-X Bridge' class = bridge subclass = PCI-PCI bce1@pci0:4:0:0: class=0x020000 card=0x01b11028 chip=0x164c14e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)' class = network subclass = ethernet vgapci0@pci0:16:13:0: class=0x030000 card=0x01b11028 chip=0x515e1002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon ES1000 (Radeon ES1000)' class = display subclass = VGA --------------070603080101070608030509-- From owner-freebsd-hardware@FreeBSD.ORG Tue Dec 7 06:29:07 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29AC51065673; Tue, 7 Dec 2010 06:29:07 +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 3F78B8FC15; Tue, 7 Dec 2010 06:29:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA23250; Tue, 07 Dec 2010 08:29:00 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPr2q-000GOI-04; Tue, 07 Dec 2010 08:29:00 +0200 Message-ID: <4CFDD42A.9020109@freebsd.org> Date: Tue, 07 Dec 2010 08:28:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> <4CFD3EC0.1060600@fuckner.net> <4CFD5006.7010303@aldan.algebra.com> <4CFD6BA3.7070505@freebsd.org> <4CFD6D2F.6090304@aldan.algebra.com> <4CFD6F75.10003@freebsd.org> <4CFDA038.3010709@aldan.algebra.com> In-Reply-To: <4CFDA038.3010709@aldan.algebra.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: questions@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 06:29:07 -0000 on 07/12/2010 04:47 Mikhail T. said the following: > On 06.12.2010 18:19, Andriy Gapon wrote: >> Another possibility is that a driver that should be able to handle your hardwre >> just doesn't know the particular IDs. >> >> pciconf -lv output could shed some light. > Attached -- it is a "vanilla" PowerEdge 2900 with just one add-on card -- audio... Looks like no SMBus device indeed. -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Tue Dec 7 10:25:51 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 749BD106564A; Tue, 7 Dec 2010 10:25:51 +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 8AD778FC14; Tue, 7 Dec 2010 10:25:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28712; Tue, 07 Dec 2010 12:25:44 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PPujv-000GhM-Tt; Tue, 07 Dec 2010 12:25:43 +0200 Message-ID: <4CFE0BA7.8080003@freebsd.org> Date: Tue, 07 Dec 2010 12:25:43 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "O. Hartmann" References: <4CFC910A.5090806@aldan.algebra.com> <4CFCDA96.8040803@freebsd.org> <4CFD2D25.8090607@aldan.algebra.com> <4CFE071B.3080409@mail.zedat.fu-berlin.de> In-Reply-To: <4CFE071B.3080409@mail.zedat.fu-berlin.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: "Mikhail T." , netchild@freebsd.org, hardware@freebsd.org Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 10:25:51 -0000 on 07/12/2010 12:06 O. Hartmann said the following: > On 12/06/10 19:36, Mikhail T. wrote: > >> Is not it just like Linux, that one needs to get patches from here and >> there to get going :-\ ? > > Not anymore, Mikhail, it is in these day the other way around :-( Oh, come on, please don't start this bullshit. -- Andriy Gapon From owner-freebsd-hardware@FreeBSD.ORG Tue Dec 7 10:27:33 2010 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336AA1065672; Tue, 7 Dec 2010 10:27:33 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E31088FC15; Tue, 7 Dec 2010 10:27:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1PPuR9-0004tI-D2>; Tue, 07 Dec 2010 11:06:19 +0100 Received: from e178020251.adsl.alicedsl.de ([85.178.20.251] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1PPuR9-00005W-Aj>; Tue, 07 Dec 2010 11:06:19 +0100 Message-ID: <4CFE071B.3080409@mail.zedat.fu-berlin.de> Date: Tue, 07 Dec 2010 11:06:19 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101127 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Mikhail T." References: <4CFC910A.5090806@aldan.algebra.com> <4CFCDA96.8040803@freebsd.org> <4CFD2D25.8090607@aldan.algebra.com> In-Reply-To: <4CFD2D25.8090607@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.20.251 Cc: netchild@freebsd.org, hardware@freebsd.org, Andriy Gapon Subject: Re: monitoring hardware temperatures X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 10:27:33 -0000 On 12/06/10 19:36, Mikhail T. wrote: > Is not it just like Linux, that one needs to get patches from here and > there to get going :-\ ? > > -mi Not anymore, Mikhail, it is in these day the other way around :-( Oliver From owner-freebsd-hardware@FreeBSD.ORG Wed Dec 8 22:30:34 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5EE710656C7 for ; Wed, 8 Dec 2010 22:30:34 +0000 (UTC) (envelope-from mlindgren@runelind.net) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.216.177]) by mx1.freebsd.org (Postfix) with ESMTP id 884AC8FC16 for ; Wed, 8 Dec 2010 22:30:34 +0000 (UTC) Received: by qyk27 with SMTP id 27so1118034qyk.15 for ; Wed, 08 Dec 2010 14:30:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.6.65 with SMTP id 1mr4905292qay.244.1291845762572; Wed, 08 Dec 2010 14:02:42 -0800 (PST) Received: by 10.220.192.198 with HTTP; Wed, 8 Dec 2010 14:02:42 -0800 (PST) X-Originating-IP: [67.161.148.209] Date: Wed, 8 Dec 2010 15:02:42 -0700 Message-ID: From: Mattias Lindgren To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Poor / buggy performance with the mpt driver in 8.1 AMD64? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 22:30:34 -0000 I have 8 Seagate SATA disks connected to an intel branded LSI 3081E SAS controller (Intel SASUC8I). I have 4 of the 1.5T disks and I have 4 2T disks (both are the LP 5900RPM variety) in a pair of raidz1s in a ZFS pool. Doing simple dd writes and reads I get about 80MByte write and 150MByte read which seems very very slow to me. I'm also getting errors from mpt on boot: #dmesg |grep mpt mpt0: port 0xc800-0xc8ff mem 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.19.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) da0 at mpt0 bus 0 scbus0 target 0 lun 0 da1 at mpt0 bus 0 scbus0 target 1 lun 0 da2 at mpt0 bus 0 scbus0 target 2 lun 0 da3 at mpt0 bus 0 scbus0 target 3 lun 0 da4 at mpt0 bus 0 scbus0 target 4 lun 0 da5 at mpt0 bus 0 scbus0 target 5 lun 0 da6 at mpt0 bus 0 scbus0 target 6 lun 0 da7 at mpt0 bus 0 scbus0 target 7 lun 0 mpt0: request 0xffffff80003aedc0:8885 timed out for ccb 0xffffff00020a7800 (req->ccb 0xffffff00020a7800) mpt0: attempting to abort req 0xffffff80003aedc0:8885 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xffffff80003aedc0:8885 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: request 0xffffff80003b6110:9108 timed out for ccb 0xffffff00085fc800 (req->ccb 0xffffff00085fc800) mpt0: attempting to abort req 0xffffff80003b6110:9108 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xffffff80003b6110:9108 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: request 0xffffff80003ac8a0:9287 timed out for ccb 0xffffff000857d000 (req->ccb 0xffffff000857d000) mpt0: attempting to abort req 0xffffff80003ac8a0:9287 function 0 mpt0: mpt_wait_req(1) timed out mpt0: mpt_recover_commands: abort timed-out. Resetting controller mpt0: mpt_cam_event: 0x0 mpt0: completing timedout/aborted req 0xffffff80003ac8a0:9287 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 etc I'm running a vanilla version of FreeBSD with no special kernel patches. FreeBSD beastie 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 I have the following in /boot/loader.conf per the FreeBSD ZFS tuning guide pertaining to NFS shares: vfs.zfs.zil_disable="1" Does anyone have any thoughts on getting rid of the cam event error as well as my performance numbers? Other people with comparable systems are reporting dd numbers that are twice what I'm seeing. From owner-freebsd-hardware@FreeBSD.ORG Thu Dec 9 08:16:10 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057E31065672 for ; Thu, 9 Dec 2010 08:16:10 +0000 (UTC) (envelope-from dean@fragfest.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 84F5E8FC16 for ; Thu, 9 Dec 2010 08:16:09 +0000 (UTC) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB96BeIY027489 for ; Thu, 9 Dec 2010 17:11:40 +1100 Received: from [172.29.0.102] (c122-106-145-234.carlnfd1.nsw.optusnet.com.au [122.106.145.234]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB96BVgM029790 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 9 Dec 2010 17:11:33 +1100 Message-ID: <4D00733C.3040809@fragfest.com.au> Date: Thu, 09 Dec 2010 17:12:12 +1100 From: Dean Hamstead User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Poor / buggy performance with the mpt driver in 8.1 AMD64? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 08:16:10 -0000 My experience is that ZFS performance is miserable compared to UFS. I found that GEOM raid5 with UFS was more than 2x faster than ZFS on the same controller, same disks etc. That aside, something looks seriously screwy with your raid card. I assume youve covered the basics? update the firmware, check cables etc? Youre confident that the hard is in the right mode? That all firmware settings of the card are reasonably sane? Dean On 09/12/10 09:02, Mattias Lindgren wrote: > I have 8 Seagate SATA disks connected to an intel branded LSI 3081E > SAS controller (Intel SASUC8I). I have 4 of the 1.5T disks and I have > 4 2T disks (both are the LP 5900RPM variety) in a pair of raidz1s in a > ZFS pool. Doing simple dd writes and reads I get about 80MByte write > and 150MByte read which seems very very slow to me. I'm also getting > errors from mpt on boot: > > #dmesg |grep mpt > > mpt0: port 0xc800-0xc8ff mem > 0xfe9fc000-0xfe9fffff,0xfe9e0000-0xfe9effff irq 16 at device 0.0 on > pci1 > mpt0: [ITHREAD] > mpt0: MPI Version=1.5.19.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 0 Active Volumes (2 Max) > mpt0: 0 Hidden Drive Members (14 Max) > da0 at mpt0 bus 0 scbus0 target 0 lun 0 > da1 at mpt0 bus 0 scbus0 target 1 lun 0 > da2 at mpt0 bus 0 scbus0 target 2 lun 0 > da3 at mpt0 bus 0 scbus0 target 3 lun 0 > da4 at mpt0 bus 0 scbus0 target 4 lun 0 > da5 at mpt0 bus 0 scbus0 target 5 lun 0 > da6 at mpt0 bus 0 scbus0 target 6 lun 0 > da7 at mpt0 bus 0 scbus0 target 7 lun 0 > mpt0: request 0xffffff80003aedc0:8885 timed out for ccb > 0xffffff00020a7800 (req->ccb 0xffffff00020a7800) > mpt0: attempting to abort req 0xffffff80003aedc0:8885 function 0 > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_recover_commands: abort timed-out. Resetting controller > mpt0: mpt_cam_event: 0x0 > mpt0: mpt_cam_event: 0x0 > mpt0: completing timedout/aborted req 0xffffff80003aedc0:8885 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > mpt0: request 0xffffff80003b6110:9108 timed out for ccb > 0xffffff00085fc800 (req->ccb 0xffffff00085fc800) > mpt0: attempting to abort req 0xffffff80003b6110:9108 function 0 > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_recover_commands: abort timed-out. Resetting controller > mpt0: mpt_cam_event: 0x0 > mpt0: completing timedout/aborted req 0xffffff80003b6110:9108 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > mpt0: request 0xffffff80003ac8a0:9287 timed out for ccb > 0xffffff000857d000 (req->ccb 0xffffff000857d000) > mpt0: attempting to abort req 0xffffff80003ac8a0:9287 function 0 > mpt0: mpt_wait_req(1) timed out > mpt0: mpt_recover_commands: abort timed-out. Resetting controller > mpt0: mpt_cam_event: 0x0 > mpt0: completing timedout/aborted req 0xffffff80003ac8a0:9287 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x16 > mpt0: mpt_cam_event: 0x12 > mpt0: mpt_cam_event: 0x12 > > etc > > I'm running a vanilla version of FreeBSD with no special kernel patches. > > FreeBSD beastie 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 > 02:36:49 UTC 2010 > root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > I have the following in /boot/loader.conf per the FreeBSD ZFS tuning > guide pertaining to NFS shares: > > vfs.zfs.zil_disable="1" > > Does anyone have any thoughts on getting rid of the cam event error as > well as my performance numbers? Other people with comparable systems > are reporting dd numbers that are twice what I'm seeing. > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > From owner-freebsd-hardware@FreeBSD.ORG Fri Dec 10 09:38:44 2010 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A63CC1065670 for ; Fri, 10 Dec 2010 09:38:44 +0000 (UTC) (envelope-from freebsd-hardware@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A25418FC18 for ; Fri, 10 Dec 2010 09:38:43 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PQzR4-0000H4-Ar for freebsd-hardware@freebsd.org; Fri, 10 Dec 2010 10:38:42 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Dec 2010 10:38:42 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Dec 2010 10:38:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hardware@freebsd.org From: Ivan Voras Date: Fri, 10 Dec 2010 10:38:28 +0100 Lines: 17 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: Poor / buggy performance with the mpt driver in 8.1 AMD64? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 09:38:44 -0000 On 12/08/10 23:02, Mattias Lindgren wrote: > I have 8 Seagate SATA disks connected to an intel branded LSI 3081E > SAS controller (Intel SASUC8I). I have 4 of the 1.5T disks and I have > 4 2T disks (both are the LP 5900RPM variety) in a pair of raidz1s in a > ZFS pool. Doing simple dd writes and reads I get about 80MByte write > and 150MByte read which seems very very slow to me. I'm also getting > errors from mpt on boot: Such large difference between read and write, together with the slow rotation speed of your drives could indicate that you have 4K sector drive. Can you confirm this? (report what "diskinfo -v " outputs, but you'll probably also have to lookup on the drives themselves or on the net for the specific model you have). If so, until FreeBSD gets this right (heh), you will have to do this dance with your drives to make ZFS 4K-aligned. But first, try figuring out if the drives are 4K.