This file is not used today since we end up using
sysdeps/i386/htl/machine-sp.h. Getting the stack pointer does not need
to be hurd specific and can go into sysdeps/.
---
sysdeps/mach/i386/machine-sp.h | 30 --
1 file changed, 30 deletions(-)
delete mode 100644 sysdeps
The kernel does not use these functions so we can avoid a few compiler
warnings. I think we could make the hurd servers not use these also but
currently these are still needed.
---
server.c | 94 +---
1 file changed, 48 insertions(+), 46 deletion
contrib/ChangeLog:
* config-list.mk: Add x86_64-gnu to list of archs.
Signed-off-by: Flavio Cruz
---
contrib/config-list.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index 20b8f4a196f..661b11c9bbd 100644
--- a/cont
Applied, thanks!
Flavio Cruz, le lun. 30 janv. 2023 01:52:53 -0500, a ecrit:
> We seem to call only into the exception and message server routines.
> ---
> hurd/msgportdemux.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/hurd/msgportdemux.c b/hurd/msgportdemux.c
> i
Applied, thanks!
Flavio Cruz, le lun. 30 janv. 2023 01:52:53 -0500, a ecrit:
> We seem to call only into the exception and message server routines.
> ---
> hurd/msgportdemux.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/hurd/msgportdemux.c b/hurd/msgportdemux.c
> i
Applied, thanks!
Sergey Bugaev, le lun. 30 janv. 2023 15:52:16 +0300, a ecrit:
> This adds a special SHM_ANON value that can be passed into shm_open ()
> in place of a name. When called in this way, shm_open () will create a
> new anonymous shared memory file. The file will be created in the same
Applied, thanks!
Sergey Bugaev, le lun. 30 janv. 2023 15:52:15 +0300, a ecrit:
> This is a flag that causes open () to create a new, unnamed file in the
> same filesystem as the given directory. The file descriptor can be
> simply used in the creating process as a temporary file, or shared with
>
Hi Flávio and Thomas!
On Mon, 2023-01-30 16:44:29 +0100, Thomas Schwinge
wrote:
> On 2023-01-27T21:15:01-0500, Flávio Cruz wrote:
> > Not sure what happened, but here's the patch as an attachment. Thanks for
> > your patience.
>
> Thanks, that worked. Without any changes now pushed to master
Applied, thanks!
Sergey Bugaev, le lun. 30 janv. 2023 15:52:14 +0300, a ecrit:
> Instead of __file_name_lookup_at delegating to __file_name_lookup
> in simple cases, make __file_name_lookup_at deal with both cases, and
> have __file_name_lookup simply wrap __file_name_lookup_at.
>
> Signed-off-by
Flávio Cruz, le mer. 01 févr. 2023 03:40:38 -0500, a ecrit:
> One could imagine adding new RPCs with parameters that are compatible
> on both archs to avoid doing any translation.
> It might be less work than waiting for all userland to be 64 bit ready.
64bit userland won't be that much work actua
Damien Zammit, le mer. 01 févr. 2023 10:06:11 +, a ecrit:
> I very much doubt a disk exists with 255 physical heads.
That's not the question :)
Disks have been lying about their geometry for a long time. But yes,
some disks may be erroneously reporting an "all-max" geometry that we
should jus
Applied, thanks!
Damien Zammit, le mer. 01 févr. 2023 10:06:05 +, a ecrit:
> ---
> i386/i386/db_trace.c| 3 ++-
> i386/i386at/model_dep.h | 4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/i386/i386/db_trace.c b/i386/i386/db_trace.c
> index 99cb8c48..04c868af 10
Applied, thanks!
Damien Zammit, le mer. 01 févr. 2023 10:05:39 +, a ecrit:
> ---
> i386/intel/pmap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c
> index 84a4cef5..0505cfa2 100644
> --- a/i386/intel/pmap.c
> +++ b/i386/intel/pmap.c
> @@ -2928,
Mmmm, I believe we do? linux_init() is called before
cpu_launch_first_thread(), and some Linux drivers may need the clock
ticking for their probing.
Note however that we don't plan to keep Linux drivers on the long run:
once rumpdisk is confirmed to be stable we'll just get rid of the Linux
driver
Hello,
Damien Zammit, le mer. 01 févr. 2023 10:05:47 +, a ecrit:
> This is a rather large commit, but difficult to break it up.
Perhaps you can separate out the moving of the i386at_init code
> @@ -448,47 +444,8 @@ i386at_init(void)
>*/
> biosmem_setup();
>
> - /*
> -
https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/sched_prim.c#L1243
Check this line, and the rest of the function. I think that it was a
modification which i did with Samuel
El mié, 1 feb 2023 a las 12:57, Almudena Garcia ()
escribió:
> In previous time, Samuel proposed me to set a "bound
In previous time, Samuel proposed me to set a "bound processor", to force
that booting use only BSP, and the AP will be using once booting are
finishing.
But I don't remember fine how to do it.
Also we found that ext2fs had a thread which was never assigned to any
processor, but we never discover
Original Message
On 1 Feb 2023, 10:35 pm, Almudena Garcia < liberamenso10...@gmail.com> wrote:
Ok. Now I understand better. Maybe it's the same problem which I found in my
first implementation: the AP was stuck, and the scheduler was sending all
threads to the BSP.
Try to debug
Ok. Now I understand better. Maybe it's the same problem which I found in
my first implementation: the AP was stuck, and the scheduler was sending
all threads to the BSP.
Try to debug it using gdb, and checking the registers values in qemu
monitor.
El mié, 1 feb 2023 a las 12:32, Damien Zammit ()
Hi Almu,
I removed the slave main function and instead called the cpu launch first
thread directly, see mpdesc. Of course, I have been testing the scheduler with
all cpus. Unfortunately it is currently stuck in machine idle occasionally with
interrupts off on one or more cpu and the first task d
It's great!!
If I remember well, this caused me some problems when I tried to install
Debian GNU/Hurd with SATA over real hardware a year ago.
El mié, 1 feb 2023 a las 11:56, Damien Zammit ()
escribió:
> This allows qemu -M q35 to boot without 30 second timeout
> failing on hd0, when disk is actu
+/* Turn paging on.
+ * TODO: Why does setting the WP bit here cause a crash?
+ */
+set_cr0(get_cr0() | CR0_PG /* | CR0_WP */);
+set_cr0(get_cr0() & ~(CR0_CD | CR0_NW));
+if (CPU_HAS_FEATURE(CPU_FEATURE_PGE))
+set_cr4(get_cr4() | CR4_PGE);
Check my original paging_s
This is a rather large commit, but difficult to break it up.
This also serialises the AP bringup, so paging can be enabled per cpu
one by one.
Also-by: Almudena Garcia
---
i386/i386/cpu_number.h | 2 +
i386/i386/mp_desc.c | 226
i386/i386/mp_desc.h
---
i386/intel/pmap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/i386/intel/pmap.c b/i386/intel/pmap.c
index 84a4cef5..0505cfa2 100644
--- a/i386/intel/pmap.c
+++ b/i386/intel/pmap.c
@@ -2928,6 +2928,7 @@ void pmap_update_interrupt(void)
int s;
my_cpu = cpu_nu
> However, with ncpus>1 and apic enabled, there are warnings spewed
> at beginning of gnumach regarding cpu_number, but doesnt prevent
> continuing to start of boot process.
:-)
Then, the next step (added to little refactors) will be add the APs to
scheduler, using `slave_main()` function.
After
This allows qemu -M q35 to boot without 30 second timeout
failing on hd0, when disk is actually attached via ahci.
I very much doubt a disk exists with 255 physical heads.
---
linux/src/drivers/block/ide.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux/src/drivers/block
This has been rebased onto master and reworked to address review.
Same tests applied as last time, same results as last time.
However, with ncpus>1 and apic enabled, there are warnings spewed
at beginning of gnumach regarding cpu_number, but doesnt prevent
continuing to start of boot process.
Da
---
linux/dev/arch/i386/kernel/irq.c | 12 ++--
linux/dev/init/main.c| 2 ++
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/linux/dev/arch/i386/kernel/irq.c b/linux/dev/arch/i386/kernel/irq.c
index 67feea84..5f221da1 100644
--- a/linux/dev/arch/i386/kernel/irq
---
i386/i386/db_trace.c| 3 ++-
i386/i386at/model_dep.h | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/i386/i386/db_trace.c b/i386/i386/db_trace.c
index 99cb8c48..04c868af 100644
--- a/i386/i386/db_trace.c
+++ b/i386/i386/db_trace.c
@@ -37,6 +37,7 @@
#include
#inc
On Tue, Jan 31, 2023 at 10:54 PM Luca wrote:
> I think it would be possible to handle both a 32-bit and a
> 64-bit userspace at the same time, as in XNU, but we'd need also
> user-space support if we want to integrate 32-bit and 64-bit tasks, and
> this seems a bit more complicated to me (although
On Tue, Jan 31, 2023 at 2:54 PM Luca wrote:
> Hi Sergey,
>
> Il 31/01/23 14:30, Sergey Bugaev ha scritto:
> >> I understand they are related to the x64 bringup, and possibly to
> >> running 32-bit userland on a 64-bit kernel (or to support for 32-bit
> >> tasks communicating with 64-bit tasks?).
31 matches
Mail list logo
