From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v1] xen/mce: Don't spam the console with "CPUx: Temperature z" (v2) Date: Wed, 4 Jun 2014 14:50:59 -0400 Message-ID: <20140604185059.GA6645@phenom.dumpdata.com> References: <1401889050-31871-1-git-send-email-konrad.wilk@oracle.com> <1401889050-31871-2-git-send-email-konrad.wilk@oracle.com> <538F4E300200007800017DDF@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WsGHI-0005mr-TD for xen-devel@lists.xenproject.org; Wed, 04 Jun 2014 18:51:13 +0000 Content-Disposition: inline In-Reply-To: <538F4E300200007800017DDF@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: jinsong.liu@alibaba-inc.com, chegger@amazon.de, keir@xen.org, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Wed, Jun 04, 2014 at 03:49:52PM +0100, Jan Beulich wrote: > >>> On 04.06.14 at 15:37, wrote: > > If the machine has been quite busy it ends up with these > > messages printed on the hypervisor console: > > > > (XEN) CPU3: Temperature/speed normal > > (XEN) CPU1: Temperature/speed normal > > (XEN) CPU0: Temperature/speed normal > > (XEN) CPU1: Temperature/speed normal > > (XEN) CPU0: Temperature/speed normal > > (XEN) CPU2: Temperature/speed normal > > (XEN) CPU3: Temperature/speed normal > > (XEN) CPU0: Temperature/speed normal > > (XEN) CPU2: Temperature/speed normal > > (XEN) CPU3: Temperature/speed normal > > (XEN) CPU1: Temperature/speed normal > > (XEN) CPU0: Temperature above threshold > > (XEN) CPU0: Running in modulated clock mode > > (XEN) CPU1: Temperature/speed normal > > (XEN) CPU2: Temperature/speed normal > > (XEN) CPU3: Temperature/speed normal > > > > While the state changes are important, the non-altered > > state information is not needed. As such add a latch > > mechanism to only print the information if it has > > changed since the last update. > > But isn't the interrupt supposed to happen only when state changes > in the first place? HA! That is what I thought too, but this machine keeps on triggering this interrupt. > > Jan >