ktrace can generate a stack for you from that dump. The line starting with "ktrace" is the command line (you might change 9k8cpu to the path to the kernel file in you're not in the directory where you built it). Then the following lines up to but not including the "cpu0: exiting" can be dropped into ktrace's stdin to have it generate a stack trace. You'll need to add the ^d at the end if you're cut-and-pasting.
Though it looks like it's just triggering the page fault trap on that 0xfffffffffffffc00 address, which itself looks like a victim of sign-extension. So back up to the fault and find the source of that address? Paul On Tue, Jan 28, 2025 at 9:09 AM <tlaro...@kergis.com> wrote: > 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-M550d6760d5cca5e351e89e55 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
