[lkml]   [1996]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 1.3.95 is not stable
>>>>> "Linus" == Linus Torvalds <> writes:

Linus> On 25 Apr 1996, Steven L Baur wrote:
>> Here are 3 crash traces from syslog. The symptoms were all
>> similar in that init died each time making shutdown problematic.
>> I've downgraded to .93 out of self-defense. Presumably the
>> constant network crashes are going to get fixed before 2.0, right?

Linus> The strange thing is that the 94/95 patches didn't really
Linus> change much of the kernel: they contain mostly m68k stuff and
Linus> spelling fixes.

Linus> The crash you see is due to memory corruption in the kernel
Linus> (the function "handle_signal()" to be exact): the code sequence
Linus> _should_ be

Linus> addl $0x10,%esp cmpl $0x0,0x8(%ebx) jnl <handle_signal+106>

Linus> which is "0x83 0xc4 0x10 0x83 0x7b 0x08 0x00 0x7d 0x06". Your
Linus> panic reports "0x83 0x84 0x10 0x83 0x7b 0x08 0x00 0x7d 0x06".

Linus> Note the _one_bit_ error in the second byte... (0xc4 has become
Linus> a 0x84).

Linus> Now, one-bit errors might be due to flaky memory, and the
Linus> reason you see the problems with some kernels and not others
Linus> _may_ be because the small differences in the kernels move the
Linus> code around a bit, and then the errors show up in different
Linus> places (or fail to show up at all).

Linus> The error may well be due to a bogus kernel pointer being used
Linus> for bitmap operations too, of course. That's the more likely
Linus> explanation (bogus pointers _usually_ result in byte or word
Linus> corruption rather than just a single bit error, but this can be
Linus> unlucky).

I don't know if this might be related, but I have received a report,
from Andreas Schwab, about something similar for the m68k port.

Andreas told me that he experiences a bug randomly changing bits in
user pages. I haven't noticed this myself though and I'm afraid we got
no cure for it ;(.


 \ /
  Last update: 2005-03-22 13:37    [W:0.061 / U:1.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site