[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 |