 
	
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-4.2-testing test] 50412: regressions - FAIL
 >>> On 16.04.15 at 17:21, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.2-testing test] 50412: 
> regressions - 
> FAIL"):
>> On 15.04.15 at 21:09, <osstest@xxxxxxxxxxxxxxx> wrote:
>> >  test-amd64-i386-pair   21 guest-migrate/src_host/dst_host fail REGR. vs. 
>> > 36512
>> >  test-i386-i386-pair    21 guest-migrate/src_host/dst_host fail REGR. vs. 
>> > 36512
>> 
>> These have been persistent since flight 50318. While for the 1st
>> one I can't immediately see what's going wrong, the 2nd and 3rd
>> ones suffer from full SWIOTLBs again on at least one of the two
>> hosts. Could they be told to use a larger SWIOTLB?
> 
> Hrm.  I hadn't noticed that this was a swiotlb problem.
> 
> I'm not convinced it would be correct to add an override to osstest to
> specify a larger swiotlb.  These tests are not doing anything
> particularly strange.
> 
> If the swiotlb is too small then surely that is a kernel tuning bug.
Quite possible, albeit determining the right size is a tough thing to
do, as the kernel - at the time it needs the size - has no idea how
many and what kind of devices it'll have to be able to handle.
> However, I could be persuaded to add a boot option to increase the
> swiotlb size as a workaround for these specific machines if you think
> it might help.  Would you care to specify a specific command line
> option ?
Not really, as this very much depends on system and load. I'm
afraid that would need to be determined experimentally.
> Also, are you sure this isn't our longstanding swiotlb dma bug, that
> some of the machines in the old colo also had ?
No, I'm not sure about this at all.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
 
 | 
|  | Lists.xenproject.org is hosted with RackSpace, monitoring our |