1.2.13 __generic_memcpy_tofs cures crashes

Steven L. Baur (steve@miranova.com)
08 Apr 1996 21:38:02 -0700

>>>>> "Linus" == Linus Torvalds <torvalds@cs.helsinki.fi> writes:

Linus> No, cr2 is the faulting virtual address, so that's not it. I
Linus> agree that the weird behaviour could potentially be from
Linus> something else than a buggy CPU, but considering that the
Linus> machine in question has been showing symptoms that others don't
Linus> see for the whole 1.3.x series, I'm now strongly suspecting
Linus> hardware (I'm always suspicious of hardware, but I want to make
Linus> sure a linux bug can't possibly be the more likely cause
Linus> _first_)

Linus> Does soembody else with Cyrix CPU's see strange behaviour like this?

In an earlier message you suggested replacing __generic_memcpy_tofs
with the version from 1.2.13 and it worked. By the time this message
makes it off this machine, I will have had 24 hours of continuous
error free (as reported in syslog) operation on my problem machine.
It passed its previous 1.3 record over twelve hours ago. (Considering
how much useless legacy code is already in the kernel (xia fs, ext fs,
etc.), it would be nice to also include the slower memcpy routines as
a special option for people with braindamaged hardware.)

Adding that to the accumulated 16 days of error free uptime on the
other four boxes I had 1.3.84 running on (they've been running 1.3.85
all day today, also without error), and I'm already rethinking my
opinion about the relative stability of 1.3 kernels.

Just to be sure that it is indeed the Cyrix chip, I'm going to have it
replaced tomorrow.

$ uptime
9:35pm up 1 day, 0 min, 9 users, load average: 0.10, 0.08, 0.23
$ hostname


steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.