Hi there!
I am interested in getting more driver support into the Hurd.
I started by rebasing/compiling the PCI arbiter patches and documenting
the steps required to make it all work on the stock Debian disk image.
Note you might need to extend the disk image to get more disk space
before
On 29/10/18 21:19, Damien Zammit wrote:
> Please see below and attached tarball with all rebased patches:
I have another patch for each of libpciaccess and pciutils that go on
top of my previous ones.
This provides fallback mechanism for when servers/bus/pci is unavailable
it will fall b
a new post with the gnumach patch.
Cheers,
Damien
>From 72f96ca9e17e838443cbbf64331d6acdd242ec29 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 4 Nov 2018 21:33:50 -0500
Subject: [PATCH] pci-arbiter: Remove embedded pciaccess code
This patch removes all embedded pciaccess code from the arbiter
and
rom 8f5525e8d46b5cf47d7eaaeb92cdc247464cf1ac Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Fri, 9 Nov 2018 22:17:46 -0500
Subject: [PATCH] Restrict access to PCI cfg io ports to one process
---
i386/i386/io_perm.c | 26 +-
i386/i386/io_perm.h | 2 --
i386/incl
On 10/11/18 20:42, Samuel Thibault wrote:
> Damien Zammit, le sam. 10 nov. 2018 18:58:35 +1100, a ecrit:
>> +CPPFLAGS += -imacros $(srcdir)/config.h
>
> Why is this needed?
I have now removed config.h and this line.
> So it seems that libpciaccess doesn't provide an interface
On 11/11/18 13:05, Samuel Thibault wrote:
> Do you know how your copyright assignment is going, so I can commit it?
Haven't heard anything since I sent through my request.
Damien
On 11/11/18 12:51, Samuel Thibault wrote:
> Damien Zammit, le dim. 11 nov. 2018 12:43:07 +1100, a ecrit:
>> +#define IS_IN_PROTECTED_RANGE(from, to) \
>> + ( ( ( from <= PCI_CFG1_START ) && ( to >= PCI_CFG1_END ) ) || \
>
> That should be from <= END &
001
From: Damien Zammit
Date: Tue, 6 Nov 2018 02:53:36 -0500
Subject: [PATCH] ACPI tables translator
Exposes x86 ACPI tables as a netfs on a mount point
---
Makefile | 3 +-
acpi/Makefile | 35
acpi/acpi.c | 290 +
acpi/acpi.h |
ns.
Thanks, Damien
>From b79f52db69000b0d4bdc75346a109aaf08ec45d8 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Fri, 9 Nov 2018 22:17:46 -0500
Subject: [PATCH] Restrict access to PCI cfg io ports to one process
---
i386/i386/io_perm.c | 27
On 13/11/18 05:39, Almudena Garcia wrote:
> In my docs, I've written the procedure to get this:
>
> /- How to find APIC table
> To find APIC table, we can read RSDT table RSDT reference. To get the
> address of RSDT, we need to read RDSP table./
> /Once got RSDT table, we need to read Entry
for patch.
Thanks,
Damien
>From b24bbaad7227749286a3c081fc471e5da91cd59a Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 23 Dec 2018 23:59:29 -0500
Subject: [PATCH] Prepare for rump disk access by making libstore take non-mach
device
---
libstore/device.c |
ementation.
Thanks,
Damien
>From 22758da0b147980c11dbd456f7a4e00404261212 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Tue, 6 Nov 2018 02:53:36 -0500
Subject: [PATCH 1/3] ACPI tables translator
Exposes x86 ACPI tables as a netfs on a mount point
---
Makefile | 3 +-
acpi/Makef
On 18/11/18 04:30, liberamenso10...@gmail.com wrote:
> Ok. In any case, I've restarted the project two months ago.
>
> You can read the docs from here:
> https://gitlab.com/snippets/1756024
Hi, don't forget you can read the coreboot source code which is a free
software bios that, among other
Hi Kalle,
On 25/11/18 19:58, Kalle Olavi Niemitalo wrote:
> Perhaps this code should first check whether the SCI_EN bit is
> already set, as described in ACPI 5.0 section 4.8.2.5
> "Legacy/ACPI Select and the SCI Interrupt", and skip the outb if
> so. Section 5.2.9 "Fixed ACPI Description Table
Hi Almudena,
> El dom., 10 mar. 2019 a las 18:35, Samuel Thibault
> (mailto:samuel.thiba...@gnu.org>>) escribió:
> Adam Van Ymeren, le dim. 10 mars 2019 13:08:23 -0400, a ecrit:
> > I don't think that's necessary. The process doesn't have to
> initiated from gnumach. Hurd could have
Hi,
On 04/02/19 06:27, Almudena Garcia wrote:
> Possibly. I don't know if it's still relevant with nowadays' hardware,
> though: is APIC still at that address?
See [1] for coreboot's definition of the x86 multiprocessing table MP
table structures. See [2] for coreboot's implementation
On 4/9/19 6:10 am, Joan Lledó wrote:
> 3- In libpciaccess upstream there are some commits by Damien Zammit,
> one of them with the new modules for the Hurd. I wonder: this new
> module expects to be used from both user tasks and the translator?
There are currently two modes of
n applying
netdde patches and trying to bring up /dev/eth0.
Cheers,
Damien
>From 1dc2aedc175fdc5297eab566820ff26e664e4eca Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Mon, 11 Nov 2019 21:04:47 +1100
Subject: [PATCH] Fix unmasking curr_pic_mask only irqs
---
i386/i386at/interrupt.S | 3
Hi there,
Please find attached 2x patches for gnumach (apply cleanly on debian gnumach).
The first patch combines all spls 1-7 into a single spl that disables all
interrupts.
It boots with just this patch.
The second patch removes all concept of a cached PIC mask, and allows the PIC
to remain
On 4/11/19 7:48 am, Samuel Thibault wrote:
> Hello,
>
> Uploaded fixed netdde, pciutils, libpciaccess, and commited this
> pci-arbiter cleanup!
>
> Samuel
>
Thank you for doing all this!
wOOt!! I will test it soon.
Damien
Hi,
On 20/10/19 7:00 am, Almudena Garcia wrote:
> Finally, after a couple of downgrade and upgrade, I found the failed package:
> *libpciaccess0*
> Downgrading this package to 2017 snapshot version, and holding It, the
> problem with network configuration is solved and I can upgrade my system
On 25/11/19 9:51 am, Joan Lledó wrote:
> El dg. 24 de 11 de 2019 a les 21:17 +0100, en/na Samuel Thibault va
> escriure:
>> AIUI, apart from my changes, these are the changes which are already
>> upstream?
>
> No, none of this changes are upstream.
Joan, I think you are getting confused where is
one for Linux possibly because
it's too difficult to change the Linux kernel sound API and ALSA
is almost good enough for most purposes.
--
Damien Zammit
ZamAudio
On 30/11/19 9:06 pm, Joan Lledó wrote:
> Hi,
>
> What about this? Do I send the PR? Is there any alternative for the
> weak reference?
>
> El dt. 26 de 11 de 2019 a les 22:53 +0100, en/na Samuel Thibault va
> escriure:
>> Joan Lledó, le lun. 25 nov. 2019 10:02:55 +0100, a ecrit:
>>> 2- Didn't
>From ec49ad8431fd20cef877098767820243bb3b95dd Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sat, 23 Nov 2019 15:08:47 +1100
Subject: [PATCH] ext2fs: Fix fast symlinks created by linux
---
ext2fs/inode.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/ext2fs/inode.
back to opening the regular master
device.
Thoughts?
Damien
>From 938ae54389d8ce91b2575199a07c3b8787b0bdbd Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sat, 9 Nov 2019 18:35:10 +1100
Subject: [PATCH] libstore alternative master device with @ prefix
---
libstore/device.c |
Hi Samuel,
On 9/12/19 10:08 am, Samuel Thibault wrote:
> I have been thinking about how to get rump running for the / filesystem.
> ...
> I'm thinking that the same can be used for the rump translator,
> something like:
>
> module rump --fs-server-task='${fs-task}' '$(task-create)'
term wise.
Fixed
Damien
>From 995085eca1f178d9d2db6de04abb9cb5dea17e9b Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 29 Mar 2020 22:37:23 +1100
Subject: [PATCH] rumpdisk: Add userspace disk support via librump
---
Makefile |
While polishing rumpdisk I made these trivial patches which may be useful.
Damien
>From 364be01ee8120f795c588c30f92557a9c3f97578 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Fri, 10 Apr 2020 22:17:31 +1000
Subject: [PATCH 1/2] pci-ops.c: Use compatible pointers
---
pci-arbiter/pci-op
On 20/4/20 5:39 am, Almudena Garcia wrote:
> Yes, I know. But, if I want to start the cpu explorating using ACPI
> translator, I think that the best way is to create other translator, instead
> call to this directly from gnumach.
> Another problem can be share the reference to lapic with
On 30/3/20 10:38 pm, Samuel Thibault wrote:
> Damien Zammit, le lun. 30 mars 2020 22:22:12 +1100, a ecrit:
>> I don't think block-rump.c needs a separate library, what do you think?
>
> Indeed, the way you did seems well-contained.
Thanks. See patch for configure.ac/Makefile
On 3/4/20 9:28 am, Samuel Thibault wrote:
> Concerning the link line, I don't understand why hardcoding everything?
>
> - For a start, are the _pic.a versions really needed? The .a versions
> should just work.
I think the _pic.a versions are required. I could not get rump to work with .a
That
yea, I have added that one instead to our tree (rump doesn't have it).
>>> There are a couple mach_print debugging calls left.
Oops, yeah done.
Damien
>From fd76bb26a629dbe42840ff8807047fe531494bc0 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 29 Mar 2020 22:37:23 +1100
S
Hi Samuel,
I am sending this primarily because I don't want to lose these patches.
With the attached debian patches for libpciaccess and hurd,
the rumpkernel debian packages I have prepared locally work out of the box.
The problem is, you can't compile hurd with these patches without building
Hi Samuel,
On 29/3/20 11:19 am, Samuel Thibault wrote:
> --- a/src/common_interface.c
> +++ b/src/common_interface.c
> @@ -290,11 +290,13 @@ pci_device_map_range(struct pci_device *dev, pciaddr_t
> base,
>
> /* Make sure that there isn't already a mapping with the same base and
> *
Hurd TODO for Damien:
=
- Fix libstore patch
- Remove useless debugging eg:
>> + mach_print("device open\n");
- Remove most of this header:
>> +++ b/libmachdevrump/dev_hdr.h
- Complete the following:
> I see that most of the patch is actually coming from the
On 29/3/20 11:24 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> Apply these first to libpciaccess:
>> upstreaming/libpciaccess/99-fix-pciconf-calls
>> upstreaming/libpciaccess/99-region-probe
>> upstreaming/libpciacc
On 29/3/20 11:31 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> I could then push out my latest debian rumpkernel tree.
>
> I'd say yes, you can go ahead.
>
> I don't think you need to wait for libpciaccess patches? Sure all
&g
On 30/3/20 7:06 am, Samuel Thibault wrote:
> Damien Zammit, le sam. 28 mars 2020 16:50:41 +1100, a ecrit:
>> Then you'll need me to push latest rumpkernel tree so you can build rump libs
>
> Could you commit the upstream tarballs to the repo as well so I have the
> correct v
isk and used your new api. See patch below.
I don't think block-rump.c needs a separate library, what do you think?
Thanks,
Damien
>From 45ac091794bd7b96e7b0cb01852f3bee72c29168 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 29 Mar 2020 22:37:23 +1100
Subject: [PATCH] rumpdisk: Add
On 29/3/20 4:16 pm, Damien Zammit wrote:
> Hurd TODO for Damien:
> =
>
> - Fix libstore patch
Done
> - Remove useless debugging eg:
Done
>
> - Remove most of this header:
>>> +++ b/libmachdevrump/dev_hdr.h
>> - put the files common to
Samuel,
>> I have a feeling we are going to need all of acpica incorporated into
>> gnumach eventually,
>> because you need a full ACPI parser for learning the PCI interrupts and
>> proper shutdown mechanism.
>
> Can't the parsing be done in userland (like we do for shutdown), and
> just hand
Hi all,
I have added ACPICA support to gnumach here:
http://git.zammit.org/gnumach-sv.git/log/?h=debian-acpica
It boots and prints a log but the problem I am facing is that
the log is not saved to /var/log/dmesg even though it prints at boot.
As it scrolls so fast, I cannot read it and I don't
This one-liner fixes libmachdev build failure.
---
libmachdev/trivfs_server.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/libmachdev/trivfs_server.h b/libmachdev/trivfs_server.h
index ae30a830..40ae57fe 100644
--- a/libmachdev/trivfs_server.h
+++ b/libmachdev/trivfs_server.h
@@ -27,7
With the changes now provided upstream in libpciaccess:
- https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/commits/master
This change is now required in rumpkernel.
---
debian/patches/memory-range.diff | 8
1 file changed, 8 insertions(+)
diff --git
On 6/9/20 11:17 pm, Samuel Thibault wrote:
>> I have uploaded libpciaccess_0.16-1+hurd.5 with the latest upstream
>> version.
Thanks!
> One issue remains, however: Xorg's vesa driver produces
>
> [1669282.478] (II) VESA(0): initializing int10
> [1669282.478] (EE) VESA(0): Cannot read int vect
>
Hi,
On 23/8/20 8:47 pm, Joan Lledó wrote:
> http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=jlledom-pciaccess-map
Thanks for doing this, I tried it locally and fixed two bugs in my libpciaccess
patches:
diff --git a/src/x86_pci.c b/src/x86_pci.c
index 1614729..1e70f35 100644
---
On 18/8/20 6:51 am, Joan Lledó wrote:
> El 17/8/20 a les 1:51, Damien Zammit ha escrit:
>> Perhaps a better way to fix the mapping problem I encountered
>> is by removing the check for previous mappings when trying to map regions,
>
> I could check the pointe
Joan,
On 18/8/20 6:51 am, Joan Lledó wrote:
> El 17/8/20 a les 1:51, Damien Zammit ha escrit:
>> Perhaps a better way to fix the mapping problem I encountered
>> is by removing the check for previous mappings when trying to map regions,
I have removed my latest patch from my
On 22/8/20 8:38 pm, Joan Lledó wrote:
> However, I think the problem here is the x86 backend, not the common
> interface. If we take a look at all other backends we'll see that:
>
> 1.- Neither of them call its probe() from its create(). So it's the
> client who must call pci_device_probe(), it's
Hi Joan,
I found another probe() call in hurd_pci.c that should not be there.
(So I dropped a second incorrect patch).
Can you please confirm this final branch looks correct?
http://git.zammit.org/libpciaccess.git/log/?h=rumpdisk-upstream
Thanks,
Damien
On 26/10/20 4:42 pm, Damien Zammit wrote:
> On 26/10/20 10:56 am, Almudena Garcia wrote:
>> This is my lspci -nn
>
> I think it's a bug with the pci-arbiter listing some of your hardware four
> times using lspci.
>
I just wrote a test program that iterates over all pci d
On 26/10/20 10:56 am, Almudena Garcia wrote:
> This is my lspci -nn
I think it's a bug with the pci-arbiter listing some of your hardware four
times using lspci.
Damien
Hi,
I figured out why it was hanging on reboot:
netdde was frozen because pci-arbiter was not working
with my setup that used x86 method of pci access for rumpdisk.
When I removed the translators from /dev/netdde and /servers/bus/pci,
reboot-hurd rebooted cleanly with this patch.
Damien
---
libmachdev/Makefile | 4 +-
libmachdev/ds_routines.c | 10 +++
libmachdev/machdev-device_emul.h | 1 +
libmachdev/machdev.h | 1 +
libmachdev/trivfs_server.c | 116 ++-
libmachdev/trivfs_server.h | 33 +
work
so I've left physical alignment as a TODO as well as pmin != 0, but included it
in the RPC itself so it can be committed even if it doesn't do anything yet.
Please see attached 2 new patches.
Thanks,
Damien
>From adfad36aab3bb1f9a626fa5ba22d12f286e39fd6 Mon Sep 17 00:00:00 2001
From
> alignment and release unused pages accordingly.
I think I have fixed vm_allocate_contiguous, see attached second patch.
I still need to test patch 0002 with netdde/rump, for instance.
Damien
>From 0ab926aac6ca96169b74f337f70da8229109e45f Mon Sep 17 00:00:00 2001
From: Damien Zammit
Hi,
On 3/7/20 7:29 pm, Damien Zammit wrote:
> I have tried to refactor the RPCs but I'm not sure how to make it a
> fully-fledged "irq" mach device.
I have a new version of my patch that should make this a proper mach device and
I fixed the RPCs for ds_device_intr_*
to
Hey Almudena,
On 4/7/20 1:49 am, Almudena Garcia wrote:
> I'm following this guide, simply Xorg seems doesn't works in my machine
> https://www.debian.org/ports/hurd/hurd-install
Are you running coreboot or factory bios on your T60?
I think coreboot native gfx does *not* support VBE graphics
On 5/7/20 11:50 am, Damien Zammit wrote:
> One thing that is missing from this patch is the "vm_allocate_contiguous" RPC.
> It is required for DMA. How should I proceed with it? Do I make it an RPC
> on the
> "mem" device only?
See attached for first attemp
How should I proceed with it? Do I make it an RPC on
the
"mem" device only?
See attached for revised patch.
Thanks,
Damien
>From 072658e23208b4337f5d43c11244333e9798bdb2 Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sun, 5 Jul 2020 11:15:44 +1000
Subject: [PATCH
ba66c39f340253a3ca210ab Mon Sep 17 00:00:00 2001
From: Damien Zammit
Date: Sat, 27 Jun 2020 22:57:51 +1000
Subject: [PATCH] irq: Refactor interrupt handling as a mach device
---
Makefrag.am | 4 +-
device/ds_routines.c | 62 +++
device/ds_ro
Hello,
I compiled and installed the latest master-user_level_drivers-debian branch
of gnumach, (which has both fallback and new RPCs for interrupt handling).
Using the attached patch, I was able to build libddekit.a and link with netdde.
This enabled the new user-land driver path to work for
On 29/6/20 7:52 pm, Ricardo Wurmus wrote:
> What is the API provided to user applications? Or would it be enough to
> add support for this new API to JACK, so that all audio applications
> using JACK automatically benefit from this?
I'm not sure if it may be best to use the NetBSD implementation
Hi Joshua,
On 10/6/20 9:49 am, Joshua Branson wrote:
> And I know Damien Zammit is fantastic, because he is working on some
> ridiculously amazing audio work for the Hurd. And holy Alaskan
> Asparagus tips! How does he have time to be a kernel developer and make
> such beautiful mus
On 7/6/20 10:29 pm, Joshua Branson wrote:
> Hey Samuel!
>
> I just want to thank you for being so diligent at maintaining and
> continuing to develop the GNU/Hurd. You are one of my heroes, and I
> love how dedicated you are to the project!
>
> Wishing you a good day,
>
> Joshua
>
Yes,
---
libmachdev/Makefile| 2 +-
libmachdev/trivfs_server.c | 56 ++
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/libmachdev/Makefile b/libmachdev/Makefile
index db275cce..15b98cf1 100644
--- a/libmachdev/Makefile
+++
---
libmachdev/ds_routines.c | 19 --
libmachdev/machdev.h | 5 +-
libmachdev/trivfs_server.c | 135 -
3 files changed, 131 insertions(+), 28 deletions(-)
diff --git a/libmachdev/ds_routines.c b/libmachdev/ds_routines.c
index da5e47e2..d5451a92
---
rumpdisk/block-rump.c | 38 +
rumpdisk/main.c | 95 +--
2 files changed, 123 insertions(+), 10 deletions(-)
diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
index 42ace30d..94df9be8 100644
--- a/rumpdisk/block-rump.c
+++
libmachuser provides what we need
---
libmachdev/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libmachdev/Makefile b/libmachdev/Makefile
index 1f15ebe9..db275cce 100644
--- a/libmachdev/Makefile
+++ b/libmachdev/Makefile
@@ -19,13 +19,13 @@ dir := libmachdev
---
Makeconf | 4
1 file changed, 4 insertions(+)
diff --git a/Makeconf b/Makeconf
index f68ff6e3..b4a5dbd5 100644
--- a/Makeconf
+++ b/Makeconf
@@ -582,15 +582,19 @@ mach_defs_names = bootstrap exc mach mach4 \
gnumach \
task_notify \
+mach_i386_defs_names = mach_i386
---
debian/rules | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/rules b/debian/rules
index 6862a30f..c9851d1e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,8 +6,9 @@ export SHELL = bash
#export DH_VERBOSE=1
DEB_HOST_ARCH_OS ?= $(dpkg-architecture
---
debian/patches/machirqdev.diff | 173 +
debian/patches/series | 1 +
2 files changed, 174 insertions(+)
create mode 100644 debian/patches/machirqdev.diff
diff --git a/debian/patches/machirqdev.diff b/debian/patches/machirqdev.diff
new file mode
---
debian/control | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index ea63d25c..3cce3aac 100644
--- a/debian/control
+++ b/debian/control
@@ -5,8 +5,9 @@ Build-Depends:
debhelper (>= 8.0.0),
autotools-dev,
zlib1g-dev,
-
This still does not work. I get a freeze on reboot command:
root@zamhurd:~# reboot
INIT: Switching to runlevel: 6
INIT: Sending processes configured via /etc/inittab the TERM signal
root@zamhurd:~#
Broadcast message from root@zamhurd (console) (Sun Jul 25 16:32:28 1999):
The system is going
---
libmachdev/ds_routines.c | 15 +++-
libmachdev/machdev.h | 5 +-
libmachdev/trivfs_server.c | 154 -
3 files changed, 148 insertions(+), 26 deletions(-)
diff --git a/libmachdev/ds_routines.c b/libmachdev/ds_routines.c
index da5e47e2..53e0c080
---
Makeconf | 4
1 file changed, 4 insertions(+)
diff --git a/Makeconf b/Makeconf
index f68ff6e3..b4a5dbd5 100644
--- a/Makeconf
+++ b/Makeconf
@@ -582,15 +582,19 @@ mach_defs_names = bootstrap exc mach mach4 \
gnumach \
task_notify \
+mach_i386_defs_names = mach_i386
---
libmachdev/Makefile| 2 +-
libmachdev/trivfs_server.c | 60 ++
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/libmachdev/Makefile b/libmachdev/Makefile
index db275cce..15b98cf1 100644
--- a/libmachdev/Makefile
+++
---
rumpdisk/block-rump.c | 39 ++
rumpdisk/main.c | 95 +--
2 files changed, 123 insertions(+), 11 deletions(-)
diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
index 42ace30d..474852cd 100644
--- a/rumpdisk/block-rump.c
Hello,
These patches for three different repos make rumpdisk expose a block device and
boot off it.
I have tried to keep the patches separate for now, but easily can be squashed.
There are two known issues with this:
1. The server using libpciaccess currently needs to be faked with
NB: Reboot still hangs on diskfs_S_startup_dosync() even though that
times out and then rumpdisk shuts down cleanly.
---
libmachdev/Makefile | 6 +--
libmachdev/ds_routines.c | 10
libmachdev/machdev-device_emul.h | 1 +
libmachdev/machdev.h | 1 +
---
libdiskfs/fsys-getroot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libdiskfs/fsys-getroot.c b/libdiskfs/fsys-getroot.c
index 735f359a..2c0d15dd 100644
--- a/libdiskfs/fsys-getroot.c
+++ b/libdiskfs/fsys-getroot.c
@@ -194,7 +194,8 @@ diskfs_S_fsys_getroot (struct
NB: Not sure why this seems to have no effect on /dev/rumpdisk
Am I setting the translator on the wrong port?
---
rumpdisk/main.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/rumpdisk/main.c b/rumpdisk/main.c
index 27a8ea38..68fb8be2 100644
---
---
libdiskfs/boot-start.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c
index 29b8acc6..fa59e1b2 100644
--- a/libdiskfs/boot-start.c
+++ b/libdiskfs/boot-start.c
@@ -518,7 +518,9 @@ diskfs_S_fsys_init (struct diskfs_control
---
libdiskfs/boot-start.c | 11 +++
libdiskfs/init-startup.c | 64 +---
2 files changed, 52 insertions(+), 23 deletions(-)
diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c
index 29b8acc6..4fbd62c5 100644
--- a/libdiskfs/boot-start.c
+++
This patch almost provides shutdown notification for rumpdisk,
but fails at getproc() which returns 0, I struggle to figure out why.
Currently:
Hurd server bootstrap: ext2fs[part:2:device:/dev/wd0] ...
WARNING: machdev not registered for shutdown
---
libmachdev/Makefile | 6 +--
Hi there,
On 15/8/20 9:49 pm, Joan Lledó wrote
> I downloaded and tried the last qemu image "debian-hurd-20200731.img".
> When I try to read the memory mapped content of region files in the
> arbiter, it crashes and shows the message "Real-time signal 0".
I am also getting this on my latest hurd
Hi there,
On 17/8/20 1:04 am, Joan Lledó wrote:
> I found the same issue, investigating a bit more I found that in
> func_files.c:201[1], the value of region->memory is 0x0, so reading from
> there raises a segfault. That pointer should be filled in libpciacces,
> at x86_pci.c:601[2] during the
On 24/11/20 5:16 am, Samuel Thibault wrote:
> Hello,
>
> Had you tested support for cd-rom? With qemu I am getting a media sense
> error with status 0x50.
I think that was the reason for the qemu patch for syncing IDE cache iirc.
Damien
Hi,
On 10/11/20 6:12 am, Samuel Thibault wrote:
> Btw, is your second partition within small bounds? (e.g. within 4GiB
> that can be expressed with 32bit integers)
Device Boot Start End Sectors Size Id Type
/dev/sdd12048 1953791 1951744 953M 82 Linux swap /
currently, it does not reopen the same device twice, it
just passes the caller a send right to the old one.
Damien
On 8/11/20 10:51 am, Samuel Thibault wrote:
> Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit:
>> On 8/11/20 2:35 am, Samuel Thibault wrote:
>>> Perhap
Hi,
On 8/11/20 2:35 am, Samuel Thibault wrote:
> Perhaps, before mounting, try to run
DISK
> fdisk -l /dev/wd0
root@zamhurd:~# showtrans /dev/wd0
/hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0
root@zamhurd:~# fdisk -l /dev/wd0
ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT
Hi,
On 10/11/20 10:39 am, Samuel Thibault wrote:
>> sdd2 is / that boots with rumpdisk.static
>> sdd3 is the second partition I am trying to mount with the injected
>> translator
>
> That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its
> off_t etc. will be 32bit, thus probably
Hi Samuel,
On 10/11/20 6:21 pm, Samuel Thibault wrote:
>> It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default:
>
> But is rumpkernel itself also built with it?
>
> Really, better actually *test* that offsets are getting properly
> propagated.
Test program output:
```
...
Previous problems mentioned with 2x rumpdisk partitions all fixed.
Booted off rumpdisk / and mounted second partition in userspace:
root@zamhurd:~# showtrans /dev/wd0
/hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0
root@zamhurd:~# fdisk -l /dev/wd0
Disk /dev/wd0: 298.9 GiB, 320072933376
Hi Samuel,
I need to figure out the next step of rumpdisk, using the arbiter instead of
faking the arbiter.
> youpi: pci-arbiter could be exposed as a device name in the master device
> port and the userland pci-arbiter running on /server/bus/pci can try to open
> that
> youpi: just like
On 11/11/20 5:58 am, Samuel Thibault wrote:
> Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit:
>> I also printed inside rumpdisk to dump the offsets before calling
>> pread/pwrite,
>> these offsets are sometimes wider than 32 bits, sometimes not.
>
> Ok.
Hi,
How do I expose the hurdish pci subsystem that has no underlying node to attach
to for a netfs
in pci-arbiter during bootstrap?
I have almost completed the loop with rumpdisk and the arbiter, but I cannot
start pci-arbiter
as it has no underlying node to attach to, and the specific
On 16/11/20 12:40 pm, Samuel Thibault wrote:
> It booted fine :D
\o/ YAY!
Hi,
On 16/11/20 11:04 am, Samuel Thibault wrote:
> I tried wd0, it does work (but my setup is using wd1, so doesn't boot :) )
Hmm, I have the same problem on my end trying to boot off wd1:
ahcisata0 port 1: device present, speed: 1.5Gb/s
ahcisata0 port 0: device present, speed: 1.5Gb/s
wd0 at
1 - 100 of 606 matches
Mail list logo
