[kernel] bug#155: top reports 50% idle on 2-way

X-PA-RISC Linux-PR-Message: report 155
X-PA-RISC Linux-PR-Package: kernel
X-Loop: daniel_frazier@hp.com
Received: via spool by bugs@bugs.parisc-linux.org id=B.10068124425890
          (code B ref -1); Mon, 26 Nov 2001 22:18:01 GMT
Date: Mon, 26 Nov 2001 15:02:58 -0700
From: Grant Grundler <grundler@puffin.external.hp.com>
Message-Id: <200111262202.PAA10773@puffin.external.hp.com>
To: submit@bugs.parisc-linux.org

Package: kernel
Version: 2.4.14-pa11

On 2-way (64-bit kernel) a500, "top" reports:

 13:53:16 up 14:20,  2 users,  load average: 0.00, 0.00, 0.00
20 processes: 19 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   0.0% user,  50.0% system,   0.0% nice,  50.0% idle
Mem:   3782308K total,  1179876K used,  2602432K free,    52328K buffers
Swap:   525288K total,        0K used,   525288K free,   566336K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
11733 grundler  17   0  1116 1120   896 R     0.5  0.0   0:00 top
    1 root       8   0   648  652   552 S     0.0  0.0   0:05 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root      18  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    4 root      18  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU1
    5 root       9   0     0    0     0 SW    0.0  0.0   0:00 kswapd
    6 root       9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    7 root       9   0     0    0     0 SW    0.0  0.0   0:00 kupdated
   14 root      -1 -20     0    0     0 SW<   0.0  0.0   0:00 mdrecoveryd
...

Nothing is running. Should be reading 0 system, 100% idle.

Matthew Wilcox saw a similar thing on a 4-way system:
  14:46:09 up 1 day, 23:36,  2 users,  load average: 6.03, 6.02, 6.00
42 processes: 35 sleeping, 7 running, 0 zombie, 0 stopped
CPU states:  74.6% user,   0.4% system,   0.0% nice,  25.0% idle
Mem:    752864K total,   531964K used,   220900K free,    32844K buffers
Swap:  2097136K total,        0K used,  2097136K free,   136368K cached

My first guess is we are possibly chasing several bugs:
1) System time isn't being accounted properly.
2) top is summarizing N-1 CPU data. Either CPU 0 is getting
  skipped or the last CPU's data isn't getting copied out to top.
3) a 32<->64 bit syscall wrapper is broken.