9vx - os x fix

9vx - os x fix

[Russ Cox]

It looks like calling fork() in OS X 10.5 doesn't
copy the alternate signal stack information into
the child.  If you add the -F flag to keep it from
forking into the background, Andrey says it
works fine.

I'll tweak the code to work around this later.
For now, just use -F.

Russ

Re: [9fans] 9vx - os x fix

[David Leimbach]

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

Yep that's working ok.  Though I'm losing the ability to send capital
letters to X11 in general, I'm not sure if that's an artifact of this or
not.
Dave

On Fri, Jun 27, 2008 at 8:31 AM, Russ Cox <rsc@swtch.com> wrote:

> It looks like calling fork() in OS X 10.5 doesn't
> copy the alternate signal stack information into
> the child.  If you add the -F flag to keep it from
> forking into the background, Andrey says it
> works fine.
>
> I'll tweak the code to work around this later.
> For now, just use -F.
>
> Russ
>
>
>

[-- Attachment #2: Type: text/html, Size: 856 bytes --]

Re: [9fans] 9vx - os x fix

[andrey mirtchovski]

I can send capital letters just fine, but I can't chord with the
option/apple buttons like I'm used to on the native drawterm/acme.
Need to get the latest changes from acme-sac.osx and write a native
client, I suppose :)

Is it supposed to run at full-load? Both cores are fully utilized and
9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
with timeouts.

On Fri, Jun 27, 2008 at 9:39 AM, David Leimbach <leimy2k@gmail.com> wrote:
> Yep that's working ok.  Though I'm losing the ability to send capital
> letters to X11 in general, I'm not sure if that's an artifact of this or
> not.
> Dave
>

Re: [9fans] 9vx - os x fix

[ron minnich]

On Fri, Jun 27, 2008 at 8:56 AM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
>
> Is it supposed to run at full-load? Both cores are fully utilized and
> 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
> main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
> with timeouts.


is that hlt() :-)

ron

Re: [9fans] 9vx - os x fix

[David Leimbach]

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

Funny!  Chording works great for me!  (I'm suspecting my X11  is borked
though, it may be completely unrelated to this project).

On Fri, Jun 27, 2008 at 8:56 AM, andrey mirtchovski <mirtchovski@gmail.com>
wrote:

> I can send capital letters just fine, but I can't chord with the
> option/apple buttons like I'm used to on the native drawterm/acme.
> Need to get the latest changes from acme-sac.osx and write a native
> client, I suppose :)
>
> Is it supposed to run at full-load? Both cores are fully utilized and
> 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
> main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
> with timeouts.
>
> On Fri, Jun 27, 2008 at 9:39 AM, David Leimbach <leimy2k@gmail.com> wrote:
> > Yep that's working ok.  Though I'm losing the ability to send capital
> > letters to X11 in general, I'm not sure if that's an artifact of this or
> > not.
> > Dave
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1406 bytes --]

Re: [9fans] 9vx - os x fix

[andrey mirtchovski]

On Fri, Jun 27, 2008 at 10:34 AM, David Leimbach <leimy2k@gmail.com> wrote:
> Funny!  Chording works great for me!  (I'm suspecting my X11  is borked
> though, it may be completely unrelated to this project).

button 2/3 emulation with option and apple keys works, but i'm using
button1+option+apple to snarf/paste very often, that is the one that
is not working for me (naturally it works with a 3-button mouse).

Re: [9fans] 9vx - os x fix

[Russ Cox]

Replying to many messages... please read to find yours.

> Yep that's working ok.  Though I'm losing the ability to send capital
> letters to X11 in general, I'm not sure if that's an artifact of this or
> not.

Almost certainly not.  The -F workaround is about new fork
semantics.  The capital letters thing may be that I missed an
OS X-specific fix in the X code, imported from p9p.
I hope someone will take it upon themselves to hook the
drawterm Carbon code in instead.

> Is it supposed to run at full-load? Both cores are fully utilized and
> 9vx.OSX uses 187% of the cpu at all times. dtruss reports that the
> main thread is just sitting there doing "select_nocancel(0x0,0x0,0x0)"
> with timeouts.

I think I mentioned this in an earlier message.
I don't know what's going on.  I hope someone
else will figure it out.  It doesn't do this on Linux
or FreeBSD, which suggests that perhaps there
is a bug in the OS X pthreads implementation
(or in 9vx's use of pthreads).  It does make it
somewhat unbearable.

> BTW when i try to make vx32 (under macos 10.5.3) i get the following:
>
> % make
> make: vx32-gcc: Command not found
> make: vx32-gcc: Command not found
> gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I.
> -m80387 -mfp-ret-in-387 -o libvxc/_exit.o libvxc/_exit.c
> libvxc/_exit.c: In function '_exit':
> libvxc/syscall.h:8: error: can't find a register in class 'BREG' while
> reloading 'asm'
> make: *** [libvxc/_exit.o] Error 1

The tree has more than just 9vx.
To build guests for the other apps you need
the vx32-gcc cross-compilers to make
loadable ELF binaries.  If you

	make 9vx/9vx

you'll still get the two "Command not found"
messages, but they're harmless, and the build
should run fine.

> [rminnich@amd64 src]$ make 9vx/9vx
> make: vx32-gcc: Command not found
> make: vx32-gcc: Command not found
> make: *** No rule to make target `9vx/9vx'.  Stop.
>
> OK, I can see that 9vx/9vx target in 9vx/Makefrag, but the alarm just
> went off and I gotta go pretend to work. More later. It would be nice
> to have this work on x86 64 :-)

Use

	make ARCH=i386

to override the result of uname -m.
The 9vx Makefrag knows not to even bother
trying on x86-64.

> trying to answer my own question about high cpu load, it looks like
> 9vx is busy switching all the time. if anyone knows these tracing
> facilities better, please step up :)

You need to figure out which kproc is the one
that is spinning so hard.  The fact that cpu is >100%
suggests that more than one thread is spinning hard,
meaning it is is probably not the single-use guys
like the x11 kproc or the timer kproc.  That leaves
all the kprocs that are waiting on i/o.

Try adding some iprints to sched.c after each
call to psleep(), and I bet you'll find an
insomniac.

Russ

Re: [9fans] 9vx - os x fix

[andrey mirtchovski]

>        make 9vx/9vx

on 10.5.3 that fails with:

gcc -g -O3 -MD -std=gnu99 -I.  -I. -I9vx -I9vx/a -Wall
-Wno-missing-braces -c -o 9vx/main.o 9vx/main.c
9vx/main.c: In function 'sigsegv':
9vx/main.c:491: error: 'struct __darwin_mcontext32' has no member named 'es'
9vx/main.c:492: error: 'struct __darwin_mcontext32' has no member named 'ss'
9vx/main.c:493: error: 'struct __darwin_mcontext32' has no member named 'ss'
make: *** [9vx/main.o] Error 1

turns out that osx exposes __es and __ss for mcontext in
/usr/include/mach/i386/_structs.h. this fixes it:

gcc -D__DARWIN_UNIX03=0 -g -O3 -MD -std=gnu99 -I.  -I. -I9vx -I9vx/a
-Wall -Wno-missing-braces -c -o 9vx/main.o 9vx/main.c

a bit later on:

gcc -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I.  -o libvx32/emu.o libvx32/emu.c
libvx32/emu.c: In function 'vxproc_run':
libvx32/emu.c:1796: error: storage size of 'env' isn't known
make: *** [libvx32/emu.o] Error 1

is fixed identically by:

gcc -D__DARWIN_UNIX03=0 -Ilibvx32 -c -g -O3 -MD -std=gnu99 -I.  -o
libvx32/emu.o libvx32/emu.c

and then later on we fail with:

gcc -g -O3 -MD -std=gnu99 -I.  -I. -I9vx -I9vx/a -Wall
-Wno-missing-braces -c -o 9vx/stub.o 9vx/stub.c
make: *** No rule to make target `libvx32/darwin-asm.o', needed by
`libvx32/libvx32.a'.  Stop.

and darwin-asm.S just seems to be missing everywhere. in fact, there
is no definition for vx32_getcontext:

$ find . -type f | xargs grep vx32_getcontext
./libvx32/emu.c:	if(vx32_getcontext(&env)){
Binary file ./libvx32/emu.o matches
./libvx32/vx32impl.h:int vx32_getcontext(struct i386_thread_state*);
$

Re: [9fans] 9vx - os x fix

[Russ Cox]

Thanks.  Will add the #define.

> and darwin-asm.S just seems to be missing everywhere. in fact, there
> is no definition for vx32_getcontext:

Oops.  That's on my Mac at home;
guess I forgot to copy it off.

Russ

Re: [9fans] 9vx - os x fix

[David Leimbach]

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

On Fri, Jun 27, 2008 at 10:00 AM, Russ Cox <rsc@swtch.com> wrote:

> Replying to many messages... please read to find yours.
>
> > Yep that's working ok.  Though I'm losing the ability to send capital
> > letters to X11 in general, I'm not sure if that's an artifact of this or
> > not.
>
> Almost certainly not.  The -F workaround is about new fork
> semantics.  The capital letters thing may be that I missed an
> OS X-specific fix in the X code, imported from p9p.
> I hope someone will take it upon themselves to hook the
> drawterm Carbon code in instead.


I think there's a high chance Carbon will be "effectively dead" in 6 months
time.  Snow Leopard looms.  (10.6),  Carbon may still exist, but I wouldn't
want to bet any future reliance on it.

It's probably time for a new Cocoa variant of this stuff.

Then again, I have to wonder about Snow Leopard and *any* 32bit
applications...  I didn't go to WWDC and even if I did, I probably couldn't
share that information thanks to Apple's openness.

Dave

[-- Attachment #2: Type: text/html, Size: 1484 bytes --]

Re: [9fans] 9vx - os x fix

[roger peppe]

i discovered a macos x nasty a while ago that
means that if you've forked, then accessing certain
library calls (anything Carbon?) draws an error.

the stated reason for doing this is that the library
doesn't work if the stack has been copied,
but it's a bit of a bugger if you're just forking
to put yourself in the background.

is it possible that you're running up against this?

BTW when i try to make vx32 (under macos 10.5.3) i get the following:

% make
make: vx32-gcc: Command not found
make: vx32-gcc: Command not found
gcc -m32 -c -nostdinc -Ilibvxc/include -g -O3 -MD -std=gnu99 -I.
-m80387 -mfp-ret-in-387 -o libvxc/_exit.o libvxc/_exit.c
libvxc/_exit.c: In function '_exit':
libvxc/syscall.h:8: error: can't find a register in class 'BREG' while
reloading 'asm'
make: *** [libvxc/_exit.o] Error 1


admittedly i've only had the briefest peruse through the documentation,
so i'm probably doing something wrong.

  cheers,
    rog.

On Fri, Jun 27, 2008 at 4:31 PM, Russ Cox <rsc@swtch.com> wrote:
> It looks like calling fork() in OS X 10.5 doesn't
> copy the alternate signal stack information into
> the child.  If you add the -F flag to keep it from
> forking into the background, Andrey says it
> works fine.
>
> I'll tweak the code to work around this later.
> For now, just use -F.
>
> Russ
>
>
>

Re: [9fans] 9vx - os x fix

[andrey mirtchovski]

trying to answer my own question about high cpu load, it looks like
9vx is busy switching all the time. if anyone knows these tracing
facilities better, please step up :)

dappprof (profiles execution, elapsed time is in nanoseconds):

CALL                                                       ELAPSED
libSystem.B.dylib swtch_pri                                67472182
libSystem.B.dylib sched_yield                              75788623
9vx.OSX          unlock                                  297823144
9vx.OSX          lock                                    362717059
9vx.OSX          canlock                                 516405744
libSystem.B.dylib pthread_getspecific                42273900861098
9vx.OSX          getmach                            46118238370761
libSystem.B.dylib pthread_cond_wait                  65330580967450
libSystem.B.dylib _pthread_cond_wait                222897259712785
9vx.OSX          __i686.get_pc_thunk.bx           1256657382372551

dapptrace (traces execution, only a small fragment is listed, without
thread ids):

-> libSystem.B.dylib:sched_yield(0xF30E0, 0xF30E0, 0xB038CE88)
-> libSystem.B.dylib:swtch_pri(0x0, 0x0, 0x0)
-> libSystem.B.dylib:_sysenter_trap(0x93846BC1, 0x0, 0x0)
<- libSystem.B.dylib:swtch_pri = 10
<- libSystem.B.dylib:sched_yield = 21
-> 9vx.OSX:canlock(0xF30E0, 0xF30E0, 0xB038CE88)
-> 9vx.OSX:__i686.get_pc_thunk.bx(0x0, 0x0, 0x0)
<- 9vx.OSX:__i686.get_pc_thunk.bx = 3
-> 9vx.OSX:getmach(0x0, 0x0, 0x0)
-> 9vx.OSX:__i686.get_pc_thunk.bx(0x101, 0x0, 0x0)
<- 9vx.OSX:__i686.get_pc_thunk.bx = 3
-> libSystem.B.dylib:pthread_getspecific(0x101, 0x0, 0x0)
<- libSystem.B.dylib:pthread_getspecific = 12
<- 9vx.OSX:getmach = 31
-> 9vx.OSX:getmach(0x0, 0x0, 0x0)
-> 9vx.OSX:__i686.get_pc_thunk.bx(0x101, 0x0, 0x0)
<- 9vx.OSX:__i686.get_pc_thunk.bx = 3
-> libSystem.B.dylib:pthread_getspecific(0x101, 0x0, 0x0)
<- libSystem.B.dylib:pthread_getspecific = 12
<- 9vx.OSX:getmach = 31
<- 9vx.OSX:canlock = 104
-> libSystem.B.dylib:sched_yield(0xF30E0, 0xF30E0, 0xB038CE88)
-> libSystem.B.dylib:swtch_pri(0x0, 0x0, 0x0)
-> libSystem.B.dylib:_sysenter_trap(0x93846BC1, 0x0, 0x0)
<- libSystem.B.dylib:swtch_pri = 10
<- libSystem.B.dylib:sched_yield = 21

a gdb backtrace:

(gdb) attach 25798
Attaching to process 25798.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ....... done
0x9380a390 in _pthread_cond_wait ()
(gdb) bt
#0  0x9380a390 in _pthread_cond_wait ()
#1  0x93850371 in pthread_cond_wait ()
#2  0x0000abc6 in idlehands () at 9vx/sched.c:47
#3  0x000419cd in _runproc () at 9vx/a/proc.c:542
#4  0x00043696 in sched () at 9vx/a/proc.c:165
#5  0x00009e48 in main (argc=2, argv=0xbffff6ac) at 9vx/main.c:178
(gdb) info thread
Thread 0x10b (local 0xf03) has current state "WAITING"
Thread 0x10b has a suspend count of 0.
(gdb) info threads
  9 process 25798 thread 0x1803  0x937d858a in swtch_pri ()
  8 process 25798 thread 0x1703  0x937d858a in swtch_pri ()
  7 process 25798 thread 0x1603  canlock (l=0xf30e0) at 9vx/stub.c:300
  6 process 25798 thread 0x1503  0x937d858a in swtch_pri ()
  5 process 25798 thread 0x1403  0x937d858a in swtch_pri ()
  4 process 25798 thread 0x1103  0x937d858a in swtch_pri ()
  3 process 25798 thread 0x1003  0x9384e24a in __sigwait ()
  2 process 25798 thread 0xf03  0x9383fbf6 in poll$UNIX2003 ()
* 1 process 25798 thread 0x10b  0x9380a390 in _pthread_cond_wait ()
(gdb)

and an sc_usage run (sc_usage traces system calls, i'm including it
here because it lists what the different threads are doing,
unfortunately you need to see it run interactively to get an idea of
what's happening):

TYPE                            NUMBER        CPU_TIME   WAIT_TIME
------------------------------------------------------------------------------
System         Idle                                      0:00.000
System         Busy                                      0:11.684( 0:00.613)
9vx.OSX        Usermode                       0:16.647

swtch_pri                     72985(5840)     0:00.165   1:25.690( 0:05.028) 4
select_nocancel                  70(1)        0:00.000   0:00.844( 0:00.014)


CURRENT_TYPE              LAST_PATHNAME_WAITED_FOR     CUR_WAIT_TIME THRD# PRI
------------------------------------------------------------------------------
swtch_pri                                                     0:00.011   0   0
swtch_pri                                                     0:00.011   1   0
Pre-empted                                                    0:00.001   2   0
Running U                                                     0:00.001   3  30
swtch_pri                                                     0:00.011   4   0
swtch_pri                                                     0:00.011   5   0