Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter <adamcarter3@gmail.com> wrote:
>> #expanded form of -march=native. Nothing special here. Noting this
>> here because people keep freaking out when they see it in-line.
>> SYS_CFLAGS_MARCH_NATIVE_EXP="-march=amdfam10 -mcx16 -msahf -mpopcnt
>> --param l1-cache-size=64 --param l1-cache-line-size=64 --param
>> l2-cache-size=512 -mtune=amdfam10"
>> CFLAGS="${SYS_CFLAGS_MARCH_NATIVE_EXP} -O2 -pipe -ggdb3"
>> CXXFLAGS="${CFLAGS}"
>> FEATURES="splitdebug"
>> MAKEOPTS="--jobs --load=5"
>> EMERGE_DEFAULT_OPTS="--jobs --load-average=6 --verbose --tree
>> --with-bdeps=y --keep-going"
>
> FYI Michael, i'm not too dissimilar, and no apparent problems with
> glibc-2.14.1-r3. Mostly stable, kernel from gentoo-sources 3.3.2.
Lost my SSH session to inara (inara and kaylee are the two systems
that are borked by the upgrade, saffron is the one system I have which
upgraded without problem) when saffron hung coming out of screensaver.
I can no longer ssh into either inara or kaylee. And I won't have time
to work with either until Sunday at the earliest.
This has not been a good week.
--
:wq
04-27-2012, 09:20 AM
Willie WY Wong
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Thu, Apr 26, 2012 at 10:38:21AM -0400, Penguin Lover Doug Hunley squawked:
> On Thu, Apr 26, 2012 at 04:47, Helmut Jarausch
> <jarausch@igpm.rwth-aachen.de> wrote:
> > I am at glibc-2.15-r1 on AMD64 with no problems so far,
>
> ditto here
>
Hey guys, I think we've pretty much established that Michael is
running into an isolated problem or some strange edge case.
Rubbing it in further really won't help, as he is quite clearly
having an issue with two (or three) of his boxes despite y'all's
success on yours. So can we please stop with the "works for me"
e-mails?
At the very least, if you were to post one such, please make it
possibly useful for Michael by including your build options and such.
Regards,
W
04-27-2012, 04:23 PM
"Mike Edenfield"
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
From: Michael Mol [mailto:mikemol@gmail.com]
Sent: Thursday, April 26, 2012 9:54 PM
> I can no longer ssh into either inara or kaylee.
Clearly they are busy fsck'ing /malcom and /simon
04-28-2012, 07:10 AM
Pandu Poluan
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Apr 27, 2012 8:58 AM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Thu, Apr 26, 2012 at 8:35 PM, Adam Carter <adamcarter3@gmail.com> wrote:
> >> #expanded form of -march=native. Nothing special here. Noting this
> >> here because people keep freaking out when they see it in-line.
> I don't think I have one on kaylee. If I have one on inara, it'd be >= system RAM, so at least 4G.
Are you sure?
I remember having a lot of grief trying to graphite-ize glibc without a swapfile. Now, every time I see glibc in the list of "things to emerge", I swapon /.swapfile (and swapoff that file after emerge us complete).
If you're using distcc, perhaps you need to turn on swapfile temporarily on all participating hosts.
Rgds,
04-28-2012, 03:07 PM
Michael Mol
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
Kaylee has 10GB of RAM...if that's not enough, I'll be disabling graphite. (Though I haven't explicitly enabled it, either.)
But, no I'm not sure, and can't check until Sunday eveningish. Currently at Penguicon.
On Apr 28, 2012 5:32 AM, "Pandu Poluan" <pandu@poluan.info> wrote:
On Apr 28, 2012 3:32 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> I don't think I have one on kaylee. If I have one on inara, it'd be >= system RAM, so at least 4G.
Are you sure?
I remember having a lot of grief trying to graphite-ize glibc without a swapfile. Now, every time I see glibc in the list of "things to emerge", I swapon /.swapfile (and swapoff that file after emerge us complete).
If you're using distcc, perhaps you need to turn on swapfile temporarily on all participating hosts.
Rgds,
06-23-2012, 04:37 AM
Michael Mol
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
> <dgoncharov@users.sf.net> wrote:
>> On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>>> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> Wow. Just wow. This is incredible.
>>>
>>> This is repeatable for me.
>>>
>> <snip>
>>> ** The problem occurred while executing the ebuild file named
>>> ** 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>>>
>> <snip>
>>> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>>> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>>> l2-cache-size=4096 -mtune=core2 -ggdb3"
>>> CXXFLAGS="${CFLAGS}"
>>
>> Can you upgrage to glibc-2.15?
>
> Sure. It's going to be another full reinstall.
Forgot to try this. Will do tomorrow.
>
>> Can you tweak you gcc flags to something more conventional and see if the
>> problem persists?
>
> Those CFLAGS should be equivalent to:
> CFLAGS="-O2 -pipe -ggdb3 --march=native".
>
> But I'll try making it just -O2 -pipe --march=native.
Just an update: Tried CFLAGS="-O2 -pipe --march=native -ggdb3". Same results.
>
>> If you are interested in submitting a patch to the upstream then you can build
>> the glibc test suite with your gcc flags and check if the tests pass.
I do still have a working gentoo laptop I could try this on...but it
has an i3 proc, as opposed to the core 2 xeon or the phenom 9650. Have
a link to instructions?
--
:wq
06-23-2012, 10:08 PM
Michael Mol
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 23, 2012 at 12:37 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Sat, Jun 2, 2012 at 11:56 PM, Michael Mol <mikemol@gmail.com> wrote:
>> On Sat, Jun 2, 2012 at 11:34 PM, Dmitry Goncharov
>> <dgoncharov@users.sf.net> wrote:
>>> On Sat, Jun 02, 2012 at 10:52:12PM -0400, Michael Mol wrote:
>>>> On Sat, Apr 28, 2012 at 11:07 AM, Michael Mol <mikemol@gmail.com> wrote:
>>>> Wow. Just wow. This is incredible.
>>>>
>>>> This is repeatable for me.
>>>>
>>> <snip>
>>>> ** The problem occurred while executing the ebuild file named
>>>> ** 'glibc-2.14.1-r3.ebuild' located in the '/var/db/pkg/sys-
>>>>
>>> <snip>
>>>> CFLAGS="-O2 -pipe -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf
>>>> --param l1-cache-size=32 --param l1-cache-line-size=64 --param
>>>> l2-cache-size=4096 -mtune=core2 -ggdb3"
>>>> CXXFLAGS="${CFLAGS}"
>>>
>>> Can you upgrage to glibc-2.15?
>>
>> Sure. It's going to be another full reinstall.
>
> Forgot to try this. Will do tomorrow.
>
>>
>>> Can you tweak you gcc flags to something more conventional and see if the
>>> problem persists?
>>
>> Those CFLAGS should be equivalent to:
>> CFLAGS="-O2 -pipe -ggdb3 --march=native".
>>
>> But I'll try making it just -O2 -pipe --march=native.
>
> Just an update: Tried CFLAGS="-O2 -pipe --march=native -ggdb3". Same results.
>
>>
>>> If you are interested in submitting a patch to the upstream then you can build
>>> the glibc test suite with your gcc flags and check if the tests pass.
>
> I do still have a working gentoo laptop I could try this on...but it
> has an i3 proc, as opposed to the core 2 xeon or the phenom 9650. Have
> a link to instructions?
For anyone following or interested, this is now reported as bug
#423149. I'll be tracking progress there, so I have a common place to
keep notes and discoveries as I try to work it out.
https://bugs.gentoo.org/show_bug.cgi?id=423149
--
:wq
06-27-2012, 01:58 PM
Michael Mol
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
On Sat, Jun 23, 2012 at 6:08 PM, Michael Mol <mikemol@gmail.com> wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=423149
As it turned out, it was my CFLAGS. Not the ones anyone usually cares
about, either.
If you build glibc with CFLAGS="${CFLAGS} -g3", your glibc will be
very, very broken. Apparently, it's old, known and has been a problem
for about five years.[1]
Which means that when I changed my CFLAGS from "-ggdb" to "-ggdb3" a
few months ago, the next time I emerged glibc was going to be the time
that killed my system. I didn't think twice about it at the time,
either; When trying to debug something, how often does it turn out to
be the debugging *data* that's causing the problem? I'm accustomed to
systems behaving differently with debuggers attached, but this
was...bizarre.
The other big thing I kept hearing about was "try changing
{this|that|other thing}; it might be affecting glibc, because glibc is
a whiny b*tch". Are there alternatives to glibc?
Meanwhile, while trying to accelerate the tweak/retry cycle of testing
this, I wrote a script which automatically installs, configures,
updates and builds Gentoo. I'll share it on github soon enough; it's
got a bunch of pieces which are particular to my use case. Just a
couple more changes before it generates a clean, configured system
(for me). Once I've got a stable, working box at home, I'll be able to
refine it.
Just a heads-up, I think =sys-libs/glibc-2.14.1-r3 is a stinker.
