Date: Sun, 05 Sep 2004 22:55:54 +0400 From: Maxim Maximov <mcsi@mcsi.pp.ru> To: John Baldwin <jhb@freebsd.org> Cc: Nate Lawson <nate@root.org> Subject: Re: panic on shutdown Message-ID: <413B613A.5020600@mcsi.pp.ru> In-Reply-To: <4138D10E.4060809@mcsi.pp.ru> References: <4137EA5C.30606@mcsi.pp.ru> <4138A524.8080107@root.org> <4138A806.9020105@mcsi.pp.ru> <200409031341.47074.jhb@FreeBSD.org> <4138D10E.4060809@mcsi.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Maximov wrote:
> John Baldwin wrote:
>
>> On Friday 03 September 2004 01:21 pm, Maxim Maximov wrote:
>>
>>> Nate Lawson wrote:
>>>
>>>> John Baldwin wrote:
>>>>
>>>>> On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> I just got this panic on shutdown using Power button, hand
>>>>>> transcribed:
>>>>>>
>>>>>> Syncing disks: <numbers>
>>>>>> No buffers busy after final sync
>>>>>> Uptime: 21m53s
>>>>>> Powering system off using ACPI
>>>>>>
>>>>>> panic: lock (sleep mutex) Giant not locked @
>>>>>> /usr/src/sys/kern/kern_timeout.c:279
>>>>>>
>>>>>> cpuid = 0
>>>>>> KDB: enter: panic
>>>>>> ACPI power-off failed - timeout
>>>>>>
>>>>>> Rebooting...
>>>>>> cpu_reset: called on cpu#1
>>>>>> cpu_reset: Stopping other CPUs
>>>>>>
>>>>>> Here it hung until I pressed Power button again. Then it shut down.
>>>>>
>>>>>
>>>>> Looks like the timeout/callout routine dropped Giant more than it
>>>>> acquired it.
>>>>
>>>>
>>>> I don't see how this could be triggered by ACPI. If you reboot the
>>>> system with ACPI disabled (or enabled), do you also get this message?
>>>
>>>
>>> My system can't boot with ACPI disabled.
>>>
>>> Also I want to mention that this panic is rare. I've seen it about 10
>>> times in 2-3 months of everyday rebooting.
>>>
>>> And by the way, the command issued to shut the system down was 'halt -p'
>>
>>
>>
>> I would hack the timeout code to add some printf's before the
>> mtx_unlock(&Giant) to dump the function pointer and argument if
>> !tmtx_owned(&Giant) and then use gdb to figure out what the callout
>> function was. I.e. something like:
>>
>> if (not mpsafe) {
>> if (!mtx_owned(&Giant))
>> printf("func = %p, arg = %p\n", c_func, c_arg)
>> mtx_unlock(&Giant);
>> }
>>
>
> Thanks, I recompiled kernel with this code. I'll let you know if this
> yields anything..
Just got one after 'halt -p'!
func = 0xc07b3298, arg = 0xc09656e0
mcsi@ultra(ttyp1) [99] ~# gdb
--symbols=/usr/obj/usr/src/sys/ULTRA/kernel.debug --readnow
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 "i386-marcel-freebsd"...
(gdb) x 0xc07b3298
0xc07b3298 <scrn_timer>: Cannot access memory at address 0xc07b3298
(gdb) x 0xc09656e0
0xc09656e0 <main_softc>: Cannot access memory at address 0xc09656e0
(gdb) quit
--
Maxim Maximov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?413B613A.5020600>