From nobody@FreeBSD.org  Tue Aug 14 06:38:31 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 67025106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Aug 2012 06:38:31 +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 0D0918FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Aug 2012 06:38:31 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q7E6cUCg030667
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Aug 2012 06:38:30 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q7E6cUoO030666;
	Tue, 14 Aug 2012 06:38:30 GMT
	(envelope-from nobody)
Message-Id: <201208140638.q7E6cUoO030666@red.freebsd.org>
Date: Tue, 14 Aug 2012 06:38:30 GMT
From: Max Johnson <adscomplex@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Kernel memomry leak when polling cpu temperature via coretemp kernel module.
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         170627
>Category:       kern
>Synopsis:       Kernel memory leak when polling cpu temperature via coretemp kernel module.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    mjg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 14 06:40:10 UTC 2012
>Closed-Date:    Sun Sep 09 11:10:35 UTC 2012
>Last-Modified:  Sun Sep 09 11:10:35 UTC 2012
>Originator:     Max Johnson
>Release:        9.0
>Organization:
>Environment:
FreeBSD devel.host 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
coretemp kernel module is loaded by:

kldload coretemp 

every minute sysctl counters
is polled by stats scripts and stored id rrd's.

active memory usage always growing and after 15-20 days we have a kernel panic.

Additional information:

Aug  2 15:58:22 devel kernel: CPU: Intel(R) Xeon(R) CPU           X3230  @ 2.66GHz (2660.05-MHz K8-class CPU)
Aug  2 15:58:22 devel kernel: Origin = "GenuineIntel"  Id = 0x6fb  Family = 6  Model = f  Stepping = 11
Aug  2 15:58:22 devel kernel: 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>
Aug  2 15:58:22 devel kernel: Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM>
Aug  2 15:58:22 devel kernel: AMD Features=0x20100800<SYSCALL,NX,LM>
Aug  2 15:58:22 devel kernel: AMD Features2=0x1<LAHF>
Aug  2 15:58:22 devel kernel: TSC: P-state invariant, performance statistics
Aug  2 15:58:22 devel kernel: real memory  = 8589934592 (8192 MB)
Aug  2 15:58:22 devel kernel: avail memory = 8245788672 (7863 MB)

.....

Aug  2 15:58:34 devel kernel: coretemp0: <CPU On-Die Thermal Sensors> on cpu0
Aug  2 15:58:34 devel kernel: est0: <Enhanced SpeedStep Frequency Control> on cpu0
Aug  2 15:58:34 devel kernel: est: CPU supports Enhanced Speedstep, but is not recognized.
Aug  2 15:58:34 devel kernel: est: cpu_vendor GenuineIntel, msr a230a2306000a23
Aug  2 15:58:34 devel kernel: device_attach: est0 attach returned 6
Aug  2 15:58:34 devel kernel: coretemp1: <CPU On-Die Thermal Sensors> on cpu1
Aug  2 15:58:34 devel kernel: est1: <Enhanced SpeedStep Frequency Control> on cpu1
Aug  2 15:58:34 devel kernel: est: CPU supports Enhanced Speedstep, but is not recognized.
Aug  2 15:58:34 devel kernel: est: cpu_vendor GenuineIntel, msr a230a2306000a23
Aug  2 15:58:34 devel kernel: device_attach: est1 attach returned 6
Aug  2 15:58:34 devel kernel: coretemp2: <CPU On-Die Thermal Sensors> on cpu2
Aug  2 15:58:34 devel kernel: est2: <Enhanced SpeedStep Frequency Control> on cpu2
Aug  2 15:58:34 devel kernel: est: CPU supports Enhanced Speedstep, but is not recognized.
Aug  2 15:58:34 devel kernel: est: cpu_vendor GenuineIntel, msr a230a2306000a23
Aug  2 15:58:34 devel kernel: device_attach: est2 attach returned 6
Aug  2 15:58:34 devel kernel: coretemp3: <CPU On-Die Thermal Sensors> on cpu3
Aug  2 15:58:34 devel kernel: est3: <Enhanced SpeedStep Frequency Control> on cpu3
Aug  2 15:58:34 devel kernel: est: CPU supports Enhanced Speedstep, but is not recognized.
Aug  2 15:58:34 devel kernel: est: cpu_vendor GenuineIntel, msr a230a2306000a23
Aug  2 15:58:34 devel kernel: device_attach: est3 attach returned 6

>How-To-Repeat:
Just load coretemp module

and pool actively (every few seconds) a temperature counters.

Active memory will grow slowly.

>Fix:
Do not load and use coretemp module.

>Release-Note:
>Audit-Trail:

From: Mark Johnston <markjdb@gmail.com>
To: bug-followup@FreeBSD.org, adscomplex@gmail.com
Cc:  
Subject: Re: kern/170627: Kernel memory leak when polling cpu temperature via
 coretemp kernel module.
Date: Sat, 8 Sep 2012 19:16:32 -0400

 Hi Max,
 
 Why do you think that coretemp is causing the memory leak? As far as I
 can see, polling the coretemp sysctls shouldn't cause any memory to be
 allocated at all - coretemp basically just reads a bunch of MSRs. Just
 for fun, I tried running something like
 
 while true; do
     for n in $(jot - 0 $(sysctl -n hw.ncpu)); do
         sysctl -q dev.cpu.${n}.temperature >/dev/null 2>&1
         sysctl -q dev.cpu.${n}.coretemp >/dev/null 2>&1
     done
 done
 
 for a few hours and didn't see any problems.
 
 What panic are you getting? How exactly are polling the temperature
 sensors - which sysctls are you reading?
 
 Thanks,
 -Mark

From: Mark Johnston <markjdb@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/170627: Kernel memory leak when polling cpu temperature via
 coretemp kernel module.]
Date: Sun, 9 Sep 2012 03:17:31 -0400

 Forwarding so that this gets logged. The PR can be closed.
 
 ----- Forwarded message from Remme <adscomplex@gmail.com> -----
 
 Date: Sun, 9 Sep 2012 09:39:01 +0300
 From: Remme <adscomplex@gmail.com>
 To: Mark Johnston <markjdb@gmail.com>
 Subject: Re: kern/170627: Kernel memory leak when polling cpu temperature via coretemp kernel module.
 
 Hi Mark,
 
 Please cancel this report.
 Sorry for taking your time - but at the first sight coretemp was the reason.
 (Module unload fixed a problem - but only for a first 12-24 hours.).
 The reason for panic was a sphinxsearch (searchd).
 At this moment we are downgraded it to 0.9.9 and this seems solved a kernel
 panic problem.
 But we still have a growing active memory issue.
 
 Thank you for your time and attention.
 WBR,
 Max.
 
 
 On Sun, Sep 9, 2012 at 2:16 AM, Mark Johnston <markjdb@gmail.com> wrote:
 
 > Hi Max,
 >
 > Why do you think that coretemp is causing the memory leak? As far as I
 > can see, polling the coretemp sysctls shouldn't cause any memory to be
 > allocated at all - coretemp basically just reads a bunch of MSRs. Just
 > for fun, I tried running something like
 >
 > while true; do
 >     for n in $(jot - 0 $(sysctl -n hw.ncpu)); do
 >         sysctl -q dev.cpu.${n}.temperature >/dev/null 2>&1
 >         sysctl -q dev.cpu.${n}.coretemp >/dev/null 2>&1
 >     done
 > done
 >
 > for a few hours and didn't see any problems.
 >
 > What panic are you getting? How exactly are polling the temperature
 > sensors - which sysctls are you reading?
 >
 > Thanks,
 > -Mark
 >
 
 ----- End forwarded message -----
State-Changed-From-To: open->closed 
State-Changed-By: mjg 
State-Changed-When: Sun Sep 9 11:10:20 UTC 2012 
State-Changed-Why:  
Per submitter request. 


Responsible-Changed-From-To: freebsd-bugs->mjg 
Responsible-Changed-By: mjg 
Responsible-Changed-When: Sun Sep 9 11:10:20 UTC 2012 
Responsible-Changed-Why:  
Per submitter request. 

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