Date: Mon, 14 Jan 2013 23:20:21 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Po-Li Soong <polis@spectralogic.com>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Stable <freebsd-stable@FreeBSD.org> Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1 Message-ID: <50F47695.8050205@FreeBSD.org> In-Reply-To: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com> References: <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66DDB6@reactor.sldomain.com> <20130109234924.GM2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66E4F3@reactor.sldomain.com> <20130113175527.GB2561@kib.kiev.ua> <0C4D65F6A0FC9E4B95EA114508C7E0FE5F66EF0E@reactor.sldomain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F47695.8050205>