qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Brad Campbell <brad@wasp.net.au>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Timing.. was : kqemu processor feature question
Date: Wed, 19 Oct 2005 10:18:43 +0400	[thread overview]
Message-ID: <4355E543.3080409@wasp.net.au> (raw)
In-Reply-To: <43556663.9090203@wasp.net.au>

Brad Campbell wrote:
> John R. Hogerhuis wrote:
> 
>> Anyway everything seems to be fitting your theory about Athlon
>> extensions. It would be nice to catch it in the act of trying to run an
>> Athlon instruction on a Pentium.
> 
> And it was all a bogus trail.. It's *timer* related!
> I made start_rtc_timer() fail (return -1) unconditionally, and voila it 
> boots first time every time, and any Image I throw at it..
> So something in the win2k loader appears to be timing sensitive. I did 
> try the -win2k-hack for a lark, but that only had random results..
> So there is an issue with the RTC handler on this machine by the looks..
> RTC max freq is 1024, so it's not that.. further debugging required


There is something bogus happening in cpu_calibrate_ticks() on this machine

When it boots windows ok I get this..

bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
timer: min=450 us max=50188 us avg=2424 us avg_freq=412.523 Hz
timer: min=243 us max=53085 us avg=2435 us avg_freq=410.534 Hz
timer: min=80 us max=24302 us avg=2416 us avg_freq=413.747 Hz
timer: min=20 us max=60886 us avg=2837 us avg_freq=352.417 Hz

When it fails to start I get this..

bklaptop:/tracks>qemu -hda w2k.img -m 512 -user-net -localtime -enable-audio
timer: min=194 us max=226993 us avg=21626 us avg_freq=46.239 Hz
timer: min=646 us max=550679 us avg=21923 us avg_freq=45.613 Hz
timer: min=939 us max=203745 us avg=21966 us avg_freq=45.525 Hz
timer: min=171 us max=540720 us avg=28920 us avg_freq=34.577 Hz
timer: min=4641 us max=80171 us avg=21372 us avg_freq=46.789 Hz

I might start qemu 30 times, and get 1 boot from 30 starts..

If the machine is loaded when I start qemu it will start every time. (while true ; do echo -n . ; 
done) in the shell is enough to load it up..
It *almost* looks like the tsc is stopping while the machine is in hlt state and cpu_calibrate_ticks 
is getting bogus figures somewhere..

This machine has SpeedStep, but according to the info in /sys/devices/system/cpu/cpu0/cpufreq/
It has not changed state since boot and the governor is set to max_freq..

<Cue swimmy visual wipe effect> "Some time later......"

By changing cpu_calibrate_ticks to do something silly and keep busy while waiting instead of 
sleeping, I get dead reliable results every time.. (Yes, it's horridly ugly, I know it's ugly but it 
works here)

void cpu_calibrate_ticks(void)
{
     int64_t usec, ticks;

     usec = get_clock();
     ticks = cpu_get_real_ticks();
#ifdef _WIN32
     Sleep(50);
#else
     while (get_clock()-usec < 50000) {
         get_clock();
     }
#endif
     usec = get_clock() - usec;
     ticks = cpu_get_real_ticks() - ticks;
     ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
     printf("Ticks_per_sec = %lld\n",ticks_per_sec);
}

bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz
timer: min=305 us max=2995 us avg=980 us avg_freq=1019.897 Hz
timer: min=220 us max=25093 us avg=1020 us avg_freq=979.883 Hz
timer: min=27 us max=9872 us avg=701 us avg_freq=1425.036 Hz

So it appears to give a much more accurate idea of tics_per_sec. (which is where all my timer 
problems on this laptop are coming from)

For testing I run cpu_calibrate_tics 8 times in the init sequence..
This is just changing the above routine only.. no other machine modification or restart...

Before
bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
Ticks_per_sec = 47720193
Ticks_per_sec = 32508223
Ticks_per_sec = 34422776
Ticks_per_sec = 51535607
Ticks_per_sec = 29776765
Ticks_per_sec = 29481406
Ticks_per_sec = 26230393
Ticks_per_sec = 26133451
Winner - RTC enabled
timer: min=2568 us max=850100 us avg=38857 us avg_freq=25.735 Hz
timer: min=5607 us max=153629 us avg=37663 us avg_freq=26.551 Hz

After
bklaptop:/tracks>qemu -hda w2k.img -user-net -m 512 -localtime
Ticks_per_sec = 999800944
Ticks_per_sec = 999876102
Ticks_per_sec = 999892940
Ticks_per_sec = 999842403
Ticks_per_sec = 999893360
Ticks_per_sec = 999882080
Ticks_per_sec = 999877682
Ticks_per_sec = 999871643
Winner - RTC enabled
timer: min=90 us max=10628 us avg=994 us avg_freq=1005.900 Hz
timer: min=33 us max=22670 us avg=1003 us avg_freq=996.085 Hz

It's got me.. I'm off to try and find the processor datasheet on this PIII-M to check the tsc info..

Regards,
Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

  reply	other threads:[~2005-10-19  6:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-18  5:10 [Qemu-devel] kqemu processor feature question Brad Campbell
2005-10-18 18:43 ` Francois Rioux
2005-10-18 20:34   ` Brad Campbell
2005-10-18 21:03     ` John R. Hogerhuis
2005-10-18 21:17       ` Brad Campbell
2005-10-19  6:18         ` Brad Campbell [this message]
2005-10-19 23:09           ` [Qemu-devel] Timing.. was : " Sven Zenker
2005-10-19 18:23         ` [Qemu-devel] " Emmanuel Pellereau
2005-10-19 19:11           ` Brad Campbell
2005-10-19 21:46             ` Jim C. Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4355E543.3080409@wasp.net.au \
    --to=brad@wasp.net.au \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).