Re: port-evbarm/53303: Some evbarm-earmv7hf test runs jump to 0x04000000

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR port-evbarm/53303; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-evbarm/53303: Some evbarm-earmv7hf test runs jump to 0x04000000
Date: Mon, 18 Jun 2018 18:50:54 +0300

 This may not be ARM specific after all - i386 also sometimes gets the same
 message from qemu (but with a different address) when it attempts to reboot.
 For example, from http://releng.netbsd.org/b5reports/i386/2018/2018.06.17.13.12.25/test.log :
 
   [ 6727.3164359] dumping to dev 0,1 offset 2680
   [ 6727.3164359] dump 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 succeeded
   
   
   [ 6727.3164359] rebooting...
   qemu-system-i386: Trying to execute code outside RAM or ROM at 0xefffff53
   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.
 
 -- 
 Andreas Gustafsson, gson%gson.org@localhost