Re: [Crash-utility] [PATCH] add a new command: ipcs

----- 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