Bug 89035 - top showing 0% cpu and 0% mem for all proccesses
Summary: top showing 0% cpu and 0% mem for all proccesses
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: procps
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-16 19:15 UTC by Adrian Likins
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-04-28 10:46:05 UTC
Embargoed:


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

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.



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