From nobody@FreeBSD.org  Sat Nov 10 23:42:08 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 073ADDEC
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 10 Nov 2012 23:42:08 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id E46338FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 10 Nov 2012 23:42:07 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id qAANg7US074164
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 10 Nov 2012 23:42:07 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id qAANg71Y074162;
	Sat, 10 Nov 2012 23:42:07 GMT
	(envelope-from nobody)
Message-Id: <201211102342.qAANg71Y074162@red.freebsd.org>
Date: Sat, 10 Nov 2012 23:42:07 GMT
From: Viktor tujber <viktor.stujber@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: load average 0.60 at 100% idle
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         173541
>Category:       kern
>Synopsis:       load average 0.60 at 100% idle
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 10 23:50:00 UTC 2012
>Closed-Date:    
>Last-Modified:  Fri Jan 31 06:30:00 UTC 2014
>Originator:     Viktor tujber
>Release:        9.1-RC3
>Organization:
>Environment:
FreeBSD poring 9.1-RC3 FreeBSD 9.1-RC3 #0 r242461: Fri Nov  2 01:17:26 CET 2012     root@poring:/usr/src/sys/PORING  amd64

>Description:
I run FreeBSD on an intel atom D525MWV board. On recent FreeBSD versions, I am observing unusual load averages reported by 'top' even when 100% idle. It happens in a normal system, in single user mode, and on official usb install images. I have not yet confirmed if the load is real or if it's just kernel reporting the values wrong.

Here are kernels that I have tried. Four of them are from the currently available usb memstick installers; the 2011 one is a version I've been successfully using for a year until downgrading recently.

8.3-RELEASE  amd64 2012-04-09           -> load 0.02 after 5 minutes idle
9.0-RELEASE  amd64 2012-01-03           -> load 0.02 after 5 minutes idle
10.0-CURRENT amd64 2011-11-12 (cvs)     -> load 0.02 after 5 minutes idle
9.1-RC3      amd64 2012-10-30 (r242324) -> load 0.60 after 5 minutes idle
10.0-CURRENT amd64 2012-11-02 (r242464) -> load 0.60 after 5 minutes idle

>How-To-Repeat:
1) boot system on affected hardware(?)
2) leave 'top' running for a few minutes
3) observe load averages
>Fix:


>Release-Note:
>Audit-Trail:

From: =?UTF-8?B?VmlrdG9yIMWgdHVqYmVy?= <viktor.stujber@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Sun, 11 Nov 2012 06:50:10 +0100

 A night without sleep and a chain of manual bisection steps later:
 stable/9 r232058 2012-02-23 - pass
 stable/9 r232129 2012-02-24 - fail
 (will continue to narrow it down later)

From: umage <theultramage@hotmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Sun, 11 Nov 2012 20:26:25 +0100

 --------------020202030603010502040906
 Content-Type: text/plain; charset="UTF-8"; format=flowed
 Content-Transfer-Encoding: 7bit
 
 The problem first occurs on 232086 (original head revision 231161)
 http://svnweb.freebsd.org/base?view=revision&revision=232086
 
 It has some acpi-related and tick source-related changes regarding their 
 probing order/priority. I observed that this does indeed change the way 
 they are reported in /var/log/messages. In particular, the order changes 
 and they're initalized way earlier in the startup process. Diff attached.
 
 --------------020202030603010502040906
 Content-Type: text/plain; charset="windows-1250"; name="messages.diff"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="messages.diff"
 
 LS0tIHIyMzIwODUtcGFzcwkyMDEyLTExLTExIDIwOjE1OjI4LjYxNzAwMDAwMCArMDEwMA0K
 KysrIHIyMzIwODYtZmFpbAkyMDEyLTExLTExIDE5OjI3OjA5LjgwNzUwMDAwMCArMDEwMA0K
 QEAgLTMsNyArMyw3IEBADQoga2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5
 ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCiBrZXJuZWw6
 IFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdo
 dHMgcmVzZXJ2ZWQuDQoga2VybmVsOiBGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h
 cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCi1rZXJuZWw6IEZyZWVCU0QgOS4wLVNU
 QUJMRSAjMCByMjMyMDg1OiBTdW4gTm92IDExIDE5OjI3OjA4IENFVCAyMDEyDQora2VybmVs
 OiBGcmVlQlNEIDkuMC1TVEFCTEUgIzAgcjIzMjA4NjogU3VuIE5vdiAxMSAxODoxOToyNiBD
 RVQgMjAxMg0KIGtlcm5lbDogcm9vdEBwb3Jpbmc6L3Vzci9vYmovc3RvcmFnZS91c2Vycy9y
 b290L2ZyZWVic2QtcmVnL3N5cy9QT1JJTkcgYW1kNjQNCiBrZXJuZWw6IENQVTogSW50ZWwo
 UikgQXRvbShUTSkgQ1BVIEQ1MjUgICBAIDEuODBHSHogKDE4MDAuMTEtTUh6IEs4LWNsYXNz
 IENQVSkNCiBrZXJuZWw6IE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MTA2Y2Eg
 IEZhbWlseSA9IDYgIE1vZGVsID0gMWMgIFN0ZXBwaW5nID0gMTANCkBAIC0yOCwxMiArMjgs
 MjIgQEANCiBrZXJuZWw6IGtiZDEgYXQga2JkbXV4MA0KIGtlcm5lbDogYWNwaTA6IDxJTlRF
 TCBENTI1TVc+IG9uIG1vdGhlcmJvYXJkDQoga2VybmVsOiBhY3BpMDogUG93ZXIgQnV0dG9u
 IChmaXhlZCkNCi1rZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAz
 NTc5NTQ1IEh6IHF1YWxpdHkgOTAwDQota2VybmVsOiBhY3BpX3RpbWVyMDogPDI0LWJpdCB0
 aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMA0KIGtlcm5l
 bDogY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KIGtlcm5lbDogY3B1MTogPEFDUEkgQ1BV
 PiBvbiBhY3BpMA0KIGtlcm5lbDogY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KIGtlcm5l
 bDogY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KK2tlcm5lbDogYXRydGMwOiA8QVQgcmVh
 bHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxLDB4NzQtMHg3NyBpcnEgOCBvbiBhY3BpMA0K
 K2tlcm5lbDogRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkg
 MA0KK2tlcm5lbDogYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMsMHg1MC0w
 eDUzIGlycSAwIG9uIGFjcGkwDQora2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1
 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KK2tlcm5lbDogRXZlbnQgdGltZXIgImk4MjU0
 IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMA0KK2tlcm5lbDogaHBldDA6IDxI
 aWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAzZmZm
 IG9uIGFjcGkwDQora2VybmVsOiBUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4
 MTgwIEh6IHF1YWxpdHkgOTUwDQora2VybmVsOiBFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVl
 bmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDUwDQora2VybmVsOiBFdmVudCB0aW1lciAiSFBF
 VDEiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MA0KK2tlcm5lbDogRXZlbnQg
 dGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDANCitrZXJu
 ZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxp
 dHkgOTAwDQora2VybmVsOiBhY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0
 NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMA0KIGtlcm5lbDogYWNwaV9idXR0b24w
 OiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMA0KIGtlcm5lbDogcGNpYjA6IDxBQ1BJIEhvc3Qt
 UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KIGtlcm5lbDogcGNpMDog
 PEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCkBAIC04MCwxNiArOTAsNiBAQA0KIGtlcm5lbDog
 YWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwDQoga2VybmVs
 OiBpY2hzbWIwOiA8SW50ZWwgODI4MDFHQiAoSUNINykgU01CdXMgY29udHJvbGxlcj4gcG9y
 dCAweDMwMDAtMHgzMDFmIGlycSAxOSBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwDQoga2VybmVs
 OiBzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjANCi1rZXJuZWw6
 IGhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAt
 MHhmZWQwM2ZmZiBvbiBhY3BpMA0KLWtlcm5lbDogVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1
 ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MA0KLWtlcm5lbDogRXZlbnQgdGltZXIgIkhQ
 RVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ1MA0KLWtlcm5lbDogRXZlbnQg
 dGltZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDANCi1rZXJu
 ZWw6IEV2ZW50IHRpbWVyICJIUEVUMiIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkg
 NDQwDQota2VybmVsOiBhdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4
 NzEsMHg3NC0weDc3IGlycSA4IG9uIGFjcGkwDQota2VybmVsOiBFdmVudCB0aW1lciAiUlRD
 IiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwDQota2VybmVsOiBhdHRpbWVyMDogPEFU
 IHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTANCi1rZXJu
 ZWw6IFRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAw
 DQota2VybmVsOiBFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1
 YWxpdHkgMTAwDQoga2VybmVsOiBhdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw
 NDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMA0KIGtlcm5lbDogYXRrYmQwOiA8
 QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCiBrZXJuZWw6IGtiZDAgYXQgYXRrYmQw
 DQo=
 --------------020202030603010502040906--

From: umage <umage@netvor.sk>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Tue, 13 Nov 2012 16:58:03 +0100

 This is a multi-part message in MIME format.
 --------------070202010701040503090208
 Content-Type: text/plain; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: 7bit
 
 The offending revision where the issue can first be observed in stable-9 
 is r232086 (MFC: r231161) - 
 http://svnweb.freebsd.org/base?view=revision&revision=232086
 The consequence of that change can be observed in /var/log/messages - 
 the timer sources get initialized way earlier and in different order. 
 Diff attached.
 
 --------------070202010701040503090208
 Content-Type: text/plain; charset=windows-1250;
  name="messages.diff"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename="messages.diff"
 
 LS0tIHIyMzIwODUtcGFzcwkyMDEyLTExLTExIDIwOjE1OjI4LjYxNzAwMDAwMCArMDEwMA0K
 KysrIHIyMzIwODYtZmFpbAkyMDEyLTExLTExIDE5OjI3OjA5LjgwNzUwMDAwMCArMDEwMA0K
 QEAgLTMsNyArMyw3IEBADQoga2VybmVsOiBDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5
 ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCiBrZXJuZWw6
 IFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdo
 dHMgcmVzZXJ2ZWQuDQoga2VybmVsOiBGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h
 cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCi1rZXJuZWw6IEZyZWVCU0QgOS4wLVNU
 QUJMRSAjMCByMjMyMDg1OiBTdW4gTm92IDExIDE5OjI3OjA4IENFVCAyMDEyDQora2VybmVs
 OiBGcmVlQlNEIDkuMC1TVEFCTEUgIzAgcjIzMjA4NjogU3VuIE5vdiAxMSAxODoxOToyNiBD
 RVQgMjAxMg0KIGtlcm5lbDogcm9vdEBwb3Jpbmc6L3Vzci9vYmovc3RvcmFnZS91c2Vycy9y
 b290L2ZyZWVic2QtcmVnL3N5cy9QT1JJTkcgYW1kNjQNCiBrZXJuZWw6IENQVTogSW50ZWwo
 UikgQXRvbShUTSkgQ1BVIEQ1MjUgICBAIDEuODBHSHogKDE4MDAuMTEtTUh6IEs4LWNsYXNz
 IENQVSkNCiBrZXJuZWw6IE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MTA2Y2Eg
 IEZhbWlseSA9IDYgIE1vZGVsID0gMWMgIFN0ZXBwaW5nID0gMTANCkBAIC0yOCwxMiArMjgs
 MjIgQEANCiBrZXJuZWw6IGtiZDEgYXQga2JkbXV4MA0KIGtlcm5lbDogYWNwaTA6IDxJTlRF
 TCBENTI1TVc+IG9uIG1vdGhlcmJvYXJkDQoga2VybmVsOiBhY3BpMDogUG93ZXIgQnV0dG9u
 IChmaXhlZCkNCi1rZXJuZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAz
 NTc5NTQ1IEh6IHF1YWxpdHkgOTAwDQota2VybmVsOiBhY3BpX3RpbWVyMDogPDI0LWJpdCB0
 aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMA0KIGtlcm5l
 bDogY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KIGtlcm5lbDogY3B1MTogPEFDUEkgQ1BV
 PiBvbiBhY3BpMA0KIGtlcm5lbDogY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KIGtlcm5l
 bDogY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KK2tlcm5lbDogYXRydGMwOiA8QVQgcmVh
 bHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxLDB4NzQtMHg3NyBpcnEgOCBvbiBhY3BpMA0K
 K2tlcm5lbDogRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkg
 MA0KK2tlcm5lbDogYXR0aW1lcjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMsMHg1MC0w
 eDUzIGlycSAwIG9uIGFjcGkwDQora2VybmVsOiBUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1
 ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KK2tlcm5lbDogRXZlbnQgdGltZXIgImk4MjU0
 IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMA0KK2tlcm5lbDogaHBldDA6IDxI
 aWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAzZmZm
 IG9uIGFjcGkwDQora2VybmVsOiBUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4
 MTgwIEh6IHF1YWxpdHkgOTUwDQora2VybmVsOiBFdmVudCB0aW1lciAiSFBFVCIgZnJlcXVl
 bmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgNDUwDQora2VybmVsOiBFdmVudCB0aW1lciAiSFBF
 VDEiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ0MA0KK2tlcm5lbDogRXZlbnQg
 dGltZXIgIkhQRVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDANCitrZXJu
 ZWw6IFRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxp
 dHkgOTAwDQora2VybmVsOiBhY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0
 NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMA0KIGtlcm5lbDogYWNwaV9idXR0b24w
 OiA8U2xlZXAgQnV0dG9uPiBvbiBhY3BpMA0KIGtlcm5lbDogcGNpYjA6IDxBQ1BJIEhvc3Qt
 UENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KIGtlcm5lbDogcGNpMDog
 PEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCkBAIC04MCwxNiArOTAsNiBAQA0KIGtlcm5lbDog
 YWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwDQoga2VybmVs
 OiBpY2hzbWIwOiA8SW50ZWwgODI4MDFHQiAoSUNINykgU01CdXMgY29udHJvbGxlcj4gcG9y
 dCAweDMwMDAtMHgzMDFmIGlycSAxOSBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwDQoga2VybmVs
 OiBzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjANCi1rZXJuZWw6
 IGhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAt
 MHhmZWQwM2ZmZiBvbiBhY3BpMA0KLWtlcm5lbDogVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1
 ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MA0KLWtlcm5lbDogRXZlbnQgdGltZXIgIkhQ
 RVQiIGZyZXF1ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDQ1MA0KLWtlcm5lbDogRXZlbnQg
 dGltZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDANCi1rZXJu
 ZWw6IEV2ZW50IHRpbWVyICJIUEVUMiIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkg
 NDQwDQota2VybmVsOiBhdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4
 NzEsMHg3NC0weDc3IGlycSA4IG9uIGFjcGkwDQota2VybmVsOiBFdmVudCB0aW1lciAiUlRD
 IiBmcmVxdWVuY3kgMzI3NjggSHogcXVhbGl0eSAwDQota2VybmVsOiBhdHRpbWVyMDogPEFU
 IHRpbWVyPiBwb3J0IDB4NDAtMHg0MywweDUwLTB4NTMgaXJxIDAgb24gYWNwaTANCi1rZXJu
 ZWw6IFRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAw
 DQota2VybmVsOiBFdmVudCB0aW1lciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1
 YWxpdHkgMTAwDQoga2VybmVsOiBhdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw
 NDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMA0KIGtlcm5lbDogYXRrYmQwOiA8
 QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCiBrZXJuZWw6IGtiZDAgYXQgYXRrYmQw
 DQo=
 --------------070202010701040503090208--

From: Johan Broman <je.broman@gmail.com>
To: bug-followup@FreeBSD.org
Cc: viktor.stujber@gmail.com
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Thu, 3 Jan 2013 23:19:00 +0100

 --089e01177699f745b904d269bf93
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi!
 
 I'm getting the exact same issue. Upgraded from FreeBSD 9.0 to FreeBSD 9.1
 and my load avg jumped from 0.01 to 0.60, while the server is doing pretty
 much nothing at all.
 
 I'm also seeing the timer differences in dmesg as described earlier in the
 bug report.
 
 # sysctl -a | egrep "kern.event|clock"
 kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 }
 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400)
 i8254(100) RTC(0)
 kern.eventtimer.et.LAPIC.flags: 15
 kern.eventtimer.et.LAPIC.frequency: 0
 kern.eventtimer.et.LAPIC.quality: 400
 kern.eventtimer.et.i8254.flags: 1
 kern.eventtimer.et.i8254.frequency: 1193182
 kern.eventtimer.et.i8254.quality: 100
 kern.eventtimer.et.RTC.flags: 17
 kern.eventtimer.et.RTC.frequency: 32768
 kern.eventtimer.et.RTC.quality: 0
 kern.eventtimer.et.HPET.flags: 3
 kern.eventtimer.et.HPET.frequency: 14318180
 kern.eventtimer.et.HPET.quality: 450
 kern.eventtimer.et.HPET1.flags: 3
 kern.eventtimer.et.HPET1.frequency: 14318180
 kern.eventtimer.et.HPET1.quality: 440
 kern.eventtimer.et.HPET2.flags: 3
 kern.eventtimer.et.HPET2.frequency: 14318180
 kern.eventtimer.et.HPET2.quality: 440
 kern.eventtimer.periodic: 0
 kern.eventtimer.timer: HPET
 kern.eventtimer.activetick: 1
 kern.eventtimer.idletick: 0
 kern.eventtimer.singlemul: 2
 debug.acpi.reset_clock: 1
 debug.clocktime: 0
 hw.clockrate: 2133
 machdep.wall_cmos_clock: 0
 dev.atrtc.0.%desc: AT realtime clock
 
 
 # dmesg | more
 Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation.
 FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012
     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
 CPU: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz (2133.45-MHz K8-class
 CPU)
   Origin = "GenuineIntel"  Id = 0x6f2  Family = 6  Model = f  Stepping = 2
 
 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>
   Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
   AMD Features=0x20100800<SYSCALL,NX,LM>
   AMD Features2=0x1<LAHF>
   TSC: P-state invariant, performance statistics
 real memory  = 4296015872 (4097 MB)
 avail memory = 4101558272 (3911 MB)
 Event timer "LAPIC" quality 400
 ACPI APIC Table: <COMPAQ GLENWOOD>
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 FreeBSD/SMP: 1 package(s) x 2 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
 ioapic0: Changing APIC ID to 1
 ioapic0 <Version 2.0> irqs 0-23 on motherboard
 kbd1 at kbdmux0
 acpi0: <HPQOEM SLIC-WKS> on motherboard
 acpi0: Power Button (fixed)
 acpi0: reservation of 0, a0000 (3) failed
 acpi0: reservation of 100000, dff00000 (3) failed
 cpu0: <ACPI CPU> on acpi0
 cpu1: <ACPI CPU> on acpi0
 attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
 Timecounter "i8254" frequency 1193182 Hz quality 0
 Event timer "i8254" frequency 1193182 Hz quality 100
 atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
 Event timer "RTC" frequency 32768 Hz quality 0
 hpet1: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
 Event timer "HPET" frequency 14318180 Hz quality 450
 Event timer "HPET1" frequency 14318180 Hz quality 440
 Event timer "HPET2" frequency 14318180 Hz quality 440
 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
 device_attach: hpet0 attach returned 12
 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf808-0xf80b on acpi0
 
 Regards
 Johan
 
 --089e01177699f745b904d269bf93
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Hi!<br><br>I&#39;m getting the exact same issue. Upgraded from FreeBSD 9.0 =
 to FreeBSD 9.1 and my load avg jumped from 0.01 to 0.60, while the server i=
 s doing pretty much nothing at all.<br><br>I&#39;m also seeing the timer di=
 fferences in dmesg as described earlier in the bug report. <br>
 <br># sysctl -a | egrep &quot;kern.event|clock&quot; <br>kern.clockrate: { =
 hz =3D 1000, tick =3D 1000, profhz =3D 8126, stathz =3D 127 }<br>kern.event=
 timer.choice: HPET(450) HPET1(440) HPET2(440) LAPIC(400) i8254(100) RTC(0)<=
 br>kern.eventtimer.et.LAPIC.flags: 15<br>
 kern.eventtimer.et.LAPIC.frequency: 0<br>kern.eventtimer.et.LAPIC.quality: =
 400<br>kern.eventtimer.et.i8254.flags: 1<br>kern.eventtimer.et.i8254.freque=
 ncy: 1193182<br>kern.eventtimer.et.i8254.quality: 100<br>kern.eventtimer.et=
 .RTC.flags: 17<br>
 kern.eventtimer.et.RTC.frequency: 32768<br>kern.eventtimer.et.RTC.quality: =
 0<br>kern.eventtimer.et.HPET.flags: 3<br>kern.eventtimer.et.HPET.frequency:=
  14318180<br>kern.eventtimer.et.HPET.quality: 450<br>kern.eventtimer.et.HPE=
 T1.flags: 3<br>
 kern.eventtimer.et.HPET1.frequency: 14318180<br>kern.eventtimer.et.HPET1.qu=
 ality: 440<br>kern.eventtimer.et.HPET2.flags: 3<br>kern.eventtimer.et.HPET2=
 .frequency: 14318180<br>kern.eventtimer.et.HPET2.quality: 440<br>kern.event=
 timer.periodic: 0<br>
 kern.eventtimer.timer: HPET<br>kern.eventtimer.activetick: 1<br>kern.eventt=
 imer.idletick: 0<br>kern.eventtimer.singlemul: 2<br>debug.acpi.reset_clock:=
  1<br>debug.clocktime: 0<br>hw.clockrate: 2133<br>machdep.wall_cmos_clock: =
 0<br>
 dev.atrtc.0.%desc: AT realtime clock<br><br><br># dmesg | more<br>Copyright=
  (c) 1992-2012 The FreeBSD Project.<br>Copyright (c) 1979, 1980, 1983, 1986=
 , 1988, 1989, 1991, 1992, 1993, 1994<br>=A0=A0=A0=A0=A0=A0=A0 The Regents o=
 f the University of California. All rights reserved.<br>
 FreeBSD is a registered trademark of The FreeBSD Foundation.<br>FreeBSD 9.1=
 -RELEASE #0 r243825: Tue Dec=A0 4 09:23:10 UTC 2012<br>=A0=A0=A0 root@farre=
 ll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64<br>CPU: Intel(R) Core=
 (TM)2 CPU=A0=A0=A0=A0=A0=A0=A0=A0=A0 6400=A0 @ 2.13GHz (2133.45-MHz K8-clas=
 s CPU)<br>
 =A0 Origin =3D &quot;GenuineIntel&quot;=A0 Id =3D 0x6f2=A0 Family =3D 6=A0 =
 Model =3D f=A0 Stepping =3D 2<br>=A0 Features=3D0xbfebfbff&lt;FPU,VME,DE,PS=
 E,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI=
 ,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE&gt;<br>
 =A0 Features2=3D0xe3bd&lt;SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTP=
 R,PDCM&gt;<br>=A0 AMD Features=3D0x20100800&lt;SYSCALL,NX,LM&gt;<br>=A0 AMD=
  Features2=3D0x1&lt;LAHF&gt;<br>=A0 TSC: P-state invariant, performance sta=
 tistics<br>
 real memory=A0 =3D 4296015872 (4097 MB)<br>avail memory =3D 4101558272 (391=
 1 MB)<br>Event timer &quot;LAPIC&quot; quality 400<br>ACPI APIC Table: &lt;=
 COMPAQ GLENWOOD&gt;<br>FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs<=
 br>
 FreeBSD/SMP: 1 package(s) x 2 core(s)<br>=A0cpu0 (BSP): APIC ID:=A0 0<br>=
 =A0cpu1 (AP): APIC ID:=A0 1<br>ioapic0: Changing APIC ID to 1<br>ioapic0 &l=
 t;Version 2.0&gt; irqs 0-23 on motherboard<br>kbd1 at kbdmux0<br>acpi0: &lt=
 ;HPQOEM SLIC-WKS&gt; on motherboard<br>
 acpi0: Power Button (fixed)<br>acpi0: reservation of 0, a0000 (3) failed<br=
 >acpi0: reservation of 100000, dff00000 (3) failed<br>cpu0: &lt;ACPI CPU&gt=
 ; on acpi0<br>cpu1: &lt;ACPI CPU&gt; on acpi0<br>attimer0: &lt;AT timer&gt;=
  port 0x40-0x43 irq 0 on acpi0<br>
 Timecounter &quot;i8254&quot; frequency 1193182 Hz quality 0<br>Event timer=
  &quot;i8254&quot; frequency 1193182 Hz quality 100<br>atrtc0: &lt;AT realt=
 ime clock&gt; port 0x70-0x71 irq 8 on acpi0<br>Event timer &quot;RTC&quot; =
 frequency 32768 Hz quality 0<br>
 hpet1: &lt;High Precision Event Timer&gt; iomem 0xfed00000-0xfed003ff on ac=
 pi0<br>Event timer &quot;HPET&quot; frequency 14318180 Hz quality 450<br>Ev=
 ent timer &quot;HPET1&quot; frequency 14318180 Hz quality 440<br>Event time=
 r &quot;HPET2&quot; frequency 14318180 Hz quality 440<br>
 hpet0: &lt;High Precision Event Timer&gt; iomem 0xfed00000-0xfed003ff on ac=
 pi0<br>device_attach: hpet0 attach returned 12<br>Timecounter &quot;ACPI-fa=
 st&quot; frequency 3579545 Hz quality 900<br>acpi_timer0: &lt;24-bit timer =
 at 3.579545MHz&gt; port 0xf808-0xf80b on acpi0<br>
 <br>Regards<br>Johan<br><br>
 
 --089e01177699f745b904d269bf93--

From: =?UTF-8?B?VmlrdG9yIMWgdHVqYmVy?= <viktor.stujber@gmail.com>
To: Johan Broman <je.broman@gmail.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Thu, 03 Jan 2013 23:44:46 +0100

 For my system's kernel I just undid that one revision I mentioned 
 earlier. No ill-effects observed. Since the change is so low-level and 
 there is no rationale provided in the commit message, I do not know what 
 improvement it was supposed to achieve. I tried e-mailing the author of 
 that commit, but got no response.
 Also, due to the low-power nature of my system, I can't test if the 0.60 
 load is real, or just a by-product of broken time accounting. Either way 
 it might be affecting the process scheduler.

From: Johan Broman <je.broman@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Fri, 4 Jan 2013 00:06:16 +0100

 --047d7b5d95370023f704d26a691e
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi!
 
 I see. I got around the problem in FreeBSD 9.1 by changing the clock
 source. Like this:
 
 # sysctl -w kern.eventtimer.timer=LAPIC
 
 The load avg dropped to 0.00 again. You can try the different clock sources
 available to you and see what works best. Some sources might increase the
 number of interrupts (like the RTC) and some might cause more context
 switching or CPU load. For me the LAPIC works best. You can list your clock
 sources using:
 
 # sysctl kern.eventtimer.choice
 
 From what I understand, measuring time can be tricky because new systems
 can regulate core frequency on the fly (in HW) and virtualization also
 increases the difficulty...
 
 It seems the order and/or weight of the clock sources has changed. When I
 have a chance I will reboot into the old kernel and see what has been
 changed. I'm totally new to FreeBSD so I don't know the normal handling of
 these bugs but I'll put the author of the patch on cc as well :)
 
 Good luck!
 Johan
 
 --047d7b5d95370023f704d26a691e
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Hi!<br><br>I see. I got around the problem in FreeBSD 9.1 by changing the c=
 lock source. Like this:<br><br># sysctl -w kern.eventtimer.timer=3DLAPIC<br=
 ><br>The load avg dropped to 0.00 again. You can try the different clock so=
 urces available to you and see what works best. Some sources might increase=
  the number of interrupts (like the RTC) and some might cause more context =
 switching or CPU load. For me the LAPIC works best. You can list your clock=
  sources using:<br>
 <br># sysctl kern.eventtimer.choice<br><br>From what I understand, measurin=
 g time can be tricky because new systems can regulate core frequency on the=
  fly (in HW) and virtualization also increases the difficulty...<br><br>
 It seems the order and/or weight of the clock sources has changed. When I h=
 ave a chance I will reboot into the old kernel and see what has been change=
 d. I&#39;m totally new to FreeBSD so I don&#39;t know the normal handling o=
 f these bugs but I&#39;ll put the author of the patch on cc as well :)<br>
 <br>Good luck!<br>Johan<br><br>
 
 --047d7b5d95370023f704d26a691e--

From: Frederique Rijsdijk <frederique@isafeelin.org>
To: bug-followup@FreeBSD.org, viktor.stujber@gmail.com
Cc:  
Subject: Re: kern/173541: load average 0.60 at 100% idle
Date: Fri, 31 Jan 2014 07:14:14 +0100

 I'm seeing the same issues in FreeBSD 10-RELEASE.
 
 A VM has a load avg of about 0.5, a physical install will show ~0.3 load 
 average. My tests were done in single user mode even.
 
 https://forums.freebsd.org/viewtopic.php?f=4&t=44600
>Unformatted:
