----- Original Message ----- Hello Qiao, Interestingly enough, I remember looking into doing something like this to dump the three IPCS facilities quite a while ago. And although I cannot recall exactly what my reasons were, I think I decided against it because there were too many changes to kernel's IPC code over several kernel versions. So I certainly appreciate the amount of work that you have done. I built and tested your patch, and have the following comments. First, when posting a patch, can you please use the current upstream version of the crash utility? I think that your patch must be against crash-6.0.4: $ patch -p1 < ./0001-add-ipcs-command.patch patching file Makefile patching file defs.h Hunk #1 FAILED at 1662. Hunk #2 FAILED at 1820. Hunk #3 succeeded at 3695 (offset 121 lines). Hunk #4 succeeded at 4055 (offset 2 lines). 2 out of 4 hunks FAILED -- saving rejects to file defs.h.rej patching file global_data.c patching file help.c Hunk #1 succeeded at 5566 (offset 75 lines). patching file ipcs.c $ As part of my automated testing process, I run the same command(s), against ~150 saved dumpfiles consisting of various kernel versions. And not surprisingly, when testing the "ipcs" command, it failed a considerable number of times. These are samples of the errors: ipcs: invalid structure member offset: ipc_id_ary_p FILE: ipcs.c LINE: 281 FUNCTION: ipc_search_array() ipcs: invalid structure member offset: idr_layer_layer FILE: ipcs.c LINE: 338 FUNCTION: idr_find() ipcs: zero-size memory allocation! (called from 53ffb3) ipcs: invalid kernel virtual address: 8 type: "ipc_id_ary.p" ipcs: cannot resolve "hugetlbfs_file_operations" and eventually, when running against a 2.6.24 kernel, the "ipcs" command just quietly goes into an infinite loop. (I didn't check where...) And strangely enough, it worked OK on some RHEL5 dumpfiles, but failed on other RHEL5 dumpfiles. For example, on a 2.6.18-157.el5 kernel it failed like this: crash> ipcs ------ Shared Memory Segments ------ SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE ipcs: zero-size memory allocation! (called from 53ffb3) which comes from the GETBUF() call ipc_search_array(). And it's not because there's no IPC segments existing, because many of the dumpfiles just show this: crash> ipcs ------ Shared Memory Segments ------ SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE In that case, you should show something like "(none allocated)" after the header. Anyway, it would be preferable if the command worked on all 2.6-era kernels, but it should at least work on all kernels from RHEL5 (2.6.18) and up. The command output violates the 80-column rule. If the data displayed by a command is fixed (i.e., without things like file pathnames) , then it should be formatted so that it fits into 80-columns: (1) So in this case, I would omit the SHM_INODE column completely. If the user actually wants to see the inode, it can be found easily enough by following the trail from the shmid_kernel structure. (2) Don't waste space in the output with the "0x" prepended to the KEY value -- if you feel that a particular column's value is not obviously decimal or hexadecimal, then indicate what it is in the command's help page. (3) Your SHMID column should probably be made larger: 12345678901234567890123456789012345678901234567890123456789012345678901234567890 crash> ipcs ------ Shared Memory Segments ------ SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE ffff81003c537390 0x00000000 32768 0 96 42 600 393216 2 ffff81003bc3a718 ffff8100230cf1d0 0x7800801c 65537 0 1 0 666 4096 0 ffff81003d4cd418 ffff8100101b35d0 0x6600800a 135036930 0 1 0 666 4096 0 ffff81003c861118 ffff81002428b790 0x7600801e 269975555 1 0 0 666 4096 0 ffff81003bc3a118 ffff810018f9a0d0 0x6a0081bd 393221 0 0 99 600 8192 0 ffff81003d919a18 ffff81003c429d90 0x71008105 135364615 0 0 99 600 8192 0 ffff81002103a418 ffff8100300256d0 0x7000801c 270303241 0 0 99 600 8192 0 ffff810031304118 crash> Also, when creating new functions, can you please put the function name on its own line? It helps when using "grep" or "vi" to quickly find the actual function if the function name is the first thing on the line. In other words, change all instances like this: static void ipc_search_array(ulong ipc_ids_p, int id, int (*fn)(ulong, int)) { to this: static void ipc_search_array(ulong ipc_ids_p, int id, int (*fn)(ulong, int)) { Also, whenever you add new entries to the offset_table[] or size_table[] arrays, please dump their values in dump_offset_table() so that their values can be seen by "help -o". It makes it much easier to debug offset-related bugs and/or kernel changes over time. And if the command is going to be "ipcs", then it should deal with all 3 SYSV IPCS facilities. I wouldn't consider taking a half-baked command with just the shared memory stats. A few other minor nits: + /* + * global data + */ + static int idr_bits; + static ulong init_flags; + static ulong hugetlbfs_f_op_addr; + static ulong shm_f_op_addr; + static ulong shm_f_op_huge_addr; + static int use_shm_f_op; + static struct total_shm_info total_shm_info; + static unsigned int page_size; + static unsigned int page_shift; Can you put these items into one global data structure, and make them available for dumping during runtime with a "help" command? For now, you can add a "hidden" option letter to cmd_ipcs() to dump them. And page_size and page_shift are redundant -- you can just use the existing PAGESIZE() and PAGESHIFT() macros. Here's my suggestion. Work on this command as a standalone extension module. It will be very easy to transform what you have in place now into an extension module -- the most work will be involved with creating your own "MYOFFSET()" and MYSIZE() macros, and storing your offsets and sizes locally. And if/when it eventually is worthy of making it a new crash command or option, then it will be mostly a matter of doing a global search-and-replace of your MYOFFSET()/MYSIZE() callers with OFFSET() and SIZE(), and putting the members/sizes into the global offset_table[] and size_table[] arrays. And in the meantime, you won't have to constantly update the patch for each subsequent crash release. Thanks, Dave

----- Original Message ----- Hello Qiao, First, I don't understand why you dropped the shmid_kernel address display from the shared memory output? I only requested that you drop the *inode* address -- because it could be ascertained from the shmid_kernel structure. In most crash commands, the relevant "head" data structure address is displayed, along with a few other key values. The data structure addresses are important for kernel debugging -- with your output, statistics are dumped, but if the user actually needed to debug the IPC facility, there would be no "starting point" kernel virtual address to work from. That being the case, the shared memory output should show the "shmid_kernel" address, the semaphore output should show the "sem_array" address, and the message queue output should show the "msg_queue" address. They should be shown in the first column of each display (similar to the SHMID_KERNEL you showed in your first patch) and the output restricted to 80 columns. Secondly, with respect to testing it against my sample set of kernels, these are the errors that I still see: (a) On these kernel versions: 2.6.9-89.ELxenU 2.6.15-1.2054_FC5 2.6.16.33-xen 2.6.18-1.2714.el5xen 2.6.18-36.el5xen 2.6.18-58.el5xen 2.6.18-152.el5xen 2.6.31 uniprocessor kernel the command fails immediatedly with this error: ipcs: cannot resolve "hugetlbfs_file_operations" (b) On *all* RHEL5 2.6.18-era kernels, the message queue display always fails like this: ------ Message Queues -------- KEY MSQID UID PERMS USED-BYTES MESSAGES ipcs: invalid structure member offset: kern_ipc_perm_id FILE: ipcs.c LINE: 899 FUNCTION: get_msg_info() (c) On this 2.6.36-0.16.rc3.git0.fc15 Fedora kernel, it shows: ------ Shared Memory Segments ------ KEY SHMID UID PERMS BYTES NATTCH STATUS ipcs: invalid kernel virtual address: 10 type: "nsproxy.ipc_ns" (d) On *all* RHEL4 2.6.9-era and SLES9 2.6.5-era kernels, the command fail like this: ------ Shared Memory Segments ------ KEY SHMID UID PERMS BYTES NATTCH STATUS ipcs: invalid structure member offset: ipc_id_ary_p FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array() or this: ------ Shared Memory Segments ------ KEY SHMID UID PERMS BYTES NATTCH STATUS (none allocated)------ Semaphore Arrays -------- KEY SEMID UID PERMS NSEMS ipcs: invalid structure member offset: ipc_id_ary_p FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array() It would be preferable if you could support all 2.6-era kernels, but if not, the command should handle them more gracefully by pre-verifying the offsets before using them, and if they are invalid, then use the option_not_supported() routine. Thanks, Dave

Hello Dave, I am going to fix the bug on some kernels. And I also need to confirm the style with you. At 2012-4-11 4:00, Dave Anderson wrote: I separate the display in two places beacuse displaying all items violates the 80-column rule. And the "-m" shows like the command system's build-in command. Actually, the reason why I change it like this is because the inode is important to my proposer. He wants to use it to identify memory area from such inode information. As you said, the information displayed by "-M" can be contained in the "-i id" output. But we have to get the address of inode one by one. I think debugger will prefer getting data at one time. From the aspect of myself, I would agree with it. But my proposer wants to use it as soon as possible as a build-in command. I am not sure how long it will take to convert an extension command to a build-in command. So I insisted sending it as a build-in command. -- -- Regards Qiao Nuohan -------------------------------------------------- Qiao Nuohan Development Dept.I Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China TEL: +86+25-86630566-8526 FUJITSU INTERNAL: 7998-8526 FAX: +86+25-83317685 EMail: qiaonuohan(a)cn.fujitsu.com -------------------------------------------------- This communication is for use by the intended recipient(s) only and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not an intended recipient of this communication, you are hereby notified that any dissemination, distribution or copying hereof is strictly prohibited. If you have received this communication in error, please notify me by reply e-mail, permanently delete this communication from your system, and destroy any hard copies you may have printed

Hello Dave, At 2012-4-11 21:58, Dave Anderson wrote: I know I must post it as an extension module at first. But I still have concern about how it will be accepted as a build-in. To what extent, it is good enough to be accepted? And I think I need to do some effort to accelerate the progress. Would you please give some suggestion? -- -- Regards Qiao Nuohan

Hello Dave, I cannot get all kernels at hand. So I have to ask you about the code. Please show me. I want to see the struct msg_queue and struct struct kern_ipc_perm. what is struct nsproxy? Or is there any symbol referring to ipc_ns? what is struct ipc_id? And what is entries in struct ipc_id or something similar to it? -- -- Regards Qiao Nuohan

----- Original Message ----- It does the same thing. But in the failure case, it appears that the task_struct.nsproxy pointer that you are using is NULL: RHEL4/linux-2.6.9: crash> ipc_ids struct ipc_ids { int size; int in_use; int max_id; short unsigned int seq; short unsigned int seq_max; struct semaphore sem; struct ipc_id *entries; } SIZE: 56 crash> Dave

At 2012/4/11 22:50, Dave Anderson Wrote: Ahh, I khow the reason now: msg_queue_q_id is not initialized!!!! I am surprised that nsproxy is NULL. Each user task belongs to a namesapce, so current_task.nsproxy should not be NULL. I guess the current task may be a kernel thread in your test. Thanks Wen Congyang

----- Original Message ----- Or perhaps just use the default "init_nsproxy", or even better, go directly to "init_ipc_ns": struct nsproxy init_nsproxy = { .count = ATOMIC_INIT(1), .uts_ns = &init_uts_ns, #if defined(CONFIG_POSIX_MQUEUE) || defined(CONFIG_SYSVIPC) .ipc_ns = &init_ipc_ns, #endif .mnt_ns = NULL, .pid_ns = &init_pid_ns, #ifdef CONFIG_NET .net_ns = &init_net, #endif }; Dave

----- Original Message ----- Thanks for doing that, as it makes it easier to build/test/debug. This version looks to cover earlier 2.6 kernels, at a minimum all RHEL4 2.6.9-era kernels now work OK. Thanks for making that work as well. I should note that I only have one 2.6.5-era SLES9 dumpfile -- but it may be a hybrid that is patched by another company, and it requires a System.map file, so it may be suspect. Anyway, it fails the shared memory display because the (first) shmid_kernel address contains bogus data: crash> ipcs -m ------ Shared Memory Segments ------ SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ipcs: invalid kernel virtual address: 400108010 type: "file.f_dentry" crash> The semaphore command shows suspect data as well: crash> ipcs -s ------ Semaphore Arrays -------- SEM_ARRAY KEY SEMID UID PERMS NSEMS 10302b127a0 0x00000000 1 0 2 62388694941697 crash> And the message queue seems to work, but it doesn't show "(none allocated)": crash> ipcs -q ------ Message Queues -------- MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES crash> In any case, because it's a somewhat strange/modified SLES9 kernel, I don't want to say that the command doesn't work with that kernel version. If any SUSE kernel users on this list can verify it, that would be helpful. (just go the top-level directory of any crash source tree, copy the ipcs.c file into the extensions sub-directory, enter "make extensions".) Anyway, here are my comments with this version. The basic "ipcs" output looks pretty good -- except for: (1) Please change the "SHM_KERNEL" header string to "SHMID_KERNEL" so that it reflects the name of the actual kernel data structure, i.e., the same way that "MSG_QUEUE" and "SEM_ARRAY" reflect the kernel's "msg_queue" and "sem_array" structure names. (2) Please remove the "0x" from the KEY columns. Continue to display the key value with a zero-filled 4-byte (integer) hexadecimal value, which is enough to make it obvious that it's not decimal. However, I really don't like the "-u" option, either used alone or in conjunction with "-i". It's confusing, redundant, and in most cases pretty much useless. For example: crash> ipcs -s ------ Semaphore Status -------- emaphore Arrays -------- SEM_ARRAY KEY SEMID UID PERMS NSEMS 1007bc33d90 0x11016565 0 0 644 2 1007bc33b90 0x71014002 32769 0 666 1 100f3348990 0xc9e03647 163842 0 644 3 crash> ipcs -su ------ Semaphore Status -------- used arrays = 3 allocated semaphores = 6 crash> Is the "-u" option really even necessary for semaphores? I can easily count the number of arrays and count the NSEMS column if I actually wanted to know how many allocated semaphores there are. But who cares? The same thing applies to the message queues: crash> ipcs -m ------ Message Queues -------- MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES 107f8ef72d0 0x23064010 0 0 600 0 0 107f80113d0 0x5106000d 32769 0 700 1068 1 105f0c43e90 0x000004d2 98306 0 666 0 0 crash> ipcs -mu ------ Messages Status -------- allocated queues = 3 used headers = 1 used space = 1068 bytes crash> I can see the USED-BYTES column, or add the USED-BYTES, and can obviously see the number of queues. But who cares? So I see nothing gained by implementing "-u" for message queues or semaphores. And when combined with "-i id", they are even more useless. However, perhaps there may be some useful extra information associated with shared memory: crash> ipcs -m ------ Shared Memory Segments ------ SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS 10007b88d90 0x01000007 688128 0 600 512000 2 10007df89d0 0x00000000 360449 0 600 393216 2 dest 10007bad7d0 0x00000000 131074 0 600 393216 2 dest 10007b832d0 0x00000000 163843 0 600 393216 2 dest 1000f6b1dd0 0x00000000 196612 0 600 393216 2 dest 10007baca90 0x00000000 229381 0 600 393216 2 dest 10007b831d0 0x00000000 262150 0 600 393216 2 dest 10007b874d0 0x00000000 294919 0 600 393216 2 dest 10007ba8690 0x00000000 327688 0 600 393216 2 dest 10007df87d0 0x00000000 393225 0 600 393216 2 dest 10007bacc90 0x00000000 425994 0 600 393216 2 dest 10007dfc6d0 0x00000000 458763 0 600 393216 2 dest 1000fbfb9d0 0x00000000 491532 0 600 393216 2 dest 10007b88b90 0x00000000 524301 0 600 393216 2 dest 10007b84990 0xf900c00c 720910 0 600 189 1 crash> ipcs -mu ----- Shared Memroy Status -------- segments allocated 15 pages allocatd 1374 pages resident 1106 pages swapped 994 swap performance attemts 0 swap performance successes 0 crash> But I note that you insist on dumping the shared memory inode somewhere, but it certainly looks out of place here: crash> ipcs -mi 688128 SHMID: 688128 ------ Shared Memroy Status -------- segments allocated 15 pages allocatd 125 pages resident 13 pages swapped 35 swap performance attemts 0 swap performance successes 0 vfs_inode 0x10010029da0 crash> But if you had taken my suggestion, and followed the tradition of "kmem -s" and "kmem -S" or "kmem -f" and "kmem -F", you could dump the statistics of each shared memory segment after the one-liner, i.e., like this: crash> ipcs -m SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810036f67490 0x00000000 65536 3369 600 393216 2 dest ffff810036f67390 0x00000000 98305 3369 600 393216 2 dest ffff810036f67690 0x00000000 131074 3369 600 393216 2 dest ffff810036f67190 0x00000000 163843 3369 600 393216 2 dest ffff8100329184d0 0x00000000 196612 3369 600 393216 2 dest ffff81003f01d790 0x00000000 229381 3369 600 393216 2 dest crash> where -M would do the same thing, but separate and follow each one-liner above with the statistics associated with it: crash> ipcs -M SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810036f67490 0x00000000 65536 3369 600 393216 2 dest (display segment statistics here) SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810036f67390 0x00000000 98305 3369 600 393216 2 dest (display segment statistics here) SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810036f67690 0x00000000 131074 3369 600 393216 2 dest (display segment statistics here) SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810036f67190 0x00000000 163843 3369 600 393216 2 dest (display segment statistics here) SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff8100329184d0 0x00000000 196612 3369 600 393216 2 dest (display segment statistics here) SHM_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff81003f01d790 0x00000000 229381 3369 600 393216 2 dest (display segment statistics here) (display cumulative shared memory statistics here) crash> But as I mentioned before, it's hard to conceive of a compelling reason to have an additional "ipcs -S" or "ipcs -Q" options. So you could simplify the invocation to allow these options: ipcs [-s | q | -[mM] ] [-i id | unique-address-of-first-column] And if by chance the "id" value is used by more than one facility, then you could dump them both. Thanks, Dave

----- Original Message ----- This is looking pretty good... A few comments: This confusion is unnecessary: crash> ipcs ffff81042fc7d9d0 ipcs: specified one of -s -m -M -q together with -i option/addr Usage: ipcs [-smMq] [-i id | addr] Enter "help ipcs" for details. crash> When using a shmid_kernel, msg_queue or sem_array address, why force the user to also enter -s, -m, -M, or -q? Those addresses are guaranteed to be unique values. And for that matter, you could drop the "-i" entirely. There may be duplicate id values among the 3 facilities, but if that's the case, you could just display all of them. That way, it could be simplified to this: Usage: ipcs [-smMq] [id | address] And you could also allow multiple id and/or address values to be entered, as is done by most of the other crash commands. And a few other aesthetic issues... The "------ Shared Memory Segments ------", "------ Semaphore Arrays --------" and "------ Message Queues --------" lines are unnecessary. It's obvious what each section is showing, because the items in the headers self-identify what facility is being dumped. The semaphore and message queue KEY values still have "0x": SEM_ARRAY KEY SEMID UID PERMS NSEMS ffff88003de05610 0x00000000 0 0 600 1 ffff88003775f250 0x00000000 98305 0 600 1 MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES ffff81042fc7d9d0 0x51008003 0 0 700 0 0 ffff81062f9f0790 0xffffffff 32769 0 600 0 0 ffff81062fe1d0d0 0x000004d2 98306 0 666 0 0 The ipcs -M output could be condensed a bit, from this: SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff81062f9f0d90 740004b7 2031616 0 600 4 0 dest PAGES ALLOCATED 1 PAGES RESIDENT 0 PAGES SWAPPED 1 SWAP PERFORMANCE ATTEMPTS 0 SWAP PERFORMANCE SUCCESSES 0 vfs_inode 0xffff81062f5ca158 to something like this: SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff81062f9f0d90 740004b7 2031616 0 600 4 0 dest PAGES ALLOCATED: 1 RESIDENT: 0 SWAPPED: 1 SWAP ATTEMPTS: 0 SUCCESSES: 0 VFS_INODE: ffff81062f5ca158 Other than those few items, I like it... Thanks, Dave

----- Original Message ----- I would do something similar to all of the commands that can accept multiple pid/task-address arguments: crash> ps 1 500 ffff88003ef20040 ps: invalid task or pid value: 500 PID PPID CPU TASK ST %MEM VSZ RSS COMM 1 0 3 ffff88003ef214c0 IN 0.1 23640 1092 init 3 2 0 ffff88003ef20040 IN 0.0 0 0 [migration/0] crash> So in your example, it would look like: crash> ipcs 0 1 ipcs: invalid id or address: 1 SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff880473b54990 00000000 0 0 666 90000 1 SEM_ARRAY KEY SEMID UID PERMS NSEMS ffff880472037990 00000000 0 0 600 1 crash> Thanks, Dave

----- Original Message ----- I believe that SLES9 kernels containing debuginfo data are built *after* the original distribution's non-debuginfo kernels are built. Therefore, they may have slight differences in their symbol values, so the correct System.map file needs to be added to the crash command line. I only have one sample SLES9 kernel (which I believe was modified by a 3rd party), and it is invoked like this: $ crash vmlinux-2.6.5-7.315-smp.debug System.map-2.6.5-7.315-smp ap17.1234028168.dmp So as I understand it: (1) the original kernel was vmlinux-2.6.5-7.315-smp (2) the vmlinux-2.6.5-7.315-smp.debug kernel was built later (3) the original System.map-2.6.5-7.315-smp file is required to deal with symbol value differences between the two kernels. I presume that what you need is a "vmlinux-2.6.5-7.97-smp.debug" kernel. But I don't know where they can be found -- even google cannot find one. Perhaps you can download the 2.6.5-era kernel sources and check them against your support for the RHEL4 2.6.9-era sources? It's probably something fairly minor. As far as this version of ipcs.c goes, the only issues I have are display problems. For some reason, if none of the facilities are being used, I see this output on RHEL4 and RHEL5 kernels: crash> ipcs SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS (none allocated)SEM_ARRAY KEY SEMID UID PERMS NSEMS (none allocated)MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES (none allocated) crash> ipcs -mqs SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS (none allocated)SEM_ARRAY KEY SEMID UID PERMS NSEMS (none allocated)MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES (none allocated) crash> On kernels that are later than 2.6.18, the output is correct, for example on this 2.6.24 kernel: crash> ipcs SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS (none allocated) SEM_ARRAY KEY SEMID UID PERMS NSEMS (none allocated) MSG_QUEUE KEY MSQID UID PERMS USED-BYTES MESSAGES (none allocated) crash> And on all kernels, the SHMID_KERNEL header is missing from "ipcs -M" if no shared memory is used: crash> ipcs -M (none allocated) crash> Lastly, the help page data needs work: (1) It still shows the output with the "------ Shared Memory Segments ------", etc., strings. (2) It still shows the "0x" in the KEY values. (3) The "ipcs -M" example shows error output. None of the crash help page examples show a command being used incorrectly, so please just show it working correctly: display specified resources in detail with an address crash> ipcs -M 1 ffff880473a28250 2 invalid id or address: 1 invalid id or address: 2 SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff880473a28250 00000002 65538 0 666 90000 1 PAGES ALLOCATED: 96 RESIDENT: 22 SWAPPED: 0 SWAP PERFORMANCE ATTEMPTS: 0 SUCCESSES: 0 VFS_INODE: ffff880470503758 Thanks, Dave

----- Original Message ----- I see that in all "ipcs -M" displays where there are a number of shared memory pages swapped out, it shows something like this: SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810026d75ed0 00000000 360452 3369 600 393216 2 dest PAGES ALLOCATED: 96 RESIDENT: 48 SWAPPED: 36 SWAP PERFORMANCE ATTEMPTS: 0 SUCCESSES: 0 VFS_INODE: ffff81003d927d58 where on every one of them, the "SWAP PERFORMANCE" values are always zero. So then I saw that your code just hardwires them to "0L": fprintf(fp, "PAGES ALLOCATED: %ld RESIDENT: %ld SWAPPED: %ld\n", (shm_info.bytes+PAGESIZE()-1) >> PAGESHIFT(), shm_info.rss, shm_info.swap); fprintf(fp, "SWAP PERFORMANCE ATTEMPTS: %ld SUCCESSES: %ld\n", 0L, 0L); fprintf(fp, "VFS_INODE: %lx\n", shm_info.shm_inode); And looking at recent kernel sources, Linux stopped using those two fields since version 2.6 -- it just returns 0 to the SHM_INFO shmctl system call. Here is relevant part of the shmctl(2) man page: SHM_INFO (Linux specific) Returns a shm_info structure whose fields contain information about system resources consumed by shared memory. This struc- ture is defined in <sys/shm.h> if the _GNU_SOURCE feature test macro is defined: struct shm_info { int used_ids; /* # of currently existing segments */ unsigned long shm_tot; /* Total number of shared memory pages */ unsigned long shm_rss; /* # of resident shared memory pages */ unsigned long shm_swp; /* # of swapped shared memory pages */ unsigned long swap_attempts; /* Unused since Linux 2.4 */ unsigned long swap_successes; /* Unused since Linux 2.4 */ }; So that line of output is completely meaningless, and should be dropped entirely. That being the case, I'm now thinking that the -M option may be unnecessary? The shared memory output could be restricted to just 2 lines: SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH STATUS ffff810026d75ed0 00000000 360452 3369 600 393216 2 dest PAGES ALLOCATED/RESIDENT/SWAPPED: 96/48/36 VFS_INODE: ffff81003d927d58 Dave

----- Original Message ----- OK, fair enough... I will put this module on the extension module web page for now. The only thing that I will modify is to change the "VFS_INODE" string to indicate just "INODE", given that it's a pointer to a "struct inode". Thanks, Dave

----- Original Message ----- OK, that's good. I will send you a link to my files off-list. And perhaps you can make your SLES files available to me so I can have a "clean" example? Thanks, Dave