colinux-devel — Cooperative Linux development mailing list

Re: [coLinux-devel] Max memory of colinux

[Henry N. <hen...@ar...>]

Am 11.03.2009 20:24, schrieb Cliff Zhao:
> It seems to me that the max memory is 1024MB. Is it right? When I try to
> add more memory, it only shows about 1GB.
>
> How can I make it bigger than 1GB.

More is not supported, because currently is not coded inside the coLinux 
kernel. We have only "LOWMEM" coded. So the limit is near 1 GB, exactly 
it is 1000 MB.

-- 
Henry N.

[coLinux-devel] Max memory of colinux

[Cliff Z. <zh...@gm...>]

It seems to me that the max memory is 1024MB. Is it right? When I try to add
more memory, it only shows about 1GB.
How can I make it bigger than 1GB.

Thanks.

Best Regards,
Cliff Zhao

[coLinux-devel] autobuild org.colinux.devel 20090305 00:03:41

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20090305/

 colinux-0.8.0-20090305.src.tgz  (684903 Bytes)
 daemons-0.8.0-20090305.dbg.zip  (590733 Bytes)
 daemons-0.8.0-20090305.zip  (477522 Bytes)
 modules-2.6.22.18-co-0.8.0-20090305.tgz  (2636493 Bytes)
 vmlinux-2.6.22.18-co-0.8.0-20090305.zip  (1674213 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20090305.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.1.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1234 | henryn | 2009-03-05 00:03:41 +0000 (Thu, 05 Mar 2009) | 1 line
Changed paths:
   M /branches/devel/conf/linux-2.6.22.18-config
   M /branches/devel/patch/pci-core.diff
   M /branches/devel/src/colinux/common/ioctl.h
   M /branches/devel/src/colinux/kernel/monitor.c
   M /branches/devel/src/colinux/kernel/pci.c
   M /branches/devel/src/colinux/kernel/video.c
   M /branches/devel/src/colinux/kernel/video.h
   M /branches/devel/src/colinux/user/config.c

* Disable video and audio support from build, is incomplete and not used.
------------------------------------------------------------------------
r1233 | henryn | 2009-03-04 23:53:09 +0000 (Wed, 04 Mar 2009) | 1 line
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/conf/linux-2.6.22.18-config

* Req #2114493: Add iscsi kernel support (CONFIG_ISCSI_TCP).
------------------------------------------------------------------------
r1232 | henryn | 2009-03-04 22:48:20 +0000 (Wed, 04 Mar 2009) | 1 line
Changed paths:
   M /branches/devel/src/colinux/user/config.c

* scsi: Size for disk image is in megabytes. Range check added.
------------------------------------------------------------------------
r1231 | henryn | 2009-03-04 22:45:44 +0000 (Wed, 04 Mar 2009) | 1 line
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/src/colinux/os/winnt/user/install/colinux.nsi
   M /branches/devel/src/colinux/os/winnt/user/install/iDl.ini

* Installer: Image download updated to Fedora 10
------------------------------------------------------------------------

[coLinux-devel] [ colinux-Feature Requests-2114493 ] add iscsi kernel support

[SourceForge.net <no...@so...>]

Feature Requests item #2114493, was opened at 2008-09-16 18:34
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2114493&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Ritesh Raj Sarraf (riteshsarraf)
Assigned to: Nobody/Anonymous (nobody)
Summary: add iscsi kernel support

Initial Comment:
Hi,

I noticed that coLinux is modular but the features enabled is very minimal.

I see room for many more features to be enabled, like iscsi et cetera.

Is there a particular reason why these features are disabled?
Or is it something a user can enable?


Ritesh

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2009-03-05 01:06

Message:
CONFIG_ISCSI_TCP is enabled now, and committed to SVN as revision r1233.
You will find this in the devel snapshots and in next release version
0.7.4.


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2008-11-26 01:34

Message:
New modules are not in coLinux, because we have ported from one of very old
config step by step between kernel versions without changing to many
things. So, simply not all modules are enabled. Some modules does not
working under coLinux. In this case iscsi seems me a module with software
layer only (no hardware device) and should work without any problems.

Please use the 20081123-Snapshot and update the modules from
http://www.henrynestler.com/colinux/testing/devel-0.8.0/20081123-Snapshot/iscsi/

It would be nice if you can give a positive result.

Henry


----------------------------------------------------------------------

Comment By: Ritesh Raj Sarraf (riteshsarraf)
Date: 2008-11-25 13:17

Message:
Hi,

Can you please just comment if this is a valid request ?

I just want to confirm if coLinux by default should be providing the
modules or is it that the user is expected to compile additional modules
are required.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2114493&group_id=98788

Re: [coLinux-devel] Attempting to make coLinux work ... tackling problems running Anaconda

[Henry N. <hen...@ar...>]

Henry Nestler wrote:
> You can add a size parameter to create empty disk images. But be
> carefully, it can shrink the size (and delete) existing images. For
> example to create a 1GB image:
>     scsi0=disk,file.img,1073741824

The size should give in megabytes, not in bytes. The right example with 
1GB is:
   scsi0=disk,file.img,1024

-- 
Henry N.

Re: [coLinux-devel] Attempting to make coLinux work ... tackling problems running Anaconda

[Henry N. <hen...@ar...>]

Hello Bill,

Bill C. Riemers wrote:
> The first code problem I found is the capacity for cobd devices is
> listed as 16.  As none removable devices, anaconda expect the size
> value to be valid.  However, the size is always read as 0, so anaconda
> skip past the devices.   On a hunch, I added a open command into the
> code, and found once a cobd device has been opened, the size value is
> nolonger 0, so anaconda will recognize it.  So the solution is coLinux
> either needs to mark all cobd devices as removable, or it needs to
> initialize the size parameter.

Please try the devel version 0.8.0 from snapshot page.

The size problem should not exist with the scsi driver. This type of 
driver allows partition tables and give the installer the exactly size 
from image file. An example for config:
   scsi0=disk,file.img

You can add a size parameter to create empty disk images. But be 
carefully, it can shrink the size (and delete) existing images. For 
example to create a 1GB image:
   scsi0=disk,file.img,1073741824
In the installer (Anaconda) than you need to create a partition.

> The next problem I came across is that anaconda expects CD's to have
> the cd capacity set.   Since coLinux treats all cobd devices the same,
> none are marked as CD.  So again, I did a quick hack and modified my
> build of anaconda to consider all coLinux devices as both CD's and
> hard disks.

In the devel version exist scsi for cdrom support. This works also with 
mostly installers. An example for config:
   scsi1=cdrom,file.iso

All parameters you will find in colinux-daemon.txt after installing 
coLinux, or in the SVN:
http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/doc/colinux-daemon

-- 
Henry N.

Re: [coLinux-devel] [Fwd: Re: Patch to support drivers compiled into the kernel]

[Henry N. <hen...@ar...>]

Hello Bill,

Bill C Riemers wrote:
> I'm wondering if some of the coLinux developers could hop on the
> networkmanager mailing list?
>
> I submitted my patch for NetworkManager, but it seems the general
> opinion there is that the coLinux network driver is not implemented
> correctly.   The discussion is over my head, and if I'm going to need to
> submit a patch for coLinux instead, then some of the developers should
> give their input to what it should look like.  If the coLinux driver is
> implemented correctly, then a case needs to be made for that, so
> NetworkManager can be patched to accommodate.
>
> Note: For reference, I have attached my patch for NetworkManager.

Have read the thread and answered there:
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/12437

I'm not on the list and don't know how my post will see or not. Here is 
the copy:

This is the output from coLinux 0.8.0 with three network interfaces:

ls -l /sys/bus/pci/drivers/conet/

lrwxrwxrwx 1 root root    0 Mar  4 00:01 0000:00:00.0 ->
../../../../devices/pci0000:00/0000:00:00.0
lrwxrwxrwx 1 root root    0 Mar  4 00:01 0000:00:00.1 ->
../../../../devices/pci0000:00/0000:00:00.1
lrwxrwxrwx 1 root root    0 Mar  4 00:01 0000:00:00.2 ->
../../../../devices/pci0000:00/0000:00:00.2
--w------- 1 root root 4096 Mar  4 00:01 bind
--w------- 1 root root 4096 Mar  4 00:01 new_id
--w------- 1 root root 4096 Mar  4 00:01 unbind

I don't know how to manage the problem under older coLinux. To patch an
older kernel without PCI support is not doable and not needed.

A new release candidate will be out as copy from current devel version
near this or next month.

-- 
Henry N.

[coLinux-devel] [Fwd: Re: Patch to support drivers compiled into the kernel]

[Bill C R. <do...@gm...>]

Hi,

I'm wondering if some of the coLinux developers could hop on the
networkmanager mailing list?

I submitted my patch for NetworkManager, but it seems the general
opinion there is that the coLinux network driver is not implemented
correctly.   The discussion is over my head, and if I'm going to need to
submit a patch for coLinux instead, then some of the developers should
give their input to what it should look like.  If the coLinux driver is
implemented correctly, then a case needs to be made for that, so
NetworkManager can be patched to accommodate.

Note: For reference, I have attached my patch for NetworkManager.


Bill


-------- Original Message --------
Subject: 	Re: Patch to support drivers compiled into the kernel
Date: 	Tue, 3 Mar 2009 19:29:48 +0100
From: 	Kay Sievers <kay...@vr...>
To: 	Bill C Riemers <bri...@re...>
CC: 	Dan Williams <dc...@re...>, Net...@gn...
References: 	<49A...@re...>
<1236093674.27170.11.camel@localhost.localdomain>
<ac3...@ma...>
<1236102533.27170.52.camel@localhost.localdomain>
<ac3...@ma...>
<49A...@re...>



On Tue, Mar 3, 2009 at 19:20, Bill C Riemers <bri...@re...> wrote:
> I'm sorry, it seems the list manager did not deliver all the replies Kay
> Sievers quoted...

> 13: udi = '/org/freedesktop/Hal/devices/net_00_ff_d3_da_b0_00'
>  net.interface = 'eth0'  (string)
>  linux.sysfs_path = '/sys/class/net/eth0'  (string)
>  net.address = '00:ff:d3:da:b0:00'  (string)
>  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)

Seems the driver does not set its parent device properly in the
kernel. That nothing to fix in HAL or NM, it's a rather trivial kernel
driver fix. What's the driver that creates your eth0 interface? It's
usually one of that list:
  ls -l /sys/bus/pci/drivers/

Also note, no recent kernel should set CONFIG_SYSFS_DEPRECATED=y.
Recent udev/HAL does not supports that old sysfs format properly
anymore. You should not see any "/sys/class/..." path in HAL, they
should all start with "/sys/devices/...".

Kay

[coLinux-devel] [ colinux-Feature Requests-2081864 ] properly register coLinux as a service

[SourceForge.net <no...@so...>]

Feature Requests item #2081864, was opened at 2008-08-29 08:29
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: properly register coLinux as a service 

Initial Comment:
if coLinux is fully registered as a service, it can be easily managed from the windows control panel, without necessarily requiring console commands to be executed manually by the user

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2009-03-03 19:25

Message:
This is not possible from installer. The installer has no information about
your configuration (cobdX Blockdvices, ethX network devices).

You need first create a runable config file and than you can use this
config file to create a service.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-03 14:07

Message:
possibly, the OP was referring to the way coLinux is by default installed?
In other words, was this supposed to be about the INSTALLER offering a
service-option?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 06:30

Message:
this is obsolete, you can easily register it manually from the console by
using --install-service

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-16 15:13

Message:
having this would definitively improve the level of integration for colinux
under Windows

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-19 23:09

Message:
still installing it by default as a service that can be managed from the
control panel would be pretty intuitive

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-14 16:59

Message:
colinux already runs just fine as a service, at least it did the last time
I checked (before I moved to Vista x64).  There are a ton of different
programs to register services, I always used cygwin cygrunsrv to do it but
others like srvany from Microsoft should work too.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-09-21 19:07

Message:
this might actually be a good idea?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-1368314 ] Maximum CPU usage per CoLinux service

[SourceForge.net <no...@so...>]

Feature Requests item #1368314, was opened at 2005-11-28 15:38
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1368314&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Maximum CPU usage per CoLinux service

Initial Comment:
Setting a max cpu usage would be ideal for using 
colinux in a virtual server environment, ensuring (on 
multi colinux service machines) that no services 
crunching stops other processes from working. eg, 4 
processes could have 25% processing time each.

Chris

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-03 13:09

Message:
This might be handy, I did notice that running coLinux in the background
does appear to slow down some CPU-intense applications like 3D
games/simulations, so having an option to throttle CPU usage could be
helpful for scenarios where you may not want to terminate coLinux

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1368314&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-2081864 ] properly register coLinux as a service

[SourceForge.net <no...@so...>]

Feature Requests item #2081864, was opened at 2008-08-29 06:29
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: properly register coLinux as a service 

Initial Comment:
if coLinux is fully registered as a service, it can be easily managed from the windows control panel, without necessarily requiring console commands to be executed manually by the user

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-03 13:07

Message:
possibly, the OP was referring to the way coLinux is by default installed?
In other words, was this supposed to be about the INSTALLER offering a
service-option?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 05:30

Message:
this is obsolete, you can easily register it manually from the console by
using --install-service

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-16 14:13

Message:
having this would definitively improve the level of integration for colinux
under Windows

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-19 21:09

Message:
still installing it by default as a service that can be managed from the
control panel would be pretty intuitive

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-14 14:59

Message:
colinux already runs just fine as a service, at least it did the last time
I checked (before I moved to Vista x64).  There are a ton of different
programs to register services, I always used cygwin cygrunsrv to do it but
others like srvany from Microsoft should work too.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-09-21 17:07

Message:
this might actually be a good idea?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

[coLinux-devel] [ colinux-Bugs-2622508 ] slight UI glitch wrt fltk console

[SourceForge.net <no...@so...>]

Bugs item #2622508, was opened at 2009-02-21 04:15
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: slight UI glitch wrt fltk console

Initial Comment:
the fltk console app doesn't seem to handle window resizing events properly, in fact it doesn't even honor terminal events resulting from running "reset" in order to make the console adjust to the new window layout.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-03 13:05

Message:
I could verify that this problem persists even via SSH connections, so it
really isn't specific to the FLTK console, rather it seems to affect most
ncurses-based programs - i.e. resets and window dimension changes do affect
the raw console output, but don't seem to affect many ncurses-based linux
utilities. 

So, this is problably only a very small issue related to terminal
handling/emulation.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 05:39

Message:
that's not really all that much of a problem, after all you are likely to
simply use an ssh client or X client/VNC to connect to coLinux-on the other
hand, the resizing events don't even seem to be honored in a running ssh
client.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-22 02:32

Message:
it doesn't seem to accept the PASTE event either, i.e. you cannot easily
paste text from the clipboard into the shell

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788

Re: [coLinux-devel] Attempting to make coLinux work ... tackling problems running Anaconda

[Bill C. R. <do...@fr...>]

As a follow-up, I figured out a better way to debug and traced the
problem in NetworkManager.   It occurred to me I could run anaconda in
a chroot environment.

It seems that NetworkManager will ignore any device without an
associated driver.  e.g. an info.linux.driver entry for the
net.originating_device.   I will try patching NetworkManager to
by-pass this limitation, and see where that gets us.

Bill

On Sun, Mar 1, 2009 at 11:46 PM, Bill C. Riemers <do...@fr...> wrote:
> I spent a number of hours this weekend attempting to get Anaconda to
> work with coLinux.   coLinux has come a long way, and even the Live CD
> almost works.  I would like to briefly describe some of the problems I
> found, some of the solutions, and where I am stuck right now.
>
> The biggest problem I've had so far is debugging.   I can find no way
> to scroll in the console window.  So tracebacks, and errors quickly
> appear on the screen and disappear.  Is there anyway to redirect the
> console output to a log file or such?  If so, it would make life much
> easier.   For now, I've just been entering print statements in code,
> and sleep commands to give me time to read the output.   It doesn't
> always tell me where it crashed, but it does help me figure out where
> it didn't crash.
>
> The first problem I found is anaconda needs the driver modules.  I
> found simply appending the modules to the initrd.img file works just
> fine to fix this:
>      gunzip -c initrd.img > initrd.cpio
>      tar xfz vmlinux-modules.tar.gz
>      find lib/modules |cpio -o -H newc -A -F initrd.cpio
>      gzip -c initrd.cpio > initrd.img
>
> The first code problem I found is the capacity for cobd devices is
> listed as 16.  As none removable devices, anaconda expect the size
> value to be valid.  However, the size is always read as 0, so anaconda
> skip past the devices.   On a hunch, I added a open command into the
> code, and found once a cobd device has been opened, the size value is
> nolonger 0, so anaconda will recognize it.  So the solution is coLinux
> either needs to mark all cobd devices as removable, or it needs to
> initialize the size parameter.
>
> The next problem I came across is that anaconda expects CD's to have
> the cd capacity set.   Since coLinux treats all cobd devices the same,
> none are marked as CD.  So again, I did a quick hack and modified my
> build of anaconda to consider all coLinux devices as both CD's and
> hard disks.
>
> Next, for some reason NetManager in the initrd.img is unable to
> initialize the network for slirp network, even when I explicitly
> specify the networking parameters.   I've had similar problems in the
> past with qemu, and managed to get around it by using a different
> networking setup.  I will try the same for coLinux, but for now this
> problem stopped me dead in my tracks.
>
> Now, you might think as I did, that we don't need networking.  Just
> specify an ISO image and install from that.   However, the problem is
> the only headless option for anaconda is to use vnc.  But in order to
> use vnc, we need networking.  Otherwise anaconda consistently crashes
> trying to set-up graphical display.  I am not certain that having
> networking, and thus vnc will avoid this crash, but I am certain it
> can not work without networking for a headless install.
>
> The last sticker is going to be the partitioning.  In that there seems
> to be no capacity in anaconda to deal with hard disks of type 16.
> However, once I get past the networking problem I will try and add
> this capability to anaconda.
>
> Any insight others have, especially in the NetworkManager problem and
> how to debug this code would be greatly appreciated.
>
> Bill
>

[coLinux-devel] [ colinux-Bugs-2587396 ] Shutdown coLinux hang host on Windows 2000

[SourceForge.net <no...@so...>]

Bugs item #2587396, was opened at 2009-02-11 03:42
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Daemons (Windows)
Group: None
>Status: Closed
Resolution: Fixed
Priority: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Henry N. (henryn)
Summary: Shutdown coLinux hang host on Windows 2000

Initial Comment:
I report this problem in #2445837
Unfortunate, the problem live also.
I try the autobuild-20090210, it hang also.

step:
1. Boot your linux with cmd
set COLINUX_NO_SMP_WORKAROUND=N
colinux-daemon.exe -t FLTK cocon=116x36 kernel=vmlinux mem=500 cobd0=..\root_fs cobd1=..\swap_fs eth0=ndis-bridge,"本地连接" setcobd=async root=/dev/cobd0 ro

2. login to linux
3. execute 'halt'.
Now, you will found process 'colinux-ndis-net-daemon.exe' can not halt, and host can not do manything(include close system), you must hard-reset your PC.


btw: another info when I use my build-20081209, it work fine, and when I replace vmlinux in build-20090211, it will report "colinux: BUG at /develop/build/linux-2.6.22.18/block/elevator.c:780"
I do not known what's wrong in kernel patch.


----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2009-03-02 22:07

Message:
OK, I will close it now.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-02 11:09

Message:
Great!
I try again with SVN code today, the bug solved.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-27 23:45

Message:
"MmUnmapLockedPages" hangs, if it was called outside of user context.

MSDN says:
"Note that if the call to MmMapLockedPages or MmMapLockedPagesSpecifyCache
specified user mode, the caller must be in the context of the original
process before calling MmUnmapLockedPages."

Changes of SVN revision r1200 (2009-01-04T20:53:09) reverted back on SVN
r1225 now.
On SVN r1226 we now only free the mld, without unmapping it.

Snapshot 20090227 includes this changes.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 03:03

Message:
You are right!
But I can reduce range.

I build the svn code myself.
The last running snapshot found at 2008-12-09
The first with problem found at 2009-01-05
Between them, I found that the kernel API version changed.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-18 22:32

Message:
Hello,

this is not a problem of ndis-bridge only. I have this also without
ndis-bridge. That's why have changed the title line here.

I's something with shutting down sequence of coLinux kernel driver and the
attached daemons under Windows 2000 only.

Host: 256MB RAM, Windows 2000 (no Service packs), single core
Here is my config:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp

CoLinux have only started, and than used the FLTK Menu "Monitor *
Shutdown".
Sometimes this simple configuration above hangs on CMD.EXE, sometimes the
Slirp daemon.
After the shutdown it hangs with these last 3 lines:
  System halted.
  colinux: Linux VM terminated
  colinux: halted, exiting.

If I open ProcessExplorer for this task, then the GUI goes into completely
unusable state. Mouse can move. But all windows are frozen. Only the tilte
line of running Windows task can activate and deactivate by mouse click.
CTRL-ALT-DEL cleans the desktop, but the "logon Windows" comes not up. Only
Power off or Reset key can use to reboot the host.

With this config it hangs very rarely (1 hangs of 30 starts):
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0

If I add more network devices, then the system hangs more often.
For example with eth0 and eth1 it hangs very often:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN"

My fovorite for test is this. This automatically "halt" the Linux directly
after boot is complete (start in runlevel 0):
colinux-daemon kernel=vmlinux init 0 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN" ^
 cofs0=.

The last running snapshot found at 2008-11-30 (no problems).
The first with problem found in snapshot 2009-01-13 (hangs with
eth0+eth1).
Can you confirm this?

Old snapshots exists at
http://www.henrynestler.com/colinux/testing/devel-0.8.0/


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 02:28

Message:
1. My host is Windows2000 SP4, 1GB RAM, Core Duo 2.8GHz
2. When I set 'COLINUX_NO_SMP_WORKAROUND=Y', the
'colinux-ndis-net-daemon.exe' can be close, but 'colinux-console-fltk.exe'
can not, and hang my system also.
3. use cmdline 'init 1', I look 'colinux-ndis-net-daemon.exe' running, and
I got same as (2)
4. I look the info below:
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-11 08:36

Message:
What is the host system? Windows XP or Windows 2000?
Does it hang with COLINUX_NO_SMP_WORKAROUND=Y ?
Does it hang, if you boots without using network? For example by adding
"init 1" to the kernel parameters (starts in runlevel 1).

For the elevator.c:780 you have changed the IO Scheduler to CFQ?
"setcobd=async" does not work in conjunction with "elevator=cfq".
I have added as separate bug artifact #2588147


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

[coLinux-devel] [ colinux-Support Requests-1942381 ] Allocate more then 1 Gb RAM Needed!

[SourceForge.net <no...@so...>]

Support Requests item #1942381, was opened at 2008-04-14 19:30
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1942381&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allocate more then 1 Gb RAM Needed!

Initial Comment:
Please implement support for more then 1 gb ram for user in colinux. 4Gb at least!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-02 19:38

Message:
comment2, 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622064&aid=1942381&group_id=98788

[coLinux-devel] [ colinux-Bugs-2587396 ] Shutdown coLinux hang host on Windows 2000

[SourceForge.net <no...@so...>]

Bugs item #2587396, was opened at 2009-02-11 02:42
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Daemons (Windows)
Group: None
Status: Open
Resolution: Fixed
Priority: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Henry N. (henryn)
Summary: Shutdown coLinux hang host on Windows 2000

Initial Comment:
I report this problem in #2445837
Unfortunate, the problem live also.
I try the autobuild-20090210, it hang also.

step:
1. Boot your linux with cmd
set COLINUX_NO_SMP_WORKAROUND=N
colinux-daemon.exe -t FLTK cocon=116x36 kernel=vmlinux mem=500 cobd0=..\root_fs cobd1=..\swap_fs eth0=ndis-bridge,"本地连接" setcobd=async root=/dev/cobd0 ro

2. login to linux
3. execute 'halt'.
Now, you will found process 'colinux-ndis-net-daemon.exe' can not halt, and host can not do manything(include close system), you must hard-reset your PC.


btw: another info when I use my build-20081209, it work fine, and when I replace vmlinux in build-20090211, it will report "colinux: BUG at /develop/build/linux-2.6.22.18/block/elevator.c:780"
I do not known what's wrong in kernel patch.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-02 10:09

Message:
Great!
I try again with SVN code today, the bug solved.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-27 22:45

Message:
"MmUnmapLockedPages" hangs, if it was called outside of user context.

MSDN says:
"Note that if the call to MmMapLockedPages or MmMapLockedPagesSpecifyCache
specified user mode, the caller must be in the context of the original
process before calling MmUnmapLockedPages."

Changes of SVN revision r1200 (2009-01-04T20:53:09) reverted back on SVN
r1225 now.
On SVN r1226 we now only free the mld, without unmapping it.

Snapshot 20090227 includes this changes.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 02:03

Message:
You are right!
But I can reduce range.

I build the svn code myself.
The last running snapshot found at 2008-12-09
The first with problem found at 2009-01-05
Between them, I found that the kernel API version changed.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-18 21:32

Message:
Hello,

this is not a problem of ndis-bridge only. I have this also without
ndis-bridge. That's why have changed the title line here.

I's something with shutting down sequence of coLinux kernel driver and the
attached daemons under Windows 2000 only.

Host: 256MB RAM, Windows 2000 (no Service packs), single core
Here is my config:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp

CoLinux have only started, and than used the FLTK Menu "Monitor *
Shutdown".
Sometimes this simple configuration above hangs on CMD.EXE, sometimes the
Slirp daemon.
After the shutdown it hangs with these last 3 lines:
  System halted.
  colinux: Linux VM terminated
  colinux: halted, exiting.

If I open ProcessExplorer for this task, then the GUI goes into completely
unusable state. Mouse can move. But all windows are frozen. Only the tilte
line of running Windows task can activate and deactivate by mouse click.
CTRL-ALT-DEL cleans the desktop, but the "logon Windows" comes not up. Only
Power off or Reset key can use to reboot the host.

With this config it hangs very rarely (1 hangs of 30 starts):
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0

If I add more network devices, then the system hangs more often.
For example with eth0 and eth1 it hangs very often:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN"

My fovorite for test is this. This automatically "halt" the Linux directly
after boot is complete (start in runlevel 0):
colinux-daemon kernel=vmlinux init 0 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN" ^
 cofs0=.

The last running snapshot found at 2008-11-30 (no problems).
The first with problem found in snapshot 2009-01-13 (hangs with
eth0+eth1).
Can you confirm this?

Old snapshots exists at
http://www.henrynestler.com/colinux/testing/devel-0.8.0/


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 01:28

Message:
1. My host is Windows2000 SP4, 1GB RAM, Core Duo 2.8GHz
2. When I set 'COLINUX_NO_SMP_WORKAROUND=Y', the
'colinux-ndis-net-daemon.exe' can be close, but 'colinux-console-fltk.exe'
can not, and hang my system also.
3. use cmdline 'init 1', I look 'colinux-ndis-net-daemon.exe' running, and
I got same as (2)
4. I look the info below:
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-11 07:36

Message:
What is the host system? Windows XP or Windows 2000?
Does it hang with COLINUX_NO_SMP_WORKAROUND=Y ?
Does it hang, if you boots without using network? For example by adding
"init 1" to the kernel parameters (starts in runlevel 1).

For the elevator.c:780 you have changed the IO Scheduler to CFQ?
"setcobd=async" does not work in conjunction with "elevator=cfq".
I have added as separate bug artifact #2588147


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

[coLinux-devel] Attempting to make coLinux work ... tackling problems running Anaconda

[Bill C. R. <do...@fr...>]

I spent a number of hours this weekend attempting to get Anaconda to
work with coLinux.   coLinux has come a long way, and even the Live CD
almost works.  I would like to briefly describe some of the problems I
found, some of the solutions, and where I am stuck right now.

The biggest problem I've had so far is debugging.   I can find no way
to scroll in the console window.  So tracebacks, and errors quickly
appear on the screen and disappear.  Is there anyway to redirect the
console output to a log file or such?  If so, it would make life much
easier.   For now, I've just been entering print statements in code,
and sleep commands to give me time to read the output.   It doesn't
always tell me where it crashed, but it does help me figure out where
it didn't crash.

The first problem I found is anaconda needs the driver modules.  I
found simply appending the modules to the initrd.img file works just
fine to fix this:
      gunzip -c initrd.img > initrd.cpio
      tar xfz vmlinux-modules.tar.gz
      find lib/modules |cpio -o -H newc -A -F initrd.cpio
      gzip -c initrd.cpio > initrd.img

The first code problem I found is the capacity for cobd devices is
listed as 16.  As none removable devices, anaconda expect the size
value to be valid.  However, the size is always read as 0, so anaconda
skip past the devices.   On a hunch, I added a open command into the
code, and found once a cobd device has been opened, the size value is
nolonger 0, so anaconda will recognize it.  So the solution is coLinux
either needs to mark all cobd devices as removable, or it needs to
initialize the size parameter.

The next problem I came across is that anaconda expects CD's to have
the cd capacity set.   Since coLinux treats all cobd devices the same,
none are marked as CD.  So again, I did a quick hack and modified my
build of anaconda to consider all coLinux devices as both CD's and
hard disks.

Next, for some reason NetManager in the initrd.img is unable to
initialize the network for slirp network, even when I explicitly
specify the networking parameters.   I've had similar problems in the
past with qemu, and managed to get around it by using a different
networking setup.  I will try the same for coLinux, but for now this
problem stopped me dead in my tracks.

Now, you might think as I did, that we don't need networking.  Just
specify an ISO image and install from that.   However, the problem is
the only headless option for anaconda is to use vnc.  But in order to
use vnc, we need networking.  Otherwise anaconda consistently crashes
trying to set-up graphical display.  I am not certain that having
networking, and thus vnc will avoid this crash, but I am certain it
can not work without networking for a headless install.

The last sticker is going to be the partitioning.  In that there seems
to be no capacity in anaconda to deal with hard disks of type 16.
However, once I get past the networking problem I will try and add
this capability to anaconda.

Any insight others have, especially in the NetworkManager problem and
how to debug this code would be greatly appreciated.

Bill

[coLinux-devel] autobuild org.colinux.devel 20090228 19:26:49

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20090228/

 colinux-0.8.0-20090228.src.tgz  (685387 Bytes)
 daemons-0.8.0-20090228.dbg.zip  (591812 Bytes)
 daemons-0.8.0-20090228.zip  (478739 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

The vmlinux and modules are up to date. Please use last version from
http://www.henrynestler.com/colinux/autobuild/devel-20090205/

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.1.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1230 | henryn | 2009-02-28 19:26:49 +0000 (Sat, 28 Feb 2009) | 1 line
Changed paths:
   M /branches/devel/src/colinux/os/winnt/user/install/iDl.ini

* Installer: Fixup link for "More images on Sourceforge".
------------------------------------------------------------------------
r1229 | henryn | 2009-02-28 18:58:14 +0000 (Sat, 28 Feb 2009) | 1 line
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/src/colinux/os/winnt/user/daemon/service.c

* Enclose spaces in CWD for --install-service/--run-service.
------------------------------------------------------------------------
r1228 | henryn | 2009-02-28 17:54:46 +0000 (Sat, 28 Feb 2009) | 1 line
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/src/colinux/os/winnt/user/install/colinux.nsi
   M /branches/devel/src/colinux/os/winnt/user/install/iDl.ini

* Installer: Image download updated to Ubuntu 7.10
------------------------------------------------------------------------
r1227 | henryn | 2009-02-28 17:48:18 +0000 (Sat, 28 Feb 2009) | 1 line
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/src/colinux/os/winnt/user/install/colinux.nsi
   M /branches/devel/src/colinux/os/winnt/user/install/iDl.ini

* Installer: Image download updated to Fedora 9
------------------------------------------------------------------------

[coLinux-devel] autobuild org.colinux.devel 20090227 22:27:05

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20090227/

 colinux-0.8.0-20090227.src.tgz  (685247 Bytes)
 daemons-0.8.0-20090227.dbg.zip  (591669 Bytes)
 daemons-0.8.0-20090227.zip  (478688 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

The vmlinux and modules are up to date. Please use last version from
http://www.henrynestler.com/colinux/autobuild/devel-20090205/

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.1.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1226 | henryn | 2009-02-27 22:27:05 +0000 (Fri, 27 Feb 2009) | 4 lines
Changed paths:
   M /branches/devel/src/colinux/kernel/monitor.c

* free_shared_page: Call co_os_userspace_unmap anyway, NULL-pointers of
  shared_user_address are checked in co_os_userspace_unmap self.
* Free shared_handle (mdl) all times now, also if we are in kernel context.
  But don't unmap it. See Bug #2587396 and SVN r1200.
------------------------------------------------------------------------
r1225 | henryn | 2009-02-27 21:47:07 +0000 (Fri, 27 Feb 2009) | 1 line
Changed paths:
   M /branches/devel/src/colinux/kernel/monitor.c

* Bug #2587396: Shutdown coLinux hangs host on Windows 2000. Revert SVN r1200.
------------------------------------------------------------------------

[coLinux-devel] [ colinux-Bugs-2587396 ] Shutdown coLinux hang host on Windows 2000

[SourceForge.net <no...@so...>]

Bugs item #2587396, was opened at 2009-02-11 03:42
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Daemons (Windows)
Group: None
Status: Open
>Resolution: Fixed
>Priority: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Henry N. (henryn)
Summary: Shutdown coLinux hang host on Windows 2000

Initial Comment:
I report this problem in #2445837
Unfortunate, the problem live also.
I try the autobuild-20090210, it hang also.

step:
1. Boot your linux with cmd
set COLINUX_NO_SMP_WORKAROUND=N
colinux-daemon.exe -t FLTK cocon=116x36 kernel=vmlinux mem=500 cobd0=..\root_fs cobd1=..\swap_fs eth0=ndis-bridge,"本地连接" setcobd=async root=/dev/cobd0 ro

2. login to linux
3. execute 'halt'.
Now, you will found process 'colinux-ndis-net-daemon.exe' can not halt, and host can not do manything(include close system), you must hard-reset your PC.


btw: another info when I use my build-20081209, it work fine, and when I replace vmlinux in build-20090211, it will report "colinux: BUG at /develop/build/linux-2.6.22.18/block/elevator.c:780"
I do not known what's wrong in kernel patch.


----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2009-02-27 23:45

Message:
"MmUnmapLockedPages" hangs, if it was called outside of user context.

MSDN says:
"Note that if the call to MmMapLockedPages or MmMapLockedPagesSpecifyCache
specified user mode, the caller must be in the context of the original
process before calling MmUnmapLockedPages."

Changes of SVN revision r1200 (2009-01-04T20:53:09) reverted back on SVN
r1225 now.
On SVN r1226 we now only free the mld, without unmapping it.

Snapshot 20090227 includes this changes.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 03:03

Message:
You are right!
But I can reduce range.

I build the svn code myself.
The last running snapshot found at 2008-12-09
The first with problem found at 2009-01-05
Between them, I found that the kernel API version changed.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-18 22:32

Message:
Hello,

this is not a problem of ndis-bridge only. I have this also without
ndis-bridge. That's why have changed the title line here.

I's something with shutting down sequence of coLinux kernel driver and the
attached daemons under Windows 2000 only.

Host: 256MB RAM, Windows 2000 (no Service packs), single core
Here is my config:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp

CoLinux have only started, and than used the FLTK Menu "Monitor *
Shutdown".
Sometimes this simple configuration above hangs on CMD.EXE, sometimes the
Slirp daemon.
After the shutdown it hangs with these last 3 lines:
  System halted.
  colinux: Linux VM terminated
  colinux: halted, exiting.

If I open ProcessExplorer for this task, then the GUI goes into completely
unusable state. Mouse can move. But all windows are frozen. Only the tilte
line of running Windows task can activate and deactivate by mouse click.
CTRL-ALT-DEL cleans the desktop, but the "logon Windows" comes not up. Only
Power off or Reset key can use to reboot the host.

With this config it hangs very rarely (1 hangs of 30 starts):
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0

If I add more network devices, then the system hangs more often.
For example with eth0 and eth1 it hangs very often:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN"

My fovorite for test is this. This automatically "halt" the Linux directly
after boot is complete (start in runlevel 0):
colinux-daemon kernel=vmlinux init 0 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN" ^
 cofs0=.

The last running snapshot found at 2008-11-30 (no problems).
The first with problem found in snapshot 2009-01-13 (hangs with
eth0+eth1).
Can you confirm this?

Old snapshots exists at
http://www.henrynestler.com/colinux/testing/devel-0.8.0/


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 02:28

Message:
1. My host is Windows2000 SP4, 1GB RAM, Core Duo 2.8GHz
2. When I set 'COLINUX_NO_SMP_WORKAROUND=Y', the
'colinux-ndis-net-daemon.exe' can be close, but 'colinux-console-fltk.exe'
can not, and hang my system also.
3. use cmdline 'init 1', I look 'colinux-ndis-net-daemon.exe' running, and
I got same as (2)
4. I look the info below:
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-11 08:36

Message:
What is the host system? Windows XP or Windows 2000?
Does it hang with COLINUX_NO_SMP_WORKAROUND=Y ?
Does it hang, if you boots without using network? For example by adding
"init 1" to the kernel parameters (starts in runlevel 1).

For the elevator.c:780 you have changed the IO Scheduler to CFQ?
"setcobd=async" does not work in conjunction with "elevator=cfq".
I have added as separate bug artifact #2588147


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

[coLinux-devel] [ colinux-Bugs-2587396 ] Shutdown coLinux hang host on Windows 2000

[SourceForge.net <no...@so...>]

Bugs item #2587396, was opened at 2009-02-11 02:42
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Daemons (Windows)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shutdown coLinux hang host on Windows 2000

Initial Comment:
I report this problem in #2445837
Unfortunate, the problem live also.
I try the autobuild-20090210, it hang also.

step:
1. Boot your linux with cmd
set COLINUX_NO_SMP_WORKAROUND=N
colinux-daemon.exe -t FLTK cocon=116x36 kernel=vmlinux mem=500 cobd0=..\root_fs cobd1=..\swap_fs eth0=ndis-bridge,"本地连接" setcobd=async root=/dev/cobd0 ro

2. login to linux
3. execute 'halt'.
Now, you will found process 'colinux-ndis-net-daemon.exe' can not halt, and host can not do manything(include close system), you must hard-reset your PC.


btw: another info when I use my build-20081209, it work fine, and when I replace vmlinux in build-20090211, it will report "colinux: BUG at /develop/build/linux-2.6.22.18/block/elevator.c:780"
I do not known what's wrong in kernel patch.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 02:03

Message:
You are right!
But I can reduce range.

I build the svn code myself.
The last running snapshot found at 2008-12-09
The first with problem found at 2009-01-05
Between them, I found that the kernel API version changed.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-18 21:32

Message:
Hello,

this is not a problem of ndis-bridge only. I have this also without
ndis-bridge. That's why have changed the title line here.

I's something with shutting down sequence of coLinux kernel driver and the
attached daemons under Windows 2000 only.

Host: 256MB RAM, Windows 2000 (no Service packs), single core
Here is my config:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp

CoLinux have only started, and than used the FLTK Menu "Monitor *
Shutdown".
Sometimes this simple configuration above hangs on CMD.EXE, sometimes the
Slirp daemon.
After the shutdown it hangs with these last 3 lines:
  System halted.
  colinux: Linux VM terminated
  colinux: halted, exiting.

If I open ProcessExplorer for this task, then the GUI goes into completely
unusable state. Mouse can move. But all windows are frozen. Only the tilte
line of running Windows task can activate and deactivate by mouse click.
CTRL-ALT-DEL cleans the desktop, but the "logon Windows" comes not up. Only
Power off or Reset key can use to reboot the host.

With this config it hangs very rarely (1 hangs of 30 starts):
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0

If I add more network devices, then the system hangs more often.
For example with eth0 and eth1 it hangs very often:
colinux-daemon kernel=vmlinux mem=64 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN"

My fovorite for test is this. This automatically "halt" the Linux directly
after boot is complete (start in runlevel 0):
colinux-daemon kernel=vmlinux init 0 ^
 cobd0=Debian-4.0r0-etch.ext3 root=/dev/cobd0 ^
 eth0=slirp ^
 eth1=ndis-bridge,"LAN" ^
 cofs0=.

The last running snapshot found at 2008-11-30 (no problems).
The first with problem found in snapshot 2009-01-13 (hangs with
eth0+eth1).
Can you confirm this?

Old snapshots exists at
http://www.henrynestler.com/colinux/testing/devel-0.8.0/


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 01:28

Message:
1. My host is Windows2000 SP4, 1GB RAM, Core Duo 2.8GHz
2. When I set 'COLINUX_NO_SMP_WORKAROUND=Y', the
'colinux-ndis-net-daemon.exe' can be close, but 'colinux-console-fltk.exe'
can not, and hang my system also.
3. use cmdline 'init 1', I look 'colinux-ndis-net-daemon.exe' running, and
I got same as (2)
4. I look the info below:
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2009-02-11 07:36

Message:
What is the host system? Windows XP or Windows 2000?
Does it hang with COLINUX_NO_SMP_WORKAROUND=Y ?
Does it hang, if you boots without using network? For example by adding
"init 1" to the kernel parameters (starts in runlevel 1).

For the elevator.c:780 you have changed the IO Scheduler to CFQ?
"setcobd=async" does not work in conjunction with "elevator=cfq".
I have added as separate bug artifact #2588147


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2587396&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-1898496 ] prepackaged GUI image

[SourceForge.net <no...@so...>]

Feature Requests item #1898496, was opened at 2008-02-21 08:05
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1898496&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: prepackaged GUI image

Initial Comment:
The slashdot discussion (http://developers.slashdot.org/developers/04/04/12/211236.shtml?tid=106) shows quite well that many users would find it easier if there was a prepackaged version that comes with all the necessary programs and configs to easily run a UI (i.e. X11/KDE) version on top of coLinux.

Something like this would preferably come with the necessary X server for the windows side of things and be sufficiently preconfigured

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 05:42

Message:
I would agree, this really isn't the scope of the project, there are
already such pre-packaged versions provided by 3rd parties (i.e. andLinux).

----------------------------------------------------------------------

Comment By: George P Boutwell (gboutwel)
Date: 2008-11-21 19:59

Message:
The original author and I had a few discussions about this back when we
first started the port to 2.6 kernels...  The current developers may have
different opinions, but I tend to agree with what was decided then.  To
summarize:

coLinux project's main purpose is to provide the patched kernel and host
machine drivers necessary to accomplish fast (near native performance)
virtualized Linux.  With the few developers working on the project is is
completely unrealistic to expect or extend this purpose beyond that. 
Focusing on that, it was decided that coLinux as a project would not go out
of it's way to build and support an installer which included everything for
graphical images, this in turn allowed several projects to be built on
coLinux that servered that purpose similar to that of andLinux (used to be
one called Colonize or something like that too but couldn't find it on
Source Forge today when I looked).

Henry, you think this choice to continue to focus on our main goal of
providing the kernel and drivers for a fast virtualized linux is the right
one, then you can probably consider this request resolved.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-31 20:33

Message:
Logged In: NO 

this is a rather academic discussion, those who tackle this idea are going
to decide what tools and languages they use

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-31 17:29

Message:
Logged In: NO 

"
Most
mainstream scripting languages are well-supported on a rather wide number
of platforms, unlike C# development tools, which still require numerous
non-standard dependencies to be properly installed and set up for each
platform individually.
"

Sorry, but this isin't true! To develope using C# you can use mono to
compile the stuff you write on all supported platform, windows too. You can
write it with any ide/rad you like, naturally there are tools to do like
monodevelop on linux and sharpdevelop/visual studio (express) on windows.
This is the same for any scripting language: you need the runtime to
execute the script and any editor to write the stuff

I didn't see any kinda of non-standard dependencies:
- On windows, you have the runtime simply doing updates
- On linux, many major distros has it ((open)suse, ubuntu, fedora,
gentoo)

Another example: if you use GTK you need binding ... like any other
programming language that doesn't resides directly on the libraries (note:
technically you can compile in the bindings using a couple of mono tools)



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-31 05:55

Message:
Logged In: NO 

I think, this frontend would be Win32-specific in any way, so it really
doesn't matter what language is used for implementation, however it may be
easier to favor an implementation language that is commonly and widely
known within the community of potential contributors, so that future
maintenance of such a frontend would not be limited to an unnecessarily
small group of contributor who are sufficiently familiar with the
corresponding language. Using a scripting language such as Python or Ruby
on the other hand, brings the added advantage that potential
contributors/maintainers of such a frontend would not necessarily have to
install any complex dependencies (think IDE, compilers, runtime libs). Most
mainstream scripting languages are well-supported on a rather wide number
of platforms, unlike C# development tools, which still require numerous
non-standard dependencies to be properly installed and set up for each
platform individually.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 19:16

Message:
Logged In: NO 

Just a note to the previous comment ...

if necessary you can use python too for development using ironpython!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 19:14

Message:
Logged In: NO 

Python is awesome, i know, but why not C#?

Mono is distribuited with major linux systems and on windows you're fully
integrated with .NET! I think that a lot of users are windows based so a
fully native interface and a fully integrated application can do better
than a python application

Another really important stuff is that with .NET you can easely build two
interfaces and load the preferred at startup time simply checking the
operative system ... with the interfaces that relies on a set of
functionalities implemented in a backend


----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2008-08-29 18:50

Message:
Logged In: YES 
user_id=579204
Originator: NO

If somebody has knowledges about Python, then here are some of GUI scripts
for coLinux configuration, that has to be finish:

http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/configurator/

It's very old. First needs to remove the outdated XML from that.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 16:26

Message:
Logged In: NO 

The following site contains a listing of available GUI toolkit bindings
for python, including a section about UI-building toolkits (e.g. dialog
editors):

http://wiki.python.org/moin/GuiProgramming

In addition, here's  a site providing a full tutorial about PyQT
programming:

http://www.commandprompt.com/community/pyqt/book1
http://wiki.python.org/moin/PyQt

PythonStudio includes a full GUI editor, as well:
http://www.codeplex.com/IronPythonStudio

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 06:57

Message:
Logged In: NO 

thinking about it, the most promising approach would probably be to simply
implement this totally separate, using a scripting language and a GUI
toolkit, i.e. something like python or ruby with GTK/QT bindings. This way,
it would not unnecessarily affect any of the existing code, would be very
much straight forward and also flexible and easily extendsible for future
changes

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 06:24

Message:
Logged In: NO 

something like this would probably be best implemented as a separate,
standaline "profile manager", so that creating/editing and deleting
profiles can be done via this app, and starting a profile would only entail
passing the stored parameters to the corresponding binaries, this would
keep the overhead to a minimum.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-08-29 06:03

Message:
Logged In: NO 

see "andLinux"

however, usability could still be somewhat improved for users with a
non-nix background, in particular the whole setup process should either be
more intuitive or simply provide some more GUI frontends, i.e. by allowing
the most common actions to be directly done from the executables via UI
means, rather than requiring users to pass lots of cryptic options via
command line parameters. In this context, it would already be a significant
improvement if the most basic and relevant parameters could be configured
via some sort of GUI frontend, be it embedded or not, so that running a
process without REQUIRED parameters automatically brings up a dialog for
users to configure the most important parameters, and optionally save them
as startup profiles, so that they may next time select a startup profile or
create a new one.

Similar to how firefox starts actually: provide a way for customization,
preferably using lots of nifty tooltips and explanations and once a user
has a working config, enable them to save and reuse configs

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=1898496&group_id=98788

[coLinux-devel] [ colinux-Bugs-2622508 ] slight UI glitch wrt fltk console

[SourceForge.net <no...@so...>]

Bugs item #2622508, was opened at 2009-02-21 04:15
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: slight UI glitch wrt fltk console

Initial Comment:
the fltk console app doesn't seem to handle window resizing events properly, in fact it doesn't even honor terminal events resulting from running "reset" in order to make the console adjust to the new window layout.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 05:39

Message:
that's not really all that much of a problem, after all you are likely to
simply use an ssh client or X client/VNC to connect to coLinux-on the other
hand, the resizing events don't even seem to be honored in a running ssh
client.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-22 02:32

Message:
it doesn't seem to accept the PASTE event either, i.e. you cannot easily
paste text from the clipboard into the shell

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-2081864 ] properly register coLinux as a service

[SourceForge.net <no...@so...>]

Feature Requests item #2081864, was opened at 2008-08-29 06:29
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: properly register coLinux as a service 

Initial Comment:
if coLinux is fully registered as a service, it can be easily managed from the windows control panel, without necessarily requiring console commands to be executed manually by the user

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-23 05:30

Message:
this is obsolete, you can easily register it manually from the console by
using --install-service

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-16 14:13

Message:
having this would definitively improve the level of integration for colinux
under Windows

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-19 21:09

Message:
still installing it by default as a service that can be managed from the
control panel would be pretty intuitive

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-14 14:59

Message:
colinux already runs just fine as a service, at least it did the last time
I checked (before I moved to Vista x64).  There are a ton of different
programs to register services, I always used cygwin cygrunsrv to do it but
others like srvany from Microsoft should work too.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-09-21 17:07

Message:
this might actually be a good idea?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2081864&group_id=98788

[coLinux-devel] [ colinux-Bugs-2622508 ] slight UI glitch wrt fltk console

[SourceForge.net <no...@so...>]

Bugs item #2622508, was opened at 2009-02-21 04:15
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: slight UI glitch wrt fltk console

Initial Comment:
the fltk console app doesn't seem to handle window resizing events properly, in fact it doesn't even honor terminal events resulting from running "reset" in order to make the console adjust to the new window layout.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-22 02:32

Message:
it doesn't seem to accept the PASTE event either, i.e. you cannot easily
paste text from the clipboard into the shell

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2622508&group_id=98788