colinux-devel

[coLinux-devel] coLinux 0.5.3

[Dan A. <da...@gm...>]

Saturday again, time for a new release.

* Version 0.5.3 AKA "Valentine release"
  * Virtual CMOS system time is now passed to Linux, you no longer
    need to update the time using ntp on boot. Note that the virtual CMOS
    time is GMT, so the coLinux machine needs to set its own timezone.
  * cobd's devfs support was added to the Linux patch. Gentoo would work 
    now (based on a patch from Pat Erley). 
    A Gentoo root filesystem was created and released by Pat Erley.
  * Fixed an unwanted termination that was discovered when devfs was compiled
    in to the kernel.
  * Fixed an issue with mxml and the passage of boot parameters.
  * colinux-console: Fixed the CPU utilization issue.
  * colinux-console: Escape doesn't close the window now.
  * coLinux RAM is configurable, using a memory element in the XML under
    <colinux>, like: <memory size="64"></memory>. Minimum is 8MB, maximum is 192MB. 
    WARNING: high values might destabilize Windows, because the memory is
    allocated from the non-cached pool which has a maximum of 256MB system-wide,
    meaning there's less left for Windows drivers and subsystems.
  * bin/cobuild.sh: Thomas Fritzsche contributed this script which
    automates the creation of a cross compilation cygwin environment 
    on Linux.

NOTE:

I tested the configurable RAM option on my Windows machine, which
has 256MB of physical RAM. It worked with 64MB, and even 128MB, i.e,
half! Now that's cooperative. Of course, Windows' performance was 
affected because it had less crash. 

And KDE ran much faster.

I'm suspecting that Windows and its drivers aren't using much of that
memory pool (like 10MB or so), so you can freely use amounts like 128MB,
especially if your boxes have a lot of RAM to compensate.

-- 
Dan Aloni
da...@gm...

Re: [coLinux-devel] coLinux 0.5.3

[Matt B. <ma...@zi...>]

On Sat, Feb 14, 2004 at 10:00:27PM +0200, Dan Aloni wrote:

> I'm suspecting that Windows and its drivers aren't using much of that
> memory pool (like 10MB or so), so you can freely use amounts like 128MB,
> especially if your boxes have a lot of RAM to compensate.

It would be interesting if someone knows how to find out just how
much of the pool is being used, so a reasonable guess could be made.

--=20
Matt Behrens <ma...@zi...> <http://www.zigg.com/>
Life's too short to recompile what you don't hack. <http://www.debian.org/>

Re: [coLinux-devel] coLinux 0.5.3

[Richard G. <ric...@ri...>]

On my system with 1GB if I set memory size=128 coLinux fails to load with
a -1. If I drop it back to 96, it seems to work fine. How to troubleshoot?

----- Original Message ----- 
From: "Dan Aloni" <da...@gm...>
To: "Cooperative Linux Development" <col...@li...>
Sent: Saturday, February 14, 2004 2:00 PM
Subject: [coLinux-devel] coLinux 0.5.3


> Saturday again, time for a new release.
>
> * Version 0.5.3 AKA "Valentine release"
>   * Virtual CMOS system time is now passed to Linux, you no longer
>     need to update the time using ntp on boot. Note that the virtual CMOS
>     time is GMT, so the coLinux machine needs to set its own timezone.
>   * cobd's devfs support was added to the Linux patch. Gentoo would work
>     now (based on a patch from Pat Erley).
>     A Gentoo root filesystem was created and released by Pat Erley.
>   * Fixed an unwanted termination that was discovered when devfs was
compiled
>     in to the kernel.
>   * Fixed an issue with mxml and the passage of boot parameters.
>   * colinux-console: Fixed the CPU utilization issue.
>   * colinux-console: Escape doesn't close the window now.
>   * coLinux RAM is configurable, using a memory element in the XML under
>     <colinux>, like: <memory size="64"></memory>. Minimum is 8MB, maximum
is 192MB.
>     WARNING: high values might destabilize Windows, because the memory is
>     allocated from the non-cached pool which has a maximum of 256MB
system-wide,
>     meaning there's less left for Windows drivers and subsystems.
>   * bin/cobuild.sh: Thomas Fritzsche contributed this script which
>     automates the creation of a cross compilation cygwin environment
>     on Linux.
>
> NOTE:
>
> I tested the configurable RAM option on my Windows machine, which
> has 256MB of physical RAM. It worked with 64MB, and even 128MB, i.e,
> half! Now that's cooperative. Of course, Windows' performance was
> affected because it had less crash.
>
> And KDE ran much faster.
>
> I'm suspecting that Windows and its drivers aren't using much of that
> memory pool (like 10MB or so), so you can freely use amounts like 128MB,
> especially if your boxes have a lot of RAM to compensate.
>
> -- 
> Dan Aloni
> da...@gm...
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>
>

Re: [coLinux-devel] coLinux 0.5.3

[Thomas F. <tf...@no...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dan,

with this release I can now compile my own colinux-kernel and thanks for
the integration of my build script. Currently this script is designed to
work on top of colinux. So the current version in 0.5.3 tries to download
and build the pre2. I attached a version that should compile 0.5.3, but in
future it could be usefull to rewrite the script so that it simply
compiles the colinux-version that it is shipped with. What directory
structure would you prefer for this? What about the linux kernel build
directory that is currently outside the colinux directory structure?

Thanks and regards,
 Thomas

PS.: I still have fsck errors with rootcheck=yes. I tied a manual check
but this didn't solve this problem (debian 1gb-image). You wrote about an
other patch, I will give this a try.

> Saturday again, time for a new release.
>
> * Version 0.5.3 AKA "Valentine release"
>   * Virtual CMOS system time is now passed to Linux, you no longer
>     need to update the time using ntp on boot. Note that the virtual CMOS
>     time is GMT, so the coLinux machine needs to set its own timezone.
>   * cobd's devfs support was added to the Linux patch. Gentoo would work
>     now (based on a patch from Pat Erley).
>     A Gentoo root filesystem was created and released by Pat Erley.
>   * Fixed an unwanted termination that was discovered when devfs was
> compiled
>     in to the kernel.
>   * Fixed an issue with mxml and the passage of boot parameters.
>   * colinux-console: Fixed the CPU utilization issue.
>   * colinux-console: Escape doesn't close the window now.
>   * coLinux RAM is configurable, using a memory element in the XML under
>     <colinux>, like: <memory size="64"></memory>. Minimum is 8MB, maximum
> is 192MB.
>     WARNING: high values might destabilize Windows, because the memory is
>     allocated from the non-cached pool which has a maximum of 256MB
> system-wide,
>     meaning there's less left for Windows drivers and subsystems.
>   * bin/cobuild.sh: Thomas Fritzsche contributed this script which
>     automates the creation of a cross compilation cygwin environment
>     on Linux.
>
> NOTE:
>
> I tested the configurable RAM option on my Windows machine, which
> has 256MB of physical RAM. It worked with 64MB, and even 128MB, i.e,
> half! Now that's cooperative. Of course, Windows' performance was
> affected because it had less crash.
>
> And KDE ran much faster.
>
> I'm suspecting that Windows and its drivers aren't using much of that
> memory pool (like 10MB or so), so you can freely use amounts like 128MB,
> especially if your boxes have a lot of RAM to compensate.
>
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAMI2inwJBIFTVIqwRAlAYAKCE6JJc9Z7eEWbRRSHhCbDJhlaQuQCfTXx5
sdkQ2wHz8feXTsSStSVi47A=
=vSHl
-----END PGP SIGNATURE-----

[coLinux-devel] Utilising pre-installed Linux...

[Chakat S. <san...@e3...>]

I was told that I could save myself an 18MB download (and a gig of space 
on a small C:) by using my installation of Mandrake 9.1 instead.  
However, I can't figure out how to edit the XML file to point to the 
Linux partitions in order for it to boot.  I'm running a dual boot 
system (XP and Mandrake), and I don't know too much about Linux to go 
mucking about with it.  Can anyone help?

Sandy

Re: [coLinux-devel] coLinux 0.5.3

[Thomas F. <tf...@no...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi coLinux-Hackers,

I tested the current "Valentine release" + cobd.c patch. I wrote that I
get the time from the host system (only one hour diffenrence because I
didn't have setup the timezone). What I'm wondering is the fact that I
have not the same date. On colinux I have 12. Feb 2004 in Windows I have
16. Feb. 2004 and I could not explain this 4 days by not setting the
timezone.

I found the problem for the fsck problem I wrote about. This was not
solved by applying the cobd.c patch. It was just a false configuration of
the /dev/fstab file, because filesystem was set to ext2 and should be
ext3!?
I checked this and this is also in the original debian 1gb image and
should be changed.

Thanks and regards,
 Thomas


> Saturday again, time for a new release.
>
> * Version 0.5.3 AKA "Valentine release"
>   * Virtual CMOS system time is now passed to Linux, you no longer
>     need to update the time using ntp on boot. Note that the virtual CMOS
>     time is GMT, so the coLinux machine needs to set its own timezone.
>   * cobd's devfs support was added to the Linux patch. Gentoo would work
>     now (based on a patch from Pat Erley).
>     A Gentoo root filesystem was created and released by Pat Erley.
>   * Fixed an unwanted termination that was discovered when devfs was
> compiled
>     in to the kernel.
>   * Fixed an issue with mxml and the passage of boot parameters.
>   * colinux-console: Fixed the CPU utilization issue.
>   * colinux-console: Escape doesn't close the window now.
>   * coLinux RAM is configurable, using a memory element in the XML under
>     <colinux>, like: <memory size="64"></memory>. Minimum is 8MB, maximum
> is 192MB.
>     WARNING: high values might destabilize Windows, because the memory is
>     allocated from the non-cached pool which has a maximum of 256MB
> system-wide,
>     meaning there's less left for Windows drivers and subsystems.
>   * bin/cobuild.sh: Thomas Fritzsche contributed this script which
>     automates the creation of a cross compilation cygwin environment
>     on Linux.
>
> NOTE:
>
> I tested the configurable RAM option on my Windows machine, which
> has 256MB of physical RAM. It worked with 64MB, and even 128MB, i.e,
> half! Now that's cooperative. Of course, Windows' performance was
> affected because it had less crash.
>
> And KDE ran much faster.
>
> I'm suspecting that Windows and its drivers aren't using much of that
> memory pool (like 10MB or so), so you can freely use amounts like 128MB,
> especially if your boxes have a lot of RAM to compensate.
>
> --
> Dan Aloni
> da...@gm...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAMLKunwJBIFTVIqwRAqgFAKCb2PjwQzODQd15AlOpn0YtAqi2XACglWZx
GQYJlvkS9Pmio3+Vw7vgwqw=
=MCg+
-----END PGP SIGNATURE-----

Re: [coLinux-devel] coLinux 0.5.3

[Dan A. <da...@gm...>]

On Mon, Feb 16, 2004 at 12:08:14PM -0000, Thomas Fritzsche wrote:

> I tested the current "Valentine release" + cobd.c patch. I wrote that I
> get the time from the host system (only one hour diffenrence because I
> didn't have setup the timezone). What I'm wondering is the fact that I
> have not the same date. On colinux I have 12. Feb 2004 in Windows I have
> 16. Feb. 2004 and I could not explain this 4 days by not setting the
> timezone.

The problem resides in the conversion between Windows' KeQuerySystemTime
and the UNIX time returned to Linux. It returns the number of seconds since
January 1, 1601 (should look at the history books to find out why Microsoft
picked up this date). When calculating the difference I forgot to subtract 
the extra days of the 3 non existing leap years of 1700, 1800, and 1900. 
The last day is an off-by-one :).

Fixed in the next release.

-- 
Dan Aloni
da...@gm...