Date: Sun, 22 Jun 2014 13:40:59 -0400 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: [CURRENT]: weird memory/linker problem? Message-ID: <53A7152B.9060901@freebsd.org> In-Reply-To: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> References: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 2014-06-22 10:56, O. Hartmann wrote: > > Hello. > > 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). > > The boxes affected have 8 GB of RAM and are old-style Core2Duo systems. > > The phenomenon: > > Starting up the box shows the operating system working. But sometimes it is impossible to > start certain applications, like Firefox - they segfault. More disturbing is the fail of > the linker when building world. Sometimes I get strange messages like > > relocation truncated to fit: R_X86_64_PC32 against symbol `__error' defined in .text > > when compiling/linking. The funny thing is: rebooting the box and doing exactly the same > very often leaves the system then operable - starting applications works, compiling works! > > First I thought this could be a indication of a dying system and so I checked the memory > for two days non-stop without any indication of anything wrong. The boxes do not have ECC > RAM - it's Intel. > > I see this problem on two C2D based boxes relatively often (one E8400 two core, another > Q6600 quadcore, both systems have 8 GB RAM). This phenomenon also occured two or three > months ago on another machine with 32 GB RAM and a Core-i7 3930K, but it went away (it was > the very same error as shown above). > > Another system, a i3-3220 with 16 GB RAM never showed the problem although that system > build world also on a regular basis very frequent as the C2D systems do. > > 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. > > 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 again. > > Those errors are frequent on 8GB, C2D based systems and at the moment not present any > more on more modern systems with more memory as described above. This could be a > coincidence, but it is strange anyway. > > I do not exclude dying hardware, but I'd like to ask whether there is something strange > going on with FreeBSD's memory management at the moment and whether those problems could > also be triggered by some nasty bug? I never see a crash (which would also 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 ports tree. > > By the way, FreeBSD CURRENT suffer from a tremendous performance cut these 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 /usr/ports is > residing on ZFS (the box has 16GB RAM!), it takes sometimes 30(!) minutes 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). > > Well, I know these reports of mine are a bit weird since I have no exact log of the > problems, but I think if there is an issue not with the hardware, I report those in. > > Regards, > > oh > 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 -- Allan Jude [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53A7152B.9060901>