From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#26936: grub_cmd_set_date test sometimes fail Date: Sat, 03 Jun 2017 00:54:46 +0200 Message-ID: <871sr2ngp5.fsf@inria.fr> References: <87vap2iqc5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGvTE-00060Q-1y for bug-guix@gnu.org; Fri, 02 Jun 2017 18:55:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGvTD-0004c7-5k for bug-guix@gnu.org; Fri, 02 Jun 2017 18:55:04 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:49400) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGvTD-0004bm-3B for bug-guix@gnu.org; Fri, 02 Jun 2017 18:55:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGvTC-0002xr-T3 for bug-guix@gnu.org; Fri, 02 Jun 2017 18:55:02 -0400 In-Reply-To: <87vap2iqc5.fsf@gmail.com> Sender: "Debbugs-submit" Resent-To: bug-guix@gnu.org Resent-Message-ID: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Maxim Cournoyer Cc: 26936-done@debbugs.gnu.org Hello, Maxim Cournoyer skribis: > I've been encountering this test failure a couple times (3 out of 4 last > build I've tried) recently on my GuixSD x86_64 system when building grub > version 2.02. > > This test failure is not deterministic. The Guix automated build farm > has yet to stumble on that failure. I can reproduce it after a few tries. Upon failure, the =E2=80=98test-suite.log=E2=80=99 file reads: --8<---------------cut here---------------start------------->8--- FAIL: grub_cmd_set_date =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D qemu-system-i386: Trying to execute code outside RAM or ROM at 0xff62f000 This usually means one of the following happened: (1) You told QEMU to execute a kernel for the wrong machine type, and it cr= ashed on startup (eg trying to run a raspberry pi kernel on a versatilepb Q= EMU machine) (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU execute= d a ROM full of no-op instructions until it fell off the end (3) Your guest kernel has a bug and crashed by jumping off into nowhere This is almost always one of the first two, so check your command line and = that you are using the right type of kernel for this machine. If you think option (3) is likely then you can try debugging your guest wit= h the -d debug options; in particular -d guest_errors will cause the log to= include a dump of the guest register state at this point. Execution cannot continue; stopping here. Test failed: 2017-06-02 19:03:48 Friday --8<---------------cut here---------------end--------------->8--- If we add =E2=80=9Cset -x=E2=80=9D in the =E2=80=98grub-shell=E2=80=99 scri= pt, which is used by the test, we see that it invokes QEMU like this: --8<---------------cut here---------------start------------->8--- + ./grub-mkrescue --output=3D/tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t8= --override-directory=3D./grub-core --rom-directory=3D/tmp/guix-build-grub-= 2.02.drv-0/tmp.d2FE5o8cWd --locale-directory=3D./po --themes-directory=3D./= themes /boot/grub/grub.cfg=3D/tmp/guix-build-grub-2.02.drv-0/tmp.IxQUpfc7pT= /boot/grub/testcase.cfg=3D/tmp/guix-build-grub-2.02.drv-0/tmp.v4GOg503yw + '[' xcd =3D xhd ']' + '[' xcd =3D xcd ']' + '[' i386-pc =3D arm64-efi ']' + '[' i386-pc =3D arm-efi ']' + '[' i386-pc =3D powerpc-ieee1275 ']' + device=3D'cdrom ' + bootdev=3D'-boot d' + '[' xcd =3D xfd ']' + '[' xcd =3D xqemu ']' + '[' xcd =3D xmipsel_qemu ']' + '[' xcd =3D xmipsel_fulong2e ']' + '[' xcd =3D xmips_qemu ']' + '[' xcd =3D xcoreboot ']' + '[' i386-pc =3D mipsel-arc ']' + '[' xcd =3D xnet ']' + '[' xcd =3D xemu ']' + timeout -s KILL 60 qemu-system-i386 -nographic -monitor file:/dev/null -s= erial file:/dev/stdout -cdrom /tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t= 8 -boot d --8<---------------cut here---------------end--------------->8--- It would seem that the test uses unique files, which would rule out the possibility of a race condition when running tests with -jN. However, running =E2=80=9Cmake check -j20=E2=80=9D led to another failure, = in =E2=80=98grub_cmd_sleep=E2=80=99: --8<---------------cut here---------------start------------->8--- Interval not in range 1496434911-1496434898 !=3D 10 --8<---------------cut here---------------end--------------->8--- All in all, I=E2=80=99m tempted to think this has to do with running the te= sts in parallel. As a stop-gap measure, I=E2=80=99ve committed a change to run tests sequentially. With this =E2=80=9Cguix build grub --rounds=3D5=E2=80=9D pas= ses for on my x86_64 laptop. Let=E2=80=99s reopen the bug if we find that=E2=80=99s not = enough. Ludo=E2=80=99.