After i apply the KGDB patches to kernel, complie and boot with the new image, my machine appears to hang up. Whats wrong?
KGDB for Linux 2.6.8-rc1 onwards uses early_param to pass the control to KGDB code in the kernel during the bootup. This is done very early in the kernel boot up before any messages can be enabled. Hence during the boot up the kernel is actually waiting for connection from remote GDB but since it cannot display any messages it appears that the machine has hung.

Why are two machines necessary for KGDB?
KGDB requires gdb for handling source code and debug information generated by gcc. gdb cannot be run on the test machine when the kernel is in debug state. Hence gdb has to be run on a separate machine which contains a running kernel.

Can I place breakpoints in interrupt handlers?
Yes, you can. Breakpoints can be placed almost anywhere in a kernel. KGDB cannot handle breakpoints only in the parts of the kernel which are used by it (KGDB). These include the KGDB serial line handler and interprocessor interrupt handlers.

Why does a kernel and modules need to be compiled on a developement machine instead of a test machine?
gdb needs to refer to source code files and vmlinux or a module object file. Since gdb runs on the developement machine, these files are required to be present on the developement machine. The test machine needs vmlinuz or module object files only. If a kernel or modules are compiled on the developement machine, only vmlinuz or module object files need to be copied to the test machine. On the other hand, compiling a kernel or modules on the test machine makes it it necessary to copy object files as well as source code files to the developement machine. Hence a developement model is much simplified if compilation is done on a developement machine.

Why do I need to compile all kernel drivers except for the one to be debugged in the kernel and not as modules?
In the current module debugging model, a module has to be loaded by a script. Drivers compiled in the kernel are loaded automatically during bootup. Since gdb does not know about those modules, if control goes to any code within the module, gdb won't be able to print line numbers, stack trace etc. If modules are needed, then should be loaded by loadmodule.sh script.
KGDB stub as well as gdb will need to be modified to fix the problem. A gdb fix for a similar problem in userland is under implementation (First patch to fix gdb appeared in July 2001). Once gdb is fixed, I'll fix KGDB stub. After that a special script will not be needed to load modules. gdb will automatically recognize all modules loaded in the kernel.
I am working on the problem. Both gdb and KGDB stub fixes are non-trivial and will take some time (Around October 2001). If you need a fix for this problem ealier than that, please send me a mail. If many people want the fix, I'll work faster and release a not-so-complete version.

I am not able to debug my modules ...
For module debugging the appropriate GDB should be used on the development machine. Please see the module debugging page for more details.