Great work, Carsten. FYI, The prlimit64 message also could bring problems. Gcc failed to build on arm because of it. I added a patch (gcc46-libiberty-conftest.patch) to gcc's configure file to ignore such warning. This may happened to other package also.
Junfeng -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Munk Sent: Thursday, June 23, 2011 11:11 PM To: Anas Nashif Cc: [email protected] Subject: Re: [meego-packaging] Please temporarily disable armv8el builds in Trunk:Testing, Re: ARM qemu issue (was Re: [meego-commits] 20594 accepted: Trunk/util-linux-ng was deleted) Thank you - I verified before someone re-enabled Trunk:Testing builds that my fix worked for what it's supposed to do. Had successful gzip build and m4 build. Please accept SR, re-enable builds and that should do the trick, but will sadly cause a rebuild of the world on both IA and ARM :/ There's still something about the prlimit64 messages, but that shouldn't be a blocker. /Carsten 2011/6/23 Anas Nashif <[email protected]>: > 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 _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
