From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 10 22:20:16 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 214C116A4CE; Wed, 10 Nov 2004 22:20:15 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9594A43D45; Wed, 10 Nov 2004 22:20:15 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iAAMKAFp029474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Nov 2004 14:20:11 -0800 Message-ID: <41929419.2060505@root.org> Date: Wed, 10 Nov 2004 14:20:09 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Kondratyev References: <128676437.20041011133831@bikeman.ru> <401094078.20041011134529@bikeman.ru> <66751906.20041107194159@bikeman.ru> <418FAA88.3070706@root.org> <4192733E.3000606@bikeman.ru> In-Reply-To: <4192733E.3000606@bikeman.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Troubles with ACPI on HP nx5000 laptop X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2004 22:20:16 -0000 Dmitry Kondratyev wrote: > NL> NL> After it has hung, please break to DDB > NL> (ctrl-alt-backspace) and do a ps. Go through doing a "tr" on each > NL> process id that looks interesting, looking for stacks that have > NL> "acpi_tz" functions in them. Email me the process stack info. It's > NL> obvious that you're getting a deadlock in the acpi thermal zone > NL> switching code but we need to figure out how. > > I don't think it's deadlock, because I found only one process > callling acpi_tz funcs. I didn't mean two separate processes deadlock but just a situation where a thread stops without making progress. > > ps > 45 c15b8c5c d4de5000 0 0 0 0000204 [RUNQ] > acpi_thermal > > trace 45 > sched_switch(c155f640,0,1,5e21f7f1,5e141b1) at sched_switch+0x160 > mi_switch(1,0,d3becca8,10) at mi_switch+0x1d9 > sleepq_switch(c07a4694,c155f640,d3becce0,c04e1dcc,c07a4694) at > sleepq_switch+0x167 > sleepq_timedwait(c07a4694,54,c07a46a0,c07a0150,0) at > sleepq_timedwait+0x12 > msleep(c07a4694,c07a46a0,254,c07a0150,3e8) at msleep+0x3bc > acpi_tz_thread(0,d3becd48,68bf09fc,85e800c6, 2c483cd) at > acpi_tz_thread+0x1da > fork_exit(c07902f0,0,d3becd48) at fork_exit+0x80 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd3becd7c, ebp = 0 --- This looks normal. It just means there's no work for the thermal thread to do so it sleeps. I wonder why it's on the RUNQ though? Please recompile your acpi module with options ACPI_DEBUG. Then set this at the loader prompt or in loader.conf: debug.acpi.layer="ACPI_THERMAL" debug.acpi.level="ACPI_LV_OBJECTS ACPI_LV_ALL_EXCEPTIONS" Send me the output after a hang. > Furthermore, after "cont" in ddb, everything worked for a few > seconds. And it always works for a while till hangs again if after > hanging I call ddb and type "cont". Maybe it will "unhang" if I > wait till CPU gets cold. If you have a serial console, a ps on all threads once it hangs would be helpful. -- Nate