done On 23 Jun 2011, at 11:38, Carsten Munk wrote: > 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
_______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
