Commit graph SchOS/include/mp.h
Author SHA1 Message Date
Nexoniarz
94c936ed98 boot: stop assuming the machine is an emulator
Every one of these works under QEMU and stops a real machine:

- MADT processors that are "online capable" but not enabled were
  counted as CPUs. AMD firmware lists absent cores that way (so does
  QEMU with maxcpus), and startothers() then waited for ever for an
  AP that does not exist. Only enabled entries count now, x2APIC
  (type 9) entries are read too, and the wait is bounded to a second;
  an AP that misses it is parked with INIT and the boot goes on.
- The PIT calibration loop had no bound. Recent boards clock-gate the
  8254: the output never rises (a hang) or floats high (TSC "0 MHz"
  and every clock thousands of times fast). The loop is bounded and
  checked, and falls back to the ACPI PM timer, then CPUID 0x15/0x16.
  Under QEMU pit=off the PM timer gives the same figures the PIT did.
- Firmware that hands over in x2APIC mode left lapic[] reading
  garbage: cpunum() panicked or the timer never started. Each CPU is
  switched back to xAPIC first (x2APIC -> disabled -> xAPIC).
- The IOAPIC was always at 0xFEC00000 and interrupts were aimed at
  APIC ID "0". Both now come from the firmware's tables.
- INIT-to-STARTUP was 100 us ("Bochs is slow"); it is the 10 ms the
  MP specification asks for.
- mouseinit() drained the 8042 with an unbounded loop. With no
  controller the port reads 0xFF and the loop never ends. It now
  notices there is no controller and skips the mouse.

Tested in QEMU: i440fx and q35, -smp 4, -smp 2,maxcpus=4, pit=off.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HH7xukt4aaiGj1nQEAoQf1
2026-10-22 10:29:12 +02:00
Nexoniarz
d0f7acf9eb Initial commit: Schunix as it stands before the SchOS rename
An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.

No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.
2026-08-09 13:47:01 +02:00