[RTEMS Project] #3037: QEMU fails to exit after test, 4 BSPS

[RTEMS trac]

#3037: QEMU fails to exit after test, 4 BSPS
-------------------------------+------------------------------
 Reporter:  Cillian O'Donnell  |       Owner:  joel.sherrill@…
     Type:  defect             |      Status:  new
 Priority:  normal             |   Milestone:  Indefinite
Component:  bsps               |     Version:  4.12
 Severity:  normal             |  Resolution:
 Keywords:  qemu               |
-------------------------------+------------------------------

Comment (by Chris Johns):

 Replying to [comment:5 Cillian O'Donnell]:
 > Replying to [comment:4 Chris Johns]:
 > > Replying to [comment:3 Cillian O'Donnell]:
 > > > Replying to [ticket:3037 Cillian O'Donnell]:
 > > > > Qemu tests time out as it fails to exit after test is run.
 Hello.exe hangs on the line 'end of test hello world' and requires manual
 exit (crtl+C)
 > >
 > > The `rtems-tester` can be conditionally made to stop a simulator after
 a test if we finally decide the issue is in the simulator. We need to be
 careful not to kill the test if the problem is in the shutdown of the BSP
 due of a lack of a suitable shutdown, a bug or some issue in the tool set
 up.
 > >
 > Ok, any tips on how to determine which of these problems I have?

 You need to examine each BSP:

  1. Does the BSP have suitable reset logic? This could be a hardware
 register that generate a power on reset (POR) or a power down, or a call
 to target resident ROM code that does this. It may mean looking into any
 technical reference detail about the specific target hardware looking for
 something that we could use, for example watch dogs.

  2. Does QEMU support the functionality to match the BSP? If not what does
 QEMU support and does the BSP support it? It may also pay to ask the qemu
 community to see if there is something we are missing.

  3. If QEMU and the BSP cannot be made to align so qemu exits please come
 back so we can discuss possible support in the tester to kill qemu.
 Killing qemu when a test passes is something we can support however what
 happens on failures is more difficult. Further timeouts are hard when
 running parallel qemu jobs because the load on the host changes the
 targets view of real-time vs the hosts view.

 > > > >
 > > > > *** BEGIN OF TEST HELLO WORLD ***
 > > > > Hello World
 > > > > *** END OF TEST HELLO WORLD ***
 > > > > qemu: terminating on signal 2
 > > > >
 > > > > The BSPS affected are
 > > > >
 > > > > ARM: lm3s6965_qemu
 > > > >
 > > > > i386: PC386 (Current RSB-Qemu hangs before test output and
 Couverture-Qemu is as described)
 > > > This anomaly has disappeared with a slight change of Qemu options.
 i386 PC386 now behaves like the rest for both Qemu variants
 > >
 > > What is the change to the options? It would be nice to document here
 what they are.
 > >
 > Yes I should've mentioned this. Using the following 3 sets of options,
 which are more in line with what had worked previously, the tests hangs
 before the output
 >
 > qemu-system-i386 -m 128 -boot b -hda path_to/rtems-boot.img -no-reboot
 -monitor null -serial stdio -nographic -append "--console=com1;boot;"
 -kernel hello.exe
 >
 > or
 >
 > qemu-system-i386 -no-reboot -serial null -serial mon:stdio -nographic
 -kernel hello.exe
 > (in this case 'kill pid' must be issued)
 >
 > or
 >
 > qemu-system-i386 -no-reboot -monitor null -serial stdio -nographic
 -kernel hello.exe
 >

 This aligns to the settings in the `rtems-test` tool:

  https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/qemu.cfg#n51

 > and with a simpler set of options suggested by Sebastian it hangs after
 the output and behaves like the others as detailed above
 >
 > qemu-system-i386 -monitor null -nographic -serial stdio -nodefaults
 -kernel hello.exe
 >

 Just to be clear, what do you mean by "others"? Is this systems that hang
 or the systems that exit qemu to finish the test?

--
Ticket URL: <http://devel.rtems.org/ticket/3037#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project