 TermiNexus
|
61208676c6
|
fix(main): _start 加 stackrealign，修复变参函数 movaps #GP
根因链：_start 由 bootloader jmp 进入（rsp≡0 mod 16），编译器/llc 按 call
约定对齐函数帧（假设入口 rsp≡8 mod 16）→ 帧整体偏 8 → _start 内所有调用
rsp≡8 mod 16 → __init__ 的 float 变参调用（snprintf %.2f 保存 xmm）movaps
#GP（cr4.OSFXSR 已启用、地址 16 对齐仍 #GP 正是此因）。
加 t.attr.stackrealign 使 _start 序言动态重对齐栈，与入口约定无关。
|
2026-08-26 20:18:09 +08:00 |
|
|
TermiNexus
|
7b084803f5
|
fix(cpu): 启动早期启用 SSE/FPU，修复 movaps #GP
faulting RSP=0x7d760 16 对齐证明非栈对齐问题，movaps #GP(err=0) 真因是 CR4.OSFXSR 未置位（SSE 未启用）。OVMF 启动后 SSE 默认关闭，变参函数传 float/double 保存 xmm 寄存器时触发。新增 cpu.enable_sse（CR0 清 EM 置 MP + CR4 OSFXSR|OSXMMEXCPT + fninit），main.vp __init__ 开头调用。
|
2026-08-26 19:36:50 +08:00 |
|
|
TermiNexus
|
530c85d6a4
|
fix(main): 移除 BootInfo 局部重声明，修复 memmap 全 0
根因：BootInfo: t.CPtr = self.BootInfo（函数内注解重声明全局名）触发编译器
bug——局部 alloca 创建但从不写入（赋值落全局 @BootInfo），后续 BootInfo.X 读
未初始化局部 → 全 0 → mm.init 收 addr=0/size=0/desc=0 → 走 CMOS fallback →
读到 0xFF → size≈4GB → buddy 分配假内存 → 线程栈 4GB → #PF PANIC。
BootInfo 原始字节转储证实 bootloader 传参正确（mmap=0xde20d60 size=4800
desc=48 fb=0x80000000），纯内核读错。直接使用 global BootInfo 修复。
编译器 bug（注解局部重声明全局名赋值落全局）待 TransPyV 单独修复。
|
2026-08-26 19:26:50 +08:00 |
|
|
TermiNexus
|
87d4e359d8
|
debug(main): 转储 BootInfo 地址处原始 88 字节
BootInfo=0xde20d00 非 NULL 但字段全 0。转储该地址原始字节，区分内存确实全 0
（bootloader 写入未生效/重定位缺失）还是内核读错偏移（布局不匹配）。
|
2026-08-26 19:23:30 +08:00 |
|
|
TermiNexus
|
963e0ed53f
|
debug(main): 打印 BootInfo 指针与 memmap 原始字段
mm.init 收到 addr=0 size=0 desc=0（全部为 0），可能是全局 BootInfo 为 NULL
（读物理 0-24 全 0）或 bootloader 传参异常。mm.init 前打印 BootInfo 指针
本身与 MemmapAddr/MemmapSize/MemmapDescSize/framebuffer_addr 原始值。
|
2026-08-26 19:17:58 +08:00 |
|
|
TermiNexus
|
3995cb9545
|
debug(timer): 门32读回+软int0x20+PIC ISR，一次性区分中断分发路径
LAPIC 配置已确认正常（base/ver/svr/lint0 全部读回正确）但硬件中断仍不达。
新增三段诊断：1) 读回 IDT 门 32 的 base/sel/type；2) 软件 int 0x20 验证
分发路径（门有效→H+返回，门无效→[GP] err=0x20）；3) 读 PIC1 ISR 确认
PIT IRQ0 是否真正到达 PIC 并被响应。
|
2026-08-26 18:42:58 +08:00 |
|
|
TermiNexus
|
ee329c313f
|
fix(apic): early_init 改用 IA32_APIC_BASE EN 位判断，避免 cpuid 误判跳过 init
lint0 读回 0x0（QEMU 复位默认 0x10000）说明此前读的是 RAM，_lapic_base 为 0，
init() 很可能未执行。msr_read 已在前置流程验证可用，改按 MSR bit11 判断更可靠。
main.vp 增补综合诊断：打印 base/version/svr/lint0 重写读回/特性位，一次性区分
init 未执行、MMIO 映射失效、写不粘三种假设。
|
2026-08-26 18:39:07 +08:00 |
|
|
TermiNexus
|
9ff53aa1fa
|
debug(apic): 读回 LINT0 与 APIC BASE MSR，验证 EXTINT 配置是否生效
PIT 正常（cnt=1109）但中断不送达。读回验证：
- lint0=0x700 → EXTINT 未屏蔽（正确）；0x10700 → 被屏蔽；其它 → 写入失败
- apic_base_msr bit11 → APIC 使能状态
用后移除。
|
2026-08-26 18:32:21 +08:00 |
|
|
TermiNexus
|
f675540c64
|
chore(boot): 移除全部中断排查诊断（int20 测试 + T/[T]/D 打印）
定时中断已确认恢复（APIC LINT0=EXTINT）。移除 int 0x20 软件触发测试与
isr32_handler 'T'、timer_handler '[T]'、isr_default 'D' 打印，回归干净
内核，定位 sti 后新出现的 #GP（疑似 int 0x20 测试触发）。
|
2026-08-26 18:19:41 +08:00 |
|
|
TermiNexus
|
3c163a5936
|
debug(boot): sti 后软件触发 int 0x20，二分定位中断不送达
APIC LINT0=EXTINT 已配置但仍无定时中断。加 int 0x20（向量 32）软件触发：
- 有 T → IDT gate 32 正常，问题在 PIT/PIC 硬件送达
- 无 T → IDT/lidt 问题
用后移除。
|
2026-08-26 18:16:09 +08:00 |
|
|
TermiNexus
|
9ec3627a5a
|
fix(boot): 启用 apic.early_init，配置 LINT0=EXTINT 恢复 PIC 定时中断
QEMU/OVMF（UEFI）下本地 APIC 已启用，PIC 外部中断须经 LAPIC LINT0 送达
CPU。apic.init() 将 LINT0 配为 EXTINT（取消屏蔽）；此前 early_init 被注释，
LINT0 保持未配置/屏蔽 → 定时器中断被 APIC 吞掉 → sti 后 timer_msleep 等
不到 ticks 永远挂死（serial.log 停在 "sti done"，T/D 诊断均无输出）。
|
2026-08-26 18:14:29 +08:00 |
|
|
TermiNexus
|
49d074e487
|
通过插件的静态推导修复了一些错误
|
2026-07-30 17:28:27 +08:00 |
|
|
TermiNexus
|
20e7289c61
|
将 .py 和 .pyi 后缀名改为了 .vp 和 .vpi 后缀名
|
2026-07-30 16:34:26 +08:00 |
|