qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] kernel 2.6 losing too many ticks
@ 2004-10-01 14:25 zitu
  2004-10-01 18:37 ` bennet
  0 siblings, 1 reply; 4+ messages in thread
From: zitu @ 2004-10-01 14:25 UTC (permalink / raw)
  To: qemu-devel

Hi,

Host=XP
Guest=linux lfs 2.6.5 (from a bootlfs cd iso)

When I try to boot under qemu 0.6 and above, it takes forever.
This does not happen with 2.4 kernels. Anyway to fix this else
than recompiling the 2.6 kernel ?

On a side-line, does qemu-fast exist for win32 ?

Rgds,
Zitu

--

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] kernel 2.6 losing too many ticks
  2004-10-01 14:25 [Qemu-devel] kernel 2.6 losing too many ticks zitu
@ 2004-10-01 18:37 ` bennet
  2004-10-01 23:32   ` Juergen Lock
  2004-10-05  9:07   ` zitu
  0 siblings, 2 replies; 4+ messages in thread
From: bennet @ 2004-10-01 18:37 UTC (permalink / raw)
  To: qemu-devel

A speedup can  be made by passing clock=pit to the kernel parameters (at 
lilo  prompt: linux clock=pit)
But there's still a problem with some timers : sleep 1 sleeps for about 
10 seconds !
I can't find why, and don't know how to get more information to solve 
the problem.

Hope it helps

zitu a écrit :

>Hi,
>
>Host=XP
>Guest=linux lfs 2.6.5 (from a bootlfs cd iso)
>
>When I try to boot under qemu 0.6 and above, it takes forever.
>This does not happen with 2.4 kernels. Anyway to fix this else
>than recompiling the 2.6 kernel ?
>
>On a side-line, does qemu-fast exist for win32 ?
>
>Rgds,
>Zitu
>
>--
>
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] kernel 2.6 losing too many ticks
  2004-10-01 18:37 ` bennet
@ 2004-10-01 23:32   ` Juergen Lock
  2004-10-05  9:07   ` zitu
  1 sibling, 0 replies; 4+ messages in thread
From: Juergen Lock @ 2004-10-01 23:32 UTC (permalink / raw)
  To: bennet; +Cc: qemu-devel

On Fri, Oct 01, 2004 at 07:43:20PM +0000, bennet wrote:
> A speedup can  be made by passing clock=pit to the kernel parameters (at 
> lilo  prompt: linux clock=pit)
> But there's still a problem with some timers : sleep 1 sleeps for about 
> 10 seconds !
> I can't find why, and don't know how to get more information to solve 
> the problem.

This happens when the host's hz is < than the guest's: linux 2.4 kernels
have a default of 100 and 2.6 kernels of 1000 -> factor 10, which you see
with `sleep 1'.  Also, qemu has an internal limit of 1000 (or 1024?),
so if your guest's hz is > than that it'll still be slow even if the
hosts's hz is as fast or faster.  (Maybe this should be made configurable?
some ppl use e.g. hz 5000 to increase gig ethernet performance, like
the FreeSBIE kernel...)

 HTH,
	Juergen

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] kernel 2.6 losing too many ticks
  2004-10-01 18:37 ` bennet
  2004-10-01 23:32   ` Juergen Lock
@ 2004-10-05  9:07   ` zitu
  1 sibling, 0 replies; 4+ messages in thread
From: zitu @ 2004-10-05  9:07 UTC (permalink / raw)
  To: bennet; +Cc: qemu-devel

Quoting bennet:
> A speedup can  be made by passing clock=pit to the kernel parameters (at
> lilo  prompt: linux clock=pit)
> But there's still a problem with some timers : sleep 1 sleeps for about
> 10 seconds !
> I can't find why, and don't know how to get more information to solve
> the problem.
>
> Hope it helps
>

clock=pit worked like a charm.
Thx

Zitu
--

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2004-10-05  9:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-01 14:25 [Qemu-devel] kernel 2.6 losing too many ticks zitu
2004-10-01 18:37 ` bennet
2004-10-01 23:32   ` Juergen Lock
2004-10-05  9:07   ` zitu

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).