Samuel Thibault, le ven. 10 janv. 2025 19:40:05 +0100, a ecrit:
> Diego Nieto Cid, le mar. 07 janv. 2025 18:48:49 +, a ecrit:
> > I've been running gnumach with this patch for some time, doing other
> > porting/debugging tasks and suffered from sporadic filesystem corruption.
>
> Probably ext2
Hi,
On Fri, Jan 10, 2025 at 07:40:05PM +0100, Samuel Thibault wrote:
>
> Probably ext2fs doesn't really cope well with memory allocation
> limitation?
>
That's a good candidate, indeed. I replaced the prinf with a panic call, but
I couldn't reproduce the error, yet.
Diego
Hello,
Diego Nieto Cid, le mar. 07 janv. 2025 18:48:49 +, a ecrit:
> I've been running gnumach with this patch for some time, doing other
> porting/debugging tasks and suffered from sporadic filesystem corruption.
Probably ext2fs doesn't really cope well with memory allocation
limitation?
Sa
Hello,
I've been running gnumach with this patch for some time, doing other
porting/debugging tasks and suffered from sporadic filesystem corruption.
I'm afraid this changes could be the cause of the issue. Currently, I switched
back to the kernel supplied by the Debian package to check whether c
From: Diego Nieto Cid
* include/mach/gnumach.defs: (vm_set_size_limit) new routine
(vm_get_size_limit) likewise
* kern/task.c: (task_create_kernel) if parent_task is not null copy virtual
memory limit
* tests/test-vm.c: (test_vm_limit) add test for the new routines
* vm/vm_kern.c: (p
