From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FEbOo-0004SZ-Md for garchives@archives.gentoo.org; Thu, 02 Mar 2006 00:10:31 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k2208qPk030155; Thu, 2 Mar 2006 00:08:52 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k2208p8B020271 for ; Thu, 2 Mar 2006 00:08:52 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FEbN7-00039J-JZ for gentoo-amd64@lists.gentoo.org; Thu, 02 Mar 2006 01:08:45 +0100 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Mar 2006 01:08:45 +0100 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Mar 2006 01:08:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: glibc update problem Date: Wed, 01 Mar 2006 17:08:33 -0700 Organization: Organization? Me? Message-ID: References: <20060228225750.7564725213F@smtp.nildram.co.uk> <4405E164.90501@telia.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 87175b99-ce6d-49d3-94fb-588666fb89f0 X-Archives-Hash: 5779d5b540c72d10ee3c389eecf48f59 Simon Strandman posted <4405E164.90501@telia.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 http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list