Hi,
jasjit singh <singh.jasjit@xxxxxxxxxxx> writes:
> 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 ?
The stackframe points to 412 bytes into the function chrdev_open(), with
the assembly output you can see which instruction that is.
> 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 ?
Depends on the situation whether they are useful.
See Documentation/BUG-HUNTING.
Hannes
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
