From owner-freebsd-current@FreeBSD.ORG Sun Jun 22 17:41:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1259D33 for ; Sun, 22 Jun 2014 17:41:07 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id CA79527D3 for ; Sun, 22 Jun 2014 17:41:07 +0000 (UTC) Received: from [10.1.1.2] (S01060001abad1dea.hm.shawcable.net [50.70.146.73]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 92B7815062 for ; Sun, 22 Jun 2014 17:40:59 +0000 (UTC) Message-ID: <53A7152B.9060901@freebsd.org> Date: Sun, 22 Jun 2014 13:40:59 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: [CURRENT]: weird memory/linker problem? References: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="clVJfqFkFnhEJ8FdVtkFidt3jwnG7W1FO" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 17:41:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --clVJfqFkFnhEJ8FdVtkFidt3jwnG7W1FO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-22 10:56, O. Hartmann wrote: >=20 > Hello. >=20 > I face a strange problem on a set of CURRENT driven boxes. The systems = in question are > all the same version of CURRENT (more or less, a week or so discrepancy= ). >=20 > The boxes affected have 8 GB of RAM and are old-style Core2Duo systems.= >=20 > The phenomenon: >=20 > Starting up the box shows the operating system working. But sometimes i= t is impossible to > start certain applications, like Firefox - they segfault. More disturbi= ng is the fail of > the linker when building world. Sometimes I get strange messages like >=20 > relocation truncated to fit: R_X86_64_PC32 against symbol `__error' def= ined in .text >=20 > when compiling/linking. The funny thing is: rebooting the box and doing= exactly the same > very often leaves the system then operable - starting applications work= s, compiling works! >=20 > First I thought this could be a indication of a dying system and so I c= hecked the memory > for two days non-stop without any indication of anything wrong. The box= es do not have ECC > RAM - it's Intel. >=20 > I see this problem on two C2D based boxes relatively often (one E8400 t= wo core, another > Q6600 quadcore, both systems have 8 GB RAM). This phenomenon also occur= ed two or three > months ago on another machine with 32 GB RAM and a Core-i7 3930K, but i= t went away (it was > the very same error as shown above). >=20 > Another system, a i3-3220 with 16 GB RAM never showed the problem altho= ugh that system > build world also on a regular basis very frequent as the C2D systems do= =2E >=20 > Well, I feel a bit confused. On the first view, the problem looks weird= and it indicates > a kind of memory problem - but testing the memory didn't show anything = wrong.=20 >=20 > Today "windowmaker" stopped starting due to a malformed command in one = of windowmaker's > library. I did reboot the box and everything was all right. Then, also = today, I tried > compiling world and I got a weird error message about a misspelled "Int= __xxx", I can not > remember exactly the text, I rebooted and everything was all right agai= n. >=20 > Those errors are frequent on 8GB, C2D based systems and at the moment n= ot present any > more on more modern systems with more memory as described above. This c= ould be a > coincidence, but it is strange anyway. >=20 > I do not exclude dying hardware, but I'd like to ask whether there is s= omething strange > going on with FreeBSD's memory management at the moment and whether tho= se problems could > also be triggered by some nasty bug? I never see a crash (which would a= lso indicated > faulty hardware), I mostly realise those strange behaviour either after= a fresh boot or > after I ran some memory disk i/o intensive jobs, like updating the port= s tree. >=20 > By the way, FreeBSD CURRENT suffer from a tremendous performance cut th= ese days when > compiling world and updating the ports tree and running portmaster. On = one box, on which > ports reside on a UFS partion, it takes more than 8 minutes to pass the= portmaster -da, > which is quick when not compiling world. On another system on which /us= r/ports is > residing on ZFS (the box has 16GB RAM!), it takes sometimes 30(!) minut= es to perform a > "svn update" while compiling world (that is the i3-3220 with 16 GB RAM = system), it takes > 6 - 15 minutes when the box is relaxed and updating the ports tree the = first time (every > subsequent update is much faster). >=20 > Well, I know these reports of mine are a bit weird since I have no exac= t log of the > problems, but I think if there is an issue not with the hardware, I rep= ort those in. >=20 > Regards, >=20 > oh >=20 In order to get a better benchmark for 'svn update' on the ports tree if you 'zfs unmount pool/usr/ports' it will flush all ARC entries for that dataset, then 'zfs mount pool/usr/ports' and run the test again. This should give you more reproducible results --=20 Allan Jude --clVJfqFkFnhEJ8FdVtkFidt3jwnG7W1FO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTpxUuAAoJEJrBFpNRJZKf9GMQALBPuuFjvpnTto31S2zMU6/F yOhgoCIojD75PdTGrWNSn4KMfDnQX3DHvJoYrH6vOyTJO3N0PdV5yKiQuigAEJYZ cb5OfGvxR5d6ZBe/f+5Za9OZI0srKsFS1nX5wSwFkvc+njv5fsQaDdxrIsFSQY6+ xk6U+v5CBV+gENxchtmkIhTlBTqjLZjz4xfEkuGlyn6ry1TXtxeuN5gYiDdD8w4s gO1SSMq5F3vg12O+Nhh2BJJcpI3Jz3d8j/7fpWD4psMfClzleFv2qkNljVKdm45k syXnI4UfvKfHWOewUAvkVWXOgFpnxI4o/7DOr7XgMPH2snz/8RiKgUifDl1Vsy6C wQNSDy/dQfdppV9UwBoqPZjOvJbMK/2nKFy18eaxrBdYj8PYQcjLy8yxgqqOM+Qi YYUV8Ms/6/ECagHPEN+ZxglBk9aNXqw+dwFo1ph70ORo9MjnE2UycAloY9MsYe71 mtxE90C8Jdet0WXosDuomUIzDr0HelwYaEyZOihRm5Xjp4FVMtUbymAjC/WPTV4x 2YvZzuCNbTNfzuBW0x3RlR4Oqh0EcSHsVVUDXlHCB3hI2fwqAWRbUmyVWdPcLI8H Ve+YK6GpKU0RlJ4KJO3jkIhSh8L/Ew4/8B/5msQQZr1nRJ55PlXXuAwfAPK1W8+S vyr7j7HAjtN8cCeOw5MD =LXDC -----END PGP SIGNATURE----- --clVJfqFkFnhEJ8FdVtkFidt3jwnG7W1FO--