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)
> > >
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
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
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
> > > ima
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
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
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
> --
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.
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
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
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
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
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 upstre
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.
> >
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
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
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 late
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
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
Diego Nieto Cid, le ven. 23 mai 2025 00:52:57 +0100, a ecrit:
> On Thu, May 22, 2025 at 02:44:28AM +0200, Samuel Thibault wrote:
> > Diego Nieto Cid, le mer. 21 mai 2025 23:57:26 +0100, a ecrit:
> > > Now I have a few issues building GLIBC.
> > >
> > > 1. I a
Diego Nieto Cid, le mer. 21 mai 2025 23:57:26 +0100, a ecrit:
> Now I have a few issues building GLIBC.
>
> 1. I added the following checks to sysdeps/mach/configure.ac
>
> mach_RPC_CHECK(gnumach.defs, vm_set_size_limit,
>HAVE_MACH_VM_SET_SIZE_LIMIT)
> ma
Hello,
dnie...@gmail.com, le sam. 17 mai 2025 23:56:15 +0100, a ecrit:
> The ext2fs side of the changes seems to be as strightforward
> as calling setrlimit when the bootstraap port is null, given
> the following lines of diskfs_init_main:
I'm thinking that it's not just the bootstrap fs that sho
Diego Nieto Cid, le ven. 16 mai 2025 00:02:00 +0100, a ecrit:
> However, since raising the limit to the max value for the root
> filesystem is something we rather have than not, I should probably
> start looking at it.
Indeed.
> I have a question, though. Should ext2fs go through glibc setrlimit?
Hello,
Ludovic Courtès, le ven. 09 mai 2025 00:34:08 +0200, a ecrit:
> The patch below fixes that (and thus fixes the Shepherd socket
> activation, as yelninei initially reported).
Makes sense indeed, applied, thanks!
Samuel
Zhaoming Luo, le sam. 03 mai 2025 21:28:08 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when the kernel and the
> mapped_time_value structure in header file time_value.h support it.
> Otherwise step back to use the 32bit time.
Applied, thanks!
Samuel
> ---
> configure.ac
Hello,
Zhaoming Luo, le sam. 03 mai 2025 12:49:56 +0800, a ecrit:
> Use 64bit mapped time values in maptime_read when possible. The 64bit
> time values in mapped time will be zero when the kernel does not support
> 64bit mapped time.
> + if (mtime->time_value.seconds == 0)
Please add
AC_CHECK_
Zhaoming Luo, le sam. 03 mai 2025 08:30:10 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:21:31AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> > > On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > > >
Zhaoming Luo, le sam. 03 mai 2025 08:17:52 +0800, a ecrit:
> On Sat, May 03, 2025 at 02:10:12AM +0200, Samuel Thibault wrote:
> > Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> > > Get the time with higher resolution from kernel using host_get_time64()
&
Zhaoming Luo, le ven. 02 mai 2025 22:45:44 +0800, a ecrit:
> Get the time with higher resolution from kernel using host_get_time64()
> when possible.
It seems there's a misunderstanding. I explained that the mapped time
does have 64bit precision fields, that's what I mean we want to use,
rather th
Zhaoming Luo, le ven. 02 mai 2025 18:52:49 +0800, a ecrit:
> I'm wondering if I should consider the case that host_get_time64() is not
> supported
Yes, please.
I wonder how many times I will have to repeat it: backward compatibility
is really important, otherwise people can't try to downgrade ker
Zhaoming Luo, le jeu. 01 mai 2025 18:13:46 +0800, a ecrit:
> We can have better resolution now so this comment can be removed.
Applied, thanks!
Samuel
> ---
> include/mach/time_value.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/mach/time_value.h b/include/
Zhaoming Luo, le mar. 29 avril 2025 17:21:05 +0800, a ecrit:
> On Tue, Apr 29, 2025 at 09:51:25AM +0200, Samuel Thibault wrote:
> >
> > What is more concerning is:
> >
> > piixide0:0:0: lost interrupt
> >
> > So the user-level interrupt mechanism should be
Zhaoming Luo, le mar. 29 avril 2025 11:06:47 +0800, a ecrit:
> On Tue, Apr 29, 2025 at 02:19:30AM +, Damien Zammit wrote:
> > Hi, this is very interesting and probably indicating that we need to fix
> > race between previous servers starting up and next ones, as you mentioned.
I don't think i
Ludovic Courtès, le lun. 21 avril 2025 16:59:03 +0200, a ecrit:
> Samuel Thibault writes:
> > dev_read starts with if (err) return err;. Various functions do not
> > define their own err variable. I don't know the original reason for
> > this, but this looks fishy
Ludovic Courtès, le lun. 21 avril 2025 00:59:00 +0200, a ecrit:
> Samuel Thibault writes:
>
> > Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit:
> >> What happens here is that reading from /dev/klog (opened with
> >> O_NONBLOCK) returns ED_WOULD
Hello,
Ludovic Courtès, le dim. 20 avril 2025 17:40:02 +0200, a ecrit:
> What happens here is that reading from /dev/klog (opened with
> O_NONBLOCK) returns ED_WOULD_BLOCK. However Guile and its concurrency
> framework (Fibers) don’t know about this error, hence the (non-fatal)
> backtrace, but t
Hello,
So it works as your additional test shows, but it is fragile.
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn.c
Hello,
yelninei--- via Bug reports for the GNU Hurd, le ven. 18 avril 2025 14:42:03
+0200, a ecrit:
> client = accept(fd, NULL, NULL);
> if (client < 0) return 1;
> fprintf(stderr, "Accepting connection\n");
> if ((fcntl(client, F_GETFL) & O_NONBLOCK) != 0)
> {
> fprintf
Hello
I fixed these and pushed it, thanks so much!
Samuel
Samuel Thibault, le ven. 11 avril 2025 02:27:04 +0200, a ecrit:
> Hello,
>
> Sorry it took me long to manage to fine time to look at this...
>
> Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> > diff
Samuel Thibault, le jeu. 17 avril 2025 23:31:50 +0200, a ecrit:
> Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> > I haven't tested this patch again some stress tests as I don't know why
> > the `dpkg-buildpackage -B` on my qemu got stuck at:
> >
Hello,
Zhaoming Luo, le lun. 10 mars 2025 16:44:09 +0800, a ecrit:
> I haven't tested this patch again some stress tests as I don't know why
> the `dpkg-buildpackage -B` on my qemu got stuck at:
>
> ```
> ...
> ../scripts/evaluate-test.sh stdio-common/scanf14 $? false false >
> /home/1speaker/ap
Hello,
Sorry it took me long to manage to fine time to look at this...
Luca Dariz, le mer. 19 mars 2025 18:11:18 +0100, a ecrit:
> diff --git a/sysdeps/mach/hurd/i386/sigreturn.c
> b/sysdeps/mach/hurd/i386/sigreturn.c
> index ce8df8d02b..618cb74196 100644
> --- a/sysdeps/mach/hurd/i386/sigreturn
Zhaoming Luo, le jeu. 10 avril 2025 20:20:26 +0800, a ecrit:
> The option -M q35 is needed when trying rumpdisk in qemu
It would be useful to track down why, and fix the issue :)
Samuel
> ---
> hurd/rump/rumpdisk.mdwn | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/hurd/rump/
Applied, thanks!
Zhaoming Luo, le jeu. 10 avril 2025 08:55:49 +0800, a ecrit:
> ---
> hurd/running/debian/qemu_image.mdwn | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/running/debian/qemu_image.mdwn
> b/hurd/running/debian/qemu_image.mdwn
> index 9984ac33..8409bc
Applied, thanks!
Etienne Brateau, le lun. 07 avril 2025 22:11:26 +0200, a ecrit:
> ---
> i386/i386/trap.c| 4 ++--
> i386/intel/pmap.c | 4 ++--
> i386/intel/read_fault.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/i386/i386/trap.c b/i386/i386/trap.c
Hello,
Hakan Candar, le sam. 05 avril 2025 13:40:01 +, a ecrit:
> I’ve been working on getting GNU Mach to compile on riscv64,
Nice :)
I don't remember if somebody did some work about this.
> Separately, I created a `riscv64-none-gnu` target for GCC and created the
> necessary backend confi
Zhaoming Luo, le jeu. 03 avril 2025 12:42:19 +0800, a ecrit:
> This is done.
Applied, thanks!
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contributing.mdwn b/contributing.mdwn
> index d79388ab..c9ce3c6a 100644
> --- a/contributing.mdwn
> +++ b/contributing.
Applied, thanks!
Zhaoming Luo, le mer. 02 avril 2025 17:23:54 +0800, a ecrit:
> ---
> hurd/io.defs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hurd/io.defs b/hurd/io.defs
> index 5bc399ed..4c63de36 100644
> --- a/hurd/io.defs
> +++ b/hurd/io.defs
> @@ -46,7 +46,7 @@
Applied, thanks!
Zhaoming Luo, le mer. 26 mars 2025 12:06:08 +0800, a ecrit:
> This is done.
> See:
> https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=6d91c78f0c240e3c7d81e19e85507e0aec580d6f
>
> ---
> contributing.mdwn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/contri
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 12:25:51 +0800, a ecrit:
> 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.
>
> * i386/i386/apic.c: Implement the two high-precision clock
Applied, thanks!
Zhaoming Luo, le lun. 24 mars 2025 13:20:42 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available. Fall back to
> host_get_time if gnumach does not support host_get_time64 but the
> gnumach headers
Zhaoming Luo, le dim. 23 mars 2025 10:47:14 +0800, a ecrit:
> Check the availability of host_get_time64 and use it to replace
> host_get_time for CLOCK_REALTIME when it's available.
> case CLOCK_REALTIME:
>{
> - /* __host_get_time can only fail if passed an invalid host_t.
> +
Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 10:20:37
+, a ecrit:
> You probably want to disable it entirely so it doesn't need to execute a
> branch condition every time it reads the timer, ie with #ifdef.
The if is precisely meant for the case where hpet is not avai
Hello,
Almost there!
Samuel
Zhaoming Luo, le dim. 23 mars 2025 18:13:55 +0800, a ecrit:
> +uint32_t
> +hpclock_get_counter_period_nsec(void)
> +{
> +if (hpet_addr != NULL)
> + return hpet_period_nsec;
> +else
> + return 0;
When hpet_addr is NULL, hpet_period_nsec will already be
Damien Zammit via Bug reports for the GNU Hurd, le dim. 23 mars 2025 08:22:23
+, a ecrit:
> I think we are assuming any machine with ACPI has HPET. This is true since
> ~2005.
Yes, but we currently still support the non-APIC case too.
Samuel
Zhaoming Luo, le dim. 23 mars 2025 13:29:47 +0800, a ecrit:
> On Sun, Mar 23, 2025 at 12:48:52AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> >
> > > diff --git a/i386/i386at/model_dep.c b/i386/i386at/model_dep.c
> &
Hello,
Zhaoming Luo, le dim. 23 mars 2025 09:50:33 +0800, a ecrit:
> Use the host_get_time64 to replace the deprecated host_get_time for
> CLOCK_REALTIME.
host_get_time64 is not always available, not with older gnumach. Please
use #if machinery like above in the monotonic case.
In general, pleas
Hello,
Zhaoming Luo, le sam. 22 mars 2025 15:24:50 +0800, a ecrit:
> The HPET counter is read once in every clock interrupt. When any of the
> functions used for getting time is used, the HPET counter is read again and
> the difference between these two read is multiplied by the HPET period
> and
Hello,
While at it, we'd better also fix sysdeps/mach/hurd/dup3.c the exact
same way (which will also fix dup2).
Thanks,
Samuel
Zhaoming Luo, le jeu. 06 mars 2025 06:39:04 +0800, a ecrit:
> Ignoring the return value of mach_port_mod_ref() causes the situation
> + if (err)
> +
Zhaoming Luo, le mer. 05 mars 2025 20:07:56 +0800, a ecrit:
> On Wed, Mar 05, 2025 at 12:38:39PM +0100, Samuel Thibault wrote:
> > Hello,
>
> Thanks for the quick reply.
> >
> > Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> > > - Run 'a
Hello,
Zhaoming Luo, le mer. 05 mars 2025 19:25:15 +0800, a ecrit:
> - Run 'apt source glibc', use quilt to apply this patch and build
> the libc package using `dpkg-buildpackage -B`. I got the same error as
> [0].
>
> [0]:
> https://buildd.debian.org/status/fetch.php?pkg=glibc&arch=hurd-i38
Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit:
> Test 537 on Hurd opens 0x4 file discriptors and close them[0].
The code is really odd.
if(nitems > 0x7fff)
nitems = 0x4;
I would have rather understood
if(nitems > 0x7fff)
nitems = 0x8000;
which will happ
Zhaoming Luo, le lun. 03 mars 2025 19:35:37 +0800, a ecrit:
> a dup() is executed[4]. The code line of [4] I think is where the issue
> is. We ignored return value of __mach_port_mod_refs(). In this case we
> indeed reached the limit of reference count[5],
Oops :)
This should indeed be fixed into
Zhaoming Luo, le sam. 01 mars 2025 19:06:52 +0800, a ecrit:
> It checks for the total time of requesting a page under http
> protocol[0][1]. More than 0 is needed.
>
> It's just too fast and our GNU Mach clock is not accurate enough:
Ah :/
> Maybe adding the support of high accuracy clock in GNU
Zhaoming Luo, le ven. 28 févr. 2025 20:42:41 +0800, a ecrit:
> I have applied the code and make test.
[...]
> I think you can commit the code.
Ok, done so, thanks!
> I could only see two failed tests now. Test 537 is a stress test and
> it got stuck and outputing a lot of 'Deallocating a bogus po
Hello,
Nice investigation!
Zhaoming Luo, le jeu. 27 févr. 2025 10:37:36 +0800, a ecrit:
> It means that pthread_hurd_cond_timedwait_np() successes but
> current->signal is still 1. I assume current->signal will only be
> modified to 1 when pthread_hurd_cond_timedwait_np() returns EINTR. Maybe
> w
Zhaoming Luo, le jeu. 27 févr. 2025 08:23:16 +0800, a ecrit:
> On Tue, Feb 25, 2025 at 08:28:34PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> > > The program './runtests.pl -g 546' stopped at [0] several times bef
Hello,
Zhaoming Luo, le mar. 25 févr. 2025 21:14:14 +0800, a ecrit:
> The program './runtests.pl -g 546' stopped at [0] several times before
> the test is really running, so I think some preparations involved
> io_select_common. However, after the test is running, I set a breakpoint
> at [1](it's
Hello,
Zhaoming Luo, le sam. 22 févr. 2025 14:27:07 +0800, a ecrit:
> This is not completed, but I would to confirm whether I have
> understanded the code.
Yes, this is the idea.
> Then we use 'machdev_trivfs_init ()' to init it so ext2fs can use
> device_open('hd0s1'); the following stuff it is
Samuel Thibault, le sam. 22 févr. 2025 15:33:27 +0100, a ecrit:
> Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> > The pciutils package is failing to build in Debian on hurd-amd64:
> >
> >
> > https://buildd.debian.org/status/fetch.php?pkg=pci
Guillem Jover, le sam. 22 févr. 2025 14:09:59 +0100, a ecrit:
> The pciutils package is failing to build in Debian on hurd-amd64:
>
>
> https://buildd.debian.org/status/fetch.php?pkg=pciutils&arch=hurd-amd64&ver=1%3A3.13.0-1%2Bb1&stamp=1732538417&raw=0
>
> The error is the following:
>
> ,---
Zhaoming Luo, le sam. 22 févr. 2025 21:06:18 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 02:01:58PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit:
> > > On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote:
> > >
Zhaoming Luo, le sam. 22 févr. 2025 20:59:53 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 01:07:40PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit:
> > > On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote:
> > >
Zhaoming Luo, le sam. 22 févr. 2025 20:03:12 +0800, a ecrit:
> On Sat, Feb 22, 2025 at 12:47:16PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit:
> > > lib533.c:96 select() failed, with errno 1073741828 (Interrupted system
> &g
Hello,
Zhaoming Luo, le sam. 22 févr. 2025 19:29:55 +0800, a ecrit:
> lib533.c:96 select() failed, with errno 1073741828 (Interrupted system call)
This is expected if the test handles a signal. Does it indeed set up a
signal handler and get a signal?
Samuel
Zhaoming Luo, le lun. 17 févr. 2025 12:21:53 +0800, a ecrit:
> On Sun, Feb 16, 2025 at 10:30:17AM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit:
> > > In the test[0] of vim. I think the issue is that th
Zhaoming Luo, le lun. 17 févr. 2025 10:16:42 +0800, a ecrit:
> On Sun, Feb 16, 2025 at 10:39:42AM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit:
> > > In test_filechanged.vim, those three parts are the sources of fail:
> > >
Hello,
Zhaoming Luo, le lun. 17 févr. 2025 09:14:13 +0800, a ecrit:
> This is what I have done to try to open the storeio translator in
> ext2fs, like what's mentioned in the TODO list.
> ```
>error_t err;
>mach_port_t bootstrap;
>
> - /* Initialize the diskfs library, parse arguments, a
Zhaoming Luo, le dim. 16 févr. 2025 16:22:01 +0800, a ecrit:
> In test_filechanged.vim, those three parts are the sources of fail:
>
> https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L15-L18
> https://github.com/vim/vim/blob/master/src/testdir/test_filechanged.vim#L57-L60
>
Hello,
Zhaoming Luo, le dim. 16 févr. 2025 15:59:41 +0800, a ecrit:
> In the test[0] of vim. I think the issue is that the sleep time is not
> long enough. Sleep for 200ms is possible to pass the test, though the
> possibility is not that high. I think sleep for 2 seconds might be a
> good option.
Samuel Thibault, le lun. 10 févr. 2025 13:57:46 +0100, a ecrit:
> Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> > * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> > extern since they are used in another module (icmp.c) and shouldn
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:38:26 -0500, a ecrit:
> ---
> server.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/server.c b/server.c
> index 8da231c..9d25573 100644
> --- a/server.c
> +++ b/server.c
> @@ -766,6 +766,14 @@ WriteExtractArg(FILE *file,
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:56 -0500, a ecrit:
> ---
> mach/mig_strncpy.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/mach/mig_strncpy.c b/mach/mig_strncpy.c
> index b0c001d775..dbd0a08e56 100644
> --- a/mach/mig_strncpy.c
> ++
Applied, thanks!
Flavio Cruz, le dim. 09 févr. 2025 22:37:13 -0500, a ecrit:
> ---
> kern/ipc_mig.c | 25 +
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/kern/ipc_mig.c b/kern/ipc_mig.c
> index 18ac88ef..b6543703 100644
> --- a/kern/ipc_mig.c
> +++
Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> extern since they are used in another module (icmp.c) and shouldn't be
> removed.
> diff --git a/pfinet/linux-src/net/ipv4/tcp_ipv4.c
> b/pfinet/linux-src/net
Applied, thanks!
Zhaoming Luo, le sam. 08 févr. 2025 18:32:20 +0800, a ecrit:
> The term_getctty() should accept pty_class
>
> See
> https://mail.gnu.org/archive/html/bug-hurd/2025-02/msg00061.html
>
> * term/users.c: The term_getctty() accepts pty_class
> ---
> term/users.c | 2 +-
> 1 file ch
Zhaoming Luo, le sam. 08 févr. 2025 12:51:04 +0800, a ecrit:
> On Sat, Feb 08, 2025 at 08:55:31AM +0800, Zhaoming Luo wrote:
> > On Fri, Feb 07, 2025 at 01:57:01PM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> > > &
Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
> I know this is due to the way of our kernel to handle file and memory.
> Do we have a good way to fix this,
Not a trivial way. It'd need adding names to the kernel map entries, and
setting them from mmap() and such functions that map fi
Zhaoming Luo, le ven. 07 févr. 2025 18:44:50 +0800, a ecrit:
> This is V2 of figuring out the issue. V1 is abandoned due to my mistake,
> but this time I can confirm the source of issue. This time I ran
> rpctrace directly on vim, and used two printfs to locate the isatty().
>
> ```
> printf ("Sta
Zhaoming Luo, le jeu. 06 févr. 2025 10:54:30 +0800, a ecrit:
> Though I don't know why gdb tells me it uses the implementation in
> $(glibc)/unix/bsd/getpt.c. Is it expected?
Yes, if you git grep you will see that there are only login/getpt.c
(dumb), sysdeps/unix/sysv/linux/getpt.c (linux-specific
Zhaoming Luo, le jeu. 06 févr. 2025 11:11:42 +0800, a ecrit:
> On Thu, Feb 06, 2025 at 10:54:30AM +0800, Zhaoming Luo wrote:
> > On Thu, Feb 06, 2025 at 02:03:26AM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit:
> > > >
Zhaoming Luo, le mer. 05 févr. 2025 09:03:49 +0800, a ecrit:
> Please have a look, I hope the semantics are correct :).
That looks alright indeed!
Thanks,
Samuel
> ---
> runtime/doc/builtin.txt| 1 +
> src/evalfunc.c | 9 -
> src/testdir/test_functions.vim | 2 ++
Zhaoming Luo, le mer. 05 févr. 2025 10:33:04 +0800, a ecrit:
> On Tue, Feb 04, 2025 at 09:12:18AM +0100, Samuel Thibault wrote:
> > Only out_io and err_io are supposed to be readable. Or did they mean
> > from the point of view of the executed process. Again, it means check
&
Yuqian Yang, le mer. 05 févr. 2025 02:04:47 +0800, a ecrit:
> I tried many cases. qemu-kvm never reproduced however I tried.
>
> I get a working one in VirtualBox by not pushing enter immediately
> after grub is installed and it prompts me to reboot. So I guess
> the problem is indeed that the fil
1 - 100 of 2429 matches
Mail list logo
