On 8/22/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >> > >>> This is QEMU, with dynticks and HPET:
> >> > >>>
> >> > >>> % time seconds usecs/call callserrors syscall
> >> > >>> -- --- --- - -
> -
> >---
> >> > >>> 52.100.002966
>> > >>> This is QEMU, with dynticks and HPET:
>> > >>>
>> > >>> % time seconds usecs/call callserrors syscall
>> > >>> -- --- --- - -
-
>---
>> > >>> 52.100.002966 0 96840
clock_gettime
>> > >>> 19.500.001110
> $ dmesg |grep -i hpet
> ACPI: HPET 7D5B6AE0, 0038 (r1 A M I OEMHPET 5000708 MSFT 97)
> ACPI: HPET id: 0x8086a301 base: 0xfed0
> hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0
> hpet0: 4 64-bit timers, 14318180 Hz
> hpet_resources: 0xfed0 is busy
What kernel version was that? There w
On Wed, Aug 22, 2007 at 02:34:24PM +0200, Andi Kleen wrote:
> On Wed, Aug 22, 2007 at 10:03:32AM +0300, Avi Kivity wrote:
> > Maybe the kernel is using the timer, so userspace can't. Just a guess.
>
> HPET has multiple timers (variable, but typically 2 or 4). The kernel
> only uses timer 0. It's
Dear all,
I have been attempting to get QEMU to run on the Minix operation system
(running on x86, see http://www.minix3.org/ for more info on the OS) for
some time now. I have gotten the program to compile and have added the
Minix-specific a.out-like format to dyngen. I am quite certain this
On Wed, Aug 22, 2007 at 06:38:18PM +0200, Luca wrote:
> and I'm reading it from /proc/config.gz on the guest.
>
> > And a huge number of settime calls?
>
> Yes, maybe some QEMU timer is using an interval < 1ms?
> Dan do you any any idea of what's going on?
Not really...
Blue Swirl wrote:
> On 8/22/07, Alexander Graf <[EMAIL PROTECTED]> wrote:
>
>> - All interceptions (well, maybe I did oversee one or two)
>>
>
> Nice work! For better performance, you should do the op.c checks
> statically at translation time (if possible).
>
>
>
Thanks. I thought about
On 8/22/07, Alexander Graf <[EMAIL PROTECTED]> wrote:
> - All interceptions (well, maybe I did oversee one or two)
Nice work! For better performance, you should do the op.c checks
statically at translation time (if possible).
On 8/22/07, Luca <[EMAIL PROTECTED]> wrote:
> On 8/22/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Luca wrote:
> > >>> This is QEMU, with dynticks and HPET:
> > >>>
> > >>> % time seconds usecs/call callserrors syscall
> > >>> -- --- --- - - ---
On 8/22/07, Luca <[EMAIL PROTECTED]> wrote:
> I see a lot of sub ms timer_settime(). Many of them are the result of
> ->expire_time being less than the current qemu_get_clock().
False alarm, this was a bug in the debug code :D
Luca
On 8/22/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Luca wrote:
> >>> This is QEMU, with dynticks and HPET:
> >>>
> >>> % time seconds usecs/call callserrors syscall
> >>> -- --- --- - -
> >>> 52.100.002966 0 96840
Luca wrote:
>>> This is QEMU, with dynticks and HPET:
>>>
>>> % time seconds usecs/call callserrors syscall
>>> -- --- --- - -
>>> 52.100.002966 0 96840 clock_gettime
>>> 19.500.001110 0
On 8/22/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Luca Tettamanti wrote:
> > Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto:
> >
> >> Luca Tettamanti wrote:
> >>
> >>
> >>> Actually I'm having troubles with cyclesoak (probably it's calibration),
> >>> numbers are not very stable
Luca Tettamanti wrote:
> Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto:
>
>> Luca Tettamanti wrote:
>>
>>
>>> Actually I'm having troubles with cyclesoak (probably it's calibration),
>>> numbers are not very stable across multiple runs...
>>>
>>>
>> I've had goo
Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
>
> > Actually I'm having troubles with cyclesoak (probably it's calibration),
> > numbers are not very stable across multiple runs...
> >
>
> I've had good results with cyclesoak; maybe you need to run
On Wed, Aug 22, 2007 at 10:03:32AM +0300, Avi Kivity wrote:
> Maybe the kernel is using the timer, so userspace can't. Just a guess.
HPET has multiple timers (variable, but typically 2 or 4). The kernel
only uses timer 0. It's possible someone else in user space is using
it though. Try lsof /dev/
Dan Kenigsberg wrote:
> On Tue, Aug 21, 2007 at 01:15:22PM -0700, Matthew Kent wrote:
>
>> On Tue, 2007-21-08 at 21:40 +0200, Luca wrote:
>>
>>> On 8/21/07, Matthew Kent <[EMAIL PROTECTED]> wrote:
>>>
On Sat, 2007-18-08 at 01:11 +0200, Luca Tettamanti wrote:
>
17 matches
Mail list logo
