From jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net  Thu Dec 18 20:59:59 2003
Return-Path: <jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 12F9516A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 Dec 2003 20:59:59 -0800 (PST)
Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 6BFB043D31
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 Dec 2003 20:59:56 -0800 (PST)
	(envelope-from jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net)
Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (localhost.pacbell.net [127.0.0.1])
	by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.9p2/8.12.9) with ESMTP id hBJ3ZkJ7003033
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 18 Dec 2003 19:35:46 -0800 (PST)
	(envelope-from jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net)
Received: (from jin@localhost)
	by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.9p2/8.12.9/Submit) id hBJ3ZkGl003032;
	Thu, 18 Dec 2003 19:35:46 -0800 (PST)
	(envelope-from jin)
Message-Id: <200312190335.hBJ3ZkGl003032@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Date: Thu, 18 Dec 2003 19:35:46 -0800 (PST)
From: "Jin Guojun[VFF]" <jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Reply-To: "Jin Guojun[VFF]" <jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: vmstat/iostat/top all fail to report CPU usage
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         60385
>Category:       bin
>Synopsis:       vmstat/iostat/top all fail to report CPU usage (still in 5.3R)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Dec 18 21:00:31 PST 2003
>Closed-Date:    Mon Jul 16 12:54:27 GMT 2007
>Last-Modified:  Mon Jul 16 12:54:27 GMT 2007
>Originator:     Jin Guojun[VFF]
>Release:        FreeBSD 5.2-RC1
>Organization:
>Environment:
System: FreeBSD 5.2-RC1


	FreeBSD 5.2-RC1 #0: Sun Dec  7 22:15:14 GMT 2003
    root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a2c000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a2c21c.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Pentium III/Pentium III Xeon/Celeron (463.55-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
  Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 536858624 (511 MB)
avail memory = 511819776 (488 MB)
MPTable: <OEM00000 PROD00000000>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  1
 cpu1 (AP): APIC ID:  0
ioapic0: Assuming intbase of 0
ioapic0 <Version 1.1> irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0: <math processor> on motherboard
npx0: INT 16 interface
acpi0: <ASUS   P2B-DS  > on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 7 entries at 0xc00f0d20
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000

>Description:
	Regardless the system is idle or not, vmstat/iostat/top
	all cannot report where CPU goes. Top shows everything is 0.0%.
	Not clear if this is bin problem or kernel problem,
	but assume it is either the wrong structure or API issue.

# top
last pid:  2045;  load averages:  0.00,  0.00,  0.00    up 0+03:52:37  20:41:07
18 processes:  2 running, 16 sleeping
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Mem: 25M Active, 195M Inact, 73M Wired, 60M Buf, 202M Free
Swap: 1024M Total, 1024M Free

  PID USERNAME PRI NICE   SIZE    RES STATE  C   TIME   WCPU    CPU COMMAND
  458 root      96    0  6220K  2884K RUN    1   0:01  0.00%  0.00% sshd
  388 root      96    0  3488K  2464K select 1   0:01  0.00%  0.00% sshd
  394 root      96    0  3528K  2700K select 0   0:00  0.00%  0.00% sendmail
  461 root      20    0  2364K  1896K pause  1   0:00  0.00%  0.00% csh
  411 root       8    0  1336K  1016K nanslp 0   0:00  0.00%  0.00% cron
  242 root      96    0  1312K   860K select 0   0:00  0.00%  0.00% syslogd
  341 root      96    0  1236K   752K select 0   0:00  0.00%  0.00% usbd
  397 smmsp     20    0  3404K  2648K pause  0   0:00  0.00%  0.00% sendmail
 2045 root      96    0  2208K  1452K CPU1   1   0:00  0.00%  0.00% top
  450 root       5    0  1276K   928K ttyin  0   0:00  0.00%  0.00% getty

devp# iostat 1
      tty             ad0              fd0             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   43 16.53   4  0.07   0.00   0  0.00   2  0  1  0 96
   0  180  0.00   0  0.00   0.00   0  0.00   0  0  0  0  0
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0  0
   0   59  0.00   0  0.00   0.00   0  0.00   0  0  0  0  0

devp#  vmstat 1
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr ad0 fd0   in   sy  cs us sy id
 0 0 0   28056 189588   21   0   0   0  28   0   0   0  258    0 491  2  1 96
 0 0 0   28056 189588    4   0   0   0   4   0   0   0  207    0 361  0  0  0
 0 0 0   28056 189588    0   0   0   0   0   0   0   0  207    0 358  0  0  0
^C

>How-To-Repeat:
	run vmstat, iostat and top to see the problem.

>Fix:

	


>Release-Note:
>Audit-Trail:

From: Friedemann Becker <Friedemann.Becker@web.de>
To: freebsd-gnats-submit@FreeBSD.org,
	jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
Date: Wed, 14 Jan 2004 13:56:22 +0100

 I can't reproduce, please elaborate on that.
 Maybe it's an SMP only problem?
 
 

From: "Julien Gabel" <jpeg@thilelli.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
Date: Sun, 18 Apr 2004 19:54:23 +0200 (CEST)

 Hello,
 
 I can reproduce the problem here:
 
  - FreeBSD 5.2.1-RELEASE-p4 #0: Wed Apr 14 22:06:33 CEST 2004 i386;
 
  - Single processor, Hyperthreading *enable*;
 
  - dmesg:
    Preloaded elf kernel "/boot/kernel/kernel" at 0xc0aa6000.
    Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0aa626c.
    ACPI APIC Table: <PTLTD          APIC  >
    Timecounter "i8254" frequency 1193182 Hz quality 0
    CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU)
      Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
      Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,
       MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,
       HTT,TM,PBE>
      Hyperthreading: 2 logical CPUs
    real memory  = 1071579136 (1021 MB)
    avail memory = 1031471104 (983 MB)
    FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
     cpu0 (BSP): APIC ID:  0
     cpu1 (AP): APIC ID:  1
    ioapic0 <Version 1.1> irqs 0-23 on motherboard
    Pentium Pro MTRR support enabled
    npx0: [FAST]
    npx0: <math processor> on motherboard
    npx0: INT 16 interface
    acpi0: <PTLTD    RSDT  > on motherboard
    pcibios: BIOS version 2.10
    Using $PIR table, 6 entries at 0xc00fdf60
    acpi0: Power Button (fixed)
    Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
 
  - vmstat/iostat/top all fail to report CPU usage;
 
  - This seems to be an SMP specific problem since I have an other machine
    with an identical level release, but which a single processor *without*
    Hyperthreading.
 
 Note: I think this problem may be related to Problem Report bin/30310.
 -- 
 -jpeg.

From: Thomas Novin <thnov@xyz.pp.se>
To: freebsd-gnats-submit@FreeBSD.org,
	jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
Date: Sun, 13 Jun 2004 21:43:41 +0200

 This is reproducible on my single-cpu system.
 
 FreeBSD 5.2.1-RELEASE-p8 #1: Mon Jun  7 22:03:12 CEST 2004
      root@mail:/usr/obj/usr/src/sys/VER_5
 Preloaded elf kernel "/boot/kernel/kernel" at 0xc0841000.
 Timecounter "i8254" frequency 1193182 Hz quality 0
 CPU: Intel(R) Pentium(R) III CPU             1200MHz (1196.22-MHz 686-class 
 CPU)
    Origin = "GenuineIntel"  Id = 0x6b1  Stepping = 1
    Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
 real memory  = 536870912 (512 MB)
 avail memory = 511840256 (488 MB)
 Pentium Pro MTRR support enabled
 npx0: [FAST]
 npx0: <math processor> on motherboard
 npx0: INT 16 interface
 
 # vmstat 1
   procs      memory      page                    disks     faults      cpu
   r b w     avm    fre  flt  re  pi  po  fr  sr tw0 fd0   in   sy  cs us sy id
   0 0 0  673612  36184   10   0   0   0   6   1   0   0  202    0 253  0  0  0
   1 0 0  673612  36184    5   0   0   0   5   0   0   0  213    0 264  0  0  0
   1 0 0  673612  36184    0   0   0   0   0   0   0   0  208    0 256  0  0  0
 
 This is however the only 5.2.1 machine I have that has this problem. I also 
 have a few SMP machines which doesn't have this problem, cpu usage 
 reporting works just fine. This system used to have a SMP-kernel since I 
 install the same kernel on all machines but after noting this problem and 
 reading this problem report I recompiled it without SMP/APIC but the 
 problem remained.
 

From: Thomas Novin <thnov@xyz.pp.se>
To: freebsd-gnats-submit@FreeBSD.org,
	jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
Date: Tue, 29 Jun 2004 23:51:43 +0200

 Is there any additional info anyone would like to have regarding this 
 issue? I'd love to see this get solved and I gladly would help as much 
 as I can.
 
 -- 
 Thomas Novin  thnov@xyz.pp.se  http://xyz.pp.se/~thnov/
 V: +46 (0)431 445400  F: +46 (0)431 445410  GSM: +46 (0)730 667425
 -- 
 

From: Thomas Novin <thnov@xyz.pp.se>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
Date: Mon, 08 Nov 2004 16:34:12 +0100

 There is no change on this issue after upgrading to FreeBSD 5.3-RELE.
 
 
 --
 Thomas Novin =B7 thnov@xyz.pp.se =B7 http://xyz.pp.se/~thnov/
 V: +46 (0)431 445400 =B7 F: +46 (0)431 445410 =B7 GSM: +46 (0)730 667425=20
 

From: Thomas Novin <thnov@xyz.pp.se>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
  (still in 5.3R)
Date: Fri, 12 Nov 2004 14:32:52 +0100

 Some new observations I've done:
 
 Same problem on another machine (also 5.3R) w/ Tyan Thunder S2510 
 motherboard, singel CPU system. Moved the disk to another machine with Tyan 
 Thunder 2518 motherboard and dual CPU and here vmstat/iostat/top works OK.
 
 Thomas
 
 

From: Jeff Behl <jbehl@fastclick.com>
To: freebsd-gnats-submit@FreeBSD.org,
	jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still
 in 5.3R)
Date: Sun, 14 Nov 2004 23:41:08 -0800

 this problem manifests itself after about 5 days on a dual proc amd64 
 system running 5.3R.  i'd give the dmesg but it's been overwritten, but 
 the system is a ibm eseries server.
 
 any ideas how to fix/get around this would be greatly appreciated as 
 it's hampering stress testing on this system vs a redhat aes server (boo!)

From: Dima Dorfman <dd@freebsd.org>
To: freebsd-gnats-submit@freebsd.org
Cc: Jeff Behl <jbehl@fastclick.com>, Thomas Novin <thnov@xyz.pp.se>
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still in 5.3R)
Date: Fri, 19 Nov 2004 00:22:01 +0000

 Based on Thomas's report that the same system disk works in another
 machine, this sounds like a problem with support for certain kind of
 hardware. I can't reproduce it on any of my machines here. If you have
 a system that has this problem, the following output would be useful
 to help diagnose this.
 
 These sysctls:
 
   # sysctl kern.clockrate
   # sysctl kern.timecounter
   # sysctl vm.loadavg
 
 dmesg information about the timecounters:
 
   # fgrep Timecounter /var/run/dmesg.boot
 
 Also, a few samples of this sysctl at 5 second intervals:
 
   # sysctl kern.cp_time
 
 And just as a sanity check, try something like this:
 
   # /usr/bin/time ls -R > /dev/null
 
 and see whether the output is non-zero (but make sure that the command
 takes long enough to accrue some time!).
 
 uname output and a summary of the hardware in question (i386/amd64,
 SMP, HT) would be helpful to go with the above output.

From: Thomas Novin <thnov@xyz.pp.se>
To: Dima Dorfman <dd@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
  (still in 5.3R)
Date: Fri, 19 Nov 2004 08:33:20 +0100

 # sysctl kern.clockrate
 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 }
 # sysctl kern.timecounter
 kern.timecounter.stepwarnings: 0
 kern.timecounter.nbinuptime: 1600002999
 kern.timecounter.nnanouptime: 4200
 kern.timecounter.nmicrouptime: 2047672
 kern.timecounter.nbintime: 518528232
 kern.timecounter.nnanotime: 146335
 kern.timecounter.nmicrotime: 518381897
 kern.timecounter.ngetbinuptime: 0
 kern.timecounter.ngetnanouptime: 16793514
 kern.timecounter.ngetmicrouptime: 558311521
 kern.timecounter.ngetbintime: 0
 kern.timecounter.ngetnanotime: 0
 kern.timecounter.ngetmicrotime: 90967573
 kern.timecounter.nsetclock: 14
 kern.timecounter.hardware: TSC
 kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)
 kern.timecounter.tick: 1
 # sysctl vm.loadavg
 vm.loadavg: { 2.13 1.78 1.33 }
 # fgrep Timecounter /var/run/dmesg.boot
 Timecounter "i8254" frequency 1193182 Hz quality 0
 Timecounter "TSC" frequency 1196221361 Hz quality 800
 Timecounters tick every 10.000 msec
 Timecounter "i8254" frequency 1193182 Hz quality 0
 Timecounter "TSC" frequency 1196219615 Hz quality 800
 Timecounters tick every 10.000 msec
 # while [ 1 ] ; do sysctl kern.cp_time && sleep 5 ; done
 kern.cp_time: 0 0 0 0 0
 kern.cp_time: 0 0 0 0 0
 kern.cp_time: 0 0 0 0 0
 kern.cp_time: 0 0 0 0 0
 kern.cp_time: 0 0 0 0 0
 kern.cp_time: 0 0 0 0 0
 # cd /usr/local/
 # /usr/bin/time ls -R > /dev/null
          3.11 real         0.00 user         0.19 sys
 
 # uname -a
 FreeBSD hawk.xxx.net 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Mon Nov  8 
 15:06:10 CET 2004     root@hawk.xxx.net:/usr/obj/usr/src/sys/VER_53  i386
 
 One system is Tyan S2510 (or S2518) motherboard. 1 x 1,2GHz PIII CPU.
 Also noted on another system with Tyan Thunder S2510 motherboard. 1,13GHz 
 PIII CPU.
 
 These systems have reported CPU usage without problem on 4.x. 
 

From: Dima Dorfman <dd@freebsd.org>
To: Thomas Novin <thnov@xyz.pp.se>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still in 5.3R)
Date: Fri, 19 Nov 2004 08:41:51 +0000

 Thomas Novin <thnov@xyz.pp.se> wrote:
 > kern.cp_time: 0 0 0 0 0
 > # cd /usr/local/
 > # /usr/bin/time ls -R > /dev/null
 >         3.11 real         0.00 user         0.19 sys
 
 Okay, so the timecounter is sane (no surprise there) but statclock
 isn't firing (no surprise there either). bde just told me about PR
 17800, which sports the same symptoms and includes a patch. Can you
 try that? It might be slightly incomplete, but it definitely sounds
 like that bug could be the culprit.
 
 Dima.

From: Thomas Novin <thnov@xyz.pp.se>
To: Dima Dorfman <dd@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage
  (still in 5.3R)
Date: Fri, 19 Nov 2004 10:56:52 +0100

 At 09:41 2004-11-19, you wrote:
 >Okay, so the timecounter is sane (no surprise there) but statclock
 >isn't firing (no surprise there either). bde just told me about PR
 >17800, which sports the same symptoms and includes a patch. Can you
 >try that? It might be slightly incomplete, but it definitely sounds
 
 /usr/src# patch -p0 < patch
 Hmm...  Looks like a unified diff to me...
 (Patch is indented 1 space.)
 The text leading up to this was:
 --------------------------
 | --- sys/i386/isa/clock.c.old    Thu Nov 18 11:18:59 2004
 | +++ sys/i386/isa/clock.c        Thu Nov 18 11:12:10 2004
 --------------------------
 Patching file sys/i386/isa/clock.c using Plan A...
 Hunk #1 failed at 946.
 1 out of 1 hunks failed--saving rejects to sys/i386/isa/clock.c.rej
 done
 
 Hmm...however I manually edited the file and added 'rtcin(RTC_INTR); /*=20
 clear any pending interrupt */' between 'writertc(RTC_STATUSB,=20
 RTCSB_24HR);' and '/* Don't bother enabling the statistics clock. */'
 
 Rebuilt kernel, rebooted and voila!
 # sysctl kern.clockrate
 kern.clockrate: { hz =3D 100, tick =3D 10000, profhz =3D 1024, stathz =3D=
  128 }
 # sysctl kern.timecounter
 kern.timecounter.stepwarnings: 0
 kern.timecounter.nbinuptime: 787111
 kern.timecounter.nnanouptime: 0
 kern.timecounter.nmicrouptime: 1207
 kern.timecounter.nbintime: 394785
 kern.timecounter.nnanotime: 85
 kern.timecounter.nmicrotime: 394700
 kern.timecounter.ngetbinuptime: 0
 kern.timecounter.ngetnanouptime: 102
 kern.timecounter.ngetmicrouptime: 160555
 kern.timecounter.ngetbintime: 0
 kern.timecounter.ngetnanotime: 0
 kern.timecounter.ngetmicrotime: 15508
 kern.timecounter.nsetclock: 4
 kern.timecounter.hardware: TSC
 kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000)
 kern.timecounter.tick: 1
 # sysctl vm.loadavg
 vm.loadavg: { 4.27 2.64 1.15 }
 #  while [ 1 ] ; do sysctl kern.cp_time && sleep 5 ; done
 kern.cp_time: 16199 206 4076 395 312
 kern.cp_time: 16766 206 4147 399 312
 kern.cp_time: 17364 206 4185 404 312
 kern.cp_time: 17961 206 4230 404 312
 kern.cp_time: 18514 206 4307 415 312
 
 # vmstat 1
   procs      memory      page                   disk   faults      cpu
   r b w     avm    fre  flt  re  pi  po  fr  sr tw0   in   sy  cs us sy id
   1 0 0  963436 154208 5045   1   2   1 1161   0 2613  734 6931 1447 72 19 =
  9
   0 0 0  963444 154284 2723   0   0   0 273   0  13  603 3355 990 20 11 69
   0 0 0  963640 153924 2792   0   0   0 218   0  15  510 3259 874 22  8 71
   1 0 0  963640 154228  195   0   0  17  84   0 170  759 1336 1220  2 12 87
   0 0 0  964024 153776 5830   0   0   0 641   0  18  524 4363 981 39 12 49
 
 # top
 
 last pid:  1581;  load=20
 averages:  2.34,  2.74,  1.47=20
                    up 0+00:06:08  10:46:57
 140 processes: 2 running, 138 sleeping
 CPU states: 28.6% user,  0.0% nice, 11.8% system,  0.0% interrupt, 59.5%=
  idle
 Mem: 393M Active, 318M Inact, 141M Wired, 111M Buf, 145M Free
 Swap: 1000M Total, 1000M Free
 
 Cool... It's working again! Thanks for the help.
 
 Thomas
 
 
 
 --
 Thomas Novin =B7 thnov@xyz.pp.se =B7 http://xyz.pp.se/~thnov/
 V: +46 (0)431 445400 =B7 F: +46 (0)431 445410 =B7 GSM: +46 (0)730 667425=20
 

From: Jeff Behl <jbehl@fastclick.com>
To: Dima Dorfman <dd@freebsd.org>
Cc: freebsd-gnats-submit@freebsd.org, Thomas Novin <thnov@xyz.pp.se>
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still
 in 5.3R)
Date: Mon, 22 Nov 2004 17:56:38 -0800

 Sorry for the delay.  My output is below.  It may be a while before I 
 can try out a patch as were in a little bit of a bind and need the 
 systems to be up and stable for a while.  That, and I only see the 
 problem pop up sporatically.  After a reboot, things seem to work fine 
 for a seemingly random amount of time.  Having said that, not being able 
 to see my CPU utilization is pretty scary as these machines are under a 
 decent amount of load.  If it's going to help a lot, I may be able to 
 prioritize and add the patch.  Please let me know.
 
 
 www6# top
 last pid: 29362;  load averages:  0.07,  0.12,  0.16    up 4+08:04:51  
 17:45:51
 30 processes:  1 running, 29 sleeping
 CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% 
 idle
 Mem: 714M Active, 503M Inact, 150M Wired, 32K Cache, 214M Buf, 483M Free
 Swap: 4069M Total, 4069M Free
 
 FreeBSD www6.cdn.sjc 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Tue Nov 16 
 15:41:52 PST 2004     root@www6.cdn.sjc:/usr/obj/usr/src/sys/SMP  amd64
 
 www6# sysctl kern.clockrate
 kern.clockrate: { hz = 1024, tick = 976, profhz = 1024, stathz = 128 }
 
 www6# sysctl kern.timecounter
 kern.timecounter.tick: 1
 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000)
 kern.timecounter.hardware: ACPI-fast
 kern.timecounter.nsetclock: 6
 kern.timecounter.ngetmicrotime: 38349140
 kern.timecounter.ngetnanotime: 0
 kern.timecounter.ngetbintime: 0
 kern.timecounter.ngetmicrouptime: 209761019
 kern.timecounter.ngetnanouptime: 16567
 kern.timecounter.ngetbinuptime: 0
 kern.timecounter.nmicrotime: 249915960
 kern.timecounter.nnanotime: 20037
 kern.timecounter.nbintime: 249935822
 kern.timecounter.nmicrouptime: 29418
 kern.timecounter.nnanouptime: 0
 kern.timecounter.nbinuptime: 1939815878
 kern.timecounter.stepwarnings: 0
 kern.timecounter.smp_tsc: 0
 
 www6#
 www6# sysctl vm.loadavg
 vm.loadavg: { 0.09 0.12 0.17 }
 
 www6# fgrep Timecounter /var/run/dmesg.boot
 Timecounter "i8254" frequency 1193182 Hz quality 0
 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
 Timecounters tick every 0.976 msec
 
 www6# sysctl kern.cp_time && sleep 5 && sysctl kern.cp_time && sleep 5 && !!
 sysctl kern.cp_time && sleep 5 && sysctl kern.cp_time && sleep 5 && 
 sysctl kern.cp_time && sleep 5 && sysctl kern.cp_time && sleep 5
 kern.cp_time: 732270 104 925106 790100 90108268
 kern.cp_time: 732270 104 925106 790100 90108268
 kern.cp_time: 732270 104 925106 790100 90108268
 kern.cp_time: 732270 104 925106 790100 90108268
 
 
 
 www6# /usr/bin/time ls -R > /dev/null
         0.00 real         0.00 user         0.00 sys
 
 
 
 

From: Simon House <simonhouse@shaw.ca>
To: freebsd-gnats-submit@FreeBSD.org,
	jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc:  
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still
 in 5.3R)
Date: Mon, 10 Jan 2005 11:03:27 -0700

 I have just aquired an old dual PII, and have compiled the stock SMP
 kernel + patch per PR17800.  My results (with a possible clue to fix)
 are as follows:
 
 1)  Top/vmstat/etc report as normal after reboot
 
 2)  Approximately 20 minutes later, the bug appears and all zeros are
 reported in top.
 
 3)  Using 'date' I run the system clock back a few minutes, and top is
 reporting the (presumably correct) information once again.
 
 4)  Another ~20 minutes pass - and the bug is back, but of course works 
 again after changing the system date!
 
 fire# uname -a
 FreeBSD fire.xxxx.ca 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Mon Jan 10
 09:55:27 MST 2005     root@fire.xxx.ca:/usr/src/sys/i386/compile/SMP  i386
 
 ----top results after reboot:
 CPU states:  0.2% user,  0.0% nice,  0.2% system,  0.0% interrupt, 99.6%
 idle
 
 ----top results after 20 minutes:
 CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% 
 idle
 
 ----top results after running the clock back 2 minutes (then back to the 
 correct time)
 CPU states:  0.6% user,  0.0% nice,  1.1% system,  0.0% interrupt, 98.3% 
 idle
 
 
 fire# dmesg
 Copyright (c) 1992-2004 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
          The Regents of the University of California. All rights reserved.
 FreeBSD 5.3-RELEASE #1: Mon Jan 10 09:55:27 MST 2005
      root@fire.xxxxx.ca:/usr/src/sys/i386/compile/SMP
 Timecounter "i8254" frequency 1193182 Hz quality 0
 CPU: Pentium II/Pentium II Xeon/Celeron (350.80-MHz 686-class CPU)
    Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
  
 Features=0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
 real memory  = 536858624 (511 MB)
 avail memory = 515694592 (491 MB)
 MPTable: <OEM00000 PROD00000000>
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
   cpu0 (BSP): APIC ID:  1
   cpu1 (AP): APIC ID:  0
 ioapic0: Assuming intbase of 0
 ioapic0 <Version 1.1> irqs 0-23 on motherboard
 npx0: [FAST]
 npx0: <math processor> on motherboard
 npx0: INT 16 interface
 pcib0: <Intel 82443BX (440 BX) host to PCI bridge> pcibus 0 on motherboard
 pir0: <PCI Interrupt Routing Table: 7 Entries> on motherboard
 pci0: <PCI bus> on pcib0
 agp0: <Intel 82443BX (440 BX) host to PCI bridge> mem 
 0xe4000000-0xe7ffffff at device 0.0 on pci0
 pcib1: <PCI-PCI bridge> at device 1.0 on pci0
 pci1: <PCI bus> on pcib1
 isab0: <PCI-ISA bridge> at device 4.0 on pci0
 isa0: <ISA bus> on isab0
 atapci0: <Intel PIIX4 UDMA33 controller> port 
 0xd800-0xd80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0
 ata0: channel #0 on atapci0
 ata1: channel #1 on atapci0
 uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xd400-0xd41f at 
 device 4.2 on pci0
 uhci0: [GIANT-LOCKED]
 usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
 usb0: USB revision 1.0
 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
 uhub0: 2 ports with 2 removable, self powered
 piix0: <PIIX Timecounter> port 0xe800-0xe80f at device 4.3 on pci0
 Timecounter "PIIX" frequency 3579545 Hz quality 0
 ahc0: <Adaptec aic7890/91 Ultra2 SCSI adapter> port 0xd000-0xd0ff mem 
 0xe1000000-0xe1000fff irq 5 at device 6.0 on pci0
 ahc0: [GIANT-LOCKED]
 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
 rl0: <RealTek 8139 10/100BaseTX> port 0xb800-0xb8ff mem 
 0xe0800000-0xe08000ff irq 10 at device 11.0 on pci0
 miibus0: <MII bus> on rl0
 rlphy0: <RealTek internal media interface> on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 rl0: Ethernet address: 00:ee:b1:00:08:59
 pci0: <display, VGA> at device 12.0 (no driver attached)
 cpu0 on motherboard
 cpu1 on motherboard
 orm0: <ISA Option ROMs> at iomem 0xc8000-0xccfff,0xc0000-0xc7fff on isa0
 pmtimer0 on isa0
 atkbdc0: <Keyboard controller (i8042)> at port 0x64,0x60 on isa0
 atkbd0: <AT Keyboard> irq 1 on atkbdc0
 kbd0 at atkbd0
 atkbd0: [GIANT-LOCKED]
 fdc0: <Enhanced floppy controller> at port 0x3f0-0x3f5 irq 6 drq 2 on isa0
 fdc0: [FAST]
 fd0: <1440-KB 3.5" drive> on fdc0 drive 0
 ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
 ppbus0: <Parallel port bus> on ppc0
 plip0: <PLIP network interface> on ppbus0
 lpt0: <Printer> on ppbus0
 lpt0: Interrupt-driven port
 ppi0: <Parallel I/O> on ppbus0
 sc0: <System console> at flags 0x100 on isa0
 sc0: VGA <16 virtual consoles, flags=0x300>
 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
 sio0: type 16550A
 sio1 at port 0x2f8-0x2ff irq 3 on isa0
 sio1: type 16550A
 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 unknown: <PNP0400> can't assign resources (port)
 unknown: <PNP0501> can't assign resources (port)
 unknown: <PNP0501> can't assign resources (port)
 unknown: <PNP0700> can't assign resources (port)
 unknown: <PNP0303> can't assign resources (port)
 Timecounters tick every 10.000 msec
 Waiting 15 seconds for SCSI devices to settle
 da0 at ahc0 bus 0 target 0 lun 0
 da0: <SEAGATE ST39175LC 0001> Fixed Direct Access SCSI-2 device
 da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing 
 Enabled
 da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
 da1 at ahc0 bus 0 target 1 lun 0
 da1: <SEAGATE ST39173WC 6244> Fixed Direct Access SCSI-2 device
 da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing 
 Enabled
 da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
 SMP: AP CPU #1 Launched!
 Mounting root from ufs:/dev/da0s1a
 

From: Gavin Atkinson <gavin@FreeBSD.org>
To: jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net
Cc: Julien Gabel <jpeg@thilelli.net>, Thomas Novin <thnov@xyz.pp.se>,
        Jeff Behl <jbehl@fastclick.com>, Simon House <simonhouse@shaw.ca>,
        bug-followup@FreeBSD.org
Subject: Re: bin/60385: vmstat/iostat/top all fail to report CPU usage (still
 in 5.3R)
Date: Thu, 14 Jun 2007 20:31:51 +0100 (BST)

 [sent to everyone who was having problems in the audit-trail]
 
 Are you still able to reproduce this problem on more recent versions of 
 FreeBSD?  A significant number of changes have been made to the RTC code 
 since this was submitted, and two changes in particular (including the one 
 mentioned in the PR) may well have solved ot.
 
 So: Is anyone still seeing this issue?
 
 Thanks,
 
 Gavin
State-Changed-From-To: open->feedback 
State-Changed-By: gavin 
State-Changed-When: Thu Jun 14 20:32:09 UTC 2007 
State-Changed-Why:  
Have asked for feedback 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60385 
State-Changed-From-To: feedback->closed 
State-Changed-By: gavin 
State-Changed-When: Mon Jul 16 12:51:59 UTC 2007 
State-Changed-Why:  
Feedback timeout (>1 month), believed to be fixed by the patch from i386/17800 
(a version of which has been committed) 

http://www.freebsd.org/cgi/query-pr.cgi?pr=60385 
>Unformatted:
