How to see the data content in page cache (ia64, 2.6.9)
I would like to know how to see page cache data in ia64 platform. Here is what I tried.
# rpm -qi crash Name : crash Relocations: (not relocatable) Version : 4.1.2 Vendor: Red Hat, Inc. Release : 4.el5 Build Date: Thu Feb 11 05:50:40 2010 Install Date: Sat Mar 20 13:18:50 2010 Build Host: boris.build.redhat.com Group : Development/Debuggers Source RPM: crash-4.1.2-4.el5.src.rpm Size : 8294048 License: GPLv2 Signature : DSA/SHA1, Fri Feb 12 18:23:44 2010, Key ID 5326810137017186 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://people.redhat.com/anderson Summary : crash utility for live systems; netdump, diskdump, kdump, LKCD or mcore dumpfiles Description : The core analysis suite is a self-contained tool that can be used to investigate either live systems, kernel core dumps created from the netdump, diskdump and kdump packages from Red Hat Linux, the mcore kernel patch offered by Mission Critical Linux, or the LKCD kernel patch. crash> sys KERNEL: ./vmlinux DUMPFILE: ./vmcore CPUS: 6 DATE: Fri Mar 11 12:44:22 2011 UPTIME: 81 days, 22:52:43 LOAD AVERAGE: 83.31, 73.83, 54.87 TASKS: 11090 NODENAME: XXXXXXXXX RELEASE: 2.6.9-42.EL VERSION: #1 SMP Wed Apr 23 01:17:02 JST 2008 MACHINE: ia64 (1418 Mhz) MEMORY: 15.7 GB PANIC: (INIT) crash> mach MACHINE TYPE: ia64 MEMORY SIZE: 15.7 GB CPUS: 6 PROCESSOR SPEED: 1418 Mhz HZ: 1024 PAGE SIZE: 16384 KERNEL STACK SIZE: 32768 KERNEL CACHED REGION: e000000000000000 KERNEL UNCACHED REGION: c000000000000000 KERNEL VMALLOC REGION: a000000000000000 USER DATA/STACK REGION: 8000000000000000 USER DATA/STACK REGION: 6000000000000000 USER TEXT REGION: 4000000000000000 USER SHARED MEMORY REGION: 2000000000000000 USER IA32 EMULATION REGION: 0000000000000000 crash> files PID: 5647 TASK: e0000002a2718000 CPU: 3 COMMAND: "XXXXXXXXXXX" ROOT: / CWD: XXXXXXXXXXXXX FD FILE DENTRY INODE TYPE PATH 0 e000000106c34100 e00000010896f350 e000000105e60a40 CHR /dev/null 1 e0000002bcbab000 e00000011bf75a00 e0000001157363d8 REG XXXXXXXXX 2 e0000002bcbab000 e00000011bf75a00 e0000001157363d8 REG XXXXXXXXX 3 e00000011f55b100 e0000001099fdcd0 e0000001173c7350 REG XXXXXXXXX 4 e0000002bf68b400 e00000011bf75a00 e0000001157363d8 REG XXXXXXXXX 5 e0000002be754200 e00000011bf75af0 e0000001157360c0 REG XXXXXXXXX 6 e00000011f55b400 e00000011bf75be0 e000000115735da8 REG XXXXXXXXX 7 e0000002c338fa00 e00000011dad5910 e00000010a2be6d0 SOCK socket:/[74273] 8 e0000002bf688900 e0000002a058c470 e00000010981eb50 SOCK socket:/[74405] 9 e00000011f559400 e00000010f355be0 e00000010981edd0 SOCK socket:/[74406] 10 e00000010c571600 e00000010ad1e720 e00000010e23c140 CHR XXXXXXXXX 11 e0000002c63fac00 e00000010896fda0 e000000114e96540 CHR XXXXXXXXX 12 e00000010e7bde00 e00000010bb66540 e00000010e23c440 CHR XXXXXXXXX 13 e00000010a8c3900 e0000002b6236720 e0000002a682d7d0 SOCK socket:/[75027] 16 e0000002b8e00c00 e0000002c1d3cb00 e0000002f0239e28 REG XXXXXXXXX crash> inode e0000001157363d8 struct inode { i_hash = { next = 0x0, pprev = 0xe000000103c50f08 }, i_list = { next = 0xe0000002176fb0c8, prev = 0xe00000000f460aa8 }, i_dentry = { next = 0xe00000011bf75a68, prev = 0xe00000011bf75a68 }, i_ino = 264070, i_count = { counter = 1 }, i_mode = 33188, i_nlink = 1, i_uid = 0, i_gid = 0, i_rdev = 0, i_size = 265086, i_atime = { tv_sec = 1299815058, tv_nsec = 0 }, i_mtime = { tv_sec = 1299815058, tv_nsec = 0 }, i_ctime = { tv_sec = 1299815058, tv_nsec = 0 }, i_blkbits = 12, i_blksize = 16384, i_version = 1, i_blocks = 528, i_bytes = 0, i_sock = 0 '\0', i_lock = { lock = 0 }, i_sem = { count = { counter = 0 }, sleepers = 0, wait = { lock = { lock = 0 }, task_list = { next = 0xe000000115736498, prev = 0xe000000115736498 } } }, i_alloc_sem = { count = 0, wait_lock = { lock = 0 }, wait_list = { next = 0xe0000001157364b0, prev = 0xe0000001157364b0 } }, i_op = 0xa000000200357430, i_fop = 0xa0000002003574d0, i_sb = 0xe0000001044f7480, i_flock = 0x0, i_mapping = 0xe0000001157364e8, // struct address_space i_data = { host = 0xe0000001157363d8, page_tree = { height = 1, gfp_mask = 544, rnode = 0xe00000005b691988 }, tree_lock = { lock = 0 }, i_mmap_writable = 0, i_mmap = { prio_tree_node = 0x0, index_bits = 1 }, i_mmap_nonlinear = { next = 0xe000000115736518, prev = 0xe000000115736518 }, i_mmap_lock = { lock = 0 }, truncate_count = { counter = 0 }, nrpages = 1, writeback_index = 0, a_ops = 0xa000000200357658, flags = 210, backing_dev_info = 0xe000000108ebe3c0, private_lock = { lock = 0 }, private_list = { next = 0xe000000115736560, prev = 0xe000000115736560 }, assoc_mapping = 0x0 }, i_dquot = {0x0, 0x0}, i_devices = { next = 0xe000000115736588, prev = 0xe000000115736588 }, i_pipe = 0x0, i_bdev = 0x0, crash> address_space 0xe0000001157364e8 struct address_space { host = 0xe0000001157363d8, page_tree = { // struct radix_tree_root height = 1, gfp_mask = 544, rnode = 0xe00000005b691988 // struct radix_tree_node }, tree_lock = { lock = 0 }, i_mmap_writable = 0, i_mmap = { prio_tree_node = 0x0, index_bits = 1 }, i_mmap_nonlinear = { next = 0xe000000115736518, prev = 0xe000000115736518 }, i_mmap_lock = { lock = 0 }, truncate_count = { counter = 0 }, nrpages = 1, writeback_index = 0, a_ops = 0xa000000200357658, flags = 210, backing_dev_info = 0xe000000108ebe3c0, private_lock = { lock = 0 }, private_list = { next = 0xe000000115736560, prev = 0xe000000115736560 }, assoc_mapping = 0x0 } crash> radix_tree_node 0xe00000005b691988 struct radix_tree_node { count = 1, slots = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa0007fffc9388ed0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, tags = {{0}, {0}} } crash> page 0xa0007fffc9388ed0 struct page { flags = 4503599627374593, _count = { counter = 3 }, _mapcount = { counter = -1 }, private = 16140901074090370392, mapping = 0xe0000001157364e8, index = 16, lru = { next = 0x100100, prev = 0x200200 } } I read the 2.6.9 kernel code to see what address is returned by calling page_address(), and here is the result. mm/highmem.c 518void *page_address(struct page *page) 519{ 520 unsigned long flags; 521 void *ret; 522 struct page_address_slot *pas; 523 524 if (!PageHighMem(page)) 525 return lowmem_page_address(page); include/linux/mm.h 410static inline void *lowmem_page_address(struct page *page) 411{ 412 return __va(page_to_pfn(page) << PAGE_SHIFT); 413} include/asm-ia64/page.h 52#ifdef __ASSEMBLY__ 53# define __pa(x) ((x) - PAGE_OFFSET) 54# define __va(x) ((x) + PAGE_OFFSET) 55#else /* !__ASSEMBLY */ ... 117#define __va(x) ({ia64_va _v; _v.l = (long) (x); _v.f.reg = -1; _v.p;}) ... 149#endif /* !__ASSEMBLY__ */ include/asm-ia64/page.h 189#define PAGE_OFFSET __IA64_UL_CONST(0xe000000000000000) include/asm-ia64/types.h 16#ifdef __ASSEMBLY__ 17# define __IA64_UL(x) (x) 18# define __IA64_UL_CONST(x) x 19 20# ifdef __KERNEL__ 21# define BITS_PER_LONG 64 22# endif 23 24#else 25# define __IA64_UL(x) ((unsigned long)(x)) 26# define __IA64_UL_CONST(x) x##UL include/asm-ia64/page.h 86#ifndef CONFIG_DISCONTIGMEM 87# define pfn_valid(pfn) (((pfn) < max_mapnr) && ia64_pfn_valid(pfn)) 88# define page_to_pfn(page) ((unsigned long) (page - mem_map)) 89# define pfn_to_page(pfn) (mem_map + (pfn)) 90#else 91extern struct page *vmem_map; 92extern unsigned long max_low_pfn; 93# define pfn_valid(pfn) (((pfn) < max_low_pfn) && ia64_pfn_valid(pfn)) 94# define page_to_pfn(page) ((unsigned long) (page - vmem_map)) 95# define pfn_to_page(pfn) (vmem_map + (pfn)) 96#endif include/asm-ia64/page.h 15/* 16 * PAGE_SHIFT determines the actual kernel page size. 17 */ 18#if defined(CONFIG_IA64_PAGE_SIZE_4KB) 19# define PAGE_SHIFT 12 20#elif defined(CONFIG_IA64_PAGE_SIZE_8KB) 21# define PAGE_SHIFT 13 22#elif defined(CONFIG_IA64_PAGE_SIZE_16KB) 23# define PAGE_SHIFT 14 24#elif defined(CONFIG_IA64_PAGE_SIZE_64KB) 25# define PAGE_SHIFT 16 26#else 27# error Unsupported page size! 28#endif crash> rd vmem_map a0000001007ceae8: a0007fffc7200000 .. ..... The calculation in lowmem_page_address() should be: __va(page_to_pfn(page) << PAGE_SHIFT = (((unsigned long) (page - vmem_map)) << PAGE_SHIFT) + PAGE_OFFSET Because, page=0xa0007fffc9388ed0 vmem_map=0xa0007fffc7200000 PAGE_SHIFT=14 PAGE_OFFSET=0xe000000000000000 = ((0xa0007fffc9388ed0 - 0xa0007fffc7200000) << 14) + 0xe000000000000000 = (0x2188ed0 << 14) + 0xe000000000000000 = 0xE000008623B40000 crash> rd 0xE000008623B40000 rd: read error: kernel virtual address: e000008623b40000 type: "64-bit KVADDR" Would you please tell me what's wrong? Thanks in advance, Terry |
Maybe, the page data can be seen from the page address as below. Could somebody tell me if this is correct?
crash> kmem 0xa0007fffc9388ed0 PAGE PHYSICAL MAPPING INDEX CNT FLAGS a0007fffc9388ed0 265358000 e0000001157364e8 16 3 10000000001001 ^^^^^^^^^ crash> mach MACHINE TYPE: ia64 MEMORY SIZE: 15.7 GB CPUS: 6 PROCESSOR SPEED: 1418 Mhz HZ: 1024 PAGE SIZE: 16384 KERNEL STACK SIZE: 32768 KERNEL CACHED REGION: e000000000000000 ^^^^^^^^^^^^^^^^ KERNEL UNCACHED REGION: c000000000000000 KERNEL VMALLOC REGION: a000000000000000 USER DATA/STACK REGION: 8000000000000000 USER DATA/STACK REGION: 6000000000000000 USER TEXT REGION: 4000000000000000 USER SHARED MEMORY REGION: 2000000000000000 USER IA32 EMULATION REGION: 0000000000000000 crash> p/x (0x265358000+0xe000000000000000) $2 = 0xe000000265358000 crash> rd 0xe000000265358000 2043 e000000265358000: 0000000000000000 0000000000000000 ................ e000000265358010: 0000000000000000 0000000000000000 ................ e000000265358020: 0000000000000000 0000000000000000 ................ e000000265358030: 0000000000000000 0000000000000000 ................ e000000265358040: 0000000000000000 0000000000000000 ................ e000000265358050: 0000000000000000 0000000000000000 ................ e000000265358060: 0000000000000000 0000000000000000 ................ e000000265358070: 0000000000000000 0000000000000000 ................ e000000265358080: 0000000000000000 0000000000000000 ................ e000000265358090: 0000000000000000 0000000000000000 ................ e0000002653580a0: 0000000000000000 0000000000000000 ................ e0000002653580b0: 0000000000000000 0000000000000000 ................ e0000002653580c0: 0000000000000000 0000000000000000 ................ e0000002653580d0: 0000000000000000 0000000000000000 ................ e0000002653580e0: 0000000000000000 0000000000000000 ................ e0000002653580f0: 0000000000000000 0000000000000000 ................ e000000265358100: 0000000000000000 0000000000000000 ................ e000000265358110: 0000000000000000 0000000000000000 ................ e000000265358120: 0000000000000000 0000000000000000 ................ e000000265358130: 0000000000000000 0000000000000000 ................ e000000265358140: 0000000000000000 0000000000000000 ................ e000000265358150: 0000000000000000 0000000000000000 ................ e000000265358160: 0000000000000000 0000000000000000 ................ e000000265358170: 0000000000000000 0000000000000000 ................ e000000265358180: 0000000000000000 0000000000000000 ................ e000000265358190: 0000000000000000 0000000000000000 ................ e0000002653581a0: 0000000000000000 0000000000000000 ................ e0000002653581b0: 0000000000000000 0000000000000000 ................ e0000002653581c0: 0000000000000000 0000000000000000 ................ e0000002653581d0: 0000000000000000 0000000000000000 ................ e0000002653581e0: 0000000000000000 0000000000000000 ................ e0000002653581f0: 0000000000000000 0000000000000000 ................ e000000265358200: 0000000000000000 0000000000000000 ................ e000000265358210: 0000000000000000 0000000000000000 ................ e000000265358220: 0000000000000000 0000000000000000 ................ ... If this is correct, why the cached data is empty? |
All times are GMT -5. The time now is 05:34 AM. |