pcp
[Top] [All Lists]

Re: *.out.bad files for cases 109,113,114,131,154,159,187,189

To: "Zhang, Sonic" <sonic.zhang@xxxxxxxxx>
Subject: Re: *.out.bad files for cases 109,113,114,131,154,159,187,189
From: kenmcd@xxxxxxxxxxxxxxxxx
Date: Wed, 1 Jan 2003 21:17:32 +1100 (EST)
Cc: "PCP (E-mail)" <pcp@xxxxxxxxxxx>
In-reply-to: <957BD1C2BF3CD411B6C500A0C944CA2602AFA57C@pdsmsx32.pd.intel.com>
Reply-to: kenmcd@xxxxxxxxxxxxxxxxx
Sender: pcp-bounce@xxxxxxxxxxx
On Fri, 27 Dec 2002, Zhang, Sonic wrote:

> [more QA failures]

109
        src-oss/pmclient is not producing correct results ... same
        cause as the failure for 053 I commented on in an earlier
        response.

113
        You'll need a newer PCP installation with the metric
        filesys.avail ... the QA test will use this in preference to
        filesys.free when both are available.  The mismatch is caused
        because some filesystems on some Linux systems report different
        numbers of "free" space in the filesystem depending on the user's
        id (root gets more!).

114
        You'll need a newer PCP installation with the metric
        proc.psinfo.wchan_s supported from the Linux PMDA.

131
        Looks like $PCPQA_FAR_PMCD was not that far away!  I've changed
        the time constant from 1msec to 10usec ... see the attached
        modified 131.

154
        This test assumed the cisco PMDA had been installed at some
        point in the past.  I've re-worked the logic ... please try the
        modified 154 that I've attached.

159
        I will have to think about this one, it requires you to have
        access to a Cisco router to test out the cisco PMDA ... the
        required input for the PMDA installation is almost impossible
        to capture in any simple parameterization ... do you want/need
        to test the cisco PMDA?  If so, could you please run the Install
        script in /var/pcp/pmdas/cisco as root and send me the transcript
        of the installation dialog.

187
        This one has a residual reference to hostnames within SGI ...
        fixed as per the attached new 187 script.

189

        This is the mysterious "pmie leaves defunct processes" problem
        that has been recently reported and we cannot reproduce ... so
        far this is the only failure that really looks like a potential
        PCP s/w problem (as opposed to a setup, installation, or QA
        engineering problem).

        Although on closer inspection this looks more like the kernel
        is having a hard time keeping up rather than pmie, as the pids
        of the defunct processes are changing at each observation.

        I've modified the test slightly to include the final check
        to see if all the defunct processes to eventually go away ...
        this is attached and I'd appreciate seeing 189.out.bad from
        this (it will still fail, but should give me some more information).

Attachment: 154
Description: 154

Attachment: 131
Description: 131

Attachment: 187
Description: 187

Attachment: 189
Description: 189

<Prev in Thread] Current Thread [Next in Thread>
  • Re: *.out.bad files for cases 109,113,114,131,154,159,187,189, kenmcd <=