emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#26936: closed (grub_cmd_set_date test sometimes fa


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#26936: closed (grub_cmd_set_date test sometimes fail)
Date: Fri, 02 Jun 2017 22:55:02 +0000

Your message dated Sat, 03 Jun 2017 00:54:46 +0200
with message-id <address@hidden>
and subject line Re: bug#26936: grub_cmd_set_date test sometimes fail
has caused the debbugs.gnu.org bug report #26936,
regarding grub_cmd_set_date test sometimes fail
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
26936: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=26936
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: grub_cmd_set_date test sometimes fail Date: Sun, 14 May 2017 23:31:06 -0700 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Hello,

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.

Maxim

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- Subject: Re: bug#26936: grub_cmd_set_date test sometimes fail Date: Sat, 03 Jun 2017 00:54:46 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Hello,

Maxim Cournoyer <address@hidden> 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
‘test-suite.log’ file reads:

--8<---------------cut here---------------start------------->8---
FAIL: grub_cmd_set_date
=======================

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 
crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb 
QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed 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 with 
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 “set -x” in the ‘grub-shell’ script, which is used by the
test, we see that it invokes QEMU like this:

--8<---------------cut here---------------start------------->8---
+ ./grub-mkrescue --output=/tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t8 
--override-directory=./grub-core 
--rom-directory=/tmp/guix-build-grub-2.02.drv-0/tmp.d2FE5o8cWd 
--locale-directory=./po --themes-directory=./themes 
/boot/grub/grub.cfg=/tmp/guix-build-grub-2.02.drv-0/tmp.IxQUpfc7pT 
/boot/grub/testcase.cfg=/tmp/guix-build-grub-2.02.drv-0/tmp.v4GOg503yw
+ '[' xcd = xhd ']'
+ '[' xcd = xcd ']'
+ '[' i386-pc = arm64-efi ']'
+ '[' i386-pc = arm-efi ']'
+ '[' i386-pc = powerpc-ieee1275 ']'
+ device='cdrom '
+ bootdev='-boot d'
+ '[' xcd = xfd ']'
+ '[' xcd = xqemu ']'
+ '[' xcd = xmipsel_qemu ']'
+ '[' xcd = xmipsel_fulong2e ']'
+ '[' xcd = xmips_qemu ']'
+ '[' xcd = xcoreboot ']'
+ '[' i386-pc = mipsel-arc ']'
+ '[' xcd = xnet ']'
+ '[' xcd = xemu ']'
+ timeout -s KILL 60 qemu-system-i386 -nographic -monitor file:/dev/null 
-serial file:/dev/stdout -cdrom /tmp/guix-build-grub-2.02.drv-0/tmp.cwW8BQx8t8 
-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 “make check -j20” led to another failure, in
‘grub_cmd_sleep’:

--8<---------------cut here---------------start------------->8---
Interval not in range 1496434911-1496434898 != 10
--8<---------------cut here---------------end--------------->8---

All in all, I’m tempted to think this has to do with running the tests
in parallel.

As a stop-gap measure, I’ve committed a change to run tests
sequentially.  With this “guix build grub --rounds=5” passes for on my
x86_64 laptop.  Let’s reopen the bug if we find that’s not enough.

Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]