Pavel Dovgalyuk <dovga...@ispras.ru> writes:
>> From: Alex Bennée [mailto:alex.ben...@linaro.org]
>> Pavel Dovgalyuk <dovga...@ispras.ru> writes:
>> >> From: Alex Bennée [mailto:alex.ben...@linaro.org]
>> >> Pavel Dovgalyuk <dovga...@ispras.ru> writes:
>> >
>> >> I ran the following test on both pre-mttcg-merge and my current HEAD
>> >> which includes Paolo's fix series:
>> >>
>> >> ./arm-softmmu/qemu-system-arm -machine type=virt \
>> >> -display none -smp 1 -m 4096 -cpu cortex-a15 \
>> >> -kernel ../images/aarch32-current-linux-initrd-guest.img
>> >> -append "console=ttyAMA0" -serial mon:stdio \
>> >> -net none \
>> >> -icount shift=7,rr=record,rrfile=replay.bin
>> >>
>> >> And then:
>> >>
>> >> ./arm-softmmu/qemu-system-arm -machine type=virt \
>> >> -display none -smp 1 -m 4096 -cpu cortex-a15 \
>> >> -kernel ../images/aarch32-current-linux-initrd-guest.img
>> >> -append "console=ttyAMA0" -serial mon:stdio \
>> >> -net none \
>> >> -icount shift=7,rr=replay,rrfile=replay.bin
>> >>
>> >> And they both ran the same. However I kept running into:
>> >>
>> >> [ 3.542408] RPC: Registered tcp NFSv4.1 backchannel transport module.
>> >> qemu-system-arm: Missing character write event in the replay log
>> >>
>> >> This seems to be a pre-existing
>> >
>> > Does it mean that qemu-arm platform includes some serial devices that were
>> > not detected by the replay?
>>
>> It's the standard ARM platform serial port. When I read replay.txt is
>> said:
>>
>> * Supports i386, x86_64, and ARM hardware platforms.
>>
>> Should we add some qualifications about which machine types are
>> supported? What is you ARM test case for record/replay?
>
> I tested on vexpress-a9 platform with Debian wheezy.
Thanks for that. I now have a test case that I can reproduce failures on
without needing graphics.
I've been investigating if there are any problems with the timer
processing now they have been moved into the TCG thread. The record
stage seems to work fine but I'm having difficulty figuring out why
playback freezes. It seems we get to a point where we are stuck waiting
for a suspiciously exact timer deadline:
replay_account_executed_instructions: instructions_count reached zero
handle_icount_deadline: deadline=471077745280
replay_account_executed_instructions: instructions_count reached zero
handle_icount_deadline: deadline=10000000
[Switching to Thread 0x7fff7a7be700 (LWP 733)]
Thread 3 "qemu-system-arm" hit Breakpoint 1, handle_icount_deadline () at
/home/alex/lsrc/qemu/qemu.git/cpus.c:1184
1184 fprintf(stderr,"%s: no change to deadline=%ld for
%ld\n",
(gdb) c
Continuing.
handle_icount_deadline: no change to deadline=10000000 for 11
Thread 3 "qemu-system-arm" hit Breakpoint 1, handle_icount_deadline () at
/home/alex/lsrc/qemu/qemu.git/cpus.c:1184
1184 fprintf(stderr,"%s: no change to deadline=%ld for
%ld\n",
(gdb) c 10
Will ignore next 9 crossings of breakpoint 1. Continuing.
handle_icount_deadline: no change to deadline=10000000 for 12
handle_icount_deadline: no change to deadline=10000000 for 13
handle_icount_deadline: no change to deadline=10000000 for 14
handle_icount_deadline: no change to deadline=10000000 for 15
handle_icount_deadline: no change to deadline=10000000 for 16
handle_icount_deadline: no change to deadline=10000000 for 17
handle_icount_deadline: no change to deadline=10000000 for 18
handle_icount_deadline: no change to deadline=10000000 for 19
handle_icount_deadline: no change to deadline=10000000 for 20
handle_icount_deadline: no change to deadline=10000000 for 21
(gdb) p replay_state
$1 = {cached_clock = {1490191319270134000, 0}, current_step = 267869922,
instructions_count = 0, data_kind = 12, has_unread_data = 1, file_offset = 0,
block_request_id = 0}
But the timers are all enabled:
(gdb) qemu timers
Processing Realtime timers
clock QEMU_CLOCK_REALTIME is enabled:true, last:-9223372036854775808
Processing Virtual timers
clock QEMU_CLOCK_VIRTUAL is enabled:true, last:-9223372036854775808
timer 34297350016/1 (cb:0x555555a2e952 <ptimer_tick>)
timer 503290000000/1000000 (cb:0x555555bd4d1d <ra_timer_handler>)
Processing Host timers
clock QEMU_CLOCK_HOST is enabled:true, last:1490191319270134000
Processing Virtual RT timers
clock QEMU_CLOCK_VIRTUAL_RT is enabled:true, last:-9223372036854775808
One area I wanted to look back at was comparing the record trace from
pre-mttcg-merge to now to see if any information was missing. However
the bin file has quite a lot of noise in it from changing fields so I
was wondering do you have any sort of dumper tool for comparing the
traces? If not is the format of the trace file specified anywhere?
I found:
#define REPLAY_VERSION 0xe02005
but couldn't find any more than that. Is the format basically just
described by the calls to replay_put_byte?
--
Alex Bennée
