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

[gson%gson.org@localhost (Andreas Gustafsson)]

>Number:         53303
>Category:       port-evbarm
>Synopsis:       Some evbarm-earmv7hf test runs jump to 0x04000000
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-evbarm-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 21 19:35:00 +0000 2018
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current
>Organization:

>Environment:
System: NetBSD
Architecture: arm
Machine: evbarm
>Description:

The TNF testbed for evbarm-earmv7hf runs the tests in qemu from a
preinstalled disk image that is automatically resized on boot, which
requires a reboot.  The problem is that this reboot sometimes fails
with an error message from qemu, as in the following console output:

  [   2.2273094] kern.module.path=/stand/evbarm/8.99.17/modules
  Fri May 18 03:13:45 UTC 2018
  Starting root file system check:
  /dev/rld0a: file system is clean; not checking
  Growing ld0 MBR partition #1 (1112MB -> 1824MB)
  Growing ld0 disklabel (1336MB -> 2048MB)
  Resizing /
  reboot:drebootedebybroot**************************************************| 100%
  [  70.2810153] rebooting...
  qemu-system-arm: Trying to execute code outside RAM or ROM at 0x04000000
  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.

The full log is at:

  http://releng.netbsd.org/b5reports/evbarm-earmv7hf/2018/2018.05.17.08.24.28/test.log

I don't know if this is a bug in NetBSD or in qemu.

>How-To-Repeat:

Review testbed logs.

>Fix: