Hello,
Milos Nikic, le jeu. 24 juil. 2025 12:03:56 -0700, a ecrit:
> 3. Spammy device nodes (/dev/random, /dev/null, etc.)
>
> These nodes are not just noisy in atime updates — they also frequently change
> mtime and ctime.
I don't see why they should. It's the translator sitting on them that
wo
>
> > That’s the trick: the issue isn’t how, but *when*.
> > The journal contains information from before the crash, but after
> reboot, we’re
> > walking a post-crash live filesystem. If we try to resolve inode paths
> at boot,
> > we might end up with mismatche
Hey Joshua,
Thank you so much for the kind words, I appreciate it a lot.
As for the donation, I don't think there is a need.
Thanks again,
Milos
On Tue, Jul 22, 2025 at 7:25 AM wrote:
> July 21, 2025 at 2:38 PM, "Milos Nikic" nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gma
July 21, 2025 at 2:38 PM, "Milos Nikic" mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E
> wrote:
>
> Hello,
>
> Thank you for the detailed review — I really appreciate the time and care
> you’ve put into this. I’ve signed and sent the copyright assignment.
nd up with mismatches, or restoring paths that no longer make sense.
But the journal is supposed to be in an order that makes sense
sequentially. Again, better check how ext3/4/jbd are doing it, rather
than trying to re-invent them.
> One additional note: while testing i have discovered that
Hello,
Thank you for the detailed review — I really appreciate the time and care
you’ve put into this. I’ve signed and sent the copyright assignment.
> But did you trash to hard-reboot your system during disk load, replay,
> hard-reboot during load, replay, etc. ? :)
Yes, I’ve been doing just t
Hello,
Thanks for the update on this.
Milos Nikic, le ven. 18 juil. 2025 16:00:19 -0700, a ecrit:
> I'm now using this system routinely without issues,
But did you trash to hard-reboot your system during disk load, replay,
hard-reboot during load, replay, etc. ? :)
> The journaling system is st
Damien Zammit, le dim. 20 juil. 2025 11:20:33 +, a ecrit:
> Hi,
>
> Original Message
> On 20/7/25 8:54 pm, Samuel Thibault wrote:
>
> > > Set Receive Timeout is required.
> > >
> > > The immediate flag makes it begin filling the bpf buffer without any
> > delay. But wi
Hi,
Original Message
On 20/7/25 8:54 pm, Samuel Thibault wrote:
> > Set Receive Timeout is required.
> >
> > The immediate flag makes it begin filling the bpf buffer without any
> delay. But without the timeout set, a pending blocking read will never
> return until the wh
Damien Zammit, le dim. 20 juil. 2025 10:34:16 +, a ecrit:
> Original Message
> > Damien Zammit, le dim. 20 juil. 2025 02:49:16 +, a ecrit:
> > > + flag = 0;
> > > + err = rump_sys_ioctl (nd->bpf_fd, BIOCIMMEDIATE, &flag);
> > > + if (err < 0)
> > > +{
> > > +
Hi Samuel,
Original Message
On 20/7/25 7:43 pm, Samuel Thibault wrote:
> Damien Zammit, le dim. 20 juil. 2025 02:49:16 +, a ecrit:
> > + flag = 0;
> > + err = rump_sys_ioctl (nd->bpf_fd, BIOCIMMEDIATE, &flag);
> > + if (err < 0)
> > +{
> > + mach_print("ER
Damien Zammit, le dim. 20 juil. 2025 02:49:16 +, a ecrit:
> + flag = 0;
> + err = rump_sys_ioctl (nd->bpf_fd, BIOCIMMEDIATE, &flag);
> + if (err < 0)
> +{
> + mach_print("ERROR: biocimmediate failed\n");
> + errno = rump_errno2host(err);
> + return errno;
> +}
> +
> +
Samuel Thibault, le ven. 18 juil. 2025 21:53:29 +0200, a ecrit:
> > TODO: We still need to work out a strategy to have interrupts enabled
> > during the handler, so that nested interrupts that occur via code that
> > is executed inside the irq handler to make the device raise a new
> > interrupt, a
Applied, thanks!
Damien Zammit, le sam. 19 juil. 2025 06:41:44 +, a ecrit:
> Avoid reading the ioapic registers for vector and trigger mode,
> by introducing an O(1) memory lookup for these properties.
> ---
> i386/i386/apic.h | 6 ++
> i386/i386/pic.c | 5 +
> i386/i386/pi
Hello,
Please do test without apic too, your change currently breaks it.
This also needs to update the comment above irq_acknowledge().
Damien Zammit, le ven. 18 juil. 2025 11:13:01 +, a ecrit:
> We now have a different strategy for EOI depending on trigger mode:
> For edge triggered, the eo
TESTED: netdde works on smp with this patch
On 7/18/25 9:13 PM, Damien Zammit wrote:
> We now have a different strategy for EOI depending on trigger mode:
> For edge triggered, the eoi comes before the handler so we don't
> miss interrupts. For level triggered, the eoi comes after the handler
> s
s exactly right.
> Notably, 362c84a08a1b8f1eb7f9c1c37c6ed7cece348ee4 explicitly made it
> ack before calling the handler. Please check the rationale behind it,
> otherwise we will just re-open bugs that were previously fixed and we
> are not actually making progress.
>
> Samuel
>
> Damien Za
will just re-open bugs that were previously fixed and we
are not actually making progress.
Samuel
Damien Zammit, le jeu. 17 juil. 2025 09:20:44 +, a ecrit:
> This should ensure we don't ack nested interrupts out of order.
>
> TESTED: On SMP this stops failure in xhci from h
Hello,
It seems that the Linux glue does not like APIC for the moment, so I
have changed this into enabling by default only when the Linux glue is
disabled.
Samuel
Damien Zammit, le lun. 23 juin 2025 01:30:11 +, a ecrit:
> ---
> i386/configfrag.ac | 8
> 1 file changed, 4 insertion
Damien Zammit, le sam. 12 juil. 2025 12:34:44 +, a ecrit:
> This code may be needed in the future, so add it in now
> but keep it disabled. The special EOI handling for
> interrupts may only need to be done for one kind of trigger mode.
Applied, thanks!
> ---
> i386/i386at/ioapic.c | 19 +++
Applied, thanks!
Damien Zammit, le sam. 12 juil. 2025 12:34:23 +, a ecrit:
> ---
> i386/i386at/ioapic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/i386/i386at/ioapic.c b/i386/i386at/ioapic.c
> index 85359664..465a9f3b 100644
> --- a/i386/i386at/ioapic.c
> +++ b/i386/i386at/ioap
Damien Zammit, le sam. 12 juil. 2025 11:30:01 +, a ecrit:
> Also, do the lapic eoi before the ioapic eoi.
Why?
> Add code for conditioning on TMR bit, but keep it disabled for now.
>
> TESTED: on SMP and UP+apic: receives a large file over rumpnet.
>
> ---
> i386/i386/irq.c | 23 +
Damien Zammit, le sam. 12 juil. 2025 11:05:59 +, a ecrit:
> On 7/12/25 8:21 PM, Samuel Thibault wrote:
> > This is the locking for the management of ndisabled and calling
> > mask/unmask only.
>
> Yes, correct, however inside the ioapic_irq_eoi() function we are
> masking/unmasking again,
Bu
Hi Samuel,
On 7/12/25 8:21 PM, Samuel Thibault wrote:
> This is the locking for the management of ndisabled and calling
> mask/unmask only.
Yes, correct, however inside the ioapic_irq_eoi() function we are
masking/unmasking again,
so I think we need to protect the mask per irq as well wrapped ar
Hello,
Just a quick skim over it.
Damien Zammit, le lun. 07 juil. 2025 09:26:54 +, a ecrit:
> +int
> +main (int argc, char **argv)
> +{
> +
> + /* Make sure we will not swap out,
> + * because dma buffers for net drivers don't work otherwise */
> + err = wire_task_self ();
> + if (err)
Damien Zammit, le sam. 12 juil. 2025 09:49:06 +, a ecrit:
> On 7/11/25 4:56 PM, Damien Zammit wrote:
> > This avoids race condition with multiple devices raising interrupts
> > simultaneously on the same IRQ and causing mask to fail.
>
> If we add locking per apic pin,
This is the locking for
Damien Zammit, le ven. 11 juil. 2025 06:56:30 +, a ecrit:
> This avoids race condition with multiple devices raising interrupts
> simultaneously on the same IRQ and causing mask to fail.
>
> TESTED: on SMP and UP+apic gnumach, boots to console and receives
> a large file over rumpnet on debian
Hi,
On 7/11/25 4:56 PM, Damien Zammit wrote:
> This avoids race condition with multiple devices raising interrupts
> simultaneously on the same IRQ and causing mask to fail.
If we add locking per apic pin, we need to lock in EOI as well.
I have been testing a patch locally here but it has introd
Hello,
Damien Zammit, le jeu. 10 juil. 2025 10:14:21 +, a ecrit:
> This avoids race condition with multiple devices raising interrupts
> simultaneously on the same IRQ and causing mask to fail.
Are we *sure* that PCI interrupts may get raised on several cpus
concurrently ? It makes the race g
Damien Zammit, le jeu. 10 juil. 2025 10:14:13 +, a ecrit:
> We need to wait first for pending to clear before sending
> the IPI assert signal. Likewise, if we always do it this
> way, we don't need to wait for pending to clear afterward
> because next time we will wait again anyway. Deassert
Damien Zammit, le lun. 07 juil. 2025 09:25:35 +, a ecrit:
> This allows top to show Cpu0 to CpuN idle stats when you press 1.
>
> TESTED: on UP and SMP gnumach with debian hurd-i386.
Applied, thanks!
> ---
> procfs/rootdir.c | 63 ++--
> 1 file ch
Hello,
Milos Nikic, le jeu. 03 juil. 2025 08:40:43 -0700, a ecrit:
> The goal is to capture metadata changes very early in the boot process —
> ideally even before fsck — and flush them to a raw device (backed by a file or
> similar) synchronously (i.e. the calling thread waits for the result of t
On 4/07/25 03:40, Milos Nikic wrote:
Hi all,
I’m working on a user-space metadata journaling layer for libdiskfs and
have run into a boot-time issue I hope to get guidance on.
The goal is to capture metadata changes very early in the boot process —
ideally even before fsck — and flush them t
Milos Nikic, le mer. 02 juil. 2025 18:25:11 -0700, a ecrit:
> Thank you for sharing your thoughts on real-time support
Not real-time, relatime :)
(relative atime)
It really saves a *lot* of utime updates.
Samuel
Hello,
Thank you for sharing your thoughts on real-time support — it’s helpful to
understand the broader direction, and I’ll certainly take that into account
as development progresses.
Regarding EXT4, after some investigation, it appears there are limitations
in how much we can adopt from their a
Milos Nikic, le mer. 02 juil. 2025 09:01:04 -0700, a ecrit:
> The async path came first because I noticed that the vast majority (90%+) of
> generated events were utime updates.
We want to add relatime support :)
> These seem well-suited to periodic async flushing (every few hundred
> millisecond
Hi,
You're right — the asynchronous producer-consumer model isn't sufficient on
its own for all use cases. I’ll be adding a synchronous write path next to
ensure durability for critical operations.
The async path came first because I noticed that the vast majority (90%+)
of generated events were
Milos Nikic, le mar. 01 juil. 2025 21:32:19 -0700, a ecrit:
> The current version uses an asynchronous producer-consumer model with a
> ring-buffer queue and a dedicated flusher thread.
Mmm, is that really how it can work? AIUI journalling first makes sure
the journal is written before making some
Hi,
Thanks again for the earlier feedback — I’ve applied the style corrections
and, since then, have rewritten the system a few times from the ground up.
The current version uses an asynchronous producer-consumer model with a
ring-buffer queue and a dedicated flusher thread. (it also synchounosly
On 7/2/25 7:54 AM, Samuel Thibault wrote:
> Possibly the interrupt and the driver thread are stupidly competing for
> the spinlock.
>
We could try compiling rump with RUMP_LOCKS_UP
and keep the setting RUMP_NCPU=1.
We also need to figure out why running with
RUMP_NCPU=2 fails to open random init.
Hello,
Milos Nikic, le jeu. 26 juin 2025 23:40:22 -0700, a ecrit:
> diff --git a/ext2fs/inode.c b/ext2fs/inode.c
> index dc309ac8..a3560630 100644
> --- a/ext2fs/inode.c
> +++ b/ext2fs/inode.c
> /* these flags aren't actually defined by a header file yet, so temporarily
> disable them if nece
Samuel Thibault, le mar. 01 juil. 2025 23:45:05 +0200, a ecrit:
> Samuel Thibault, le mar. 01 juil. 2025 23:26:38 +0200, a ecrit:
> > I guess it's working on BSD only by luck because mutex_init() is mostly
> > no-op... I'll add a patch for this which seems to work for me
>
> It's *very* slow, thou
Samuel Thibault, le mar. 01 juil. 2025 23:26:38 +0200, a ecrit:
> I guess it's working on BSD only by luck because mutex_init() is mostly
> no-op... I'll add a patch for this which seems to work for me
It's *very* slow, though...
# dd < /dev/ud0 > /dev/null bs=64K count=10
10+0 records in
10+0 re
Samuel Thibault, le mar. 01 juil. 2025 22:20:52 +0200, a ecrit:
> Samuel Thibault, le mar. 01 juil. 2025 22:09:27 +0200, a ecrit:
> > Samuel Thibault, le mar. 01 juil. 2025 21:32:23 +0200, a ecrit:
> > > Damien Zammit, le mar. 01 juil. 2025 14:16:27 +, a ecrit:
> > > > This provides a functiona
Samuel Thibault, le mar. 01 juil. 2025 22:09:27 +0200, a ecrit:
> Samuel Thibault, le mar. 01 juil. 2025 21:32:23 +0200, a ecrit:
> > Damien Zammit, le mar. 01 juil. 2025 14:16:27 +, a ecrit:
> > > This provides a functional rumpdisk and rumpusbdisk
> > > with or without static linkage of libru
Samuel Thibault, le mar. 01 juil. 2025 21:32:23 +0200, a ecrit:
> Damien Zammit, le mar. 01 juil. 2025 14:16:27 +, a ecrit:
> > This provides a functional rumpdisk and rumpusbdisk
> > with or without static linkage of librump.
>
> Great :) applied, thanks!
>
> > TESTED:
> > - opens usb stic
Damien Zammit, le mar. 01 juil. 2025 14:16:27 +, a ecrit:
> This provides a functional rumpdisk and rumpusbdisk
> with or without static linkage of librump.
Great :) applied, thanks!
> TESTED:
> - opens usb stick with both dynamic and static rumpusbdisk.
I'm still getting issues with rumpu
No, I believe separating the stack is worthwhile at this point because if you
link less modules in the usb driver, we can narrow the problem down to less
code, ie is the problem in the hc or in the peripheral driver?
I already made it crash without umass or scsipi modules linked so I think the
Damien Zammit, le lun. 30 juin 2025 03:55:11 +, a ecrit:
> I wanted to move things along for usb, I didn't realise the driver is
> actually broken on master.
>
> I'll have another go at separating the stack.
I don't think it's a problem of stack separation. Trying to separate
things into sev
I wanted to move things along for usb, I didn't realise the driver is actually
broken on master.
I'll have another go at separating the stack.
Damien
Sent from Proton Mail Android
Original Message
On 30/6/25 8:14 am, Samuel Thibault wrote:
> Hello,
>
> Damien Zammit, l
Hello,
Damien Zammit, le ven. 27 juin 2025 06:41:53 +, a ecrit:
> This provides support for the /dev/ud* nodes
> that pass through to /dev/usbdisk, and enables
> usb disk support in the installer.
>
> UNTESTED
Please do test changes.
Writing changes that look reasonable is not what would co
Hello,
Diego Nieto Cid, le sam. 28 juin 2025 23:31:45 +0100, a ecrit:
> 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) {
>
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);
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.
>
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 <
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
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
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
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
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
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
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
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
>
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
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:
> >
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.
> >
> >
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
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
1 - 100 of 4195 matches
Mail list logo
