Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: glibc update problem
Date: Thu, 02 Mar 2006 00:10:31
In Reply to: Re: [gentoo-amd64] glibc update problem by Simon Strandman
Simon Strandman posted <4405E164.90501@×××××.com>, 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 >> elibc_glibc" >> > 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 -- gentoo-amd64@g.o mailing list