On 13 February 2014 16:31, Alex Bligh wrote:
> The current code (timer_mod_ns_locked) runs the rearm code
> if the modified timer is at the front of the timer queue
> (only). So if you modify B (in your example above) whether
> you extend or reduce the time, it will only 'rearm' if
> B now occurs
On 13 Feb 2014, at 16:20, Peter Maydell wrote:
> On 13 February 2014 16:09, Alex Bligh wrote:
>> I suspect the issue is not walking the lists, but calling
>> qemu_notify, breaking out of mainloop select etc. etc.; that
>> happens on a timer_modify but not on a timer_del. We could
>> fix this so
On 13 February 2014 16:09, Alex Bligh wrote:
> I suspect the issue is not walking the lists, but calling
> qemu_notify, breaking out of mainloop select etc. etc.; that
> happens on a timer_modify but not on a timer_del. We could
> fix this so that it only happened if the timer's expiry
> time was
On 13 Feb 2014, at 15:36, Peter Maydell wrote:
> On 10 February 2014 17:15, Rob Herring wrote:
>> This doesn't appear to be too useful. The AvgLength is large because
>> INT64_MAX / GTIMER_SCALE is used as the next timer value when no timer
>> is needed.
>
> The code already uses timer_del() wh
On 10 February 2014 17:15, Rob Herring wrote:
> This doesn't appear to be too useful. The AvgLength is large because
> INT64_MAX / GTIMER_SCALE is used as the next timer value when no timer
> is needed.
The code already uses timer_del() when no next timer is needed
(that's the "timer disabled" ca
Rob,
>> A while ago a wrote some instrumentation. I can't recall how far I got with
>> testing it, but here it is rebased onto master without so much as a compile
>> test
>> (top 4 commits - ignore the 5th):
>>
>> https://github.com/abligh/qemu/commit/e711816da9831c97f7d8a111b610ef42f7ba69fa
>
On Sat, Feb 8, 2014 at 9:20 AM, Alex Bligh wrote:
> Paolo,
>
> On 8 Feb 2014, at 13:26, Paolo Bonzini wrote:
>
>>>
>>> What I'd suggest you do is run qemu within gdb, and when you have
>>> seen the sluggish behaviour, set a breakpoint in timerlist_run_timers
>>> just before the line saying cb(opaq
Paolo,
On 8 Feb 2014, at 13:26, Paolo Bonzini wrote:
>>
>> What I'd suggest you do is run qemu within gdb, and when you have
>> seen the sluggish behaviour, set a breakpoint in timerlist_run_timers
>> just before the line saying cb(opaque). If I'm right your breakpoint
>> should immediately hit.
Il 08/02/2014 12:48, Alex Bligh ha scritto:
Rob,
On 7 Feb 2014, at 18:15, Rob Herring wrote:
I've bisected a problem with system emulation and SMP kernels using
per cpu timers to this commit. I can reproduce this problem on ARM
emulation with both ARM generic timers (only in 1.7.0) and ARM MPC
Rob,
On 7 Feb 2014, at 18:15, Rob Herring wrote:
> I've bisected a problem with system emulation and SMP kernels using
> per cpu timers to this commit. I can reproduce this problem on ARM
> emulation with both ARM generic timers (only in 1.7.0) and ARM MPCore
> timers. Using a single broadcast ti
I've bisected a problem with system emulation and SMP kernels using
per cpu timers to this commit. I can reproduce this problem on ARM
emulation with both ARM generic timers (only in 1.7.0) and ARM MPCore
timers. Using a single broadcast timer in the guest kernel works fine.
My host is ubuntu 13.1
11 matches
Mail list logo
