Date: Thu, 10 Oct 2002 10:24:17 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: David Wolfskill <david@catwhisker.org> Cc: acpi-jp@jp.FreeBSD.org, current@FreeBSD.ORG Subject: RE: panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/ Message-ID: <XFMail.20021010102417.jhb@FreeBSD.org> In-Reply-To: <200210100357.g9A3v56V009763@bunrab.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Oct-2002 David Wolfskill wrote:
> I'm including acpi-jp@jp.FreeBSD.org because there may well be some
> interaction with the recently-imported acpica-unix-20021002. Please
> be judicious with respect to where replies are directed.
This isn't ACPI related I don't think. You got a stray interrupt and
sched_ithd() tried to call printf(). Unfortunately, cpu_unpend() seems
to be executing while it is still in a critical section, so when printf()
calls into select() it breaks. Probably printf() needs work to be made
more intelligent so it doesn't get into select() in that case but defers
it.
> The panic occurred with -CURRENT CVSupped around 0347 hrs. US/Pacific (7
> hrs. west of GMT, at this time of year). The machine is my laptop, a
> Dell Inspiron 5000e, after I had logged in to xdm, but switched to vty1,
> then used the keyboard chord (Fn+Esc, in this case) to request a suspend
> (to RAM). Although I tried to use "panic" (in the debugger) to get a
> crash dump, that effort was unsuccessful. I do, however, have the
> following (hand-transcribed -- twice!) trace:
>
> panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/sys/kern/sys_generic.c:1191
> Debugger("panic")
> Stoppd at Debugger+0x54: xchgl %ebx, in_Debugger.0
> db> tr
> Debugger(c047a4cd,c0529600,c047d6d9,cdbf57ec,1) at Debugger+0x54
> panic(c047d6d9,c04795bf,c047e00d,c047dfe0,4a7) at panic+0xab
> witness_lock(c04ec5e0,8,c047dfe0,4a7,cdbf5858) at witness_lock+0x97
> _mtx_lock_flags(c04ec5e0,0,c047dfe0,4a7,cdbf5858) at _mtx_lock_flags+0xb1
> Selwakeup(c26cbe04,c26cbe30,73,c26cbe30,cdbf5858) at Selwakeup+0x2f
> ptcwakeup(c26cbe30,1,cdbf58a4,c02e42cb,c26cbe30) at ptcwakeup+0x2e
> ptsstart(c26cbe30,cdbf58bc,c02e5fa4,c26cbe30,c26cbe30) at ptsstart+0x37
> ttstart(c26cbe30,c26cbe307,cdbf59b4,cdbf5858) at ttstart+0x1b
> tputchar(73,c26cbe30,1,c049c473,7d0) at tputchar+0x54
> kvprrintf(c049c472,c02d0310,cdbf59b4,a,cdbf59d4) at kvprrintf+0x8d
> printf(c049c472,b,1,b,296) at printf+0x57
> sched_ithd(b,c02d6631,c052a7c0,0,c047d4f9) at sched_ithd+0x63
> i386_unpend(c052c3f0,c0506d40,15,cdbf5a30,c02ba0a5) at i386_unpend+0xb7
> cpu_unpend(197,cdbf5a3c,c02b9d34,7d0,cdbf5a5c) at cpu_unpend+0x2a
> cpu_critical_exit(7d0,cdbf5a5c,c02aab5d,c0506d40,1) at cpu_critical_exit+0x15
> critical_exit(c0506d40,1,c04795d6,1b2,cdc34000) at critical_exit+0x24
> _mtx_unlock_spin_flags(c0506d40,0,c049b3e,19f,70) at _mtx_unlock_spin_flags+0xbd
> getit(10,c04e7460,c2633090,cdbf5abc,70) at getit+0x62
> DELAY(7d0,c2611500,c2629f00,c2629f00) at DELAY+0x30
> cbb_pcic_power_disable_socket(c262bb00,c2629f00,c25502b0,cdbf5b00) at
> cbb_pcic_power_disable_socket+0x8f
> cbb_power_disable_socket(c262bb00,c2629f00,cdbf5aec,0,0) at cbb_power_disable_socket+0x2f
> cardbus_detach_card(c2629f00,1,cdbf5b38,c02c8076,c2629f00) at cardbus_detach_card+0x9c
> cardbus_suspend(c2629f00,c2623cc0,c2623b00,c2623b00,c2623cc0) at cardbus_suspend+0x19
> bus_generic_suspend(c262bb00,c2623cc0,c2623b00,c2550058,c262bb00) at bus_generic_suspend+0x5b
> cbb_suspend(c262bb00,c2550058,c04a51a8,c2b01c40,0) at cbb_suspend+0x7a
> bus_generic_suspend(c2629500,c2608058,c04a51a8,c2609058,c0f07700) at bus_generic_suspend+0x5b
> bus_generic_suspend(c0f07500,c2607058,c04a51a8,0,0) at bus_generic_suspend+0x5b
> bus_generic_suspend(c2611500,c25e7058,c04a51a8,cdbf5c3a,0) at bus_generic_suspend+0x5b
> bus_generic_suspend(c0f06c80,c25b8058,c04a51a8,cdbf5c10,c2618a40) at bus_generic_suspend+0x5b
> bus_generic_suspend(c0f06f00,c0efa058,c04a51a8,c05293c8,40400000) at bus_generic_suspend+0x5b
> acpi_SetSleepState(c2611480,1,cdbf5c78,c0647562,c2611480) at acpi_SetSleepState+0x106
> acpi_system_eventhandler_sleep(c2611480,1,5da,c2611480c2625e20) at
> acpi_system_eventhandler_sleep+0x1d
> acpi_eventhandler_sleep_button_for_sleep(c2611480,c0656514,c27fd400,c27fd400,cdbf5ca4) at
> acpi_eventhandler_sleep_button_for_sleep+0x62
> acpi_button_notify_pressed_for_sleep(c2625e20,c27fd400,1,cdbf5cd0,c02d3f2c) at
> acpi_button_notify_pressed_for_sleep+0x9a
> AcpiOsExecuteQueue(c27fd400,1,c047d265,c9,c0f06d1c) at AcpiOsExecuteQueue+0x17
> taskqueue_run(c0f06d00,cdbf5d08,c02a1d92,0,0) at taskqueue_run+0x9c
> taskqueue_acpi_run(0,0,c0477f04,215,c260f370) at taskqueue_acpi_run+0x13
> ithread_loop(c0ef7d00,cdbf5d48,c0477c63,34b,efbfff64) at ithread_loop+0x182
> fork_exit(c02a1c10,c0ef7d00,cdbf5d48) at fork_exit+0xa7
> fork_tramploine() at fork_tramploine+0x1a
> --- trap 0x1, eip = 0, esp = 0xcdbf5d7c, ebp = 0
> db> show locks
> exclusive sx acpi_sleep_event r=0 (0xc0f07c88) locked @ /usr/src/sys/dev/acpica/acpi.c:1498
> exclusive sleep mutex Giant r=0 (0xc04e9100) locked @ /usr/src/sys/kern/kern_intr.c:533
> db>
>
>
> And that's all I have.
>
> I'll "clone" the system from slice 3 to slice 2, in order to be
> able to reproduce the symptom, in case that helps. (I run recent -STABLE
> on slice 1, recent -CURRENT on slice 3, and whatever has my attention for
> hacking on slice 2.)
>
> Thanks,
> david
> --
> David H. Wolfskill david@catwhisker.org
> To paraphrase David Hilbert, there can be no conflicts between the
> discipline of systems administration and Microsoft, since they have
> nothing in common.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20021010102417.jhb>