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 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass version targeted for testing: xen c3a2148192705592d38407ba9919eb1eb151a153 baseline version: xen c3a2148192705592d38407ba9919eb1eb151a153 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 fail test-amd64-i386-xl-credit2 pass test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-xl-sedf pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail test-amd64-i386-xl-winxpsp3-vcpus1 fail test-amd64-i386-xend-qemut-winxpsp3 fail test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Published tested tree is already up to date.
>>> 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 17594Ian, 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? Thanks, Jan
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