[gentoo-amd64] Re: Initial install issues

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
200605162027.21948.volker.armin.hemmann@××××××××××××.de, excerpted below,
on  Tue, 16 May 2006 20:27:21 +0200:

> So I bet it is a) the ram b) overheating of the CPU or c) your PSU.
> In that order.
>
> bzip2 needs a lot of CPU power, so overheating could be the reason.
> Overheating or undervolting, as soon as it has an increased load.

I'll second that.  I've experienced bunzip2 issues before due both to
over-clocking and to memory issues.  Most recently due to memory issues,
due to some generic memory I had.

bzip2 is high compression, which stresses the CPU.  It can also stress
memory with larger tarballs.  One characteristic of good compression is
that the compressed form appears random -- no duplication or pattern
visible, or further compression is possible.  In such a situation,
transmission or storage errors become possible and the reliability of the
data is thus suspect.  To account for and counteract this, bzip2 performs
a pretty intensive integrity check.  If your computer has unreliable
parts, memory, CPU, etc, bunzip2 is very often the canary in the coal mine
in terms of spotting them, due in part to this intensive integrity check
and its sensitivity to memory or CPU errors.

Despite the fact that you don't provide the specific errors, which could
have been quite useful, I'd lay money on the problem being unreliable
hardware, either CPU or memory.  If it's possible with your motherboard,
declock one or both a notch or two.  Here, the memory error I had at the
rated PC3200 (DDR-400) entirely disappeared when an upgraded BIOS gave me
the ability to declock the generic memory from 200 (doubled to 400) MHz to
183 (doubled to 366) MHz, from PC3200 to PC3000 equivalent.  At the lower
speed, the system was rock stable.  

Likewise in an earlier generation, when I was overclocking my (then
Athlon-C) CPU from 1.2 to 1.33 GHz.  For about a year and a half, I ran
Distributed.net, thus 100% CPU on the overclocked.  It ran fine, but it
DID shorten the life of my CPU, such that at about 18 months in, I started
getting various errors and ended up declocking back to 1.2 GHz.  Even
there, however, I had to keep the increased voltage, as the system was no
longer stable without it, and even with the increased voltage, still
wasn't absolutely stable.  It was while I was on that system that MS put
out eXPrivacy, and after waiting literally years for an NT based full
32-bit system, I realized I couldn't accept the privacy and other
compromises that MS was demanding.  As a result, there was simply no way I
could legally run eXPrivacy, because I couldn't agree to the EULA or the
authentication scheme.  Fortunately, I had been scoping out Linux for some
time and ensuring all the hardware I purchased was Linux compatible, so I
upgraded to Linux rather than go illegal with MSWormOS eXPrivacy.  I've
never looked back, but one thing I DID find out right away was that the
system wasn't stable enough (due to my previous overclocking) to reliably
do certain things (including using bunxip2).  Fortunately, I had chosen
Mandrake, a binary distribution, so it wasn't as bad as it would have been
on Gentoo, but I got used to having to redo things like bunzip2 calls 2 or
3 times to get them to work properly.

I switched to AMD64 (and to the previously mentioned problem with generic
memory) before I switched to Gentoo.  Fortunately, the problem with the
memory wasn't as bad as yours seems to be, but I still had to babysit
emerges, and do some of them several times over to finish them
successfully, until that BIOS upgrade gave me the ability to declock the
memory just that one notch, and one notch made all the difference!

So...  Try declocking your system, either memory or CPU.  Something's not
running stable.  If you can't or doing so doesn't help on amd64, chances
are you'll have difficulty with x86 Gentoo on that computer as well,
unless you can do the compiles on other x86 computers and just do the
binary package thing on that one.  Even then, if it won't do bunzip2,
since the binary package thing uses bzip2 packages, you might be out of
luck.  If you can't declock something, you are most likely looking at
either a memory replace or a CPU replace to get reasonable stability. 
Unfortunately... but that's dealing with real life, and I have the
real life experiences demonstrating the fact.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list