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.
> [EMAIL PROTECTED] 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
