Simon Strandman posted <4405E164.90501@...>, excerpted below, on
Wed, 01 Mar 2006 19:01:08 +0100:
Robbert Young wrote...
>> USE="x86 3dnow X acpi alsa apache2 audiofile avi bitmap-fonts bzip2
>> crypt cups dga eds emboss encode exif expat fam fbcon foomaticdb
>> fortran gd gdbm gif glut gpm gstreamer gtk gtk2 imagemagick imlib ipv6
>> java jikes jpeg junit lcms libg++ libwww mad mailwrapper mhash mikmod
>> mmx mng mozilla mp3 mpeg mysql ncurses nptl ogg oggvorbis opengl pam
>> pcre pdflib png python quicktime readline samba sdl slang spell sse
>> ssl tcpd tetex tiff truetype truetype-fonts type1-fonts udev
>> userlocales vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux
> 1. Check you RAM with memtest86+.
Excellent advice, but it won't catch all errors, particularly bus errors
that happen only under stress. I know, as I have just such a problem
here. After a BIOS came out that had memory speed tweaking, I reduced the
speed from the rated 200 (ddr to 400=pc3200) to 183 (ddr to 366, pc3000)
and it's now rock-stable, as Linux /should/ be.
Of course, an insufficient power supply is the next candidate in the
hardware failure realm.
> 2. Drop your CFLAGS to "-march=opteron -O2 -pipe". Extreme CFLAGS wont
> improve your performance anyway and I'm a bit suprised you're using such
> CFLAGS on a server.
Well, it /is/ glibc we are talking, and if you check the glibc ebuild, it
strips virtually all flags /other/ than the above "-march=opteron -O2
-pipe". Thus, in this particular case, unless the ebuild itself has been
hacked to kill that strip, I don't believe this is the problem.
On most ebuilds it could be. You are absolutely right on that, as most
don't stripflags to such a small subset. Also see below.
> 3. You aren't supposed to use a x86 profile on a x86_64-pc-linux-gnu
> system. Change to an amd64 profile instead.
If the issue isn't purely hardware, I'd lay money on this. glibc in
particular is not something one wants to be compiling toward the wrong
arch. It could very easily be a section of 32-bit hand-tuned assembly,
that the compiler is trying to unite with a 64-bit overall glibc. That
*WILL* produce problems.
In addition, flags like 3dnow and mmx (just tried to write xmms =8^) are
masked on amd64, because they tend to invoke 32-bit only assembly code.
amd64 has those by default, so no need for those USE flags. As I
mentioned, however, it's not likely that such is the problem with glibc,
given its stripflags. That's anyway on amd64. It's possible they still
get thru on the bastardized amd64 system but x86 profile we see here.
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 in
firstname.lastname@example.org mailing list