Ive also had a problem with signal 11, heres a great page explaining the aspects of
signal 11 error from gcc (http://www.bitwizard.nl/sig11/).
Signal 11 is usually a hardware problem, as the article points out. I found a sloppy
soulution playing with my BIOS settings, turns out
Ive also had a problem with signal 11, heres a great page explaining the aspects of
signal 11 error from gcc (http://www.bitwizard.nl/sig11/).
Signal 11 is usually a hardware problem, as the article points out. I found a sloppy
soulution playing with my BIOS settings, turns out
Riley Williams wrote:
> Hi Peter.
>
> >> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
>
> > Perhaps, but is has absolutely nothing to do with the rest of
> > this discussion.
>
> The `lock halt` bug patch was specific to the Cyrix processors (not to
> be confused with
Riley Williams wrote:
>
> Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
>
Perhaps, but is has absolutely nothing to do with the rest of this
discussion.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Followup to: <[EMAIL PROTECTED]>
By author:szonyi calin <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs
Followup to: [EMAIL PROTECTED]
By author:szonyi calin [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Almost always ?
It seems like gcc is THE ONLY program which gets
signal 11
Why the X server doesn't get signal 11 ?
Why others programs don't get signal 11 ?
gcc happens to be one
Riley Williams wrote:
Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
Perhaps, but is has absolutely nothing to do with the rest of this
discussion.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Riley Williams wrote:
Hi Peter.
Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
Perhaps, but is has absolutely nothing to do with the rest of
this discussion.
The `lock halt` bug patch was specific to the Cyrix processors (not to
be confused with the `lock
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs don't get signal 11 ?
...
> Some time ago I installed Linux (Redhat 6.0) on my
> pc (Cx486 8M RAM) and gcc had a lot of signal
t; > > a application. It only parse and gernerates
> > object files. How can RAM or
> > > motherboard makes different
> >
> > It's most likely flackey memory.
> >
> > Remember- a single bit that dropps can cause the
> > signal 11. It doesn't have
>
At 10:20 AM 6/29/01, you wrote:
>Almost always ?
>It seems like gcc is THE ONLY program which gets
>signal 11
>Why the X server doesn't get signal 11 ?
>Why others programs don't get signal 11 ?
>
>I remember that once Bill Gates was asked about
>crashes in windows and
t;
> It's most likely flackey memory.
>
> Remember- a single bit that dropps can cause the
> signal 11. It doesn't have
> to happen consistently either. I had the same
> problem until I slowed down
> memory access (that seemd to cover the borderline
> chip).
>
> The comp
ed with gcc without any problem. Again compilation is only
> a application. It only parse and gernerates object files. How can RAM or
> motherboard makes different
It's most likely flackey memory.
Remember- a single bit that dropps can cause the signal 11. It doesn't have
to happen consis
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote:
>
> "This is almost always the result of flakiness in your hardware - either
> RAM (most likely), or motherboard (less likely). "
>
> I cannot understand this. There are many
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote:
This is almost always the result of flakiness in your hardware - either
RAM (most likely), or motherboard (less likely).
I cannot understand this. There are many other
compilation is only
a application. It only parse and gernerates object files. How can RAM or
motherboard makes different
It's most likely flackey memory.
Remember- a single bit that dropps can cause the signal 11. It doesn't have
to happen consistently either. I had the same problem until I slowed
that I compiled with gcc without any
problem. Again compilation is only
a application. It only parse and gernerates
object files. How can RAM or
motherboard makes different
It's most likely flackey memory.
Remember- a single bit that dropps can cause the
signal 11. It doesn't have
At 10:20 AM 6/29/01, you wrote:
Almost always ?
It seems like gcc is THE ONLY program which gets
signal 11
Why the X server doesn't get signal 11 ?
Why others programs don't get signal 11 ?
I remember that once Bill Gates was asked about
crashes in windows and he said: It's a hardware
problem
.
Remember- a single bit that dropps can cause the
signal 11. It doesn't have
to happen consistently either. I had the same
problem until I slowed down
memory access (that seemd to cover the borderline
chip).
The compiler uses different amounts of memory
depending on the source file
Almost always ?
It seems like gcc is THE ONLY program which gets
signal 11
Why the X server doesn't get signal 11 ?
Why others programs don't get signal 11 ?
...
Some time ago I installed Linux (Redhat 6.0) on my
pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a
couple every hour) I
"This is almost always the result of flakiness in your hardware - either
RAM (most likely), or motherboard (less likely). "
I cannot understand this. There are many other
stuffs that I compiled with gcc without any problem. Again
hi
I am trying to compile the kernel2.4.5 source code.
Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2. Now when I
compile I will get the following error
gcc: Internel compiler error: program cc1 got fatal signal 11
make Error 1
Leaving directory
hi
I am trying to compile the kernel2.4.5 source code.
Presently I have kernel2.2.14 and Redhat6.2. I have egcs1.2.2. Now when I
compile I will get the following error
gcc: Internel compiler error: program cc1 got fatal signal 11
make Error 1
Leaving directory
This is almost always the result of flakiness in your hardware - either
RAM (most likely), or motherboard (less likely).
I cannot understand this. There are many other
stuffs that I compiled with gcc without any problem. Again compilation
Hi all,
Well, I upgraded my system to glibc 2.2.1 with few problems. Unfortunately,
there are no improvements in my stability problems. X still dies.
So, I ask again, how can I debug this? How can I determine if this is a
kernel problem or not?
Thanks,
--Rainer
-
To
Hi all,
Well, I upgraded my system to glibc 2.2.1 with few problems. Unfortunately,
there are no improvements in my stability problems. X still dies.
So, I ask again, how can I debug this? How can I determine if this is a
kernel problem or not?
Thanks,
--Rainer
-
To
As per Russell King's suggestion, I ran memtest86 on my system for about 12
hours last night. I found no memory errors. Note that the tests did not
complete because I had to stop them this morning. I'll contiue them tonight.
They got through test 9 of 11.
As per David Ford's suggestion, I am
Thanks for all the info, comments below:
First, I ran X in gdb and got the following via 'bt' after X died. This is
my first experience with gdb so if I should do anything in particular,
please tell me.
#0 0x401addeb in __sigsuspend (set=0xb930)
at
Thanks for all the info, comments below:
First, I ran X in gdb and got the following via 'bt' after X died. This is
my first experience with gdb so if I should do anything in particular,
please tell me.
#0 0x401addeb in __sigsuspend (set=0xb930)
at
As per Russell King's suggestion, I ran memtest86 on my system for about 12
hours last night. I found no memory errors. Note that the tests did not
complete because I had to stop them this morning. I'll contiue them tonight.
They got through test 9 of 11.
As per David Ford's suggestion, I am
On Sat, Jan 20, 2001 at 01:46:50PM +0100, [EMAIL PROTECTED] wrote:
> I know that signal 11 with gcc is a sign of bad hardware; however it
> strikes me that I don't get random oopses - a whole bunch of them is appended.
The compiler tends to hammer harder on the memory than the
Rainer Mager wrote:
> > Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> > showing exactly the same behaviour, although I can't reproduce it at will.
>
> Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
> convinced me to not upgrade glibc yet ;-)
On Mon, 22 Jan 2001, Russell King wrote:
> Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
> address 0x220068,
and X is likely to be the biggest process by far on a box, so
statistically will be the process that hits this bad byte the most.
no?
regards,
--
Paul Jakma
Rogier Wolff writes:
> Harware problems are normally not reproducable. Can you attach a
> debugger to your X server, and catch it when things go bad? (And
> give the Xfree86 people a backtrace)
Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.
Evidence: I recently
Rainer Mager wrote:
> particular problem still exists. In brief, X windows dies with signal 11. I
[snip]
Does it always happen when you are moving the mouse over a button or
windowbar or some other on-screen object like that?
Usually, when I have that happen, it's because I'm overclock
Rainer Mager wrote:
particular problem still exists. In brief, X windows dies with signal 11. I
[snip]
Does it always happen when you are moving the mouse over a button or
windowbar or some other on-screen object like that?
Usually, when I have that happen, it's because I'm overclocking
Rogier Wolff writes:
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and catch it when things go bad? (And
give the Xfree86 people a backtrace)
Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.
Evidence: I recently had
On Mon, 22 Jan 2001, Russell King wrote:
Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
address 0x220068,
and X is likely to be the biggest process by far on a box, so
statistically will be the process that hits this bad byte the most.
no?
regards,
--
Paul Jakma
On Sat, Jan 20, 2001 at 01:46:50PM +0100, [EMAIL PROTECTED] wrote:
I know that signal 11 with gcc is a sign of bad hardware; however it
strikes me that I don't get random oopses - a whole bunch of them is appended.
The compiler tends to hammer harder on the memory than the kernel
> Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
> showing exactly the same behaviour, although I can't reproduce it at will.
Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
convinced me to not upgrade glibc yet ;-)
--Rainer
-
To unsubscribe from
Rainer Mager wrote:
> that it is likely a hardware or kernel problem. So, my question is,
> how can I pin point the problem? Is this likely to be a kernel
> issue?
No, not hardware. No not kernel.
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and
On Mon, 22 Jan 2001, Rainer Mager wrote:
> I brought up this issue last month and had some response but as
> of yet my particular problem still exists. In brief, X windows dies
> with signal 11. I have done quite a bit of testing and this does not
> seem to be a hardware is
Hi all,
I brought up this issue last month and had some response but as of yet my
particular problem still exists. In brief, X windows dies with signal 11. I
have done quite a bit of testing and this does not seem to be a hardware
issue. Also, I have never managed to get a signal 11
Hi all,
I brought up this issue last month and had some response but as of yet my
particular problem still exists. In brief, X windows dies with signal 11. I
have done quite a bit of testing and this does not seem to be a hardware
issue. Also, I have never managed to get a signal 11
On Mon, 22 Jan 2001, Rainer Mager wrote:
I brought up this issue last month and had some response but as
of yet my particular problem still exists. In brief, X windows dies
with signal 11. I have done quite a bit of testing and this does not
seem to be a hardware issue. Also, I have
Rainer Mager wrote:
that it is likely a hardware or kernel problem. So, my question is,
how can I pin point the problem? Is this likely to be a kernel
issue?
No, not hardware. No not kernel.
Harware problems are normally not reproducable. Can you attach a
debugger to your X server, and
Would this be an SMP IA32 box with glibc 2.2? I have two such boxen
showing exactly the same behaviour, although I can't reproduce it at will.
Close, it is actually an SMP IA32 box with glibc 2.1.3. But you've now
convinced me to not upgrade glibc yet ;-)
--Rainer
-
To unsubscribe from this
I know that signal 11 with gcc is a sign of bad hardware; however it
strikes me that I don't get random oopses - a whole bunch of them is appended.
I used 2.4.0 with alsa, kmp3player running and an endless loop compiling the
kernel.
Mirko Kloppstech
ksymoops 2.3.7 on i686 2.4.0. Options
I know that signal 11 with gcc is a sign of bad hardware; however it
strikes me that I don't get random oopses - a whole bunch of them is appended.
I used 2.4.0 with alsa, kmp3player running and an endless loop compiling the
kernel.
Mirko Kloppstech
ksymoops 2.3.7 on i686 2.4.0. Options
I was wondering if anyone had any new info/suggestions for the Signal 11
problem.
I think I last reported that I had tried 2.4.0test12 w AGPGart and DRM
turned off. This seemed a bit more stable but I did have X crash with
Signall 11 after about 1.5 days.
I'd really appreciate any advice on how
I was wondering if anyone had any new info/suggestions for the Signal 11
problem.
I think I last reported that I had tried 2.4.0test12 w AGPGart and DRM
turned off. This seemed a bit more stable but I did have X crash with
Signall 11 after about 1.5 days.
I'd really appreciate any advice on how
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> Yes.
>
> And I realize that somebody inside RedHat really wanted to use a snapshot
> in order to get some C++ code to compile right.
>
> But it at the same time threw C stability out the window, by using a
> not-very-widely-tested snapshot for a
Date:Fri, 15 Dec 2000 01:09:29 + (GMT)
From: Alan Cox <[EMAIL PROTECTED]>
> > oWe tell vendors to build RPMv3 , glibc 2.1.x
> Curious HOW do you tell vendors??
When they ask. More usefully Dan Quinlann and most vendors put together a
recommended set of
Date:Fri, 15 Dec 2000 01:09:29 + (GMT)
From: Alan Cox [EMAIL PROTECTED]
oWe tell vendors to build RPMv3 , glibc 2.1.x
Curious HOW do you tell vendors??
When they ask. More usefully Dan Quinlann and most vendors put together a
recommended set of things to
> > o We tell vendors to build RPMv3 , glibc 2.1.x
> Curious HOW do you tell vendors??
When they ask. More usefully Dan Quinlann and most vendors put together a
recommended set of things to build with and use. It warns about library
pitfalls, kernel changes and what packaging is supported. It
Sticking my nose where it doesn't belong...
On Thu, 14 Dec 2000, Alan Cox wrote:
> > Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
> > And since redhat is _the_ distro that commercial entities use to
> > release software for, this was very arguably a bad move.
> o
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>> Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
>> And since redhat is _the_ distro that commercial entities use to
>> release software for, this was very arguably a bad move.
>
>Except you
> Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
> And since redhat is _the_ distro that commercial entities use to
> release software for, this was very arguably a bad move.
Except you conveniently ignore a few facts
o Someone else moved to 2.95 not RH . In fact
] wrote:
> On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
>
> > It's related to some change in 2.4 vs. 2.2. There are other programs
> > affected other than X, SSH also get's spurious signal 11's now and again
> > with 2.4 and glibc <= 2.1 and it does not occur on 2.2.
>
&
In article <[EMAIL PROTECTED]>,
Bernhard Rosenkraenzer <[EMAIL PROTECTED]> wrote:
>The same thing is true of *any* gcc release.
>For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x
>_and_ the upcoming 3.0 release.
Yes, but 2.96 is also binary incompatible with all non-redhat
On Thu, 14 Dec 2000, Jakub Jelinek wrote:
> On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
> > user applications and (b) gcc-2.96 is so broken that it requires special
> > libraries for C++ vtable chunks handling that is different, so the
> > _working_ gcc can only be used
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
> user applications and (b) gcc-2.96 is so broken that it requires special
> libraries for C++ vtable chunks handling that is different, so the
> _working_ gcc can only be used with programs that do not need such
> library support.
> If you ask any gcc folks, the main reason they think this was a really
> stupid thing to do was exactly that the 2.96 thing is incompatible BOTH
> with the 2.95.x release _and_ the upcoming 3.0 release.
And with egcs 1.1.2. So
egcs is a different format to all others
2.95 is a
On Thu, 14 Dec 2000, Bernhard Rosenkraenzer wrote:
> >
> > gcc-2.95.2 is at least a real release, from a branch that is actively
> > maintained
>
> Not very actively.
> Please take the time to compare the activity in gcc_2_95_branch with the
> patches in the current "2.96" version in rawhide.
On Thu, 14 Dec 2000, Linus Torvalds wrote:
> If you ask any gcc folks, the main reason they think this was a really
> stupid thing to do was exactly that the 2.96 thing is incompatible BOTH
> with the 2.95.x release _and_ the upcoming 3.0 release.
The same thing is true of *any* gcc release.
On Thu, 14 Dec 2000, Alan Cox wrote:
>
> > user applications and (b) gcc-2.96 is so broken that it requires special
> > libraries for C++ vtable chunks handling that is different, so the
>
> Wrong - the C++ vtable format change is part of the intended progression of the
> compiler and needed
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote:
> There has a been a thread on the teTeX mailing list the last few days
> about a (RedHat, but probably more general than just their rpms)
> gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
>
> unsigned varname; /* "unsigned
> I don't know why RH decided to do their idiotic gcc-2.96 release (it
> certainly wasn't approved by any technical gcc people - the gcc people
Every single patch in that release barring I believe 2 was accepted into
the main tree. So they liked the code. The naming did upset people and was
In article <[EMAIL PROTECTED]>,
Clayton Weaver <[EMAIL PROTECTED]> wrote:
>
>There has a been a thread on the teTeX mailing list the last few days
>about a (RedHat, but probably more general than just their rpms)
>gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
Quite frankly, anybody
This is unrelated to the signal 11 problem, but something to consider
for "random crashes and segfaults", ie are you using this compiler
and glibc version combination.
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general
This is unrelated to the signal 11 problem, but something to consider
for "random crashes and segfaults", ie are you using this compiler
and glibc version combination.
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general
In article [EMAIL PROTECTED],
Clayton Weaver [EMAIL PROTECTED] wrote:
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general than just their rpms)
gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
Quite frankly, anybody who uses
I don't know why RH decided to do their idiotic gcc-2.96 release (it
certainly wasn't approved by any technical gcc people - the gcc people
Every single patch in that release barring I believe 2 was accepted into
the main tree. So they liked the code. The naming did upset people and was
On Thu, 14 Dec 2000, Alan Cox wrote:
user applications and (b) gcc-2.96 is so broken that it requires special
libraries for C++ vtable chunks handling that is different, so the
Wrong - the C++ vtable format change is part of the intended progression of the
compiler and needed to meet
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote:
There has a been a thread on the teTeX mailing list the last few days
about a (RedHat, but probably more general than just their rpms)
gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile
unsigned varname; /* "unsigned int
On Thu, 14 Dec 2000, Linus Torvalds wrote:
If you ask any gcc folks, the main reason they think this was a really
stupid thing to do was exactly that the 2.96 thing is incompatible BOTH
with the 2.95.x release _and_ the upcoming 3.0 release.
The same thing is true of *any* gcc release.
For
If you ask any gcc folks, the main reason they think this was a really
stupid thing to do was exactly that the 2.96 thing is incompatible BOTH
with the 2.95.x release _and_ the upcoming 3.0 release.
And with egcs 1.1.2. So
egcs is a different format to all others
2.95 is a
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
user applications and (b) gcc-2.96 is so broken that it requires special
libraries for C++ vtable chunks handling that is different, so the
_working_ gcc can only be used with programs that do not need such
library support.
On Thu, 14 Dec 2000, Jakub Jelinek wrote:
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote:
user applications and (b) gcc-2.96 is so broken that it requires special
libraries for C++ vtable chunks handling that is different, so the
_working_ gcc can only be used with
In article [EMAIL PROTECTED],
Bernhard Rosenkraenzer [EMAIL PROTECTED] wrote:
The same thing is true of *any* gcc release.
For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x
_and_ the upcoming 3.0 release.
Yes, but 2.96 is also binary incompatible with all non-redhat
] wrote:
On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
It's related to some change in 2.4 vs. 2.2. There are other programs
affected other than X, SSH also get's spurious signal 11's now and again
with 2.4 and glibc = 2.1 and it does not occur on 2.2.
AOL
I've begun to get a bit paranoid
Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
And since redhat is _the_ distro that commercial entities use to
release software for, this was very arguably a bad move.
Except you conveniently ignore a few facts
o Someone else moved to 2.95 not RH . In fact
In article [EMAIL PROTECTED],
Alan Cox [EMAIL PROTECTED] wrote:
Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
And since redhat is _the_ distro that commercial entities use to
release software for, this was very arguably a bad move.
Except you conveniently ignore a
Sticking my nose where it doesn't belong...
On Thu, 14 Dec 2000, Alan Cox wrote:
Yes, but 2.96 is also binary incompatible with all non-redhat distro's.
And since redhat is _the_ distro that commercial entities use to
release software for, this was very arguably a bad move.
o We tell
o We tell vendors to build RPMv3 , glibc 2.1.x
Curious HOW do you tell vendors??
When they ask. More usefully Dan Quinlann and most vendors put together a
recommended set of things to build with and use. It warns about library
pitfalls, kernel changes and what packaging is supported. It is
On Wed, 13 Dec 2000, Linus Torvalds wrote:
> On Wed, 13 Dec 2000, Linus Torvalds wrote:
> >
> > Hint: "ptep_mkdirty()".
rather obvious oopsie.. once spotted.
> In case you wonder why the bug was so insidious, what this caused was two
> separate problems, both of them able to cause SIGSGV's.
On Wed, 13 Dec 2000, Linus Torvalds wrote:
> On Wed, 13 Dec 2000, Mike Galbraith wrote:
> >
> > Not in my test tree. Same fault, and same trace leading up to it. no
>
> Ok.
>
> It definitely looks like a swapoff() problem.
>
> Have you ever seen the behaviour without running swapoff?
No.
a signal 11
again and will never, ever crash ;-)
Finally, as soon as there is a patch, can other people who have seen this
problem test it. My problem is so random that I'd need at least a few days
to gain some confidence this is fixed.
Thanks all.
--Rainer
> -Original Message-
> From:
On Wed, 13 Dec 2000, Linus Torvalds wrote:
>
>
> Ehh, I think I found it.
>
> Hint: "ptep_mkdirty()".
>
> Oops.
>
> I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that
Poor European Gérard as slim as 1.84 meter - 78 Kg these days.
What about old days poor European
On Wed, Dec 13, 2000 at 11:35:57AM -0800, Linus Torvalds wrote:
>
>
> Ehh, I think I found it.
>
> Hint: "ptep_mkdirty()".
>
> Oops.
>
> I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that
> this explains it.
>
> Linus
Good. Sounds like you guys have a
On Wed, 13 Dec 2000, Linus Torvalds wrote:
>
> Hint: "ptep_mkdirty()".
In case you wonder why the bug was so insidious, what this caused was two
separate problems, both of them able to cause SIGSGV's.
One: we didn't mark the page table entry dirty like we were supposed to.
Two: by making
On Wed, 13 Dec 2000, Mike Galbraith wrote:
>
> Not in my test tree. Same fault, and same trace leading up to it. no
Ok.
It definitely looks like a swapoff() problem.
Have you ever seen the behaviour without running swapoff?
Also, can you re-create it without running swapon() (if it's
On Wed, 13 Dec 2000, Linus Torvalds wrote:
> On Wed, 13 Dec 2000, Linus Torvalds wrote:
> >
> > Lookin gat "swapoff()", it could easily be something like
> >
> > - swapoff walks theough the processes, marking the pages dirty
> >(correctly)
> > - swapoff goes on to the next swap entry,
On Wed, 13 Dec 2000, Linus Torvalds wrote:
>
> Lookin gat "swapoff()", it could easily be something like
>
> - swapoff walks theough the processes, marking the pages dirty
>(correctly)
> - swapoff goes on to the next swap entry, and because it needs memory for
>this, the VM layer
wing app. If I run my
> >> script from an xterm (or gnome-terminal or whatever) then it starts up fine.
> >> If, however, I try to launch it from my gnome taskbar's menu then it dies
> >> with signal 11 (the Java log is available upon request). This seems to be
> >&g
On Wed, 13 Dec 2000, Rainer Mager wrote:
> Mike et al,
>
> I have no idea what IKD is and I don't know what to do with any results I
> might find BUT I'd be happy to do this if it will help. Please pass on the
> info with the instructions. Who should I report the results to?
IKD is a
>> From: CMA [mailto:[EMAIL PROTECTED]]
>> Did you already try to selectively disable L1 and L2 caches (if
>> your box has both) and see what happens?
>
>Anyone know how to do this?
If you own a p6 class machine (sorry but I didn't find your hw specs in
previous messages)
you should be able to
Mike et al,
I have no idea what IKD is and I don't know what to do with any results I
might find BUT I'd be happy to do this if it will help. Please pass on the
info with the instructions. Who should I report the results to?
--Rainer
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
Give that man a cigarit was an env var (not LOCALE but LANG). I'd
actually checked this but I didn't think that made a difference in my case.
Thanks Linus, now can you fix the larger signal 11 problem?
--Rainer
> [mailto:[EMAIL PROTECTED]]On Behalf Of Linus Torvalds
> I'd
Mike et al,
I have no idea what IKD is and I don't know what to do with any results I
might find BUT I'd be happy to do this if it will help. Please pass on the
info with the instructions. Who should I report the results to?
--Rainer
[mailto:[EMAIL PROTECTED]]On Behalf Of Mike
1 - 100 of 194 matches
Mail list logo
