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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility