fridtjof/qemu-cr16
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Revert "replay: stop us hanging in rr_wait_io_event"

Browse source 
This reverts commit 1f881ea4a4.

That commit causes reverse_debugging.py test failures, and does
not seem to solve the root cause of the problem x86-64 still
hangs in record/replay tests.

The problem with short-cutting the iowait that was taken during
record phase is that related events will not get consumed at the
same points (e.g., reading the clock).

A hang with zero icount always seems to be a symptom of an earlier
problem that has caused the recording to become out of synch with
the execution and consumption of events by replay.

Acked-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-Id: <20240813050638.446172-6-npiggin@gmail.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240813202329.1237572-14-alex.bennee@linaro.org>
This commit is contained in:
Nicholas Piggin 2024-08-13 21:23:21 +01:00 • committed by Alex Bennée
parent 9dbab31d9e
commit 94962ff00d
3 changed files with 1 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

21
replay/replay.c
View file

@ -451,27 +451,6 @@ void replay_start(void)
replay_enable_events();
}
/*
* For none/record the answer is yes.
*/
bool replay_can_wait(void)
{
if (replay_mode == REPLAY_MODE_PLAY) {
/*
* For playback we shouldn't ever be at a point we wait. If
* the instruction count has reached zero and we have an
* unconsumed event we should go around again and consume it.
*/
if (replay_state.instruction_count == 0 && replay_state.has_unread_data) {
return false;
} else {
replay_sync_error("Playback shouldn't have to iowait");
}
}
return true;
}
void replay_finish(void)
{
if (replay_mode == REPLAY_MODE_NONE) {