Hello,
Damien Zammit, le mar. 22 juil. 2025 09:23:42 +, a ecrit:
> This adds a working rump driver for /dev/wmX cards,
> which are Intel i8254x Gigabit Ethernet devices.
> (See man.netbsd.org for "wm(4)")
> This should be easily extended to support other NICs
> by contributing some makefile fo
Applied, thanks!
Joan Lledó, le mar. 29 juil. 2025 17:52:44 +0200, a ecrit:
> From: Joan Lledó
>
> After DHCPRELEASE, DHCP client sends a SIOCSIFADDR to set the
> interface address to 0.0.0.0. This is not accepted by our IP
> validator `ipv4config_is_valid()`. I think this use case is legit
> so
translator validates the new IP and
considers it invalid for the previous netmask and gateway.
This patch assumes that a client trying to set the address to 0.0.0.0 or
255.255.255.255 is in fact trying to remove the IP from the interface so it
does exactly that, it sets all fields to INADDR_NONE
From: Joan Lledó
After DHCPRELEASE, DHCP client sends a SIOCSIFADDR to set the
interface address to 0.0.0.0. This is not accepted by our IP
validator `ipv4config_is_valid()`. I think this use case is legit
so this commit makes the translator accept 0.0.0.0 as a valid address.
This assumes that a
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
s, 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 h
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.
This adds a working rump driver for /dev/wmX cards,
which are Intel i8254x Gigabit Ethernet devices.
(See man.netbsd.org for "wm(4)")
This should be easily extended to support other NICs
by contributing some makefile foo to netbsd/rump.
TESTED:
- On UP+apic it works 100% with hurd-i386.
- On S
the filesystem
> remains read-only at that early point and it onl stops being readonly after
> the RPC come online.
> If is just call diskfs_node_update that early (as i do in the patch) it
> silently has no effect (!!!)
You probably just want to set diskfs_readonly = 0 while playing
ev/null` and `/dev/random`. These are
surprisingly frequent and pollute the journal. In my next patch, I’ve
implemented automatic exclusion for such inodes — they’re detected and
ignored dynamically. (no need to configure them manually).
Better use the ext3/4 native way of allocating blocks for the j
g system is structured around a single public entry point
> (journal.c, journal.h). All other components are internal to libdiskfs. The
> patch adds around 9 new .c files and several .h headers. Existing code changes
> are limited to a few hooks in strategic places.
For proper atomicity w
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;
> +}
> +
> +
This adds a working rump driver for /dev/wmX cards,
which are Intel i8254x Gigabit Ethernet devices.
(See man.netbsd.org for "wm(4)")
This should be easily extended to support other NICs
by contributing some makefile foo to netbsd/rump.
TESTED:
- On UP+apic it works 100% with hurd-i386.
- On S
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
We now have a different strategy for EOI depending on trigger mode:
For edge triggered, the behaviour is unchanged; the eoi comes
before the handler so we don't miss interrupts.
For level triggered, the eoi comes after the handler
since a high interrupt line doesn't keep triggering until it has
bee
I think we want level triggered interrupts to be handled before EOI
because we may want to set IF during the service routine to capture
nested ones and I'm not sure if the current handling of level
triggered interrupts will allow that (?)
I have split this patch in half so that the irqinfo s
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/pic.h | 6 ++
i386/i386at/ioapic.c | 27 +--
4 files changed
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 aft
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
since a high interrupt line doesn't keep triggering until it has
been eoi'd so makes sense to h
Yes you are right. I spoke with netbsd devs about this. On arm at least, they
enable interrupts before calling the handler but ack them in a different order
to calling the handler, depending on trigger mode. That is, for edge triggered,
the eoi comes before the handler so they don't miss inter
Hello,
Please check the history of this file. There has been a lot of pushing
one way and another, we need to make sure what is exactly right.
Notably, 362c84a08a1b8f1eb7f9c1c37c6ed7cece348ee4 explicitly made it
ack before calling the handler. Please check the rationale behind it,
otherwise we wil
This should ensure we don't ack nested interrupts out of order.
TESTED: On SMP this stops failure in xhci from hanging rumpnet.
When a second usb driver is executed, the second one detects a problem
and disables the uhub0 port, which breaks the first usb driver.
But this does not block rumpnet fr
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
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.
---
i386/i386at/ioapic.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/i386/i386a
---
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/ioapic.c
@@ -304,6 +304,7 @@ lapic_tmr_bit(uint8_t vec)
void
ioapic_irq_eoi(int pin)
{
+/* FI
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
Now that we have locking per apic pin, we need to
prevent usual pin maskings from stepping on EOI special masking
procedures. Also, do the lapic eoi before the ioapic eoi.
Add code for conditioning on TMR bit, but keep it disabled for now.
TESTED: on SMP and UP+apic: receives a large file over rum
rapped around
this function
to prevent the mask from being in the wrong state at any given time when
__{enable/disable}_irq is called.
I will send a new patch, see if you agree with it.
Damien
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
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 hurd-i386.
---
i386/i386/irq.c | 49 +
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
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 does
not seem necessary according to Intel SDM Vol 3, which
says an IP
This avoids race condition with multiple devices raising interrupts
simultaneously on the same IRQ and causing mask to fail.
---
i386/i386/irq.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/i386/i386/irq.c b/i386/i386/irq.c
index 91318f67..d91b385
unsubmitted
patch I have, a full SMP system can be booted and works with rumpnet as
net driver. Netdde still does not function correctly in this
configuration. The main thing is that there are no more gnumach hangs
with receiving large files with rumpnet.
I think these two changes are safe to apply as is
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
This adds a working rump driver for /dev/wmX cards,
which are Intel i8254x Gigabit Ethernet devices.
(See man.netbsd.org for "wm(4)")
TESTED:
- It seems to work 100% on UP with hurd-i386.
- On SMP it still works better than netdde but hangs gnumach
when a large file is received.
Example u
This allows top to show Cpu0 to CpuN idle stats when you press 1.
TESTED: on UP and SMP gnumach with debian hurd-i386.
---
procfs/rootdir.c | 63 ++--
1 file changed, 50 insertions(+), 13 deletions(-)
diff --git a/procfs/rootdir.c b/procfs/rootdir.c
i
---
debian/librump-dev.install | 4 +++-
debian/librump0.install| 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/debian/librump-dev.install b/debian/librump-dev.install
index 0c0f8bcb5..4c8e79a20 100644
--- a/debian/librump-dev.install
+++ b/debian/librump-dev.install
@@ -7
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.
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
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 co
rr = uhci_init(&sc->sc);
[...]
}
int
uhci_init(uhci_softc_t *sc)
{
[...]
mutex_init(&sc->sc_intr_lock, MUTEX_DEFAULT, IPL_USB);
[...]
}
For sure that will crash if an interrupt happens between
pci_intr_establish_xname and uhci_init's mutex_init.
I guess it's working
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
This provides a functional rumpdisk and rumpusbdisk
with or without static linkage of librump.
TESTED:
- opens usb stick with both dynamic and static rumpusbdisk.
- boots off ahci with static rumpdisk
---
Makeconf | 4 ++--
rumpdisk/Makefile | 18 +-
2 files changed
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:
>
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,
&
This provides support for the /dev/ud* nodes
that pass through to /dev/usbdisk, and enables
usb disk support in the installer.
UNTESTED
---
debian/hurd-udeb.install.in| 1 +
debian/hurd-udeb.lintian-overrides | 2 ++
debian/local/setup-translators | 4
debian/rules
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,
&g
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.
>
> Bette
include the missing header, fix the warning.
---
i386/intel/read_fault.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/i386/intel/read_fault.c b/i386/intel/read_fault.c
index 8ff64bbe..4a14e75d 100644
--- a/i386/intel/read_fault.c
+++ b/i386/intel/read_fault.c
@@ -30,6 +30,7 @@
#include
#
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
ould be also useful to check that trying to vm_protect the PROT_NONE
> > into PROT_ALL fails when that comes above the limit.
> >
>
> I'm tackling this test and I'm finding some trouble to implement it.
> Currently, the patch performs the calculation of PROT_NONE size
fails when that comes above the limit.
>
I'm tackling this test and I'm finding some trouble to implement it.
Currently, the patch performs the calculation of PROT_NONE size based
on the entry's max protection.
So, if I want to test for the promotion from PROT_NONE to PROT_ALL,
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
r 32-bit platforms where vm_offset_t and vm_size_t
> are typedefs of uintptr_t (i.e., unsigned int).
>
> This patch replaces those constants with 0 and UINTPTR_MAX,
> which match the expected types and avoid implicit conversion
> or overflow warnings.
>
> No functional
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
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 where vm_offset_t and vm_size_t
>>> are typedefs o
wrote:
>>
>> > 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
>> >
e vm_offset_t and vm_size_t
> > are typedefs of uintptr_t (i.e., unsigned int).
> >
> > This patch replaces those constants with 0 and UINTPTR_MAX,
> > which match the expected types and avoid implicit conversion
> > or overflow warnings.
> >
>
include the missing header, fix the warning.
---
i386/intel/read_fault.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/i386/intel/read_fault.c b/i386/intel/read_fault.c
index 8ff64bbe..c91d4e4d 100644
--- a/i386/intel/read_fault.c
+++ b/i386/intel/read_fault.c
@@ -34,6 +34,7 @@
#include
ssing 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 where vm_offset_t and vm_size_t
> are typedefs of uintptr_t (i.e., unsigned int).
>
> This patch rep
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
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 casting the phys_addr_t value to unsigned long long,
ensuring the form
., unsigned int).
This patch replaces those constants with 0 and UINTPTR_MAX,
which match the expected types and avoid implicit conversion
or overflow warnings.
No functional change.
---
vm/vm_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/vm/vm_object.c b/vm/vm_object.c
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
Compiler warns about it, and its only invoked from this file.
---
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..7db67f99 100644
--- a/i386/i386/ldt.c
+++ b/i386/i386/ldt.c
@@ -54,7 +54,7 @@ struct real_descript
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 at the top of trap.c to
satisfy the compiler and clarify the functio
; 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 default to using
> > apic even w
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
---
i386/configfrag.ac | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/i386/configfrag.ac b/i386/configfrag.ac
index 6b4eb270..92a8ed53 100644
--- a/i386/configfrag.ac
+++ b/i386/configfrag.ac
@@ -93,18 +93,18 @@ if [ x"$enable_lpr" = xyes ]; then]
[fi]
AC_ARG_ENABL
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
1 - 100 of 4295 matches
Mail list logo
