Date: Fri, 1 May 2009 15:01:39 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: freebsd-acpi@freebsd.org, Alan Amesbury <amesbury@umn.edu> Subject: Re: Garbled output from kgdb? Message-ID: <200905011501.40083.jhb@freebsd.org> In-Reply-To: <49FB2847.406@umn.edu> References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <sched_idletd>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905011501.40083.jhb>