Date: Sun, 15 Jul 2012 16:18:21 -0400 From: Justin Hibbits <chmeeedalf@gmail.com> To: mdf@FreeBSD.org Cc: freebsd-current <freebsd-current@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: panic with DEBUG_MEMGUARD on PowerPC Message-ID: <20120715161821.7fbfff75@narn.knownspace> In-Reply-To: <CAMBSHm99OWq4sK-Wamnfy%2B_W5rJ-2WCQ24kGLFTK%2BQqfQzDs-Q@mail.gmail.com> References: <A3CD63CD-694A-48F5-B0F7-9C8923AFCB90@gmail.com> <CAMBSHm-5Xix46MaYAwBek6hWvcOHZ7%2BR_4cpdG5SH_5RD7difQ@mail.gmail.com> <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> <CAMBSHm-CM0hc2Cu=C-zf7ArENqVz9iOHCjb0wMSPCnYQbXKqdA@mail.gmail.com> <E7611D3D-806F-4BA1-9B83-6C903D23D6EB@gmail.com> <CAMBSHm99OWq4sK-Wamnfy%2B_W5rJ-2WCQ24kGLFTK%2BQqfQzDs-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 15 Jul 2012 09:39:03 -0700 mdf@FreeBSD.org wrote: > On Sat, Jul 14, 2012 at 8:39 AM, Justin Hibbits > <chmeeedalf@gmail.com> wrote: > > On Jul 13, 2012, at 12:20 AM, mdf@freebsd.org wrote: > > > >> On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits > >> <chmeeedalf@gmail.com> wrote: > >>> > >>> On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: > >>> > >>>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits > >>>> <chmeeedalf@gmail.com> wrote: > >>>>> > >>>>> > >>>>> When tracking down a panic exposed by INVARIANTS, I tried > >>>>> setting DEBUG_MEMGUARD, so I could find the culprit that's > >>>>> trashing freed memory. > >>>>> However, this causes a panic at bootup. It shows up right > >>>>> after the first > >>>>> WARNING: WITNESS message, with the following: > >>>>> > >>>>> Tracing, and printf() debugging, I see arguments to > >>>>> vm_map_findspace(): start: 0xD0000000, length: 4246446080, and > >>>>> map->max_offset = 4026531839. > >>>>> > >>>>> Beyond that, I'm lost with tracking this down. Machine is a > >>>>> dual processor > >>>>> PowerPC G4, with 2GB RAM. > >>>> > >>>> > >>>> > >>>> The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of > >>>> virtual space for 2GB of RAM sounds about right (it's been a > >>>> while since I was in this code), unless this is a 32-bit kernel, > >>>> in which case it'd be too much since there isn't that much > >>>> virtual space available. > >>>> > >>>> So, is the kernel 32-bit? What are the values used and returned > >>>> by memguard_fudge()? The intent of that routine is to get > >>>> kmeminit() to allocate a larger map so memguard can use part of > >>>> it for private virtual addresses. But it shouldn't be asking > >>>> for "too much"; i.e. the intent was to check both physical and > >>>> virtual space available and be greedy, but not too greedy. > >>>> > >>>> There were some issues with that code for some platforms that > >>>> e.g. didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in > >>>> r216425. > >>> > >>> > >>> It is a 32-bit kernel, on 32-bit hardware. The values for > >>> memguard_fudge are (defaults): > >>> > >>> tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 > >>> > >>> When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: > >>> > >>> tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: > >>> 2147483648 (all > >>> 2GB). > >>> > >>> But the start and map->max_offset remain the same on all runs I > >>> make. > >> > >> > >> memguard_fudge is still broken for 32-bit architectures with no > >> vm_kmem_max. In the absence of a km_max to limit the value, we > >> essentially use twice the physical memory for the virtual limit. > >> But with 2GB on a 32-bit machine, this requires 4GB of virtual > >> space. > >> > >> Setting vm_kmem_size_max to 2GB should work; I'd expect to see > >> tmp=about 200MB, which is much larger than the input 112MB but the > >> allocation should work. But I don't really know what else PowerPC > >> has need of for virtual space, so that still could be too large. > >> > >> You can try smaller values of vm_kmem_size_max, like 1GB or 512MB. > >> You shouldn't need to set vm_kmem_size at all. At some point the > >> added space for the memguard_map will be small enough that the > >> kmem_suballoc will work. > >> > >> Hmm, what is the min_offset and max_offset of kernel_map when the > >> call to memguard_fudge is made? > >> > >> Thanks, > >> matthew > > > > > > > > Without setting vm.kmem_size/vm.kmem_size_max, I see the following: > > > > map: 0x1000000, min_offset: 0xD0000000, max_offset: 0xEFFFFFFF > > > > It does boot when I set vm.kmem_size=256M/vm.kmem_size_max=512M. > > > > When I tried 512M/1024M, it panicked at the same place -- > > kmem_suballoc from kmeminit. So it looks like I have to set > > vm.kmem_size/vm.kmem_size_max way back in order for it to boot with > > memguard(9). > > Please try the attached patch (or at > http://people.freebsd.org/~mdf/memguard.diff). > > Thanks, > matthew Hi Matthew, That patched works perfectly. Thanks, Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120715161821.7fbfff75>