colinux-devel — Cooperative Linux development mailing list

[coLinux-devel] problem with X and memory

[Sergey S. <sg...@se...>]

Hello colinux-devel,

I just set coLinux 0.5.3.
I had a problem with setting of memory more than 64 mb(option <memory size="64">), when I put, for example, 96 mb.
coLinux stops the work at once after the start with the message "Demon
failed: -1". I have 512 mb Ram.
Yet very often KDE hangs up, here I can not watch the reason of this, because hanging up arises up in casual places.

p.S.
Sorry for my poor english.
-- 
Best regards,
 Sergey                          mailto:sg...@se...

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

[Regis N. <re...@ho...>]

----- Original Message ----- 
From: "Regis NEBOR" <re...@ho...>
To: "Chakat Sandwalker" <san...@e3...>
Sent: Monday, February 16, 2004 2:43 AM
Subject: Re: [coLinux-devel] Utilising pre-installed Linux...


> Hi
>
> This config file allowed me to boot on my /dev/hda2 :
>
> <?xml version="1.0" encoding="UTF-8"?>
> <colinux>
>     <block_device index="0" path="\Device\HarddiskVolume2" enabled="true">
>     </block_device>
>     <bootparams>root=/dev/cobd0</bootparams>
>     <image path="vmlinux"></image>
> </colinux>
>
> But the kernel will remain colinux's one. You'll have to change some
setting
> in the previous setup too.
> I would say getting an image made with colinux in mind is easier at the
> moment.
>
> Regis
>
> ----- Original Message ----- 
> From: "Chakat Sandwalker" <san...@e3...>
> To: <col...@li...>
> Sent: Monday, February 16, 2004 1:56 AM
> Subject: [coLinux-devel] Utilising pre-installed Linux...
>
>
> > 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
> >
> >
> > -------------------------------------------------------
> > 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 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-----

[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 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-----

Re: [PATCH] Re: [coLinux-devel] cobd devfs support

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

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

Hi Dan,

thanks for the patch this solved the issue with the
CO_TERMINATE_INVALID_OPERATION errors. I can now build the kernel and get
system time from host operation system.

Thanks,
 Thomas

> Thaks, the patch I made below completes your effort.
>
> This patch also fixes at least one invalid operation (termination 7)
> problem
> that was encountered. It turns out that time.c was trying to query the
> BIOS
> directly for the system time and therefore was stopped by co_terminate().
> In
> the next release, it would get this information from the host OS using a
> special interface. For now, the patch below adds devfs support and
> addresses
> the invalid operation problem alone.
>
> (applies on top of 0.5.3-pre2's patch/linux)
>
> diff -u linux/arch/i386/kernel/time.c linux/arch/i386/kernel/time.c
> --- linux/arch/i386/kernel/time.c	2003-12-13 17:17:01.000000000 +0200
> +++ linux/arch/i386/kernel/time.c	2004-02-14 01:50:50.000000000 +0200
> @@ -121,6 +121,8 @@
>
>  extern spinlock_t i8259A_lock;
>
> +#ifndef CONFIG_COOPERATIVE
> +
>  #ifndef CONFIG_X86_TSC
>
>  /* This function must be called with interrupts disabled
> @@ -254,6 +256,18 @@
>  	return count;
>  }
>
> +#else
> +
> +static unsigned long do_slow_gettimeoffset(void)
> +{
> +	/*
> +	 * coLinux TODO for 0.5.3: Request the time from the host OS.
> +	 */
> +	return 0;
> +}
> +
> +#endif
> +
>  static unsigned long (*do_gettimeoffset)(void) = do_slow_gettimeoffset;
>
>
> diff -u linux/drivers/block/cobd.c linux/drivers/block/cobd.c
> --- linux/drivers/block/cobd.c	2004-02-06 17:11:19.000000000 +0200
> +++ linux/drivers/block/cobd.c	2004-02-14 01:30:47.000000000 +0200
> @@ -10,6 +10,8 @@
>  #include <linux/errno.h>
>  #include <linux/major.h>
>  #include <linux/slab.h>
> +#include <linux/devfs_fs_kernel.h>
> +
>
>  #define MAJOR_NR COLINUX_MAJOR
>  #define DEVICE_NR(device) MINOR(device)  /* has no partition bits */
> @@ -19,6 +21,7 @@
>  #define DEVICE_OFF(d) /* do-nothing */
>
>  #include <linux/blk.h>
> +#include <linux/blkpg.h>
>  #include <linux/hdreg.h>
>  #include <linux/cooperative.h>
>
> @@ -231,10 +234,14 @@
>  	for (i=0; i < cobd_devs; i++)
>  		register_disk(NULL, MKDEV(MAJOR_NR, i), 1, &cobd_fops,  cobd_sizes[i]);
>
> -	printk("cobd driver initialized\n");
> +        devfs_register_series(NULL, "cobd%u", cobd_devs,
> DEVFS_FL_DEFAULT,
> +                              MAJOR_NR, 0,
> +                              S_IFBLK | S_IRUSR | S_IWUSR | S_IRGRP,
> +                              &cobd_fops, NULL);
> +
> +	printk("cobd: loaded (max %d devices)\n", cobd_devs);
>
> -	result = 0;
> -	return result;
> +	return 0;
>
>  fail_malloc_2:
>  	kfree(cobd_blksizes);
> @@ -242,6 +249,9 @@
>  	kfree(cobd_sizes);
>  fail_malloc:
>
> +	if (devfs_unregister_blkdev(MAJOR_NR, "cobd"))
> +		printk(KERN_WARNING "loop: cannot unregister blkdev\n");
> +
>  	return result;
>  }
>
> @@ -262,0 +273 @@
> +
> diff -u linux/include/asm-i386/io.h linux/include/asm-i386/io.h
> --- linux/include/asm-i386/io.h	2004-02-08 00:43:12.000000000 +0200
> +++ linux/include/asm-i386/io.h	2004-02-14 01:50:28.000000000 +0200
> @@ -124,8 +124,7 @@
>  static inline void * ioremap (unsigned long offset, unsigned long size)
>  {
>  #ifdef CONFIG_COOPERATIVE
> - 	co_debug("ioremap %x:%d\n", offset, size);
> -	co_terminate(CO_TERMINATE_INVALID_OPERATION);
> +	panic("ioremap %ld:%ld\n", offset, size);
>  #endif
>  	return __ioremap(offset, size, 0);
>  }
> @@ -153,8 +152,7 @@
>  static inline void * ioremap_nocache (unsigned long offset, unsigned long
> size)
>  {
>  #ifdef CONFIG_COOPERATIVE
> - 	co_debug("ioremap %x:%d\n", offset, size);
> -	co_terminate(CO_TERMINATE_INVALID_OPERATION);
> +	panic("ioremap_nocache %ld:%ld\n", offset, size);
>  #endif
>          return __ioremap(offset, size, _PAGE_PCD);
>  }
> @@ -443,7 +441,9 @@
>
>  static inline unsigned long badio(const char *file, int line)
>  {
> -	co_terminate(CO_TERMINATE_INVALID_OPERATION);
> +#ifdef CONFIG_COOPERATIVE
> +	panic("badio %s:%d\n", file, line);
> +#endif
>  	return 0;
>  }
>
>
>
>
> --
> 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
>


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

iD8DBQFAMH8+nwJBIFTVIqwRArxYAJ9z59DXlGfgOkKCFLWOINx2YsS0hwCgprcz
+384TzRrxUFmauWS3FZIiGQ=
=8egT
-----END PGP SIGNATURE-----

Re: [PATCH] Re: [coLinux-devel] Invalid argument zeroing block?

[Sean B. <sea...@so...>]

On Sunday 15 February 2004 22:17, Dan Aloni wrote:
> On Sat, Feb 14, 2004 at 08:07:32PM -0600, Richard Goodwin wrote:
> > On one of my systems I'm having some problems adding a new cobd device. I
> > tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
> > partition on it, but then mke2fs (or ext3) bombs out with "Invalid
> > argument zeroing block 536846320 at end of filesystem". fdisk, cfdisk,
> > and sfdisk all report that the partitions I create are screwy, like
> > -19349 blocks or something.
> >
> > I tried creating a 3gb image by copy /b the Debian 1gb image, but the
> > same problem happens (different block sizes of course). sfdisk -g (get
> > geometry) says the kernel can't determine the geometry.
> >
> > I've done this fine on my work system but doesn't appear to be working on
> > the home system. I actually already have a cobd0, cobd1, and cobd2, so
> > this makes cobd3. Has anyone else run into this?
>
> This patch on top of the 0.5.3/linux/patch should address the problem.
>
> It turns out that cobd was passing wrong information about the device's
> size to userspace. Userspace gets the size of the disk in hardsects and
> that can only fit into an unsigned long. The previous calculation was
> overflowing.

Will this patch allow me to boot my real Linux root fs which is 20gb?
- I did try about a week ago but got messages reporting attempts to access 
data beyond the end of the disk.

Cheers.

Disk /dev/hda: 80.0 GB, 80060424192 bytes
255 heads, 63 sectors/track, 9733 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/hda2   *         264        2839    20691720   83  Linux

# tune2fs -l /dev/hda2

tune2fs 1.34 (25-Jul-2003)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          390f1859-0a75-4802-a373-5b530026038f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index needs_recovery large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              5131840
Block count:              5172930
Reserved block count:     206917
Free blocks:              909993
Free inodes:              4624578
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32480
Inode blocks per group:   1015
Last mount time:          Sun Feb 15 23:14:11 2004
Last write time:          Mon Feb 16 02:33:32 2004
Mount count:              1
Maximum mount count:      2
Last checked:             Sun Feb 15 23:13:37 2004
Check interval:           15552000 (6 months)
Next check after:         Sat Aug 14 00:13:37 2004
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       3868049
Default directory hash:   tea
Directory Hash Seed:      d6487111-58fe-49d0-9ff5-cb965bec03da

Re: [coLinux-devel] Crashing in time.c

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

On Sun, Feb 15, 2004 at 07:14:36PM -0800, Origional Trakk wrote:
> Running with the new 0.5.3 install..
> Running on a new toshiba satellite P25 series laptop
> (possible BIOS issue?)
> At the end of the boot sequence:
> (It looks like it happens when apache starts.)
> (Log from the daemon page.) The console clears too
> fast to see anything happen.
> 
> I'll try look at the problem. I'm not a kernel coder
> my any means, but I'll put my best foot forward. I
> wouldn't rely on me to figure it out anytime soon.

It tries to set the CMOS time.

I think the correct strategy is to not allow it. Will get fixed
in the next release. 

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

[coLinux-devel] Crashing in time.c

[Origional T. <tra...@ya...>]

Running with the new 0.5.3 install..
Running on a new toshiba satellite P25 series laptop
(possible BIOS issue?)
At the end of the boot sequence:
(It looks like it happens when apache starts.)
(Log from the daemon page.) The console clears too
fast to see anything happen.

I'll try look at the problem. I'm not a kernel coder
my any means, but I'll put my best foot forward. I
wouldn't rely on me to figure it out anytime soon.

-----
conet: initialized
Kernel panic: badio time.c:526

In interrupt handler - not syncing
 daemon: monitor terminated, reason 3
switch_message: freed message a043f58 (2 to 4)
daemon: module disconnected: conet0
Pipe broken, exiting
switch_message: freed message a043f58 (2 to 4)
daemon: module disconnected: console
daemon: monitor shutting down
daemon: daemon cleanup
Removing kernel driver
Stopping driver service
Removing driver service

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

[coLinux-devel] conet driver stats patch

[Pat E. <pat...@ma...>]

This patch adds statistics to the conet driver.  Please test and consider merging.

Pat Erley

[PATCH] Re: [coLinux-devel] Invalid argument zeroing block?

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

On Sat, Feb 14, 2004 at 08:07:32PM -0600, Richard Goodwin wrote:
> On one of my systems I'm having some problems adding a new cobd device. I
> tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
> partition on it, but then mke2fs (or ext3) bombs out with "Invalid argument
> zeroing block 536846320 at end of filesystem". fdisk, cfdisk, and sfdisk all
> report that the partitions I create are screwy, like -19349 blocks or
> something.
> 
> I tried creating a 3gb image by copy /b the Debian 1gb image, but the same
> problem happens (different block sizes of course). sfdisk -g (get geometry)
> says the kernel can't determine the geometry.
> 
> I've done this fine on my work system but doesn't appear to be working on
> the home system. I actually already have a cobd0, cobd1, and cobd2, so this
> makes cobd3. Has anyone else run into this?

This patch on top of the 0.5.3/linux/patch should address the problem. 

It turns out that cobd was passing wrong information about the device's
size to userspace. Userspace gets the size of the disk in hardsects and
that can only fit into an unsigned long. The previous calculation was
overflowing.

Tested this with a newly created 3gb image, and it seems to be okay.

diff -u linux/drivers/block/cobd.c linux/drivers/block/cobd.c
--- linux/drivers/block/cobd.c	2004-02-14 01:54:01.000000000 +0200
+++ linux/drivers/block/cobd.c	2004-02-16 00:04:44.000000000 +0200
@@ -39,7 +39,7 @@
 		     unsigned int cmd, unsigned long arg)
 {
 	int err;
-	long size;
+	unsigned long size;
 	int dev;
 
 	dev = MINOR(inode->i_rdev);
@@ -55,8 +55,8 @@
 		if (err) 
 			return -EFAULT;
 
-		size = (cobd_sizes[dev] * 1024) / cobd_hardsects[dev];
-		if (copy_to_user((long *) arg, &size, sizeof (long)))
+		size = (cobd_sizes[dev]) * (1024 / cobd_hardsects[dev]);
+		if (copy_to_user((unsigned long *) arg, &size, sizeof (unsigned long)))
 			return -EFAULT;
 
 		return 0;
@@ -139,7 +139,7 @@
 		co_request->type = CO_BLOCK_READ;
 	else
 		co_request->type = CO_BLOCK_WRITE;
-	co_request->offset = req->sector * PBD_BLOCK_SIZE;
+	co_request->offset = ((unsigned long long)req->sector) * PBD_BLOCK_SIZE;
 	co_request->size = req->current_nr_sectors * PBD_BLOCK_SIZE;
 	co_request->address = req->buffer;
 	co_request->rc = 0;
@@ -211,6 +211,7 @@
 		co_block_request_t *request;
 		unsigned long flags;
 		unsigned long long size = 0;
+		long rc = 0;
 	
 		local_irq_save(flags);
 		co_passage_page->operation = CO_OPERATION_DEVICE;
@@ -219,10 +220,17 @@
 		request = (co_block_request_t *)&co_passage_page->params[2];
 		request->type = CO_BLOCK_STAT;
 		co_switch();
+		rc = request->rc;
 		size = request->disk_size;
 		local_irq_restore(flags);
 
-		cobd_sizes[i] = size / 1024;
+		if (!rc) {
+			/* Request successed */
+			cobd_sizes[i] = size / 1024;
+		} else {
+			cobd_sizes[i] = 0;
+		}
+
 		cobd_blksizes[i] = PAGE_SIZE;
 		cobd_hardsects[i] = PBD_BLOCK_SIZE;
 	}



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

[coLinux-devel] Invalid argument zeroing block?

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

On one of my systems I'm having some problems adding a new cobd device. I
tried using Sean's 4gb image, mounted via the xml, used fdisk to put a
partition on it, but then mke2fs (or ext3) bombs out with "Invalid argument
zeroing block 536846320 at end of filesystem". fdisk, cfdisk, and sfdisk all
report that the partitions I create are screwy, like -19349 blocks or
something.

I tried creating a 3gb image by copy /b the Debian 1gb image, but the same
problem happens (different block sizes of course). sfdisk -g (get geometry)
says the kernel can't determine the geometry.

I've done this fine on my work system but doesn't appear to be working on
the home system. I actually already have a cobd0, cobd1, and cobd2, so this
makes cobd3. Has anyone else run into this?


Thanks!
Richard

[coLinux-devel] coLinus, Windows ICS. multiple NICs

[TP D. <tp...@di...>]

I posted a very similar email earlier, so I apologize if I'm being too
repetitious.

I'm already using Windows ICS to allow another NIC to access the Internet,
and as far as I can determine, Windows 200o Professional only supports
sharing the  external (Internet) connection to a single other NIC.

From Windows, I can ping coLinux's TAP-Win32 IP, and get a response when
coLinux is running. But from coLinux, all pings to any address -- including
the TAP-Win32 adapter's -- fail.

Can anyone tell me a way to allow both coLinux's TAP32 connection and the
local connection that's already using ICS, to both get acccess to the
internet?

Thanks.

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] Re: cross probs while building fltk, maybe mxml too

[Sean B. <sea...@so...>]

On Saturday 14 February 2004 16:33, Dan Aloni wrote:
> On Sat, Feb 14, 2004 at 04:10:35PM +0000, Sean Brook wrote:
> > Could someone please post a diff to fltk that would allow me to compile
> > fltk against cygwin cross build tools.
> >
> > I found this past post by Don Aloni:
>
>                              ^
> My surname may appear Italian, but I'm not ;)

Oops, apologies for that. I have watched too many gangster films. Just call me 
a dirty rat.

>
> > http://sourceforge.net/mailarchive/message.php?msg_id=7148836
>
> Here's a better source:
>
> http://www.colinux.org/patches/fltk-1.1.4.diff

Many thanks for that.

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/>

[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] gentoo-i686-ext3 Release Notes

[Pat E. <pat...@ma...>]

On Sat, 14 Feb 2004 10:53:23 -0500
Pat Erley <pat...@ma...> wrote:

> Release notes are attached as README
> 
> Pat Erley
> 
> 
> 
if you do run into problems with this particular image, please CC me directly when reporting problems.  I've already had one person run into problems running it, but I believe it was a hardware issue.  I'm looking into it.

Pat

Re: [coLinux-devel] gentoo-i686-ext3 Release Notes

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

On Sat, Feb 14, 2004 at 10:53:23AM -0500, Pat Erley wrote:

> Release notes are attached as README

This image is now available from sourceforge's coLinux page:

http://sourceforge.net/project/showfiles.php?group_id=98788&package_id=108058&release_id=213043

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

Re: [coLinux-devel] Re: cross probs while building fltk, maybe mxml too

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

On Sat, Feb 14, 2004 at 04:10:35PM +0000, Sean Brook wrote:
> Could someone please post a diff to fltk that would allow me to compile fltk 
> against cygwin cross build tools.
> 
> I found this past post by Don Aloni:
                             ^
My surname may appear Italian, but I'm not ;)

> http://sourceforge.net/mailarchive/message.php?msg_id=7148836

Here's a better source:

http://www.colinux.org/patches/fltk-1.1.4.diff

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

[coLinux-devel] Re: cross probs while building fltk, maybe mxml too

[Sean B. <sea...@so...>]

Could someone please post a diff to fltk that would allow me to compile fltk 
against cygwin cross build tools.

I found this past post by Don Aloni:
http://sourceforge.net/mailarchive/message.php?msg_id=7148836

But it seems as though sourceforge cuts off the end of longer posts. In other 
words I think the diff is is not complete and I could not compile fltk using 
it:
...
Compiling filename_list.o...
filename_list.cxx: In function `int fl_filename_list(const char*, dirent***,
   int (*)(dirent**, dirent**))':
filename_list.cxx:54: error: invalid conversion from `int (*)(const dirent**,
   const dirent**)' to `int (*)(dirent**, dirent**)'
make[1]: *** [filename_list.o] Error 1
make[1]: Leaving directory `/usr/src/cygwin/fltk-1.1.4/src'

Could I also get any diff against mxml that may be needed or any parameters 
that should be used. I managed to compile mxml but I want to make sure 
everything is correct.

Many thanks for any help.

[coLinux-devel] problem to run full gnome on cygwin/x

[Sugree P. <su...@hp...>]

Hi all,

coLinux is working great on my system perfectly in pure text mode. In X
environment, it randomly stops responding (or so slow). All gnome's
processes look like to freeze but it is actually not at all. I can break
them by pressing ctrl-c and kill like usual.

Note that my system is RedHat 9.0 installed on 1 GB ext3 fs and 256 MB swap
partition. I upload my root fs at
http://amata.cpe.ku.ac.th/~sugree/dload/colinux/redhat-9.0.ext3.1gb.bz2 in
case you want to try. It comes with apt-get pointed to freshrpms.net.

Any idea?

Thanks,

Sugree Phatanapherom
su...@hp...

[coLinux-devel] gentoo-i686-ext3 Release Notes

[Pat E. <pat...@ma...>]

Release notes are attached as README

Pat Erley

[PATCH] Re: [coLinux-devel] Single user mode (i.e., kernel commandline parameters)

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

On Sat, Feb 14, 2004 at 02:07:13PM +0200, Dan Aloni wrote:
> On Sat, Feb 14, 2004 at 10:40:25PM +1000, Ian Latter wrote:
> > 
> > > >Yes you can get to a cmd prompt without init.  Change the boot 
> > > >parameters in the default xml file such that "init=/bin/sh".
> > > >
> > > I tried that.  It didn't work.  It just went ahead and ran init anyway 
> > > and booted up all the way.
> > 
> > If this is the case then you may have the wrong version of coLinux --
> > Dan said that he was going to fix that up -- I dunno if he did (hadn't
> > retested that yet).
> 
> I did implement it, but somehow it takes only the first paramter. Will 
> be fixed for the next version.

Turns out that mxml splited the space separated text parameter line
to nodes. Here's a fix.

--- colinux-20040210/src/colinux/user/config.c	2004-02-08 00:38:21.000000000 +0200
+++ main/src/colinux/user/config.c	2004-02-14 14:27:41.000000000 +0200
@@ -95,16 +95,39 @@
 			if (strcmp(name, "block_device") == 0) {
 				co_load_config_blockdev(out_config, &walk->value.element);
 			} else if (strcmp(name, "bootparams") == 0) {
+				char *param_line;
+				unsigned long param_line_size_left;
+				unsigned long index;
+				mxml_node_t *text_node;
+
 				if (walk->child == NULL)
 					continue;
 
-				walk = walk->child;
-				if (walk->type != MXML_TEXT) 
-					continue;
+				param_line = out_config->boot_parameters_line;
+				param_line_size_left = sizeof(out_config->boot_parameters_line);
+
+				bzero(param_line, param_line_size_left);
+
+				text_node = walk->child;
+				index = 0;
+
+				while (text_node  &&  text_node->type == MXML_TEXT) {
+					if (index != 0) {
+						int param_size = strlen(param_line);
+						param_line += param_size;
+						param_line_size_left -= param_size;
+					}
+						
+					snprintf(param_line, 
+						 param_line_size_left, 
+						 index == 0 ? "%s" : " %s", 
+						 text_node->value.text.string);
+
+					index++;
+					text_node = text_node->next;
+				}
 
-				snprintf(out_config->boot_parameters_line, 
-					 sizeof(out_config->boot_parameters_line), 
-					 "%s", walk->value.text.string);
+				printf("%s\n", out_config->boot_parameters_line);
 			} else if (strcmp(name, "image") == 0) {
 				co_load_config_image(out_config, &walk->value.element);
 			}



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

Re: [coLinux-devel] Single user mode (i.e., kernel commandline parameters)

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

On Sat, Feb 14, 2004 at 10:40:25PM +1000, Ian Latter wrote:
> 
> > >Yes you can get to a cmd prompt without init.  Change the boot 
> > >parameters in the default xml file such that "init=/bin/sh".
> > >
> > I tried that.  It didn't work.  It just went ahead and ran init anyway 
> > and booted up all the way.
> 
> If this is the case then you may have the wrong version of coLinux --
> Dan said that he was going to fix that up -- I dunno if he did (hadn't
> retested that yet).

I did implement it, but somehow it takes only the first paramter. Will 
be fixed for the next version.

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