On Tue, Nov 29, 2016 at 10:11:34AM +0100, Thomas Schwinge wrote:
> Early after a system reboot (second run of the executable), I ran into a
> GNU Mach "panic ../vm/vm_page.c:2058: vm_page_evict: vm_page: unable to
> recycle any page"; see attached. As this is new code in GNU Mach (commit
> 5d12584
Hi!
On Mon, 28 Nov 2016 19:55:20 +0100, Samuel Thibault
wrote:
> Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote:
> > ..., but on the new ("bad") system, the first non-sensical (huge;
> > -2147479552 is 0x80001000) vm_allocate call actually succeeds:
>
> Yes, the userland address spac
Hello,
Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote:
> ..., but on the new ("bad") system, the first non-sensical (huge;
> -2147479552 is 0x80001000) vm_allocate call actually succeeds:
Yes, the userland address space is now 3G again, so it can now indeed
allocate that much.
> I hav
Hi!
On Mon, 28 Nov 2016 16:03:44 +0100, I wrote:
> Updating a Debian GNU/Hurd virtual machine to recent packages after many
> months, and then running the GCC testsuite, I observe the following
> behavior, which should be reproducible with the executable in the
> attached tarball:
>
> $ vmsta
Hello,
Thomas Schwinge, on Mon 28 Nov 2016 16:03:44 +0100, wrote:
> But nevertheless, unreclaimed swap space upon process
> termination sounds like a bug?
It's actually not really a new problem. It has just been emphasized
more with recent memory management changes.
Samuel
On Mon, Nov 28, 2016 at 04:03:44PM +0100, Thomas Schwinge wrote:
> Unless this a known issue, or somebody can quickly pinpoint the problem,
> I'll try to bisect core system packages, between the version of the
> "good" and "bad" disk images.
It's a known issue, a side effect of the page cache chan