From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 30 19:10:12 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A2316A418 for ; Sun, 30 Sep 2007 19:10:12 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7FCF013C458 for ; Sun, 30 Sep 2007 19:10:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 31712 invoked from network); 30 Sep 2007 19:10:13 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 30 Sep 2007 19:10:13 -0000 Message-ID: <46FFF493.3070800@root.org> Date: Sun, 30 Sep 2007 12:10:11 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <46FC28DA.5090703@root.org> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> In-Reply-To: <46FC3CB3.3060202@root.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------090706080609010908080303" Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 19:10:12 -0000 This is a multi-part message in MIME format. --------------090706080609010908080303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Nate Lawson wrote: >> devinfo -rv >> nexus0 >> acpi0 > ... >> I/O memory addresses: >> 0xc0000-0xdffff >> 0xe0000-0xfffff >> 0xf0000000-0xf7ffffff >> 0xfed13000-0xfed13fff >> 0xfed14000-0xfed17fff >> 0xfed18000-0xfed18fff >> 0xfed19000-0xfed19fff >> 0xfed1c000-0xfed1ffff >> 0xfed20000-0xfed9ffff >> acpi_hpet0 pnpinfo unknown at unknown >> I/O memory addresses: >> 0xfed00000-0xfed003ff > > Ok, that's one problem. acpi_hpet is attaching before the system > resource object. So the resources are already allocated from nexus > before acpi0 can get to them. > > To test, set this hint at the loader prompt and the message will go away > (but you won't have the HPET timer): > > debug.acpi.disabled="hpet" Please try the attached patch for 7-current. You should not see the message any more but will still have an acpi_hpet0 device. Please send me dmesg and devinfo -rv output after testing. -Nate --------------090706080609010908080303 Content-Type: text/x-patch; name="hpet.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="hpet.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.242 diff -u -r1.242 acpi.c --- sys/dev/acpica/acpi.c 13 Sep 2007 01:37:17 -0000 1.242 +++ sys/dev/acpica/acpi.c 30 Sep 2007 19:01:45 -0000 @@ -509,7 +509,6 @@ * a problem but should be addressed eventually. */ acpi_ec_ecdt_probe(dev); - acpi_hpet_table_probe(dev); /* Bring device objects and regions online. */ if (ACPI_FAILURE(status = AcpiInitializeObjects(flags))) { Index: sys/dev/acpica/acpi_hpet.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_hpet.c,v retrieving revision 1.11 diff -u -r1.11 acpi_hpet.c --- sys/dev/acpica/acpi_hpet.c 30 Jul 2007 15:21:26 -0000 1.11 +++ sys/dev/acpica/acpi_hpet.c 30 Sep 2007 19:07:26 -0000 @@ -83,14 +83,18 @@ } /* Discover the HPET via the ACPI table of the same name. */ -void -acpi_hpet_table_probe(device_t parent) +static void +acpi_hpet_identify(driver_t *driver, device_t parent) { ACPI_TABLE_HPET *hpet; ACPI_TABLE_HEADER *hdr; ACPI_STATUS status; device_t child; + /* Only one HPET device can be added. */ + if (devclass_get_device(acpi_hpet_devclass, 0)) + return; + /* Currently, ID and minimum clock tick info is unused. */ status = AcpiGetTable(ACPI_SIG_HPET, 1, (ACPI_TABLE_HEADER **)&hdr); @@ -105,7 +109,7 @@ if (hpet->Sequence != 0) printf("ACPI HPET table warning: Sequence is non-zero (%d)\n", hpet->Sequence); - child = BUS_ADD_CHILD(parent, 0, "acpi_hpet", 0); + child = BUS_ADD_CHILD(parent, 10, "acpi_hpet", 0); if (child == NULL) { printf("%s: can't add child\n", __func__); return; @@ -115,8 +119,6 @@ acpi_set_magic(child, (uintptr_t)&acpi_hpet_devclass); bus_set_resource(child, SYS_RES_MEMORY, 0, hpet->Address.Address, HPET_MEM_WIDTH); - if (device_probe_and_attach(child) != 0) - device_delete_child(parent, child); } static int @@ -254,6 +256,7 @@ static device_method_t acpi_hpet_methods[] = { /* Device interface */ + DEVMETHOD(device_identify, acpi_hpet_identify), DEVMETHOD(device_probe, acpi_hpet_probe), DEVMETHOD(device_attach, acpi_hpet_attach), DEVMETHOD(device_detach, acpi_hpet_detach), Index: sys/dev/acpica/acpivar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpivar.h,v retrieving revision 1.107 diff -u -r1.107 acpivar.h --- sys/dev/acpica/acpivar.h 21 Jun 2007 22:50:37 -0000 1.107 +++ sys/dev/acpica/acpivar.h 30 Sep 2007 19:01:18 -0000 @@ -432,8 +432,6 @@ /* Embedded controller. */ void acpi_ec_ecdt_probe(device_t); -/* HPET table probe*/ -void acpi_hpet_table_probe(device_t); /* AC adapter interface. */ int acpi_acad_get_acline(int *); --------------090706080609010908080303-- From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 30 20:10:26 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C593716A418 for ; Sun, 30 Sep 2007 20:10:26 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0C913C49D for ; Sun, 30 Sep 2007 20:10:26 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 38370 invoked from network); 30 Sep 2007 20:10:27 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 30 Sep 2007 20:10:27 -0000 Message-ID: <470002B5.6030002@root.org> Date: Sun, 30 Sep 2007 13:10:29 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@FreeBSD.org, acpi@freebsd.org X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------010009080907080806050809" Cc: Subject: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 20:10:26 -0000 This is a multi-part message in MIME format. --------------010009080907080806050809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Attached is a patch (one for 6, one for 7) that shouldn't break anything for most people and may fix some battery status issues for others. It changes how we run tasks during boot. It seems some hardware expects synchronous access but our taskq is not running until after interrupts are enabled. This patch bounces calls through a wrapper that executes the callback directly if we're not booted yet. Please let me know if it breaks anything for you. Thanks, Nate --------------010009080907080806050809 Content-Type: text/x-patch; name="taskq6a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="taskq6a.diff" Index: sys/dev/acpica/acpi_acad.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_acad.c,v retrieving revision 1.33.2.2 diff -u -r1.33.2.2 acpi_acad.c --- sys/dev/acpica/acpi_acad.c 5 Nov 2005 23:48:38 -0000 1.33.2.2 +++ sys/dev/acpica/acpi_acad.c 30 Sep 2007 19:24:23 -0000 @@ -181,7 +181,7 @@ */ AcpiInstallNotifyHandler(handle, ACPI_ALL_NOTIFY, acpi_acad_notify_handler, dev); - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_acad_init_acline, dev); + acpi_queue_task(OSD_PRIORITY_LO, acpi_acad_init_acline, dev); return (0); } Index: sys/dev/acpica/acpi_cmbat.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cmbat.c,v retrieving revision 1.39.2.5 diff -u -r1.39.2.5 acpi_cmbat.c --- sys/dev/acpica/acpi_cmbat.c 11 Jun 2006 20:50:08 -0000 1.39.2.5 +++ sys/dev/acpica/acpi_cmbat.c 30 Sep 2007 19:25:16 -0000 @@ -149,7 +149,7 @@ AcpiInstallNotifyHandler(handle, ACPI_ALL_NOTIFY, acpi_cmbat_notify_handler, dev); - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cmbat_init_battery, dev); + acpi_queue_task(OSD_PRIORITY_LO, acpi_cmbat_init_battery, dev); return (0); } Index: sys/dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.57.2.3 diff -u -r1.57.2.3 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 11 Jun 2007 18:54:09 -0000 1.57.2.3 +++ sys/dev/acpica/acpi_cpu.c 30 Sep 2007 19:25:26 -0000 @@ -313,7 +313,7 @@ CTLFLAG_RD, 0, "node for CPU children"); /* Queue post cpu-probing task handler */ - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); + acpi_queue_task(OSD_PRIORITY_LO, acpi_cpu_startup, NULL); } /* Index: sys/dev/acpica/acpi_dock.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_dock.c,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 acpi_dock.c --- sys/dev/acpica/acpi_dock.c 23 Mar 2007 19:45:52 -0000 1.5.2.1 +++ sys/dev/acpica/acpi_dock.c 30 Sep 2007 19:25:31 -0000 @@ -238,7 +238,7 @@ goto out; } - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_dock_attach_later, dev); + acpi_queue_task(OSD_PRIORITY_LO, acpi_dock_attach_later, dev); out: return (AE_OK); Index: sys/dev/acpica/acpi_perf.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_perf.c,v retrieving revision 1.21.2.4 diff -u -r1.21.2.4 acpi_perf.c --- sys/dev/acpica/acpi_perf.c 23 Jan 2007 07:21:23 -0000 1.21.2.4 +++ sys/dev/acpica/acpi_perf.c 30 Sep 2007 19:25:56 -0000 @@ -221,7 +221,7 @@ sc->px_curr_state = CPUFREQ_VAL_UNKNOWN; if (acpi_perf_evaluate(dev) != 0) return (ENXIO); - AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_px_startup, NULL); + acpi_queue_task(OSD_PRIORITY_LO, acpi_px_startup, NULL); if (!sc->info_only) cpufreq_register(dev); Index: sys/dev/acpica/acpivar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpivar.h,v retrieving revision 1.95.2.6 diff -u -r1.95.2.6 acpivar.h --- sys/dev/acpica/acpivar.h 17 Jun 2007 17:28:41 -0000 1.95.2.6 +++ sys/dev/acpica/acpivar.h 30 Sep 2007 19:29:59 -0000 @@ -390,6 +415,8 @@ int acpi_sleep_machdep(struct acpi_softc *sc, int state); int acpi_table_quirks(int *quirks); int acpi_machdep_quirks(int *quirks); +ACPI_STATUS acpi_queue_task(UINT32 Priority, + ACPI_OSD_EXEC_CALLBACK Function, void *Context); /* Battery Abstraction. */ struct acpi_battinfo; Index: sys/dev/acpica/Osd/OsdSchedule.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/Osd/OsdSchedule.c,v retrieving revision 1.32.2.6 diff -u -r1.32.2.6 OsdSchedule.c --- sys/dev/acpica/Osd/OsdSchedule.c 6 Jul 2006 08:32:49 -0000 1.32.2.6 +++ sys/dev/acpica/Osd/OsdSchedule.c 30 Sep 2007 19:23:24 -0000 @@ -83,11 +83,33 @@ } /* + * If we're up and running, queue the task for our taskq. It will run + * shortly. If we're booting and we had queued it, it would not actually run + * until interrupts are enabled later in boot. So in that case, run it + * directly instead. If a driver really wants the task delayed until boot, + * they can use acpi_queue_task() below. + */ +ACPI_STATUS +AcpiOsQueueForExecution(UINT32 Priority, ACPI_OSD_EXEC_CALLBACK Function, + void *Context) +{ + ACPI_STATUS status; + + if (!(cold || rebooting)) + status = acpi_queue_task(Priority, Function, Context); + else { + Function(Context); + status = AE_OK; + } + return (status); +} + +/* * This function may be called in interrupt context, i.e. when a GPE fires. * We allocate and queue a task for one of our taskqueue threads to process. */ ACPI_STATUS -AcpiOsQueueForExecution(UINT32 Priority, ACPI_OSD_EXEC_CALLBACK Function, +acpi_queue_task(UINT32 Priority, ACPI_OSD_EXEC_CALLBACK Function, void *Context) { struct acpi_task_ctx *at; --------------010009080907080806050809 Content-Type: text/x-patch; name="taskq7a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="taskq7a.diff" Index: sys/dev/acpica/acpi_acad.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_acad.c,v retrieving revision 1.38 diff -u -r1.38 acpi_acad.c --- sys/dev/acpica/acpi_acad.c 22 Mar 2007 18:16:40 -0000 1.38 +++ sys/dev/acpica/acpi_acad.c 30 Sep 2007 19:42:09 -0000 @@ -181,7 +181,7 @@ */ AcpiInstallNotifyHandler(handle, ACPI_ALL_NOTIFY, acpi_acad_notify_handler, dev); - AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_acad_init_acline, dev); + acpi_queue_task(OSL_NOTIFY_HANDLER, acpi_acad_init_acline, dev); return (0); } Index: sys/dev/acpica/acpi_cmbat.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cmbat.c,v retrieving revision 1.46 diff -u -r1.46 acpi_cmbat.c --- sys/dev/acpica/acpi_cmbat.c 22 Mar 2007 18:16:40 -0000 1.46 +++ sys/dev/acpica/acpi_cmbat.c 30 Sep 2007 19:42:26 -0000 @@ -149,7 +149,7 @@ AcpiInstallNotifyHandler(handle, ACPI_ALL_NOTIFY, acpi_cmbat_notify_handler, dev); - AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_cmbat_init_battery, dev); + acpi_queue_task(OSL_NOTIFY_HANDLER, acpi_cmbat_init_battery, dev); return (0); } Index: sys/dev/acpica/acpi_cpu.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.67 diff -u -r1.67 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 30 Aug 2007 21:18:42 -0000 1.67 +++ sys/dev/acpica/acpi_cpu.c 30 Sep 2007 19:42:31 -0000 @@ -318,7 +318,7 @@ CTLFLAG_RD, 0, "node for CPU children"); /* Queue post cpu-probing task handler */ - AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_cpu_startup, NULL); + acpi_queue_task(OSL_NOTIFY_HANDLER, acpi_cpu_startup, NULL); } /* Index: sys/dev/acpica/acpi_dock.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_dock.c,v retrieving revision 1.6 diff -u -r1.6 acpi_dock.c --- sys/dev/acpica/acpi_dock.c 31 May 2007 08:49:51 -0000 1.6 +++ sys/dev/acpica/acpi_dock.c 30 Sep 2007 19:42:34 -0000 @@ -233,7 +233,7 @@ goto out; } - AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_dock_attach_later, dev); + acpi_queue_task(OSL_NOTIFY_HANDLER, acpi_dock_attach_later, dev); out: return (AE_OK); Index: sys/dev/acpica/acpi_perf.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_perf.c,v retrieving revision 1.26 diff -u -r1.26 acpi_perf.c --- sys/dev/acpica/acpi_perf.c 22 Mar 2007 18:16:40 -0000 1.26 +++ sys/dev/acpica/acpi_perf.c 30 Sep 2007 19:42:38 -0000 @@ -221,7 +221,7 @@ sc->px_curr_state = CPUFREQ_VAL_UNKNOWN; if (acpi_perf_evaluate(dev) != 0) return (ENXIO); - AcpiOsExecute(OSL_NOTIFY_HANDLER, acpi_px_startup, NULL); + acpi_queue_task(OSL_NOTIFY_HANDLER, acpi_px_startup, NULL); if (!sc->info_only) cpufreq_register(dev); Index: sys/dev/acpica/acpivar.h =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpivar.h,v retrieving revision 1.107 diff -u -r1.107 acpivar.h --- sys/dev/acpica/acpivar.h 21 Jun 2007 22:50:37 -0000 1.107 +++ sys/dev/acpica/acpivar.h 30 Sep 2007 19:43:42 -0000 @@ -417,6 +417,8 @@ int acpi_sleep_machdep(struct acpi_softc *sc, int state); int acpi_table_quirks(int *quirks); int acpi_machdep_quirks(int *quirks); +ACPI_STATUS acpi_queue_task(ACPI_EXECUTE_TYPE Type, + ACPI_OSD_EXEC_CALLBACK Function, void *Context); /* Battery Abstraction. */ struct acpi_battinfo; Index: sys/dev/acpica/Osd/OsdSchedule.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/Osd/OsdSchedule.c,v retrieving revision 1.39 diff -u -r1.39 OsdSchedule.c --- sys/dev/acpica/Osd/OsdSchedule.c 22 Mar 2007 18:16:41 -0000 1.39 +++ sys/dev/acpica/Osd/OsdSchedule.c 30 Sep 2007 19:40:59 -0000 @@ -83,11 +83,33 @@ } /* + * If we're up and running, queue the task for our taskq. It will run + * shortly. If we're booting and we had queued it, it would not actually run + * until interrupts are enabled later in boot. So in that case, run it + * directly instead. If a driver really wants the task delayed until boot, + * they can use acpi_queue_task() below. + */ +ACPI_STATUS +AcpiOsExecute(ACPI_EXECUTE_TYPE Type, ACPI_OSD_EXEC_CALLBACK Function, + void *Context) +{ + ACPI_STATUS status; + + if (!(cold || rebooting)) + status = acpi_queue_task(Type, Function, Context); + else { + Function(Context); + status = AE_OK; + } + return (status); +} + +/* * This function may be called in interrupt context, i.e. when a GPE fires. * We allocate and queue a task for one of our taskqueue threads to process. */ ACPI_STATUS -AcpiOsExecute(ACPI_EXECUTE_TYPE Type, ACPI_OSD_EXEC_CALLBACK Function, +acpi_queue_task(ACPI_EXECUTE_TYPE Type, ACPI_OSD_EXEC_CALLBACK Function, void *Context) { struct acpi_task_ctx *at; --------------010009080907080806050809-- From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 30 23:20:56 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DB016A419 for ; Sun, 30 Sep 2007 23:20:56 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 3280913C457 for ; Sun, 30 Sep 2007 23:20:55 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so2089193ugf for ; Sun, 30 Sep 2007 16:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=iDlKRF9uDDwfkSBxb/hjxtLw7RaS5UTqwFUUDuGyA5o=; b=h8i5JRhP5bM0nxA11zZYeEPqtn+2pcfp2hqmhuR6WbDYZPudfuf7t7siplLZyqwFCOFmaSfsRLCvyDTUsgR/6PGw2/Uhw2yLWQQR3h3YR6QjDLGfXh6NDad/PBkzp1j2q67EQMkQnjXS8wEGuyo5pqxtvCBEVOL3FOWz5lOyLag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=acodkeDv7xVBEOHLLbxaPftHIbaal1B15bwHGZlMRUT5nI8ruZ3z9cI4r6/oZYU2/8nLXo56tUJaWP6v/DVS1nkbXKfKrvL6ASBQplmRIY0Q1G2U2sry6eN3264/VAVTPU1Gg5mRmoMPewx4MHBQZJa09mAEO8T4Z2BYInXXwwI= Received: by 10.67.19.11 with SMTP id w11mr8071164ugi.1191194454804; Sun, 30 Sep 2007 16:20:54 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Sun, 30 Sep 2007 16:20:54 -0700 (PDT) Message-ID: <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> Date: Mon, 1 Oct 2007 02:20:54 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Nate Lawson" In-Reply-To: <46FFF493.3070800@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <46FC28DA.5090703@root.org> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 23:20:57 -0000 On 9/30/07, Nate Lawson wrote: > Nate Lawson wrote: > >> devinfo -rv > >> nexus0 > >> acpi0 > > ... > >> I/O memory addresses: > >> 0xc0000-0xdffff > >> 0xe0000-0xfffff > >> 0xf0000000-0xf7ffffff > >> 0xfed13000-0xfed13fff > >> 0xfed14000-0xfed17fff > >> 0xfed18000-0xfed18fff > >> 0xfed19000-0xfed19fff > >> 0xfed1c000-0xfed1ffff > >> 0xfed20000-0xfed9ffff > >> acpi_hpet0 pnpinfo unknown at unknown > >> I/O memory addresses: > >> 0xfed00000-0xfed003ff > > > > Ok, that's one problem. acpi_hpet is attaching before the system > > resource object. So the resources are already allocated from nexus > > before acpi0 can get to them. > > > > To test, set this hint at the loader prompt and the message will go away > > (but you won't have the HPET timer): > > > > debug.acpi.disabled="hpet" > > Please try the attached patch for 7-current. You should not see the > message any more but will still have an acpi_hpet0 device. Please send > me dmesg and devinfo -rv output after testing. > > -Nate Nate, Here is it before applying the patch with cpufreq enabled. devinfo -rv nexus0 acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x60 0x64 0x72-0x73 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0x400-0x47f 0x500-0x53f 0x680-0x6ff I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xf0000000-0xf7ffffff 0xfed13000-0xfed13fff 0xfed14000-0xfed17fff 0xfed18000-0xfed18fff 0xfed19000-0xfed19fff 0xfed1c000-0xfed1ffff 0xfed20000-0xfed9ffff acpi_hpet0 pnpinfo unknown at unknown I/O memory addresses: 0xfed00000-0xfed003ff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 acpi_throttle0 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 acpi_throttle1 acpi_perf1 est1 p4tcc1 cpufreq1 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 acpi_button0 pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x2970 subvendor=0x8086 subdevice=0x5354 class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x2972 subvendor=0x8086 subdevice=0x5354 class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.IGFX I/O ports: 0x20c0-0x20c7 I/O memory addresses: 0x80000000-0x8fffffff 0x90100000-0x901fffff drm0 pcib1 pnpinfo vendor=0x8086 device=0x27d0 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.PEX0 pci1 pcib2 pnpinfo vendor=0x8086 device=0x27d4 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=2 handle=\_SB_.PCI0.PEX2 pci2 pcib3 pnpinfo vendor=0x8086 device=0x27d6 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=3 handle=\_SB_.PCI0.PEX3 pci3 unknown pnpinfo vendor=0x8086 device=0x27c8 subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.UHC1 I/O ports: 0x2080-0x209f unknown pnpinfo vendor=0x8086 device=0x27c9 subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.UHC2 I/O ports: 0x2060-0x207f unknown pnpinfo vendor=0x8086 device=0x27ca subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.UHC3 I/O ports: 0x2040-0x205f unknown pnpinfo vendor=0x8086 device=0x27cb subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=3 handle=\_SB_.PCI0.UHC4 I/O ports: 0x2020-0x203f pcib4 pnpinfo vendor=0x8086 device=0x244e subvendor=0x8086 subdevice=0x5354 class=0x060401 at slot=30 function=0 handle=\_SB_.PCI0.P32_ pci4 fxp0 pnpinfo vendor=0x8086 device=0x1094 subvendor=0x8086 subdevice=0x0001 class=0x020000 at slot=8 function=0 Interrupt request lines: 0x14 I/O ports: 0x1000-0x103f I/O memory addresses: 0x90000000-0x90000fff miibus0 ukphy0 pnpinfo oui=0xaa00 model=0x31 rev=0x0 at phyno=1 isab0 pnpinfo vendor=0x8086 device=0x27b8 subvendor=0x8086 subdevice=0x5354 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.LPC_ isa0 atkbdc0 ACPI I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 fdc0 ppc0 sc0 sio0 sio1 sio2 sio3 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xcafff atapci0 pnpinfo vendor=0x8086 device=0x27c0 subvendor=0x8086 subdevice=0x5354 class=0x01018a at slot=31 function=2 handle=\_SB_.PCI0.IDES I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0x20a0-0x20af I/O memory addresses: 0x90200000-0x902003ff ata0 Interrupt request lines: 0xe ad0 subdisk0 ata1 Interrupt request lines: 0xf ad2 subdisk2 unknown pnpinfo vendor=0x8086 device=0x27da subvendor=0x8086 subdevice=0x5354 class=0x0c0500 at slot=31 function=3 I/O ports: 0x2000-0x201f acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=3 at handle=\_SB_.PCI0.IOCM pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.PCI0.LPC_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.PCI0.LPC_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.PCI0.LPC_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.PCI0.LPC_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.PCI0.LPC_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.PCI0.LPC_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.PCI0.LPC_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.PCI0.LPC_.LNKH atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.LPC_.DMAC attimer0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.LPC_.RTC_ unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.LPC_.PIC_ fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.LPC_.FPU_ attimer1 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.LPC_.TMR_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.LPC_.SPKR acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=1 at handle=\_SB_.PCI0.LPC_.XTRA unknown pnpinfo _HID=PNP0C31 _UID=1 at handle=\_SB_.PCI0.LPC_.TPM_ acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=2 at handle=\_SB_.PCI0.LPC_.XTR2 unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.LPC_.FDC0 unknown pnpinfo _HID=PNP0400 _UID=0 at handle=\_SB_.PCI0.LPC_.LPT_ unknown pnpinfo _HID=PNP0401 _UID=0 at handle=\_SB_.PCI0.LPC_.ECP_ unknown pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2M unknown pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2K unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC_.UAR1 unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPC_.UAR2 unknown pnpinfo _HID=AWY0001 _UID=0 at handle=\_SB_.PCI0.LPC_.IELK unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX4 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX5 unknown pnpinfo _HID=PNP0003 _UID=0 at handle=\_SB_.PCI0.APIC unknown pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.HPET unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.EHCI unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.AC9M unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.AZAL unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID.P_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID.P_D1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID.P_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID.P_D1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD.S_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD.S_D1 acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x408-0x40b apic0 I/O memory addresses: 0xfec00000-0xfec0001f 0xfee00000-0xfee003ff legacy0 ram0 I/O memory addresses: 0x0-0x8efff 0x100000-0x7e625fff 0x7e6f5000-0x7f575fff 0x7f57e000-0x7f62cfff 0x7f631000-0x7f6a6fff 0x7f6e9000-0x7f6ecfff 0x7f6ff000-0x7f6fffff Do I still need to apply the patch? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 30 23:51:50 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B346316A420 for ; Sun, 30 Sep 2007 23:51:50 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9E25613C4D9 for ; Sun, 30 Sep 2007 23:51:50 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 59688 invoked from network); 30 Sep 2007 23:51:51 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 30 Sep 2007 23:51:51 -0000 Message-ID: <47003695.1090104@root.org> Date: Sun, 30 Sep 2007 16:51:49 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <46FC28DA.5090703@root.org> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> In-Reply-To: <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2007 23:51:50 -0000 Abdullah Ibn Hamad Al-Marri wrote: > On 9/30/07, Nate Lawson wrote: >> Nate Lawson wrote: >>>> devinfo -rv >>>> nexus0 >>>> acpi0 >>> ... >>>> I/O memory addresses: >>>> 0xc0000-0xdffff >>>> 0xe0000-0xfffff >>>> 0xf0000000-0xf7ffffff >>>> 0xfed13000-0xfed13fff >>>> 0xfed14000-0xfed17fff >>>> 0xfed18000-0xfed18fff >>>> 0xfed19000-0xfed19fff >>>> 0xfed1c000-0xfed1ffff >>>> 0xfed20000-0xfed9ffff >>>> acpi_hpet0 pnpinfo unknown at unknown >>>> I/O memory addresses: >>>> 0xfed00000-0xfed003ff >>> Ok, that's one problem. acpi_hpet is attaching before the system >>> resource object. So the resources are already allocated from nexus >>> before acpi0 can get to them. >>> >>> To test, set this hint at the loader prompt and the message will go away >>> (but you won't have the HPET timer): >>> >>> debug.acpi.disabled="hpet" >> Please try the attached patch for 7-current. You should not see the >> message any more but will still have an acpi_hpet0 device. Please send >> me dmesg and devinfo -rv output after testing. > > Do I still need to apply the patch? Yes, this won't fix cpufreq (need to figure out new Intel tables to make that happen), but it will fix the "unable to allocate" error in dmesg you first reported. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 03:57:44 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D8C16A46B for ; Mon, 1 Oct 2007 03:57:43 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0CC13C45D for ; Mon, 1 Oct 2007 03:57:43 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so2114061ugf for ; Sun, 30 Sep 2007 20:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aPoMAkzQ3xvu4VmlrUKvGeRgy/WgV7PuTcxr6lgSFp0=; b=c35UW/8pwyr2F8U3fJwl4ByI6V9Ty6LHriky7nN//Nn+g2lZ/R9Rl8hTEdpzvoq0I+FI2F+0QAAJzt/+dB5/c7F8GMb/baRymv+JWLjdJ83bz2hP1w7Zof8ImE/5voujVRW6zKpNNkT3agbES29ZOLfk0yR2lSLaWueakRqIkYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EQnQef4GZ1nZKByMbwKn8zrU0AbSbSEarIS3t+yjgATXJ8JklDDD3n67N6j6l4LgmewBr/UI/jGSxIt3/tAXK7riPpJwthwNzeL755srIA00Ie1L7DgEeHDnCDbQt1LQuxgiEyP2vt00SupPqS8WqNxtlnQhoun8aEPU0r6398A= Received: by 10.66.225.17 with SMTP id x17mr8299129ugg.1191211061809; Sun, 30 Sep 2007 20:57:41 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Sun, 30 Sep 2007 20:57:41 -0700 (PDT) Message-ID: <499c70c0709302057m3687639apbd628da297ff9c12@mail.gmail.com> Date: Mon, 1 Oct 2007 06:57:41 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Nate Lawson" In-Reply-To: <47003695.1090104@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <46FC28DA.5090703@root.org> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> <47003695.1090104@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 03:57:44 -0000 On 10/1/07, Nate Lawson wrote: > Abdullah Ibn Hamad Al-Marri wrote: > > On 9/30/07, Nate Lawson wrote: > >> Nate Lawson wrote: > >>>> devinfo -rv > >>>> nexus0 > >>>> acpi0 > >>> ... > >>>> I/O memory addresses: > >>>> 0xc0000-0xdffff > >>>> 0xe0000-0xfffff > >>>> 0xf0000000-0xf7ffffff > >>>> 0xfed13000-0xfed13fff > >>>> 0xfed14000-0xfed17fff > >>>> 0xfed18000-0xfed18fff > >>>> 0xfed19000-0xfed19fff > >>>> 0xfed1c000-0xfed1ffff > >>>> 0xfed20000-0xfed9ffff > >>>> acpi_hpet0 pnpinfo unknown at unknown > >>>> I/O memory addresses: > >>>> 0xfed00000-0xfed003ff > >>> Ok, that's one problem. acpi_hpet is attaching before the system > >>> resource object. So the resources are already allocated from nexus > >>> before acpi0 can get to them. > >>> > >>> To test, set this hint at the loader prompt and the message will go away > >>> (but you won't have the HPET timer): > >>> > >>> debug.acpi.disabled="hpet" > >> Please try the attached patch for 7-current. You should not see the > >> message any more but will still have an acpi_hpet0 device. Please send > >> me dmesg and devinfo -rv output after testing. > > > > Do I still need to apply the patch? > > Yes, this won't fix cpufreq (need to figure out new Intel tables to make > that happen), but it will fix the "unable to allocate" error in dmesg > you first reported. > > -- > Nate Nate, Thank you, Here is the new dmsg. FreeBSD 7.0-CURRENT #0: Mon Oct 1 02:49:06 GMT 2007 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2397.62-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2130026496 (2031 MB) avail memory = 2055786496 (1960 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20c0-0x20c7 mem 0x90100000-0x901fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 fxp0: port 0x1000-0x103f mem 0x90000000-0x90000fff irq 20 at device 8.0 on pci4 miibus0: on fxp0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:19:d1:41:1e:0c fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20a0-0x20af mem 0x90200000-0x902003ff irq 19 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) orm0: at iomem 0xc0000-0xcafff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad0: 70911MB at ata0-master SATA150 ad2: 238474MB at ata1-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a here is devinfo -rv devinfo -rv nexus0 acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x60 0x64 0x72-0x73 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0x400-0x47f 0x500-0x53f 0x680-0x6ff I/O memory addresses: 0xc0000-0xdffff 0xe0000-0xfffff 0xf0000000-0xf7ffffff 0xfed00000-0xfed00fff 0xfed13000-0xfed13fff 0xfed14000-0xfed17fff 0xfed18000-0xfed18fff 0xfed19000-0xfed19fff 0xfed1c000-0xfed1ffff 0xfed20000-0xfed9ffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 acpi_throttle0 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 acpi_throttle1 acpi_perf1 est1 p4tcc1 cpufreq1 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 acpi_button0 pnpinfo _HID=PNP0C0E _UID=0 at handle=\_SB_.SLPB pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 pci0 hostb0 pnpinfo vendor=0x8086 device=0x2970 subvendor=0x8086 subdevice=0x5354 class=0x060000 at slot=0 function=0 vgapci0 pnpinfo vendor=0x8086 device=0x2972 subvendor=0x8086 subdevice=0x5354 class=0x030000 at slot=2 function=0 handle=\_SB_.PCI0.IGFX I/O ports: 0x20c0-0x20c7 I/O memory addresses: 0x80000000-0x8fffffff 0x90100000-0x901fffff drm0 pcib1 pnpinfo vendor=0x8086 device=0x27d0 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.PEX0 pci1 pcib2 pnpinfo vendor=0x8086 device=0x27d4 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=2 handle=\_SB_.PCI0.PEX2 pci2 pcib3 pnpinfo vendor=0x8086 device=0x27d6 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=3 handle=\_SB_.PCI0.PEX3 pci3 unknown pnpinfo vendor=0x8086 device=0x27c8 subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=0 handle=\_SB_.PCI0.UHC1 I/O ports: 0x2080-0x209f unknown pnpinfo vendor=0x8086 device=0x27c9 subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=1 handle=\_SB_.PCI0.UHC2 I/O ports: 0x2060-0x207f unknown pnpinfo vendor=0x8086 device=0x27ca subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=2 handle=\_SB_.PCI0.UHC3 I/O ports: 0x2040-0x205f unknown pnpinfo vendor=0x8086 device=0x27cb subvendor=0x8086 subdevice=0x5354 class=0x0c0300 at slot=29 function=3 handle=\_SB_.PCI0.UHC4 I/O ports: 0x2020-0x203f pcib4 pnpinfo vendor=0x8086 device=0x244e subvendor=0x8086 subdevice=0x5354 class=0x060401 at slot=30 function=0 handle=\_SB_.PCI0.P32_ pci4 fxp0 pnpinfo vendor=0x8086 device=0x1094 subvendor=0x8086 subdevice=0x0001 class=0x020000 at slot=8 function=0 Interrupt request lines: 0x14 I/O ports: 0x1000-0x103f I/O memory addresses: 0x90000000-0x90000fff miibus0 ukphy0 pnpinfo oui=0xaa00 model=0x31 rev=0x0 at phyno=1 isab0 pnpinfo vendor=0x8086 device=0x27b8 subvendor=0x8086 subdevice=0x5354 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.LPC_ isa0 atkbdc0 ACPI I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 fdc0 ppc0 sc0 sio0 sio1 sio2 sio3 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 ACPI I/O memory addresses: 0xc0000-0xcafff atapci0 pnpinfo vendor=0x8086 device=0x27c0 subvendor=0x8086 subdevice=0x5354 class=0x01018a at slot=31 function=2 handle=\_SB_.PCI0.IDES I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0x20a0-0x20af I/O memory addresses: 0x90200000-0x902003ff ata0 Interrupt request lines: 0xe ad0 subdisk0 ata1 Interrupt request lines: 0xf ad2 subdisk2 unknown pnpinfo vendor=0x8086 device=0x27da subvendor=0x8086 subdevice=0x5354 class=0x0c0500 at slot=31 function=3 I/O ports: 0x2000-0x201f acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=3 at handle=\_SB_.PCI0.IOCM pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.PCI0.LPC_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.PCI0.LPC_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.PCI0.LPC_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.PCI0.LPC_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.PCI0.LPC_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.PCI0.LPC_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.PCI0.LPC_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.PCI0.LPC_.LNKH atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.LPC_.DMAC attimer0 pnpinfo _HID=PNP0B00 _UID=0 at handle=\_SB_.PCI0.LPC_.RTC_ unknown pnpinfo _HID=PNP0000 _UID=0 at handle=\_SB_.PCI0.LPC_.PIC_ fpupnp0 pnpinfo _HID=PNP0C04 _UID=0 at handle=\_SB_.PCI0.LPC_.FPU_ attimer1 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.LPC_.TMR_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.LPC_.SPKR acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=1 at handle=\_SB_.PCI0.LPC_.XTRA unknown pnpinfo _HID=PNP0C31 _UID=1 at handle=\_SB_.PCI0.LPC_.TPM_ acpi_sysresource2 pnpinfo _HID=PNP0C02 _UID=2 at handle=\_SB_.PCI0.LPC_.XTR2 unknown pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.LPC_.FDC0 unknown pnpinfo _HID=PNP0400 _UID=0 at handle=\_SB_.PCI0.LPC_.LPT_ unknown pnpinfo _HID=PNP0401 _UID=0 at handle=\_SB_.PCI0.LPC_.ECP_ unknown pnpinfo _HID=PNP0F03 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2M unknown pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.LPC_.PS2K unknown pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.LPC_.UAR1 unknown pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.LPC_.UAR2 unknown pnpinfo _HID=AWY0001 _UID=0 at handle=\_SB_.PCI0.LPC_.IELK unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX4 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.PEX5 unknown pnpinfo _HID=PNP0003 _UID=0 at handle=\_SB_.PCI0.APIC unknown pnpinfo _HID=PNP0103 _UID=0 at handle=\_SB_.PCI0.HPET unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.EHCI unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.AC9M unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.AZAL unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID.P_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDEC.PRID.P_D1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID.P_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.PRID.P_D1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD.S_D0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDES.SECD.S_D1 acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x408-0x40b acpi_hpet0 pnpinfo unknown at unknown ACPI I/O memory addresses: 0xfed00000-0xfed003ff apic0 I/O memory addresses: 0xfec00000-0xfec0001f 0xfee00000-0xfee003ff legacy0 ram0 I/O memory addresses: 0x0-0x8efff 0x100000-0x7e625fff 0x7e6f5000-0x7f575fff 0x7f57e000-0x7f62cfff 0x7f631000-0x7f6a6fff 0x7f6e9000-0x7f6ecfff 0x7f6ff000-0x7f6fffff I still see CPU supports Enhanced Speedstep, but is not recognized too. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 05:13:33 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7904416A64F for ; Mon, 1 Oct 2007 05:13:33 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BA0D613C5A5 for ; Mon, 1 Oct 2007 05:12:47 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 98405 invoked from network); 1 Oct 2007 05:12:50 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 1 Oct 2007 05:12:50 -0000 Message-ID: <470081CF.5050702@root.org> Date: Sun, 30 Sep 2007 22:12:47 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <46FC28DA.5090703@root.org> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> <47003695.1090104@root.org> <499c70c0709302057m3687639apbd628da297ff9c12@mail.gmail.com> In-Reply-To: <499c70c0709302057m3687639apbd628da297ff9c12@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 05:13:33 -0000 Abdullah Ibn Hamad Al-Marri wrote: > On 10/1/07, Nate Lawson wrote: >> Yes, this won't fix cpufreq (need to figure out new Intel tables to make >> that happen), but it will fix the "unable to allocate" error in dmesg >> you first reported. > Nate, > > Thank you, > > Here is the new dmsg. > > > FreeBSD 7.0-CURRENT #0: Mon Oct 1 02:49:06 GMT 2007 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 Error message is gone. > here is devinfo -rv > > devinfo -rv > nexus0 > acpi0 > I/O memory addresses: > 0xc0000-0xdffff > 0xe0000-0xfffff > 0xf0000000-0xf7ffffff > 0xfed00000-0xfed00fff acpi now properly owns this address range. > 0xfed13000-0xfed13fff > 0xfed14000-0xfed17fff > 0xfed18000-0xfed18fff > 0xfed19000-0xfed19fff > 0xfed1c000-0xfed1ffff > 0xfed20000-0xfed9ffff > acpi_hpet0 pnpinfo unknown at unknown > ACPI I/O memory addresses: > 0xfed00000-0xfed003ff HPET still attaching. > I still see CPU supports Enhanced Speedstep, but is not recognized too. That is a separate problem, unrelated. Thanks for testing. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 11:08:14 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B2A16A46D for ; Mon, 1 Oct 2007 11:08:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B6C4013C49D for ; Mon, 1 Oct 2007 11:08:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l91B8Ef0064367 for ; Mon, 1 Oct 2007 11:08:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l91B8DfQ064363 for freebsd-acpi@FreeBSD.org; Mon, 1 Oct 2007 11:08:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2007 11:08:13 GMT Message-Id: <200710011108.l91B8DfQ064363@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 11:08:14 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 s i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/114113 acpi [patch] ACPI kernel panic during S3 suspend / resume o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116169 acpi [PATCH] acpi_ibm => psm0 not found problem 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th o kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi Dell C810 - ACPI problem o kern/114722 acpi [acpi] [patch] Nearly duplicate p-state entries report 18 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 17:28:16 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36D4C16A418 for ; Mon, 1 Oct 2007 17:28:16 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id B5F7713C46A for ; Mon, 1 Oct 2007 17:28:15 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2671756nfb for ; Mon, 01 Oct 2007 10:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-disposition:content-type:content-transfer-encoding:message-id; bh=pd6CYxGDT32iVr963HJvBssmSWGnzl6AuWSgynuwhLA=; b=uN3KJTKqF7A2P1ft99FMgaLZsi458qvtp0GMltPRO6abroHzxfQ7rvGSfhUqA3XM2BLBlcikzldoYLS6dBP18hmV+DC5rKOwpk5yZqgsS1MKoM6xIBq5LEKvdj6ILxo2WkBA777KX/WNC4jGNHRqb33Oe+lAPdX1idqLwvFB8yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-disposition:content-type:content-transfer-encoding:message-id; b=qd+YcBcD0kBhmTFvev7UjjhC+h+QdDpHGhTVGPBF4wUXgDFuVARouNWYWmutI2gxf51K8iTH45NC+wQT0E6eDdbo4XpzZSKt/dtvKy0YZoecPKG+DfRa2FkEwmkoFfUY+QdkiRmm7z8ZDWOciSDrUG42KCQSorBG7ULtCEjNiVs= Received: by 10.78.180.16 with SMTP id c16mr6608695huf.1191258244092; Mon, 01 Oct 2007 10:04:04 -0700 (PDT) Received: from vallhala.mshome.net ( [85.160.194.30]) by mx.google.com with ESMTPS id k5sm461934nfd.2007.10.01.10.03.59 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2007 10:04:01 -0700 (PDT) From: Milan Bartos To: freebsd-acpi@freebsd.org Date: Mon, 1 Oct 2007 19:03:15 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200710011903.15982.merlyn500@gmail.com> Subject: Prestigio Nobile 157 ACPI - overheating X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 17:28:16 -0000 Hi. I have laptop Prestigio Nobile 157 and i am running 6.2-STABLE. Kernel is GENERIC. I have my proc dev.cpu.0.freq=1000 to have temperature about 54 Celsius. If a have dev.cpu.0.freq=1700, temperature is over 70 Celsius. Is this bug, unsuported acpi device or attribute my laptop? My dmesg following: --- dmesg --- Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #1: Wed Sep 26 18:12:54 CEST 2007 root@Vallhala.mshome.net:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.70GHz (1694.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 536281088 (511 MB) avail memory = 515375104 (491 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link3: BIOS IRQ 11 for 0.29.INTB is invalid pci0: on pcib0 agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 10 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd0000000-0xd00003ff irq 10 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci_link3: BIOS IRQ 11 for 2.5.INTA is invalid pci2: on pcib2 bfe0: mem 0xd0200000-0xd0201fff irq 10 at device 5.0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0a:e4:b6:20:82 iwi0: mem 0xd0202000-0xd0202fff irq 11 at device 6.0 on pci2 iwi0: Ethernet address: 00:0e:35:ef:56:1e cbb0: at device 9.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 10 at device 9.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fwohci0: mem 0xd0203000-0xd02037ff irq 11 at device 9.2 on pci2 fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 06:e4:0a:00:69:4f:10:03 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 06:e4:0a:4f:10:03 fwe0: Ethernet address: 06:e4:0a:4f:10:03 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xd0000c00-0xd0000dff,0xd0000800-0xd00008ff irq 10 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 ppc0: port 0x378-0x37f irq 5 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd8000-0xdbfff,0xdc000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/20.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 1694509209 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a drm0: port 0x3000-0x30ff mem 0xd8000000-0xdfffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on pci1 --- end dmesg --- Please, help me, all you will need (some sysctls or anything else) i will send you. Thanks, Milan From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 18:09:20 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 690C416A51E for ; Mon, 1 Oct 2007 18:09:20 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id E05EC13C4B3 for ; Mon, 1 Oct 2007 18:09:19 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so2266033ugf for ; Mon, 01 Oct 2007 11:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=183dNyiAnEMW71iwOvOyWIx29RnjHe8+qIcEpFaFSaM=; b=sHPkrZm/rauIxvaVfAj8ucph42r8Ev7tGzdaYtDbKvmGuLhd8QraXxb563k3zmz+TY9EhU2JItKjijx2I1fb8MKS4qNo/NT4tkTyKO7BTLEiPAnkx8QW7s6rL0rJH5WYx18GjN/vJB/kaDgTj3uJ52jaoHzCELuyo2I4RBV+I4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZUzPvg6pxOTfODM/OXSSdLmWVZPPF942BjYbfm58eCGEMm+9CwUSuRzVyvkbcRnBt4lMvBaosNOAIoWW6AV2QmJ+cIdUXuYKuXcggDVOFFFFWMPENwtUMUVAvR2Bj2C4pRw6BapgH75hNGO6Zb33tq3lFkt22yxYZSBHYGfpIrc= Received: by 10.66.242.5 with SMTP id p5mr9180576ugh.1191262153839; Mon, 01 Oct 2007 11:09:13 -0700 (PDT) Received: by 10.67.29.14 with HTTP; Mon, 1 Oct 2007 11:09:13 -0700 (PDT) Message-ID: <499c70c0710011109k61d3365n84038115a26e0398@mail.gmail.com> Date: Mon, 1 Oct 2007 21:09:13 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-acpi@freebsd.org Subject: est doesn't support C2D E6600 and newer CPUs? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 18:09:20 -0000 Hello, Here is my server dmesg. FreeBSD 7.0-CURRENT #0: Mon Oct 1 02:49:06 GMT 2007 ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2397.62-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2130026496 (2031 MB) avail memory = 2055786496 (1960 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x20c0-0x20c7 mem 0x90100000-0x901fffff,0x80000000-0x8fffffff irq 16 at device 2.0 on pci0 pcib1: at device 28.0 on pci0 pci1: on pcib1 pcib2: at device 28.2 on pci0 pci2: on pcib2 pcib3: at device 28.3 on pci0 pci3: on pcib3 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.3 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 fxp0: port 0x1000-0x103f mem 0x90000000-0x90000fff irq 20 at device 8.0 on pci4 miibus0: on fxp0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:19:d1:41:1e:0c fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20a0-0x20af mem 0x90200000-0x902003ff irq 19 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) orm0: at iomem 0xc0000-0xcafff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad0: 70911MB at ata0-master SATA150 ad2: 238474MB at ata1-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s1a so I tried to unload cpufreq.ko and got this. kldunload: can't unload file: Device not configured Any hints? Any news about http://www.daemonology.net/freebsd-est/? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 18:19:04 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9000816A41B for ; Mon, 1 Oct 2007 18:19:04 +0000 (UTC) (envelope-from SRS0=e7ebb3db3349f9294f350cd1f0e8c13e6ad8abaf=475=es.net=oberman@es.net) Received: from postal1.es.net (postal2.es.net [IPv6:2001:400:14:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 4AC6613C458 for ; Mon, 1 Oct 2007 18:19:02 +0000 (UTC) (envelope-from SRS0=e7ebb3db3349f9294f350cd1f0e8c13e6ad8abaf=475=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id GCT07153; Mon, 01 Oct 2007 11:18:53 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 879B645010; Mon, 1 Oct 2007 11:18:52 -0700 (PDT) To: Milan Bartos In-Reply-To: Your message of "Mon, 01 Oct 2007 19:03:15 +0200." <200710011903.15982.merlyn500@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1191262732_25579P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 01 Oct 2007 11:18:52 -0700 From: "Kevin Oberman" Message-Id: <20071001181852.879B645010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: Milan Bartos X-To_Domain: gmail.com X-To: Milan Bartos X-To_Email: merlyn500@gmail.com X-To_Alias: merlyn500 Cc: freebsd-acpi@freebsd.org Subject: Re: Prestigio Nobile 157 ACPI - overheating X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 18:19:04 -0000 --==_Exmh_1191262732_25579P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: Milan Bartos > Date: Mon, 1 Oct 2007 19:03:15 +0200 > Sender: owner-freebsd-acpi@freebsd.org > > Hi. I have laptop Prestigio Nobile 157 and i am running 6.2-STABLE. Kernel is > GENERIC. I have my proc dev.cpu.0.freq=1000 to have temperature about 54 > Celsius. If a have dev.cpu.0.freq=1700, temperature is over 70 Celsius. Is > this bug, unsuported acpi device or attribute my laptop? > My dmesg following: > [-snip-] > > Please, help me, all you will need (some sysctls or anything else) i > will send you. OK. People need to learn a bit about the normal temperatures of modern CPUs (as well as how they are measured). You have a 1.6GHz Pentium-M. The CPU temperature is measured on the silicon by a single junction that is tied to two pins on the package. The temperature you see is going to be higher than whet you saw on many older systems with a temperature sensor mounted under the CPU in the socket. These showed a lower temperature due to the combination of convection and thermal conduction. Your CPU is most likely a 735. If so, it is speced for operation to 100C and thermal shutdown forced at 125C. 70C is not really all that hot. My system tends to idle at about 55C and, during a big build (e.g. buildworld or openoffice.org) will climb to about 85C. This is higher than I used to see, but I suspect I need to remove the keyboard and clean the heat sink. Dust accumulation can really impact thermal transfer and the laptop is now 2.5 years old. Really, what you are seeing is pretty normal. You can see what the vendor thought was too hot by looking at 'sysctl hw.sysctl.thermal'. Look at values for PSV and CRT. PSV is when the system should start aggressive thermal control by forcing the performance down. CRT is when the systems should alarm and, depending on configuration, start a shutdown. On my 2G Pentium-M I see: hw.acpi.thermal.tz0._PSV: 94.5C hw.acpi.thermal.tz0._CRT: 99.0C So even 80C is not excessive. Just very uncomfortable if you really have the laptop on your lap. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1191262732_25579P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHAToMkn3rs5h7N1ERAplTAJ4kgSZxNdPDM+kw7FwhJIyMfyqS+gCeNvGb ltzu5d6W1dohRbu62EMm9+Q= =vIxv -----END PGP SIGNATURE----- --==_Exmh_1191262732_25579P-- From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 18:41:20 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A789C16A418 for ; Mon, 1 Oct 2007 18:41:20 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2E46113C49D for ; Mon, 1 Oct 2007 18:41:19 +0000 (UTC) (envelope-from merlyn500@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2692451nfb for ; Mon, 01 Oct 2007 11:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=+l9AozR+SlJuEtTVuJl7QlnOocUqHL1Nc7N1HlU9eVc=; b=EaJI46vqXQqzRk4ql4KcQuH/rz+2lq8GyBHHavPtjkuCK1GHn8yHp4VLzdEVu3qP162KUgCtBo8HWXgtXdaKO43MCv8/9UuHGszia4/JRMJ7uqiqC178z/sWXGHT44fAI4/R+SftvGFdfRrmmhVZrt+w5X73BLzJzZoIBjH4dsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=o9fFmXxaU6zokbDFtTV7sU+TvjlADLV3m3UQL64hzo53nUu1wO/42RGrdjnKUo7lNocZmW1MYAVXsW6/O3400qF80hCpIx7Wf+wIU/PBM3wOKSgKD18IdSVluMpnq6T4ayd+e3hRFbMiym+WBmnYo56sxMTu8NZzP20nHXdJyrI= Received: by 10.78.118.5 with SMTP id q5mr3357220huc.1191264078125; Mon, 01 Oct 2007 11:41:18 -0700 (PDT) Received: from vallhala.mshome.net ( [85.160.212.180]) by mx.google.com with ESMTPS id h6sm408196nfh.2007.10.01.11.41.15 (version=SSLv3 cipher=OTHER); Mon, 01 Oct 2007 11:41:16 -0700 (PDT) From: Milan Bartos To: "Kevin Oberman" Date: Mon, 1 Oct 2007 20:40:27 +0200 User-Agent: KMail/1.9.7 References: <20071001181852.879B645010@ptavv.es.net> In-Reply-To: <20071001181852.879B645010@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710012040.28160.merlyn500@gmail.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Prestigio Nobile 157 ACPI - overheating X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 18:41:20 -0000 Thank you very much for this comprehensive information about processors. I will try clean my laptop (he is more than 2 years old). And i will be calmer (quieter ?). So once again thank for Your instructions and Your time. Milan Dne Monday 01 of October 2007 20:18:52 Kevin Oberman napsal(a): > > From: Milan Bartos > > Date: Mon, 1 Oct 2007 19:03:15 +0200 > > Sender: owner-freebsd-acpi@freebsd.org > > > > Hi. I have laptop Prestigio Nobile 157 and i am running 6.2-STABLE. > > Kernel is GENERIC. I have my proc dev.cpu.0.freq=1000 to have temperature > > about 54 Celsius. If a have dev.cpu.0.freq=1700, temperature is over 70 > > Celsius. Is this bug, unsuported acpi device or attribute my laptop? > > My dmesg following: > > [-snip-] > > > Please, help me, all you will need (some sysctls or anything else) i > > will send you. > > OK. People need to learn a bit about the normal temperatures of modern > CPUs (as well as how they are measured). > > You have a 1.6GHz Pentium-M. The CPU temperature is measured on the > silicon by a single junction that is tied to two pins on the > package. The temperature you see is going to be higher than whet you saw > on many older systems with a temperature sensor mounted under the CPU in > the socket. These showed a lower temperature due to the combination of > convection and thermal conduction. > > Your CPU is most likely a 735. If so, it is speced for operation to 100C > and thermal shutdown forced at 125C. 70C is not really all that hot. My > system tends to idle at about 55C and, during a big build > (e.g. buildworld or openoffice.org) will climb to about 85C. This is higher > than I used to see, but I suspect I need to remove the keyboard and > clean the heat sink. Dust accumulation can really impact thermal > transfer and the laptop is now 2.5 years old. > > Really, what you are seeing is pretty normal. You can see what the > vendor thought was too hot by looking at 'sysctl hw.sysctl.thermal'. > Look at values for PSV and CRT. PSV is when the system should start > aggressive thermal control by forcing the performance down. CRT is when > the systems should alarm and, depending on configuration, start a > shutdown. > > On my 2G Pentium-M I see: > hw.acpi.thermal.tz0._PSV: 94.5C > hw.acpi.thermal.tz0._CRT: 99.0C > > So even 80C is not excessive. Just very uncomfortable if you really have > the laptop on your lap. From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 19:10:20 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7082A16A468 for ; Mon, 1 Oct 2007 19:10:20 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 68A4413C43E for ; Mon, 1 Oct 2007 19:10:20 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 78463 invoked from network); 1 Oct 2007 19:10:21 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 1 Oct 2007 19:10:21 -0000 Message-ID: <4701461B.10207@root.org> Date: Mon, 01 Oct 2007 12:10:19 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kevin Oberman References: <20071001181852.879B645010@ptavv.es.net> In-Reply-To: <20071001181852.879B645010@ptavv.es.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Milan Bartos , freebsd-acpi@freebsd.org Subject: Re: Prestigio Nobile 157 ACPI - overheating X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 19:10:20 -0000 Kevin Oberman wrote: >> From: Milan Bartos >> Date: Mon, 1 Oct 2007 19:03:15 +0200 >> Sender: owner-freebsd-acpi@freebsd.org >> >> Hi. I have laptop Prestigio Nobile 157 and i am running 6.2-STABLE. Kernel is >> GENERIC. I have my proc dev.cpu.0.freq=1000 to have temperature about 54 >> Celsius. If a have dev.cpu.0.freq=1700, temperature is over 70 Celsius. Is >> this bug, unsuported acpi device or attribute my laptop? >> My dmesg following: >> > [-snip-] >> Please, help me, all you will need (some sysctls or anything else) i >> will send you. > > OK. People need to learn a bit about the normal temperatures of modern > CPUs (as well as how they are measured). > > You have a 1.6GHz Pentium-M. The CPU temperature is measured on the > silicon by a single junction that is tied to two pins on the > package. The temperature you see is going to be higher than whet you saw > on many older systems with a temperature sensor mounted under the CPU in > the socket. These showed a lower temperature due to the combination of > convection and thermal conduction. > > Your CPU is most likely a 735. If so, it is speced for operation to 100C > and thermal shutdown forced at 125C. 70C is not really all that hot. My > system tends to idle at about 55C and, during a big build > (e.g. buildworld or openoffice.org) will climb to about 85C. This is higher > than I used to see, but I suspect I need to remove the keyboard and > clean the heat sink. Dust accumulation can really impact thermal > transfer and the laptop is now 2.5 years old. > > Really, what you are seeing is pretty normal. You can see what the > vendor thought was too hot by looking at 'sysctl hw.sysctl.thermal'. > Look at values for PSV and CRT. PSV is when the system should start > aggressive thermal control by forcing the performance down. CRT is when > the systems should alarm and, depending on configuration, start a > shutdown. > > On my 2G Pentium-M I see: > hw.acpi.thermal.tz0._PSV: 94.5C > hw.acpi.thermal.tz0._CRT: 99.0C > > So even 80C is not excessive. Just very uncomfortable if you really have > the laptop on your lap. You should probably run powerd to drop the CPU to lower settings. If you're comparing to Windows XP, it uses an adaptive mode similar to powerd when on or off AC power. Most laptops are not designed any more to run comfortably at 100%, they're designed to be comfortable with adaptive cpu freq management but not self-destruct at 100%. powerd_enable="YES" Also, see if you're using lower Cx levels for cpu idling. They can make a big heat difference. performance_cx_lowest="LOW" economy_cx_lowest="LOW" man rc.conf -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 19:21:52 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B61E16A417 for ; Mon, 1 Oct 2007 19:21:52 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5FC13C46A for ; Mon, 1 Oct 2007 19:21:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id a2so2283934ugf for ; Mon, 01 Oct 2007 12:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jgW8doPTQICckYpmsBnLWXBGn7K2+bMb/7HBxSGbxQo=; b=INgNql6BoGOzoXJtXJQciNDDmRXD1YkPSoo8hcxiaosFO4GPc7IKlbCJpigSK4RHn7qs9JqU5WVWCTCds0mx+NMjj8YdOYcrCuBTTKuyuJy20tNTV5eMqLhBBuMtVy/q0zCBwJz06Ykn0OaI9Ad4gFh+KP2wj3RKhwRxUnmqmaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RhpK3IG5ZD7I6rWhqNt2aG21EViERHTk1ZTuGebg9BxKNL+YmdYaUZkH9djHTZc2e5LlVBVhBUqQzRrulg8aOf50lsPfmfyxJLpBgJDALA5f2nQiS8DF9zYErbSoXedPzNGRHnfQl93DyIMi7AkWqEqXh1jdl1+CTvmx6A8g5LA= Received: by 10.67.98.20 with SMTP id a20mr9263807ugm.1191266509370; Mon, 01 Oct 2007 12:21:49 -0700 (PDT) Received: by 10.67.29.14 with HTTP; Mon, 1 Oct 2007 12:21:49 -0700 (PDT) Message-ID: <499c70c0710011221n52b3d0f1ha3ab51de8d905d1d@mail.gmail.com> Date: Mon, 1 Oct 2007 22:21:49 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Nate Lawson" In-Reply-To: <470081CF.5050702@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0709271301g500d1d08gefe126bc65300d6c@mail.gmail.com> <499c70c0709271546i494a98au1a5d9dce4630a56c@mail.gmail.com> <46FC355A.1060807@root.org> <499c70c0709271559v515d1f7ev1a88acca94b68c4c@mail.gmail.com> <46FC3CB3.3060202@root.org> <46FFF493.3070800@root.org> <499c70c0709301620x6625a715t1247b70583c39619@mail.gmail.com> <47003695.1090104@root.org> <499c70c0709302057m3687639apbd628da297ff9c12@mail.gmail.com> <470081CF.5050702@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: INTEL D946GZIS acpi issues. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 19:21:52 -0000 On 10/1/07, Nate Lawson wrote: > > > Abdullah Ibn Hamad Al-Marri wrote: > > On 10/1/07, Nate Lawson wrote: > >> Yes, this won't fix cpufreq (need to figure out new Intel tables to make > >> that happen), but it will fix the "unable to allocate" error in dmesg > >> you first reported. > > > Nate, > > > > Thank you, > > > > Here is the new dmsg. > > > > > > FreeBSD 7.0-CURRENT #0: Mon Oct 1 02:49:06 GMT 2007 > > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > cpu0: on acpi0 > > Error message is gone. > > > here is devinfo -rv > > > > devinfo -rv > > nexus0 > > acpi0 > > I/O memory addresses: > > 0xc0000-0xdffff > > 0xe0000-0xfffff > > 0xf0000000-0xf7ffffff > > 0xfed00000-0xfed00fff > > acpi now properly owns this address range. > > > 0xfed13000-0xfed13fff > > 0xfed14000-0xfed17fff > > 0xfed18000-0xfed18fff > > 0xfed19000-0xfed19fff > > 0xfed1c000-0xfed1ffff > > 0xfed20000-0xfed9ffff > > > acpi_hpet0 pnpinfo unknown at unknown > > ACPI I/O memory addresses: > > 0xfed00000-0xfed003ff > > HPET still attaching. > > > I still see CPU supports Enhanced Speedstep, but is not recognized too. > > That is a separate problem, unrelated. Thanks for testing. > > -- > Nate Nate, Thank you for your hard work to make acpi better for FreeBSD }:) Could you please commit the hpet.diff into HEAD please? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 2 06:20:08 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A495B16A417 for ; Tue, 2 Oct 2007 06:20:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF5F13C474 for ; Tue, 2 Oct 2007 06:20:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id BE7E72086; Tue, 2 Oct 2007 08:02:23 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3AA21207E; Tue, 2 Oct 2007 08:02:23 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 20613844A4; Tue, 2 Oct 2007 08:02:23 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Abdullah Ibn Hamad Al-Marri" References: <499c70c0710011109k61d3365n84038115a26e0398@mail.gmail.com> Date: Tue, 02 Oct 2007 08:02:23 +0200 In-Reply-To: <499c70c0710011109k61d3365n84038115a26e0398@mail.gmail.com> (Abdullah Ibn Hamad Al-Marri's message of "Mon\, 1 Oct 2007 21\:09\:13 +0300") Message-ID: <86lkamawb4.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, FreeBSD Current Subject: Re: est doesn't support C2D E6600 and newer CPUs? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 06:20:08 -0000 "Abdullah Ibn Hamad Al-Marri" writes: > [...] No need for est, acpi_perf handles the E6600 just fine. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 2 06:33:16 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF72216A418 for ; Tue, 2 Oct 2007 06:33:16 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B711613C467 for ; Tue, 2 Oct 2007 06:33:16 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 60093 invoked from network); 2 Oct 2007 06:33:18 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 2 Oct 2007 06:33:18 -0000 Message-ID: <4701E62C.5030909@root.org> Date: Mon, 01 Oct 2007 23:33:16 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <499c70c0710011109k61d3365n84038115a26e0398@mail.gmail.com> <86lkamawb4.fsf@ds4.des.no> In-Reply-To: <86lkamawb4.fsf@ds4.des.no> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, FreeBSD Current Subject: Re: est doesn't support C2D E6600 and newer CPUs? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 06:33:17 -0000 Dag-Erling Smørgrav wrote: > "Abdullah Ibn Hamad Al-Marri" writes: >> [...] > > No need for est, acpi_perf handles the E6600 just fine. > > DES Depends on the mobo. Some export the info to acpi and some don't. The linux driver has some workarounds for that, but it's too complicated for me to spend time figuring out right now. You have to look at speedstep-centrino.c and several other files to get the full picture. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 2 18:53:42 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D50BE16A417; Tue, 2 Oct 2007 18:53:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 6E72613C45D; Tue, 2 Oct 2007 18:53:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 212557702-1834499 for multiple; Tue, 02 Oct 2007 14:53:36 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l92IrT8k013068; Tue, 2 Oct 2007 14:53:29 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Tue, 2 Oct 2007 14:07:26 -0400 User-Agent: KMail/1.9.6 References: <499c70c0710011109k61d3365n84038115a26e0398@mail.gmail.com> <86lkamawb4.fsf@ds4.des.no> <4701E62C.5030909@root.org> In-Reply-To: <4701E62C.5030909@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200710021407.27711.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 02 Oct 2007 14:53:30 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on server.baldwin.cx X-Virus-Status: Clean Cc: Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?= , FreeBSD Current Subject: Re: est doesn't support C2D E6600 and newer CPUs? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 18:53:43 -0000 On Tuesday 02 October 2007 02:33:16 am Nate Lawson wrote: > Dag-Erling Sm=C3=B8rgrav wrote: > > "Abdullah Ibn Hamad Al-Marri" writes: > >> [...] > >=20 > > No need for est, acpi_perf handles the E6600 just fine. > >=20 > > DES >=20 > Depends on the mobo. Some export the info to acpi and some don't. The > linux driver has some workarounds for that, but it's too complicated for > me to spend time figuring out right now. You have to look at > speedstep-centrino.c and several other files to get the full picture. At some point my laptop suddenly started getting CPU levels from ACPI while= I=20 was testing the patch below. The patch below did work for me though even=20 though it only supports the high and low settings. I #if 0'd the code in detach since detach always fails and it would be bad = to=20 free the frequency table out from under the driver w/o stopping it. Index: est.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/sys/i386/cpufreq/est.c,v retrieving revision 1.11 diff -u -r1.11 est.c =2D-- est.c 11 May 2006 17:35:44 -0000 1.11 +++ est.c 2 Oct 2007 18:04:58 -0000 @@ -38,6 +38,7 @@ #include =20 #include "cpufreq_if.h" +#include #include =20 #include @@ -70,6 +71,7 @@ struct est_softc { device_t dev; int acpi_settings; + int msr_settings; freq_info *freq_list; }; =20 @@ -897,6 +899,7 @@ static int est_get_info(device_t dev); static int est_acpi_info(device_t dev, freq_info **freqs); static int est_table_info(device_t dev, uint64_t msr, freq_info **freqs); +static int est_msr_info(device_t dev, uint64_t msr, freq_info **freqs); static freq_info *est_get_current(freq_info *freq_list); static int est_settings(device_t dev, struct cf_setting *sets, int *count); static int est_set(device_t dev, const struct cf_setting *set); @@ -1031,11 +1034,13 @@ static int est_detach(device_t dev) { +#if 0 struct est_softc *sc; =20 sc =3D device_get_softc(dev); =2D if (sc->acpi_settings) + if (sc->acpi_settings || sc->msr_settings) free(sc->freq_list, M_DEVBUF); +#endif return (ENXIO); } =20 @@ -1059,6 +1064,9 @@ if (error) error =3D est_acpi_info(dev, &sc->freq_list); =20 + if (error) + error =3D est_msr_info(dev, msr, &sc->freq_list); + if (error) { printf( "est: CPU supports Enhanced Speedstep, but is not recognized.\n" @@ -1149,6 +1157,77 @@ return (0); } =20 +/* + * Flesh out a simple rate table containing the high and low frequencies + * based on the current clock speed and the upper 32 bits of the MSR. + */ +static int +est_msr_info(device_t dev, uint64_t msr, freq_info **freqs) +{ + struct est_softc *sc; + freq_info *fp; + int bus, freq, volts; + uint16_t id; + + if (strcmp("GenuineIntel", cpu_vendor) !=3D 0) + return (EOPNOTSUPP); + + /* Figure out the bus clock. */ + freq =3D tsc_freq / 1000000; + id =3D msr >> 32; + bus =3D freq / (id >> 8); + device_printf(dev, "Guessed bus clock (high) of %d MHz\n", bus); + if (bus !=3D 100 && bus !=3D 133) { + /* We may be running on the low frequency. */ + id =3D msr >> 48; + bus =3D freq / (id >> 8); + device_printf(dev, "Guessed bus clock (low) of %d MHz\n", bus); + if (bus !=3D 100 && bus !=3D 133) + return (EOPNOTSUPP); + =09 + /* Calculate high frequency. */ + id =3D msr >> 32; + freq =3D ((id >> 8) & 0xff) * bus; + } + + /* Fill out a new freq table containing just the high and low freqs. */ + sc =3D device_get_softc(dev); + fp =3D malloc(sizeof(freq_info) * 3, M_DEVBUF, M_WAITOK | M_ZERO); + + /* First, the high frequency. */ + volts =3D id & 0xff; + if (volts !=3D 0) { + volts <<=3D 4; + volts +=3D 700; + } + fp[0].freq =3D freq; + fp[0].volts =3D volts; + fp[0].id16 =3D id; + fp[0].power =3D CPUFREQ_VAL_UNKNOWN; + device_printf(dev, "Guessed high setting of %d MHz @ %d Mv\n", freq, + volts); + + /* Second, the low frequency. */ + id =3D msr >> 48; + freq =3D ((id >> 8) & 0xff) * bus; + volts =3D id & 0xff; + if (volts !=3D 0) { + volts <<=3D 4; + volts +=3D 700; + } + fp[1].freq =3D freq; + fp[1].volts =3D volts; + fp[1].id16 =3D id; + fp[1].power =3D CPUFREQ_VAL_UNKNOWN; + device_printf(dev, "Guessed low setting of %d MHz @ %d Mv\n", freq, + volts); + + /* Table is already terminated due to M_ZERO. */ + sc->msr_settings =3D TRUE; + *freqs =3D fp; + return (0); +} + static freq_info * est_get_current(freq_info *freq_list) { =2D-=20 John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 15:38:34 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD9ED16A41B; Wed, 3 Oct 2007 15:38:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 7738313C469; Wed, 3 Oct 2007 15:38:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l93FcUEi080879; Wed, 3 Oct 2007 11:38:31 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 3 Oct 2007 11:38:26 -0400 User-Agent: KMail/1.6.2 References: <470002B5.6030002@root.org> In-Reply-To: <470002B5.6030002@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710031138.28820.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4461/Wed Oct 3 04:50:48 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 15:38:35 -0000 On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote: > Attached is a patch (one for 6, one for 7) that shouldn't break > anything for most people and may fix some battery status issues for > others. It changes how we run tasks during boot. It seems some > hardware expects synchronous access but our taskq is not running > until after interrupts are enabled. This patch bounces calls > through a wrapper that executes the callback directly if we're not > booted yet. Sorry, I didn't test it but I have some questions. Why do you add a wrapper and pollute all AcpiOsQueueForExecution()/AcpiOsExecute() consumers? Isn't it more simpler to let the function determine to queue or not to queue? Why do you check cold and rebooting flags? If you wanted to check the taskqueue is ready, you could check taskqueue_acpi is NULL or not, instead. Thanks, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:04:29 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DF516A46C for ; Wed, 3 Oct 2007 16:04:29 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 594FC13C4A7 for ; Wed, 3 Oct 2007 16:04:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 4142 invoked from network); 3 Oct 2007 16:04:29 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 3 Oct 2007 16:04:29 -0000 Message-ID: <4703BD8D.1080501@root.org> Date: Wed, 03 Oct 2007 09:04:29 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jung-uk Kim References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> In-Reply-To: <200710031138.28820.jkim@FreeBSD.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 16:04:29 -0000 Jung-uk Kim wrote: > On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote: >> Attached is a patch (one for 6, one for 7) that shouldn't break >> anything for most people and may fix some battery status issues for >> others. It changes how we run tasks during boot. It seems some >> hardware expects synchronous access but our taskq is not running >> until after interrupts are enabled. This patch bounces calls >> through a wrapper that executes the callback directly if we're not >> booted yet. > > Sorry, I didn't test it but I have some questions. Why do you add a > wrapper and pollute all AcpiOsQueueForExecution()/AcpiOsExecute() > consumers? Isn't it more simpler to let the function determine to > queue or not to queue? Why do you check cold and rebooting flags? > If you wanted to check the taskqueue is ready, you could check > taskqueue_acpi is NULL or not, instead. There are 2 different behaviors I'm trying to support and only the caller knows which one they want: 1. Run a task at some point in the future but "soon" 2. Queue a task to be run, definitely after boot is complete Notifies are in the first class. Initialization functions for the various drivers are in the second. ACPI-CA is moving to making all Notifies completely synchronous (i.e. they wait for the thread to run). So if we go to the model you describe (#1), this will work but suddenly the initialization of the drivers won't wait for boot. It will be run right away. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:36:24 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C9C416A418; Wed, 3 Oct 2007 16:36:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 38E7B13C458; Wed, 3 Oct 2007 16:36:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l93GaNxL085495; Wed, 3 Oct 2007 12:36:23 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Nate Lawson Date: Wed, 3 Oct 2007 12:36:19 -0400 User-Agent: KMail/1.6.2 References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> <4703BD8D.1080501@root.org> In-Reply-To: <4703BD8D.1080501@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710031236.21309.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4461/Wed Oct 3 04:50:48 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 16:36:24 -0000 On Wednesday 03 October 2007 12:04 pm, Nate Lawson wrote: > Jung-uk Kim wrote: > > On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote: > >> Attached is a patch (one for 6, one for 7) that shouldn't break > >> anything for most people and may fix some battery status issues > >> for others. It changes how we run tasks during boot. It seems > >> some hardware expects synchronous access but our taskq is not > >> running until after interrupts are enabled. This patch bounces > >> calls through a wrapper that executes the callback directly if > >> we're not booted yet. > > > > Sorry, I didn't test it but I have some questions. Why do you > > add a wrapper and pollute all > > AcpiOsQueueForExecution()/AcpiOsExecute() consumers? Isn't it > > more simpler to let the function determine to queue or not to > > queue? Why do you check cold and rebooting flags? If you wanted > > to check the taskqueue is ready, you could check taskqueue_acpi > > is NULL or not, instead. > > There are 2 different behaviors I'm trying to support and only the > caller knows which one they want: > > 1. Run a task at some point in the future but "soon" > 2. Queue a task to be run, definitely after boot is complete > > Notifies are in the first class. Initialization functions for the > various drivers are in the second. ACPI-CA is moving to making all > Notifies completely synchronous (i.e. they wait for the thread to > run). So if we go to the model you describe (#1), this will work > but suddenly the initialization of the drivers won't wait for boot. > It will be run right away. Understood. However, there are two conflicting Notify handler implemtations, i.e., 'synchronous' type with a semaphore (which is in newer unreleased ACPI-CA) and 'do not defer' type (which is in Linux kernel source): http://bugzilla.kernel.org/show_bug.cgi?id=5534 See the patches that are actually committed to Linux git tree: http://bugzilla.kernel.org/attachment.cgi?id=10429&action=view http://bugzilla.kernel.org/attachment.cgi?id=10430&action=view I believe the vendor didn't finalize the design yet. For now, we may have to try Linux way. Thanks, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:42:07 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 981EF16A469 for ; Wed, 3 Oct 2007 16:42:07 +0000 (UTC) (envelope-from dana.myers@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB4413C448 for ; Wed, 3 Oct 2007 16:42:07 +0000 (UTC) (envelope-from dana.myers@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so941148anc for ; Wed, 03 Oct 2007 09:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=XuuXItPH4aQlNEKSHe0xjhATyYPRV1OMfN5eXi4a3bA=; b=ZrIJZQmJgRgNM5ghxn4EIb+gamefBALFmC+hA4KUaxvIr3c4HcavWNstkjXWUsuyruioK+gJ5ASoaUKCfzDii03RbSvScgwBytyUJM/b+snIyTqOq3bsF53tHNNdjYTb9f8W/hwVSp2UoTdqKwEiS8mmaWQkFpijhZpxMIrLfJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ks2j+Yp2P3CFqi4OO5RxYtsnlg9ECvyGUEFq1eJryf4BGHa73kCUt/X6QqsrW/JC0m5zqRvLE8h6erm8rPHU0EQzOIf3mvnzzwn6kEoD7VP61RiO4tP+jl0Ij44HysAjbSx2qUgwJQDRgHobeQFcIL6AyZE/uavgZ2QUp5xEGj8= Received: by 10.142.135.9 with SMTP id i9mr717502wfd.1191428238497; Wed, 03 Oct 2007 09:17:18 -0700 (PDT) Received: from ?192.168.0.2? ( [67.180.22.170]) by mx.google.com with ESMTPS id f42sm1547301rvb.2007.10.03.09.17.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Oct 2007 09:17:17 -0700 (PDT) Message-ID: <4703C08B.6040703@gmail.com> Date: Wed, 03 Oct 2007 09:17:15 -0700 From: "Dana H. Myers" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nate Lawson References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> <4703BD8D.1080501@root.org> In-Reply-To: <4703BD8D.1080501@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Jung-uk Kim Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 16:42:07 -0000 Nate Lawson wrote: > 1. Run a task at some point in the future but "soon" > 2. Queue a task to be run, definitely after boot is complete > > Notifies are in the first class. Initialization functions for the > various drivers are in the second. ACPI-CA is moving to making all > Notifies completely synchronous (i.e. they wait for the thread to run). Note that I've encountered an issue with synchronous Notify in the Solaris port of ACPI CA on a particular machine. Specifically, the Acer Ferrari 3400 deadlocks while delivering AC/battery events, since Notify() is performed while holding a mutex. The AC/battery driver notify handler evaluates _STA and _BST, and either of these attempt to hold the same mutex. Bob Moore and I have been discussing solutions for this but have nothing firm at this point. While I suppose I *could* make the AC/battery driver Notify handler behave like a high-level interrupt and simply schedule yet another thread to run to handle the Notify, this scheme generally ends up the same as asynchronous Notify in the first place. Dana From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:51:05 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B36D116A421; Wed, 3 Oct 2007 16:51:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 73ECC13C469; Wed, 3 Oct 2007 16:51:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l93Gp4Y4086540; Wed, 3 Oct 2007 12:51:04 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 3 Oct 2007 12:50:59 -0400 User-Agent: KMail/1.6.2 References: <470002B5.6030002@root.org> <4703BD8D.1080501@root.org> <4703C08B.6040703@gmail.com> In-Reply-To: <4703C08B.6040703@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710031251.02304.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4461/Wed Oct 3 04:50:48 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 16:51:05 -0000 On Wednesday 03 October 2007 12:17 pm, Dana H. Myers wrote: > Nate Lawson wrote: > > 1. Run a task at some point in the future but "soon" > > 2. Queue a task to be run, definitely after boot is complete > > > > Notifies are in the first class. Initialization functions for > > the various drivers are in the second. ACPI-CA is moving to > > making all Notifies completely synchronous (i.e. they wait for > > the thread to run). > > Note that I've encountered an issue with synchronous Notify in the > Solaris port of ACPI CA on a particular machine. > > Specifically, the Acer Ferrari 3400 deadlocks while delivering > AC/battery events, since Notify() is performed while holding > a mutex. The AC/battery driver notify handler evaluates _STA > and _BST, and either of these attempt to hold the same mutex. Ha, my laptop at work is Acer Ferrari 3400. :-) > Bob Moore and I have been discussing solutions for this but > have nothing firm at this point. > > While I suppose I *could* make the AC/battery driver Notify > handler behave like a high-level interrupt and simply schedule > yet another thread to run to handle the Notify, this scheme > generally ends up the same as asynchronous Notify in the first > place. Precisely. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 17:03:48 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F378716A418 for ; Wed, 3 Oct 2007 17:03:47 +0000 (UTC) (envelope-from dana.myers@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id A9AF313C45A for ; Wed, 3 Oct 2007 17:03:47 +0000 (UTC) (envelope-from dana.myers@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so943026anc for ; Wed, 03 Oct 2007 10:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=Uekg6vtJc+ZhyDUq+1HDVq9mQl4pkD/tTlaP8DbC8uA=; b=dch8y8j+sXlMhU+tZNwE4j6rfJEDKuT842yFpqMcVmxtcyRsz2LHe1J0mOZESxbERbzP6mpcoLTOMKFmJ3z+low0APv/f2PNYvuySxerjbZJqux10mu3tY95X6oZQyEn6jZqQkkAYT4c6njhkmJkIRubBzmCqU1TrgFvKFxL46U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=SIK4NMd3Cb+G6nt8oCu3lK/L9YD6qLdaS8DAmpRLFA1BGhY/OvdzyD+1D9hBgA80100HWDUrcVy6NBPI9fNl4vc4Q85dcbKs/4oWutjb/Rg4e/bp5//XhrHCixkr4rPzA1KGXMSV3kuV+TFOvDGj966lYG4/PBHlTW4Wett/MLA= Received: by 10.142.102.5 with SMTP id z5mr898341wfb.1191429555484; Wed, 03 Oct 2007 09:39:15 -0700 (PDT) Received: from ?192.168.0.2? ( [67.180.22.170]) by mx.google.com with ESMTPS id g31sm1584617rvb.2007.10.03.09.39.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Oct 2007 09:39:15 -0700 (PDT) Message-ID: <4703C59C.3040700@gmail.com> Date: Wed, 03 Oct 2007 09:38:52 -0700 From: "Dana H. Myers" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Method returns package results in interpreter panic - is anyone seeing this on FreeBSD ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 17:03:48 -0000 I'm seeing a kernel panic in the ACPI CA interpreter under Solaris, but I don't believe it is Solaris-specific. The panic reliably happens when evaluating a method which returns a package which contains a named object as an element. method. Here's the panic stack trace, with excess stuff trimmed: ffffff00025c2e90 unix:die+f4 () ffffff00025c2fc0 unix:trap+38e () ffffff00025c2fd0 unix:cmntrap+1d0 () ffffff00025c30e0 acpica:AcpiNsGetParentNode+2b () ffffff00025c3110 acpica:AcpiNsGetPathnameLength+38 () ffffff00025c3160 acpica:AcpiUtGetSimpleObjectSize+8f () ffffff00025c31b0 acpica:AcpiUtGetElementLength+32 () ffffff00025c3230 acpica:AcpiUtWalkPackageTree+aa () ffffff00025c3290 acpica:AcpiUtGetPackageObjectSize+6d () ffffff00025c32d0 acpica:AcpiUtGetObjectSize+3d () ffffff00025c3350 acpica:AcpiEvaluateObject+1d4 () ffffff00025c33c0 acpica:AcpiEvaluateObjectTyped+72 () AcpiNsGetParentNode() panics when it attempts to follow a namespace node peer link. The node, however, is uninitialized. The case which causes this is reproduced reliably by this simplified test case: Method(DANA, 0, NotSerialized) { Name (DOM1, 0x02) Return(Package() { Package() { 0x00, 0x01, DOM1, 0x03, 0x04 } } ) } Simply evaluating DANA causes the panic when AcpiUtGetElementLength() tries to handle DOM1 - it's apparently a "local reference" and the namespace node is apparently uninitialized. So AcpiNsGetParentNode() panics trying to find the parent when it attempts to access memory at 0xCACACACACACACACA. If I replace DOM1 in the package with 0x02, the panic goes away. Has anyone encountered this on FreeBSD? Thanks - Dana From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 4 07:06:54 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB87216A419 for ; Thu, 4 Oct 2007 07:06:54 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (bns.tns.cz [213.194.214.115]) by mx1.freebsd.org (Postfix) with ESMTP id 785B913C458 for ; Thu, 4 Oct 2007 07:06:54 +0000 (UTC) (envelope-from rp@tns.cz) Received: from bns.tns.cz (localhost [127.0.0.1]) by bns.tns.cz (Postfix) with ESMTP id 9A93055E63A for ; Thu, 4 Oct 2007 09:06:52 +0200 (CEST) Received: from belzebub.tns.cz (belzebub [192.168.144.3]) by bns.tns.cz with ESMTP id 4E14H1G00018LYQFKGI; Thu, 4 Oct 2007 09:06:52 +0200 (CEST) Received: by belzebub.tns.cz (Postfix, from userid 1001) id 1548E16ADB7; Thu, 4 Oct 2007 09:10:05 +0200 (CEST) Date: Thu, 4 Oct 2007 09:10:05 +0200 From: Roman Pavlik To: freebsd-acpi@freebsd.org Message-ID: <20071004071005.GA8751@belzebub.tns.cz> References: <20070917115601.GA1371@belzebub.tns.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46FC2B86.9000100@root.org> User-Agent: Mutt/1.5.12-2006-07-14 Subject: Re: boot hangs with acpi enabled? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2007 07:06:54 -0000 > Could anyone who is experiencing a boot-time hang on 7-current with acpi > enabled send some information? First, be sure your system works with > acpi disabled (hint.acpi.0.disabled="1"), otherwise it's something else. > > Then, compile your kernel with: > options DDB > options KDB > > Reboot with the new kernel and hit CTRL-ALT-ESC when the boot hangs. > Type "trace" to get a stack trace as to what's hung. Copy down those > lines or take a small photo and send it back. Sorry for _very_ late answer. Partially because docs.freebsd.org kiding about chunk size it sends (http://www.freebsd.org/cgi/query-pr.cgi?pr=116660) and our firewall really does not like it... I hit CTRL-ALT-ESC when the boot hangs, the result is: KDB: enter: manual escape to debugger [thread pid 18 tid 100008 ] Stopped at kdb_enter+0x32: leave db> trace Tracing pid 18 tid 100008 td 0xc50f4420 kdb_enter(c0a87315,4,1,0,1,...) at kdb_enter+0x32 scgetc(e3c9ec60,c07846fc,c50f4420,c0bfaae8,c50f44b8,...) at scgetc+0x54f sckbdevent(c50f7c00,0,c0c1f060,c50ed680,e3c9ec88,...) at sckbdevent+0x204 kdbmux_intr(c50f7c00,0,c50ed698,e3c9ecb8,c077e12b,...) at kdbmux_intr+0x2b kbdmux_kbd_intr(c50f7c00,1,c0a9c9bd,52,c51e5a1c,...) at kbdmux_kbd_intr+0x25 taskqueue_run(c51e5a00,e3c9ecf8,c0732445,0,0,...) at taskqueue_run+0x10b taskqueue_swi_giant_run(0,0,c0a959fa,40b,c51e59e4,...) at taskqueue_swi_giant_run+0x13 ithread_loop(c51e6170,e3c9ed38,c0a95776,314,c50f3550,...) at ithread_loop+0x1b5 fork_exit(c0732290,c51e6170,e3c9ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe3c9ed70, ebp = 0 --- db> Regards, -- Roman From owner-freebsd-acpi@FreeBSD.ORG Sat Oct 6 17:35:14 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B333616A418 for ; Sat, 6 Oct 2007 17:35:14 +0000 (UTC) (envelope-from per-olof.nilsson@comhem.se) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB2813C458 for ; Sat, 6 Oct 2007 17:35:14 +0000 (UTC) (envelope-from per-olof.nilsson@comhem.se) Received: from c83-249-37-37.bredband.comhem.se ([83.249.37.37]:55322) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1IeDJd-000197-6p for freebsd-acpi@FreeBSD.org; Sat, 06 Oct 2007 19:19:49 +0200 From: Peo Nilsson To: freebsd-acpi@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-kPRgyHDwR2UdvpnNHMOr" Date: Sat, 06 Oct 2007 19:23:28 +0200 Message-Id: <1191691408.962.4.camel@zeus.se> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port X-Originating-IP: 83.249.37.37 X-Scan-Result: No virus found in message 1IeDJd-000197-6p. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1IeDJd-000197-6p bdd24ece5bc1ed9f5026ac9c16a68e86 Cc: Subject: ACPI (errors) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2007 17:35:14 -0000 --=-kPRgyHDwR2UdvpnNHMOr Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear list. Can anyone explain to me what this means (kb1) : =46rom xorg log: ... kbd1 at kbdmux0 ACPI-0314: *** Error: Invalid signature where RSDP indicates RSDT/XSDT should be located ACPI-0325: *** Error: Looking for RSDT (RSDP->Rev < 2) ACPI-0181: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE ACPI: table load failed: AE_BAD_SIGNATURE ... ... atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ... What is this kbd1 ? Can I get rid of this errors ? --=20 /Peo --=-kPRgyHDwR2UdvpnNHMOr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHB8SLgWSfflYlIbwRAqR5AJ4y2FUUmL59sAvqDi9V/KpCOZutzQCaA5dJ QAH4XIjeGgZKSD3WkpWfLOw= =SCPM -----END PGP SIGNATURE----- --=-kPRgyHDwR2UdvpnNHMOr--