Re: [PATCH gnumach v4] Implement per task virtual memory limit

Hi, I was updating this patch and I've gut a doubt with what to do with the result of vm_map_find_entry_anywhere in case of a failure to enforce the limit. I end up with code like below: if (anywhere) { entry = vm_map_find_entry_anywhere(map, size, mask, FALSE, &start);

Re: [RFC] Toy journaling skeleton for ext2fs

And yeah i read that diskfs_sync_everything is not the right place, but didn't yet change it. Was focused on some of the details of the journal.c tonight. More to follow soon. On Thu, Jun 26, 2025 at 11:40 PM Milos Nikic wrote: > Thanks all, > I'm attaching here the initial super early patch. >

Re: [RFC] Toy journaling skeleton for ext2fs

tx_id = journal_tx_id++; + +header_len = snprintf(header, sizeof(header), "=== BEGIN TX %" PRIu64 " === [%s]", tx_id, time_str); +footer_len = snprintf(footer, sizeof(footer), "=== END TX %" PRIu64 " ===", tx_id); + +total_len = header_len + 1 + body_le

Re: [RFC] Toy journaling skeleton for ext2fs

Hello, Milos Nikic, le mer. 25 juin 2025 14:36:04 -0700, a ecrit: > As a learning and exploration effort, I've started working on a toy journaling > layer inside ext2fs. The goal is to understand how journaling might look in a > user-space filesystem like Hurd’s, and whether it's feasible to imple

Re: [PATCH] i386 intel read fault fix

Milos Nikic, le mar. 24 juin 2025 18:48:45 -0700, a ecrit: > Created a new patch. (don't know if that is the right way to respond).  Yes it is, applied, thanks! > On Tue, Jun 24, 2025 at 6:05 AM Samuel Thibault <[1]samuel.thiba...@gnu.org> > wrote: > > Hello, > > Milos Nikic, le lun. 23

Re: [RFC] Toy journaling skeleton for ext2fs

June 25, 2025 at 5:36 PM, "Milos Nikic" mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote: > > Hi all, > > As a learning and exploration effort, I've started working on a toy > journaling layer inside ext2fs. The goal is to understand how journaling

Re: [PATCH] i386 intel read fault fix

Thank you. Created a new patch. (don't know if that is the right way to respond). On Tue, Jun 24, 2025 at 6:05 AM Samuel Thibault wrote: > Hello, > > Milos Nikic, le lun. 23 juin 2025 21:17:32 -0700, a ecrit: > > include the missing header, fix the warning. > > Better include it the usual way,

Re: [PATCH gnumach v4] Implement per task virtual memory limit

Diego Nieto Cid, le mer. 25 juin 2025 00:44:04 +0100, a ecrit: > On Wed, Jun 25, 2025 at 01:08:31AM +0200, Samuel Thibault wrote: > > > > I meant a vm_protect that changes the maximum protection. > > > > Ah, I think we concluded that the maximum protection can only go > into strictier values due

Re: [PATCH gnumach v4] Implement per task virtual memory limit

On Wed, Jun 25, 2025 at 01:08:31AM +0200, Samuel Thibault wrote: > > I meant a vm_protect that changes the maximum protection. > Ah, I think we concluded that the maximum protection can only go into strictier values due to the loop here[1]. More specifically the following if: if ((/* VM_PR

Re: [PATCH gnumach v4] Implement per task virtual memory limit

Diego Nieto Cid, le mer. 25 juin 2025 00:04:39 +0100, a ecrit: > But then I don't think I understand your suggestion: > > > It would be also useful to check that trying to vm_protect the PROT_NONE > > into PROT_ALL fails when that comes above the limit. > > Why would vm_protect fail when upgradin

Re: [PATCH gnumach v4] Implement per task virtual memory limit

On Wed, Jun 25, 2025 at 12:52:41AM +0200, Samuel Thibault wrote: > > Yes, and that's what we want: like on Linux. RLIMIT_AS is supposed to > limit mmap(PROT_NONE) as well. > Ok, then the assumption of my test is completely wrong :) I'll remove it. But then I don't think I understand your sugge

Re: [PATCH gnumach v4] Implement per task virtual memory limit

Diego Nieto Cid, le mar. 24 juin 2025 23:50:49 +0100, a ecrit: > On Tue, Jun 24, 2025 at 03:54:23PM +0200, Samuel Thibault wrote: > > Because that is what Linux implements: RLIMIT_AS limits what > > mmap(PROT_NONE) can allocate. Then, changing with mprotect() will not > > change the RLIMIT_AS count

Re: [PATCH gnumach v4] Implement per task virtual memory limit

On Tue, Jun 24, 2025 at 03:54:23PM +0200, Samuel Thibault wrote: > > Because that is what Linux implements: RLIMIT_AS limits what > mmap(PROT_NONE) can allocate. Then, changing with mprotect() will not > change the RLIMIT_AS counting. > mmap(PROT_NONE)[1][2] ends up calling vm_map(cur: VM_PROT_NO

Re: [PATCH gnumach v4] Implement per task virtual memory limit

Diego Nieto Cid, le mar. 24 juin 2025 14:39:35 +0100, a ecrit: > On Mon, Jun 23, 2025 at 12:51:23AM +0200, Samuel Thibault wrote: > > > + err = vm_deallocate(mach_task_self(), mem, M_512M); > > > + ASSERT_RET(err, "deallocation failed"); > > > > It would be also useful to check that trying to vm

Re: [PATCH gnumach v4] Implement per task virtual memory limit

On Mon, Jun 23, 2025 at 12:51:23AM +0200, Samuel Thibault wrote: > > + err = vm_deallocate(mach_task_self(), mem, M_512M); > > + ASSERT_RET(err, "deallocation failed"); > > It would be also useful to check that trying to vm_protect the PROT_NONE > into PROT_ALL fails when that comes above the li

Re: [PATCH] i386 intel read fault fix

Hello, Milos Nikic, le lun. 23 juin 2025 21:17:32 -0700, a ecrit: > include the missing header, fix the warning. Better include it the usual way, as , and outside the #if > --- > i386/intel/read_fault.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/i386/intel/read_fault.c b/i386/int

Re: [PATCH] i386 kern: fix overflow in vm_object_print_part call

Milos Nikic, le mar. 24 juin 2025 00:58:44 +0100, a ecrit: > From: Milos Nikic > > The call to vm_object_print_part was passing 0ULL and ~0ULL > for offset and size, respectively. These values are 64-bit > (unsigned long long), which causes compiler warnings when > building for 32-bit platforms w

Re: [PATCH] kdb: Fix printf format warning for phys_addr_t

Milos Nikic, le mar. 24 juin 2025 02:35:44 +0100, a ecrit: > When building without PAE support, phys_addr_t is defined as unsigned long, > but the kdb printf call uses %llx, which expects an unsigned long long. > This triggers a -Wformat warning due to a type mismatch. > > Fix this by explicitly c

Re: Developer environment setup problem

Samuel Thibault, le dim. 22 juin 2025 17:14:41 +0200, a ecrit: > Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit: > > Do you will publish amd64 version? > > There are already quite recent versions for amd64. But I had forgotten about the mig transition... I have rebuilt the amd64 im

Re: [PATCH] i386 kern: fix overflow in vm_object_print_part call

Ah yes, good. Damien Sent from Proton Mail Android Original Message On 24/6/25 2:30 pm, Milos Nikic wrote: > Hello,- > > On 32-bit systems, UINTPTR_MAX is 0x > > - > > On 64-bit systems, UINTPTR_MAX is 0x > > That is what we want, right? > > Also passi

Re: [PATCH] i386 kern: fix overflow in vm_object_print_part call

Here is an example: https://godbolt.org/z/fM8K5nGhx for 64 bits. (didnt find a good option for 32 bit compiler there) On Mon, Jun 23, 2025 at 9:29 PM Milos Nikic wrote: > > Hello, > >- > >On *32-bit systems*, UINTPTR_MAX is 0x >- > >On *64-bit systems*, UINTPTR_MAX is 0x

Re: [PATCH] i386 kern: fix overflow in vm_object_print_part call

Hello, - On *32-bit systems*, UINTPTR_MAX is 0x - On *64-bit systems*, UINTPTR_MAX is 0x That is what we want, right? Also passing anything larger than 0x (like ~0ULL) on a 32-bit build causes *overflow and truncation*, and triggers warnings. On Mon, Jun 23, 2025

Re: [PATCH] i386 kern: fix overflow in vm_object_print_part call

But on 64 bit, isn't the value supposed to be sign extended to the full width not uint32 max? Damien Sent from Proton Mail Android Original Message On 24/6/25 9:59 am, Milos Nikic wrote: > From: Milos Nikic > > The call to vm_object_print_part was passing 0ULL and ~0UL

Re: [PATCH] i386: trap.c add prototype for handle_double_fault

On Mon, Jun 23, 2025 at 11:18:53PM +0200, Samuel Thibault wrote: > Diego Nieto Cid, le lun. 23 juin 2025 21:02:03 +0100, a ecrit: > > On Mon, Jun 23, 2025 at 07:52:00PM +0100, Milos Nikic wrote: > > > > > > +/* Called from assembly (locore.S) */ > > > +void handle_double_fault(struct i386_saved_s

Re: [PATCH] i386: trap.c add prototype for handle_double_fault

Milos Nikic, le lun. 23 juin 2025 19:52:00 +0100, a ecrit: > The handle_double_fault function is defined in trap.c and called > from x86_64/locore.S, but lacked a prototype, triggering a compiler > warning: 'no previous prototype for handle_double_fault'. > > This change adds a forward declaration

Re: [PATCH] i386: trap.c add prototype for handle_double_fault

Diego Nieto Cid, le lun. 23 juin 2025 21:02:03 +0100, a ecrit: > On Mon, Jun 23, 2025 at 07:52:00PM +0100, Milos Nikic wrote: > > > > +/* Called from assembly (locore.S) */ > > +void handle_double_fault(struct i386_saved_state *regs); > > + > > Shouldn't this prototype be in i386/i386/trap.h whi

Re: [PATCH] i386 ldt.c make ldt_fill static

Milos Nikic, le lun. 23 juin 2025 20:07:08 +0100, a ecrit: > Compiler warns about it, and its only invoked from this file. Applied, thanks! > --- > i386/i386/ldt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/i386/i386/ldt.c b/i386/i386/ldt.c > index 5db36426..7db67f

Re: [PATCH] i386: trap.c add prototype for handle_double_fault

Hello, On Mon, Jun 23, 2025 at 07:52:00PM +0100, Milos Nikic wrote: > > +/* Called from assembly (locore.S) */ > +void handle_double_fault(struct i386_saved_state *regs); > + Shouldn't this prototype be in i386/i386/trap.h which is included by locore.S? Cheers, Diego

Re: [PATCH gnumach] ioapic.c: Fix default polarity and trigger mode for irqs

Michael Banck via Bug reports for the GNU Hurd, le lun. 23 juin 2025 08:57:14 +0200, a ecrit: > On Sun, Jun 22, 2025 at 10:06:40PM +0200, Samuel Thibault wrote: > > Damien Zammit, le dim. 22 juin 2025 07:33:46 +, a ecrit: > > > 0-13 are on rising edge (legacy) > > > 14-N are active-low level t

Re: [PATCH gnumach] ioapic.c: Fix default polarity and trigger mode for irqs

Hi, On Sun, Jun 22, 2025 at 10:06:40PM +0200, Samuel Thibault wrote: > Damien Zammit, le dim. 22 juin 2025 07:33:46 +, a ecrit: > > 0-13 are on rising edge (legacy) > > 14-N are active-low level triggered. > > > > This allows for PIIX3 chipset to have working IDE, > > if we patch hurd/acpi to

Re: Developer environment setup problem

Hello folks, Ok i have pulled the latest code to my host machine. It contains all the fixes. I was able to run the test now and it ran successfully. Thanks Samuel. I also renamed hd0 to wd0 in my Debian-Hurd fstab and was able to make the cross compiled kernel boot up and work. Thanks Almudena, f

Re: Problem without -M q35 option for qemu

Hi, Now that [1] and [2] are merged, hurd boots in qemu without -M q35. Almu, maybe you can compile hurd/acpi.static and gnumach with these changes and try on old hardware with piixide, the "lost interrupt" problem should be gone, but I'm not sure if that is the problem you saw, or if it timed o

Re: [PATCH gnumach] ioapic.c: Fix default polarity and trigger mode for irqs

Hi, On 6/23/25 6:06 AM, Samuel Thibault wrote: > With both in place, should we perhaps make gnumach default to using > apic even without smp ? > > (that'd enable hpet by default, notably) > Yes that is a great idea!  I can send a patch later. Damien

Re: [PATCH gnumach v4] Implement per task virtual memory limit

Hello, dnie...@gmail.com, le lun. 16 juin 2025 23:58:06 +0100, a ecrit: > diff --git a/tests/test-vm.c b/tests/test-vm.c > index 4ece792e..8e4ad884 100644 > --- a/tests/test-vm.c > +++ b/tests/test-vm.c > @@ -75,11 +75,96 @@ static void test_wire() >// TODO check that all memory is actually wi

Re: [PATCH glibc v1] Hurd limits: implement RLIMIT_AS against Mach RPCs

Hello, Thanks for this! dnie...@gmail.com, le lun. 16 juin 2025 23:58:07 +0100, a ecrit: > diff --git a/hurd/hurdrlimit.c b/hurd/hurdrlimit.c > index 6cb5045bfe..6b0d8a26a3 100644 > --- a/hurd/hurdrlimit.c > +++ b/hurd/hurdrlimit.c > @@ -39,6 +39,11 @@ init_rlimit (void) > >for (i = 0; i <

Re: [PATCH hurd v2] libpager: raise RLIMIT_AS if permissions allow us

dnie...@gmail.com, le lun. 16 juin 2025 23:58:08 +0100, a ecrit: > From: Diego Nieto Cid > > * libpager/demuxer.c(pager_start_workers): set current and max RLIMIT_AS > to RLIM_INFINITY when the current user has access to the privileged host > port. Applied, thanks! > --- > libpager/d

Re: [PATCH gnumach] ioapic.c: Fix default polarity and trigger mode for irqs

Damien Zammit, le dim. 22 juin 2025 07:33:46 +, a ecrit: > 0-13 are on rising edge (legacy) > 14-N are active-low level triggered. > > This allows for PIIX3 chipset to have working IDE, > if we patch hurd/acpi to ignore buggy irq 9 response. With both in place, should we perhaps make gnumach

Re: [PATCH hurd] acpi: Ignore irq 9 requests because PIIX3 ACPI is wrong

Damien Zammit, le dim. 22 juin 2025 07:36:10 +, a ecrit: > Fall back to bios defaults for requests for irq 9. > Ideally we could check the PIIX3 bridge device exists on > pci, but that would require pci access before pci-arbiter > exists. This is a convenient workaround for now. Applied, than

Re: [PATCH gnumach] ioapic.c: Fix default polarity and trigger mode for irqs

Damien Zammit, le dim. 22 juin 2025 07:33:46 +, a ecrit: > 0-13 are on rising edge (legacy) > 14-N are active-low level triggered. > > This allows for PIIX3 chipset to have working IDE, > if we patch hurd/acpi to ignore buggy irq 9 response. Applied, thanks! > --- > i386/i386at/ioapic.c | 1

Re: Developer environment setup problem

Milos Nikic, le dim. 22 juin 2025 08:55:16 -0700, a ecrit: > I did post the configs already (but I guess they just got lost in the emails) Apparently indeed. > here they are again: > > [1]https://justpaste.it/gg2af is config log from Debian Hurd  Thanks. I have added some configure snippet to t

Re: Developer environment setup problem

Hi: I read your explaination. The script https://github.com/AlmuHS/gnumach_dev_scripts/blob/main/compile_scratch.sh is mine, and it's designed to compile a gnumach-smp kernel, with APIC and rumpdisk enabled, from Linux. So, if you try to boot the gnumach compiled with this script, you have to be s

Re: Developer environment setup problem

Thank you Samuel, I did post the configs already (but I guess they just got lost in the emails) here they are again: https://justpaste.it/gg2af is config log from Debian Hurd In the meantime I got development from Qemu working thanks to your guys suggestions. (I already submitted a few small pat

Re: Developer environment setup problem

True. I've just noticed it Thanks for your work El dom, 22 jun 2025 a las 17:14, Samuel Thibault () escribió: > Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit: > > Do you will publish amd64 version? > > There are already quite recent versions for amd64. > > Samuel >

Re: Developer environment setup problem

Almudena Garcia, le dim. 22 juin 2025 17:10:22 +0200, a ecrit: > Do you will publish amd64 version? There are already quite recent versions for amd64. Samuel

Re: Developer environment setup problem

Do you will publish amd64 version? El dom, 22 jun 2025 a las 16:58, Samuel Thibault () escribió: > Samuel Thibault, le dim. 22 juin 2025 16:41:14 +0200, a ecrit: > > Samuel Thibault, le dim. 22 juin 2025 16:27:26 +0200, a ecrit: > > > Milos Nikic, le dim. 15 juin 2025 17:16:54 -0700, a ecrit: > >

Re: Developer environment setup problem

Samuel Thibault, le dim. 22 juin 2025 16:41:14 +0200, a ecrit: > Samuel Thibault, le dim. 22 juin 2025 16:27:26 +0200, a ecrit: > > Milos Nikic, le dim. 15 juin 2025 17:16:54 -0700, a ecrit: > > > I am developing inside qemu (on Arch linux) with debian > > > image debian-hurd-20230608.img. > > > >

Re: Developer environment setup problem

Samuel Thibault, le dim. 22 juin 2025 16:27:26 +0200, a ecrit: > Milos Nikic, le dim. 15 juin 2025 17:16:54 -0700, a ecrit: > > I am developing inside qemu (on Arch linux) with debian > > image debian-hurd-20230608.img. > > That image is quite old actually. Perhaps better use a more up-to-date > i

Re: Developer environment setup problem

Hello, Milos Nikic, le dim. 15 juin 2025 17:16:54 -0700, a ecrit: > I am developing inside qemu (on Arch linux) with debian > image debian-hurd-20230608.img. That image is quite old actually. Perhaps better use a more up-to-date image, I have now uploaded 20250622. > When i ".configure" and then

Re: [PATCH] The function lock_info_sort was defined as static and aliased via a macro to lis, requiring a forward declaration to be callable from lip(). This indirection served no functional purpose a

Thank you. I wasn't aware of that. Will try to format it better going forward! On Sat, Jun 21, 2025, 4:43 AM Samuel Thibault wrote: > Hello, > > Milos Nikic, le ven. 20 juin 2025 18:14:58 +0100, a ecrit: > > This change: > > - Removes the macro aliasing lock_info_sort to lis > > - Moves lock_i

Fwd: Re: [PATCH 0/1] fix cp /dev/null file

Courriel initial De : gfleury Envoyé : 21 juin 2025 13:23:17 GMT+02:00 À : Samuel Thibault Objet : Re: [PATCH 0/1] fix cp /dev/null file Le 2025-01-18 18:35, Guy-Fleury Iteriteka a écrit : > Le 18 janvier 2025 15:08:55 GMT+02:00, Samuel Thibault > a écrit : Guy-

Re: [PATCH] Reading lapic->error_status.r may have side effects, and we must preserve it. To avoid a compiler warning about err being unused, cast it to (void).

Milos Nikic, le jeu. 19 juin 2025 16:51:05 +0100, a ecrit: > This keeps the behavior intact while eliminating the warning. Applied, thanks! > --- > i386/i386/smp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/i386/i386/smp.c b/i386/i386/smp.c > index e3e4cc82..53d9b876 100644 > --

Re: Problem without -M q35 option for qemu

Hi: We get the same issue (or pretty similar) in real hardware, in many Thinkpad models with Core2Duo. And the already known problem with SMP even in more modern Thinkpad models (probably the problem keeps in some other computers, but I don't have another PC to test it). I think that the problem

Re: [PATCH] Fixing compiler warnings on ktss c-file. Some that only appear when building on 32 bit arch, some that happen regardless of architecture. Changes tested on the 32 bit build.

Applied, thanks! Milos Nikic, le ven. 20 juin 2025 22:23:43 +0100, a ecrit: > --- > i386/i386/ktss.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/i386/i386/ktss.c b/i386/i386/ktss.c > index 34cb6df2..1f61d3d6 100644 > --- a/i386/i386/ktss.c > +++ b/i386/i386/ktss.

Re: [PATCH] The function lock_info_sort was defined as static and aliased via a macro to lis, requiring a forward declaration to be callable from lip(). This indirection served no functional purpose a

Hello, Milos Nikic, le ven. 20 juin 2025 18:14:58 +0100, a ecrit: > This change: > - Removes the macro aliasing lock_info_sort to lis > - Moves lock_info_sort before lip() to eliminate the need for a forward > declaration > - Updates the call in lip() to refer to lock_info_sort directly > > The

Re: [PATCH] i386: Remove unused volatile variable err in amp.c

Yes, thank you. I created another patch where I am suppressing it. (void) err. That should be better i hope Thank you. On Fri, Jun 20, 2025 at 10:07 PM Damien Zammit wrote: > As discussed, this patch is not correct. > > Thanks, > Damien > > On 6/19/25 2:56 PM, Milos Nikic wrote: > > The varia

Re: [PATCH] i386: Remove unused volatile variable err in amp.c

As discussed, this patch is not correct. Thanks, Damien On 6/19/25 2:56 PM, Milos Nikic wrote: > The variable was assigned but never used, and was marked volatile > unnecessarily. This patch removes the dead assignment and declaration, and > one compiler warning. > --- > i386/i386/smp.c | 2 -

Re: [PATCH] The function lock_info_sort was defined as static and aliased via a macro to lis, requiring a forward declaration to be callable from lip(). This indirection served no functional purpose a

In addition, Lis() function is declared static in the code as it exists before this patch, and it has been like that since 2023: static void lis(int arg, int abs, int count); It is not very surprising that nothing outside of this c file is directly calling lis() The only thing that calls lis()

Re: [PATCH] The function lock_info_sort was defined as static and aliased via a macro to lis, requiring a forward declaration to be callable from lip(). This indirection served no functional purpose a

Hello, I rebuilt the kernel with LOCK_MONITOR enabled (via CPPFLAGS="-DLOCK_MONITOR") and booted into it successfully. The system is running normally, and lock monitoring functions like lock_info_sort are present. I also verified that lis() is not used anywhere in the source tree (confirmed with

Re: [PATCH] The function lock_info_sort was defined as static and aliased via a macro to lis, requiring a forward declaration to be callable from lip(). This indirection served no functional purpose a

Hi, Did you try compiling with lock monitoring enabled to make sure you didn't break kdb? I think there is a caller of lis and/or lip from my memory. Damien Sent from Proton Mail Android Original Message On 21/6/25 3:20 am, Milos Nikic wrote: > This change: > - Removes t

Re: No `hurd-i386` and `hurd-amd64` variants of `crossbuild-essential-*`.

Hello, Yuqian Yang, le jeu. 19 juin 2025 11:59:04 +, a ecrit: > I found that Debian lacks `hurd-i386` and `hurd-amd64` variants of > `crossbuild-essential-*`[1]. I wonder whether this is intentional, or we can > just add these two. I'm not aware of any fundamental reason against this, but I g

Re: Developer environment setup problem

Oh wow. Thank you all folks. And especially Diego. Yes the mig thing was off somehow. I followed your clean installation with your steps and managed not only to run the tests, but also to successfully boot with the freshly built gnumech kernel. Thanks so much. Expect some (trivial at first) patc

Re: Developer environment setup problem

Hi again :) On Thu, Jun 19, 2025 at 01:16:20AM +0100, Diego Nieto Cid wrote: > > You can also test by installing mig from the Debian repository instead of > building it from source. > If you go that route you would need: sudo apt install mig-i686-gnu Or maybe the test makefiles need some

Re: Developer environment setup problem

Hello, On Tue, Jun 17, 2025 at 05:18:30PM -0700, Milos Nikic wrote: > > As far as that "n", I have no idea where that is coming from. It's not > happening when I try on the Host, only inside Hurd. > I see in the Makefile there is a line such as: > MIGCOM = $(MIG) -n -cc cat - /dev/null > It's U

Re: Developer environment setup problem

June 17, 2025 at 8:18 PM, "Milos Nikic" mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote: > > Hello folks, > > Thanks for all the emails. I've never really gotten the hang of "hacking" on the Hurd / GNU Mach / MiG, etc. Sergey wrote these two guid

Re: Developer environment setup problem

Hello folks, Thanks for all the emails. The flavor I'm running is hurd-i386 which came with the pre-installed debian-hurd-20230608.img. I am just cloning the repo. Trying to rebuild it for 32 bit, and stick it inside the /boot folder, and then change grub.cfg minimally to take my (just built and

Re: Developer environment setup problem

June 17, 2025 at 12:25 AM, "Milos Nikic" mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote: > > Hello > > Thanks folks, I appreciate any help you guys can provide. > > Yes I used the pristine gnumach and mig. Just cloned and pulled again today. If y

Re: Developer environment setup problem

Hello, Milos Nikic, le lun. 16 juin 2025 21:25:21 -0700, a ecrit: > $ make tests/test-task.iso (from my build directory). > The thing didn't even compile correctly: > > /usr/bin/ld: /tmp/ccYq0CRM.o: in function `test_task': > /home/user/Projects/hurd/gnumach/build/../tests/test-task.c:57:(.text+0

Re: Developer environment setup problem

Hi, On Mon, Jun 16, 2025 at 09:25:21PM -0700, Milos Nikic wrote: > Hello > > And inside hurd it looked like this: > > > $ cd gnumach > $ git fetch origin > $ git reset --hard origin/master > $ autoreconf -i > $ mkdir build > $ cd build > $ ../configure --host=i686-gnu CC='gcc -m32' I usually c

Re: Developer environment setup problem

Hello Thanks folks, I appreciate any help you guys can provide. Yes I used the pristine gnumach and mig. Just cloned and pulled again today. I compiled gnumach on my Linux Arch (cross compiled?). With a script from compile-scratch.sh

Re: Developer environment setup problem

Hello, On Mon, Jun 16, 2025 at 08:10:13AM -0700, Milos Nikic wrote: > Hello, > > Thanks for the email. > The thing is I am not cross compiling. I am instead compiling from inside > Hurd (in Qemu). > Yet cannot seem to get it quite right (even though it compiles > successfully inside Hurd, when I

Re: Developer environment setup problem

June 16, 2025 at 11:10 AM, "Milos Nikic" mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote: > > Hello,  > > Thanks for the email. > The thing is I am not cross compiling. I am instead compiling from inside > Hurd (in Qemu). > Yet cannot seem to get i

Re: Developer environment setup problem

Hello, Thanks for the email. The thing is I am not cross compiling. I am instead compiling from inside Hurd (in Qemu). Yet cannot seem to get it quite right (even though it compiles successfully inside Hurd, when I copy it to /boot it panics on the next reboot). Is a cross compiling route recomme

Re: Developer environment setup problem

Hi: To cross-compile gnumach from Linux you have to specify some flags in configure, to indicate the hurd architecture. You can find the flag list here: https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html Read the instructions for non-Debian systems and 64-bit, and try agai

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Hi, On Fri, Jun 13, 2025 at 12:42:53AM +, Damien Zammit wrote: > Are you sure you are giving it enough memory? For those hangs I saw, I am pretty sure. However, I had to move to the pae-enabled kernel with 4GB memory in order to make the full testsuite run reliably, it does take slightly more

Hangs in Postgres test suite (was: Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy)

Hi, changing the subject, cause this i not related to HPET anymore. On Sat, Jun 14, 2025 at 01:34:28AM +, Damien Zammit wrote: > How does it crash? Do you get a backtrace? No, it just hangs without any output. > What does it actually do during a crash? It runs the Postgres regression test

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Damien Zammit via Bug reports for the GNU Hurd, le sam. 14 juin 2025 01:34:28 +, a ecrit: > I'm glad you got it working, Michael. > (Maybe we need to update the docs to > use -M q35 option?) We rather need to fix gnumach to avoid the issue without -M q35 :) Samuel

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

I'm glad you got it working, Michael. (Maybe we need to update the docs to use -M q35 option?) How does it crash? Do you get a backtrace? What does it actually do during a crash? Can you try with a kdb enabled gnumach? Damien Sent from Proton Mail Android Original Message O

Re: GNU HURD's Clean Code – Let's Bring More Developers

Hi, I don't speak for gnu but one thing that comes to mind is that there is less code in general in the operating system because it's a microkernel model, so even drivers for hardware are not part of the core and run in userspace. I am also guilty of not adding enough documentation for the featu

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Hi, On Fri, Jun 13, 2025 at 09:42:51PM +0800, Zhaoming Luo wrote: > Do you have -M q35 with kvm command line? Thanks, that was the missing piece! It is booting fine now, and the timer resolution seems improved, it looks like the Postgres tests pass now (but the system keeps crashing on me so it

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

On Fri, Jun 13, 2025 at 03:17:41PM +0200, Michael Banck via Bug reports for the GNU Hurd wrote: > On Fri, Jun 13, 2025 at 12:42:53AM +, Damien Zammit wrote: > Ok, I did not have --disable-linux-groups yet, if I add that to the > configuration, it boots further. However, it then looks identical

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

On Fri, Jun 13, 2025 at 12:42:53AM +, Damien Zammit wrote: > Michael, > > I tried without -smp 1 flag and it still works here with UP > (--enable-apic --disable-linux-groups). Ok, I did not have --disable-linux-groups yet, if I add that to the configuration, it boots further. However, it the

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Michael, I tried without -smp 1 flag and it still works here with UP (--enable-apic --disable-linux-groups). My qemu command looks like: qemu-system-i386 -M q35,accel=kvm -m 4096 -net user,hostfwd=tcp::-:22 -net nic -display curses -hda /dev/sdd Are you sure you are giving it enough memor

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

You might need to run qemu with -smp 1 even though your gnumach is not SMP enabled, so that the acpi tables and apic works properly. I haven't tried UP with --enable-apic and no smp flag in qemu, I should try that to confirm. Damien Sent from Proton Mail Android Original Message ---

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Le 12 juin 2025 18:49:22 GMT+02:00, Michael Banck via Bug reports for the GNU Hurd a écrit : >Hi, > >On Thu, Jun 12, 2025 at 09:54:22PM +0800, Zhaoming Luo wrote: >> On Wed, Jun 11, 2025 at 09:07:10PM +0200, Michael Banck wrote: >> > On Mon, Mar 24, 2025 at 12:25:51PM +0800, Zhaoming Luo wrote: >

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Hi, On Thu, Jun 12, 2025 at 09:54:22PM +0800, Zhaoming Luo wrote: > On Wed, Jun 11, 2025 at 09:07:10PM +0200, Michael Banck wrote: > > On Mon, Mar 24, 2025 at 12:25:51PM +0800, Zhaoming Luo wrote: > > > Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64 > > > are more precise.

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

On Wed, Jun 11, 2025 at 09:07:10PM +0200, Michael Banck wrote: > Hi, Hi > > On Mon, Mar 24, 2025 at 12:25:51PM +0800, Zhaoming Luo wrote: > > Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64 > > are more precise. The highest precision can be 10ns when this patch is > > appli

Re: [PATCH mach v4 1/1] Integrate HPET so the functions used for getting time can have a higher accuracy

Hi, On Mon, Mar 24, 2025 at 12:25:51PM +0800, Zhaoming Luo wrote: > Integrate HPET so host_get_time, host_get_time64, and host_get_uptime64 > are more precise. The highest precision can be 10ns when this patch is > applied. Is there something else besides this patch that needs to be done/patched/

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Samuel Thibault, le dim. 08 juin 2025 21:57:14 +0200, a ecrit: > Diego Nieto Cid, le jeu. 29 mai 2025 23:30:58 +0100, a ecrit: > > On Tue, May 27, 2025 at 04:26:38AM +0200, Samuel Thibault wrote: > > > > > > Normally it works but possibly it got broken by some upstream change. > > > git bisect wel

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Hello, Diego Nieto Cid, le jeu. 29 mai 2025 23:30:58 +0100, a ecrit: > On Tue, May 27, 2025 at 04:26:38AM +0200, Samuel Thibault wrote: > > > > Normally it works but possibly it got broken by some upstream change. > > git bisect welcome to determine what broke it. > > > > Ok, I finally could do

Re: [util-linux FTBFS] socat hangs

Hello, On Sat, May 31, 2025 at 09:32:21PM +0100, Diego Nieto Cid wrote: > > I'll try to attach gdb to the connecting socat to see if I can find > where it's hanging. But if something rings a bell (like /dev/null usage > maybe) I'm all ears :) > I attach the gdb backtraces of the three processes

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Hello, On Tue, May 27, 2025 at 04:26:38AM +0200, Samuel Thibault wrote: > > Normally it works but possibly it got broken by some upstream change. > git bisect welcome to determine what broke it. > Ok, I finally could do a bisection for this issue and the result is the following[1]: demo@d

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Diego Nieto Cid, le mar. 27 mai 2025 03:53:20 +0100, a ecrit: > On Tue, May 27, 2025 at 02:48:47AM +0100, Diego Nieto Cid wrote: > > > > That seems to be it. I've checked out the branch relase/2.41/master and now > > make check is going further with no `Killed` output. > > > > Well, it finally fa

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Hello, On Tue, May 27, 2025 at 02:48:47AM +0100, Diego Nieto Cid wrote: > > That seems to be it. I've checked out the branch relase/2.41/master and now > make check is going further with no `Killed` output. > Well, it finally failed :( gcc -o /home/demo/dev/hurd/upstream/glibc-build/elf/tst

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Diego Nieto Cid, le mar. 27 mai 2025 02:48:47 +0100, a ecrit: > Now I'm wondering whether version 2.41 being the currently installed > package in the system makes any difference or not. No, it's not supposed to, testrun.sh is supposed to be able to fully use the build tree. Samuel

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Diego Nieto Cid, le mar. 27 mai 2025 01:38:07 +0100, a ecrit: > On Sun, May 25, 2025 at 10:26:33PM +0200, Samuel Thibault wrote: > > > > It could make a difference. Better make sure that a pristine tree works > > fine, for a start. > > > > I downloaded the latest Debian image (20250316)[1] and c

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Hello, On Tue, May 27, 2025 at 01:38:07AM +0100, Diego Nieto Cid wrote: > > Is master supposed to work or should I check some more stable branch? > That seems to be it. I've checked out the branch relase/2.41/master and now make check is going further with no `Killed` output. Now I'm wondering

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Hello, On Sun, May 25, 2025 at 10:26:33PM +0200, Samuel Thibault wrote: > > It could make a difference. Better make sure that a pristine tree works > fine, for a start. > I downloaded the latest Debian image (20250316)[1] and checked out GLIBC from Sourceware master[2] and I'm still getting the

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Diego Nieto Cid, le dim. 25 mai 2025 20:40:18 +0100, a ecrit: > > > > Perhaps you are missing the libc.so.0.3 -> libc.so symlink in your build > > directory? or elf/ld-x86-64.so.1 -> ld.so? or mach/libmachuser.so.1 -> > > libmachuser.so or hurd/libhurduser.so.0.3 -> libhurduser.so > > > > Hmm, i

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

On Sun, May 25, 2025 at 08:07:40PM +0200, Samuel Thibault wrote: > > No, it should be fine. > Ok. > > Perhaps you are missing the libc.so.0.3 -> libc.so symlink in your build > directory? or elf/ld-x86-64.so.1 -> ld.so? or mach/libmachuser.so.1 -> > libmachuser.so or hurd/libhurduser.so.0.3 ->

Re: [PATCH hurd v1] ext2fs: raise RLIMIT_AS if running as the root fs

Diego Nieto Cid, le sam. 24 mai 2025 00:18:26 +0100, a ecrit: > > > > It's much more involved than that, probably some configure flags etc. > > > > > > > > But you do not need to install it though: you can use the testrun.sh > > > > script generated by make check, to run programs with your newly-b

  1   2   3   4   5   6   7   8   9   10   >