From owner-freebsd-stable@FreeBSD.ORG Sun Jan 9 00:58:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE2716A4CE for ; Sun, 9 Jan 2005 00:58:43 +0000 (GMT) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6EC343D2F for ; Sun, 9 Jan 2005 00:58:42 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j090weKH000651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Jan 2005 11:58:41 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j090wexP047087; Sun, 9 Jan 2005 11:58:40 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j090wd0W047086; Sun, 9 Jan 2005 11:58:39 +1100 (EST) (envelope-from pjeremy) Date: Sun, 9 Jan 2005 11:58:39 +1100 From: Peter Jeremy To: Scott Sewall , freebsd-stable@freebsd.org Message-ID: <20050109005838.GX79646@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C0A1B1.2070409@redlinenetworks.com> User-Agent: Mutt/1.4.2i Subject: Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 00:58:43 -0000 On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: > I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic > occurs seems to happen when I'm running rsync of large directories > possibly in combination with reading or writing to a compact flash > attached to USB. Having just looked into an identical panic, the problem is an interface bug between bus_dmamem_alloc() and contigmalloc(). It's nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x. The relevant part of my backtrace looks like: #15 0xc028aaef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -980715140, tf_ebp = -1070676940, tf_isp = -1070676996, tf_ebx = 0, tf_edx = 6867008, tf_ecx = -1056660992, tf_eax = 7261248, tf_trapno = 12, tf_err = 0, tf_eip = -1072225192, tf_cs = 8, tf_eflags = 66118, tf_esp = -1065633592, tf_ss = 0}) at /home/src/sys/i386/i386/trap.c:466 #16 0xc0172458 in tsleep (ident=0xc58b797c, priority=4, wmesg=0xc02bfd27 "swwrt", timo=0) at /home/src/sys/kern/kern_synch.c:436 #17 0xc021e60f in swap_pager_putpages (object=0xd03c6e04, m=0xc02ec50c, count=1, sync=1, rtvals=0xc02ec4b0) at /home/src/sys/vm/swap_pager.c:1431 #18 0xc021ceaf in default_pager_putpages (object=0xd03c6e04, m=0xc02ec50c, c=1, sync=0, rtvals=0xc02ec4b0) at /home/src/sys/vm/default_pager.c:133 #19 0xc0228ca4 in vm_pageout_flush (mc=0xc02ec50c, count=1, flags=0) at /home/src/sys/vm/vm_pager.h:147 #20 0xc02285c9 in contigmalloc1 (size=36864, type=0xc02f4340, flags=1, low=0, high=4294967295, alignment=1, boundary=0, map=0xc03372ac) at /home/src/sys/vm/vm_page.c:1855 #21 0xc022887f in contigmalloc (size=36864, type=0xc02f4340, flags=1, low=0, high=4294967295, alignment=1, boundary=0) at /home/src/sys/vm/vm_page.c:1980 #22 0xc027bd3b in bus_dmamem_alloc (dmat=0xc176b4c0, vaddr=0xc1231a48, flags=1, mapp=0xc1231a44) at /home/src/sys/i386/i386/busdma_machdep.c:351 #23 0xc0231be2 in usb_block_allocmem (tag=0x0, size=36864, align=1, dmap=0xc17d8d3c) at /home/src/sys/dev/usb/usb_mem.c:186 ... #35 0xc022d4ea in uhci_intr (arg=0xc104f000) at /home/src/sys/dev/usb/uhci.c:1175 #36 0xc02841f2 in cpu_idle () at /home/src/sys/i386/i386/machdep.c:1000 Basically, the USB code is trying to allocate ~36KB RAM within an interrupt handler. usb_block_allocmem() invokes bus_dmamem_alloc() with BUS_DMA_NOWAIT (advising that sleep()ing is not allowed). Since more than one page of memory is requested, bus_dmamem_alloc() uses contigmalloc() to allocate the requested memory. The BUS_DMA_NOWAIT flag is mapped to M_NOWAIT but contigmalloc() does not support M_NOWAIT. Unfortunately, I don't know enough about the VM code to be able to suggest a fix. -- Peter Jeremy