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 of the best memory testers known to man -- much
better than most other programs. A big reason for that is that it
accesses lots of memory in funny patterns, *AND* accesses to it are
likely to be fatal.
It is just the way it is. gcc doing the signal 11 is HIGHLY
correlated with the hardware you are running on, which means it's
*usually* hardware-related.
> [... Lots of M$ flames ignored ...]
> 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 was upgrading
> the kernel every time there was a new kernel and from 2.2.12(or 14)
> no more signal 11 (very rare) Is this still a hardware problem ?
> Was a bug in kernel ?
>
> I think the last answer is more obvious.(or the gcc
> had a bug and the kernel -- a workaround).
Most likely is that your *hardware* had a bug and the new kernel a
workaround (this is quite common), but without more detail it is very
hard to know.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Hi HPA.
>> 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 was
>> upgrading the kernel every time there was a new kernel and from
>> 2.2.12(or 14) no more signal 11 (very rare) Is this still a
>> hardware problem ? Was a bug in kernel ?
>> I think the last answer is more obvious.(or the gcc had a bug
>> and the kernel -- a workaround).
> Most likely is that your *hardware* had a bug and the new kernel
> a workaround (this is quite common), but without more detail it
> is very hard to know.
Wasn't 2.2.12 the kernel that included the `lock halt` bug patch?
Best wishes from Riley.
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
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 registers` patch for the Intel processors,
and I noted that the processor in question was a Cyrix one, hence the
comment.
Best wishes from Riley.
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 registers` patch for the Intel processors,
> and I noted that the processor in question was a Cyrix one, hence the
> comment.
>
Oh. Sorry, I don't know about "lock halt" and its effects. However, if
it refers to the instruction sequence LOCK HLT I find it hard to believe
it would have the symptoms described.
-hpa
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 registers` patch for the
>> Intel processors, and I noted that the processor in question was
>> a Cyrix one, hence the comment.
> Oh. Sorry, I don't know about "lock halt" and its effects.
> However, if it refers to the instruction sequence LOCK HLT I
> find it hard to believe it would have the symptoms described.
I don't have the paperwork to hand, and my memory isn't brilliant, but
the bug was something along the lines of Cyrix processors trashing the
SP if the instruction preceding (or following, I'm not sure which) a
HLT opcode was locked, and the patch was to remove some instances in
the kernel source where that occurred.
It's quite possibly unrelated, but...
Best wishes from Riley.