Hi Luca,
On 20/6/23 05:40, l...@orpolo.org wrote:
> and at this stage the lapic pointer is not yet initialized:
>
> (gdb) p lapic
> $4 = (volatile ApicLocalUnit *) 0x0
> (gdb) x &lapic
> 0xc109bc6c : 0x
>
> I guess so far this worked because the address 0 was mapped, and now it
> isn't
Guy-Fleury Iteriteka writes:
> On June 19, 2023 10:00:32 PM GMT+02:00, Janneke Nieuwenhuizen
> wrote:
>>Hi!
>>
>>The rumpkernel archive is ridiculously large. It manages to grow so big
>>mainly by adopting the evil practice of bundling other packages. The
>>archive contains copies of many GNU
On June 19, 2023 10:00:32 PM GMT+02:00, Janneke Nieuwenhuizen
wrote:
>Hi!
>
>The rumpkernel archive is ridiculously large. It manages to grow so big
>mainly by adopting the evil practice of bundling other packages. The
>archive contains copies of many GNU utilities, a copy of llvm, and even
>a
Maybe add a little conditional in the assembly code (return 0 if lapic is 0,
using cmp and je) could fix the problem in a simpler way
El lunes 19 de junio de 2023, l...@orpolo.org escribió:
> Il 19/06/23 20:35, Almudena Garcia ha scritto:
> > But the code which starts the secondary cpus is so muc
Il 19/06/23 21:40, l...@orpolo.org ha scritto:
and at this stage the lapic pointer is not yet initialized:
(gdb) p lapic
$4 = (volatile ApicLocalUnit *) 0x0
(gdb) x &lapic
0xc109bc6c : 0x
I guess so far this worked because the address 0 was mapped, and now it
isn't.
I'm not sure w
Hi!
The rumpkernel archive is ridiculously large. It manages to grow so big
mainly by adopting the evil practice of bundling other packages. The
archive contains copies of many GNU utilities, a copy of llvm, and even
a copy of postfix.
The archive can most probably be pruned a lot further witho
Il 19/06/23 20:35, Almudena Garcia ha scritto:
But the code which starts the secondary cpus is so much later than the crash.
Then, the crash could be produced by the reading of ACPI tables, which are
supposed to be in a certain memory region, defined by a physical address.
phystokv will doesn'
But the code which starts the secondary cpus is so much later than the crash.
Then, the crash could be produced by the reading of ACPI tables, which are
supposed to be in a certain memory region, defined by a physical address.
phystokv will doesn't solve fully the problem, because the lapic add
Hi,
Il 19/06/23 19:53, Almudena Garcia ha scritto:
The cpus are started sequentially: don't start the next until the current has
finished its configuration.
in this case I think it's not needed to have a per-cpu bootstrap stack,
assuming the secondary cpu already runs a proper thread (i.e. K
Hi:
The cpus are started sequentially: don't start the next until the current has
finished its configuration.
But your idea is good
Thanks
El lunes 19 de junio de 2023, Luca Dariz escribió:
> Il 17/06/23 23:12, Samuel Thibault ha scritto:
> > Luca Dariz, le jeu. 15 juin 2023 23:49:30 +0200,
Il 17/06/23 23:12, Samuel Thibault ha scritto:
Luca Dariz, le jeu. 15 juin 2023 23:49:30 +0200, a ecrit:
diff --git a/i386/i386/ktss.c b/i386/i386/ktss.c
index 1d880167..52f3722c 100644
--- a/i386/i386/ktss.c
+++ b/i386/i386/ktss.c
@@ -61,6 +61,7 @@ ktss_fill(struct task_tss *myktss, struct real
Hi,
Il 18/06/23 22:52, Samuel Thibault ha scritto:
Hello,
Damien Zammit, le dim. 18 juin 2023 00:48:15 +, a ecrit:
Almu and I discovered that the following commit breaks --enable-apic
--enable-ncpus= >1 --disable-linux-groups
* d972c01c pmap: only map lower BIOS memory 1:1 when using
Hello,
On Mon, Jun 19, 2023 at 12:55 AM Samuel Thibault
wrote:
> > Samuel, what do you think?
>
> It looks better to me to add a shared helper that adds O_IGNORE_CTTY
> whenever the flags contain something that implies it. Callers of
> _hurd_intern_fd / _hurd_port2fd can then easily use it
That'
13 matches
Mail list logo
