What should I have to fix a bug?

1. Bug. Well known particular bug.
2. A buggy kernel.
3. Bit of luck.

Note:

• Having a repeatable bug is more then 50% of success.
• All examples are from 2.6.17.13 (i386)

Function printk().

printk is a very useful function similar to printf(). This function works everywhere and at any time (apart from early stage of booting the kernel when video isn't initialized). It uses log levels to tell the console the importance of each message. Full list of levels:

1. KERN_EMERG <-- the most important

2. KERN_ALERT
3. KERN_CRIT
4. KERN_ERR
5. KERN_WARNING
6. KERN_NOTICE
7. KERN_INFO

8. KERN_DEBUG <-- the least important

The console will print messages only with a level higher than console_loglevel. By default printk uses DEFAULT_MESSAGE_LOGLEVEL == KERN_WARNING (but this may be changed in the future).

printk() uses a cyclic buffer to manage the messages. Next klogd reads the messages (using /proc/kmsg) from the buffer and gives them to syslogd which writes them to /var/log/messages. (You can configure syslogd by editing /etc/syslog.conf).

Examples:

• printk(loglevel "mesages");

From: Linux/arch/mips/sgi-ip27/ip27-berr.c

20 #if 1
321         printk("FIXME: disabling master aborts\n");
322         csrs->POx_MSK_HEI.csr &= ~(3UL << 14);
323 #endif 

Error oops.

An oops is report of a bug in the kernel. When an oops occurs the kernel will print what the registers contain and a "back trace". An oops does not mean the system has crashed, as the system can sometimes recover from the error. If the system can not recover from the error then the kernel will panic and stop running. By default the back trace will contain the addresses of the functions that were called. If you compile your kernel with CONFIG_KALLSYMS=y the oops will be decoded and will display the function names. In the 2.4 kernel you can use ksymoops file_with_oops.txt to see the names of the functions.

http://www.urbanmyth.org/linux/oops/slides.html <-- useful link

Additional compiling options.

These options are very useful when debugging kernel:

CONFIG_PREEMPT=y

CONFIG_DEBUG_KERNEL=y

CONFIG_KALLSYMS=y

CONFIG_SPINLOCK_SLEEP=y

CONFIG_MAGIC_SYSRQ=y

Causing errors and printing extra informations.

1. Sometimes you will want to see oops informations about some bug. Use BUG() BUG_ON():

if(bad_thing)

• BUG();

or BUG_ON(bad_thing);

Examples:

From: Linux/arch/arm/plat-omap/dma.c

732         if (omap_dma_in_1510_mode()) {
733                 printk(KERN_ERR "DMA linking is not supported in 1510 mode\n");
734                 BUG();
735                 return;
736         } 

1221         BUG_ON(lcd_dma.active); 

1. Sometimes you will want to see oops informations and then stop system. Use panic(): if(terrible_error)
   • panic("var = %ld \n", var);
2. Sometimes you will want to see stack. Use dump_stack():

if(debug_check)

• dump_stack();

Examples:

From: Linux/arch/cris/arch-v32/kernel/dma.c

40                 if (options & DMA_PANIC_ON_ERROR)
41                         panic("request_dma error!"); 

From: Linux/drivers/scsi/hosts.c

398         if (!sht->detect) {
399                 printk(KERN_WARNING "scsi_register() called on new-style "
400                                     "template for driver %s\n", sht->name);
401                 dump_stack();
402         } 

Magic SysRq Key.

If you set CONFIG_MAGIC_SYSRQ=y or typed 'echo 1 > /proc/sys/kernel/sysrq', you can use SysRq Key (on PPC or i386) 'Alt+PrintScreen'.

1. SysRq+b Restart computer

2. SysRq+e Send SIGTERM to all tasks (with out init !!!)

3. SysRq+h Help

4. SysRq+i Send SIGKILL to all tasks (with out init !!!)

5. SysRq+k Kill all tasks ran from this console

6. SysRq+l Send SIGTKILL to all tasks (with init !!!)

7. SysRq+m Dump core and show it on console

8. SysRq+o Halt system and shutdown it

9. SysRq+p Print CPU registers on console

10. SysRq+r Change keyboard from RAW to XLATE

11. SysRq+s Save dirty buffers on HDD

12. SysRq+t Show current task info on console

13. SysRq+u Unmount all filesystems, and remount read only

Note that every user can use SysRq keys, and it can work improperly on an unstable system.

[:KernelHacking-HOWTO/Debugging Kernel/Debuggers:How to use non-exist debugger?]

How to use debuggers?

Before i start talking about debuggers you must know one thing. Linus don't give permission to use debuggers, because debuggers show not always true informations.

• gdb

  • gdb vmlinux /proc/kcore <--> vmlinux is un compresed image of kernel( find it in the top level kernel source directory) /proc/kcore allow gdb to see Linux's memory

http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html <-- documentaction for gdb

• + simple in use
• - you can not change data in running kernel
• kgdb
• kgdb is a path for a kernel that allow you to connect two computers, one with kgdb and second with gdb
• + you can modificate data and variables
• - you must configure connection.
• kdb

When everything fail.

No one likes bugs. So when you spend hours/days on bug fixing, you may write a short and descriptive email containing your all of the information you have found, and send it to LKML. Good luck with Bug Hunting.