From owner-freebsd-current@FreeBSD.ORG Wed Jun 10 23:13:05 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 73588106566B; Wed, 10 Jun 2009 23:13:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 10 Jun 2009 19:12:42 -0400 User-Agent: KMail/1.6.2 References: <3a142e750906090625r6586f15fn234e539dbbd57e73@mail.gmail.com> <3c1674c90906101601q68285c4ehad44dadc0d1a28e5@mail.gmail.com> In-Reply-To: <3c1674c90906101601q68285c4ehad44dadc0d1a28e5@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200906101912.54960.jkim@FreeBSD.org> Cc: Kip Macy Subject: Re: panic: blockable sleep lock (sleep mutex) 32 @ /usr/src/sys/vm/uma_core.c:1990 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 23:13:05 -0000 On Wednesday 10 June 2009 07:01 pm, Kip Macy wrote: > A M_WAITOK allocation while holding a lock will do this. No, it does not because it may be used in interrupt handler context with a spin lock held (e.g., GPE handler). In fact, I already committed a workaround: http://svn.freebsd.org/changeset/base/193963 Please let me know if it does not work for you. Thanks, Jung-uk Kim > -Kip > > On Tue, Jun 9, 2009 at 6:25 AM, Paul B. Mahol wrote: > > #0  doadump () at pcpu.h:246 > > #1  0xc04acb4e in boot (howto=260) at > > /usr/src/sys/kern/kern_shutdown.c:419 #2  0xc04ace22 in panic > > (fmt=Variable "fmt" is not available.) at > > /usr/src/sys/kern/kern_shutdown.c:575 > > #3  0xc04ecba0 in witness_checkorder (lock=0xc1094788, flags=9, > > file=0xc06429a7 "/usr/src/sys/vm/uma_core.c", line=1990, > > interlock=0x0) at /usr/src/sys/kern/subr_witness.c:1063 > > #4  0xc049ded4 in _mtx_lock_flags (m=0xc1094788, opts=0, > > file=0xc06429a7 "/usr/src/sys/vm/uma_core.c", line=1990) at > > /usr/src/sys/kern/kern_mutex.c:200 > > #5  0xc05b3eb3 in uma_zalloc_arg (zone=0xc108c700, udata=0x0, > > flags=1) at /usr/src/sys/vm/uma_core.c:1990 > > #6  0xc049a564 in malloc (size=dwarf2_read_address: Corrupted > > DWARF expression.) at uma.h:305 > > #7  0xc09cc51f in AcpiOsExecute (Type=OSL_GPE_HANDLER, > > Function=0xc099c100 , > > Context=0xc3d49618) at > > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSchedul > >e.c:103 #8  0xc099c448 in AcpiEvGpeDispatch > > (GpeEventInfo=0xc3d49618, GpeNumber=2) at > > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/events > >/evgpe.c:863 #9  0xc099c66b in AcpiEvGpeDetect > > (GpeXruptList=0xc3d4b400) at > > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/events > >/evgpe.c:586 #10 0xc099e699 in AcpiEvSciXruptHandler > > (Context=0xc3d4b400) at > > /usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica/events > >/evsci.c:172 #11 0xc0487955 in intr_event_execute_handlers > > (p=0xc3d0aa90, ie=0xc3d09300) at > > /usr/src/sys/kern/kern_intr.c:1146 > > #12 0xc04885bf in ithread_loop (arg=0xc3d4b3f0) at > > /usr/src/sys/kern/kern_intr.c:1159 > > #13 0xc0485728 in fork_exit (callout=0xc0488520 , > > arg=0xc3d4b3f0, frame=0xc39e7d38) at > > /usr/src/sys/kern/kern_fork.c:828 #14 0xc05ea6e0 in > > fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > > > > Some recent change in acpi is causing this. > > > > -- > > Paul > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org"