From owner-freebsd-acpi@FreeBSD.ORG Fri May 1 19:08:37 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D122D106566B; Fri, 1 May 2009 19:08:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2E28FC0A; Fri, 1 May 2009 19:08:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 25E8546B38; Fri, 1 May 2009 15:08:37 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id F40908A021; Fri, 1 May 2009 15:08:35 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 1 May 2009 15:01:39 -0400 User-Agent: KMail/1.9.7 References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> In-Reply-To: <49FB2847.406@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905011501.40083.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 01 May 2009 15:08:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org, Alan Amesbury Subject: Re: Garbled output from kgdb? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:08:38 -0000 On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote: > John Baldwin wrote: > > > Drop the '0x8:' from this and it will work better. Also, 'bt' output would be > > good. > > Thanks for the pointer (no pun intended). > > > (kgdb) list *0xffffffff80424561 > 0xffffffff80424561 is in turnstile_wait > (/usr/src/sys/kern/subr_turnstile.c:727). > 722 else > 723 > TAILQ_INSERT_TAIL(&ts->ts_blocked[queue], td, td_lockq); > 724 MPASS(owner == ts->ts_owner); > 725 mtx_unlock_spin(&td_contested_lock); > 726 MPASS(td->td_turnstile != NULL); > 727 LIST_INSERT_HEAD(&ts->ts_free, td->td_turnstile, > ts_hash); > 728 } > 729 thread_lock(td); > 730 thread_lock_set(td, &ts->ts_lock); > 731 td->td_turnstile = NULL; This is odd. > The backtrace looked odd (lots of stuff apparently missing), which is > why I didn't include it before. Here it is with repeated lines > collapsed for brevity: > > > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0x0000000000000000 in ?? () > #2 0xffffffff803ee713 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff803ee9c5 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff8062478e in trap_fatal (frame=0xffffffffac057a40, eva=96) > at /usr/src/sys/amd64/amd64/trap.c:764 > #5 0xffffffff806251c6 in trap (frame=0xffffffffac057a40) at > /usr/src/sys/amd64/amd64/trap.c:290 > #6 0xffffffff8060aafe in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:209 > #7 0xffffffff80424561 in turnstile_wait (ts=0xffffff000105dd20, > owner=Variable "owner" is not available. > ) at /usr/src/sys/kern/subr_turnstile.c:727 > #8 0xffffffff803e0915 in _mtx_lock_sleep (m=0xffffff00011ff600, > tid=18446742974215718624, opts=Variable "opts" is not available. > ) at /usr/src/sys/kern/kern_mutex.c:420 > #9 0xffffffff801ee1e9 in AcpiOsAcquireLock (Handle=0xffffff000105dd20) > at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377 > #10 0xffffffff801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at > /usr/src/sys/contrib/dev/acpica/hwregs.c:444 > #11 0xffffffff801f5f6e in acpi_cpu_idle () at > /usr/src/sys/dev/acpica/acpi_cpu.c:928 > #12 0xffffffff806119a9 in cpu_idle () at > /usr/src/sys/amd64/amd64/machdep.c:581 > #13 0xffffffff8040f0e4 in sched_idletd (dummy=Variable "dummy" is not > available. > ) at /usr/src/sys/kern/sched_ule.c:2676 > #14 0xffffffff803caa30 in fork_exit (callout=0xffffffff8040ee00 > , arg=0x0, frame=0xffffffffac057c80) at > /usr/src/sys/kern/kern_fork.c:804 > #15 0xffffffff8060aece in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:455 The trace actually ends here. There is nothing super bad here but there is a big problem actually in that the idle threads cannot block on a lock, so it is a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks protecting the idle registers need to use spin locks instead. The problem with blocking in the idle thread is that the scheduler assumes (even requires) that the idle thread is _always_ runnable. -- John Baldwin