Bug 89035

Summary: top showing 0% cpu and 0% mem for all proccesses
Product: [Retired] Red Hat Linux Reporter: Adrian Likins <alikins>
Component: procpsAssignee: Alexander Larsson <alexl>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: kjetilho
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-28 10:46:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
top -b -n1 output none

Description Adrian Likins 2003-04-16 19:15:39 UTC
Description of problem:

Linux sludge.devel.redhat.com 2.4.20-2.49 #1 Mon Feb 17 11:29:55 EST 2003 i686
i686 i386 GNU/Linux

[root@sludge test]# rpm -q procps
procps-2.0.11-6
[root@sludge test]# rpm -q kernel
kernel-2.4.20-2.14
kernel-2.4.20-2.24
kernel-2.4.20-2.47.1
kernel-2.4.20-2.49
kernel-2.4.20-8

Not exactly sure whats going, but it appears top is showing 
no processes as using anything more than 0.0% cpu, and only
a few processes as taking more than 0% mem...

top -b -n 1 output attached, but a sample chunk...

    1 root      15   0    92   56    40 S     0.0  0.0   0:00   0 init
    2 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 keventd
    3 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kapmd
    4 root      RT   0     0    0     0 SW    0.0  0.0   0:00   0 kdog/0
    5 root      34  19     0    0     0 SWN   0.0  0.0   0:00   0 ksoftirqd_CPU
    8 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 bdflush
    6 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kswapd
    7 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kscand
    9 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kupdated
   10 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 mdrecoveryd
   14 root      15   0     0    0     0 DW    0.0  0.0   0:00   0 kjournald
   72 root      25   0     0    0     0 SW    0.0  0.0   0:00   0 khubd
 1725 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 kjournald


Thats supposedly sorted by CPU useage, on a machine with a couple of cpu
using things running...

This seems to have started happening recently, perhaps after my
last reboot. Offhand I'm not sure if I changed kernels at the time,
but thats definately possible...

Comment 1 Adrian Likins 2003-04-16 19:24:35 UTC
Created attachment 91154 [details]
top -b -n1 output

Comment 2 Kjetil T. Homme 2003-04-22 00:39:24 UTC
same thing has happened to me, kernel 2.4.20-2.48smp and glibc-2.3.2-27.9

Comment 3 Alexander Larsson 2003-04-24 14:49:07 UTC
Its very strange that all TIME field are zero. That would seem to indicate that
both utime and stime are zero. Can you paste in /proc/$pid/stat for some process
when this happens?

Also, are you using LD_ASSUME_KERNEL or anything strange thread-related?


Comment 4 Kjetil T. Homme 2003-04-25 10:36:02 UTC
/proc/pid/stat works:

11278 (slurpcpu) R 11257 11278 11102 34834 11281 0 20 0 60 0 1180 0 0 0 25 0 0 0
84160728 1380352 58 4294967295 134512640 134513592 3221218944 3221218864
134513412 0 0 0 0 0 0 0 17 0 1180 0 0 0

11278 (slurpcpu) R 11257 11278 11102 34834 11283 0 20 0 60 0 1538 0 0 0 25 0 0 0
84160728 1380352 58 4294967295 134512640 134513592 3221218944 3221218864
134513412 0 0 0 0 0 0 0 17 0 1538 0 0 0

11278 (slurpcpu) R 11257 11278 11102 34834 11285 0 20 0 60 0 2047 0 0 0 25 0 0 0
84160728 1380352 58 4294967295 134512640 134513592 3221218944 3221218864
134513412 0 0 0 0 0 0 0 17 0 2047 0 0 0

I do use LD_ASSUME_KERNEL on threaded applications which need it (Mozilla,
Python etc.), but not on the system as a whole.

Comment 5 Alexander Larsson 2003-04-28 10:46:05 UTC
Ah, I see what's happening. Thats not the final RHL9 kernel. It doesn't have the
 &P->rtprio, &P->policy, fields in /proc/$pid/stat, so the fields added to stat
in that kernel version are incompatible. You need to upgrade the kernel.