Displaying 3 results from an estimated 3 matches for "d_alloc".
Did you mean:
r_alloc
2001 Oct 05
1
Kernel Ooops probably in conjunction with lvm
...018
Process find (pid: 27143, stackpage=c4e83000)
Stack: fffffff4 c38eeb60 c38eeb60 c48fed60 c4e83efc 00000005 c38eebbc cf8afc94
c0d1c980 00000000 00000000 00000000 00000001 00000000 00000000 00000000
cf7d4400 cf8afc94 00000000 cf8afc94 00000246 00000000 c0d1c980 c0d1c9e4
Call Trace: [d_alloc+27/348] [ext3_lookup+39/124] [real_lookup+83/196] [path_walk+1201/1736] [getname+93/156]
Code: 0f b6 43 06 39 c1 75 4d 83 3b 00 74 48 8b 74 24 18 8b 4c 24
Using defaults from ksymoops -t elf32-i386 -a i386
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symb...
2006 Jul 03
1
Problem with CentOS 4.3 on kernel and ipvsadm
...59737>] copy_page_range+0xfe/0x358
Jul 3 04:02:07 lvs2 kernel: [<c0122380>] dup_mmap+0x3de/0x4a6
Jul 3 04:02:07 lvs2 kernel: [<c0121f61>] copy_mm+0x10e/0x14f
Jul 3 04:02:07 lvs2 kernel: [<c0123172>] copy_process+0x709/0xd52
Jul 3 04:02:07 lvs2 kernel: [<c0186d5e>] d_alloc+0xc2/0x284
Jul 3 04:02:07 lvs2 kernel: [<c01238b1>] do_fork+0x98/0x1a2
Jul 3 04:02:07 lvs2 kernel: [<c0187057>] d_instantiate+0x137/0x13a
So LVS is unusable because after of no more hourse of running the kernel go to panic.
There is a solutions to this problem?
I can help to test...
2010 Mar 02
3
2.6.33 high cpu usage
With the ATI bug I was hitting earlier fixed, only my btrfs partition
continues to show high cpu usage for some operations.
Rsync, git pull, git checkout and svn up are typicall operations which
trigger the high cpu usage.
As an example, this perf report is from using git checkout to change to
a new branch; the change needed to checkout 208 files out of about 1600
total files. du(1) reports