From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 30 11:06:46 2009 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 B98D81065679 for ; Mon, 30 Nov 2009 11:06:46 +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 8CE5E8FC0A for ; Mon, 30 Nov 2009 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUB6k5b043326 for ; Mon, 30 Nov 2009 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUB6jsI043324 for freebsd-acpi@FreeBSD.org; Mon, 30 Nov 2009 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Nov 2009 11:06:46 GMT Message-Id: <200911301106.nAUB6jsI043324@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 freebsd-acpi@FreeBSD.org 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, 30 Nov 2009 11:06:46 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/140979 acpi [acpi] [panic] Kernel panic (fatal trap 12: page fault o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o kern/136808 acpi [acpi] panic when switching to s3 o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode f kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 f kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 56 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 30 14:00:05 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC081065676 for ; Mon, 30 Nov 2009 14:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FFB48FC1B for ; Mon, 30 Nov 2009 14:00:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUE04JN094895 for ; Mon, 30 Nov 2009 14:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUE04Ik094894; Mon, 30 Nov 2009 14:00:04 GMT (envelope-from gnats) Date: Mon, 30 Nov 2009 14:00:04 GMT Message-Id: <200911301400.nAUE04Ik094894@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 14:00:05 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, tungan@ukr.net Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Mon, 30 Nov 2009 15:57:23 +0200 Could you please reproduce this with debug enabled? E.g.: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Without a backtrace it's hard to see where the problem is. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 30 20:10:03 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCDF41065670 for ; Mon, 30 Nov 2009 20:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3E298FC1C for ; Mon, 30 Nov 2009 20:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUKA3kY014233 for ; Mon, 30 Nov 2009 20:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUKA34I014226; Mon, 30 Nov 2009 20:10:03 GMT (envelope-from gnats) Date: Mon, 30 Nov 2009 20:10:03 GMT Message-Id: <200911302010.nAUKA34I014226@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: "Grv" Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Grv List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 20:10:03 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: "Grv" To: Andriy Gapon Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Mon, 30 Nov 2009 21:45:55 +0200 This is a multi-part message in MIME format. --_----------=_12596103552180413 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" Unfortunately I can't save core dump despite configured debugging settings, system just doesn't see it in swap, probably because the crash occurs before swap is configured. What other options do I have? --- Original Message --- From: Andriy Gapon To: bug-followup@FreeBSD.org, tungan@ukr.net Date: 30 november, 15:57:23 Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Could you please reproduce this with debug enabled? E.g.: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Without a backtrace it's hard to see where the problem is. -- Andriy Gapon --_----------=_12596103552180413 Content-Disposition: inline Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="windows-1251"
Unfortunately I can't save core dump despite configured debugging
settings, system just doesn't see it in swap, probably because the crash
occurs before swap is configured.
What other options do I have?

--- Original Message ---
From: Andriy Gapon <avg@icyb.net.ua>
To: bug-followup@FreeBSD.org, tungan@ukr.net
Date: 30 november, 15:57:23
Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device

Could you please reproduce this with debug enabled?
E.g.:
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html

Without a backtrace it's hard to see where the problem is.

--
Andriy Gapon

--_----------=_12596103552180413-- From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 1 13:50:03 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6B31065679 for ; Tue, 1 Dec 2009 13:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD4FA8FC18 for ; Tue, 1 Dec 2009 13:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB1Do3Tn067874 for ; Tue, 1 Dec 2009 13:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB1Do3Xg067873; Tue, 1 Dec 2009 13:50:03 GMT (envelope-from gnats) Date: Tue, 1 Dec 2009 13:50:03 GMT Message-Id: <200912011350.nB1Do3Xg067873@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 13:50:04 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Andriy Gapon To: Tarick Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Tue, 01 Dec 2009 15:48:38 +0200 on 30/11/2009 21:38 Tarick said the following: > Unfortunately I can't save core dump despite configured debugging > settings, system just doesn't see it in swap, probably because the crash > occurs before swap is configured. > What other options do I have? Could you please boot with ec disabled (via the hint) and do the following? In shell: $ kgdb /boot/kernel/kernel /dev/mem In kgdb: (kgdb) info line *0xffffffff001ccfa0 And send back the output of the last command. Thanks. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 1 21:10:04 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2556B1065692 for ; Tue, 1 Dec 2009 21:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id ED76B8FC13 for ; Tue, 1 Dec 2009 21:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB1LA39m048160 for ; Tue, 1 Dec 2009 21:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB1LA3bB048159; Tue, 1 Dec 2009 21:10:03 GMT (envelope-from gnats) Date: Tue, 1 Dec 2009 21:10:03 GMT Message-Id: <200912012110.nB1LA3bB048159@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Tarick Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tarick List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 21:10:04 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Tarick To: Andriy Gapon Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Tue, 01 Dec 2009 21:39:09 +0200 Sure, as I understand this means booting with debug.acpi.disabled="ec" line in /boot/loader.conf. I use this setting constantly right now. But I recompiled kernel recently, and the instruction pointer address changed to 0xffffffff801bfe20. Here is result with this address, I hope this will help: _______________________________________________________________ ~# kgdb /boot/kernel/kernel /dev/mem GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Reading symbols from /boot/kernel/sem.ko...Reading symbols from /boot/kernel/sem.ko.symbols...done. done. Loaded symbols for /boot/kernel/sem.ko Reading symbols from /usr/local/lib/oss/modules/osscore.ko...done. Loaded symbols for /usr/local/lib/oss/modules/osscore.ko Reading symbols from /usr/local/lib/oss/modules/oss_hdaudio.ko...done. Loaded symbols for /usr/local/lib/oss/modules/oss_hdaudio.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from /boot/kernel/ng_pppoe.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_pppoe.ko #0 sched_switch (td=0xffffffff80962140, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid = PCPU_GET(cpuid); (kgdb) info line *0xffffffff801bfe20 Line 538 of "/usr/src/sys/contrib/dev/acpica/executer/exmutex.c" starts at address 0xffffffff801bfe20 and ends at 0xffffffff801bfe25 . (kgdb) __________________________________________________________ -----Original Message----- From: Andriy Gapon To: Tarick Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Tue, 01 Dec 2009 15:48:38 +0200 on 30/11/2009 21:38 Tarick said the following: > Unfortunately I can't save core dump despite configured debugging > settings, system just doesn't see it in swap, probably because the crash > occurs before swap is configured. > What other options do I have? Could you please boot with ec disabled (via the hint) and do the following? In shell: $ kgdb /boot/kernel/kernel /dev/mem In kgdb: (kgdb) info line *0xffffffff001ccfa0 And send back the output of the last command. Thanks. From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 2 06:40:02 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBEE0106566B for ; Wed, 2 Dec 2009 06:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF36D8FC17 for ; Wed, 2 Dec 2009 06:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB26e25d048498 for ; Wed, 2 Dec 2009 06:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB26e2VQ048497; Wed, 2 Dec 2009 06:40:02 GMT (envelope-from gnats) Date: Wed, 2 Dec 2009 06:40:02 GMT Message-Id: <200912020640.nB26e2VQ048497@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:40:03 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Andriy Gapon To: Tarick Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Wed, 02 Dec 2009 08:39:02 +0200 on 01/12/2009 21:39 Tarick said the following: > Sure, as I understand this means booting with debug.acpi.disabled="ec" > line in /boot/loader.conf. I use this setting constantly right now. > But I recompiled kernel recently, and the instruction pointer address > changed to 0xffffffff801bfe20. Here is result with this address, I hope > this will help: [snip] > (kgdb) info line *0xffffffff801bfe20 > Line 538 of "/usr/src/sys/contrib/dev/acpica/executer/exmutex.c" > starts at address 0xffffffff801bfe20 and > ends at 0xffffffff801bfe25 . So this points us to AcpiExReleaseMutex. One possible control flow chain is AcpiExReleaseMutex <- AcpiReleaseGlobalLock <- EcUnlock. But it's still not clear what could be wrong. Would it be possible to recompile your kernel with the following options, reproduce the panic and report full panic message? makeoptions DEBUG="-O -g" options DDB options DDB_NUMSYM options KDB options KDB_TRACE This should enable printing of stack trace on panic. Thanks! -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 2 18:00:11 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B751710656AB for ; Wed, 2 Dec 2009 18:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACF78FC1D for ; Wed, 2 Dec 2009 18:00:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB2I0BrF007756 for ; Wed, 2 Dec 2009 18:00:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB2I0B5D007755; Wed, 2 Dec 2009 18:00:11 GMT (envelope-from gnats) Date: Wed, 2 Dec 2009 18:00:11 GMT Message-Id: <200912021800.nB2I0B5D007755@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Tarick Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tarick List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:00:11 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Tarick To: Andriy Gapon Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Wed, 02 Dec 2009 19:57:53 +0200 Done, common panic message, but last line: [thread pid 0 tid 100000 ] Stopped at 0xffffffff801c95a8 = AcpiExReleaseMutex+0x218: movzbi 0x40(% rax), %r14d db> If more data are needed from debugger, please tell me so, but I may end up sending you movies or jpg. -----Original Message----- From: Andriy Gapon To: Tarick Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Wed, 02 Dec 2009 08:39:02 +0200 So this points us to AcpiExReleaseMutex. One possible control flow chain is AcpiExReleaseMutex <- AcpiReleaseGlobalLock <- EcUnlock. But it's still not clear what could be wrong. Would it be possible to recompile your kernel with the following options, reproduce the panic and report full panic message? makeoptions DEBUG="-O -g" options DDB options DDB_NUMSYM options KDB options KDB_TRACE This should enable printing of stack trace on panic. Thanks! From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 2 18:10:03 2009 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE6CF10656A9 for ; Wed, 2 Dec 2009 18:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CA9738FC12 for ; Wed, 2 Dec 2009 18:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB2IA3fl018343 for ; Wed, 2 Dec 2009 18:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB2IA3wF018342; Wed, 2 Dec 2009 18:10:03 GMT (envelope-from gnats) Date: Wed, 2 Dec 2009 18:10:03 GMT Message-Id: <200912021810.nB2IA3wF018342@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:10:03 -0000 The following reply was made to PR kern/140979; it has been noted by GNATS. From: Andriy Gapon To: Tarick Cc: bug-followup@FreeBSD.org Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Date: Wed, 02 Dec 2009 20:07:17 +0200 on 02/12/2009 19:57 Tarick said the following: > Done, common panic message, but last line: > > [thread pid 0 tid 100000 ] > Stopped at 0xffffffff801c95a8 = AcpiExReleaseMutex+0x218: movzbi 0x40(% > rax), %r14d > db> > > If more data are needed from debugger, please tell me so, but I may end > up sending you movies or jpg. Let's start with 'bt' command. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 3 09:24:08 2009 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 27F691065672 for ; Thu, 3 Dec 2009 09:24:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D30098FC16 for ; Thu, 3 Dec 2009 09:24:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA19226; Thu, 03 Dec 2009 11:24:04 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NG7uu-000Emt-F9; Thu, 03 Dec 2009 11:24:04 +0200 Message-ID: <4B178387.4050601@icyb.net.ua> Date: Thu, 03 Dec 2009 11:23:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org, "Moore, Robert" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tarick Subject: panic in AcpiExReleaseMutex 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, 03 Dec 2009 09:24:08 -0000 We are trying to resolve an issue reported in the following FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=140979 There is some additional information in: http://people.freebsd.org/~avg/pr140979/ This is 8-stable, so ACPICA version is 20090521. It looks like a NULL-pointer issue in AcpiExReleaseMutex. The reported line where the trap happens is the following: PreviousSyncLevel = WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; Fault address is 0x40 which is exactly an offset of OriginalSyncLevel within ACPI_OBJECT_MUTEX on amd64 platform. My understanding of the stacktrace on the pictures is the following. >From EC driver we call AcpiInstallAddressSpaceHandler to install EcSpaceHandler function for ACPI_ADR_SPACE_EC. As I understand, that leads to execution of _REG method of EC device. _REG method seems to access some registers in EC address space (with \_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access triggers a call to EcSpaceHandler. Now, we have a code in EcSpaceHandler that makes a direct call to EcGpeQueryHandler during a cold boot phase if SCI bit is set in CSR register. EcGpeQueryHandler performs an EC query and executes _Qxx method if need. Apparently, in our case that code path was taken and we got the NULL-pointer problem while evaluating AML Release function in either _Q20 or _Q09. Both of them acquire and release the already mentioned \_SB.PCI0.LPC0.EC0.MUT1 Mutex. Does my interpretation sound correct? Does this scenario ring any bells? Does our EC driver do everything correct? I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 in this situation. But I am not sure if it's an issue with AML or with our code. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 04:57:21 2009 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 0BA72106566B for ; Fri, 4 Dec 2009 04:57:18 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id AE59A8FC0A for ; Fri, 4 Dec 2009 04:57:18 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2009 20:52:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,339,1257148800"; d="scan'208";a="752726546" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2009 20:57:16 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx604.amr.corp.intel.com ([10.250.113.17]) with mapi; Thu, 3 Dec 2009 20:57:17 -0800 From: "Moore, Robert" To: Andriy Gapon , "freebsd-acpi@freebsd.org" Date: Thu, 3 Dec 2009 20:57:16 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acpz+mBME2OdDzj5SQWVtBgIcgIlIAAo5isg Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> In-Reply-To: <4B178387.4050601@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 04:57:21 -0000 >I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 It is OK for AML code to acquire a mutex multiple times, so I don't think t= hat is the problem. > PreviousSyncLevel =3D > WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; Multiple pointers here, do you know which one is null? >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Thursday, December 03, 2009 1:23 AM >To: freebsd-acpi@freebsd.org; Moore, Robert >Cc: Tarick >Subject: panic in AcpiExReleaseMutex > > >We are trying to resolve an issue reported in the following FreeBSD PR: >http://www.freebsd.org/cgi/query-pr.cgi?pr=3D140979 > >There is some additional information in: >http://people.freebsd.org/~avg/pr140979/ > >This is 8-stable, so ACPICA version is 20090521. > >It looks like a NULL-pointer issue in AcpiExReleaseMutex. >The reported line where the trap happens is the following: > > PreviousSyncLevel =3D > WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; > >Fault address is 0x40 which is exactly an offset of OriginalSyncLevel >within >ACPI_OBJECT_MUTEX on amd64 platform. > >My understanding of the stacktrace on the pictures is the following. >From EC driver we call AcpiInstallAddressSpaceHandler to install >EcSpaceHandler >function for ACPI_ADR_SPACE_EC. As I understand, that leads to execution >of >_REG method of EC device. _REG method seems to access some registers in E= C >address space (with \_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access >triggers >a call to EcSpaceHandler. Now, we have a code in EcSpaceHandler that make= s >a >direct call to EcGpeQueryHandler during a cold boot phase if SCI bit is se= t >in >CSR register. EcGpeQueryHandler performs an EC query and executes _Qxx >method >if need. Apparently, in our case that code path was taken and we got the >NULL-pointer problem while evaluating AML Release function in either _Q20 >or >_Q09. Both of them acquire and release the already mentioned >\_SB.PCI0.LPC0.EC0.MUT1 Mutex. > >Does my interpretation sound correct? >Does this scenario ring any bells? >Does our EC driver do everything correct? > >I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 in >this >situation. But I am not sure if it's an issue with AML or with our code. > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 05:24:26 2009 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 B5EA3106566B for ; Fri, 4 Dec 2009 05:24:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 03EB28FC15 for ; Fri, 4 Dec 2009 05:24:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id HAA09160; Fri, 04 Dec 2009 07:24:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NGQeR-000ISs-Vx; Fri, 04 Dec 2009 07:24:20 +0200 Message-ID: <4B189CD6.30906@icyb.net.ua> Date: Fri, 04 Dec 2009 07:23:34 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: Re: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 05:24:26 -0000 on 04/12/2009 06:57 Moore, Robert said the following: >> I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 > > It is OK for AML code to acquire a mutex multiple times, so I don't think that is the problem. > >> PreviousSyncLevel = >> WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; > > Multiple pointers here, do you know which one is null? > It must be AcquiredMutexList, because WalkState->Thread is checked for NULL a few lines above. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 18:45:23 2009 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 1EEFE1065696 for ; Fri, 4 Dec 2009 18:45:23 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id EA33B8FC26 for ; Fri, 4 Dec 2009 18:45:22 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 04 Dec 2009 10:45:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="218945998" Received: from orsmsx601.amr.corp.intel.com ([10.22.226.213]) by azsmga001.ch.intel.com with ESMTP; 04 Dec 2009 10:45:14 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Fri, 4 Dec 2009 10:45:13 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 10:45:11 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp0ogsptUDjOeZmRHKv65634ATWDwAbiW6w Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> In-Reply-To: <4B189CD6.30906@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 18:45:23 -0000 Yes, you are correct. I did not have the code in front of me at the time. When AcpiExReleaseMutex is called, apparently the mutex is in fact held, ot= herwise the function would have aborted immediately. When the mutex is held, the Thread->AcquiredMutexList is expected to hold (= at the minimum) the mutex object being released. Something is very wrong if= this list is NULL when releasing the mutex. Just to make sure: All of this is happening in the same thread? >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Thursday, December 03, 2009 9:24 PM >To: Moore, Robert >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: Re: panic in AcpiExReleaseMutex > >on 04/12/2009 06:57 Moore, Robert said the following: >>> I am somewhat suspicious of recursive use of \_SB.PCI0.LPC0.EC0.MUT1 >> >> It is OK for AML code to acquire a mutex multiple times, so I don't thin= k >that is the problem. >> >>> PreviousSyncLevel =3D >>> WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; >> >> Multiple pointers here, do you know which one is null? >> > >It must be AcquiredMutexList, because WalkState->Thread is checked for NUL= L >a >few lines above. > > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 20:50:46 2009 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 A36011065676 for ; Fri, 4 Dec 2009 20:50:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E28448FC0C for ; Fri, 4 Dec 2009 20:50:45 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA23783; Fri, 04 Dec 2009 22:50:38 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NGf6s-000JoY-IS; Fri, 04 Dec 2009 22:50:38 +0200 Message-ID: <4B1975EE.5070803@icyb.net.ua> Date: Fri, 04 Dec 2009 22:49:50 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: Re: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 20:50:46 -0000 on 04/12/2009 20:45 Moore, Robert said the following: > Yes, you are correct. I did not have the code in front of me at the time. > > When AcpiExReleaseMutex is called, apparently the mutex is in fact held, > otherwise the function would have aborted immediately. > > When the mutex is held, the Thread->AcquiredMutexList is expected to hold (at > the minimum) the mutex object being released. Something is very wrong if this > list is NULL when releasing the mutex. > > Just to make sure: All of this is happening in the same thread? Yes, this happens when there is only the initial thread running on BSP, no other threads are started yet. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 20:59:42 2009 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 2C2FD106568B for ; Fri, 4 Dec 2009 20:59:42 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 024D28FC16 for ; Fri, 4 Dec 2009 20:59:41 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 04 Dec 2009 12:59:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,344,1257148800"; d="scan'208";a="472965015" Received: from orsmsx601.amr.corp.intel.com ([10.22.226.213]) by orsmga002.jf.intel.com with ESMTP; 04 Dec 2009 12:59:36 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx601.amr.corp.intel.com ([10.22.226.213]) with mapi; Fri, 4 Dec 2009 12:59:41 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 12:59:39 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1I3OygVYgasCbQLaTpWo+B3vr2gAAPAxw Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> In-Reply-To: <4B1975EE.5070803@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 20:59:42 -0000 It would appear that a GPE is taken, for the EC device, thus invoking EcGpe= QueryHandler. In what context is _Q20 or _Q09 executed? This might be an important question: What is the thread_id of this initial = thread? >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Friday, December 04, 2009 12:50 PM >To: Moore, Robert >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: Re: panic in AcpiExReleaseMutex > >on 04/12/2009 20:45 Moore, Robert said the following: >> Yes, you are correct. I did not have the code in front of me at the time= . >> >> When AcpiExReleaseMutex is called, apparently the mutex is in fact held, >> otherwise the function would have aborted immediately. >> >> When the mutex is held, the Thread->AcquiredMutexList is expected to hol= d >(at >> the minimum) the mutex object being released. Something is very wrong if >this >> list is NULL when releasing the mutex. >> >> Just to make sure: All of this is happening in the same thread? > >Yes, this happens when there is only the initial thread running on BSP, no >other >threads are started yet. > > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:08:49 2009 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 758AE1065672 for ; Fri, 4 Dec 2009 21:08:49 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 370E98FC17 for ; Fri, 4 Dec 2009 21:08:48 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 04 Dec 2009 13:08:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,344,1257148800"; d="scan'208";a="575772004" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by orsmga001.jf.intel.com with ESMTP; 04 Dec 2009 13:08:34 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Fri, 4 Dec 2009 13:08:48 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 13:08:46 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1I3OygVYgasCbQLaTpWo+B3vr2gAAPAxwAABVVtA= Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2BC7@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:08:49 -0000 >Now, we have a code in EcSpaceHandler that makes a >direct call to EcGpeQueryHandler during a cold boot phase if SCI bit is se= t >in >CSR register. EcGpeQueryHandler performs an EC query and executes _Qxx >method if need. OK, I see. No GPE, but a direct call to the handler, which makes a query an= d invokes _Q20 or _Q09 What is the thread_id, and does it ever change for this thread? >-----Original Message----- >From: Moore, Robert >Sent: Friday, December 04, 2009 1:00 PM >To: 'Andriy Gapon' >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: RE: panic in AcpiExReleaseMutex > >It would appear that a GPE is taken, for the EC device, thus invoking >EcGpeQueryHandler. In what context is _Q20 or _Q09 executed? > >This might be an important question: What is the thread_id of this initial >thread? > > > >>-----Original Message----- >>From: Andriy Gapon [mailto:avg@icyb.net.ua] >>Sent: Friday, December 04, 2009 12:50 PM >>To: Moore, Robert >>Cc: freebsd-acpi@freebsd.org; Tarick >>Subject: Re: panic in AcpiExReleaseMutex >> >>on 04/12/2009 20:45 Moore, Robert said the following: >>> Yes, you are correct. I did not have the code in front of me at the >time. >>> >>> When AcpiExReleaseMutex is called, apparently the mutex is in fact held= , >>> otherwise the function would have aborted immediately. >>> >>> When the mutex is held, the Thread->AcquiredMutexList is expected to >hold >>(at >>> the minimum) the mutex object being released. Something is very wrong i= f >>this >>> list is NULL when releasing the mutex. >>> >>> Just to make sure: All of this is happening in the same thread? >> >>Yes, this happens when there is only the initial thread running on BSP, n= o >>other >>threads are started yet. >> >> >>-- >>Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:21:06 2009 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 555951065670 for ; Fri, 4 Dec 2009 21:21:06 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 91C888FC0A for ; Fri, 4 Dec 2009 21:21:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA24035; Fri, 04 Dec 2009 23:21:01 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NGfaG-000Jqx-T9; Fri, 04 Dec 2009 23:21:01 +0200 Message-ID: <4B197D0E.1020400@icyb.net.ua> Date: Fri, 04 Dec 2009 23:20:14 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: Re: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:21:06 -0000 on 04/12/2009 22:59 Moore, Robert said the following: > It would appear that a GPE is taken, for the EC device, thus invoking > EcGpeQueryHandler. In what context is _Q20 or _Q09 executed? It's invoked in "polling mode" at that stage. Interrupts are not enabled yet at that point. Let me quote my original report: [quote] _REG method seems to access some registers in EC address space (with \_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access triggers a call to EcSpaceHandler. Now, we have a code in EcSpaceHandler that makes a direct call to EcGpeQueryHandler during a cold boot phase if SCI bit is set in CSR register. EcGpeQueryHandler performs an EC query and executes _Qxx method if need. [/quote] So, everything happens in the same thread with the same context and stack. > This might be an important question: What is the thread_id of this initial > thread? This thread has a fixed tid of 100000. >> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua] >> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc: >> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in AcpiExReleaseMutex >> >> on 04/12/2009 20:45 Moore, Robert said the following: >>> Yes, you are correct. I did not have the code in front of me at the time. >>> >>> >>> >>> >>> When AcpiExReleaseMutex is called, apparently the mutex is in fact held, >>> otherwise the function would have aborted immediately. >>> >>> When the mutex is held, the Thread->AcquiredMutexList is expected to hold >>> >>> >>> >> (at >>> the minimum) the mutex object being released. Something is very wrong if >> this >>> list is NULL when releasing the mutex. >>> >>> Just to make sure: All of this is happening in the same thread? >> Yes, this happens when there is only the initial thread running on BSP, no >> other threads are started yet. >> >> >> -- Andriy Gapon -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:24:57 2009 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 27409106566C for ; Fri, 4 Dec 2009 21:24:57 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id EFDED8FC0C for ; Fri, 4 Dec 2009 21:24:56 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 04 Dec 2009 13:24:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,344,1257148800"; d="scan'208";a="575775519" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by orsmga001.jf.intel.com with ESMTP; 04 Dec 2009 13:24:41 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx604.amr.corp.intel.com ([10.250.113.17]) with mapi; Fri, 4 Dec 2009 13:24:56 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 13:24:54 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1J7DU3EWoIXfRRou5OPs0BUQK5wAADtxw Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> In-Reply-To: <4B197D0E.1020400@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:24:57 -0000 >This thread has a fixed tid of 100000. This is ok. Well, I don't see anything obvious. You will probably need to step through = the calls to AcpiExAcquireMutex and AcpiExReleaseMutex, or at least add som= e printfs to monitor the value of WalkState->Thread->AcquiredMutexList. Another question, however: is the global lock involved in any way? >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Friday, December 04, 2009 1:20 PM >To: Moore, Robert >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: Re: panic in AcpiExReleaseMutex > >on 04/12/2009 22:59 Moore, Robert said the following: >> It would appear that a GPE is taken, for the EC device, thus invoking >> EcGpeQueryHandler. In what context is _Q20 or _Q09 executed? > >It's invoked in "polling mode" at that stage. Interrupts are not enabled >yet at >that point. Let me quote my original report: >[quote] >_REG method seems to access some registers in EC address space (with >\_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access triggers a call to >EcSpaceHandler. Now, we have a code in EcSpaceHandler that makes a direct >call >to EcGpeQueryHandler during a cold boot phase if SCI bit is set in CSR >register. >EcGpeQueryHandler performs an EC query and executes _Qxx method if need. >[/quote] > >So, everything happens in the same thread with the same context and stack. > >> This might be an important question: What is the thread_id of this >initial >> thread? > >This thread has a fixed tid of 100000. > >>> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua] >>> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc: >>> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in >AcpiExReleaseMutex >>> >>> on 04/12/2009 20:45 Moore, Robert said the following: >>>> Yes, you are correct. I did not have the code in front of me at the >time. >>>> >>>> >>>> >>>> >>>> When AcpiExReleaseMutex is called, apparently the mutex is in fact >held, >>>> otherwise the function would have aborted immediately. >>>> >>>> When the mutex is held, the Thread->AcquiredMutexList is expected to >hold >>>> >>>> >>>> >>> (at >>>> the minimum) the mutex object being released. Something is very wrong >if >>> this >>>> list is NULL when releasing the mutex. >>>> >>>> Just to make sure: All of this is happening in the same thread? >>> Yes, this happens when there is only the initial thread running on BSP, >no >>> other threads are started yet. >>> >>> >>> -- Andriy Gapon > > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:39:07 2009 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 0534A1065670 for ; Fri, 4 Dec 2009 21:39:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 362C58FC12 for ; Fri, 4 Dec 2009 21:39:05 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA24165; Fri, 04 Dec 2009 23:38:58 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NGfrd-000JsA-JC; Fri, 04 Dec 2009 23:38:57 +0200 Message-ID: <4B198142.2040407@icyb.net.ua> Date: Fri, 04 Dec 2009 23:38:10 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: Re: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:39:07 -0000 on 04/12/2009 23:24 Moore, Robert said the following: >> This thread has a fixed tid of 100000. > > This is ok. > > Well, I don't see anything obvious. You will probably need to step through > the calls to AcpiExAcquireMutex and AcpiExReleaseMutex, or at least add some > printfs to monitor the value of WalkState->Thread->AcquiredMutexList. I see. > Another question, however: is the global lock involved in any way? Yes. EC querying is performed under global lock. That is, it gets locked and unlocked in EcGpeQueryHandler function before _Qxx evaluation. I am actually curious why you asked this question. Thank you! >> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua] >> Sent: Friday, December 04, 2009 1:20 PM To: Moore, Robert Cc: >> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in AcpiExReleaseMutex >> >> on 04/12/2009 22:59 Moore, Robert said the following: >>> It would appear that a GPE is taken, for the EC device, thus invoking >>> EcGpeQueryHandler. In what context is _Q20 or _Q09 executed? >> It's invoked in "polling mode" at that stage. Interrupts are not enabled >> yet at that point. Let me quote my original report: [quote] _REG method >> seems to access some registers in EC address space (with >> \_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access triggers a call to >> EcSpaceHandler. Now, we have a code in EcSpaceHandler that makes a direct >> call to EcGpeQueryHandler during a cold boot phase if SCI bit is set in CSR >> register. EcGpeQueryHandler performs an EC query and executes _Qxx method >> if need. [/quote] >> >> So, everything happens in the same thread with the same context and stack. >> >>> This might be an important question: What is the thread_id of this >> initial >>> thread? >> This thread has a fixed tid of 100000. >> >>>> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua] >>>> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc: >>>> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in >> AcpiExReleaseMutex >>>> on 04/12/2009 20:45 Moore, Robert said the following: >>>>> Yes, you are correct. I did not have the code in front of me at the >> time. >>>>> >>>>> >>>>> >>>>> When AcpiExReleaseMutex is called, apparently the mutex is in fact >> held, >>>>> otherwise the function would have aborted immediately. >>>>> >>>>> When the mutex is held, the Thread->AcquiredMutexList is expected to >> hold >>>>> >>>>> >>>> (at >>>>> the minimum) the mutex object being released. Something is very wrong >>>>> >> if >>>> this >>>>> list is NULL when releasing the mutex. >>>>> >>>>> Just to make sure: All of this is happening in the same thread? >>>> Yes, this happens when there is only the initial thread running on BSP, >>>> >> no >>>> other threads are started yet. >>>> >>>> >>>> -- Andriy Gapon >> >> -- Andriy Gapon -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:43:21 2009 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 D0271106568B for ; Fri, 4 Dec 2009 21:43:21 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id A33B18FC1A for ; Fri, 4 Dec 2009 21:43:21 +0000 (UTC) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 04 Dec 2009 13:43:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,316,1257148800"; d="scan'208";a="219000448" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by azsmga001.ch.intel.com with ESMTP; 04 Dec 2009 13:43:21 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Fri, 4 Dec 2009 13:43:14 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 13:43:13 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1KjJBI+ErTVPaR9CRE148MXJIWAAACNAw Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2C55@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> <4B198142.2040407@icyb.net.ua> In-Reply-To: <4B198142.2040407@icyb.net.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:43:21 -0000 >Yes. EC querying is performed under global lock. That is, it gets locked >and >unlocked in EcGpeQueryHandler function before _Qxx evaluation. >I am actually curious why you asked this question. Global lock has it's own internal mutex. /* Release the global lock */ Status =3D AcpiExReleaseMutexObject (AcpiGbl_GlobalLockMutex); Do you know if the failure in ReleaseMutex is during a release of the MUT1 = mutex, or could it possibly be the global lock? =20 >-----Original Message----- >From: Andriy Gapon [mailto:avg@icyb.net.ua] >Sent: Friday, December 04, 2009 1:38 PM >To: Moore, Robert >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: Re: panic in AcpiExReleaseMutex > >on 04/12/2009 23:24 Moore, Robert said the following: >>> This thread has a fixed tid of 100000. >> >> This is ok. >> >> Well, I don't see anything obvious. You will probably need to step >through >> the calls to AcpiExAcquireMutex and AcpiExReleaseMutex, or at least add >some >> printfs to monitor the value of WalkState->Thread->AcquiredMutexList. > >I see. > >> Another question, however: is the global lock involved in any way? > >Yes. EC querying is performed under global lock. That is, it gets locked >and >unlocked in EcGpeQueryHandler function before _Qxx evaluation. >I am actually curious why you asked this question. > >Thank you! > >>> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua] >>> Sent: Friday, December 04, 2009 1:20 PM To: Moore, Robert Cc: >>> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in >AcpiExReleaseMutex >>> >>> on 04/12/2009 22:59 Moore, Robert said the following: >>>> It would appear that a GPE is taken, for the EC device, thus invoking >>>> EcGpeQueryHandler. In what context is _Q20 or _Q09 executed? >>> It's invoked in "polling mode" at that stage. Interrupts are not >enabled >>> yet at that point. Let me quote my original report: [quote] _REG metho= d >>> seems to access some registers in EC address space (with >>> \_SB.PCI0.LPC0.EC0.MUT1 mutex locked). That access triggers a call to >>> EcSpaceHandler. Now, we have a code in EcSpaceHandler that makes a >direct >>> call to EcGpeQueryHandler during a cold boot phase if SCI bit is set in >CSR >>> register. EcGpeQueryHandler performs an EC query and executes _Qxx >method >>> if need. [/quote] >>> >>> So, everything happens in the same thread with the same context and >stack. >>> >>>> This might be an important question: What is the thread_id of this >>> initial >>>> thread? >>> This thread has a fixed tid of 100000. >>> >>>>> -----Original Message----- From: Andriy Gapon [mailto:avg@icyb.net.ua= ] >>>>> Sent: Friday, December 04, 2009 12:50 PM To: Moore, Robert Cc: >>>>> freebsd-acpi@freebsd.org; Tarick Subject: Re: panic in >>> AcpiExReleaseMutex >>>>> on 04/12/2009 20:45 Moore, Robert said the following: >>>>>> Yes, you are correct. I did not have the code in front of me at the >>> time. >>>>>> >>>>>> >>>>>> >>>>>> When AcpiExReleaseMutex is called, apparently the mutex is in fact >>> held, >>>>>> otherwise the function would have aborted immediately. >>>>>> >>>>>> When the mutex is held, the Thread->AcquiredMutexList is expected to >>> hold >>>>>> >>>>>> >>>>> (at >>>>>> the minimum) the mutex object being released. Something is very wron= g >>>>>> >>> if >>>>> this >>>>>> list is NULL when releasing the mutex. >>>>>> >>>>>> Just to make sure: All of this is happening in the same thread? >>>>> Yes, this happens when there is only the initial thread running on >BSP, >>>>> >>> no >>>>> other threads are started yet. >>>>> >>>>> >>>>> -- Andriy Gapon >>> >>> -- Andriy Gapon > > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:46:20 2009 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 F3E061065676 for ; Fri, 4 Dec 2009 21:46:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6828FC08 for ; Fri, 4 Dec 2009 21:46:17 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA24237; Fri, 04 Dec 2009 23:46:13 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NGfye-000Jst-V4; Fri, 04 Dec 2009 23:46:12 +0200 Message-ID: <4B1982F5.9020805@freebsd.org> Date: Fri, 04 Dec 2009 23:45:25 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: "Moore, Robert" References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> <4B198142.2040407@icyb.net.ua> In-Reply-To: <4B198142.2040407@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: Re: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:46:20 -0000 on 04/12/2009 23:38 Andriy Gapon said the following: > on 04/12/2009 23:24 Moore, Robert said the following: >> Another question, however: is the global lock involved in any way? > > Yes. EC querying is performed under global lock. That is, it gets locked and > unlocked in EcGpeQueryHandler function before _Qxx evaluation. > I am actually curious why you asked this question. Hmm, I lied, this is done only if _GLK successfully evaluates to non-zero value, which is not the case. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 4 21:52:12 2009 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 9336B1065670 for ; Fri, 4 Dec 2009 21:52:12 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8E68FC08 for ; Fri, 4 Dec 2009 21:52:12 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 04 Dec 2009 13:47:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.47,344,1257148800"; d="scan'208";a="752954825" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga001.fm.intel.com with ESMTP; 04 Dec 2009 13:52:10 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx604.amr.corp.intel.com ([10.250.113.17]) with mapi; Fri, 4 Dec 2009 13:52:11 -0800 From: "Moore, Robert" To: Andriy Gapon Date: Fri, 4 Dec 2009 13:52:10 -0800 Thread-Topic: panic in AcpiExReleaseMutex Thread-Index: Acp1KzVggFi0P+poSsuEBOB7lPUBgwAAE9KA Message-ID: <4911F71203A09E4D9981D27F9D8308583E8F2C6E@orsmsx503.amr.corp.intel.com> References: <4B178387.4050601@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F26CF@orsmsx503.amr.corp.intel.com> <4B189CD6.30906@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2A1F@orsmsx503.amr.corp.intel.com> <4B1975EE.5070803@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2BA9@orsmsx503.amr.corp.intel.com> <4B197D0E.1020400@icyb.net.ua> <4911F71203A09E4D9981D27F9D8308583E8F2C06@orsmsx503.amr.corp.intel.com> <4B198142.2040407@icyb.net.ua> <4B1982F5.9020805@freebsd.org> In-Reply-To: <4B1982F5.9020805@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-acpi@freebsd.org" , Tarick Subject: RE: panic in AcpiExReleaseMutex 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: Fri, 04 Dec 2009 21:52:12 -0000 Then I think you are stuck with figuring out why AcquiredMutexList is NULL. AcquiredMutexList is set in AcpiExLinkMutex, clearing in AcpiExUnlinkMutex. In AcpiExAcquireMutex, AcpiExLinkMutex is called after the mutex is success= fully acquired, and only on the first acquisition. In AcpiExReleaseMutexObject, AcpiExUnLinkMutex is called, but only if the M= utex OwnerThread ID is non-zero. >-----Original Message----- >From: Andriy Gapon [mailto:avg@freebsd.org] >Sent: Friday, December 04, 2009 1:45 PM >To: Moore, Robert >Cc: freebsd-acpi@freebsd.org; Tarick >Subject: Re: panic in AcpiExReleaseMutex > >on 04/12/2009 23:38 Andriy Gapon said the following: >> on 04/12/2009 23:24 Moore, Robert said the following: >>> Another question, however: is the global lock involved in any way? >> >> Yes. EC querying is performed under global lock. That is, it gets >locked and >> unlocked in EcGpeQueryHandler function before _Qxx evaluation. >> I am actually curious why you asked this question. > >Hmm, I lied, this is done only if _GLK successfully evaluates to non-zero >value, >which is not the case. > >-- >Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 5 05:05:51 2009 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 490371065679 for ; Sat, 5 Dec 2009 05:05:51 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf09.insightbb.com (mxsf09.insightbb.com [74.128.0.79]) by mx1.freebsd.org (Postfix) with ESMTP id 1900D8FC12 for ; Sat, 5 Dec 2009 05:05:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.47,346,1257138000"; d="scan'208";a="214873411" Received: from unknown (HELO asav03.insightbb.com) ([172.31.249.123]) by mxsf09.insightbb.com with ESMTP; 04 Dec 2009 23:37:10 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgGADtyGUvQLicL/2dsb2JhbACBTI8BAcU9hDMEgWc X-IronPort-AV: E=Sophos;i="4.47,346,1257138000"; d="scan'208";a="116151110" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout03.insightbb.com with ESMTP; 04 Dec 2009 23:37:10 -0500 To: freebsd-acpi@freebsd.org From: Steven Friedrich Date: Fri, 4 Dec 2009 23:37:04 -0500 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912042337.04403.freebsd@insightbb.com> Subject: ACPI temperature 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, 05 Dec 2009 05:05:51 -0000 I sent this to questions last Sunday, but only one person responded. He's running FreeBSD 8 and I think his system is reporting bogus temps too. I think there might be a missing scaling factor. I'm a hardware guy, but I don't currently have temperature measuring equipment and I would want to do it on one of my towers (which are currently in storage), not my laptop anyway. I booted my HP Pavilion zd8215us and I immediately invoked chkCPUTemperature. The first temp reported was 52C, which is 125.6F. This leads me to believe that acpi has an anomaly regarding temperature measurement. The ambient temp was 71F (21.6C). The machine had been off for over eight hours. Here's chkCPUTemperature: #!/bin/sh # $Id:$ # # CPU Temperature Information from ACPI POLLING_RATE=`sysctl hw.acpi.thermal.polling_rate|awk '{print $2}'` while [ 1 ] do sysctl hw.acpi.thermal.tz0.temperature sleep $POLLING_RATE done uname -a FreeBSD laptop2.StevenFriedrich.org 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #1: Sat Oct 3 18:47:43 EDT 2009 root@laptop2.StevenFriedrich.org:/usr/obj/usr/src/sys/LAPTOP i386 From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 5 05:24:40 2009 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 A162A106568B for ; Sat, 5 Dec 2009 05:24:40 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 88AA98FC16 for ; Sat, 5 Dec 2009 05:24:40 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id nB55OZCg006255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2009 21:24:38 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 76C4B1CC0B; Fri, 4 Dec 2009 21:24:34 -0800 (PST) To: Steven Friedrich In-reply-to: Your message of "Fri, 04 Dec 2009 23:37:04 EST." <200912042337.04403.freebsd@insightbb.com> Date: Fri, 04 Dec 2009 21:24:34 -0800 From: "Kevin Oberman" Message-Id: <20091205052434.76C4B1CC0B@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-12-05_01:2009-11-30, 2009-12-05, 2009-12-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0912040344 Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI temperature 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, 05 Dec 2009 05:24:40 -0000 > From: Steven Friedrich > Date: Fri, 4 Dec 2009 23:37:04 -0500 > Sender: owner-freebsd-acpi@freebsd.org > > I sent this to questions last Sunday, but only one person responded. He's > running FreeBSD 8 and I think his system is reporting bogus temps too. > I think there might be a missing scaling factor. I'm a hardware guy, but I > don't currently have temperature measuring equipment and I would want to do it > on one of my towers (which are currently in storage), not my laptop anyway. > > I booted my HP Pavilion zd8215us and I immediately invoked chkCPUTemperature. > The first temp reported was 52C, which is 125.6F. This leads me to believe > that acpi has an anomaly regarding temperature measurement. The ambient temp > was 71F (21.6C). The machine had been off for over eight hours. > > Here's chkCPUTemperature: > > #!/bin/sh > # $Id:$ > # > > # CPU Temperature Information from ACPI > POLLING_RATE=`sysctl hw.acpi.thermal.polling_rate|awk '{print $2}'` > while [ 1 ] > do > sysctl hw.acpi.thermal.tz0.temperature > sleep $POLLING_RATE > done > > uname -a > FreeBSD laptop2.StevenFriedrich.org 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #1: Why do you not believe the report? The temperature reported is usually measured on the die, not the package. (You couldn't measure it externally, if you wanted to.) Due to the VERY low thermal mass of the die, it heats up very quickly. Also, the maximum die temperature for most modern CPUs is 90C or higher, so 52C is not unusual. The reading of the temperature is pretty trivial, although the the units (degrees K) does require a the substraction of a constant. I really suspect that the die IS at 52C by the time the system has been running for even a minute. -- 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 From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 5 17:42:50 2009 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 AA7DD106566C for ; Sat, 5 Dec 2009 17:42:50 +0000 (UTC) (envelope-from freebsd@insightbb.com) Received: from mxsf00.insightbb.com (mxsf00.insightbb.com [74.128.0.70]) by mx1.freebsd.org (Postfix) with ESMTP id 764A78FC19 for ; Sat, 5 Dec 2009 17:42:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.47,347,1257138000"; d="scan'208";a="721212342" Received: from unknown (HELO asav02.insightbb.com) ([172.31.249.123]) by mxsf00.insightbb.com with ESMTP; 05 Dec 2009 12:42:49 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAK4qGkvQLicL/2dsb2JhbACBTNNLgjoDgXYEgWeLYg X-IronPort-AV: E=Sophos;i="4.47,347,1257138000"; d="scan'208";a="339247278" Received: from 208-46-39-11.dia.static.qwest.net (HELO laptop2.stevenfriedrich.org) ([208.46.39.11]) by asavout02.manage.insightbb.com with ESMTP; 05 Dec 2009 12:42:48 -0500 From: Steven Friedrich To: Kevin Oberman Date: Sat, 5 Dec 2009 12:42:42 -0500 User-Agent: KMail/1.12.4 (FreeBSD/7.2-RELEASE-p5; KDE/4.3.4; i386; ; ) References: <20091205052434.76C4B1CC0B@ptavv.es.net> In-Reply-To: <20091205052434.76C4B1CC0B@ptavv.es.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912051242.42894.freebsd@insightbb.com> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI temperature 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, 05 Dec 2009 17:42:50 -0000 On Saturday 05 December 2009 12:24:34 am you wrote: > > From: Steven Friedrich > > Date: Fri, 4 Dec 2009 23:37:04 -0500 > > Sender: owner-freebsd-acpi@freebsd.org > > > > I sent this to questions last Sunday, but only one person responded. He's > > running FreeBSD 8 and I think his system is reporting bogus temps too. > > I think there might be a missing scaling factor. I'm a hardware guy, but > > I don't currently have temperature measuring equipment and I would want > > to do it on one of my towers (which are currently in storage), not my > > laptop anyway. > > > > I booted my HP Pavilion zd8215us and I immediately invoked > > chkCPUTemperature. The first temp reported was 52C, which is 125.6F. This > > leads me to believe that acpi has an anomaly regarding temperature > > measurement. The ambient temp was 71F (21.6C). The machine had been off > > for over eight hours. > > > > Here's chkCPUTemperature: > > > > #!/bin/sh > > # $Id:$ > > # > > > > # CPU Temperature Information from ACPI > > POLLING_RATE=`sysctl hw.acpi.thermal.polling_rate|awk '{print $2}'` > > while [ 1 ] > > do > > sysctl hw.acpi.thermal.tz0.temperature > > sleep $POLLING_RATE > > done > > > > uname -a > > FreeBSD laptop2.StevenFriedrich.org 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 > > #1: > > Why do you not believe the report? The temperature reported is usually > measured on the die, not the package. (You couldn't measure it externally, > if you wanted to.) Due to the VERY low thermal mass of the die, it heats > up very quickly. > I've been running FreeBSD on this laptop since 2005 and only in the past month has it started shutting down when the temp it 81C. So I found the sysctl where it reports the temp and I wrote chkCPUTemperature, a bourne script to check the temp every 10 seconds. I have placed 1/2 inch spacers, ok, bottle caps from 2 litre bottles, under the four corners and it's not shutting down now. I'm an old hardware guy and I understand the die vs package issue, but what's the temp diff between the two? I was hoping to spark some interest in this issue with someone who has the ability to verify the actual temp with the reported temp. I was trying to find a linux user that might be seeing something different, possibly indicating that FreeBSD's ACPI port has a bug not in the linux code. > Also, the maximum die temperature for most modern CPUs is 90C or higher, > so 52C is not unusual. The 52C was the temp right after boot. It runs around 72C, but without the bottle cap spacers it will get to 81C during a make update or port build. > > The reading of the temperature is pretty trivial, although the the units > (degrees K) does require a the substraction of a constant. I really > suspect that the die IS at 52C by the time the system has been running > for even a minute. >