In this case you do not have to disable kgdb, but just disable the
kgdb test suite. Certainly I would be interested to know where it is
failing as it would indicate that there is a regression that is caused
by a change that occurred somewhere else in the kernel or a latent
defect in kgdb was triggered. The kgdb test suite exercises a number
of kernel fault systems as well as arch specific single stepping when
it runs and when it fails it is likely worth it to track down which
test failed and why.
If you are looking to bypass the kgdb test suite you have two options.
The kernel option that runs the tests on boot (which is not on by
default) is CONFIG_KGDB_TESTS_ON_BOOT, and make sure this is off.
You can turn off the tests in an already compiled kernel that had the
testing turned on with boot by adding the boot argument with nothing
on the other side of the = sign of the kgdbts paramter. Like:
kgdbts=
In terms of debugging what happened, if you have console output you
can save, please do send me the output of kernel boot with the kernel
boot argument:
kgdbts=V2
That enables verbose logging of exactly what is going on and will show
where wheels fall off the cart. If the kernel is dying silently it
means the early exception code has completely failed in some way on
the kernel architecture that was selected, and of course the .config
is always useful in this case.
Thanks,
Jason.
--
