I have been experimenting with getting kgdb
to work the Nexus One.
I have pulled the kernel from https://android.googlesource.com and enabled everything to do with kgdb
including kgdbts
testing using menuconfig
. Successfully built the kernel and flashed it to the device (which is unlocked rooted and running CyanogenMod 7)
I have also followed the instructions found on http://bootloader.wikidot.com/android:kgdb to enable the usb connection to act as a serial connection as required by kgdb
(and tested communications from ttyACM0
to ttyGS0
successfully).
The following folders exist indicating that kgdboc
and kgdbts
have been built into the kernel:
/sys/modules/kgdboc/parameters /sys/modules/kgdbts/parameters
The following is the output from dmesg showing the kgdbts
testing being done show what (I think) is a successful completion of the tests:
# dmesg | grep kgdb <6>[ 12.974060] kgdb: Registered I/O driver kgdbts. <6>[ 12.981781] kgdbts:RUN plant and detach test <6>[ 12.995178] kgdbts:RUN sw breakpoint test <6>[ 13.002441] kgdbts:RUN bad memory access test <6>[ 13.010864] kgdbts:RUN singlestep test 1000 iterations <6>[ 13.019042] kgdbts:RUN singlestep [0/1000] <6>[ 13.077850] kgdbts:RUN singlestep [100/1000] <6>[ 13.132720] kgdbts:RUN singlestep [200/1000] <6>[ 13.187500] kgdbts:RUN singlestep [300/1000] <6>[ 13.242370] kgdbts:RUN singlestep [400/1000] <6>[ 13.297149] kgdbts:RUN singlestep [500/1000] <6>[ 13.351928] kgdbts:RUN singlestep [600/1000] <6>[ 13.406829] kgdbts:RUN singlestep [700/1000] <6>[ 13.461578] kgdbts:RUN singlestep [800/1000] <6>[ 13.516540] kgdbts:RUN singlestep [900/1000] <6>[ 13.570922] kgdbts:RUN do_fork for 100 breakpoints <6>[ 21.117645] kgdb: Unregistered I/O driver kgdbts, debugger disabled.
I believe that the problem I am running into is getting the kernel to trigger kgdb
.
# echo -n g > /proc/sysrq-trigger
Just results in dropping me back to the command prompt and (I think) it is suppose to freeze everything and send a prompt over usb which is being used as a psuedo serial port since the phone doesn't have a real one.
From what I gather from my research that prompt is supposed to be the trigger that will allow me to issue
(gdb) target remote /dev/ttyACM0
And connect to a debugging session with the kernel.
I have also tested /proc/sysrq-trigger
with b
and c
just confirm that I am able to pass some commands to sysrq
.
So my question following my long winded attempt to provide as much information as possible is why is g
not triggering the debugger?
This is my first attempt at kernel debugging on any system and I have run out of ways to phrase my search on google so I turn to you. Thanks!
(I have also tried putting kdgbwait in the kernel command line without success as I believe this is not yet supported by the android kernel)
A kernel debugger is a debugger present in some operating system kernels to ease debugging and kernel development by the kernel developers.
Starting the Debugging SessionOpen WinDbg as Administrator. On the File menu, choose Kernel Debug. In the Kernel Debugging dialog box, open the Local tab. Select OK.
cd to your directory of your kernel tree and run gdb on the “.o” file which has the function sd_remove() in this case in sd.o, and use the gdb “list” command, (gdb) list *(function+0xoffset), in this case function is sd_remove() and offset is 0x20, and gdb should tell you the line number where you hit the panic or oops ...
The Android kernel is based on an upstream Linux Long Term Supported (LTS) kernel. At Google, LTS kernels are combined with Android-specific patches to form what are known as Android Common Kernels (ACKs). Figure 1.
Android Kernel questions are rare on [SO], asa nobody else has answered I have provided my findings on this issue. Unfortunately I don't have a nexus one to test this on so this answer is not intended as a step by step resolution of you problem, but should point you in the right direction of where to look.
The only useful resource I have found on this problem is in a LKML patch by Dongdong Deng, so it is unlikely a configuration issue as these are usually abundant and well-publicized.
This indicates that there is a problem with your kernel build. I would be tempted to start again with the latest versions of CM and see if the problem just goes away.
Failing that, try reporting this to the cyanogen team and see if this is a known issue or has a simple workaround.
As a last resort you could try the patch if the versions are compatible. The only alternative is to roll up your sleeves and start hacking the CM kernel to incorporate the patch.
Good luck.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With