On Mon, Aug 12, 2013 at 08:30:15AM -0700, Davide Italiano wrote: > ... > > Booting... > > GDB: no debug ports present > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2013 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 10.0-CURRENT #0 r254245M/254246:1000042: Mon Aug 12 07:20:47 PDT 2013 > > root_at_freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386 > > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > > WARNING: WITNESS option enabled, expect reduced performance. > > panic: Assertion strat == M_BESTFIT || strat == M_FIRSTFIT failed at /usr/src/sys/kern/subr_vmem.c:1050 > > cpuid = 0 > > KDB: stack backtrace: > > db_trace_self_wrapper(c116fcdc,73752f20,72732f72,79732f63,656b2f73,...) at db_trace_self_wrapper+0x2d/frame 0xc1820ba0 > > kdb_backtrace(c11c4b23,0,c0f8a835,c1820c74,c0f8a835,...) at kdb_backtrace+0x30/frame 0xc1820c08 > > vpanic(c12eea08,100,c0f8a835,c1820c74,c1820c74,...) at vpanic+0x11f/frame 0xc1820c44 > > kassert_panic(c0f8a835,c1172e98,c1172e39,41a,8,...) at kassert_panic+0xea/frame 0xc1820c68 > > vmem_alloc(c130d680,6681000,2,c1820cc0,3b5,...) at vmem_alloc+0x53/frame 0xc1820ca0 > > memguard_init(c130d680,c0a9fa50,c6800000,20281000,1000,10000,0) at memguard_init+0x29/frame 0xc1820cc4 > > kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0 > > mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30 > > mi_startup() at mi_startup+0xf7/frame 0xc1820d58 > > begin() at begin+0x2c > > KDB: enter: panic > > [ thread pid 0 tid 0 ] > > Stopped at kdb_enter+0x3d: movl $0,kdb_why > > db> > > > > As you can see, this is well before any device probes or much of > > anything else. Thus, I suspect that it's fairly possible that the > > assertion may well be OK after a certain point in the boot sequence, > > but decidedly *not* OK in this specific instance. Or perhaps the > > assertion just doesn't play well with DEBUG_MEMGUARD. > ... > vmem_alloc() KPI needs the consumer to specify exactly a strategy for > allocation, which is one of two between: M_FIRSTFIT/M_BESTFIT (fast > allocation vs low fragmentation), and that's the assertion that's not > respected within the code. > > 1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT); > > It looks like memguard_init() doesn't specify none of these two strategies. > > 209 vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base); > > My guess is that you need to OR one between M_BESTFIT/M_FIRSTFIT with > M_WAITOK to have your kernel booting. What's better between the two > probably will need some measurements but this should at least make > your kernel booting. Thank you for the insight & suggestion. My first attempt was to make the following change: Index: sys/vm/memguard.c =================================================================== --- sys/vm/memguard.c (revision 254246) +++ sys/vm/memguard.c (working copy) _at__at_ -206,9 +206,9 _at__at_ { vm_offset_t base; - vmem_alloc(parent, memguard_mapsize, M_WAITOK, &base); + vmem_alloc(parent, memguard_mapsize, M_WAITOK | M_FIRSTFIT, &base); memguard_map = vmem_create("memguard arena", base, memguard_mapsize, - PAGE_SIZE, 0, M_WAITOK); + PAGE_SIZE, 0, M_WAITOK | M_FIRSTFIT); memguard_cursor = base; memguard_base = base; This built OK; but attempting to boot yielded: Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #1 r254245M/254246:1000042: Mon Aug 12 08:49:12 PDT 2013 root_at_freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/MEMGUARD i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. panic: mti_zone 195 out of range 8 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c116fcdc,0,ffffffff,c1167d73,fffffffe,...) at db_trace_self_wrapper+0x2d/frame 0xc1820b58 kdb_backtrace(c11c4b23,0,c1167d58,c1820c30,c1820c00,...) at kdb_backtrace+0x30/frame 0xc1820bc0 vpanic(c12eea08,100,c1167d58,c1820c30,c1820c30,...) at vpanic+0x11f/frame 0xc1820c00 kassert_panic(c1167d58,c3,8,c130d7e4,c130d7a8,...) at kassert_panic+0xea/frame 0xc1820c24 malloc(380,c1279778,2,0,ffffffff,...) at malloc+0x308/frame 0xc1820c70 vmem_create(c11a7530,c6800000,6681000,1000,0,...) at vmem_create+0x29/frame 0xc1820ca0 memguard_init(c130d680,c0a9fa50,c6800000,20281000,1000,10000,0) at memguard_init+0x5e/frame 0xc1820cc4 kmeminit(c14b9fd4,c10efc89,0,0,c1820d30,...) at kmeminit+0x171/frame 0xc1820cf0 mallocinit(0,0,2,0,c11d3728,...) at mallocinit+0x32/frame 0xc1820d30 mi_startup() at mi_startup+0xf7/frame 0xc1820d58 begin() at begin+0x2c KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> grepping through the sources indicates to me that I/we have run afoul of: ./kern/kern_malloc.c-504- if (size & KMEM_ZMASK) ./kern/kern_malloc.c-505- size = (size & ~KMEM_ZMASK) + KMEM_ZBASE; ./kern/kern_malloc.c-506- indx = kmemsize[size >> KMEM_ZSHIFT]; ./kern/kern_malloc.c:507: KASSERT(mtip->mti_zone < numzones, ./kern/kern_malloc.c:508: ("mti_zone %u out of range %d", ./kern/kern_malloc.c:509: mtip->mti_zone, numzones)); ./kern/kern_malloc.c:510: zone = kmemzones[indx].kz_zone[mtip->mti_zone]; ./kern/kern_malloc.c-511-#ifdef MALLOC_PROFILE ./kern/kern_malloc.c-512- krequests[size >> KMEM_ZSHIFT]++; ./kern/kern_malloc.c-513-#endif Hmm.... Peace, david -- David H. Wolfskill david_at_catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC