Re: Early drop to debugger with DEBUG_MEMGUARD

On Mon, Aug 12, 2013 at 02:44:35PM -0700, David Wolfskill wrote:
> On Mon, Aug 12, 2013 at 09:10:55AM -0700, Davide Italiano wrote:
> > ...
> > OK, I'm not sure I can make an immediate guess on where's the problem
> > now (without access to my main workstation), so I think you need to
> > wait tomorrow unless someone beats me to the punch. The best I can say
> > is that maybe r254025 is responsible for this. Try to revert and see
> > if things work again.
> > ....
> 
> I tried backing out r254025, but there had been enough time that other
> commits had touched the same files.  Ended up backing out r254165,
> r254171, r254172, and r254182 as well (which seemed to go OK), but the
> result didn't build.
> 
> So I just checked out a new src working copy _at_r254024, built the world
> and kernel cleanly, verified that it booted OK, then updated the src
> working copy to r254025, built, booted, and ... BANG!
> 
> 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 #3  r254025M/254025:1000041: Mon Aug 12 14:23:48 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: enter: panic
> [ thread pid 0 tid 0 ]
> Stopped at      kdb_enter+0x3d: movl    $0,kdb_why
> db> 
> 
> So I think it's fair to say that r254025 introduced the problem.
> 
> I'll go ahead and use kernel configs without DEBUG_MEMGUARD on head
> until this is resolved (or I have an opportunity to test patches
> for someone).
> 
> The r254025 environment is on a "spare" slice of the boot drive of
> the machine, so I can leave it for now.  My more usual (active)
> "head" slice is running:
> 
> FreeBSD 10.0-CURRENT #1243  r254245M/254246:1000042: Mon Aug 12 05:39:42 PDT 2013     root_at_freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  i386
> 
> I'll be happy to test either or both.

The r254025 indeed introduced the problem, and Davide pointed out you a
workaround for the assertion triggering.

Proper fix for the memguard requires a policy of M_NEXTFIT or like, to
avoid a reuse of the previous allocated range as long as possible.

But, you have some further issue even after the assertion was silenced,
isn't it ?