From: firstname.lastname@example.org [mailto:email@example.com]On Behalf Of shruti pandey
Sent: 11 September 2004 14:49
Subject: [coLinux-users] linux kernel port
hi there ,like uml is a a port of linux kernel to a linux kernel , and it uses the architectural port --ARCH=um--which one does coLinux use?thanksshruti
firstname.lastname@example.org wrote:Send coLinux-users mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of coLinux-users digest..."
1. Re: Random signal 11 problems? (Jules)
2. Re: Random signal 11 problems? (Chuck Adams)
3. Does colinux work on NT4 (Shi, Jue)
4. Re: Does colinux work on NT4 (Nuno Lucas)
5. A fix for the SIGFPE problem (>20040622) (Dan Aloni)
Date: Thu, 09 Sep 2004 09:40:24 +0100
Subject: [coLinux-users] Re: Random signal 11 problems?
>It may be outdated and may not apply to your
>problem, but it is probably worth looking at
>the sig 11 FAQ:
Thanks. I'm pretty sure this isn't hardware related, as the same system
runs the kernel supplied with the binary package just fine, plus kernels
compiled by myself work OK without colinux.
I've compiled a copy of the kernel with the config file supplied in the
colinux source distribution, and that seems to be working, I'm going
through a second compile of it now, with it running, and it seems to be
pretty stable. It's got a lot farther than the last one did, at least.
So I guess it was one of the config options that did it. Are there any
that are known to be dangerous with colinux? The main changes I made
were optimising for my processor environment (changed from CONFIG_M586
to CONFIG_MK7, disabled CONFIG_X86_GENERIC, all consequential changes
from this). I also killed support for a.out binaries, moved binfmt_misc
to a module, switched off the kernel debugging options, and added
support for unloading modules.
There were other changes too, but mostly relating to filesystems, which
I don't think are likely candidates.
Any suggestions on what may have caused the problem?
Date: Thu, 09 Sep 2004 09:51:36 -0700
From: Chuck Adams
To: Sandy Harris
Subject: Re: [coLinux-users] Random signal 11 problems?
Sandy Harris wrote:
> It may be outdated and may not apply to your
> problem, but it is probably worth looking at
> the sig 11 FAQ:
Actually it's almost never worth looking at that FAQ. It's pure
baloney. I remember this FAQ getting thrown at me before ... Yes,
memory glitches may cause segfaults and if random apps are failing at
random times, it's worth running memtest. But there are claims in that
FAQ that are just absurd. I always found it odd how it was *just* gcc
that somehow "stressed the memory" and therefore just gcc that would
segfault. Occam's razor was right all along of course -- it was a bug
in gcc. Either that or the next upgrade magically fixed my hardware.
From: "Shi, Jue"
Date: Thu, 9 Sep 2004 10:15:18 -0700
Subject: [coLinux-users] Does colinux work on NT4
I tried to install Colinux on Windows NT4, and get an error message "An
error occured installing the tap-win32 device driver". Does Colinux work on
NT4 at all, or it's just my PC setup problem?
BTW, I have colinux running on my XP box working fine.
Date: Thu, 09 Sep 2004 18:38:35 +0100
From: Nuno Lucas
Cc: "Shi, Jue"
Subject: Re: [coLinux-users] Does colinux work on NT4
Shi, Jue, dando pulos de alegria, escreveu :
> I tried to install Colinux on Windows NT4, and get an error message "An
> error occured installing the tap-win32 device driver". Does Colinux work on
> NT4 at all, or it's just my PC setup problem?
> BTW, I have colinux running on my XP box working fine.
At this phase of development it is only expected to run ok in Win2000
I don't think it should be too difficult to make it work on NT4 (with a
recent Service Pack, at least), but it may be premature to think about
porting to old machines (for now at least).
In relation to Win9x, it would need a big patch to work, but no one says
it's impossible. But I don't know if there will be someone interested on
doing that port....
Date: Thu, 9 Sep 2004 22:52:00 +0300
From: Dan Aloni
Cc: "Joe Wells (reverse mailbox letters for non-public replies)"
, Peng ,
Subject: [coLinux-users] A fix for the SIGFPE problem (>20040622)
Thanks to Joe I was able to reproduce the problem locally and worked
on a fix which makes the problem disappear.
For the technical aspect: Since until now none of the code in
arch/i386/kernel/head.S actually runs when coLinux starts I've suspected
that there could be some initialization problem - if the kernel is not
precisely aware of the CPU's capabilities and decides not to save the
MMX registers between context switches it can indeed cause a problem. In
a multi-process scenario (such as the one with gdb and Joe's program) the
problem was indeed triggered before.
I've already commited the patch into the monotone server. If you can
check that firefox / xdvi aren't crashing anymore I'd be glad.
diff -u b/arch/i386/kernel/cooperative.c b/arch/i386/kernel/cooperative.c
@@ -85,6 +85,15 @@
__asm__ __volatile__("movl %%cr4, %0" : "=r" (mmu_cr4_features));
+ ".section .text\n"
+ ".globl co_arch_start_kernel\n"
+ " call co_startup_entry\n"
diff -u b/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
@@ -238,6 +238,7 @@
movl $-1,X86_CPUID # -1 for no CPUID initially
diff -u b/include/linux/cooperative_internal.h b/include/linux/cooperative_internal.h
@@ -28,6 +28,7 @@
extern void co_idle_processor(void);
extern void co_terminate(co_termination_reason_t reason);
extern void co_start_kernel(void);
+extern void co_arch_start_kernel(void);
extern void co_handle_jiffies(long count);
extern void co_send_message(co_module_t from,
diff -u b/kernel/cooperative.c b/kernel/cooperative.c
@@ -48,8 +48,9 @@
+ /* should never be reached */
coLinux-users mailing list
End of coLinux-users Digest
Yahoo! India Matrimony: Find your life partner online.