Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: glibc update problem
Date: Wed, 01 Mar 2006 17:08:33 -0700
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 
>> 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@g.o mailing list


References:
glibc update problem
-- Rupert Young (Restart)
Re: glibc update problem
-- Simon Strandman
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: glibc update problem
Next by thread:
mplayer sync issues
Previous by date:
Re: full write access to ntfs
Next by date:
jabberd server


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.