Re: [Crash-utility] kmem: WARNING: cannot find mem_map page for address
On 12/17/12 09:03, Dave Anderson wrote:
> That also removed the mysterious problem of having a duplicate
error
> message show up on the console.
OK, if that works for you...
In the sense of being able to do my day job, yes.
In the sense of aesthetics, not so much.
Right -- I would never expect error() to be called while inside
an open_tmpfile() operation. Normally the behind-the-scenes data
is parsed, and if anything is to be displayed while open_tmpfile()
is still in play, it would be fprint()'ed using pc->saved_fp.
I think the aesthetically pleasing solution is an "i_am_playing_with_tmpfile()"
call that says it isn't closed and crash functions shouldn't be using it.
Plus a parallel "i_am_done_with_tmpfile()" that gets implied by
"close_tmpfile()".
I can supply a patch, if you like. Probably with less verbose
function names.
>> crash> gdb set $tp = (struct cfs_trace_page
*)0xffff8807fb590740
>> crash> p $tp->page
>> $7 = (cfs_page_t *) 0xffffea001bb1d1e8
>> crash> p *$tp->page
>> $8 = {
>> flags = 144115188075855872,
>> _count = {
>> counter = 1
>> },
>> [...]
>> lru = {
>> next = 0xdead000000100100,
>> prev = 0xdead000000200200
>> }
>> }
>> crash> kmem 0xffffea001bb1d1e8
>> kmem: WARNING: cannot find mem_map page for address: ffffea001bb1d1e8
>> 879b1d1e8: kernel virtual address not found in mem map
>
> So I can print out the page_t structure (renamed as cfs_page_t in Lustre)
> at address 0xffff8807fb590740, but when I try to get kmem information about
> it, it cannot find the page. What am I missing?
>
> Thanks for hints/pointers! Regards, Bruce
I'm not sure, other than it doesn't seem to be able to find ffffea001bb1d1e8
I was able to figure that out. I also printed out the "kmem -v" table and
sorted the result. The result with "kmem -n"
[...]
66 ffff88087fffa420 ffffea0000000000 ffffea0007380000 2162688
67 ffff88087fffa430 ffffea0000000000 ffffea0007540000 2195456
132608 ffff88083c9bdb98 ffff88083c9bdd98 ffff8840e49bdd98 4345298944
132609 ffff88083c9bdba8 ffff88083c9796c0 ffff8840e4b396c0 4345331712
;...]
viz. it ain't there. Which is quite interesting, because if the lustre
cluster file system structure "cfs_trace_data" actually pointed off into
unmapped memory, it would have fallen over long, long before the point
where it did fall over.
>>> ffff8807fb590740
>>> struct cfs_trace_page {
>>> page = 0xffffea001bb1d1e8, <<<<==== address in question
>>> linkage = {
>>> next = 0xffff8807fb590ee8,
>>> prev = 0xffff880824e3d810
>>> },
It seems like it is both there and not there, so I am misunderstanding something.
For sure.
crash> whatis $tp->page
cfs_page_t *
crash> p $tp->page
$8 = (cfs_page_t *) 0xffffea001bb1d1e8
crash> p *$tp->page
$9 = {
flags = 0x200000000000000,
_count = {
counter = 1
},
{
_mapcount = {
counter = -1
},
{
inuse = 65535,
objects = 65535
}
},
{
{
private = 0,
mapping = 0x0
},
ptl = {
{
rlock = {
raw_lock = {
slock = 0
}
}
}
},
slab = 0x0,
first_page = 0x0
},
{
index = 0,
freelist = 0x0,
pfmemalloc = false
},
lru = {
next = 0xdead000000100100,
prev = 0xdead000000200200
}
}
So clearly, I am able to read cfs_page_t data at that address.
But I cannot get the mappings for it, and neither can my lustre
extensions. (We are trying to extract trace data from an in-kernel
circular buffer that is 5,100 pages in size (20 Meg).)
Thank you any help at all! Regards, Bruce