Re: Dosemu and clipper applications eating all CPU

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Maurilio Longo wrote:
>> in 1.3.1. Does your prog work in real
>> or protected mode for you?
>  it is in protect mode, I don't know if it could run at all in real 
>  mode.
Perhaps not. This may sound strange, but
I have one prog here which uses Blinker
but can work in both real and prot mode.
The program can be found here:
http://sourceforge.net/tracker/index.php?func=detail&aid=913663&group_id=49784&atid=457448
I also have another Blinker-based prog
which can't work in real mode, and therefore
can't work in any dosemu prior to 1.3.1.
But your Blinker-based program works in
prot. mode even in 1.1.3 - what version
of Blinker extender does it use? Mine
uses 3.30, which was never supported
under dosemu until recently (MaxThink
and stuff).

> Yes, it _does_ and this makes our clipper program unresponsive to user
> commands
But the original problem was that dosemu
eats 100% of CPU. It seems you have a
strictly opposite problem.
But I find that strange also. The code
in int.c I was referring to, when
$_hogthreshold=(2), will call usleep()
every 100th call of int21/ah=1c and
crawles the dosemu for you. But then
you modify the code to make it call
usleep() every 50th path (with a
different delay of INT28), and it works
better, even though it should call usleep()
twice as more frequent than with
$_hogthreshold=(2). Perhaps there is
another location in dosemu where usleep()
is called too frequently (and makes your
app irresponsive). Do you have any
idea where is it?

> But the problem, in my opinion is that usleep() sleeps a fixed amount of time
> (either INT2F_IDLE_SEC or INT28_IDLE_SEC) while it should simply (if at all
> possible on linux) give back the rest of current time slice
May be, maybe not.
I don't think it is a problem. If we
call usleep() every 50th invocation of
int21/ah=1c, and that invocations are
happening once per, say, 10 timeslices,
the difference might not be noticeable.
INT2F_IDLE_USECS is defined as 80ms,
which is 8 Linux timeslices.

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Mgr. Peter Tuharsky wrote:
> database-intensive actions are taken, typically reindexing, the CPU is 
> used by some 1% and thus the operation runs VERY slow too. Computer is 
> bored and user too :o( 
> If somebody fixed these two issues (if I were programmer, I would), 
> I'd very like it.
It is really more about tuning
rather than fixing. And it is not
easy to do because one have to have
all the different test-cases around,
and people do not always provide their
progs for testing.
You can control the speed with
$_hogthreshold option of dosemu.conf
at configure-time, or by a "speed"
command at run-time.
Dosemu is trying to do some guesses
about a CPU usage itself, but right
now it doesn't work very well. It
is necessary for dosemu to at least
calculate the percentage of CPU
power it gives to a DOS task - right
now it doesn't do even this.
It was rumoured that the DOS program
called "tame" does a great job at
calibrating the CPU utilization of
a DOS task under a multitasking system.
You can try setting $_hogthreshold=(0)
and use "tame".
http://www.tamedos.com/

Re: Dosemu and clipper applications eating all CPU

[Mgr. Peter Tuharsky]

    I have similar problem with Clipper app. In some menus, the CPU is 
100% consumed by a loop, an AthlonXP1900+ :o) Note the program ran on 
386 in past. There are two users working simultaneously (one thru thin 
client) and sometimes the response is VERY slow; program even fails to 
display entered letters in realtime.

    In other section I have strictly different problem. When some 
database-intensive actions are taken, typically reindexing, the CPU is 
used by some 1% and thus the operation runs VERY slow too. Computer is 
bored and user too :o(

    If somebody fixed these two issues (if I were programmer, I would), 
I'd very like it. Or can somebody do it for some symbolical amount of 
money? Although there could be a little difficulty paying from my country..

    Have a nice day

    Peter

Re: Dosemu and clipper applications eating all CPU

[Maximiliano Curia]

On Wed, 2004-04-28 at 02:55, Mgr. Peter Tuharsky wrote:
>     I have similar problem with Clipper app. In some menus, the CPU is 
> 100% consumed by a loop, an AthlonXP1900+ :o) Note the program ran on 
> 386 in past. There are two users working simultaneously (one thru thin 
> client) and sometimes the response is VERY slow; program even fails to 
> display entered letters in realtime.

I'm still trying to solve this problem, I've been testing some different
usleep times in different int calls, and the best I could achieve was
75% of CPU usage when idle, 1% when busy, with a very slow
responsiveness, but usable, up to 3 users.

Vanilla dosemu eats 98% CPU, 1-2% when idle, and has an excellent
responsiveness when there is only 1 user. And its still usable with 2
users, if there is a third it becomes unresponsive.

>     In other section I have strictly different problem. When some 
> database-intensive actions are taken, typically reindexing, the CPU is 
> used by some 1% and thus the operation runs VERY slow too. Computer is 
> bored and user too :o(

It's pretty annoying that when the application is doing something it
drops the cpu usage.

>     If somebody fixed these two issues (if I were programmer, I would), 
> I'd very like it. Or can somebody do it for some symbolical amount of 
> money? Although there could be a little difficulty paying from my country..

In my case, it's not about money. I have to fix this so my users don't
kill me. But you are encouraged to donate money to the dosemu project.

-- 
Saludos
/\/\ /\ >< `/

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Maurilio Longo wrote:
> it probably depends on the linker used to create the clipper app, here 
> we use blinker to create a protect mode application
Yes, the prog I now have, also uses
blinker.
Btw, in both dosemu-1.2.1 and 1.3.0
it works only in real mode since the
proper Blinker support was added only
in 1.3.1. Does your prog work in real
or protected mode for you?

> In 1.1.3 (which is the dosemu we use)
1.1.3 is too old and buggy. Why are you
still using it? 1.3.0 or 1.3.1 should
be much better.

> I had to make the changes I told you, and I
> use hog_threshold(0) to have the clipper app to give back all the time 
> it doesn't use.
OK, but not everything is clear.
You said you call usleep() every 50th
call and set $_hogthreshold=(0).
But then, if you set $_hogthreshold=(1)
with an unmodified dosemu, it should
call usleep() on *every* call of int21/ah=2c,
so it must release much more CPU time!
How it happens that it doesn't?
(please see int.c line 1201, where 0x2c
is trapped).

Re: Dosemu and clipper applications eating all CPU

[Maurilio Longo]

Stas,


> > it probably depends on the linker used to create the clipper app, here
> > we use blinker to create a protect mode application
> Yes, the prog I now have, also uses
> blinker.
> Btw, in both dosemu-1.2.1 and 1.3.0
> it works only in real mode since the
> proper Blinker support was added only
> in 1.3.1. Does your prog work in real
> or protected mode for you?
>

it is in protect mode, I don't know if it could run at all in real mode.


> > In 1.1.3 (which is the dosemu we use)
> 1.1.3 is too old and buggy. Why are you
> still using it? 1.3.0 or 1.3.1 should
> be much better.
>

I've switched to 1.2.1 the other day and set hog_threshold to 45, but it uses
nearly 60% of cpu while completely idle (lower values make serial transmission
stop working) and 99% of cpu while inside dos prompt.

>
> > I had to make the changes I told you, and I
> > use hog_threshold(0) to have the clipper app to give back all the time
> > it doesn't use.
> OK, but not everything is clear.
> You said you call usleep() every 50th
> call and set $_hogthreshold=(0).
> But then, if you set $_hogthreshold=(1)
> with an unmodified dosemu, it should
> call usleep() on *every* call of int21/ah=2c,
> so it must release much more CPU time!
> How it happens that it doesn't?
> (please see int.c line 1201, where 0x2c
> is trapped).
> -

Yes, it _does_ and this makes our clipper program unresponsive to user
commands, so I changed INT2F_ to INT28_IDLE_SEC and it was better but not
enough, so I put the 50 calls per usleep() hack, and this way it is responsive
and cpu is around 1, 2%.

But the problem, in my opinion is that usleep() sleeps a fixed amount of time
(either INT2F_IDLE_SEC or INT28_IDLE_SEC) while it should simply (if at all
possible on linux) give back the rest of current time slice, this way if it
has someting to do for, let's say,  1/10th of its time slice, it does it and
then gives 9/10th back to linux instead of sleeping for a certain _fixed_
amount of time.

regards.


--
 __________
|  |  | |__| md2520@mclink.it
|_|_|_|____| Team OS/2 Italia

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

Hello.

Maximiliano Curia wrote:
> Yes, that dosemu doesn't detect the clipper idle calls.
OK, some nice guy at SF finally
provided a clipper-based program
for testing (that's why I like
the SF tracker) and I was able to
have a look at what it does myself.
Indeed it calls int21h/1Ch, although
so infrequently, that it doesn't
seem to be usefull here.
It calls int16h/11h a bit more
frequently, although also rather
rarely.
The attached patch makes it to
release the CPU a little, although
perhaps still not enough.
Also note that clipper will work
in protected mode only in dosemu
1.3.1. On any other versions it
can work in real mode only, which
may have a different CPU loads.

[-- Attachment #2: delay.diff --]
[-- Type: text/plain, Size: 424 bytes --]

--- src/base/bios/int16.c	Sat Mar 13 00:40:05 2004
+++ src/base/bios/int16.c	Sat Mar 13 01:15:29 2004
@@ -126,7 +126,7 @@
       trigger1=0;
     if(trigger1 >= config.hogthreshold*500) {
       if(oldESP==_ESP) {
-        if (++trigger >= config.hogthreshold*20) {
+        if (trigger++ >= (config.hogthreshold - 1) * 20) {
           usleep(INT2F_IDLE_USECS);
           trigger=0;
           keyptr = get_key(extended);

[-- Attachment #3: Type: text/plain, Size: 81 bytes --]

Scanned by evaluation version of Dr.Web antivirus Daemon 
http://drweb.ru/unix/

Re: Dosemu and clipper applications eating all CPU

[Maurilio Longo]

Stas,

it probably depends on the linker used to create the clipper app, here we use
blinker to create a protect mode application, and this application calls
src/base/async/int.c function ms_dos case 0x2C.

In 1.1.3 (which is the dosemu we use) I had to make the changes I told you, and I
use hog_threshold(0) to have the clipper app to give back all the time it doesn't
use.

But, on OS/2 I have the possibility to give back the rest of my cpu time slice,
while in linux it usleep()s a fixed amount of time and this makes the program
sluggish without my changes.

regards.



Stas Sergeev ha scritto:

> Hello.
>
> Maximiliano Curia wrote:
> > Yes, that dosemu doesn't detect the clipper idle calls.
> OK, some nice guy at SF finally
> provided a clipper-based program
> for testing (that's why I like
> the SF tracker) and I was able to
> have a look at what it does myself.
> Indeed it calls int21h/1Ch, although
> so infrequently, that it doesn't
> seem to be usefull here.
> It calls int16h/11h a bit more
> frequently, although also rather
> rarely.
> The attached patch makes it to
> release the CPU a little, although
> perhaps still not enough.
> Also note that clipper will work
> in protected mode only in dosemu
> 1.3.1. On any other versions it
> can work in real mode only, which
> may have a different CPU loads.
>
>   ------------------------------------------------------------------------------
> --- src/base/bios/int16.c       Sat Mar 13 00:40:05 2004
> +++ src/base/bios/int16.c       Sat Mar 13 01:15:29 2004
> @@ -126,7 +126,7 @@
>        trigger1=0;
>      if(trigger1 >= config.hogthreshold*500) {
>        if(oldESP==_ESP) {
> -        if (++trigger >= config.hogthreshold*20) {
> +        if (trigger++ >= (config.hogthreshold - 1) * 20) {
>            usleep(INT2F_IDLE_USECS);
>            trigger=0;
>            keyptr = get_key(extended);
>
>   ------------------------------------------------------------------------------
> Scanned by evaluation version of Dr.Web antivirus Daemon
> http://drweb.ru/unix/

--
 __________
|  |  | |__| md2520@mclink.it
|_|_|_|____| Team OS/2 Italia

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Maurilio Longo wrote:
> clipper runtimes calls int 0x21 sub-function 0x2C, I intercept this one 
> and issue a usleep().
> every 50 times this function gets called or else I had a sluggish dos
OK, thanks. Now any ideas why it
doesn't work right away? Looking
into int.c:1201, I get an impression
that when hogthreshold==1, usleep()
gets called every time the int21/ah=2c
is called. So where's the problem?
Something wrong about CAN_SLEEP() ?

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Maximiliano Curia wrote:
>> Problem of clipper I presume? If it
>> just runs in a busy loop while idle,
>> dosemu can't really help.
>  Yes, that dosemu doesn't detect the clipper idle calls.
But *what kind* of idle calls?
This is the vital info. If you
can't find the answer, then the
problem can't be fixed:)
int 0x28 is the real idle call,
but since dosemu catches that,
I suspect clipper does something
else.

> It still eats the cpu, with nice -n 19, but now the 60% is marked as
> nice.
Yes, and the system must not be
crawled now at least. At least in
a theory:)

> I'm trying to understand the freedos idle.
That might be not the case either.
FreeDOS can just call int16 to do
a blocking wait for a keypress, and
that will do the trick.
You have to find out what exactly
the clipper does however.

Re: Dosemu and clipper applications eating all CPU

[Maurilio Longo]

Stas,

clipper calls time-of-day interrupt when idle, don't have right number 
of interrupt call here at home, but I did write some years ago a little 
TSR to release cpu under OS/2 and I'm using a home-made dosemu 1.0.x at 
work with a changed handling of this interrupt call inside dosemu code, 
tomorrow I'll tell you the right call.

regards.



Stas Sergeev wrote:

>
> Hello.
>
> Maximiliano Curia wrote:
>
>>> Problem of clipper I presume? If it
>>> just runs in a busy loop while idle,
>>> dosemu can't really help.
>>
>>  Yes, that dosemu doesn't detect the clipper idle calls.
>
> But *what kind* of idle calls?
> This is the vital info. If you
> can't find the answer, then the
> problem can't be fixed:)
> int 0x28 is the real idle call,
> but since dosemu catches that,
> I suspect clipper does something
> else.
>
>> It still eats the cpu, with nice -n 19, but now the 60% is marked as
>> nice.
>
> Yes, and the system must not be
> crawled now at least. At least in
> a theory:)
>
>> I'm trying to understand the freedos idle.
>
> That might be not the case either.
> FreeDOS can just call int16 to do
> a blocking wait for a keypress, and
> that will do the trick.
> You have to find out what exactly
> the clipper does however.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
 __________
|  |  | |__|  Maurilio Longo
|_|_|_|____| 

Re: Dosemu and clipper applications eating all CPU

[Maurilio Longo]

Hi,

clipper runtimes calls int 0x21 sub-function 0x2C, I intercept this one and
issue a usleep().

I had to change INT2F_IDLE_SEC to INT28_IDLE_SEC and call usleep() only every
50 times this function gets called or else I had a sluggish dos application. (I
set hog_threshold to 0)

regards.



Maurilio Longo ha scritto:

> Stas,
>
> clipper calls time-of-day interrupt when idle, don't have right number
> of interrupt call here at home, but I did write some years ago a little
> TSR to release cpu under OS/2 and I'm using a home-made dosemu 1.0.x at
> work with a changed handling of this interrupt call inside dosemu code,
> tomorrow I'll tell you the right call.
>
> regards.
>
> Stas Sergeev wrote:
>
> >
> > Hello.
> >
> > Maximiliano Curia wrote:
> >
> >>> Problem of clipper I presume? If it
> >>> just runs in a busy loop while idle,
> >>> dosemu can't really help.
> >>
> >>  Yes, that dosemu doesn't detect the clipper idle calls.
> >
> > But *what kind* of idle calls?
> > This is the vital info. If you
> > can't find the answer, then the
> > problem can't be fixed:)
> > int 0x28 is the real idle call,
> > but since dosemu catches that,
> > I suspect clipper does something
> > else.
> >
> >> It still eats the cpu, with nice -n 19, but now the 60% is marked as
> >> nice.
> >
> > Yes, and the system must not be
> > crawled now at least. At least in
> > a theory:)
> >
> >> I'm trying to understand the freedos idle.
> >
> > That might be not the case either.
> > FreeDOS can just call int16 to do
> > a blocking wait for a keypress, and
> > that will do the trick.
> > You have to find out what exactly
> > the clipper does however.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
>
> --
>  __________
> |  |  | |__|  Maurilio Longo
> |_|_|_|____|
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
 __________
|  |  | |__| md2520@mclink.it
|_|_|_|____| Team OS/2 Italia

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Peter B. Steiger wrote:
>> Problem of clipper I presume? If it
>> just runs in a busy loop while idle,
>> dosemu can't really help.
>  That is exactly the problem.  On NT/XP systems, there is a third-party
>  program called TAMEDOS which intercepts the busy loops and does
>  something so that the CPU is free but the application does not slow
>  down.
If some prog can do that, then dosemu
should either. It is just a matter of
knowing what exactly that program
intercepts ("intercepts the busy loops"
is too obscure).
Maybe a test-case of a clipper prog can
be found somewhere to see what it does?

> know at least one of the loops is a constant keyboard poll:
dosemu is catching that. It is also
trying to catch a mouse polling, and
then people complain that programs
slows down when mouse is inactive:)
It also intercepts the timer polling
and some other things. I have no
guesses as to what's missing.

Re: Dosemu and clipper applications eating all CPU

[Stas Sergeev]

Hello.

Maximiliano Curia wrote:
> I'm trying to run a clipper program inside dosemu.  It runs ok, but it
> eats all the CPU cycles when it's idle.
You haven't specified your dosemu version.

> I've already tried changing the hogthreshold value, with no changes in
> the result.
You must keep that value to 1 - that's
the most optimistic one.

> I've been told this is a known problem,
Problem of clipper I presume? If it
just runs in a busy loop while idle,
dosemu can't really help.

> but I'm hoping it can be fixed
> in some way.
You can assign a lower priority level
to dosemu process, see nice/renice
commands. That will help as to not
crawling the system any more.
You can also try the patches from here:
https://sourceforge.net/tracker/index.php?func=detail&aid=716137&group_id=49784&atid=457450
They release the CPU cycles by making
dosemu slower, which is perhaps also
not what you really want.

The real solution (if it exists) can
be found if you trace your program with
dosdebug, see what it really does when
idle, and think about adding the
appropriate heuristic to dosemu to catch
that case (but it already catches most
of the common "idling" cases).

Re: Dosemu and clipper applications eating all CPU

[Peter B. Steiger]

On Tue, 2004-03-09 at 13:16, Stas Sergeev wrote:
> Problem of clipper I presume? If it
> just runs in a busy loop while idle,
> dosemu can't really help.

That is exactly the problem.  On NT/XP systems, there is a third-party
program called TAMEDOS which intercepts the busy loops and does
something so that the CPU is free but the application does not slow
down.  I have no idea how it works.  Clipper was written in the early
80's when there was no problem for a program to take over the CPU... I
know at least one of the loops is a constant keyboard poll: "Is anyone
pressing a key yet?  What about now?  What about now?" hundreds of times
a second.

-------
Peter B. Steiger
Cheyenne, WY

Re: Dosemu and clipper applications eating all CPU

[Maximiliano Curia]

Hola Stas Sergeev!

El 09/03/2004 a las 23:16 escribiste:
> >I'm trying to run a clipper program inside dosemu.  It runs ok, but it
> >eats all the CPU cycles when it's idle.
> You haven't specified your dosemu version.

Now I'm using dosemu 1.2.0 and 1.2.1, previous versions do the same.

> >I've already tried changing the hogthreshold value, with no changes in
> >the result.
> You must keep that value to 1 - that's
> the most optimistic one.

I have it set at 1.

> >I've been told this is a known problem,
> Problem of clipper I presume? If it
> just runs in a busy loop while idle,
> dosemu can't really help.

Yes, that dosemu doesn't detect the clipper idle calls.

> >but I'm hoping it can be fixed
> >in some way.
> You can assign a lower priority level
> to dosemu process, see nice/renice
> commands. That will help as to not
> crawling the system any more.

It still eats the cpu, with nice -n 19, but now the 60% is marked as
nice.

> You can also try the patches from here:
> https://sourceforge.net/tracker/index.php?func=detail&aid=716137&group_id=49784&atid=457450
> They release the CPU cycles by making
> dosemu slower, which is perhaps also
> not what you really want.

This particular application doesn't have an speed requirement. So, it
may be solution, although not a general one.

> The real solution (if it exists) can
> be found if you trace your program with
> dosdebug, see what it really does when
> idle, and think about adding the
> appropriate heuristic to dosemu to catch
> that case (but it already catches most
> of the common "idling" cases).

I up to it now.
I'm trying to understand the freedos idle.

-- 
"UNIX is basically a simple operating system, but you have to be a genius to
understand the simplicity." -- (Dennis Ritchie)
Saludos /\/\ /\ >< `/

Dosemu and clipper applications eating all CPU

[Maximiliano Curia]

Hi!

I'm trying to run a clipper program inside dosemu.  It runs ok, but it
eats all the CPU cycles when it's idle. 

I've already tried changing the hogthreshold value, with no changes in
the result.

This is a snip of the strace of the process:

--- SIGALRM (Alarm clock) @ 0 (0) ---
<... vm86 resumed> )                    = -1 ENOSYS (Function not
implemented)
ioctl(4, FIONREAD, [0])                 = 0
select(7, [], NULL, NULL, {0, 0})       = 0 (Timeout)
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
vm86(0x1, 0x81a2980, 0xa6, 0xfff8eff1, 0x8) = -1 ENOSYS (Function not
implemented)
vm86(0x1, 0x81a2980, 0xa6, 0xfff8eff1, 0xbffffa34) = -1 ENOSYS (Function
not implemented)
vm86(0x1, 0x81a2980, 0xa6, 0xfff8eff1, 0xbffffa34) = -1 ENOSYS (Function
not implemented)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [RTMIN])
ioctl(4, FIONREAD, [0])                 = 0
select(7, [], NULL, NULL, {0, 0})       = 0 (Timeout)
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
vm86(0x1, 0x81a2980, 0xa6, 0xfff8eff1, 0xbffffa34 <unfinished ...>
--- SIGALRM (Alarm clock) @ 0 (0) ---
<... vm86 resumed> )                    = -1 ENOSYS (Function not
implemented)
ioctl(4, FIONREAD, [0])                 = 0
select(7, [], NULL, NULL, {0, 0})       = 0 (Timeout)
select(7, [6], NULL, NULL, {0, 0})      = 0 (Timeout)
vm86(0x1, 0x81a2980, 0xa6, 0xfff8eff1, 0xbffffa34 <unfinished ...>
--- SIGALRM (Alarm clock) @ 0 (0) ---

And it goes on like that.  While the user is doing nothing, this alarms
repeat themselves many times per second, turning the rest of the machine
into an unusable state.

When idle at the command prompt, the behaviour is notably different:

--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
ioctl(4, FIONREAD, [0])                 = 0
gettimeofday({1078759812, 698914}, NULL) = 0
select(8, [], NULL, NULL, {0, 0})       = 0 (Timeout)
select(8, [7], NULL, NULL, {0, 0})      = 0 (Timeout)
gettimeofday({1078759812, 699517}, NULL) = 0
vm86(0x1, 0x81778a0, 0xa6, 0xfff8dff1, 0) = -1 ENOSYS (Function not
implemented)
vm86(0x1, 0x81778a0, 0xa6, 0xfff8dff1, 0) = -1 ENOSYS (Function not
implemented)
gettimeofday({1078759812, 700033}, NULL) = 0
vm86(0x1, 0x81778a0, 0xa6, 0xfff8dff1, 0) = -1 ENOSYS (Function not
implemented)
vm86(0x1, 0x81778a0, 0xa6, 0xfff8dff1, 0) = -1 ENOSYS (Function not
implemented)
(...) repeating gettimeofday+vm86+vm86 6 more times (...)
gettimeofday({1078759812, 703178}, NULL) = 0
vm86(0x1, 0x81778a0, 0xa6, 0xfff8dff1, 0) = -1 ENOSYS (Function not
implemented)
nanosleep({0, 80000000}, 0)             = ? ERESTART_RESTARTBLOCK (To be
restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---

I've been told this is a known problem, but I'm hoping it can be fixed
in some way.

-- 
Saludos
/\/\ /\ >< `/