Andrew Morton wrote:
quoted text
> On Thu, 17 Apr 2008 16:40:34 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> On Thu, 17 Apr 2008 16:03:31 -0700
>> Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>>> I have maybe two hours in which to weed out whatever very-recently-added
>>> dud patches are causing this.  Any suggestions are welcome.
>>>
>> With git-selinux at top-of tree it's repeatably hanging in the CPA
>> self-tests (git-x86 stuff).  Last two lines are:
>>
>> CPA self-test:
>>  4k 8704 large 4847 gb 0 x 0[0-0] miss 0
>>
>> (clear as mud ;))
>>
>> I will find the config knob to disable that test.  Of course, it could be
>> telling me that CPA is buggy.
>
> Disabling CPA_DEBUG didn't help.  It's still hanging.  The final initcall
> is init_kgdbts() and disabling KGDB prevents the hang.

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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/