--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-19-2012, 01:11 PM
Dave Anderson
add a new command: ipcs
----- Original Message -----
> At 2012-4-19 3:33, Dave Anderson wrote:
> > 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.
>
> Hello Dave,
>
> I am not so sure about the output style, so I need to confirm it.
>
> With multiple id/address, the output below is OK?
>
> crash> ipcs 0 1
> VALUE 0:
> 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
>
> VALUE 1: (not found)
I would do something similar to all of the commands that can accept
multiple pid/task-address arguments:
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-23-2012, 07:42 AM
qiaonuohan
add a new command: ipcs
Hello Dave,
I have modified the output of ipcs, please see the attachment. About the
bugs of SLES, I tried to install a SLES9(2.6.5-7.97-smp) to locate the
problems. But I failed to get debuginfo. I will continue searching it.
It will be helpful, if you have some information about it.
At 2012-4-19 21:11, Dave Anderson wrote:
----- Original Message -----
At 2012-4-19 3:33, Dave Anderson wrote:
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.
Hello Dave,
I am not so sure about the output style, so I need to confirm it.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
--
Regards
Qiao Nuohan
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-23-2012, 07:27 PM
Dave Anderson
add a new command: ipcs
----- Original Message -----
> Hello Dave,
>
> I have modified the output of ipcs, please see the attachment. About the
> bugs of SLES, I tried to install a SLES9(2.6.5-7.97-smp) to locate the
> problems. But I failed to get debuginfo. I will continue searching it.
> It will be helpful, if you have some information about it.
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:
(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:
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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-24-2012, 08:56 AM
qiaonuohan
add a new command: ipcs
Hello Dave,
I am still locating problems of the SLES9. Until now, nothing was
found, and I will continue checking the difference. Once I fix them, I
will send the patch. The attachment only fixes the problem of output.
--
--
Regards
Qiao Nuohan
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-24-2012, 03:41 PM
Dave Anderson
add a new command: ipcs
----- Original Message -----
> Hello Dave,
>
> I am still locating problems of the SLES9. Until now, nothing was
> found, and I will continue checking the difference. Once I fix them,
> I
> will send the patch. The attachment only fixes the problem of output.
>
> --
> --
> Regards
> Qiao Nuohan
I see that in all "ipcs -M" displays where there are a number of
shared memory pages swapped out, it shows something like this:
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:
I keep the -M option. I think it is more clear if "ipcs -m" outputs only
one line for each shared memory and it gets more similarity with "ipcs
-s" and "ipcs -q". Actually, there are a lot of information about shared
memory like below.
Maybe later, we will need not only PAGES and VFS_INODE. We may need some
information about time. So keeping -M option is necessary.
P.S.
the two useless item has been removed, please refer to the attachment.
--
--
Regards
Qiao Nuohan
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-25-2012, 03:59 PM
Dave Anderson
add a new command: ipcs
----- Original Message -----
> At 2012-4-24 23:41, Dave Anderson wrote:
> > 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
>
> I keep the -M option. I think it is more clear if "ipcs -m" outputs only
> one line for each shared memory and it gets more similarity with "ipcs
> -s" and "ipcs -q". Actually, there are a lot of information about shared
> memory like below.
>
> [root@localhost ipcs]# ipcs -i 0 -m
>
> Shared memory Segment shmid=0
> uid=0 gid=0 cuid=0 cgid=0
> mode=0666 access_perms=0666
> bytes=90000 lpid=30412 cpid=30412 nattch=0
> att_time=Thu Apr 19 10:55:34 2012
> det_time=Fri Apr 20 11:39:06 2012
> change_time=Thu Apr 19 10:55:34 2012
>
> Maybe later, we will need not only PAGES and VFS_INODE. We may need some
> information about time. So keeping -M option is necessary.
OK, fair enough...
> P.S. the two useless item has been removed, please refer to the
> attachment.
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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-26-2012, 01:45 AM
qiaonuohan
add a new command: ipcs
At 2012-4-25 23:59, Dave Anderson wrote:
I will put this module on the extension module web page for now.
Hello Dave,
I rebuild a new SLES kernel, and try to figure out the problem you
pointed out. The version I used is 2.6.5-7.308-smp. And then I tried
ipcs module, it seems ipcs command works well, like below.
The problems didn't show on my kernel. So I think the problems do not
come from the edition of SLES, but the modification of the third party.
So I think is it possible to get the debuginfo and core you used to
test.
--
--
Regards
Qiao Nuohan
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
04-26-2012, 12:48 PM
Dave Anderson
add a new command: ipcs
----- Original Message -----
> At 2012-4-25 23:59, Dave Anderson wrote:
> > I will put this module on the extension module web page for now.
>
> Hello Dave,
>
> I rebuild a new SLES kernel, and try to figure out the problem you
> pointed out. The version I used is 2.6.5-7.308-smp. And then I tried
> ipcs module, it seems ipcs command works well, like below.
>
> crash> ipcs -M
> SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH
> STATUS
> 10027a816a0 00000000 1605632 0 666 90000 1
> PAGES ALLOCATED/RESIDENT/SWAPPED: 22/1/0
> VFS_INODE: 100268d38e8
>
> SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH
> STATUS
> 10027a813a0 00000001 1638401 0 666 90000 1
> PAGES ALLOCATED/RESIDENT/SWAPPED: 22/0/0
> VFS_INODE: 10025e2a168
>
> SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH
> STATUS
> 10027a814a0 00000002 1671170 0 666 90000 1
> PAGES ALLOCATED/RESIDENT/SWAPPED: 22/1/0
> VFS_INODE: 10025e2a4e8
>
> crash> ipcs
> SHMID_KERNEL KEY SHMID UID PERMS BYTES NATTCH
> STATUS
> 10027a816a0 00000000 1605632 0 666 90000 1
> 10027a813a0 00000001 1638401 0 666 90000 1
> 10027a814a0 00000002 1671170 0 666 90000 1
>
> SEM_ARRAY KEY SEMID UID PERMS NSEMS
> 100020787a0 00000000 0 0 666 1
> 100020786a0 00000001 32769 0 666 1
> 100020782a0 00000002 65538 0 666 1
>
> MSG_QUEUE KEY MSQID UID PERMS USED-BYTES
> MESSAGES
> 1002f7cd1a0 00001f58 0 0 600 0 0
>
> The problems didn't show on my kernel. So I think the problems do not
> come from the edition of SLES, but the modification of the third party.
> So I think is it possible to get the debuginfo and core you used to
> test.
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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
add a new command: ipcs
