On 25 apr 2005, at 23:46, Massimo Dal Zotto wrote:
No, it has nothing to do with the speed of gettimeofday, which on my pc
takes only a few microsecons to execute.
Sorry, I had misread the original remark: I thought it was asking why
qemu suddenly ran (supposedly) 20% slower when calling gettimeof
Hello!
Have anybody work qemu with winxp on a debian box. Installation ok but
after restart i see only a black screen
What is going wrong?
CU
Michael
--
Michael Ott, e-mail: [EMAIL PROTECTED], www.
On Monday 25 April 2005 04:15, Massimo Dal Zotto wrote:
> When qemu runs on an i386 cpu with speedstep enabled the clock of the
> guest os is not in sync with the clock on the host os because the
> vm_timer used for irq 0 generates interrupts at wrong rate when
> the host cpu frequency changes.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Filip Navara wrote:
> Jonas Maebe wrote:
>
>> On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
>>
>>> In the meantime until we find a better solution could you give
>>> us some explanation on why using a microseconds clock from
>>> gettimeofday inst
On Mon, Apr 25, 2005 at 10:24:45PM +0200, Jonas Maebe wrote:
>
> On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
>
> >In the meantime until we find a better solution could you give us some
> >explanation on why using a microseconds clock from gettimeofday instead
> >of rdtsc the guest os clock
Apparently it segfaults when trying to execute address 0xfff0
It told me on an apparently random appearing report which I cannot seem
to reproduce right now. Prior to the latest cvs commits it worked fine.
If I launch qemu with -S option it segfaults as soon as I tell him to
'c'ontinue. As a
On Mon, Apr 25, 2005 at 10:38:42PM +0200, Filip Navara wrote:
> (Once again Windows NT were ahead of time with this idea implemented way
> earlier ;-)
Strange, I got report from people testing stuff in Wine (about the same
RTDSC problem with laptops) finding out that 'gettimeofday' was taking les
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
| Thanks, I just figured out how to do this ;-)
| Here is my /etc/qemu-ifup script in case someone reads this thread :
A little more generic, if you want more nics or use more than 1 VM.
#!/bin/sh
INTERF="$1"
NUM=$(echo $INTERF | sed 's/[^0-9]//g')
sudo
Jonas Maebe wrote:
On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?
Because a system call (which getti
On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?
Because a system call (which gettimeofday is) is very
Thanks I'll try.
As always, Microsoft going the wrong way xD
Did you tried that XP more ago?
El 25/04/2005, a las 7:49, Filip Navara escribió:
Filip Navara wrote:
Natalia Portillo wrote:
Hi!
Windows XP AMD64 version complains about there is no local APIC
saying that the CPU is not an AMD64 one wit
On Mon, Apr 25, 2005 at 08:58:06PM +0200, Fabrice Bellard wrote:
>
> This is not the best way to fix the bug. I see 4 solutions:
>
> - Compute ticks_per_sec every n seconds and update the timers accordingly.
This won't work well if an userpace scaling governor is continuously
changing the cpu fr
Massimo Dal Zotto wrote:
When qemu runs on an i386 cpu with speedstep enabled the clock of the
guest os is not in sync with the clock on the host os because the
vm_timer used for irq 0 generates interrupts at wrong rate when
the host cpu frequency changes.
The problem is that the vm_timer uses the
I can include the patch with a specific option to enable it. The option
will disapear when the hack will be known to be stable.
Fabrice.
Filip Navara wrote:
Filip Navara wrote:
Natalia Portillo wrote:
Hi!
Windows XP AMD64 version complains about there is no local APIC
saying that the CPU is not
On Monday 25 April 2005 19:44, Nick wrote:
> Hey, everyone. I'm quite new to the list, so please tell me to shove
> off if this is the wrong area, but it seems to be the way to go.
>
> It appears that the -nographic option is broken in OS X 10.4. I've
> attempted the binary version as well as com
Hey, everyone. I'm quite new to the list, so please tell me to shove
off if this is the wrong area, but it seems to be the way to go.
It appears that the -nographic option is broken in OS X 10.4. I've
attempted the binary version as well as compiling from 0.6.1 and from
the CVS tree. It d
"Jim C. Brown" <[EMAIL PROTECTED]> writes:
> I just want to point out that your patches break qemu for almost every
> platform
> other than i386.
> [..]
> You probably want to do this, because notsc is only declared for the i386
> platform.
>
> int64_t cpu_get_real_ticks(void)
> {
> int64_
On Mon, Apr 25, 2005 at 01:07:52PM -0400, Jim C. Brown wrote:
>
> I just want to point out that your patches break qemu for almost every
> platform other than i386.
>
> You probably want to do this, because notsc is only declared for the i386
> platform.
>
> int64_t cpu_get_real_ticks(void)
>
On Monday 25 April 2005 18:07, Jim C. Brown wrote:
> On Mon, Apr 25, 2005 at 01:15:32PM +0200, Massimo Dal Zotto wrote:
> > The patch works for me but I don't know if this is the best way of fixing
> > this bug. If anyone has a better suggestion it is welcome.
> >
> > --
> > Massimo Dal Zotto <[EMA
On Mon, Apr 25, 2005 at 01:15:32PM +0200, Massimo Dal Zotto wrote:
> The patch works for me but I don't know if this is the best way of fixing
> this bug. If anyone has a better suggestion it is welcome.
>
> --
> Massimo Dal Zotto <[EMAIL PROTECTED]>
I just want to point out that your patches br
Massimo Dal Zotto <[EMAIL PROTECTED]> writes:
> When qemu runs on an i386 cpu with speedstep enabled the clock of the
> guest os is not in sync with the clock on the host os because the
> vm_timer used for irq 0 generates interrupts at wrong rate when
> the host cpu frequency changes.
>
> The foll
When qemu runs on an i386 cpu with speedstep enabled the clock of the
guest os is not in sync with the clock on the host os because the
vm_timer used for irq 0 generates interrupts at wrong rate when
the host cpu frequency changes.
The problem is that the vm_timer uses the rdtsc instruction and th
PEK,
As the author of QEMUMenu, I can tell you that I only tested it on
Windows 2000/XP hosts as I no longer have anything older that that
around.
There are most likely batch file commands/syntaxes missing from both
NT4 or Windows 9x that are in use, but at present I don't know what
they are...
Hi,
The problem is on the server side, I'll fix this issue this evening.
Thanks,
Hetz
On 4/25/05, senthil <[EMAIL PROTECTED]> wrote:
> Hai,
>
> I am Senthil from chennai,India.I am not able open your forum site after your
>
> updation.Its giving Message Redirecting after that its showing mess
Hai,
I am Senthil from chennai,India.I am not able open your forum site after your
updation.Its giving Message Redirecting after that its showing message done
in the status bar.In the screen nothing will happen.My connection is VSNL
256KBPS Broadband connection and i am using IE and Firefox
Ryan Rempel wrote:
I've been using your patch for releasing the mouse at window edges
(the -autograb path) successfully with a Windows 98 guest. However,
I'm now trying to set up a Windows 2000 guest, and the mouse isn't
releasing -- things work as they would without the patch.
Is this a known issu
26 matches
Mail list logo