El martes 20 de junio de 2023, Samuel Thibault escribió:
> Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit:
> > phystokv will doesn't solve fully the problem, because the lapic address is
> > out of the range allowed by this function.
>
> Ah, right.
>
> > Currently, we are using
Almudena Garcia, le lun. 19 juin 2023 18:35:51 +, a ecrit:
> phystokv will doesn't solve fully the problem, because the lapic address is
> out of the range allowed by this function.
Ah, right.
> Currently, we are using paging to map every ACPI table which we need to
> access (to get a virtu
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
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
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 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,
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 Linux drivers
>
> I believe the ACPI tables nee
Hi,
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 Linux drivers
I believe the ACPI tables need temporary low memory mapping to access them.
Also, the commit:
* 54a4ca2
10 matches
Mail list logo
