Date: Mon, 16 Jun 2014 11:08:22 -0500 From: Alan Cox <alc@rice.edu> To: Hans Petter Selasky <hps@selasky.org>, Ian Lepore <ian@FreeBSD.org> Cc: "arm@freebsd.org" <arm@FreeBSD.org> Subject: Re: RPI-B VM panic Message-ID: <539F1676.2020406@rice.edu> In-Reply-To: <539E9DD4.4080001@selasky.org> References: <539170AA.2000109@selasky.org> <5396947A.1060601@selasky.org> <5396A0D1.80309@selasky.org> <5396AF63.6040209@selasky.org> <8BA66A45-E08A-475D-A1FA-5047E862681E@rice.edu> <5398B6EA.9030408@selasky.org> <A9433B36-C15C-455E-AB80-3999596936F9@rice.edu> <5398BFD9.60502@selasky.org> <7390A211-C949-4079-B3DA-BF23798B8992@rice.edu> <539942C0.5010706@selasky.org> <5399DF7F.4010501@rice.edu> <5399E349.5050600@selasky.org> <1402594327.20883.216.camel@revolution.hippie.lan> <5399E660.5050207@selasky.org> <5399E901.1080805@selasky.org> <5399FB57.8090102@rice.edu> <539A140F.6020107@selasky.org> <539B2BE8.2090005@rice.edu> <539E9DD4.4080001@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/16/2014 02:33, Hans Petter Selasky wrote: >> >> This output shows that according to the object's list of pages there is >> already a page allocated at pindex 4 (or "off=0x4" above). If this list >> is correct, and not itself corrupted, then we shouldn't be making a call >> to vm_page_alloc() to allocate another page at the same pindex. >> >> Whether it is this list of pages that is corrupted or not, this means >> that the object's list of pages (shown above) and its radix tree of >> pages are out of sync. >> >> I'm curious to know what mpred is when the assertion fails. That will >> tell us something about the state of the radix tree. >> >> I've also modified ddb's "show object" to provide an additional bit of >> information. However, it would be really nice if "show object" >> displayed the state of the radix tree. >> >> > > This patch makes no change. Can you please clarify? Did I not attach the new patch? The new patch changed the output of the KASSERT and ddb's "show object" so that we could get a better idea where the vm object corruption lies.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?539F1676.2020406>