From owner-acpi-jp@jp.FreeBSD.org Thu Oct 10 23:24:19 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g9AEOJj63305;
	Thu, 10 Oct 2002 23:24:19 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mail.speakeasy.net (mail14.speakeasy.net [216.254.0.214])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g9AEOI363298
	for <acpi-jp@jp.FreeBSD.org>; Thu, 10 Oct 2002 23:24:18 +0900 (JST)
	(envelope-from jhb@FreeBSD.org)
Received: (qmail 23911 invoked from network); 10 Oct 2002 14:24:15 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
          (envelope-sender <jhb@FreeBSD.org>)
          by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
          for <current@FreeBSD.ORG>; 10 Oct 2002 14:24:15 -0000
Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1])
	by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g9AEODn5014729;
	Thu, 10 Oct 2002 10:24:14 -0400 (EDT)
	(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021010102417.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <200210100357.g9A3v56V009763@bunrab.catwhisker.org>
From: John Baldwin <jhb@freebsd.org>
To: David Wolfskill <david@catwhisker.org>
Cc: acpi-jp@jp.FreeBSD.org, current@freebsd.org
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Thu, 10 Oct 2002 10:24:17 -0400
X-Sequence: acpi-jp 1893
Subject: [acpi-jp 1893] RE: panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: jhb@FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+021008


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/
