From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [xen-unstable test] 17595: tolerable FAIL
Date: Wed, 10 Apr 2013 10:26:02 +0100
Message-ID: <5165302A.6000402@eu.citrix.com>
References: <osstest-17595-mainreport@xen.org>
	<51641B9002000078000CBBB6@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <51641B9002000078000CBBB6@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 09/04/13 12:45, Jan Beulich wrote:
>>>> On 09.04.13 at 11:58, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 17595 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/17595/
>>
>> Failures :-/ but no regressions.
>>
>> Tests which are failing intermittently (not blocking):
>>   test-amd64-amd64-xl-sedf-pin  7 debian-install              fail pass in 17594
> Ian,
>
> with Keir's agreement I put in a debugging patch that I hope will
> help spotting why the mites once in a while experience a platform
> timer wrap followed by a hang.
>
> In order for the added code to be fully utilized, you would need
> to add "log_time=<big number>" to *-mite's hypervisor options,
> with <big number> being large enough to cover the longest time
> tests would run (including an eventual timeout). To be on the
> safe side, 0x7fffffff could be used (as the maximum sensible
> value).
>
> Of course, this is going to mildly spam the logs on those systems
> (output resulting from platform timer overflow handling and timer
> calibration code).
>
> Without any option added, some debugging code would
> nevertheless be active, and there is a chance that even in this
> mode the problem could be caught earlier and in a more explicit
> way. But with it happening relatively rarely, I'd prefer the full
> functionality to be enabled from the beginning.
>
> George,
>
> could you put on your 4.3 release requirements list the need to
> revert this debugging patch (commit bd9be94), so that in the
> event that I forget about it we have a way of being reminded
> collectively?

Good idea.

  -George