WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [xen-unstable test] 6532: regressions - trouble: broken/

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 17 Mar 2011 10:43:40 +0000
Cc: ian.jackson@xxxxxxxxxxxxx
Delivery-date: Thu, 17 Mar 2011 03:43:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D81F13B020000780003708F@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <osstest-6532-mainreport@xxxxxxx> <4D81F13B020000780003708F@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 17.03.11 at 11:32, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> On 16.03.11 at 22:58, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
>> flight 6532 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking:
>>  test-amd64-amd64-pv           5 xen-boot                   fail REGR. vs. 
>> 6396
> 
> Seems like this is still failing at the same place in hpet.c, despite
> 23042:599ceb5b0a9b. Is the corresponding xen-syms available
> somewhere so I can sort out the condition to (hopefully) get a
> hint at what's still wrong?

Oh, no, I see what's wrong: That c/s only adjusts a variable local
to hpet_fsb_cap_lookup(), but num_hpets_used gets set to
non-zero only once hpet_fsb_cap_lookup() returns. I think the
local variable should go away altogether, as it being non-zero
(no matter how large) will in any case mean the legacy code path
won't be used.

I'll send another fixup patch shortly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel