First off, thanks for such great project and for your (and others) efforts on this.
I use Linux for a long time now, but I can hardly remember of any project which blew my mind the way UML does!
i would like to tell that i`m successfully running 2.6.0-test9-um (suse9 and suse8.2 rootfs) on suse9 host with custom vanilla
2.6.0-test9 kernel,patched with skas-patch. i`m in "early-testing-stage", but at the moment it looks quite good :)
it seems that i have also trouble with the "clock-skew issue":
i run 2 uml instances in parallel and do a "while true;do find /;done >/dev/null &" inside both of them.
then i watch host and uml systems with "vmstat 1" - the vmstat on the host behaves like expected.
the vmstat in the uml`s behaves strange: they don`t print their output once per second, but at very irregular intervals.
is this issue also resolved by the "long-standing patch from Sapan Bhatia" ?
answering the question to myself: i think - yes!
is there any time-schedule when we can expect this patch being available or can someone point me to the patch, if it`s somewhere
if this is another "issue" - please someone tell me if i should report a bug on SF bugtracker.
is there any suse people on this list? it seems for me that YAST (SuSE`s setup and configuration tool) has major problems when
started inside UML. Since suse9 is somewhat "uml ready" (skas patch included and uml-install-suse script delivered with distro) i
would really be happy to see this problem resolved.
i this list right for discussing the details or should this go to suse folks directly?
thanks & regards
----- Original Message -----
From: "Jeff Dike" <jdike@...>
To: <mark@...>; "Sapan Bhatia" <bhatia@...>
Sent: Tuesday, November 11, 2003 8:12 PM
Subject: Re: [uml-user] Clock skew? Problem - 'time sleep 1' can take 10 seconds!
> mark@... said:
> > Running 2.4.22-um5 with host skas patch. With a tun/tap driver setup
> > in the um doing ping -f or any measurable amount of network traffic
> > going into the um causes 'time sleep 1' to take much longer (from 2 to
> > 10 seconds typical)
> I have a fix for this in the next patch. It's a long-standing patch from
> Sapan Bhatia which sat in my queue since people hadn't been complaining
> about it. More recently, people have started moaning, so the fix is in.
> Basically, it ties the internal UML clock to the host tsc. It's under the
> control of CONFIG_UML_REAL_TIME_CLOCK, which should normally be left on.
> However, anyone debugging with UML who doesn't care about accurate timers
> may want to turn it off. The reason is that any amount of time spent with
> UML stopped while you stare at gdb will cause a lot of ticks to get backed
> up, and it will deliver them all as soon as you continue UML. I don't know
> if this will take any noticable time, but it's something to consider.