From owner-freebsd-stable@FreeBSD.ORG Mon Jan 14 21:20:30 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4E84AFE1 for ; Mon, 14 Jan 2013 21:20:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2D3B0A for ; Mon, 14 Jan 2013 21:20:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA10683; Mon, 14 Jan 2013 23:20:23 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TurSB-000LME-Kj; Mon, 14 Jan 2013 23:20:23 +0200 Message-ID: <50F47695.8050205@FreeBSD.org> Date: Mon, 14 Jan 2013 23:20:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Po-Li Soong , Konstantin Belousov Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> <20130113175527.GB2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> In-Reply-To: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 21:20:30 -0000 on 14/01/2013 22:04 Po-Li Soong said the following: > First of all, I agree with you that it would be very strange to have crashed > at vm_page_free_toq+0x45, by which point m (in the register rbx. See below > for the assembly listing.) has been dereferenced a few times. However, there > is a discrepancy between the KDB backtrace and the annotated one just few > lines below. In the annotated backtrace, it appears that it is the > vm_page_remove that runs into the panic at 0xffffffff80b50597, which is at > line 975. That source line looks a lot more probable for causing a panic than > that in vm_page_free_toq. Yes, it looks like you do not have DDB in your kernel and thus the panic time backtrace was produced by stack(9), which is not aware of trap frames and such. So that stack trace is not correct (accidentally it misses just one frame just before the trap). On the other hand, the stack trace from kgdb seems to be on spot. -- Andriy Gapon