Hi all, I think I've found a cause for our problems, but I need someone in RE to disable armv8el builds temporarily in Trunk:Testing to verify the fix, as I then can build glibc and gzip as a test in my home project.
The problem is as follows: glibc2.13 contains this patch: http://sourceware.org/ml/libc-ports/2010-11/msg00009.html, : + * sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h (atomic_full_barrier, + __arch_compare_and_exchange_val_32_acq): Use the atomic builtins + provided by GCC if __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 is defined. And when this patch is disabled, the conftest that gzip/m4 was stalling with will start working again under qemu-arm (we also confirmed that the reverse is true, when it's applied to glibc 2.12, conftest will stall). It seems to be a genuine problem in qemu and I've verified it on top of Linaro rootfs'es as well. My plan is: * Get armv8el builds disabled in Trunk:Testing * Add a patch to #undef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 for ARM builds in glibc, we can re-add when qemu has a fix. It shouldn't affect ABI/API when we re-add this. * Build this and verify typical packages like acl and gzip, m4 will build fine. * Submit fixed glibc package to Trunk:Testing and ask to have this alone enabled * When glibc package is built, re-enable armv8el Please let me know when you've disabled the builds and I'll get right on verifying and submitting. /Carsten 2011/6/22 Ulf Hofemeier <[email protected]>: > Boy, you are on top of things ;) > Ulf > > On Jun 22, 2011, at 6:49 AM, Carsten Munk wrote: > >> It basically sets a rlimit, signal handlers, tries to make printf fail >> intentionally, expects printf to fail with ENOMEM but instead it gets >> a sig11 which gets handled and something gets stuck along the way when >> exit'ing :) >> >> http://pastie.org/2106361 is the code in question. >> >> /Carsten >> >> >> 2011/6/22 Ulf Hofemeier <[email protected]>: >>> That's exactly what I said yesterday. I'm not sure what "checking whether >>> printf survives out-of-memory-conditions" is doing. I remember there used >>> to be an issue with rpmbuild reverting to single byte reads() rather than >>> doing 4k packages for ARM. This means the building would actually work, but >>> is by an order of magnitude slower, which will result in OBS eventually >>> killing the build process it runs into a timeout. >>> >>> On Jun 22, 2011, at 6:37 AM, Carsten Munk wrote: >>> >>>> We're still investigating, but the good news is that the qemu problem >>>> seems reproducable, and happens even on qemu git, linaro, qemu-meego >>>> and all these. >>>> >>>> Will follow up when I have something more - it seems like some >>>> mishandling of signals/out of memory conditions. >>>> >>>> /Carsten >>>> >>>> 2011/6/22 Carsten Munk <[email protected]>: >>>>> Thanks for letting me know, >>>>> >>>>> I'll query around a bit with qemu maintainers. >>>>> >>>>> /Carsten >>>>> >>>>> 2011/6/22 Hofemeier, Ulf <[email protected]>: >>>>>> Carsten, >>>>>> >>>>>> Latter one. I can eventually aborted the build for gzip and m4 after >>>>>> nothing had happened for hours, but that was yesterday and it happened >>>>>> again today. >>>>>> Ulf >>>>>> >>>>>> On 6/21/11 9:30 PM, "Carsten Munk" <[email protected]> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> qemu: Unsupported syscall: 369 >>>>>>> qemu: Unsupported syscall: 369 >>>>>>> qemu: Unsupported syscall: 369 >>>>>>> >>>>>>> is the one you refer to? >>>>>>> >>>>>>> Or: >>>>>>> >>>>>>> checking whether printf survives out-of-memory conditions... >>>>>>> /var/run/obs/worker/1/build/build: line 1261: 27071 Killed >>>>>>> chroot $BUILD_ROOT su -c /.build.command - $BUILD_USER < >>>>>>> /dev/null >>>>>>> >>>>>>> (I see that in m4, gzip) >>>>>>> >>>>>>> /Carsten >>>>>>> >>>>>>> 2011/6/22 Carsten Munk <[email protected]>: >>>>>>>> I'll try to see if I can catch the qemu errors - when there's any ARM >>>>>>>> problems like that, please reach out to meego-packaging@ and we'll >>>>>>>> usually get on it asap. >>>>>>>> >>>>>>>> (I try to keep track of the monitor but sometimes I don't catch it) >>>>>>>> >>>>>>>> 2011/6/22 Hofemeier, Ulf <[email protected]>: >>>>>>>>> That, plus the fact that qemu in Trunk:Testing seems to be crashing >>>>>>>>> reliably for gzip, m4, and db4. I'm working on restoring Trunk at >>>>>>>>> least. >>>>>>>>> Ulf >>>>>>>>> >>>>>>>>> On 6/21/11 9:09 PM, "Carsten Munk" <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Something went terribly wrong here: >>>>>>>>>> >>>>>>>>>> armv8el >>>>>>>>>> succeeded: 2 >>>>>>>>>> failed: 1353 >>>>>>>>>> unresolvable: 12 >>>>>>>>>> excluded: 89 >>>>>>>>>> i586 >>>>>>>>>> failed: 1440 >>>>>>>>>> unresolvable: 2 >>>>>>>>>> excluded: 14 >>>>>>>>>> >>>>>>>>>> /Carsten >>>>>>>>>> >>>>>>>>>> 2011/6/22 Ulf Hofemeier <[email protected]>: >>>>>>>>>>> Hi Chris Ferron, >>>>>>>>>>> The following change has been accepted. See the changelog below. >>>>>>>>>>> The package util-linux-ng from project Trunk has been deleted. >>>>>>>>>>> >>>>>>>>>>> Comments: >>>>>>>>>>> Reviewed OK >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> MeeGo Release Engineering Team >>>>>>>>>>> >>>>>>>>>>> [This message was auto-generated] >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Request #20594: >>>>>>>>>>> >>>>>>>>>>> delete: Trunk/util-linux-ng >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Message: >>>>>>>>>>> This pacakge will be replaced by the upstream "util-linux" >>>>>>>>>>> >>>>>>>>>>> State: accepted 2011-06-21T19:39:10 ulf >>>>>>>>>>> Comment: Reviewed OK >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> History: new 2011-06-13T09:56:30 ceferron >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> MeeGo-commits mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.meego.com/listinfo/meego-commits >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> MeeGo-packaging mailing list >>>> [email protected] >>>> http://lists.meego.com/listinfo/meego-packaging >>> >>> > > _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
