On Wed, 09 Mar 2005 09:35:44 -0800, Michael O'Keefe wrote > >>Has anyone here on this mail list had experience with debugging the linux > >>kernel? Apparently it is necessary to debug the spb2, ieee1394 and > >>ohci1394 > >>kernel modules to find out why the firewire isn't working. > >> > >>Is this done by recompiling those modules with a debug option, then using > > > > gdb > > > >>or preferably insight to actually debug? > >> > >>What is a rather robust method of doing this? Thanks for the input. > > > > First thing to do is check the module source code for a debug parameter. > > Many of the modules accept a load option that cranks up the log level that > > gives you a much more detailed look at what is going on. Sometimes you may > > have to recompile the module to get the debug options. > > And if there aren't any such options, add them yourself, and add > some printk()'s throughout the code. > > An alternative nowadays is to run the Kernel in User Space (UML ?), > I believe that makes it easier to debug, and reduces the need to > reboot when the kernel Oops', and possibly wait for fsck's etc. > > I have done some bttv debugging, and writing some modules using UVFS > (UserSpace Virtual File System)
Agreed. Really your only choice for debugging a module that interfaces with hardware is to make liberal use of printk statements. IF, you are debugging a "software only" module that doesn't interface with hardware (or you can stub out the hardware interaction functions), then User Mode Linux is a very good debugging option. On a previous project, I used it to single step through a virtual network device driver module. Worked out great and I didnt' bring down the whole system when the module went haywire. -Jon Wahlmann -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
