On Fri, Aug 21, 2020 at 12:19:03PM +0200, pet...@infradead.org wrote: > On Thu, Aug 20, 2020 at 04:28:28PM +0100, Daniel Thompson wrote: > > > Specifically I've entered the kdb in pretty much the simplest way > > possible: a direct call to kgdb_breakpoint() from a task context. I > > generate a backtrace to illustrate this, just to give you a better > > understanding of what might be happening) and then ran the single step. > > > > + make -C .. O=$PWD x86_64_defconfig > > + ../scripts/config --enable RUNTIME_TESTING_MENU > > + ../scripts/config --enable DEBUG_INFO --enable DEBUG_FS --enable > > KALLSYMS_ALL --enable MAGIC_SYSRQ --enable KGDB --enable KGDB_TESTS > > --enable KGDB_KDB --enable KDB_KEYBOARD --enable LKDTM > > + ../scripts/config --enable PROVE_LOCKING --enable DEBUG_ATOMIC_SLEEP > > + make olddefconfig > > > That asked me about a kgdb boottime selftest, which I figured was a good > idea, but even without my patches that seems to fail, and fail so that > it doesn't boot :/
If you are running to fork test (the F100 in the default test string of kgdbts=V1F100 kgdbwait) then you will need rodata=off to avoid problems setting or clearing breakpoints (you also need to have at last 100 calls to fork for the test suite to complete; a modern kernel without the excessive forking for hotplug will usually make it well into userspace before racking up this many forks). This will prevent the test suite from hanging the boot although I think you will still see the still see the stacktrace from the hardware watchpoint test (this is unrelated to current patchset). Daniel.