Applied, thanks!
Janneke Nieuwenhuizen, le ven. 26 mai 2023 19:46:44 +0200, a ecrit:
> (It's a bit weird that when using gnumach's builtin networking using
> eth0 or dev/eth0 was inconsequential).
pfinet tries both to open as file path and as gnumach device. It happens
that netdde forwards to gnumach's eth0 when
Janneke Nieuwenhuizen, le ven. 26 mai 2023 19:19:02 +0200, a ecrit:
> --8<---cut here---start->8---
> # settrans --active --create --keep-active /servers/socket/2 /hurd/pfinet \
> --ipv6=/servers/socket/26 --interface=eth0 --address=10.0.2.15 \
This needs to
Janneke Nieuwenhuizen, le ven. 26 mai 2023 19:32:01 +0200, a ecrit:
> Samuel Thibault writes:
>
> > Janneke Nieuwenhuizen, le ven. 26 mai 2023 17:42:49 +0200, a ecrit:
> >> Now that rumpdisk works in Guix we need netdde. Trying to build netdde
> >> I need the attached patch. I'm wondering how
On Fri, May 26, 2023 at 7:22 PM Samuel Thibault wrote:
> I.e. gnumach without optimizations gets things wrong. We do want to fix
> that :)
Dumping what I've been able to debug (so far):
The crash indeed happens when loading the executable image, inside
copyout (). The addresses/sizes are all
With the first two patches I can now use my 32-bit installation with a
64-bit kernel, using rumpdisk and with --enable-apic. The system is
quite usable: network, file system checks, rumpdisk all work.
Some small issues are still present, e.g:
$ cat /proc/cmdline
cat: /proc/cmdline:
* i386/i386/debug_i386.c: when using a 64-bit userspace we need to use
RAX and so on, and we can ignore most segments except FS/GS, but
only the base address is useful.
---
i386/i386/debug_i386.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/i386/i386/debug_i386.c
* device/ds_routines.c: enable interrupt registration and acknowledge
for x86_64. We can reuse the 32-bit mechanisms.
---
device/ds_routines.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/device/ds_routines.c b/device/ds_routines.c
index 1f0bacf4..ea880535
* i386/intel/pmap.c: add the check for LINUX_DEV; we could also check
for !__x86_64__, as this config would break ther kernel map by
removing the BIOS mem map, needed by the console and keyboard
drivers, but hopefully we won't need to enable Linux drivers on
x86_64.
---
i386/intel/pmap.c
Sergey Bugaev writes:
Hi Sergey,
> On Fri, May 26, 2023 at 8:19 PM Janneke Nieuwenhuizen wrote:
>> Hi!
>
> Hi,
>
>> I'm trying to get netdde to work in Guix without much success.
[..]
>> /hurd/pfinet: file_name_lookup eth0: No such file or directory
>
> See, you're telling it to open "eth0",
Samuel Thibault writes:
> Janneke Nieuwenhuizen, le ven. 26 mai 2023 17:42:49 +0200, a ecrit:
>> Now that rumpdisk works in Guix we need netdde. Trying to build netdde
>> I need the attached patch. I'm wondering how (/if?) this built for you
>> ;)
>
> It seems at some point in the flurry of
On Fri, May 26, 2023 at 8:19 PM Janneke Nieuwenhuizen wrote:
> Hi!
Hi,
> I'm trying to get netdde to work in Guix without much success.
> Here is what I've added for netdde and what Guix looks like:
>
> --8<---cut here---start->8---
> # showtrans /dev/eth0
>
Hi!
I'm trying to get netdde to work in Guix without much success.
The good news: I have built gnumach without networking and netdde, and
when using the Guix-built gnumach and netdde.static binaries on debian,
everything works fine. Using Debian's gnumach and netdde.static
binaries on Guix
Samuel Thibault, le ven. 26 mai 2023 13:15:18 +0200, a ecrit:
> BTW, it seems the control-alt-d kdb shortcut is not working?
It seems the com0 port interrupt doesn't work at all, comintr doesn't
get called. I tried both with and without acpi, (without the linux group
in both cases). I guess some
On Fri, May 26, 2023 at 7:22 PM Samuel Thibault wrote:
> I.e. gnumach without optimizations gets things wrong. We do want to fix
> that :)
Or, we could also shrug it off and do what glibc is doing:
#ifndef __OPTIMIZE__
# error "gnumach cannot be compiled without optimization"
#endif
:) :) :)
Samuel Thibault, le ven. 26 mai 2023 13:37:11 +0200, a ecrit:
> Luca, le ven. 26 mai 2023 13:18:08 +0200, a ecrit:
> > Il 26/05/23 12:56, Samuel Thibault ha scritto:
> > > Luca, le ven. 26 mai 2023 12:55:32 +0200, a ecrit:
> > > > read_exec() it seems that there is something wrong with the elf
>
Janneke Nieuwenhuizen, le ven. 26 mai 2023 17:42:49 +0200, a ecrit:
> Now that rumpdisk works in Guix we need netdde. Trying to build netdde
> I need the attached patch. I'm wondering how (/if?) this built for you
> ;)
It seems at some point in the flurry of machdev changes I introduced
Hi!
Now that rumpdisk works in Guix we need netdde. Trying to build netdde
I need the attached patch. I'm wondering how (/if?) this built for you
;)
>From b0a7e4f2706bea8d1c80d5af7a095941f9635033 Mon Sep 17 00:00:00 2001
From: Janneke Nieuwenhuizen
Date: Fri, 26 May 2023 17:39:17 +0200
Sergey Bugaev, le ven. 26 mai 2023 18:26:18 +0300, a ecrit:
> On Fri, May 26, 2023 at 2:15 PM Samuel Thibault
> wrote:
> > Here it is:
> >
> > https://dept-info.labri.fr/~thibault/tmp/gnumach
> >
> > It's master 377a9387cec7d4bdd6739d3bcc03f77f524adc69 with a busy-loop on
> > the stop_bootstrap
On Fri, May 26, 2023 at 2:15 PM Samuel Thibault wrote:
> Here it is:
>
> https://dept-info.labri.fr/~thibault/tmp/gnumach
>
> It's master 377a9387cec7d4bdd6739d3bcc03f77f524adc69 with a busy-loop on
> the stop_bootstrap variable at the very beginning of bootstrap_create.
> No lines added/removed
Samuel Thibault writes:
> Hello,
>
> Joshua Branson, le jeu. 25 mai 2023 22:32:24 -0400, a ecrit:
>> So I updated my T43 to the bleeding edge Debian in real hardware, which
>> come on that is pretty cool! The update process was pretty easy. I
>> will describe that in the postscript. I did get
On Fri, May 26, 2023 at 3:00 PM Flávio Cruz wrote:
> Hi Sergey
Hi,
> Thanks for the instructions. I was able to make it work and pushed my changes
> to Github.
That's awesome news -- thank you!
(Well, I figured as much from looking at the GitHub, but it's nice to
get a confirmation.)
What
On Fri, May 26, 2023 at 2:15 PM Samuel Thibault wrote:
> It does load, but stays stuck when starting ext2fs:
>
>start ext2fs:
Yes, I can reproduce this with your build of ext2fs.static
Unfortunately there are no symbols (maybe you could teach me how to
fetch and load separate debuginfo into
On May 26, 2023 2:00:00 PM GMT+02:00, "Flávio Cruz"
wrote:
>Hi Sergey
>
>On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote:
>
>> Hi,
>>
>> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote:
>> > I have made changes so that it does daily builds and I'm able to boot
>> small programs. However,
Hi Sergey
On Fri, May 19, 2023 at 4:02 AM Sergey Bugaev wrote:
> Hi,
>
> On Fri, May 19, 2023 at 9:43 AM Flávio Cruz wrote:
> > I have made changes so that it does daily builds and I'm able to boot
> small programs. However, I haven't had the time to boot programs built
> against Glibc. How do
Luca, le ven. 26 mai 2023 13:18:08 +0200, a ecrit:
> Il 26/05/23 12:56, Samuel Thibault ha scritto:
> > Luca, le ven. 26 mai 2023 12:55:32 +0200, a ecrit:
> > > read_exec() it seems that there is something wrong with the elf parsing,
> > > as
> > > the size parameters look like kernel addresses:
Il 26/05/23 12:56, Samuel Thibault ha scritto:
Luca, le ven. 26 mai 2023 12:55:32 +0200, a ecrit:
read_exec() it seems that there is something wrong with the elf parsing, as
the size parameters look like kernel addresses:
(gdb) p/x file_size
$1 = 0x8106f4d3
Perhaps a spurious
Sergey Bugaev, le ven. 26 mai 2023 13:58:29 +0300, a ecrit:
> On Fri, May 26, 2023 at 1:10 PM Sergey Bugaev wrote:
> > Let me actually try building w/ Luca's patches myself and seeing if
> > that works for me.
>
> Yes, still works here with the latest gnumach, so Luca's changes are
> not to
On Fri, May 26, 2023 at 1:10 PM Sergey Bugaev wrote:
> Let me actually try building w/ Luca's patches myself and seeing if
> that works for me.
Yes, still works here with the latest gnumach, so Luca's changes are
not to blame.
I can reproduce your crash with your gnumach build though; but as it
Luca, le ven. 26 mai 2023 12:55:32 +0200, a ecrit:
> read_exec() it seems that there is something wrong with the elf parsing, as
> the size parameters look like kernel addresses:
>
> (gdb) p/x file_size
> $1 = 0x8106f4d3
Perhaps a spurious signedness bit extension?
Samuel
Il 26/05/23 11:46, Luca ha scritto:
Hi
Il 26/05/23 03:31, Samuel Thibault ha scritto:
GNU Mach 1.8
ELF section header table at 80010290
biosmem: physical memory map:
biosmem: 00:09f000, available
biosmem: 09fc00:0a, reserved
Sergey Bugaev, le ven. 26 mai 2023 13:10:23 +0300, a ecrit:
> On Fri, May 26, 2023 at 12:57 PM Samuel Thibault
> wrote:
> > > And the addresses seem well above the 4 GB limit;
> >
> > Which addresses?
>
> These ones:
>
> > 0x8107a712(0,8101d463,400ee0,8101d49c,0)
> >
On Fri, May 26, 2023 at 12:57 PM Samuel Thibault
wrote:
> > And the addresses seem well above the 4 GB limit;
>
> Which addresses?
These ones:
> 0x8107a712(0,8101d463,400ee0,8101d49c,0)
> 0x8106ff27(de739868,8101d463,de736fb8,0,8104ceec
Sergey Bugaev, le ven. 26 mai 2023 12:49:55 +0300, a ecrit:
> On Fri, May 26, 2023 at 4:32 AM Samuel Thibault
> wrote:
> > I'm trying to start a 64bit Debian/Hurd but this fails very early.
> >
> > 0x8107a712 is the *read_exec call in exec_load, which does
> > happen fine, until
Hello,
On Fri, May 26, 2023 at 4:32 AM Samuel Thibault wrote:
> I'm trying to start a 64bit Debian/Hurd but this fails very early.
>
> 0x8107a712 is the *read_exec call in exec_load, which does
> happen fine, until read_exec calls copyout, which thus apparently fails
> somehow.
>
> Does
Hi
Il 26/05/23 03:31, Samuel Thibault ha scritto:
GNU Mach 1.8
ELF section header table at 80010290
biosmem: physical memory map:
biosmem: 00:09f000, available
biosmem: 09fc00:0a, reserved
biosmem:
Hello,
Joshua Branson, le jeu. 25 mai 2023 22:32:24 -0400, a ecrit:
> So I updated my T43 to the bleeding edge Debian in real hardware, which
> come on that is pretty cool! The update process was pretty easy. I
> will describe that in the postscript. I did get this error recently
> when I
37 matches
Mail list logo
