From owner-freebsd-hardware@FreeBSD.ORG Sun Apr 11 19:25:08 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 804B0106564A; Sun, 11 Apr 2010 19:25:08 +0000 (UTC) (envelope-from cnst@FreeBSD.org) Received: from hita.home.const.name (dale.cnst.cs.uwaterloo.ca [129.97.7.219]) by mx1.freebsd.org (Postfix) with ESMTP id E79028FC14; Sun, 11 Apr 2010 19:25:07 +0000 (UTC) Received: from dale.cnst.cs.uwaterloo.ca (localhost [127.0.0.1]) by hita.home.const.name (8.14.3/8.14.3) with ESMTP id o3BJOowt001457; Sun, 11 Apr 2010 15:24:50 -0400 (EDT) (envelope-from cnst@FreeBSD.org) Received: (from constant@localhost) by dale.cnst.cs.uwaterloo.ca (8.14.3/8.14.3/Submit) id o3BJOn3p001456; Sun, 11 Apr 2010 15:24:49 -0400 (EDT) (envelope-from cnst@FreeBSD.org) X-Authentication-Warning: dale.cnst.cs.uwaterloo.ca: constant set sender to cnst@FreeBSD.org using -f Date: Sun, 11 Apr 2010 15:24:49 -0400 From: "Constantine A. Murenin" To: "M. Warner Losh" Message-ID: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> References: <20100405055947.GA3544@hita.home.const.name> <20100406.074313.364718154403381345.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20100406.074313.364718154403381345.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Organization: David R. Cheriton School of Computer Science, Faculty of Mathematics, University of Waterloo X-Postal-Address: Constantine A. Murenin, David R. Cheriton School of Computer Science, University of Waterloo, 200 University Avenue West, Waterloo, Ontario N2L 3G1 Canada X-Office-Phone: +1-519-888-4567 x33581 X-Mobile-Phone: +1-K1W-ST1-CNST X-WWW: http://Constantine.SU/ X-LinkedIn: http://www.linkedin.com/in/mureninc Cc: freebsd-acpi@FreeBSD.org, "Constantine A. Murenin" , rpaulo@FreeBSD.org, freebsd-drivers@FreeBSD.org, freebsd-hardware@FreeBSD.org Subject: Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) Hardware Monitor 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: Sun, 11 Apr 2010 19:25:08 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Tue, Apr 06, 2010 at 07:43:13AM -0600, M. Warner Losh wrote: > In message: > Rui Paulo writes: > : Hi, > : > : On 5 Apr 2010, at 06:59, Constantine A. Murenin wrote: > : > : > Dear freebsd-{acpi,drivers,hardware}@, > : > > : > Attached patch provides support for the hardware monitoring capabilities that are present in many modern desktop motherboards from ASUS featuring the ATK0110 ACPI device. > : > > : > This driver, aibs(4), is a fresh replacement for FreeBSD's existing acpi_aiboost(4). The new aibs(4) driver has the following advantages when compared to the old acpi_aiboost(4): > : > * the sensors are now provided through the user-serviceable hw.acpi.aibs0 tree (with a subtree for each sensor type), instead of the Newbus-internal dev.acpi_aiboost.0 tree that contains various nonprime data at the same level as the actual sensors > : > : I was under the impression that this the right way in FreeBSD. > > To be clear, this is a regression. They should be through the dev > tree. We've been migrating exposed functionality from the hw. tree to > the dev. tree for quite some time now. hw. isn't any more > user-serviceable than dev. is. > > Warner Thanks for your comments. But what about the %desc, %driver, %location, %pnpinfo and %parent leaves that, for example, appear under the dev.aibs.0 tree? Don't they introduce the perception that the dev tree is not really user-serviceable, as most of the tree is practically entirely useless for the end-user? Is there, or should there be, a way to tell sysctl(8) to not print such %driver leaves under the dev tree? I've simply used acpi_thermal.c as the exemplar for hw.acpi attachment, as I've found it to produce more elegant results than the dev attachment. Should acpi_thermal be also converted to use the dev tree? I can write a patch. In any case, I've modified aibs(4) to now use its dev tree (see the patch inline); aibs(4) is now even smaller than it was before, still supporting several additional features: > ll /usr/c/src/sys/dev/acpi_support/{acpi_aiboost,atk0110}.c -rw-r--r-- 1 constant wheel 8919 Apr 3 20:31 /usr/c/src/sys/dev/acpi_support/acpi_aiboost.c -rw-r--r-- 1 constant wheel 8299 Apr 11 12:29 /usr/c/src/sys/dev/acpi_support/atk0110.c > ll /boot/kernel/*aib*s* -r-xr-xr-x 1 root wheel 11581 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko -r-xr-xr-x 1 root wheel 24504 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko.symbols -r-xr-xr-x 1 root wheel 9801 Apr 11 12:57 /boot/kernel/aibs.ko -r-xr-xr-x 1 root wheel 21203 Apr 11 12:57 /boot/kernel/aibs.ko.symbols > sysctl dev.aibs.0.{volt,temp,fan} dev.aibs.0.volt.0: 1240 850 1600 dev.aibs.0.volt.1: 3312 2970 3630 dev.aibs.0.volt.2: 5017 4500 5500 dev.aibs.0.volt.3: 12302 10200 13800 dev.aibs.0.temp.0: 30.0C 80.0C 95.0C dev.aibs.0.temp.1: 56.0C 60.0C 95.0C dev.aibs.0.fan.0: 878 600 7200 dev.aibs.0.fan.1: 0 700 7200 Best regards, Constantine. --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="svn_diff.aibs.r0.2010-04-11T123857-0400.dev.patch" Index: share/man/man4/aibs.4 =================================================================== --- share/man/man4/aibs.4 (revision 0) +++ share/man/man4/aibs.4 (revision 0) @@ -0,0 +1,209 @@ +.\" $FreeBSD$ +.\" $NetBSD: aibs.4,v 1.2 2010/02/09 05:37:25 cnst Exp $ +.\" $OpenBSD: aibs.4,v 1.4 2009/07/30 06:30:45 jmc Exp $ +.\" +.\" Copyright (c) 2009/2010 Constantine A. Murenin +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd April 4, 2010 +.Dt AIBS 4 +.Os +.Sh NAME +.Nm aibs +.Nd "ASUSTeK AI Booster ACPI ATK0110 voltage, temperature and fan sensor" +.Sh SYNOPSIS +To compile this driver into the kernel, +place the following lines in your +kernel configuration file: +.Bd -ragged -offset indent +.Cd "device acpi" +.Cd "device aibs" +.Ed +.Pp +Alternatively, to load the driver as a +module at boot time, place the following lines in +.Xr loader.conf 5 : +.Bd -literal -offset indent +acpi_load="YES" +aibs_load="YES" +.Ed +.Sh DESCRIPTION +The +.Nm +driver provides support for the voltage, temperature and fan sensors +available through the +.Tn ATK0110 +.Tn ASOC +.Tn ACPI +device +on +.Tn ASUSTeK +motherboards. +The number of sensors of each type, +as well as the description of each sensor, +varies according to the motherboard. +.Pp +The driver supports an arbitrary set of sensors, +provides descriptions regarding what each sensor is used for, +and reports the current values as well as +the supposed range specifications of each sensor's input +as defined by the motherboard manufacturer through +.Tn ACPI . +.Pp +The range specifications are as follows: +.Bl -bullet +.It +Voltage sensors have a lower and an upper range specification. +.It +Temperature sensors have two upper specifications. +.It +Fan sensors may either have only the lower specification, +or, depending on the +.Tn DSDT , +one lower and one upper specification. +.El +.Pp +Sensor readings and the range specifications are made available through the +.Xr sysctl 3 +interface, +and can be monitored with +.Xr sysctl 8 . +For example, on an ASUS V3-P5G965 barebone: +.Bd -literal -offset indent +> sysctl dev.aibs.0.{volt,temp,fan} +dev.aibs.0.volt.0: 1192 850 1600 +dev.aibs.0.volt.1: 3312 2970 3630 +dev.aibs.0.volt.2: 5017 4500 5500 +dev.aibs.0.volt.3: 12302 10200 13800 +dev.aibs.0.temp.0: 28.0C 80.0C 95.0C +dev.aibs.0.temp.1: 55.0C 60.0C 95.0C +dev.aibs.0.fan.0: 878 600 7200 +dev.aibs.0.fan.1: 0 700 7200 +.Pp +> sysctl -d dev.aibs.0.{volt,temp,fan} +dev.aibs.0.volt: +dev.aibs.0.volt.0: Vcore Voltage +dev.aibs.0.volt.1: +3.3 Voltage +dev.aibs.0.volt.2: +5 Voltage +dev.aibs.0.volt.3: +12 Voltage +dev.aibs.0.temp: +dev.aibs.0.temp.0: CPU Temperature +dev.aibs.0.temp.1: MB Temperature +dev.aibs.0.fan: +dev.aibs.0.fan.0: CPU FAN Speed +dev.aibs.0.fan.1: CHASSIS FAN Speed +.Ed +.Pp +Generally, sensors provided by the +.Nm +driver may also be supported by certain other drivers or utilities +that access the +.Tn ISA / +.Tn LPC +or +.Tn I2C / +.Tn SMBus +devices directly. +The precise collection of +.Nm +sensors is comprised of the sensors +specifically utilised in the motherboard +design, which may be supported through +a combination of one or more physical hardware monitoring chips. +.Pp +The +.Nm +driver, however, provides the following advantages +when compared to the native hardware monitoring drivers or other utilities: +.Bl -bullet +.It +Sensor values from +.Nm +are expected to be more reliable. +For example, voltage sensors in many hardware monitoring chips +can only sense voltage from 0 to 2 or 4 volts, and the excessive +voltage is removed by the resistors, which may vary with the motherboard +and with the voltage that is being sensed. +In +.Nm , +the required resistor factors are provided by +the motherboard manufacturer through +.Tn ACPI ; +in the native drivers, the resistor factors +are encoded into the driver based on the chip manufacturer's recommendations. +In essence, sensor values from +.Nm +are very likely to be identical to the readings from the +Hardware Monitor screen in the BIOS. +.It +Sensor descriptions from +.Nm +are more likely to match the markings on the motherboard. +.It +Sensor range specifications are supported by +.Nm . +The range specification is reported +for each individual sensor as suggested by the motherboard manufacturer. +For example, the threshold for the CPU temperature sensor is likely +to be significantly higher than that for the chassis temperature sensor. +.It +Support for newer chips in +.Nm . +Newer chips may miss a native driver, +but should be supported through +.Nm +regardless. +.El +.Sh SEE ALSO +.Xr sysctl 3 , +.Xr acpi 4 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 4.7 , +.Dx 2.5 , +.Nx 6.0 +and +.Fx 9.0 . +.Pp +An earlier version of the driver, +.Nm acpi_aiboost , +first appeared in +.Fx 7.0 +and +.Nx 5.0 . +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written for +.Ox , +.Dx , +.Nx +and +.Fx +by +.An Constantine A. Murenin Aq cnst@FreeBSD.org , +Raouf Boutaba Research Group, +David R. Cheriton School of Computer Science, +University of Waterloo. +.Pp +An earlier version of the driver, named +.Nm acpi_aiboost , +was written for +.Fx +by +.An Takanori Watanabe . Index: share/man/man4/Makefile =================================================================== --- share/man/man4/Makefile (revision 206482) +++ share/man/man4/Makefile (working copy) @@ -26,6 +26,7 @@ ahc.4 \ ahci.4 \ ahd.4 \ + ${_aibs.4} \ aio.4 \ alc.4 \ ale.4 \ @@ -629,6 +630,7 @@ _acpi_sony.4= acpi_sony.4 _acpi_toshiba.4=acpi_toshiba.4 _acpi_wmi.4= acpi_wmi.4 +_aibs.4= aibs.4 _amdsbwd.4= amdsbwd.4 _amdsmb.4= amdsmb.4 _amdtemp.4= amdtemp.4 Index: sys/conf/files =================================================================== --- sys/conf/files (revision 206482) +++ sys/conf/files (working copy) @@ -416,6 +416,7 @@ dev/acpi_support/acpi_panasonic.c optional acpi_panasonic acpi dev/acpi_support/acpi_sony.c optional acpi_sony acpi dev/acpi_support/acpi_toshiba.c optional acpi_toshiba acpi +dev/acpi_support/atk0110.c optional aibs acpi dev/acpica/Osd/OsdDebug.c optional acpi dev/acpica/Osd/OsdHardware.c optional acpi dev/acpica/Osd/OsdInterrupt.c optional acpi Index: sys/modules/acpi/Makefile =================================================================== --- sys/modules/acpi/Makefile (revision 206482) +++ sys/modules/acpi/Makefile (working copy) @@ -6,6 +6,6 @@ SUBDIR+= acpi_aiboost acpi_asus acpi_fujitsu acpi_hp acpi_ibm \ acpi_panasonic acpi_sony acpi_toshiba acpi_video \ - acpi_dock acpi_wmi + acpi_dock acpi_wmi aibs .include Index: sys/modules/acpi/aibs/Makefile =================================================================== --- sys/modules/acpi/aibs/Makefile (revision 0) +++ sys/modules/acpi/aibs/Makefile (revision 0) @@ -0,0 +1,10 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../dev/acpi_support + +KMOD= aibs +SRCS= atk0110.c +SRCS+= opt_acpi.h acpi_if.h bus_if.h device_if.h +SRCS+= opt_ddb.h + +.include Index: sys/dev/acpi_support/atk0110.c =================================================================== --- sys/dev/acpi_support/atk0110.c (revision 0) +++ sys/dev/acpi_support/atk0110.c (revision 0) @@ -0,0 +1,359 @@ +/* $FreeBSD$ */ +/* $NetBSD: atk0110.c,v 1.4 2010/02/11 06:54:57 cnst Exp $ */ +/* $OpenBSD: atk0110.c,v 1.1 2009/07/23 01:38:16 cnst Exp $ */ + +/* + * Copyright (c) 2009/2010 Constantine A. Murenin + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* + * ASUSTeK AI Booster (ACPI ASOC ATK0110). + * + * This code was originally written for OpenBSD after the techniques + * described in the Linux's asus_atk0110.c and FreeBSD's Takanori Watanabe's + * acpi_aiboost.c were verified to be accurate on the actual hardware kindly + * provided by Sam Fourman Jr. It was subsequently ported from OpenBSD to + * DragonFly BSD, to NetBSD's sysmon_envsys(9) and to FreeBSD's sysctl(9). + * + * -- Constantine A. Murenin + */ + +#define _COMPONENT ACPI_OEM +ACPI_MODULE_NAME("aibs"); +ACPI_SERIAL_DECL(aibs, "aibs"); + +#define AIBS_MORE_SENSORS +#define AIBS_VERBOSE + +enum aibs_type { + AIBS_VOLT, + AIBS_TEMP, + AIBS_FAN +}; + +struct aibs_sensor { + ACPI_INTEGER v; + ACPI_INTEGER i; + ACPI_INTEGER l; + ACPI_INTEGER h; + enum aibs_type t; +}; + +struct aibs_softc { + struct device *sc_dev; + ACPI_HANDLE sc_ah; + + struct aibs_sensor *sc_asens_volt; + struct aibs_sensor *sc_asens_temp; + struct aibs_sensor *sc_asens_fan; +}; + +static int aibs_probe(device_t); +static int aibs_attach(device_t); +static int aibs_detach(device_t); +static int aibs_sysctl(SYSCTL_HANDLER_ARGS); + +static void aibs_attach_sif(struct aibs_softc *, enum aibs_type); + +static device_method_t aibs_methods[] = { + DEVMETHOD(device_probe,aibs_probe), + DEVMETHOD(device_attach,aibs_attach), + DEVMETHOD(device_detach,aibs_detach), + { NULL, NULL } +}; + +static driver_t aibs_driver = { + "aibs", + aibs_methods, + sizeof(struct aibs_softc) +}; + +static devclass_t aibs_devclass; + +DRIVER_MODULE(aibs, acpi, aibs_driver, aibs_devclass, NULL, NULL); + + +static char* aibs_hids[] = { + "ATK0110", + NULL +}; + +static int +aibs_probe(device_t dev) +{ + if (acpi_disabled("aibs") || + ACPI_ID_PROBE(device_get_parent(dev), dev, aibs_hids) == NULL) + return ENXIO; + + device_set_desc(dev, "ASUSTeK AI Booster (ACPI ASOC ATK0110)"); + return 0; +} + +static int +aibs_attach(device_t dev) +{ + struct aibs_softc *sc = device_get_softc(dev); + + sc->sc_dev = dev; + sc->sc_ah = acpi_get_handle(dev); + + aibs_attach_sif(sc, AIBS_VOLT); + aibs_attach_sif(sc, AIBS_TEMP); + aibs_attach_sif(sc, AIBS_FAN); + + return 0; +} + +static void +aibs_attach_sif(struct aibs_softc *sc, enum aibs_type st) +{ + ACPI_STATUS s; + ACPI_BUFFER b; + ACPI_OBJECT *bp, *o; + int i, n; + const char *node; + char name[] = "?SIF"; + struct aibs_sensor *as; + struct sysctl_oid *so; + + switch (st) { + case AIBS_VOLT: + node = "volt"; + name[0] = 'V'; + break; + case AIBS_TEMP: + node = "temp"; + name[0] = 'T'; + break; + case AIBS_FAN: + node = "fan"; + name[0] = 'F'; + break; + default: + return; + } + + b.Length = ACPI_ALLOCATE_BUFFER; + s = AcpiEvaluateObjectTyped(sc->sc_ah, name, NULL, &b, + ACPI_TYPE_PACKAGE); + if (ACPI_FAILURE(s)) { + device_printf(sc->sc_dev, "%s not found\n", name); + return; + } + + bp = b.Pointer; + o = bp->Package.Elements; + if (o[0].Type != ACPI_TYPE_INTEGER) { + device_printf(sc->sc_dev, "%s[0]: invalid type\n", name); + AcpiOsFree(b.Pointer); + return; + } + + n = o[0].Integer.Value; + if (bp->Package.Count - 1 < n) { + device_printf(sc->sc_dev, "%s: invalid package\n", name); + AcpiOsFree(b.Pointer); + return; + } else if (bp->Package.Count - 1 > n) { + int on = n; + +#ifdef AIBS_MORE_SENSORS + n = bp->Package.Count - 1; +#endif + device_printf(sc->sc_dev, "%s: malformed package: %i/%i" + ", assume %i\n", name, on, bp->Package.Count - 1, n); + } + if (n < 1) { + device_printf(sc->sc_dev, "%s: no members in the package\n", + name); + AcpiOsFree(b.Pointer); + return; + } + + as = malloc(sizeof(*as) * n, M_DEVBUF, M_NOWAIT | M_ZERO); + if (as == NULL) { + device_printf(sc->sc_dev, "%s: malloc fail\n", name); + AcpiOsFree(b.Pointer); + return; + } + switch (st) { + case AIBS_VOLT: + sc->sc_asens_volt = as; + break; + case AIBS_TEMP: + sc->sc_asens_temp = as; + break; + case AIBS_FAN: + sc->sc_asens_fan = as; + break; + } + + /* sysctl subtree for sensors of this type */ + so = SYSCTL_ADD_NODE(device_get_sysctl_ctx(sc->sc_dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(sc->sc_dev)), st, + node, CTLFLAG_RD, NULL, NULL); + + for (i = 0, o++; i < n; i++, o++) { + ACPI_OBJECT *oi; + char si[3]; + const char *desc; + + /* acpica5 automatically evaluates the referenced package */ + if(o[0].Type != ACPI_TYPE_PACKAGE) { + device_printf(sc->sc_dev, + "%s: %i: not a package: %i type\n", + name, i, o[0].Type); + continue; + } + oi = o[0].Package.Elements; + if (o[0].Package.Count != 5 || + oi[0].Type != ACPI_TYPE_INTEGER || + oi[1].Type != ACPI_TYPE_STRING || + oi[2].Type != ACPI_TYPE_INTEGER || + oi[3].Type != ACPI_TYPE_INTEGER || + oi[4].Type != ACPI_TYPE_INTEGER) { + device_printf(sc->sc_dev, + "%s: %i: invalid package\n", + name, i); + continue; + } + as[i].i = oi[0].Integer.Value; + desc = oi[1].String.Pointer; + as[i].l = oi[2].Integer.Value; + as[i].h = oi[3].Integer.Value; + as[i].t = st; +#ifdef AIBS_VERBOSE + device_printf(sc->sc_dev, "%c%i: " + "0x%08"PRIx64" %20s %5"PRIi64" / %5"PRIi64" " + "0x%"PRIx64"\n", + name[0], i, + as[i].i, desc, (int64_t)as[i].l, (int64_t)as[i].h, + oi[4].Integer.Value); +#endif + snprintf(si, sizeof(si), "%i", i); + SYSCTL_ADD_PROC(device_get_sysctl_ctx(sc->sc_dev), + SYSCTL_CHILDREN(so), i, si, CTLTYPE_OPAQUE | CTLFLAG_RD, + sc, st, aibs_sysctl, st == AIBS_TEMP ? "IK" : "I", desc); + } + + AcpiOsFree(b.Pointer); +} + +static int +aibs_detach(device_t dev) +{ + struct aibs_softc *sc = device_get_softc(dev); + + if (sc->sc_asens_volt != NULL) + free(sc->sc_asens_volt, M_DEVBUF); + if (sc->sc_asens_temp != NULL) + free(sc->sc_asens_temp, M_DEVBUF); + if (sc->sc_asens_fan != NULL) + free(sc->sc_asens_fan, M_DEVBUF); + return 0; +} + +#ifdef AIBS_VERBOSE +#define ddevice_printf(x...) device_printf(x) +#else +#define ddevice_printf(x...) +#endif + +static int +aibs_sysctl(SYSCTL_HANDLER_ARGS) +{ + struct aibs_softc *sc = arg1; + enum aibs_type st = arg2; + int i = oidp->oid_number; + ACPI_STATUS rs; + ACPI_OBJECT p, *bp; + ACPI_OBJECT_LIST mp; + ACPI_BUFFER b; + char *name; + struct aibs_sensor *as; + ACPI_INTEGER v, l, h; + int so[3]; + + switch (st) { + case AIBS_VOLT: + name = "RVLT"; + as = sc->sc_asens_volt; + break; + case AIBS_TEMP: + name = "RTMP"; + as = sc->sc_asens_temp; + break; + case AIBS_FAN: + name = "RFAN"; + as = sc->sc_asens_fan; + break; + default: + return ENOENT; + } + if (as == NULL) + return ENOENT; + l = as[i].l; + h = as[i].h; + p.Type = ACPI_TYPE_INTEGER; + p.Integer.Value = as[i].i; + mp.Count = 1; + mp.Pointer = &p; + b.Length = ACPI_ALLOCATE_BUFFER; + ACPI_SERIAL_BEGIN(aibs); + rs = AcpiEvaluateObjectTyped(sc->sc_ah, name, &mp, &b, + ACPI_TYPE_INTEGER); + if (ACPI_FAILURE(rs)) { + ddevice_printf(sc->sc_dev, + "%s: %i: evaluation failed\n", + name, i); + ACPI_SERIAL_END(aibs); + return EIO; + } + bp = b.Pointer; + v = bp->Integer.Value; + AcpiOsFree(b.Pointer); + ACPI_SERIAL_END(aibs); + + switch (st) { + case AIBS_VOLT: + break; + case AIBS_TEMP: + v += 2732; + l += 2732; + h += 2732; + break; + case AIBS_FAN: + break; + } + so[0] = v; + so[1] = l; + so[2] = h; + return sysctl_handle_opaque(oidp, &so, sizeof(so), req); +} Index: sys/i386/conf/NOTES =================================================================== --- sys/i386/conf/NOTES (revision 206482) +++ sys/i386/conf/NOTES (working copy) @@ -506,6 +506,9 @@ # ACPI Docking Station device acpi_dock +# ACPI ASOC ATK0110 ASUSTeK AI Booster (voltage, temperature and fan sensors) +device aibs + # The cpufreq(4) driver provides support for non-ACPI CPU frequency control device cpufreq --gBBFr7Ir9EOA20Yy-- From owner-freebsd-hardware@FreeBSD.ORG Sun Apr 11 20:08:14 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 0954C106566C; Sun, 11 Apr 2010 20:08:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 761118FC13; Sun, 11 Apr 2010 20:08:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o3BK0dl4093898; Sun, 11 Apr 2010 14:00:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 11 Apr 2010 14:00:47 -0600 (MDT) Message-Id: <20100411.140047.527849116143353707.imp@bsdimp.com> To: cnst@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> References: <20100406.074313.364718154403381345.imp@bsdimp.com> <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, rpaulo@FreeBSD.org, freebsd-drivers@FreeBSD.org, freebsd-hardware@FreeBSD.org Subject: Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) Hardware Monitor 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: Sun, 11 Apr 2010 20:08:14 -0000 In message: <20100411192449.GA1367@dale.cnst.cs.uwaterloo.ca> "Constantine A. Murenin" writes: : On Tue, Apr 06, 2010 at 07:43:13AM -0600, M. Warner Losh wrote: : > In message: : > Rui Paulo writes: : > : Hi, : > : : > : On 5 Apr 2010, at 06:59, Constantine A. Murenin wrote: : > : : > : > Dear freebsd-{acpi,drivers,hardware}@, : > : > : > : > Attached patch provides support for the hardware monitoring : > capabilities that are present in many modern desktop motherboards from : > ASUS featuring the ATK0110 ACPI device. : > : > : > : > This driver, aibs(4), is a fresh replacement for FreeBSD's : > existing acpi_aiboost(4). The new aibs(4) driver has the following : > advantages when compared to the old acpi_aiboost(4): : > : > * the sensors are now provided through the user-serviceable : > hw.acpi.aibs0 tree (with a subtree for each sensor type), instead of : > the Newbus-internal dev.acpi_aiboost.0 tree that contains various : > nonprime data at the same level as the actual sensors : > : : > : I was under the impression that this the right way in FreeBSD. : > : > To be clear, this is a regression. They should be through the dev : > tree. We've been migrating exposed functionality from the hw. tree to : > the dev. tree for quite some time now. hw. isn't any more : > user-serviceable than dev. is. : > Warner : : Thanks for your comments. But what about the %desc, %driver, : %location, %pnpinfo and %parent leaves that, for example, appear under : the dev.aibs.0 tree? Yes. They do. : Don't they introduce the perception that the dev : tree is not really user-serviceable, as most of the tree is : practically entirely useless for the end-user? No, they shouldn't. There's documented APIs for hooking into this tree. That sounds like it would be user-serviceable. That certainly was the intent when DES added them. : Is there, or should : there be, a way to tell sysctl(8) to not print such %driver leaves : under the dev tree? sysctl dev.acpi | grep -v % will do the trick. : I've simply used acpi_thermal.c as the exemplar : for hw.acpi attachment, as I've found it to produce more elegant : results than the dev attachment. Should acpi_thermal be also : converted to use the dev tree? I can write a patch. I think it should be. : In any case, I've modified aibs(4) to now use its dev tree (see the : patch inline); aibs(4) is now even smaller than it was before, still : supporting several additional features: Woo Hoo! : > ll /usr/c/src/sys/dev/acpi_support/{acpi_aiboost,atk0110}.c : -rw-r--r-- 1 constant wheel 8919 Apr 3 20:31 : -/usr/c/src/sys/dev/acpi_support/acpi_aiboost.c : -rw-r--r-- 1 constant wheel 8299 Apr 11 12:29 : -/usr/c/src/sys/dev/acpi_support/atk0110.c : > ll /boot/kernel/*aib*s* : -r-xr-xr-x 1 root wheel 11581 Apr 11 12:57 /boot/kernel/acpi_aiboost.ko : -r-xr-xr-x 1 root wheel 24504 Apr 11 12:57 : -/boot/kernel/acpi_aiboost.ko.symbols : -r-xr-xr-x 1 root wheel 9801 Apr 11 12:57 /boot/kernel/aibs.ko : -r-xr-xr-x 1 root wheel 21203 Apr 11 12:57 /boot/kernel/aibs.ko.symbols : > sysctl dev.aibs.0.{volt,temp,fan} : dev.aibs.0.volt.0: 1240 850 1600 : dev.aibs.0.volt.1: 3312 2970 3630 : dev.aibs.0.volt.2: 5017 4500 5500 : dev.aibs.0.volt.3: 12302 10200 13800 : dev.aibs.0.temp.0: 30.0C 80.0C 95.0C : dev.aibs.0.temp.1: 56.0C 60.0C 95.0C : dev.aibs.0.fan.0: 878 600 7200 : dev.aibs.0.fan.1: 0 700 7200 Cool. Warner From owner-freebsd-hardware@FreeBSD.ORG Mon Apr 12 14:20:57 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 63EDC106564A for ; Mon, 12 Apr 2010 14:20:57 +0000 (UTC) (envelope-from freebsd@knarf.de) Received: from mail.server-king.de (mail.server-king.de [188.40.65.110]) by mx1.freebsd.org (Postfix) with ESMTP id B51FE8FC0A for ; Mon, 12 Apr 2010 14:20:56 +0000 (UTC) Received: from cheese.server-king.de (localhost [127.0.0.1]) by mail.server-king.de (8.14.4/8.14.4) with ESMTP id o3CE5i6M099416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Apr 2010 16:05:44 +0200 (CEST) (envelope-from freebsd@knarf.de) DomainKey-Signature: a=rsa-sha1; s=mail.server-king.de; d=knarf.de; c=nofws; q=dns; h=dkim-signature:received: x-authentication-warning:date:from:to:subject:message-id:mime-version:content-type: content-disposition:user-agent:x-greylist; b=xg8y83erF1tDl7osVDC0fdn+0nfjzBqyN1PBtTg2hR7hzvNSibFET7J3oRqtIWq3U X60k7EQzqcEyiePc+yjz+hQENGKqZ+QLs0vUgwW4oQfKi8XQRTetG0mywxbkI8FTTeU ZSpJxDPUBY6VzhGt51D4c8WY9b99HWjwtTpmvnE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=knarf.de; s=mail.server-king.de; t=1271081144; bh=Uj9ycpWHeq0Bbu3yeMBdZt4+xpTXZOoj6W5q8m5iuzo=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=o/CXn5pUh8i/4cbHPduhyvu9yAAeS0GyCmcqHCtv2iZClgP3jjA3qUsNNOikTWKUJ In+xRmFJOLQ6l/Dq+f9AsR1an2dMVW1onYjhXQNf9gJaIOy4ZKxVSG4TCG9uLESbIU 1kMZtywuBUq0E8w/LZDrLIjiU5yjcaAvvgcT5qtY= Received: (from knarf@localhost) by cheese.server-king.de (8.14.4/8.14.4/Submit) id o3CE5iVv099415 for freebsd-hardware@freebsd.org; Mon, 12 Apr 2010 16:05:44 +0200 (CEST) (envelope-from freebsd@knarf.de) X-Authentication-Warning: cheese.server-king.de: knarf set sender to freebsd@knarf.de using -f Date: Mon, 12 Apr 2010 16:05:44 +0200 From: Frank Bartels To: freebsd-hardware@freebsd.org Message-ID: <20100412140543.GA98416@server-king.de> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (mail.server-king.de [127.0.0.1]); Mon, 12 Apr 2010 16:05:44 +0200 (CEST) Subject: hifn(4) (crypto hardware) and geli(8) 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, 12 Apr 2010 14:20:57 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline I've tried a vpn1401 (PCI card) in two different machines (both 8.0-RELEASE-p2, i386 and amd64). I've added hifn_load="YES" to the loader.conf and I saw "GEOM_ELI: Crypto: hardware" during kernel boot. But both systems stopped working when accessing the eli devices (zfs import in my case). The system works fine without the card. Is anybody of you using this card successfully with 8.0-RELEASE? Knarf P.S.: I've tried the FreeBSD forum already without success: http://forums.freebsd.org/showthread.php?t=13080 --WIyZ46R2i8wDzkSu Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRuQYJKoZIhvcNAQcCoIIRqjCCEaYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DxIwggcoMIIGEKADAgECAgIBVjANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBMB4XDTA5MDcyODAwMDAwMVoXDTEwMDcyODIzNTk1OVowgZYxCzAJ BgNVBAYTAkRFMQ8wDQYDVQQIEwZCYXllcm4xEDAOBgNVBAcTB011bmNoZW4xLTArBgNVBAsT JFN0YXJ0Q29tIFZlcmlmaWVkIENlcnRpZmljYXRlIE1lbWJlcjEWMBQGA1UEAxMNRnJhbmsg QmFydGVsczEdMBsGCSqGSIb3DQEJARYOa25hcmZAa25hcmYuZGUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDLWCmP9KDwAsUohjL8tYwuvEVu3pnXZBit+oNuqBTzxC9vcR1C TZau0JZdOl/PTr94TClr0c6a1RntmRv8TFthge51No/zY6gImSe6TDhgvBzj3YTaHDm1Kes2 zZKzvKCW+sbodAGn6KreAbhb9IiJ2QuL3d7yXcbMjfMsRjfFCH/TOuRurjTPNUeEBbxMX0nJ Dpee9GPEbeIYBewjOyNviSfIm4Hy3OQ5GFeyEpo4QQvi4oA2ZJpwfrzTParnRHI34CR8JDQQ WqaFhd/uFOv2SKrFP6d6+BmcPy7pJSk8ItQ0ujQiPo2N4TOn9aT7Qr0kxIi7nzHTKjM7epnA rtFvAgMBAAGjggOGMIIDgjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFHimQ7xUVCq3zdFNCNHFIhmhY5WJMBkGA1Ud EQQSMBCBDmtuYXJmQGtuYXJmLmRlMIGoBgNVHSMEgaAwgZ2AFK5Vg2/sMcq59x36r2sx88gd 46y7oYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEOMIIBRwYDVR0gBIIBPjCCATowggE2Bgsr BgEEAYG1NwECADCCASUwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVk aWF0ZS5wZGYwgbwGCCsGAQUFBwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0 ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUg YXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAn hiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRwOi8v Y3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2Ew QgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIu Y2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQEFBQADggEBAIVekIt/VS99FXJlHosC30Dlv473hPN3TmCgsIUT43YW41sLUihk EaUgSl8YsRA2yR34hePf60W+zws0r/AuPTXRp/1rxwvvov7DeCRaU27QkWNfc0VZ3S8b6Zbm fHjRyPAApwLG4hPnQeIBASnc2HBGTLOWtWRkPKM9dkV46h9j6nOMHSkLZlGqVtlqXJU1rhWX TRww3WFYwRUC7uLqFyXdKjas7OEROiNKzTd5pY3KRz0weBXskU5fFcvw/vG6hm8FILyYR0gS QyRYQV/4GitN36R3/29crCkRZMJxhNI0h2/+L1rfczn69fq4gnPeYYJmlTe0JMcawT6jvayq bP0wggfiMIIFyqADAgECAgEOMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLKIVFnAEs+xny q6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQA7Xj9AGM6wgP hEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQgKO19b+R t8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj113yK Mm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTAD AQH/MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1Ud IwSBoDCBnYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNh dGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmC AQEwCQYDVR0SBAIwADA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYI KwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUF BwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYB BQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xp bWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyog b2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEB BAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEA HvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8pROEc GU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJ SCfB9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt 7KYkJCaTe6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98 p/SwnXito+GW0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkF ojhUqGt+VyU3GH/+BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQP YIu+zpzwWC/8sZFxoJCwvbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh8 6VDNL8bIIQE2LHVDwcOq+mcQx416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302g onaFdwi++YyqjPyhPO6q4fRarYvWyqp5L6UxggJvMIICawIBATCBkzCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgIBVjAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDQxMjE0MDU0M1owIwYJKoZIhvcNAQkE MRYEFN3fZvNpcXJdmapwJMURpjZCkonnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MA0GCSqGSIb3DQEBAQUABIIBAEUfiYcsp0EdoIG0uo2BkDHqkaCq3NQkagcA6QoxlyRlrvkB tnGAwveVc99UorO/9LbGp++8pJWZaewC7nB73vMClm/fVupqJMvdeBF5bbyxlDw/t60/Xlrq TYEleZ55EKZYcuM0yG+IrDwOYn2fWMn5bm+y/jB5BQNnxVKZMMGgE9ArIHbukWeay0aax0G8 7aS8CUj7L6t992WWoftuuoR+cBCkF7a5l1pnXldSB1TPHm15HejgWk3Ld31BdOtd9oJrjdf3 6GH7UDEDk2XyS+k7UnVQM2I+EeWgkbslCLN5ch7/N9/ehLhdr203yW7hywU0n1Lhid3jueRl 7JMxqqU= --WIyZ46R2i8wDzkSu-- From owner-freebsd-hardware@FreeBSD.ORG Wed Apr 14 17:23: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 BAE8B106566B for ; Wed, 14 Apr 2010 17:23:10 +0000 (UTC) (envelope-from seklecki@noc.cfi.pgh.pa.us) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 7E20A8FC19 for ; Wed, 14 Apr 2010 17:23:10 +0000 (UTC) Received: from [127.0.0.1] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 14 Apr 2010 13:33:42 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::359 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-hardware@freebsd.org X-SMFBL: ZnJlZWJzZC1oYXJkd2FyZUBmcmVlYnNkLm9yZw== DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=noc.cfi.pgh.pa.us; s=noc_cfi_pgh_pa_us_key_dkim; l=803; t=1271266422; i=@noc.cfi.pgh.pa.us; h=Message-ID:Date:From: Reply-To:Organization:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=TZ2VakfnaynFC4QSIkZ9OK/mmDU=; b=byKsONIfUDYhK6nDEEPsFpxqGER50 ZTACuh+Bto4m7qNZlVCLrChrUTf1owgTjbQpoG81dLjjzW/mNUaXYq3U8AiJ1PGZ 0WsO2wls9mLsy50OKTl+Q9XPMqfapzOpQxM Message-ID: <4BC5F9EC.1050609@noc.cfi.pgh.pa.us> Date: Wed, 14 Apr 2010 13:22:52 -0400 From: "Brian A. Seklecki (CFI NOC)" Organization: Collaborative Fusion, Inc. (DRP NOC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marco_Gon=E7alves?= References: <4BAB5729.1030207@waynext.com> In-Reply-To: <4BAB5729.1030207@waynext.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-hardware@freebsd.org" Subject: Re: Dell T410 RAID support X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@noc.cfi.pgh.pa.us List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 17:23:10 -0000 On 3/25/2010 8:29 AM, Marco Gonçalves wrote: > Hello, > > we are about to buy a Dell T410 with 5 Hot-Swap ASS R5 with PERC H700 > (Dell PERC 6/i controller). You may have better luck searching for the more-common "R410", rack mount version. There's some discussion on the list about R410 bce(4) problems and the kernel only probing 2 cores. When do you do get a unit working, share your DMESG? http://www.nycbug.org/index.php?NAV=dmesgd;SQLIMIT=20 Thanks, > Is this configuration well supported by the mfi driver? > > Regards, > Marco > _______________________________________________ > 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 Wed Apr 14 17:32:28 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 36A821065670 for ; Wed, 14 Apr 2010 17:32:28 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id ACA848FC0A for ; Wed, 14 Apr 2010 17:32:27 +0000 (UTC) Received: from [127.0.0.1] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 14 Apr 2010 13:43:04 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::360 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-hardware@freebsd.org X-SMFBL: ZnJlZWJzZC1oYXJkd2FyZUBmcmVlYnNkLm9yZw== Message-ID: <4BC5FC29.3030208@spiritual-machines.org> Date: Wed, 14 Apr 2010 13:32:25 -0400 From: "Brian A. Seklecki" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spolyack@gmail.com Subject: 8.0-R/amd64 problems with Dell DRAC4 (8th Gen) 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, 14 Apr 2010 17:32:28 -0000 All: 6 years out, it looks like cd(4)/ata(4) still has problems reading virtual CD media in the Dell PowerEdge DRAC4 LOM. We see ~ 30x of these in dmesg: acd1: WARNING - READ_TOC read data overrun 20>12 Followed by this in sysinstall: "The disc in your drive looks more like an audio disc than a FreeBSD Release" (1). acd1: DVR at ata2-slave PIO3 acd0: CDROM Of course, the BIOS is able to read from the disc and load mfsroot. Maybe a sysctl tweak is needed at loader(8). It just seem like, given the market penetration of PowerEdge 8th gen, this would be behind us. Latest DRAC firmware. ~BAS 1. See screenshot at: http://digitalfreaks.org/~lavalamp/your_installer_looks_more_like_shit_than_a_vanilla_ice_tape.jpg From owner-freebsd-hardware@FreeBSD.ORG Wed Apr 14 18:04:49 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 4D6CF1065689 for ; Wed, 14 Apr 2010 18:04:49 +0000 (UTC) (envelope-from lavalamp@spiritual-machines.org) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1B88FC1A for ; Wed, 14 Apr 2010 18:04:48 +0000 (UTC) Received: from [127.0.0.1] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 14 Apr 2010 14:15:25 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::361 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-hardware@freebsd.org X-SMFBL: ZnJlZWJzZC1oYXJkd2FyZUBmcmVlYnNkLm9yZw== Message-ID: <4BC603BF.4070705@spiritual-machines.org> Date: Wed, 14 Apr 2010 14:04:47 -0400 From: "Brian A. Seklecki" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sean McAfee , spolyack@gmail.com Subject: sysinstall butchers amr(4) partitions RELENG_6.3 -> 8.0-R binary upgrade 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, 14 Apr 2010 18:04:49 -0000 All: We have a large number of non-dangerously-dedicated disks that, given previous discussion, should be easily updated from 6.3->8. These are 8th gen Dell PE18/2850 systems with MFI/LSI amr(4): PERC4 Once loaded, sysinstall sees zero partitions in the curses-based partition editor. At the emergency shell, /dev/amrd0, /dev/amrd0a -> /dev/amrd0g are visible. In the 6.3 OS installed, these are all mapped as /dev/amrd0s1{a->g} So perhaps amrd(4) volumes don't follow the rules. What makes this breakage truly exciting If you create a new set of partitions sysinstall, then slice them, and commit, the newfs/fdisk step fails and creates: /dev/amrd0as1, /dev/armd0as1a -> /dev/armd0as1g Then it creates: /dev/amrd0cs1, /dev/armd0cs1a -> /dev/armd0cs1g Finally it creates: /dev/amrd0s1, /dev/armd0s1a -> /dev/armd0s1g None of which are usable. You can see the result of booting a FixIt image after a failed sysinstall process: http://digitalfreaks.org/~lavalamp/fbsd8_amr_sysinstall_butchered_partitions.jpg So that means its time to DBAN the volume for 30 seconds and/or re-init the RAID volume in the BIOS menu to nuke the partition table, hence a force reformat during upgrade. We wouldn't mind that if we were forcing everyone to use GPT and ZFS as defaults, but since FreeBSD 8 really changes nothing substantial this seems broken. DBAN+++ ~BAS From owner-freebsd-hardware@FreeBSD.ORG Wed Apr 14 21:22:22 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 7EB431065673 for ; Wed, 14 Apr 2010 21:22:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1CB8FC13 for ; Wed, 14 Apr 2010 21:22:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id DDCEA46B0D; Wed, 14 Apr 2010 17:22:21 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0C5BD8A021; Wed, 14 Apr 2010 17:22:20 -0400 (EDT) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Wed, 14 Apr 2010 17:14:05 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <4BC603BF.4070705@spiritual-machines.org> In-Reply-To: <4BC603BF.4070705@spiritual-machines.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004141714.05156.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 14 Apr 2010 17:22:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Sean McAfee , spolyack@gmail.com, "Brian A. Seklecki" Subject: Re: sysinstall butchers amr(4) partitions RELENG_6.3 -> 8.0-R binary upgrade 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, 14 Apr 2010 21:22:22 -0000 On Wednesday 14 April 2010 2:04:47 pm Brian A. Seklecki wrote: > All: > > We have a large number of non-dangerously-dedicated disks that, > given previous discussion, should be easily updated from 6.3->8. > > These are 8th gen Dell PE18/2850 systems with MFI/LSI amr(4): > PERC4 > > Once loaded, sysinstall sees zero partitions in the > curses-based partition editor. > > At the emergency shell, /dev/amrd0, /dev/amrd0a -> /dev/amrd0g are > visible. > > In the 6.3 OS installed, these are all mapped as /dev/amrd0s1{a->g} > > So perhaps amrd(4) volumes don't follow the rules. What makes > this breakage truly exciting > > If you create a new set of partitions sysinstall, then > slice them, and commit, the newfs/fdisk step fails > and creates: > > /dev/amrd0as1, /dev/armd0as1a -> /dev/armd0as1g > > Then it creates: > > /dev/amrd0cs1, /dev/armd0cs1a -> /dev/armd0cs1g > > Finally it creates: > > /dev/amrd0s1, /dev/armd0s1a -> /dev/armd0s1g > > None of which are usable. > > You can see the result of booting a FixIt image after a failed > sysinstall process: > > http://digitalfreaks.org/~lavalamp/fbsd8_amr_sysinstall_butchered_partitions.jpg > > So that means its time to DBAN the volume for 30 seconds > and/or re-init the RAID volume in the BIOS menu to nuke the > partition table, hence a force reformat during upgrade. > > We wouldn't mind that if we were forcing everyone to use > GPT and ZFS as defaults, but since FreeBSD 8 really changes > nothing substantial this seems broken. This is due to the GPART changes in that it is less forgiving about certain partition layouts. You can try bugging marcel@. FWIW, just doing 'dd if=/dev/zero of=/dev/amrd0 count=100' or so should have been enough to wipe the partition tables that were confusing sysinstall. -- John Baldwin From owner-freebsd-hardware@FreeBSD.ORG Sat Apr 17 13:15:06 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 1EC67106566B for ; Sat, 17 Apr 2010 13:15:06 +0000 (UTC) (envelope-from bunderbug@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA2988FC22 for ; Sat, 17 Apr 2010 13:15:05 +0000 (UTC) Received: by wwa36 with SMTP id 36so2133256wwa.13 for ; Sat, 17 Apr 2010 06:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=et2PteQATOYdHaUnsKa48xzJqWLlf77ygYaC3SAtJyI=; b=pjyvQcm9qjnx9SkqAPdNDfv5jdTuPE240/df8ubxinPRie9vOAMa6MXOgArkoup086 /KTRfEAQLwswiGsPthbTiAjOOic9nmOSEuTIGCra4WhIQkKOXjtEZN4+cPEXxgRmdsvZ Vw0b/wT83aklGoiu81iV+v1NAVd/MAyP44+vY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LBm617Sg0uT0h6Icvsxpd7x1sUORgstZ1VK37xMwrgh8DR0NkZM2YEhDbOwuKTCNws ofGVgL3bz7MBPteGws4zsVxgHeiXLzFfO61UgfOV+QX39ZBMBEIB+j8sV/sx8WQsSDSK pNqbhRYG2QhHuNps4TtS07nHjaCa07ZU8LFFk= MIME-Version: 1.0 Received: by 10.216.70.18 with HTTP; Sat, 17 Apr 2010 05:48:44 -0700 (PDT) Date: Sat, 17 Apr 2010 12:48:44 +0000 Received: by 10.216.88.143 with SMTP id a15mr3905355wef.6.1271508524871; Sat, 17 Apr 2010 05:48:44 -0700 (PDT) Message-ID: From: bunderbug To: freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: HP2710p sensor display under FreeBSD 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: Sat, 17 Apr 2010 13:15:06 -0000 Good day! Is that real to find drivers to touch-screen of this tablet-pc? ( http://www.tabletpc2.com/Review-HP_2710p_Tablet_PC_&_Expansion_Base-70020808.htmhttp://www.tabletpc2.com/Review-HP_2710p_Tablet_PC_&_Expansion_Base-70020808.htm ) Where to look (or start read from)? :) Have not much experience with hardware under FreeBSD.