On Sat, 2021-01-09 at 12:37 -0800, Khem Raj wrote: > On Sat, Jan 9, 2021 at 1:19 AM Richard Purdie > <richard.pur...@linuxfoundation.org> 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 > > > > <richard.pur...@linuxfoundation.org> 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 <richard.pur...@linuxfoundation.org> > > > > > > > > Reviewed-by: Alistair Francis <alistair.fran...@wdc.com> > > > > > > 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... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146554): https://lists.openembedded.org/g/openembedded-core/message/146554 Mute This Topic: https://lists.openembedded.org/mt/79486601/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
