Il 26/10/2013 10:24, Alex Bligh ha scritto:
> How do timer_file and timer_line get filled in? If those still
> need to be put in through code changes, how about taking
> patch 1 of the series (that fills in timer->dbg with this
> information), save for the unnecessary additions to the structure,
>
Paolo,
On 26 Oct 2013, at 08:18, Paolo Bonzini wrote:
> The simple trace backend includes a nanosecond value that is the same as
> rt_clock, so you can correlate the last timer_mod with the next
> iteration in timerlist_run_timers (I would put the tracepoint inside the
> loop, just before the cal
Il 26/10/2013 06:52, Alex Bligh ha scritto:
>
> On 26 Oct 2013, at 00:00, Paolo Bonzini wrote:
>
>> his is a bug in the distro, if it is Linux. There is no reason not to
>> enable the stap trace format when running on Linux (Fedora does for
>> other packages than QEMU, too---most notably glib an
On 26 Oct 2013, at 00:00, Paolo Bonzini wrote:
> his is a bug in the distro, if it is Linux. There is no reason not to
> enable the stap trace format when running on Linux (Fedora does for
> other packages than QEMU, too---most notably glib and glibc).
>
> If it is useful, adding debugging info
Il 25/10/2013 23:30, Alex Bligh ha scritto:
> This patch set adds facilities for debugging timers using the additional
> command line option -timer-debug-log=FILE. If this option is selected,
> a debugging file will be written showing information about the current
> state of timers in the system, w
This patch set adds facilities for debugging timers using the additional
command line option -timer-debug-log=FILE. If this option is selected,
a debugging file will be written showing information about the current
state of timers in the system, which the author feels will be useful for
debugging i
