views:

398

answers:

3

Hi there, I'm working on my first ever kernel module so I'm a bit new at this...

My module is occasionally producing a panic and I cannot get to the bottom of it using printk. As far as I can tell my options for debugging are:

1.) Find the generated OOPS message and use ksymoops

or

2.) Try at remote debug using kgdb

I'm working on a windows host and running Ubuntu in VMWare so that complicates things a bit. I'd like to try the OOPS message first but I don't know how to capture it. Do I need to be running a serial console when it happens? If so, how can I do that with Windows host? Do I need two VM's?

Like I said, I'm a bit new to this (and Linux in general) so I could really use some guidance. Thanks!

A: 

See if this helps. I don't use Windows or VMWare http://communities.vmware.com/thread/236251;jsessionid=A4A69CC15C7B951C576EF254604655D8?tstart=0

alinrus
+1  A: 

A while ago I successfully used the technique "alinrus" refers to. The part he mentioned is explained in detail at: http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html

I actually used it directly from a Windows host. So after setting up the VM (mainly enabling remote debugging and downloading the kernel (the vmlinux file, not the vmlinuz file which cannot be interpreted by gdb)), you would need to do the following:

  1. Install a recent gdb on your Windows machine (I used the one in Cygwin).
  2. Start gdb with the vmlinux file, and then do "target remote localhost:8832" to connect the VM (when it's running).

That is what you need to debug code which is statically linked into the kernel. You could try statically linking your module and the above would be sufficient. Setting up debugging for a dynamically-linked module requires an additional step to inform to gdb to use your module file as well, and how to interpret the file's sections.

3a. Run the script below on your .ko file, after loading the module (and before crashing it :) ).

3b. Paste the resulting "add-symbol-file mymodule.ko 0xe8884000 ..." lines into gdb. gdb will then load your module, as long as it can find it in the current directory or path you specify.

Script is from http://anomit.com/2009/11/04/kernel-module-debugging-a-simple-technique/

#!/bin/sh
#
# gdbline module image
#
# Outputs an add-symbol-file line suitable for pasting into gdb to examine
# a loaded module.
#
cd /sys/module/$1/sections
PROG=${1}.ko
echo -n add-symbol-file ${PROG} `/bin/cat .text`
#echo -n add-symbol-file $2 `/bin/cat .text`  #Take second argument to be gdb name of program/object file

for section in .[a-z]* *; do
    if [ $section != ".text" ]; then
        echo  " \\"
        echo -n "       -s" $section `/bin/cat $section`
    fi
done
echo

There are more things you may want to do. To do actual source-level debugging you'll want to suck down all the kernel and module source code so that gdb can find it. And there are some tricks you can use to compile your module without optimization once you get this far.

You may also want to look at Workstation 7.0's tech note on replay debugging, which contains information on debugging kernel modules. VMware knows their stuff. http://www.vmware.com/pdf/ws7_replay_linux_technote.pdf

Paul
A: 

I'm not sure if this will help you on Winblowz, but if you can move your VM to a linux box:

Debugging Linux kernels with Workstation 6.0

We just quietly added an exciting feature to Workstation 6.0. I believe it will make WS6 a great tool for Linux kernel development. You can now use gdb on your host to debug the Linux kernel running inside the VM. No kdb, no recompiling and no need for second machine. All you need is a single line in VM's configuration file.

I think this probably works on other recent VMware products as well.

Since it works on Mac OSX as well I suspect it would work on Winblowz also:

Debugging linux kernel (inside vmware) from Mac OSX

As this thread suggests, you might also remotely debug one linux VM from a second linux VM running on the same machine.

Robert S. Barnes