Ming Zhang wrote:
On Mon, 2008-03-03 at 14:04 -0500, Dave Anderson wrote:
Ming Zhang wrote:
my English sucks...
this is what i got. my side size-512 or size-1024 also works. just stuff
like dentry cache or inode cache does not work.
crash> rd 10078b2bca0 2
10078b2bca0: 000001007877c8d4 00000100710fd5c8 ..wx.......q....
crash> rd -S 10078b2bca0 2
10078b2bca0: [dentry_cache] 00000100710fd5c8
crash> kmem -s 10078b2bca0
kmem: address is not allocated in slab subsystem: 10078b2bca0
No, your English is fine -- it's your command-entering that sucks!
Above, when you entered "kmem -s 10078b2bca0", you're incorrectly entering
the *address* where the dentry_cache reference (1007877c8d4) is located.
And so it's telling you that 10078b2bca0 is not allocated in the slab
subsystem, which it isn't...
But if you entered "kmem -s 1007877c8d4", you'd see the dentry_cache
information.
yes. i noticed that. need some tea when handling 3 bugs at the same
time...
so here is my understanding. it actually shows the slab object that
contain that address. it might not be the address of that object. so
here is what i need to do
crash> rd -x 10078b2bca0
10078b2bca0: 000001007877c8d4
crash> rd -S 10078b2bca0
10078b2bca0: [dentry_cache]
crash> kmem -s 000001007877c8d4
CACHE NAME OBJSIZE ALLOCATED TOTAL
SLABS SSIZE
10037ffc080 dentry_cache 240 9429 10560
660 4k
SLAB MEMORY TOTAL ALLOCATED FREE
1007877c040 1007877c088 16 9 7
FREE / [ALLOCATED]
[1007877c8d4]
this only tell me that it belongs to one dentry object, but no idea
which one
then i have to use kmem -S dentry_cache, find out this piece
SLAB MEMORY TOTAL ALLOCATED FREE
1007877c040 1007877c088 16 9 7
FREE / [ALLOCATED]
[1007877c088]
[1007877c178]
1007877c268 (cpu 1 cache)
1007877c358 (cpu 1 cache)
[1007877c448]
1007877c538 (cpu 1 cache)
[1007877c628]
[1007877c718]
[1007877c808]
~~~~~~~~~~~~~~~~~~~~ then find out it is here.
[1007877c8f8]
1007877c9e8 (cpu 1 cache)
1007877cad8 (cpu 1 cache)
[1007877cbc8]
[1007877ccb8]
1007877cda8 (cpu 1 cache)
1007877ce98 (cpu 1 cache)
then i know the object contain this address is 1007877c808.
then
crash> dentry.d_iname
struct dentry {
[0xcc] unsigned char d_iname[36];
}
crash> eval c808+cc
hexadecimal: c8d4
decimal: 51412
octal: 144324
show me that variable in stack actually is d_iname.
then can we have the output format as
10078b2bca0: [000001007877c808+cc: dentry_cache]
so we know the object address, which slab it is in, and the offset,
(thus can derive the raw value), all in one shot?
You've done a fine bit of debugging your issue...
But I think that's a bit of overkill for each address reference.
To do it right it would have to walk slab chains to gather all of the
information needed by the "kmem -S" output, which can be extremely
time-consuming, and potentially error-prone if the slab chain is
corrupt or being modified while running on a live system.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
