On Tue, Dec 01, 2015 at 10:19:23AM +0000, Ian Campbell wrote: > On Mon, 2015-11-30 at 18:47 +0000, Anthony PERARD wrote: > > On Mon, Nov 30, 2015 at 09:40:28AM +0000, osstest service owner wrote: > > > flight 65237 qemu-mainline real [real] > > > http://logs.test-lab.xenproject.org/osstest/logs/65237/ > > > > > > Regressions :-( > > > > > > Tests which did not succeed and are blocking, > > > including tests which could not be run: > > > test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. > > > 64579 > > > test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. > > > vs. 64579 > > > > In this test, qemu SIGABRT with "Bad ram offset efffd000" as an error > > message. The test started to fail when osstest started to test with a guest > > with 5000 of memory instead of 768. > > That's still a QEMU and/or Xen bug though, right? > > IOW you aren't trying to suggest this is an osstest bug, I think.
No, I'm not. I was merely pointing out that the issue appear with guest with lots of memory. > NB the size of the guest ram depends on the amount of host RAM available, > so this will vary across hosts. > > The apparent switch to 5000 for test-amd64-i386-xl-qemuu-ovmf-amd64 was > from merlot1 starting in flight 65078, but there was a pass on merlot1 > at 63741. My guess is that a change in one of the other trees between those > two has exposed the issue. Thanks for this pointer. I've started a bisect with qemuu from this flight, since it's quick to reproduce the issue. And the first commit to exhibit the issue is: 4ed023ce2a39ab5812d33cf4d819def168965a7f (Round up RAMBlock sizes to host page sizes). I'll report that upstream. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel