FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 04-19-2012, 05:47 AM
qiaonuohan
 
Default add a new command: ipcs

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)

--
--
Regards
Qiao Nuohan



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-19-2012, 01:11 PM
Dave Anderson
 
Default 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> 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





--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-23-2012, 07:42 AM
qiaonuohan
 
Default 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.

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





--
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
 
Old 04-23-2012, 07:27 PM
Dave Anderson
 
Default 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:

$ 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


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-24-2012, 08:56 AM
qiaonuohan
 
Default 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
 
Old 04-24-2012, 03:41 PM
Dave Anderson
 
Default 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:

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
",
(shm_info.bytes+PAGESIZE()-1) >> PAGESHIFT(),
shm_info.rss, shm_info.swap);
fprintf(fp, "SWAP PERFORMANCE ATTEMPTS: %ld SUCCESSES: %ld
",
0L, 0L);
fprintf(fp, "VFS_INODE: %lx
", 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

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-25-2012, 01:33 AM
qiaonuohan
 
Default add a new command: ipcs

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.


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
 
Old 04-25-2012, 03:59 PM
Dave Anderson
 
Default 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
 
Old 04-26-2012, 01:45 AM
qiaonuohan
 
Default 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.

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.

--
--
Regards
Qiao Nuohan



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 04-26-2012, 12:48 PM
Dave Anderson
 
Default 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
 

Thread Tools




All times are GMT. The time now is 03:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org