On Tue, Jan 28, 2025 at 07:49:02AM -0800, Paul Lalonde wrote:
> Do you have a stack for the assert, from the ktrace?
>
Yes, and I was wrong: it fails relatively "late" in main.c: at
mpsinit.
Here is the info (I added a bunch of print() before each function call
to know where it stumbled upon an incorrect address):
term% nix/test_vmx
NIX
mmunit...mmuinit: vmstart 0xfffffffff0000000 vmunused 0xfffffffff023d000
vmunmapped 0xfffffffff0400000 vmend 0xfffffffff4000000
sys->pd 0x108003 0x108023
cpu0: mmu l3 pte 0xfffffffff0106ff8 = 107023
cpu0: mmu l2 pte 0xfffffffff0107ff8 = 108023
cpu0: mmu l1 pte 0xfffffffff0108c00 = e3
cpu0: mmu l1 pte 0xfffffffff0108c00 = e3
ioinit... multibootmemassert... kbdinit... meminit...asm: addr
0x0000000004000000 end 0x0000000004000000 type 1 size 0
cm 0: addr 0x4000000 npage 0
0 0 0
npage 0 upage 0 kpage 16384
confinit... archinit... mallocinit...base 0xfffffffff023d000 ptr
0xfffffffff023d000 nunits 4047617
acpiinit... umeminit... trapinit... printinit... i8259init... procinit...
mpsinit...panic: cpu0: map.c:KADDR() passed addr fffffffffffffc00 >=
fffffe0000000000
panic: cpu0: map.c:KADDR() passed addr fffffffffffffc00 >= fffffe0000000000
dumpstack
ktrace 9k8cpu 0xfffffffff011cdee 0xfffffffff0105d58
estackx 0xfffffffff0106000
0xfffffffff0105c70=0xfffffffff0105da8
0xfffffffff0105c78=0xfffffffff011cb91
0xfffffffff0105c80=0xfffffffff0105c98
0xfffffffff0105c98=0xfffffffff013cff7
0xfffffffff0105cb0=0xfffffffff0105cd0
0xfffffffff0105cc0=0xfffffffff0105ea7
0xfffffffff0105cc8=0xfffffffff0105df3
0xfffffffff0105ce0=0xfffffffff013d14d
0xfffffffff0105d08=0xfffffffff0105d90
0xfffffffff0105d28=0xfffffffff011cdee
0xfffffffff0105d30=0xfffffffff0105da8
0xfffffffff0105d40=0xfffffffff0105d58
0xfffffffff0105d48=0xfffffffff0105da8
0xfffffffff0105d50=0xfffffffff011cdee
0xfffffffff0105d58=0xfffffffff011cb99
0xfffffffff0105d68=0xfffffffff013d50f
0xfffffffff0105d88=0xfffffffff0105ed0
0xfffffffff0105d90=0xfffffffff013cff7
0xfffffffff0105d98=0xfffffffff0105db5
0xfffffffff0105e08=0xfffffffff013d1b8
0xfffffffff0105e10=0xfffffffff0105e00
0xfffffffff0105e20=0xfffffffff0105ea3
0xfffffffff0105e28=0xfffffffff0105e98
0xfffffffff0105e38=0xfffffffff013d1b8
0xfffffffff0105e40=0xfffffffff0105e98
0xfffffffff0105e60=0xfffffffff013d217
0xfffffffff0105e68=0xfffffffff015d9c9
0xfffffffff0105e80=0xfffffffff0105fb8
0xfffffffff0105e90=0xfffffffff015d5d9
0xfffffffff0105ea8=0xfffffffff0105ed0
0xfffffffff0105ec0=0xfffffffff0116a3b
0xfffffffff0105ef8=0xfffffffff012fe55
0xfffffffff0105f08=0xfffffffff01a1afa
0xfffffffff0105f10=0x0000000000000004
0xfffffffff0105f18=0x0000000000000046
0xfffffffff0105f20=0xfffffffff00fffd9
0xfffffffff0105f28=0x0000000000000006
0xfffffffff0105f30=0xfffffffff015d5d9
0xfffffffff0105f38=0xfffffffff0000400
0xfffffffff0105f40=0x0000000000000000
0xfffffffff0105f48=0xfffffffff012fec9
0xfffffffff0105f50=0xfffffffff01a1aff
0xfffffffff0105f58=0x0000000000000208
0xfffffffff0105f60=0x0000000000000124
0xfffffffff0105f68=0xfffffffff01149d0
0xfffffffff0105f70=0x0000000000000006
0xfffffffff0105f78=0xfffffffff0114ba7
0xfffffffff0105f80=0xfffffffff0227510
0xfffffffff0105f88=0xffffffff00000000
0xfffffffff0105f90=0x0000000000000000
0xfffffffff0105f98=0xfffffffff0105fb8
0xfffffffff0105fa0=0x0000000bf0116b0d
0xfffffffff0105fa8=0xfffffffff011622a
0xfffffffff0105fb0=0xffffffff00000400
0xfffffffff0105fb8=0xffffffff00000000
0xfffffffff0105fc0=0x0000000000000000
0xfffffffff0105fc8=0x0000000000000000
0xfffffffff0105fd0=0x0000000000000000
0xfffffffff0105fd8=0x0000000000000000
0xfffffffff0105fe0=0x0000000000000000
0xfffffffff0105fe8=0xfffffffff0110204
0xfffffffff0105ff0=0x000000002badb002
0xfffffffff0105ff8=0x000000000023b000
cpu0: exiting
>
>
> On Tue, Jan 28, 2025 at 6:09?AM <tlaro...@kergis.com> wrote:
>
> > After fixing problems leading to compiler warnings---legitimate
> > warnings, but even the too short binary negated unsigned 32bits values
> > promoted to 64 bits with leading bits hence 0 as mask were harmless---
> > now I want to look at the stumbing block.
> >
> > For me, under vmx, this is the assert in map.c:17:
> >
> > assert(pa < KSEG2);
> >
> > that triggers, and it should come from a call from multiboot.
> >
> > My first reflex is to start adding printf() instructions to track the
> > problem, but is there a better way when dealing with the kernel?
> >
> > Second question: since, if I'm not mistaken, 9front doesn't use
> > multiboot, is vmx usable (i.e. agnostic about) with the multiboot stuff?
> > The embedded boot stuff should handle the thing by itself without load
> > addresses having to be adjusted because of vmx?
> > --
> > Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
> > http://www.kergis.com/
> > http://kertex.kergis.com/
> > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T8b5b89fcf829819e-Mfd99b750d696a1d8ec93a9d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
