[coLinux-devel] colinux is dope! Newbie reports his experiences...

[Gregory M. T. <gmt...@am...>]

Hello, my work for the wine project and as a web programmer make it 
particularly handy to have a PC virtualization capability.  I have 
historically used VMWare -- when I heard about colinux I was very pleased, as 
VMWare is the pits.

As of the 0.6.0 release, I decided to take the plunge and give it a try.  Here 
are a couple of notes on my experiences:

Not a single blue screen of death yet.  Yay!  I cannot say the same for VMWare 
(although I have of course put VMWare though its paces for a much longer 
period of time).

I needed (way) more than 8 cobd devices.  So, I changed CO_MODULE_MAX_COBD in 
include/linux/cooperative.h, and then spent some time scratching my head as 
to why this didn't work (no, the problem wasn't that I needed to recompile 
the kernel after the change :-)).  After some grepping I found the cobd_devs 
assignment in cobd_init().  But, why is this not set to CO_MODULE_MAX_COBD 
(perhaps you plan to implement a kernel argument later (or already did))?  
Further grepping reveals that the constant is only used in the co_module_t 
struct.

I am a Gentoo user and decided to push my luck with CFLAGS and see what 
happens.  So far, I have seen a small degree of unexplained instability on my 
system, but it's quite small and not neccesarily attributable to coLinux.  I 
may scale this back a bit to see if my problems disappear.  For example, 
there is a package that fails to build repeatably, giving a suspicious "out 
of memory" error, allegedly during an "mv" operation.  Also, I have seen some 
crashes in kmail (I think those are attributable to no audio device present, 
kde 3.2 is particularly unforgiving of this).  Here are the C{,XX}FLAGS I 
have used (I have an Athlon XP) to compile "all" my userland stuff (not 
quite, Gentoo censors them sometimes):

"-mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx -m3dnow"

As you can see, these are (deliberately) rather agressive.  Please let me know 
if any of these CPU features are known to be broken in coLinux atm, or, 
oppositely, if I should also be able to add "sse".

Anyhow, it's super-impressive  that all those CPU features seem to be working 
(at least in user-land, see below)...  I will look into the "mv out of 
memory" thing -- I'm not at all convinced that it's not coLinux's fault, as 
it is 100% repeatable which doesn't sound like your typical coLinux register 
snafu.

Now for a bit of possibly bad news.  I wasn't sure if I was supposed to be 
able to get away with this or not, but I tried compiling my kernel optimized 
for Athlon, and without frame pointers.  This kernel ran admirably well, but 
exhibited occasional, non-repeatable crashes in user-level Linux processes 
(i.e., gcc segfaults), typically under heavy cobd disk load.  Should this 
have worked?  Changing back to 586/frame-pointers put me back in business... 
I haven't not tried separating these two to figure out which one(s) 
specifically cause(s) problems.

Stuff that's notably working great:
====

md (raid) -> loopback -> cobd (dos device) (yay!!! That's /home!)

access to my "raw" linux ext3 partitions.

full gentoo KDE sessions via kdm/xdmcp/vnc.

512M of Colinux RAM.


Wierd/broken stuff I've seen:
====

crypto-loop -> cobd (dos device) is apparently broken.

This one is weird.  I noticed it playing music over samba.  On Windows XP, the 
Windows "explorer.exe" process is set to high priority by default (this way 
you can still use the start menu when some regular-priority process goes 
postal).  If I run "explorer" (as a file browser), and right click on some 
file, and then wait a few seconds, leaving the pop-up right-click menu 
on-screen, then CPU utilization will max out and coLinux will starve in a big 
way.  I did not push my luck with these experiments for fear of 
blue-screening my box or panicing coLinux.  But it was enough to stop Winamp 
from reading over samba, that's for sure, and fully repeatable.  Changing the 
process-priority of explorer.exe to "Normal" or lower seems to "solve" this 
problem.


Anyhow, thanks again for all this work, Dan and others.  Also, congratulations 
on the Linux port!  

-- 
gmt