> On 17 Aug 2016, at 16:51, Koen Kooi <k...@dominion.thruhere.net> wrote: > > >> Op 17 aug. 2016, om 16:39 heeft Leif Lindholm <leif.lindh...@linaro.org> het >> volgende geschreven: >> >> Hi all, >> >> (Sent to cross-distro with debian-arm on cc.) >> >> We have an 'interesting' situation ahead of us, or indeed some of us >> have already fallen into it: >> >> ARM64 platforms with > 512GB between the lowest and highest RAM >> addresses end up getting their amount of usable memory truncated if >> the kernel is built for 39-bit VA (which is what currently happens for >> Debian kernels). For 4.7, the arm64 defconfig was changed to enable >> 48-bit VA by default. >> >> While itself not a critical error (but really annoying), in >> combination with GRUB putting the initrd near the top of available >> RAM, we end up with systems not booting. We think we've also seen >> issues with ACPI tables above this waterline. >> >> Simple - all we need to do then is enable 48-bit VA in the arm64 >> kernel config? Well, yes. I know Fedora are already doing this, and I >> have raised a bug[1] for Debian to do the same. >> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834505 >> >> The problem is - some pieces of software have had time to be written >> in a ... let's charitably call it a "focused on amd64" fasion ... with >> the embedded assumption that anything above virtual address bit 44 is >> a pointer-tag free-for-all. >> >> On the Debian-ish side, we're coming up on both Ubuntu 16.10 and the >> freeze for Stretch, leaving a pretty short window to resolve this >> unholy kernel->initrd->userland triangle. >> >> The applications we know are affected are luajit and mozjs (libv8 is >> not a problem). But this has a follow-on cost: both of these are used >> by other packages. Other jit/runtime packages could have their own >> issues. >> >> The mozjs bug is fixed on trunk, and will hopefully make it into >> release 49[2], but it remains to be seen if that's too late for some >> distributions. > > Since mozjs is “special” when it comes to API, you have to depend on a > specific version of it, so policykit hard-depends on mozjs17, which has no > fixes available for the VA problem :( I’ve seen reports of systems unable to > boot because of the systemd->polkit->mozjs chain. Is anyone working on fixing > that?
If all you need is a backport of the upstream patch to mozjs17, feel free to take mine: https://build.opensuse.org/package/view_file/openSUSE:Factory/mozjs17/mozjs-support-48bit-va.patch?expand=1 The hardest nut to crack for me right now is the couchdb issue, as that relies on SpiderMonkey, which predates mozjs17 and the dynamic allocation patch alone doesn’t actually fix it, as it pregenerates bits into its .rodata section which may get mapped high in address space again. Alex _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
