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 maj
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 thing
> > 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 i
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 W
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
> 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 s
I had tons of problems with K6III/450s in ASUS P5A motherboards with
various kinds of 128MB SIMMs. There were multiple different symptoms,
including just sig11s on compiles, corrupted input (leading to syntax
error) in compiles, and corrupted input in the buffer cache (same crash
over and over,
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 d
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
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.
E
> 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.
For
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 t
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
> 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
unfor
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
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 than just their
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.
>
---
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Linus Torvalds
> Sent: Thursday, December 14, 2000 5:19 AM
> To: Mike Galbraith
> Cc: Kernel Mailing List
> Subject: Re: Signal 11 - the continuing saga
>
>
> On Wed, 13 Dec 2000, Linus Torvalds wrote
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 L
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 it
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
P
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 somet
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, and
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 wil
On Tue, Dec 12, 2000 at 07:17:41PM -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
> >On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
> >>I have a tiny bash script that launches a Java swing app. If I run my
> >> script f
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 debu
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 Galbr
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 guess that the pro
On Wed, 13 Dec 2000, Rainer Mager wrote:
> Thanks for the info...
>
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff V. Merkey
> > > So, is this related to the larger signal 11 problems?
> >
> > There's a corruption bug in the page cache somewhere, and it's 100%
> > reproducable. Finding it wi
In article <[EMAIL PROTECTED]>,
Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
>On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
>> I have a tiny bash script that launches a Java swing app. If I run my
>> script from an xterm (or gnome-terminal or whatever) then it starts up fine.
>>
Thanks for the info...
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff V. Merkey
> > So, is this related to the larger signal 11 problems?
>
> There's a corruption bug in the page cache somewhere, and it's 100%
> reproducable. Finding it will be tough
Ok, granted this will be tough but is
On Wed, Dec 13, 2000 at 09:22:55AM +0900, Rainer Mager wrote:
> Hi again,
>
> Ok, I just upgraded to 2.4.0test12 (although I don't think there was any
> work in 12 that directly addresses this signal 11 problem). When compiling
> the new kernel I chose to disable AGPGart and RDM as suggeste
Hi again,
Ok, I just upgraded to 2.4.0test12 (although I don't think there was any
work in 12 that directly addresses this signal 11 problem). When compiling
the new kernel I chose to disable AGPGart and RDM as suggested by
[EMAIL PROTECTED] I will report later if this makes any differenc
(This message contains a number of related replies.)
> From: Mike Galbraith [mailto:[EMAIL PROTECTED]]
> Is init permanently running after you see a couple of these?
No, that is, after 23 hours up time it has used only 6 seconds CPU time
(according to top).
That reminds me that I should repeat
On Mon, 11 Dec 2000, Rainer Mager wrote:
> Well, I just had a Signal 11 even with the patch. What can I do to help
> figure this out?
My troublesome box finally seems to be stable. It's been up for the
last two days whilst under quite heavy loads without problems.
Previously, it would be lucky t
On Mon, 11 Dec 2000, Rainer Mager wrote:
> Well, I just had a Signal 11 even with the patch. What can I do to help
> figure this out?
Is init permanently running after you see a couple of these?
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Vojkovich
Subject: Re: Signal 11
> > wrong with it. I've only seen this under 2.3.x/2.4 SMP kernels. I
> > would say that this is definitely a kernel problem.=20
>
> XFree86 3.9 and XFree86 4 were rock solid for a _long_ time on 2.[34]
> kernels - even on my BP6=B9. The
: David Woodhouse
Cc: Andi Kleen; Rainer Mager; [EMAIL PROTECTED]; Mark Vojkovich
Subject: Re: Signal 11
> > wrong with it. I've only seen this under 2.3.x/2.4 SMP kernels. I
> > would say that this is definitely a kernel problem.=20
>
> XFree86 3.9 and XFree86 4 were rock
[EMAIL PROTECTED] wrote:
>
> On Sat, 9 Dec 2000, Matthew Vanecek wrote:
>
> > > Have any of the folks seeing it checked if Ben LaHaise's fixes for the page
> > > table updating race help ?
> > > Alan
> >
> > Where are his fixes at? I don't seem to see any of his posts in the
> > archives.
>
>
On Sat, 9 Dec 2000, Matthew Vanecek wrote:
> > Have any of the folks seeing it checked if Ben LaHaise's fixes for the page
> > table updating race help ?
> > Alan
>
> Where are his fixes at? I don't seem to see any of his posts in the
> archives.
dwmw2 posted one such patch earlier this week :
Alan Cox wrote:
>
> > > wrong with it. I've only seen this under 2.3.x/2.4 SMP kernels. I
> > > would say that this is definitely a kernel problem.=20
> >
> > XFree86 3.9 and XFree86 4 were rock solid for a _long_ time on 2.[34]
> > kernels - even on my BP6=B9. The random crashes started to hap
David Woodhouse ([EMAIL PROTECTED]) wrote...
> Can you reproduce it with bcrl's patch below:
Did nothing for me. gcc still got a sig11 after a while.
Took three runs of 'make bzImage' before it completed.
I wondered if I'd been unlucky enough to have been sent a
replacement K6-2 which was als
I'll try.
Jeff
On Fri, Dec 08, 2000 at 10:24:55PM +, David Woodhouse wrote:
> On Fri, 8 Dec 2000, Jeff V. Merkey wrote:
>
> > I have not seen it on UP systems either. I only see it on SMP systems.
> > After trying very hard last night, I was able to get my 4 x PPro system to
> > do it w
David Woodhouse <[EMAIL PROTECTED]> said:
[...]
> I quote from the X devel list, which perhaps I shouldn't do but this is
> hardly NDA'd stuff:
> On Mon 20 Nov 2000, [EMAIL PROTECTED] said:
> > I have seen random crashes on dual P3 BX boards (Tyan) and dual Xeon
> > GX boards (Intel). XFree8
On Fri, Dec 08, 2000 at 11:34:51AM -0800, Mark Vojkovich wrote:
>
>
> On Fri, 8 Dec 2000, David Woodhouse wrote:
>
>Some additional data points. It goes away on UP 2.4 kernels.
> Also, I can't recall seeing this problem on IA64. Maybe it's still
> there on IA64 and I just haven't been try
On Fri, 8 Dec 2000, Jeff V. Merkey wrote:
> I have not seen it on UP systems either. I only see it on SMP systems.
> After trying very hard last night, I was able to get my 4 x PPro system to
> do it with 2.4.0-12. It seems related to loading in some way. If you
> have more than two processors
On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote:
> On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
>
> > I think there may be a case when a process forks, that the MMU or some
> > other subsystem is either not setting the page bits correctly, or
> > mapping in a bad page. It's a LEVEL I bug in 2.4 is this
On Thu, 7 Dec 2000, Peter Samuelson wrote:
>
> [Dick Johnson]
> > Do:
> >
> > char main[]={0xff,0xff,0xff,0xff};
>
> Oh come on, at least pick an *interesting* invalid opcode:
>
> char main[]={0xf0,0x0f,0xc0,0xc8}; /* try also on NT (: */
What's funny, is that this actually executes on SP
On Fri, 8 Dec 2000, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Sounds like a X Server bug. You should probably contact XFree86, not
> > linux-kernel
>
> I quote from the X devel list, which perhaps I shouldn't do but this is hardly
> NDA'd stuff:
>
> On Mon 20 Nov 2000, [EMAIL PROT
Don't post the core file... It's system-dependant and really wont do
anyone but yourself a shred of good.
On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
>
>
> Andi Kleen wrote:
> >
> > On Thu, Dec 07, 2000 at 06:24:34PM -0700, Jeff V. Merkey wrote:
> > >
> > > Andi,
> > >
> > > It's related to som
[Dick Johnson]
> > > char main[]={0xf0,0x0f,0xc0,0xc8};/* try also on NT (: */
> > me2v@reliant DRFDecoder $ ./op
> > Illegal instruction (core dumped)
>
> Yep. And on early Pentinums, the ones with the "f00f" bug, it would
> lock the machine tighter than a witches crotch. Ooops, not
> pol
On Fri, 8 Dec 2000, Matthew Vanecek wrote:
> Peter Samuelson wrote:
> >
> > [Dick Johnson]
> > > Do:
> > >
> > > char main[]={0xff,0xff,0xff,0xff};
> >
> > Oh come on, at least pick an *interesting* invalid opcode:
> >
> > char main[]={0xf0,0x0f,0xc0,0xc8};/* try also on NT (: */
> >
>
[EMAIL PROTECTED] wrote:
>
> On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
>
> > I think there may be a case when a process forks, that the MMU or some
> > other subsystem is either not setting the page bits correctly, or
> > mapping in a bad page. It's a LEVEL I bug in 2.4 is this is the case,
> >
Peter Samuelson wrote:
>
> [Dick Johnson]
> > Do:
> >
> > char main[]={0xff,0xff,0xff,0xff};
>
> Oh come on, at least pick an *interesting* invalid opcode:
>
> char main[]={0xf0,0x0f,0xc0,0xc8};/* try also on NT (: */
>
me2v@reliant DRFDecoder $ ./op
Illegal instruction (core dumped)
I
> > wrong with it. I've only seen this under 2.3.x/2.4 SMP kernels. I
> > would say that this is definitely a kernel problem.=20
>
> XFree86 3.9 and XFree86 4 were rock solid for a _long_ time on 2.[34]
> kernels - even on my BP6=B9. The random crashes started to happen when =
> I
> upgraded my
> Various processes have been getting random signals after heavy CPU usage.
> Playing an MPEG movie, kernel compile, or even just some small apps
> compiling sometimes. Just for the record, this isn't an OOM situation,
> I've watched this box with half its memory free or in buffers left
> unattend
[EMAIL PROTECTED] said:
> Sounds like a X Server bug. You should probably contact XFree86, not
> linux-kernel
I quote from the X devel list, which perhaps I shouldn't do but this is hardly
NDA'd stuff:
On Mon 20 Nov 2000, [EMAIL PROTECTED] said:
> I have seen random crashes on dual P3 BX bo
"Jeff V. Merkey" wrote:
>
> > So have you enabled core dumps and actually looked at the core dumps
> > of the programs using gdb to see where they crashed ?
>
> Yes. I can only get the SSH crash when I am running remotely from the
> house over the internet, and it only shows then when running
On Thu, 7 Dec 2000, Jeff V. Merkey wrote:
> I think there may be a case when a process forks, that the MMU or some
> other subsystem is either not setting the page bits correctly, or
> mapping in a bad page. It's a LEVEL I bug in 2.4 is this is the case,
> BTW. In core dumps (I've looked at 2 o
Dave,
I think there may be a case when a process forks, that the MMU or some
other subsystem is either not setting the page bits correctly, or
mapping in a bad page. It's a LEVEL I bug in 2.4 is this is the case,
BTW. In core dumps (I've looked at 2 of them from SSH) it barfs right
after execu
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.
I've begun to get a bit paranoid about my K6-2
Hi all,
Thanks for all the input so far. Regarding this...
> (I'm not sure exactly what cerberos does, do you have a link for it ?).
The official name is "Cerberus Test Control System" aka CTCS. I don't know
the official site but a search for this should reveal something. Anyway it
is a
[Dick Johnson]
> Do:
>
> char main[]={0xff,0xff,0xff,0xff};
Oh come on, at least pick an *interesting* invalid opcode:
char main[]={0xf0,0x0f,0xc0,0xc8};/* try also on NT (: */
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [E
On Fri, 8 Dec 2000, Rainer Mager wrote:
> Hi all,
>
> I've searched around for a answer to this with no real luck yet. If anyone
> has some ideas I'd be very grateful.
Signal 11 just means that you "seg-faulted". This is usually caused
by a coding error. However, if you have tools (like t
Andi Kleen wrote:
>
> On Thu, Dec 07, 2000 at 06:24:34PM -0700, Jeff V. Merkey wrote:
> >
> > Andi,
> >
> > 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 doe
On Thu, Dec 07, 2000 at 06:24:34PM -0700, Jeff V. Merkey wrote:
>
> Andi,
>
> 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.
So have you en
Andi,
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.
Jeff
Andi Kleen wrote:
>
> On Fri, Dec 08, 2000 at 09:44:29AM +0900, Rainer Mager wrote:
On Fri, Dec 08, 2000 at 09:44:29AM +0900, Rainer Mager wrote:
> I recently upgraded to a new machine. It is running RedHat 6.2 Linux (with
> a SMP 2.4.0test[8-11] kernel) and has a Matrox G400 in it. X is 4.0.1.
> Anyway, about once every 2-3 days X will spontaneously die and the only info
>
On Fri, Dec 08, 2000 at 09:44:29AM +0900, Rainer Mager wrote:
> I've heard that signal 11 can be related to bad hardware, most
> often memory, but I've done a good bit of testing on this and the
> system seems ok. What I did was to run the VA Linux Cerberos(sp?)
> test for 15 hours+ with n
I have previously reported this error (about three months ago) on 2.4
with XFree 3.3.6. If you are running RedHat 6.2, then you are running
this X Server. It also shows up on Calders'a 2.4 eDesktop. It appears
to be something with glib 2.1 < versions on 2.4. I also see it with
secure shell 1.
74 matches
Mail list logo
