Hi, It is said that the kernel can be debugged in qemu and I take a try. First, I started the qemu with qemu -m 64M -kernel arch/x86/boot/bzImage -initrd ~/image.cpio.gz -net nic -net tap,ifname=tap0 -s In another console gdb vmlinux (gdb) target remote localhost:1234 (gdb) continue A LKM (mymodule.ko) which starts a kernel thread is made with debug info, and was 'scp' to the guest. In guest, it is inserted by insmod mymodule.ko Then, back to gdb (gdb) add-symbol-file mymodule.ko 0xc482e000 (gdb) break mymodules.c:37 (gdb) continue The 37th line of mymodules.c is in a loop of kernel thread, which ensures the breakpoint should be triggered every time the loop go through. But, the breakpoint doesn't triggered as expected. Instead, the kernel thread is running over and over indicated by its repeated output messages. So, I think a kernel thread can not be break by any breakpoint. However, I think maybe the gdb want to attach to the kernel thread. Then, I checked the kernel thread's PID with ps and got 62. (gdb) control+C (gdb) attach 62 The gdb promted me it will kill the program being debugged. I answered with 'yes', the gdb told me ptrace: No such process. then the debug session is terminated and the guest is closed. I started the qemu with the above command again qemu -m 64M -kernel arch/x86/boot/bzImage -initrd ~/image.cpio.gz -net nic -net tap,ifname=tap0 -s And, without quitting the gdb (gdb) target remote localhost:1234 (gdb) continue In the guest, 'mymodule.ko' is inserted again insmod mymodule.ko I found that the breakpoint set at mymodule.c:37 is triggered this time surprisingly, and the 'insmod' didn't return immediately until the gdb is given with another 'continue' command. (gdb) continue Then, the breakpoint doesn't triggered anymore as usual, There is two questions: 1. Why the kernel thread can not be break? 2. Why is the breakpoint triggered just when the 'mymodule.ko' is loaded? Thanks.