Date: Wed, 10 Nov 2004 14:20:09 -0800 From: Nate Lawson <nate@root.org> To: Dmitry Kondratyev <null@bikeman.ru> Cc: freebsd-acpi@freebsd.org Subject: Re: Troubles with ACPI on HP nx5000 laptop Message-ID: <41929419.2060505@root.org> In-Reply-To: <4192733E.3000606@bikeman.ru> References: <128676437.20041011133831@bikeman.ru> <401094078.20041011134529@bikeman.ru> <66751906.20041107194159@bikeman.ru> <418FAA88.3070706@root.org> <4192733E.3000606@bikeman.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41929419.2060505>