Hi ,
Use the method described in *Documentation/oops-tracing.txt *of linux
source tree to get to know where
(<ffffffff8016174f>{kmem_cache_alloc+90}
<ffffffffa0252057>{:device:device_open_nic+94}) cause the problem. That
is the first step to find the cause.
Thanks
camelguo
jasjit singh 写道:
Hi
I am calling kmalloc() at the starting of open function in my driver
for a PCI device. Here it is used to allocate the private structure.
When I run application over this driver, it goes successful for the
first time. But when I run this for second time, the kmalloc() causes
kernel panic with the following messages.
---------------------------------------------------------------------------------
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: 7035, comm: dat_data_check_ Tainted: PF 2.6.9-42.ELsmp
RIP: 0010:[<ffffffff8016187e>] <ffffffff8016187e>{cache_alloc_refill+206}
RSP: 0018:00000100261e9d88 EFLAGS: 00000012
RAX: 0000000000000004 RBX: 0000000000000003 RCX: 0000010137210400
RDX: 00000100bff6fcc8 RSI: 0000000000000220 RDI: 00000100bff6fd28
RBP: 00000100bff5a0c0 R08: ffffffff803e1ee8 R09: 00000101340c45c0
R10: 0000000100000000 R11: 0000ffff803fcc00 R12: 00000100bff6fcc8
R13: 00000100bff6fc80 R14: 0000000000000220 R15: 0000000000000002
FS: 0000002a956843e0(0000) GS:ffffffff804e5080(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000521000 CR3: 0000000000101000 C 00000000000006e0
Process dat_data_check_ (pid: 7035, threadinfo 00000100261e8000, task
00000101358e8030)
Stack: 0000000000000220 0000000000000220 00000100bff6fc80 00000100aa7a0000
0000000000000000 00000100261e9e20 0000000000000002 ffffffff8016174f
0000000000000246 00000101340c45c0
Call Trace:<ffffffff8016174f>{kmem_cache_alloc+90}
<ffffffffa0252057>{:device:device_open_nic+94}
<ffffffffa025009a>{:device:device_open+46}
<ffffffff80181599>{chrdev_open+412}
<ffffffff801789c2>{__dentry_open+201}
<ffffffff80178b88>{filp_open+106}
<ffffffff801ece75>{strncpy_from_user+74}
<ffffffff80178d77>{sys_open+57}
<ffffffff8011026a>{system_call+126}
Code: 39 41 20 eb 3f ff cb 83 fb ff 74 3a 0f b7 41 24 8b 55 00 41
Kernel panic - not syncing: nmi watchdog
---------------------------------------------------------------------------------
I kept checking memory usage. There was lots of memory available for
this kmalloc to be successful. And kmalloc() is also the first step in
open function. However there is memory allocation afterwards at a few
places using kmalloc and __get_free_pages.
I am calling kmalloc with the flag GFP_KERNEL. I have also tried with
GFP_ATOMIC, the result is same.
Could you please tell me what malfunction the first run is doing? Is
it doing some memory corruption?
Regards,
Jasjit Singh
------------------------------------------------------------------------
Sent from Yahoo! Mail
<http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52418/*http://uk.docs.yahoo.com/nowyoucan.html>.
A Smarter Email.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
