Menu
▾
▴
colinux-users
|
From: Jules <ju...@ds...> - 2004-09-07 21:33:25
|
I've been using the colinux 2004-07-10 snapshot with some success for a little while now (host system WinXP Pro), but recently I decided to compile a new kernel as the one included with the snapshot lacks a few features I wanted. I downloaded the source to the 2.6.7 kernel and applied the patch included in the colinux source to it, made a few changes to the config and then compiled it. The resulting kernel runs, but occasionally processes die unexpectedly with a signal 11. I've also seen corruption on my root ext3 filesystem -- I'm not sure if this was related or not. Has anyone encountered similar problems, or is it just me? For reference, my distribution is SuSE 9.1 personal with a load of extra development tools downloaded from the standard SuSE 9.1 drectory. |
|
From: Sandy H. <sa...@st...> - 2004-09-09 00:31:54
|
Jules wrote: > ... The resulting kernel runs, but occasionally > processes die unexpectedly with a signal 11. I've also seen corruption > on my root ext3 filesystem -- I'm not sure if this was related or not. > > Has anyone encountered similar problems, or is it just me? > It may be outdated and may not apply to your problem, but it is probably worth looking at the sig 11 FAQ: http://www.bitwizard.nl/sig11/ |
|
From: Chuck A. <ch...@da...> - 2004-09-09 16:51:47
|
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: > http://www.bitwizard.nl/sig11/ 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. chuck |
|
From: Doctor B. <do...@gm...> - 2004-09-10 12:22:54
|
Yes. The general problem with the FAQ is it assumes the gcc and
kernel have been well tested under all possible configurations. I
have seen sig 11 problems on many different hardware platforms in many
different cases. In most cases I attributed it to an inadequately
tested configuration, and the fact most people do not report the sig
11 problem when it occurs. Why? Well if the location of the error
depends on the hardware configuration you are using, it is unlikely
someone else would be able to successfully debug the problem without
access to the same machine. Sometimes it is repeatable on the same
file, regardless of current memory usage, sometimes not. Most
commonly I've seen the problem under Solaris, where the bootstrapping
process is very particular about what set of bin utils you use, what
compiler you bootstrap from etc. It seems after each major upgrade of
gcc, the bootstrapping order I need to follow to get a compiler that
does not sig 11 under Solaris is always slightly different.
Does that mean it isn't a hardware problem? Not at all. It could be
that the many different boxes I've seen the problem in the past all
share a similar design flaw, and finding a way of doing a majic build
of gcc that does not have the problem is just working around the
problem. It is also possible that in the upgrade, someone added code
to workaround the hardware problem. Possible, but not likely.
Under coLinux, I believe the most common culprit is corrupt or heavily
fragmented swap files.
Bill
On Thu, 09 Sep 2004 09:51:36 -0700, Chuck Adams <ch...@da...> wrote:
> 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:
> > http://www.bitwizard.nl/sig11/
>
>
> 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.
>
> chuck
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>
>
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>
|
|
From: Henry N. <Hen...@Ar...> - 2004-09-10 10:15:56
|
Jules wrote: > I've been using the colinux 2004-07-10 snapshot with some success for a > little while now (host system WinXP Pro), but recently I decided to > compile a new kernel as the one included with the snapshot lacks a few > features I wanted. > > I downloaded the source to the 2.6.7 kernel and applied the patch > included in the colinux source to it, made a few changes to the config > and then compiled it. The resulting kernel runs, but occasionally > processes die unexpectedly with a signal 11. I've also seen corruption > on my root ext3 filesystem -- I'm not sure if this was related or not. > > Has anyone encountered similar problems, or is it just me? > > For reference, my distribution is SuSE 9.1 personal with a load of extra > development tools downloaded from the standard SuSE 9.1 drectory. If you recompile kernel, you should also recompile colinux daemons. It's strictly recommented, to use the same GCC version for kernel and daemons. -- Henry Nestler |
|
From: Jules <ju...@ds...> - 2004-09-12 16:02:17
|
> If you recompile kernel, you should also recompile colinux daemons. > It's strictly recommented, to use the same GCC version for kernel and > daemons. Surely the colinux daemons require a windows or cross-compiler? FWIW, a kernel compiled with the default config packaged with the colinux source worked fine; it seems to be associated with one of the options I changed. I haven't investigated enough to determine which one, exactly, but my prime suspect is the CPU type, which I changed to AMD Athlon, as that is the architecture I run on. |
Thanks for helping keep SourceForge clean.
X