Re: kern/52252: uvm_km_check_empty panic when loading any module

[Anthony Mallet <tho%netbsd.org@localhost>]

On Tuesday 23 May 2017, at 21:05, Jaromír Doleček wrote:
>  1. make sure to rebuild your complete kernel, to make sure no
>     obsolete .o
>  were used - make clean && make depend && make

Yes. When doing an important upgrade I usually wipe out /usr/obj (or
move it away) and do a ./build.sh without -u.
In this case I'm also 100% sure that I did this.

>  2. make sure that DEBUG/LOCKDEBUG options between your kernel and
>     the
>  modules match - since DEBUG and LOCKDEBUG change size of critical
>  kernel structures, kernel will trample over random structure
>  contents since what module allocates is less than the kernel uses.
>
>  Looking on your config, it seems you do have the DEBUG and
>  LOCKDEBUG options there, so I think that is your problem.

Good point, but see below.
For the consistency between kernel & modules, I guess it's not
sufficient to do a ./build.sh modules, since this will not pick up the
DEBUG option from my custom kernel, right? How should I proceed, then?


Actually, my issue started with a kernel without DEBUG nor LOCKDEBUG,
and while trying to just "npfctl reload", with no module involved at
all (I usually don't use modules).

The panic was also in the same uvm_km_check_empty() when sljit -
builtin in the kernel, 100% sure - was doing a uvm_km_alloc().
See here for a partial backtrace:
http://mail-index.netbsd.org/current-users/2017/04/15/msg031529.html

This is after this panic that I discovered that anything trying to
uvm_km_alloc() in module_map was panicing on the very first page of
module_map. I can reproduce this on my test machine (the PAPYRUS
kernel that I sent) if needed, for clarity.