Andrew Morton wrote: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. --
| Ingo Molnar | [patch 12/13] syslets: x86: optimized copy_uatom() |
| Greg Kroah-Hartman | [PATCH 017/196] aoechr: Convert from class_device to device |
| Yinghai Lu | Re: 2.6.26, PAT and AMD family 6 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
