Results 1 to 1 of 1
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Mar 2008
Kernel panic debugging help needed
I am currently developing a new transport protocol as a Linux kernel module and I am close to finishing. Although I have faced a lot of bugs since the beginning, it seems that this one is very difficult to solve.
I am making the development in a virtual machine (QEMU), so that system crashes become less annoying. The problem with the last bug I faced is that the QEMU virtual machine window that pops up has only 25 rows (80x25) and I cannot see the whole debugging information that is printed on my screen just before the system crashes. So I loose part of the kernel oops output and all my printks. And when I reboot and look at /var/log/messages the last printks before the crash of my program along with the kernel oops output were not printed.
Here is the debug info I get just before kernel panic.
<a href="http://img233.imageshack.us/img233/3748/kernelpanicvp1.png">Kernel panic</a>
Is there any way to make the terminal bigger so I can see the more debug lines? I tried to google it but didn't have much luck.
Now, concerning on how to take advantage of the non-complete information that appears on the virtual machine screen..
I suppose the kernel panic happens at the function cop_rcv,right?
I tried to follow the guide provided in Linux: How To Locate An Oops | KernelTrap in order to trace the exact line that causes the problem.
1) I did "objdump -d cop.o > cop.disasm"
2) "make cop.s" wouldn't work since my Makefile is the simplest possible for building a module. Could someone please tell me how to make "make cop.s" work for me?
I tracked cop_rcv inside cop.disasm and tried to track the hex offset +0x253 (see uploaded image) inside cop_rcv but there was no such line! What should I do?
Anyone, please any ideas on how to manage these kind of panics since I can only see 25 rows and I miss a lot of my printks?
By the way, when I try to introduce some delay of 2 sec or more after a printk in cop_rcv so I can have some time to see the debug output before the system crashes, the bug is not reproduced.
I would highly appreciate any useful hint!