On Sat, 2021-01-09 at 22:49 +0000, Richard Purdie via lists.openembedded.org wrote: > On Sat, 2021-01-09 at 12:37 -0800, Khem Raj wrote: > > On Sat, Jan 9, 2021 at 1:19 AM Richard Purdie > > <[email protected]> wrote: > > > > > > On Fri, 2021-01-08 at 10:00 +0000, Richard Purdie via > > > lists.openembedded.org wrote: > > > > On Wed, 2021-01-06 at 14:53 -0800, Alistair Francis wrote: > > > > > On Wed, Jan 6, 2021 at 2:36 PM Richard Purdie > > > > > <[email protected]> wrote: > > > > > > > > > > > > When building with the new version of qemu we see errors like: > > > > > > > > > > > > """ > > > > > > qemu-i386: Unable to reserve 0x7ffff000 bytes of virtual address > > > > > > space at > > > > > > 0x1000 (Success) for use as guest address space (check your virtual > > > > > > memory > > > > > > ulimit setting, min_mmap_addr or reserve less using -R option) > > > > > > > > > > > > ERROR: The postinstall intercept hook > > > > > > 'update_gio_module_cache-nativesdk' failed > > > > > > """ > > > > > > > > > > > > The VM reseration patches we're carrying look suspicious in this > > > > > > context. > > > > > > Drop them since we don't appear to be seeing those issues any more > > > > > > on the > > > > > > autobuilder and I suspect the patches have become broken and a > > > > > > liability. > > > > > > webkitgtk builds seem to be ok now. > > > > > > > > > > Yes! Getting rid of these patches is great! > > > > > > > > > > > > > > > > > Signed-off-by: Richard Purdie <[email protected]> > > > > > > > > > > Reviewed-by: Alistair Francis <[email protected]> > > > > > > > > Unfortunately this issue is still present, I thought we weren't seeing > > > > it but once other errors cleared, this one remains, only on > > > > qemux86+musl for webkitgtk. > > > > > > > > I think we need to get to the bottom of it and figure out something > > > > which is upstreamable. This will block the qemu upgrade until we can > > > > fix it unfortunately unless we block webkitgtk on musl on 32 bit x86. > > > > > > I've sent out a couple of linux-user mmap patches for this. With those > > > fixes applied, qemu seems fine so I've upgraded. > > > > > > Khem: I do wonder whether musl's memory allocation is all ok given it > > > loops indefinitely if it doesn't see EFAULT and only ENOMEM. That may > > > need investigation? > > > > I forwarded it to musl community as well. Other musl distros are also > > carrying some patches in qemu > > eg, voidlinux has this > > https://github.com/void-linux/void-packages/blob/master/srcpkgs/qemu/patches/mmap-mremap-efault.patch > > which actually could be forwarded upstream qemu. > > Yes, the first bit of that is what I sent upstream to qemu, I came to > the same conclusion :) > > The other bit looks to optimise the looping...
Just for the archives, we ran into a problem on the centos7 builders with this change where gobject-introspection would show: qemu-i386: Unable to reserve 0x7ffff000 bytes of virtual address space at 0xa000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) /proc/sys/vm/mmap_min_addr was set to 4096. Somewhat confusingly, the way to make things work was to set this higher to to 65536 (there is an addr != temp test in there and addr was coming back as 0x10000 instead of 0x1000). Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146597): https://lists.openembedded.org/g/openembedded-core/message/146597 Mute This Topic: https://lists.openembedded.org/mt/79486601/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
