From owner-freebsd-current@FreeBSD.ORG Mon Jul 13 18:53:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61338106568F for ; Mon, 13 Jul 2009 18:53:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8D18FC14 for ; Mon, 13 Jul 2009 18:53:34 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 796F72C2A7E; Mon, 13 Jul 2009 13:30:04 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SB4kmK7nK25J; Mon, 13 Jul 2009 13:29:56 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id A58862C2A8C; Mon, 13 Jul 2009 13:29:56 -0500 (CDT) Message-ID: <4A5B7D24.60100@cs.rice.edu> Date: Mon, 13 Jul 2009 13:29:56 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kip Macy , Alan Cox , current@freebsd.org References: <20090713181650.GB76464@acme.spoerlein.net> In-Reply-To: <20090713181650.GB76464@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: panic: vm_page_free_toq: freeing mapped page 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: Mon, 13 Jul 2009 18:53:34 -0000 Ulrich Spörlein wrote: > On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: > >> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: >> >>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: >>> >>>> Hi, >>>> >>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static >>>> analyzer on a buildworld with something like the following panic: >>>> >>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 >>>> cpuid = 1 >>>> KDB: stack backtrace: >>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>>> panic() at panic+0x182 >>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 >>>> vm_object_terminate() at vm_object_terminate+0xb7 >>>> vm_object_deallocate() at vm_object_deallocate+0x17a >>>> _vm_map_unlock() at _vm_map_unlock+0x70 >>>> vm_map_remove() at vm_map_remove+0x6f >>>> vmspace_free() at vmspace_free+0x56 >>>> vmspace_exec() at vmspace_exec+0x56 >>>> exec_new_vmspace() at exec_new_vmspace+0x133 >>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee >>>> kern_execve() at kern_execve+0x3b2 >>>> execve() at execve+0x3d >>>> syscall() at syscall+0x1af >>>> Xfast_syscall() at Xfast_syscall+0xe1 >>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- >>>> >>> Can you try the following change: >>> >>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 >>> >> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into >> the scan-build run. So no luck there. Next up is a test using the >> GENERIC kernel. >> > > > No improvement with a GENERIC kernel. Next up will be to run this with > clean sysctl, loader.conf, etc. Then I'll try disabling SMP. > > Does the backtrace above point to any specific subsystem? I'm using UFS, > ZFS and GELI on this machine and could try a few combinations... > The interesting thing about the backtrace is that it shows a 32-bit i386 executable being started on a 64-bit amd64 machine. I've seen this backtrace once before, and you'll find it in the PR database. In that case, the problem "went away" after the known-to-be-broken ZERO_COPY_SOCKETS option was removed from the reporter's kernel configuration. However, I don't see that as the culprit here. Alan