colinux-devel — Cooperative Linux development mailing list

Re: [coLinux-devel] 0.5.4: i686-optimized vmlinux along with i686-optimized userspace - segfaults

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

On Fri, Mar 05, 2004 at 12:53:34PM -0000, Sean Brook wrote:

> | I'm now working on a fix, while also merging Ballard's patches.
> 
> Does the latest snapshot (20040305) fix the seg fault issues?

Yes.

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] 0.5.4: i686-optimized vmlinux along with i686-optimized userspace - segfaults

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

----- Original Message ----- 
From: "Dan Aloni" <da...@co...>
To: "Cooperative Linux Development" <col...@li...>
Sent: Tuesday, March 02, 2004 9:16 PM
Subject: [coLinux-devel] 0.5.4: i686-optimized vmlinux along with
i686-optimized userspace - segfaults


| Hello,
|
| I've figured the issue mentioned in the topic. Well, apparently the
optimized
| kernel code corrupts MMX / FPU registers for userspace while in the path
| between hardware interrupt handling and forwarding to the host.
|
| It occurs more often when the coLinux machine gets more CPU from the host,
| since hardware interrupts are caught more often in that situation.
|
| A i386-compatible vmlinux gets around it, but it's not the solution I
want.
|
| I'm now working on a fix, while also merging Ballard's patches.

Does the latest snapshot (20040305) fix the seg fault issues?

|
| -- 
| Dan Aloni
| da...@co...
|
|
| -------------------------------------------------------
| 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] 0.5.4: i686-optimized vmlinux along with i686-optimized userspace - segfaults

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

On Tue, Mar 02, 2004 at 11:16:29PM +0200, Dan Aloni wrote:
> Hello,
> 
> I've figured the issue mentioned in the topic. Well, apparently the optimized
> kernel code corrupts MMX / FPU registers for userspace while in the path 
> between hardware interrupt handling and forwarding to the host. 
> 
> It occurs more often when the coLinux machine gets more CPU from the host, 
> since hardware interrupts are caught more often in that situation.
> 
> A i386-compatible vmlinux gets around it, but it's not the solution I want.

Okay, *now* I really figured out the issue mentioned in the topic. The vmlinux 
i686 issue is only a lesser of two evils - more testing led me to the 
conclusion that the fix for the %fs/%gs wasn't complete. The fix that 
got into 0.5.4 only prevented recurring segmentation faults, but didn't take 
one thing into account.

During a context switch of the Linux scheduler, the LDT of the next process 
is loaded prior to saving the %fs/%gs register pair for the previous one. This 
means that in that small period of time, an hardware interrupt can occur and 
cause coLinux to switch back to Windows for it to be handled. On the way back,
it tries to restore %gs. However, the LDT isn't valid and %gs is loaded with
0. When __switch_to finally switches to the new process, it saves the zero'ed
%gs in ->thread.gs. So, when a switch occurs back to the process with the zero
%gs, it dies when the user space code tries to access it.

Considering this can occur only during hardware interrupts, it explains why CPU
intensive tasks are affected. When coLinux is idle, it intercepts much less
hardware interrupts.

The fix is to simplely move the saving of %fs and %gs and to prepare_to_switch(),
that occurs before switch_mm(). I've tested it on my Gentoo setup and it seems
the problem is gone.

For this milestone I've uploaded a snapshot.


diff -u linux/arch/i386/kernel/process.c linux/arch/i386/kernel/process.c
--- linux/arch/i386/kernel/process.c	2004-03-04 00:16:11.000000000 +0200
+++ linux/arch/i386/kernel/process.c	2004-03-05 07:21:18.000000000 +0200
@@ -671,12 +671,20 @@
 	 */
 	tss->esp0 = next->esp0;
 
+#ifdef CONFIG_COOPERATIVE
+	/*
+	 * We would save %fs and %gs using an atomic operation in the
+	 * just before the LDT of the next process is loaded. It is 
+	 * not here, it's in...
+	 */
+#else
 	/*
 	 * Save away %fs and %gs. No need to save %es and %ds, as
 	 * those are always kernel segments while inside the kernel.
 	 */
 	asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->fs));
 	asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->gs));
+#endif
 
 	/*
 	 * Restore %fs and %gs.
only in patch2:
unchanged:
--- linux/include/asm-i386/system.h	2004-02-02 22:39:43.000000000 +0200
+++ linux/include/asm-i386/system.h	2004-03-05 07:17:57.000000000 +0200
@@ -12,7 +12,15 @@
 struct task_struct;	/* one of the stranger aspects of C forward declarations.. */
 extern void FASTCALL(__switch_to(struct task_struct *prev, struct task_struct *next));
 
+#ifdef CONFIG_COOPERATIVE
+#define prepare_to_switch()     {					\
+   asm volatile("movl %%fs,%0":"=m" (*(int *)&prev->thread.fs));	\
+   asm volatile("movl %%gs,%0":"=m" (*(int *)&prev->thread.gs));	\
+}
+#else
 #define prepare_to_switch()	do { } while(0)
+#endif
+
 #define switch_to(prev,next,last) do {					\
 	asm volatile("pushl %%esi\n\t"					\
 		     "pushl %%edi\n\t"					\


-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] apt-get dist-upgrade broke my Debian

[Ballard J. <sac...@ho...>]

> This is because the initscripts package got updated and
> /etc/init.d/checkroot.sh also, just edit it and change the line with
> "rootcheck=yes" to "rootcheck=no".

That is one fix.  Also, in the /etc/fstab the entry for the /dev/cobd0 was
something like:

/dev/cobd0 / ext2 defaults 0 1

Change the ext2 to ext3.

/dev/cobd0 / ext3 defaults 0 1

A few more things should work fine.

Re: [coLinux-devel] apt-get dist-upgrade broke my Debian

[Marko B. <bo...@ks...>]

Karol Bryd wrote:

> 
> This is because the initscripts package got updated and
> /etc/init.d/checkroot.sh also, just edit it and change the line with
> "rootcheck=yes" to "rootcheck=no".

Thanks!

-- 
Marko
ICQ: 5990814

I'm not under the alkafluence of inkahol
that some thinkle peep I am.
It's just the drunker I sit here the longer I get.

Re: [coLinux-devel] apt-get dist-upgrade broke my Debian

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

On Thu, 4 Mar 2004 15:04:58 +0100
Karol Bryd <kb...@py...> wrote:

> On Thu, Mar 04, 2004 at 02:43:52PM +0100, Marko Bozikovic wrote:
> > Heh. A big SNAFU here :)
> > 
> > Here's what I did: took the base Debian image, installed a few packages: 
> > less, vim, base-config, ssh.
> > 
> > Then I changed sources.list to fetch stuff from unstable distribution, and 
> > did apt-get update, apt-get dist-upgrade. I did its magic, and everything 
> > worked fine until I rebooted coLinux. On the next boot I got this:
> > 
> > 
> > Checking root file system...
> > fsck 1.35 (28-Feb-2004)
> > /dev/cobd0: The filesystem size (according to the superblock) is 262144 
> > blocks
> > The physical size of the device is 0 blocks
> > Either the superblock or the partition table is likely to be corrupt!
> > 
> > /dev/cobd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> >         (i.e., without -a or -p options)
> > 
> 
> This is because the initscripts package got updated and
> /etc/init.d/checkroot.sh also, just edit it and change the line with
> "rootcheck=yes" to "rootcheck=no".

pardon my ignorance here, but isn't NOT checking root a little hackish
of a solution?  and also, isn't it a little not safe?  I have fsck working
on my gentoo images.

Pat Erley

Re: [coLinux-devel] apt-get dist-upgrade broke my Debian

[Karol B. <kb...@py...>]

On Thu, Mar 04, 2004 at 02:43:52PM +0100, Marko Bozikovic wrote:
> Heh. A big SNAFU here :)
> 
> Here's what I did: took the base Debian image, installed a few packages: 
> less, vim, base-config, ssh.
> 
> Then I changed sources.list to fetch stuff from unstable distribution, and 
> did apt-get update, apt-get dist-upgrade. I did its magic, and everything 
> worked fine until I rebooted coLinux. On the next boot I got this:
> 
> 
> Checking root file system...
> fsck 1.35 (28-Feb-2004)
> /dev/cobd0: The filesystem size (according to the superblock) is 262144 
> blocks
> The physical size of the device is 0 blocks
> Either the superblock or the partition table is likely to be corrupt!
> 
> /dev/cobd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>         (i.e., without -a or -p options)
> 

This is because the initscripts package got updated and
/etc/init.d/checkroot.sh also, just edit it and change the line with
"rootcheck=yes" to "rootcheck=no".

Regards
-- 
-= karol(at)python.org.pl =-               -= http://python.org.pl/~kbryd =-
  -= It's sweet to be remembered, but it's often cheaper to be forgotten=-

[coLinux-devel] apt-get dist-upgrade broke my Debian

[Marko B. <bo...@ks...>]

Heh. A big SNAFU here :)

Here's what I did: took the base Debian image, installed a few packages: less, 
vim, base-config, ssh.

Then I changed sources.list to fetch stuff from unstable distribution, and did 
apt-get update, apt-get dist-upgrade. I did its magic, and everything worked 
fine until I rebooted coLinux. On the next boot I got this:


Checking root file system...
fsck 1.35 (28-Feb-2004)
/dev/cobd0: The filesystem size (according to the superblock) is 262144 blocks
The physical size of the device is 0 blocks
Either the superblock or the partition table is likely to be corrupt!

/dev/cobd0: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
         (i.e., without -a or -p options)

fsck failed. Please repair manually and reboot. Please note
that the root file system is currently mounted read-only. To
remount it read-write:

# mount -n -o remount,rw /

CONTROL-D will exit from this shell and REBOOT the system.

Give root password for maintenance
(or type Control-D for normal startup):



I've tried messing around, but no luck. Fdisk reports invalid flag for 
/dev/cobd0, and partition table is empty. Remounting rw, rebooting and nothing 
changed.

Can anybody give me some pointers? This is beyond my abilities :)

TIA,
-- 
Marko
ICQ: 5990814

I'm not under the alkafluence of inkahol
that some thinkle peep I am.
It's just the drunker I sit here the longer I get.

Re: [coLinux-devel] Initrd support?

[Chris S. <cs...@ma...>]

Glad you got that working. That is what I was trying to get at last nite but was on a machine with no linux and could not find initrd.txt without downloading a whole kernel source.

Did you also follow this advice from initrd.txt ? I see you did the last 2 points and I'm assuming that the 3rd is taken care of.

 - before calling pivot_root, the current directory of the invoking
   process should point to the new root directory
 - use . as the first argument, and the _relative_ path of the directory
   for the old root as the second argument
 - a chroot program must be available under the old and the new root
 - chroot to the new root afterwards
 - use relative paths for dev/console in the exec command



The mem problem is probably typical snapshot crap hopefully they are aware but you may want to start a new thread with an apropriate subject so the right people will see it.

I have been sticking to the more stable releases because my intrests in this project are more system integration than actual development of the coLinux daemon itself.

chris


----- Original Message -----
From: Eric Andresen <ea...@ma...>
Date: Wed, 03 Mar 2004 19:24:28 -0700
To: coLinux Development <col...@li...>
Subject: Re: [coLinux-devel] Initrd support?

> Correct. I've basically bypassed this failing by loading it as a block
> device, though. In order to make it act as an initrd in this case, you
> have to add the line:
> exec chroot . /sbin/init <dev/console >dev/console 2>&1
> 
> *after* your pivot_root, otherwise when your script ends, so does your
> kernel's lifeline.
> 
> I've basically finished my initrd work, and it appears to working well.
> During this configuration process, though, I've noticed a disturbing
> problem that I can confirm occurs on two different windows machines (one
> running Server 2003, the other XP Pro): The first time through, coLinux
> runs happily, until the point where init effectively dies (not the
> problem, simply unfinished configuration). So, I close coLinux, and
> restart it. This time coLinux hangs the entire system sometime before
> the expected dying of init (right after setting the system clock, but I
> doubt that is even relevant).
> 
> I'm using the 20040304 development snapshot. I'm not sure what the cause
> of this problem is, but my guess would be something is not being
> properly cleaned out when coLinux closes the first time around. There
> was a single time where it did not occur until the third restart of
> coLinux.
> 
> Memory usage differed by about 3-8mb before and after coLinux execution,
> but that could simply be buffers/cache.
> 
> -- Eric Andresen
> 
> 
> On Wed, 2004-03-03 at 19:07, Pat Erley wrote:
> > On Thu, 4 Mar 2004 01:02:46 +0100 (CET)
> > ch...@to... wrote:
> > 
> > > did you create a new kernel with initrd support?
> > > 
> > > did you read /usr/src/Documentation/initrd.txt
> > > I think root=/dev/cobd0 init=/linuxrc
> > > needs the explicit change root commands at the end of linuxrc
> > > where as intrd=  can use a linuxrc that will automaticly pivot root at the
> > > end.
> > > 
> > > if you checked out all this you could privatly e-mail me your linuxrc and
> > > .config for your kernel and I can look it over. I could also do some
> > > further experiments with what I have tomorow. I think I stopped at the
> > > same place you are due to not having the commands needed on my initrd and
> > > realizing that I had stripped my linuxrc down to almost nothing and I came
> > > up with another way to do it.
> > 
> > actually, it'd be colinux' job to handle loading the initrd into ram.  the entire point of initrd is to load the initrd into ram and then pass vmlinuz the location of it and let it start processing it, having not had to do any disk io.
> > 
> > Pat Erley
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

Re: [coLinux-devel] coLinux on NT4?

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

I think you are using the wrong library.
I asked a similar question a few days ago. Here is part of the message:

| Dan set the bridged daemon aside in the makefile. From the colinux/src
| dir:
|
| make bridged_net_daemon
|
| You may also need the winpcap headers, those are available on the
| winpcap site (google for link). I've been using the 3.0 Developer's
| Pack. Careful how you integrate these with the existing includes, make a
| backup of what's there since pcap includes some different versions of
| what's already there.

I cannot integrate the include files because I do not know how to do it
properly.
When you do integrate them please can you tell me what you did so I can
compile the conet-bridged-daemon too :)

----- Original Message ----- 
From: "Benoit MICHEL" <ben...@cg...>
To: "Cooperative Linux Development" <col...@li...>
Sent: Thursday, March 04, 2004 9:59 AM
Subject: Re: [coLinux-devel] coLinux on NT4?


| Hi all
|
| I succeed in running colinux on nt4 sp6a after replacing ExFreePoolWithTag
| (in src/colinux/winnt/kernel/lowlevel/alloc.c) with
| ExFreePool.
| and GlobalMemoryStatusEx (in /src/colinux/os/winnt/user/misc.c) with
| GlobalMemoryStatus.
| I just still have pb compiling conet-bridged-daemon, ld can't find -lwpcap
| I downloaded libpcap-8.xxxx.tar.gz
| untared it, configure with --prefix= and --target feeded
| make then make install without any pb
|
| any idea???
|
| thx
| Ben
|
| ----- Original Message -----
| From: "Benoit MICHEL" <ben...@cg...>
| To: "Cooperative Linux Development" <col...@li...>
| Sent: Wednesday, March 03, 2004 4:37 PM
| Subject: Re: [coLinux-devel] coLinux on NT4?
|
|
| > memory allocated with ExAllocatePoolWithTag can also be freed with
| > ExFreePool (wich is NT4 supported)
| > in the file src/colinux/winnt/kernel/lowlevel/alloc.c
| > I gonna try to compile tonight with the second in place of the
first......
| >
| > And this function is declared in win32api, include/ddk/winddk.h
| > these functions are dependent of a flag : POOL_TAGGING, does someone
know
| if
| > this is set in colinux cross compilation tools? I don't think so.
| >
| > thx
| > Ben
| >
| >
| > ----- Original Message -----
| > From: "Benoit MICHEL" <ben...@cg...>
| > To: "Digital Infra, Inc." <ok...@di...>
| > Cc: "Cooperative Linux Development"
<col...@li...>
| > Sent: Wednesday, March 03, 2004 9:59 AM
| > Subject: Re: [coLinux-devel] coLinux on NT4?
| >
| >
| > > Hi
| > >
| > > I'd like to use it at work, where i'm still using nt4 (really heavy to
| use
| > > cL through vmware)
| > > It is for a real usage AND optionnaly ;) for my pleasure ;)
| > > but at home.... XP, colinux rulez
| > > what do you mean by BSOD??
| > > and the daemon doesn't trapp, just show a messagebox with "device
driver
| > > d:\col\linux.sys was unable to find entry point for ExFreePoolWithTag
in
| > > ntoskrnl.exe driver" (litteral traduction, original was in french ;) )
| > then
| > > close the windows when I click on OK.
| > >
| > > It all began with the same symptoms complaining about
| GlobalMemoryStatusEx
| > > (not supported by NT4)
| > > I made these modifications in /src/colinux/os/winnt/user/misc.c
| > >
| > > diff says :
| > > 20,21c20,21
| > > <  MEMORYSTATUSEX m;
| > > <  BOOL ret;
| > > ---
| > > >  MEMORYSTATUS m;
| > > >  //BOOL ret;
| > > 24,25c24,25
| > > <  ret = GlobalMemoryStatusEx(&m);
| > > <  if (ret != TRUE) {
| > > ---
| > > >  /*ret = */GlobalMemoryStatus(&m);
| > > >  /*if (ret != TRUE) {
| > > 28c28
| > > <  }
| > > ---
| > > >  }*/
| > > 30c30
| > > <  if (m.ullTotalPhys > (DWORDLONG)0xFF000000) {
| > > ---
| > > >  if (m.dwTotalPhys > (DWORDLONG)0xFF000000) {
| > > 36c36
| > > <  *mem_size = 0xFF000000 & (((unsigned long)m.ullTotalPhys) +
| 0xFFFFFF);
| > > ---
| > > >  *mem_size = 0xFF000000 & (((unsigned long)m.dwTotalPhys) +
0xFFFFFF);
| > >
| > >
| > > just using GlobalMemoryStatus instead of GlobalMemoryStatusEx (my NT4
| > system
| > > is far below the 2GB limit ;) )
| > >
| > > no pb anymore to compile it at home using cobuild.sh (edited to not
| > > averwrite my modifications)
| > > and when I tried it today here, the daemon complains about
| > ExFreePoolWithTag
| > >
| > > When I look at my NTOSKRNL.EXE (v4.00) it exports ExFreePool but not
| > > ExFreePoolWithTag
| > >
| > > The doc I found say that nt4 SP4 workstation support this API, i'm in
| > sp6a.
| > >
| > > Benoit
| > >
| > >
| > > ----- Original Message -----
| > > From: "Digital Infra, Inc." <ok...@di...>
| > > To: "Benoit MICHEL" <bem...@ca...>
| > > Cc: "Cooperative Linux Development"
| <col...@li...>
| > > Sent: Tuesday, March 02, 2004 4:07 PM
| > > Subject: Re: [coLinux-devel] coLinux on NT4?
| > >
| > >
| > > >
| > > > Hello
| > > >
| > > > BTW, Why you have an interest about coLinux on NT4?
| > > > Just your hobby? or you have real usage?
| > > > but, at least, I welcome your effort very much.
| > > > because, with your effort, we can collect more hints to
| > > > stabilize coLinux. thanks Benoit!.
| > > > and please give us your history of BSOD with a stack trace.
| > > >
| > > >             --- Okajima.
| > >
| > >
| > >
| > > -------------------------------------------------------
| > > 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
| >
| >
| >
| > -------------------------------------------------------
| > 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
|
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by: IBM Linux Tutorials
| Free Linux tutorial presented by Daniel Robbins, President and CEO of
| GenToo technologies. Learn everything from fundamentals to system
| administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
| _______________________________________________
| coLinux-devel mailing list
| coL...@li...
| https://lists.sourceforge.net/lists/listinfo/colinux-devel

Re: [coLinux-devel] coLinux on NT4?

[Benoit M. <ben...@cg...>]

Hi all

I succeed in running colinux on nt4 sp6a after replacing ExFreePoolWithTag
(in src/colinux/winnt/kernel/lowlevel/alloc.c) with
ExFreePool.
and GlobalMemoryStatusEx (in /src/colinux/os/winnt/user/misc.c) with
GlobalMemoryStatus.
I just still have pb compiling conet-bridged-daemon, ld can't find -lwpcap
I downloaded libpcap-8.xxxx.tar.gz
untared it, configure with --prefix= and --target feeded
make then make install without any pb

any idea???

thx
Ben

----- Original Message -----
From: "Benoit MICHEL" <ben...@cg...>
To: "Cooperative Linux Development" <col...@li...>
Sent: Wednesday, March 03, 2004 4:37 PM
Subject: Re: [coLinux-devel] coLinux on NT4?


> memory allocated with ExAllocatePoolWithTag can also be freed with
> ExFreePool (wich is NT4 supported)
> in the file src/colinux/winnt/kernel/lowlevel/alloc.c
> I gonna try to compile tonight with the second in place of the first......
>
> And this function is declared in win32api, include/ddk/winddk.h
> these functions are dependent of a flag : POOL_TAGGING, does someone know
if
> this is set in colinux cross compilation tools? I don't think so.
>
> thx
> Ben
>
>
> ----- Original Message -----
> From: "Benoit MICHEL" <ben...@cg...>
> To: "Digital Infra, Inc." <ok...@di...>
> Cc: "Cooperative Linux Development" <col...@li...>
> Sent: Wednesday, March 03, 2004 9:59 AM
> Subject: Re: [coLinux-devel] coLinux on NT4?
>
>
> > Hi
> >
> > I'd like to use it at work, where i'm still using nt4 (really heavy to
use
> > cL through vmware)
> > It is for a real usage AND optionnaly ;) for my pleasure ;)
> > but at home.... XP, colinux rulez
> > what do you mean by BSOD??
> > and the daemon doesn't trapp, just show a messagebox with "device driver
> > d:\col\linux.sys was unable to find entry point for ExFreePoolWithTag in
> > ntoskrnl.exe driver" (litteral traduction, original was in french ;) )
> then
> > close the windows when I click on OK.
> >
> > It all began with the same symptoms complaining about
GlobalMemoryStatusEx
> > (not supported by NT4)
> > I made these modifications in /src/colinux/os/winnt/user/misc.c
> >
> > diff says :
> > 20,21c20,21
> > <  MEMORYSTATUSEX m;
> > <  BOOL ret;
> > ---
> > >  MEMORYSTATUS m;
> > >  //BOOL ret;
> > 24,25c24,25
> > <  ret = GlobalMemoryStatusEx(&m);
> > <  if (ret != TRUE) {
> > ---
> > >  /*ret = */GlobalMemoryStatus(&m);
> > >  /*if (ret != TRUE) {
> > 28c28
> > <  }
> > ---
> > >  }*/
> > 30c30
> > <  if (m.ullTotalPhys > (DWORDLONG)0xFF000000) {
> > ---
> > >  if (m.dwTotalPhys > (DWORDLONG)0xFF000000) {
> > 36c36
> > <  *mem_size = 0xFF000000 & (((unsigned long)m.ullTotalPhys) +
0xFFFFFF);
> > ---
> > >  *mem_size = 0xFF000000 & (((unsigned long)m.dwTotalPhys) + 0xFFFFFF);
> >
> >
> > just using GlobalMemoryStatus instead of GlobalMemoryStatusEx (my NT4
> system
> > is far below the 2GB limit ;) )
> >
> > no pb anymore to compile it at home using cobuild.sh (edited to not
> > averwrite my modifications)
> > and when I tried it today here, the daemon complains about
> ExFreePoolWithTag
> >
> > When I look at my NTOSKRNL.EXE (v4.00) it exports ExFreePool but not
> > ExFreePoolWithTag
> >
> > The doc I found say that nt4 SP4 workstation support this API, i'm in
> sp6a.
> >
> > Benoit
> >
> >
> > ----- Original Message -----
> > From: "Digital Infra, Inc." <ok...@di...>
> > To: "Benoit MICHEL" <bem...@ca...>
> > Cc: "Cooperative Linux Development"
<col...@li...>
> > Sent: Tuesday, March 02, 2004 4:07 PM
> > Subject: Re: [coLinux-devel] coLinux on NT4?
> >
> >
> > >
> > > Hello
> > >
> > > BTW, Why you have an interest about coLinux on NT4?
> > > Just your hobby? or you have real usage?
> > > but, at least, I welcome your effort very much.
> > > because, with your effort, we can collect more hints to
> > > stabilize coLinux. thanks Benoit!.
> > > and please give us your history of BSOD with a stack trace.
> > >
> > >             --- Okajima.
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
> -------------------------------------------------------
> 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

[coLinux-devel] new deluxe gentoo image.

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

http://killashandra.magenet.com/~s0be/

there is now a 'deluxe' gentoo image available here.  this should also not have the crashing issue.

Pat Erley

Re: [coLinux-devel] Initrd support?

[Eric A. <ea...@ma...>]

Correct. I've basically bypassed this failing by loading it as a block
device, though. In order to make it act as an initrd in this case, you
have to add the line:
exec chroot . /sbin/init <dev/console >dev/console 2>&1

*after* your pivot_root, otherwise when your script ends, so does your
kernel's lifeline.

I've basically finished my initrd work, and it appears to working well.
During this configuration process, though, I've noticed a disturbing
problem that I can confirm occurs on two different windows machines (one
running Server 2003, the other XP Pro): The first time through, coLinux
runs happily, until the point where init effectively dies (not the
problem, simply unfinished configuration). So, I close coLinux, and
restart it. This time coLinux hangs the entire system sometime before
the expected dying of init (right after setting the system clock, but I
doubt that is even relevant).

I'm using the 20040304 development snapshot. I'm not sure what the cause
of this problem is, but my guess would be something is not being
properly cleaned out when coLinux closes the first time around. There
was a single time where it did not occur until the third restart of
coLinux.

Memory usage differed by about 3-8mb before and after coLinux execution,
but that could simply be buffers/cache.

-- Eric Andresen


On Wed, 2004-03-03 at 19:07, Pat Erley wrote:
> On Thu, 4 Mar 2004 01:02:46 +0100 (CET)
> ch...@to... wrote:
> 
> > did you create a new kernel with initrd support?
> > 
> > did you read /usr/src/Documentation/initrd.txt
> > I think root=/dev/cobd0 init=/linuxrc
> > needs the explicit change root commands at the end of linuxrc
> > where as intrd=  can use a linuxrc that will automaticly pivot root at the
> > end.
> > 
> > if you checked out all this you could privatly e-mail me your linuxrc and
> > .config for your kernel and I can look it over. I could also do some
> > further experiments with what I have tomorow. I think I stopped at the
> > same place you are due to not having the commands needed on my initrd and
> > realizing that I had stripped my linuxrc down to almost nothing and I came
> > up with another way to do it.
> 
> actually, it'd be colinux' job to handle loading the initrd into ram.  the entire point of initrd is to load the initrd into ram and then pass vmlinuz the location of it and let it start processing it, having not had to do any disk io.
> 
> Pat Erley

Re: [coLinux-devel] Initrd support?

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

On Thu, 4 Mar 2004 01:02:46 +0100 (CET)
ch...@to... wrote:

> did you create a new kernel with initrd support?
> 
> did you read /usr/src/Documentation/initrd.txt
> I think root=/dev/cobd0 init=/linuxrc
> needs the explicit change root commands at the end of linuxrc
> where as intrd=  can use a linuxrc that will automaticly pivot root at the
> end.
> 
> if you checked out all this you could privatly e-mail me your linuxrc and
> .config for your kernel and I can look it over. I could also do some
> further experiments with what I have tomorow. I think I stopped at the
> same place you are due to not having the commands needed on my initrd and
> realizing that I had stripped my linuxrc down to almost nothing and I came
> up with another way to do it.

actually, it'd be colinux' job to handle loading the initrd into ram.  the entire point of initrd is to load the initrd into ram and then pass vmlinuz the location of it and let it start processing it, having not had to do any disk io.

Pat Erley

FW: [coLinux-devel] coSerial driver

[peter g. <plu...@p1...>]

sorry forgot to click reply-all and send this to the list

-----Original Message-----
From: peter green [mailto:plu...@p1...]
Sent: 04 March 2004 01:22
To: ch...@to...
Subject: RE: [coLinux-devel] coSerial driver


if slirp is functioning properly it shouldn't matter how the host connects
to the internet any more than it matters to a normal internet useing app
that is the beauty of it :)


-----Original Message-----
From: col...@li...
[mailto:col...@li...]On Behalf Of
ch...@to...
Sent: 04 March 2004 01:09
To: peter green
Cc: Digital Infra, Inc.; Pat Erley; col...@li...
Subject: RE: [coLinux-devel] coSerial driver


I guess what is needed for a coKnoppix type distro is some kind of
userland network driver that is just an exe file that can take it's
configuration as args. Getting communication with the host automaticly is
esential but comunicating with the outside it would be ok to allow some
manual configuration because the circumstances will vary.

chris

> the trouble with windows nat is it requires messing with settings on the
> host
>
> which makes it toally unsuitable for a coknoppix type distro
>
> slirp linked to a virtual serial port on the colinux box should provide a
> soloution that requires sero configuration on the windows side
>
> -----Original Message-----
> From: col...@li...
> [mailto:col...@li...]On Behalf Of Digital
> Infra, Inc.
> Sent: 03 March 2004 22:39
> To: Pat Erley
> Cc: col...@li...
> Subject: Re: [coLinux-devel] coSerial driver
>
>
>
> Hello Erley.
>
>
> Good. but what you use it for?
> For an internet connection, I think Windows NAT function is enough.
> Maybe "coUSB device" is more interesting,
> because USB<->serial convert cable is very cheap.
> (But I dont know what to use this driver also ;-)
>
>                   --- Okajima.
>
>
>>I plan on starting a coSerial driver some time tonight.  The driver will
> work as
> follows:
>>
>>a line in config.xml creates a /dev/ttySn, and has a
>> colinux-serial-daemon
> that it will
> call, that will pass to/from stdin/out on another program.  Examples of
> such
> programs
> could be a slirp daemon, a serial console daemon, a virtual palm pilot....
> really
> anything for windows that you could want to communicate with a linux
> program.
>>
>>you could also initiate the serial daemon from outside the xml file, and
>> it
> would grab
> the first available ttyS.
>>
>>Any time a ttyS is activated, it should dump a dmesg entry (for hotplug
> purposes)
>>
>>If you have an entry in the config file that doesn't auto start, you'd
> issue a echo to a
> device in /dev to trigger it activating.
>>
>>I havn't decided whether to have your echo go to the device you want to
> activate like:
>>
>>echo 1 > /dev/ttyS0
>>
>>or a master device you echo a ttynumber to activate to
>>
>>echo 2 > /dev/coserial
>>
>>I plan on starting on this sometime soon(next day or two) and would like
> feedback/feature requests.
>>
>>Pat Erley
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>coLinux-devel mailing list
>>coL...@li...
>>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
coLinux-devel mailing list
coL...@li...
https://lists.sourceforge.net/lists/listinfo/colinux-devel
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004

Re[2]: [coLinux-devel] coSerial driver

[Dmitriy K. <dm...@ka...>]

DII> Good. but what you use it for?
DII> For an internet connection, I think Windows NAT function is enough.
We neened to configure Windows NAT, which is not always
possible/applicable
Also, I think it's possible to use coLinux with coserial as firewall for standalone
dialup Windows host



-- 
With regerds
 Dmitriy                          mailto:dm...@ka...

RE: [coLinux-devel] coSerial driver

[<ch...@to...>]

I guess what is needed for a coKnoppix type distro is some kind of
userland network driver that is just an exe file that can take it's
configuration as args. Getting communication with the host automaticly is
esential but comunicating with the outside it would be ok to allow some
manual configuration because the circumstances will vary.

chris

> the trouble with windows nat is it requires messing with settings on the
> host
>
> which makes it toally unsuitable for a coknoppix type distro
>
> slirp linked to a virtual serial port on the colinux box should provide a
> soloution that requires sero configuration on the windows side
>
> -----Original Message-----
> From: col...@li...
> [mailto:col...@li...]On Behalf Of Digital
> Infra, Inc.
> Sent: 03 March 2004 22:39
> To: Pat Erley
> Cc: col...@li...
> Subject: Re: [coLinux-devel] coSerial driver
>
>
>
> Hello Erley.
>
>
> Good. but what you use it for?
> For an internet connection, I think Windows NAT function is enough.
> Maybe "coUSB device" is more interesting,
> because USB<->serial convert cable is very cheap.
> (But I dont know what to use this driver also ;-)
>
>                   --- Okajima.
>
>
>>I plan on starting a coSerial driver some time tonight.  The driver will
> work as
> follows:
>>
>>a line in config.xml creates a /dev/ttySn, and has a
>> colinux-serial-daemon
> that it will
> call, that will pass to/from stdin/out on another program.  Examples of
> such
> programs
> could be a slirp daemon, a serial console daemon, a virtual palm pilot....
> really
> anything for windows that you could want to communicate with a linux
> program.
>>
>>you could also initiate the serial daemon from outside the xml file, and
>> it
> would grab
> the first available ttyS.
>>
>>Any time a ttyS is activated, it should dump a dmesg entry (for hotplug
> purposes)
>>
>>If you have an entry in the config file that doesn't auto start, you'd
> issue a echo to a
> device in /dev to trigger it activating.
>>
>>I havn't decided whether to have your echo go to the device you want to
> activate like:
>>
>>echo 1 > /dev/ttyS0
>>
>>or a master device you echo a ttynumber to activate to
>>
>>echo 2 > /dev/coserial
>>
>>I plan on starting on this sometime soon(next day or two) and would like
> feedback/feature requests.
>>
>>Pat Erley
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>coLinux-devel mailing list
>>coL...@li...
>>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

RE: [coLinux-devel] coSerial driver

[peter g. <plu...@p1...>]

the trouble with windows nat is it requires messing with settings on the
host

which makes it toally unsuitable for a coknoppix type distro

slirp linked to a virtual serial port on the colinux box should provide a
soloution that requires sero configuration on the windows side

-----Original Message-----
From: col...@li...
[mailto:col...@li...]On Behalf Of Digital
Infra, Inc.
Sent: 03 March 2004 22:39
To: Pat Erley
Cc: col...@li...
Subject: Re: [coLinux-devel] coSerial driver



Hello Erley.


Good. but what you use it for?
For an internet connection, I think Windows NAT function is enough.
Maybe "coUSB device" is more interesting,
because USB<->serial convert cable is very cheap.
(But I dont know what to use this driver also ;-)

                  --- Okajima.


>I plan on starting a coSerial driver some time tonight.  The driver will
work as
follows:
>
>a line in config.xml creates a /dev/ttySn, and has a colinux-serial-daemon
that it will
call, that will pass to/from stdin/out on another program.  Examples of such
programs
could be a slirp daemon, a serial console daemon, a virtual palm pilot....
really
anything for windows that you could want to communicate with a linux
program.
>
>you could also initiate the serial daemon from outside the xml file, and it
would grab
the first available ttyS.
>
>Any time a ttyS is activated, it should dump a dmesg entry (for hotplug
purposes)
>
>If you have an entry in the config file that doesn't auto start, you'd
issue a echo to a
device in /dev to trigger it activating.
>
>I havn't decided whether to have your echo go to the device you want to
activate like:
>
>echo 1 > /dev/ttyS0
>
>or a master device you echo a ttynumber to activate to
>
>echo 2 > /dev/coserial
>
>I plan on starting on this sometime soon(next day or two) and would like
feedback/feature requests.
>
>Pat Erley
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
coLinux-devel mailing list
coL...@li...
https://lists.sourceforge.net/lists/listinfo/colinux-devel
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.592 / Virus Database: 375 - Release Date: 18/02/2004

Re: [coLinux-devel] Initrd support?

[<ch...@to...>]

did you create a new kernel with initrd support?

did you read /usr/src/Documentation/initrd.txt
I think root=/dev/cobd0 init=/linuxrc
needs the explicit change root commands at the end of linuxrc
where as intrd=  can use a linuxrc that will automaticly pivot root at the
end.

if you checked out all this you could privatly e-mail me your linuxrc and
.config for your kernel and I can look it over. I could also do some
further experiments with what I have tomorow. I think I stopped at the
same place you are due to not having the commands needed on my initrd and
realizing that I had stripped my linuxrc down to almost nothing and I came
up with another way to do it.

chris

> initrd= doesn't work for coLinux because it can't find the file. This is
> fine, as I should be able to simulate the same result by using
> root=/dev/cobd0 init=/linuxrc, which works. The problem comes when the
> pivot_root call is made..
>
> EXT3-fs: mounted filesystem with ordered data mode.
> Kernel panic: Attempted to kill init!
>  daemon: monitor terminated, reason 3
> switch_message: freed message a047010 (2 to 4)
> daemon: module disconnected: console
> colinux: shutting down
> daemon: daemon cleanup
> Removing kernel driver
> Stopping driver service
> Removing driver service
>
> Unfortunately, this also makes the Console go completely blank on me, so
> it's hard to see if there were any other problems.
>
> If anyone could give some assistance, that would be great.
>
> --
> Eric Andresen
> Junior Systems Administrator
> Mars Space Flight Facility
> Arizona State University
> ea...@ma...
>
> On Wed, 2004-03-03 at 05:49, ch...@to... wrote:
>> see initrd.txt in a 2.4.24 kernel source documentation.
>> the newer way of specifying initrd with the explicit change_root may
>> work.
>> you will need to compile your own kernel at this time as the coLinux
>> binary kernel does not support initrd. Just apply the coLinux patch and
>> make shure you have all the initrd related options selected in
>> .configure
>> .
>>
>> I was experimenting with an initrd based setup that I was using but
>> after
>> eleminating the stuff I didn't need for coLinux mode from linuxrc I
>> realized that I could just skip the initrd and boot directly to the root
>> image.
>>
>> initrd supplying hardware modules should not be necessary because the
>> "hardware enviroment" is fixed and taken care of by the coLinux patch.
>> the initrd mounting loops may also be unnecessary because you could just
>> set that all up in the coLinux config and fstab.
>>
>> so It may be worth considering do you really need the initrd.
>>
>> chris
>>
>> > Hi,
>> >
>> > I'm trying to essentially port my current UML configuration over to a
>> > similar coLinux setup, but the first obvious problem that comes to
>> mind
>> > is that there does not appear to be a way to specify initrds.
>> >
>> > Am I mistaken, or is this so? This is a requirement for my setup,
>> > because the initrd creates a number of tmpfs filesystems for /etc,
>> /var,
>> > and /tmp (for specific reasons outside of the realm of this topic).
>> >
>> > Also, regarding the memory restrictions: is there no other possible
>> way
>> > to allocate physical ram? I find it hard to think that no Windows
>> > application surpasses this memory usage (VMware? Most games?); is
>> there
>> > a chance that one of these alternate memory allocation sources could
>> be
>> > used, thus allowing more realistic physical memory usages?
>> >
>> > Thanks,
>> > -- Eric Andresen
>> >    Junior Systems Administrator
>> >    Mars Space Flight Facility
>> >    Arizona State University
>> >    ea...@ma...
>> >
>
>

Re: [coLinux-devel] Some file creation utilities

[<ch...@to...>]

I am working on a tool that can do this as well. Mine was originally
created for loopback files on ntfs so it did not use a sparce file because
a change in filesize without windows in control could be bad news

The program that I have created is a tcl/tk starpack so it is kinda bulky
due to the executable containing a whole tcl/tk interpreter but it does
have a nice gui

I am currently experimenting with having it be able to add space to the
file and call resize2fs.exe create a new file and optionally call mke2fs
and format the file to either ext2 or 3  It will also call e2fsck before
and after any resize.

I am debating on wether or not to add sparce file support do to the fact
that sparce files can only be used if the filesystem will never be used
outside of colinux (ie. a dualboot mode) if resideing on NTFS

chris

> I have created some utilities for creating large files under windows for
> file systems. You can get them at
> http://www.geocities.com/dan_slater/colinux/utils.zip
>
> In this zip file you will find 3 executables and sources. The utilities
> are:
>
> mkFile.exe - use this to easily create a large file for your
> file-system. If you have an ntfs 5.0 partition ( the default for Windows
> 2000 and later ). Then be sure to use the -s option to create a sparse
> file. When you create a sparse file, windows only allocates disk space
> for the non-zero data. For example:
>
> mkFile -s root_fs 10G
>
> This will create a 10GB empty file named root_fs. If you look at the
> file with explorer properties or use the spsize utility, you will see
> that the while the file is 10 GB, the allocated disk space is 0 bytes.
>
> spsize - use this to check the size of a sparse file - it will report
> both the file size and the disk space used
>
> mkSparse - run this on an existing file to convert it to a sparse file -
> note: there is a lot of room for improvement for this one. Also, be
> aware this one modifies your file so it has the potential to destroy
> your data if I got something wrong.
>
> Still to do: would be nice to have a linux utility that walks the free
> space on your filesystem and zeros out any non-zero clusters before
> running mkSparse.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id70&alloc_id638&op¿ick
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

Re: [coLinux-devel] coSerial driver

[Digital I. Inc. <ok...@di...>]

And I invented(?) more generic way.

How about "piggy-back everything" driver.

I mean, assumes there is a TCP/IP connection.
and in that connection, there is a serial line data, USB data,,,,,.
in other words, what I want to say is, on an USB cable, you can put
every kind of data on it.  sound, mouse, serial, printer....
then, why we can not put them on TCP/IP?

           |sound|                             |speaker|
|Linux| -> |serial|  -> TCP/IP -> |windows| -> |serial|
           |USB|                               |USB

This is useful not only for coLinux user, but normal Linux user.

                    --- Okajima.
  

Re: [coLinux-devel] coSerial driver

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

On Thu, 04 Mar 2004 01:45:57 +0300
Vlad Doubrov <vl...@w-...> wrote:

> Pat Erley wrote:
> 
> > I plan on starting a coSerial driver some time tonight.  The driver will work as follows:
> 
>  > a line in config.xml creates a /dev/ttySn, and has a
>  > colinux-serial-daemon that it will call, that will pass to/from
>  > stdin/out on another program.  Examples of such programs could be a
>  > slirp daemon, a serial console daemon, a virtual palm pilot.... really
>  > anything for windows that you could want to communicate with a linux
>  > program.
> 
> Seems to be a very good idea, but it'd be better if it provides a
> virtual COM-port interface at the Windows side. An example of virtual
> COM-port implementation can be found at http://www.ircomm2k.de/ - I used
> to look at it sources and it seems to support only one port, so some
> enhancements are needed.

The virtual comport part would be something that would be a client of this.
 
> Also it would be nice if it supports not only simple data transfer, but
> control signals too (RTS, CTS, DTR, etc...)

hmmm.  ok, I'll keep that in mind.
 
Pat

Re: [coLinux-devel] coSerial driver

[Vlad D. <vl...@w-...>]

Pat Erley wrote:

> I plan on starting a coSerial driver some time tonight.  The driver will work as follows:

 > a line in config.xml creates a /dev/ttySn, and has a
 > colinux-serial-daemon that it will call, that will pass to/from
 > stdin/out on another program.  Examples of such programs could be a
 > slirp daemon, a serial console daemon, a virtual palm pilot.... really
 > anything for windows that you could want to communicate with a linux
 > program.

Seems to be a very good idea, but it'd be better if it provides a
virtual COM-port interface at the Windows side. An example of virtual
COM-port implementation can be found at http://www.ircomm2k.de/ - I used
to look at it sources and it seems to support only one port, so some
enhancements are needed.

Also it would be nice if it supports not only simple data transfer, but
control signals too (RTS, CTS, DTR, etc...)

-- vlad

Re: [coLinux-devel] coSerial driver

[Digital I. Inc. <ok...@di...>]

Hello Erley.


Good. but what you use it for?
For an internet connection, I think Windows NAT function is enough.
Maybe "coUSB device" is more interesting,
because USB<->serial convert cable is very cheap.
(But I dont know what to use this driver also ;-)

                  --- Okajima.


>I plan on starting a coSerial driver some time tonight.  The driver will work as 
follows:
>
>a line in config.xml creates a /dev/ttySn, and has a colinux-serial-daemon that it will 
call, that will pass to/from stdin/out on another program.  Examples of such programs 
could be a slirp daemon, a serial console daemon, a virtual palm pilot.... really 
anything for windows that you could want to communicate with a linux program.
>
>you could also initiate the serial daemon from outside the xml file, and it would grab 
the first available ttyS. 
>
>Any time a ttyS is activated, it should dump a dmesg entry (for hotplug purposes) 
>
>If you have an entry in the config file that doesn't auto start, you'd issue a echo to a 
device in /dev to trigger it activating. 
>
>I havn't decided whether to have your echo go to the device you want to activate like:
>
>echo 1 > /dev/ttyS0
>
>or a master device you echo a ttynumber to activate to
>
>echo 2 > /dev/coserial
>
>I plan on starting on this sometime soon(next day or two) and would like 
feedback/feature requests.
>
>Pat Erley
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>coLinux-devel mailing list
>coL...@li...
>https://lists.sourceforge.net/lists/listinfo/colinux-devel
>

[coLinux-devel] coSerial driver

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

I plan on starting a coSerial driver some time tonight.  The driver will work as follows:

a line in config.xml creates a /dev/ttySn, and has a colinux-serial-daemon that it will call, that will pass to/from stdin/out on another program.  Examples of such programs could be a slirp daemon, a serial console daemon, a virtual palm pilot.... really anything for windows that you could want to communicate with a linux program.

you could also initiate the serial daemon from outside the xml file, and it would grab the first available ttyS. 

Any time a ttyS is activated, it should dump a dmesg entry (for hotplug purposes) 

If you have an entry in the config file that doesn't auto start, you'd issue a echo to a device in /dev to trigger it activating. 

I havn't decided whether to have your echo go to the device you want to activate like:

echo 1 > /dev/ttyS0

or a master device you echo a ttynumber to activate to

echo 2 > /dev/coserial

I plan on starting on this sometime soon(next day or two) and would like feedback/feature requests.

Pat Erley