SchOS/kernel/core
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz ff0acfc913 gfx: a framebuffer at physical zero is not a framebuffer
Booting with a virtio-gpu as the *only* display reboot-looped. Not a hang, not
a panic: the firmware came back round to the boot menu, started the loader
again, and did it again, for ever, with nothing to say why.

virtio-gpu has no linear aperture, so OVMF's virtio GOP implements Blt and
nothing else. On a machine with one and nothing else, the firmware reports a
width and a height and a FrameBufferBase of **zero**:

    schos: framebuffer 0x0000000000000000 0x500x0x320

Two places took that at face value.

**kmain() tested `if (bi.ptr && ...)` with bi.ptr already run through P2V()**,
and P2V(0) is KERNBASE, which is not zero. So the guard could not fail -- and
its own comment, three lines above, said "drawing into address zero is a worse
failure than staying quiet". The intent was exactly right and the test could
never enforce it. It reads the physical value first now and tests that.

**vga_fb_init() attached the scanout regardless**, one layer down, so fixing
kmain alone just moved the same write.

Either one had gfx_clear() write four megabytes over physical 0: the real-mode
IVT, the BIOS data area, the AP trampoline at 0x7000, the early page tables.
Hence a reset with no output -- there was nothing left to run.

Both refuse now, and the refusal says what it is:

    vga: firmware reported a 1280x800 display with no framebuffer address;
         no graphical console

A machine with no usable linear framebuffer gets no graphical console. That is
the truth about it, and the serial line still has everything.

**It still does not reach a shell on such a machine**, and that is recorded
rather than implied: the console path assumes a framebuffer -- vt_init()
reports a terminal of `0 by 0` cells -- and that path has never been exercised.
What this fixes is a machine that destroyed low memory and reset; what it does
not do is make a headless boot work. Supported remains stdvga, with virtio-gpu
optional beside it, which is what docs/architecture/graphics.md already said.

Both supported configurations verified: stdvga alone and stdvga with
virtio-gpu, one boot each, no traps, socktest and memfdtest green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-22 14:58:21 +02:00
..
console.c kbd: three layouts, and the arrow keys were sitting on top of UTF-8 2026-09-20 01:09:32 +02:00
dma.c dma: best fit, and say which number is the problem 2026-09-14 21:28:07 +02:00
kalloc.c debugger: who owns this page, and who just wrote to it 2026-09-14 01:17:57 +02:00
klog.c root: find the filesystem instead of being told at build time, and fix dmesg 2026-09-22 01:24:34 +02:00
kmem.c kmem: a slab allocator, and what the fixed tables actually cost 2026-09-22 09:32:06 +02:00
ksym.c debugger: D5, the network transport -- and the plan closes 2026-09-14 15:33:53 +02:00
main.c gfx: a framebuffer at physical zero is not a framebuffer 2026-09-22 14:58:21 +02:00
panic.c branding: one mark, and PSOGM draws it 2026-09-21 21:35:58 +02:00
qr.c Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00
sbuf.c debugger: the kernel can be asked a question 2026-09-14 00:58:45 +02:00
sleeplock.c kernel: holdingsleep asks who holds the lock, not whether anyone does 2026-09-12 17:13:59 +02:00
spinlock.c Fix two bugs the Fedora move exposed 2026-08-09 19:29:21 +02:00
string.c net: the socket layer stops saying yes to things it did not do, and ping works 2026-09-12 17:14:35 +02:00
time.c boot: one line when it works, all of it when it does not 2026-09-14 21:19:50 +02:00
uaccess.c Initial commit: Schunix as it stands before the SchOS rename 2026-08-09 13:47:01 +02:00