Deciphering Call Trace details

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all

whenever kernel gets panicked, it gives some messages like
---------------------------------------------------------------------------------
NMI Watchdog detected LOCKUP, CPU=0, registers:
CPU 0
Modules linked in: ccp(U) md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core nfs lockd nfs_acld
Pid: 4883, comm: dat_data_check_ Tainted: P      2.6.9-42.ELsmp
RIP: 0010:[<ffffffff801618e6>] <ffffffff801618e6>{cache_alloc_refill+310}
RSP: 0018:000001011843fd88  EFLAGS: 00000013
RAX: 00000100bff6fcc8 RBX: 0000000000000006 RCX: 0000010136626440
RDX: 00000100bff6fcc8 RSI: 00000000000000d0 RDI: 00000100bff6fd28
RBP: 00000100bff5a0c0 R08: ffffffff803e1ee8 R09: 000001013ad703c0
R10: 0000000100000000 R11: 0000ffff803fcc00 R12: 00000100bff6fcc83: 00000100bff6fc80 R14: 0000000002
FS:  0000002a95994d80(0000) GS:ffffffff804e5080(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000521000 CR3: 0000000000101000 CR4: 00000000000006e0
Process dat_data_check_ (pid: 4883, threadinfo 000001011843e000, task 000001013919b7f0)
Stack: 00000000000000d0 00000000000000d0 00000100bff6fc80 000001012ff40000
       0000000000000000 000001011843fe20 0000000000000002 ffffffff8016174f
       0000000000000202 000001013ad703c0
Call Trace:<ffffffff8016174f>{kmem_cache_alloc+90} <ffffffffa0252057>{:ccp:device_open_nic+94}
       <ffffffffa025009a>{:ccp:device_open+46} <ffffffff80181599>{chrdev_open+412}
       <ffffffff801789c2>{__dentry_open+201} <ffffffff80178b88>{filp_open+106}
       <ffffffff8016cd34>{do_mmap_pgoff+1577} <ffffffff801ece75>{strncpy_from_user+74}
       <ffffffff80178d77>{sys_open+57} <ffffffff8011026a>{system_call+126}
 ---------------------------------------------------------------------------------------------------

My question is how I can decipher the constant values that are added to (perhaps) function pointers.
e.g  412 in {chrdev_open+412}.
Can these figures be actually helpful in getting what exactly caused kernel to panic ?

And I am not a hardware specialist. Can I use the values of stack and various CPU registers to my help ? If yes, then how ?

Thanks,
Jasjit Singh


Sent from Yahoo! Mail.
A Smarter Email.

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux