Bug 89035 - top showing 0% cpu and 0% mem for all proccesses
top showing 0% cpu and 0% mem for all proccesses
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: procps (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-16 15:15 EDT by Adrian Likins
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-28 06:46:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
top -b -n1 output (7.23 KB, text/plain)
2003-04-16 15:24 EDT, Adrian Likins
no flags Details

  None (edit)
Description Adrian Likins 2003-04-16 15:15:39 EDT
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 15:24:35 EDT
Created attachment 91154 [details]
top -b -n1 output
Comment 2 Kjetil T. Homme 2003-04-21 20:39:24 EDT
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 10:49:07 EDT
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 06:36:02 EDT
/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 06:46:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.