From owner-freebsd-stable@FreeBSD.ORG Fri Oct 30 16:54:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F1931065696 for ; Fri, 30 Oct 2009 16:54:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 020A88FC0C for ; Fri, 30 Oct 2009 16:54:50 +0000 (UTC) Received: by qyk6 with SMTP id 6so1709909qyk.3 for ; Fri, 30 Oct 2009 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Ztn1vSjnK8pCE1TWmRnfZPxwkQMbwoWDdb0ORv6FquM=; b=sA123DKUUR4qL5vmWsBF7V4NqlLmSvjW0x6kiEOZzu7d2qgxMv6ejzwLbb4n3rnl7h rfPRKbh5PuaACHhgpxDW6Yiw3G2OR+Fme6rs3dOgTSy5TytrtvhLCh42AtFA1XsY/W9O m9gOKuzy2yTl2NhssgcZgUVDgTpX5wW0vuMsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ihK2/9xXY6SqOoROqnSOUk3WKKchujhLDeItKcgw3aMgubVTgDgYCfTWf8hUWPGcA+ JqkBXu8kxCGEseEOTGWUioo2x1t/OW0ep/dbPLNAhSAr88deojN7nEKzmmTpmsiXLWcs 9lFYJRGGEQvZ1TBhSegq9g9pbiUO4rl9I7a18= Received: by 10.224.101.206 with SMTP id d14mr1109899qao.238.1256921690124; Fri, 30 Oct 2009 09:54:50 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm2219084qyk.8.2009.10.30.09.54.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Oct 2009 09:54:48 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 30 Oct 2009 09:54:51 -0700 From: Pyun YongHyeon Date: Fri, 30 Oct 2009 09:54:51 -0700 To: Norbert Papke Message-ID: <20091030165451.GA17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910292156.19845.npapke@acm.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: 7.2 Stable Crash - possibly related to if_re X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 16:54:51 -0000 On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > This occurred shortly after "scp"ing from a VirtualBox VM to the host. The > file transfer got stuck. The "re" interface stopped working. Shortly > afterwards, the host crashed. The "re" interface was used by the host, the > guest was using a different NIC in bridged mode. > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > 18:36:57 PDT 2009 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 It looks like a NULL pointer dereference, possibly mbuf related one. > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff80d476ee > stack pointer = 0x10:0xffffff8000078ae0 > frame pointer = 0x10:0xffffff8000078b40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 18 (swi5: +) > Physical memory: 8177 MB > > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xffffffff801d5faf in db_fncall (dummy1=Variable "dummy1" is not > available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 > #2 0xffffffff801d64b9 in db_command (last_cmdp=0xffffffff80b46ac8, > cmd_table=0x0, dopager=1) > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 > #3 0xffffffff801d66bb in db_command_loop () > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 > #4 0xffffffff801d8197 in db_trap (type=Variable "type" is not available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 > #5 0xffffffff8054ab45 in kdb_trap (type=12, code=0, tf=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 > #6 0xffffffff807fcdd3 in trap_fatal (frame=0xffffff8000078a30, > eva=Variable "eva" is not available. > ) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 > #7 0xffffffff807fd185 in trap_pfault (frame=0xffffff8000078a30, usermode=0) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 > #8 0xffffffff807fd9bd in trap (frame=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 > #9 0xffffffff807e710e in calltrap () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko Hmm, I think there is a missing information here. Not sure where it dereferenced a NULL pointer in re_rxeof(). Because that this is the first report for NULL pointer dereference in Rx handler I need more information how to reproduce it with minimal configuration. Can you also reproduce the issues without virtual box? By chance, did you stop the re0 interface with ifconfig when you noticed the file transfer got stuck? > #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. > ) > > at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 > #12 0xffffffff80554d46 in taskqueue_run (queue=0xffffff000192f300) > at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 > #13 0xffffffff804fbc1d in ithread_loop (arg=0xffffff00019433a0) > at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 > #14 0xffffffff804f83c4 in fork_exit (callout=0xffffffff804fbaa5 > , arg=0xffffff00019433a0, > frame=0xffffff8000078c80) > at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 > #15 0xffffffff807e74ee in fork_trampoline () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 >