Linux thread
Posted: 16 Oct 2025, 15:52
sooo guys, sorry for that rmw post. turned out to be placebo. i was deep into ram tuning, trying different subtimings, and the fps boost on the 14700k just happened to line up with it. but fps are just fps — the core problem stayed.
so, back to the roots. i always return to the d875pbz, that board is my baseline. the one that never had the issue. i compare everything against it and move by elimination. i already ruled out ram behaviour, gpu power states, even pcie mapping. the only consistent difference left was in the chipset — the pch and how it changed everything once intel started merging functions into one chip.
the d875pbz was a clean design. agp slot, northbridge, southbridge, direct irq lines. predictable. the newer boards like i945gc brought acpi 2.0, the io-apic integrated into the chipset, and pci-e instead of agp. on paper it’s progress. in feel, it’s different.
some of you remember that on older Windows builds you could switch in Device Manager between ACPI Uniprocessor PC and Advanced Configuration and Power Interface (ACPI) PC. that wasn’t cosmetic — it changed how HAL routed interrupts. the uniprocessor HAL used simple static mapping, while the full ACPI HAL started sharing and dynamically assigning interrupts between devices. most of my boards from that time had half the system stacked on IRQ 16.
i tried to emulate that old static behaviour again. disabled Message Signaled Interrupts with
bcdedit /set msi ForceDisable
and also switched off MSI in BIOS. doesn’t really make logical sense, but input and that heavy car bug got noticeably better. not perfect, but more consistent.
at that point i had nothing left to try on Windows. i kept thinking — maybe the problem is deeper, maybe modern boards are just too dependent on ACPI tables. MADT, DSDT, FADT — those define device maps, irq routing, power domains, everything. they’re part of the firmware now. editing them by hand is technically possible, but a nightmare. one wrong offset or checksum and the board doesn’t boot. ACPI 2.0 added dynamic routing, power states, hotplug — and i think that’s when the system stopped being deterministic.
so i switched. installed Fedora with the Zen kernel just to see how far Linux gaming has come. tested CS2 on the RTX 4070 Super. fps were lower, around 450, dipping to 350 in 5v5, but the game stayed consistent. that got my attention but i moved to Arch based CachyOs
because i wanted full control over the kernel. The big things Linux allows you , is full control over a kernel and it comes with things disabling I/O-APIC and ACPI routing completely. my current GRUB looks like this:
nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 mitigations=off pcie_aspm=off processor.maxcstate=1 intel_idle.max_cstate=0 pcie_port_pm=off apm=off clk_ignore_unused clocksource=tsc tsc=perfect acpi=noirq noirqbalance nohz=off pci=noacpi noapic pnpbios=off
pcie_aspm=off and pcie_port_pm=off stop the link from retraining mid-load. maxcstate=1 and intel_idle.max_cstate=0 keep cores awake. clocksource=tsc tsc=perfect locks the kernel timer to cpu tsc — no interpolation. acpi=noirq pci=noacpi noapic cut the system off from the firmware’s irq routing, reverting to old PIC-style static interrupts. noirqbalance freezes them in place, so kernel can’t shuffle them around.
PIC-style basically means how interrupts worked before APIC even existed. back in the 90s every device line was hardwired to one of 15 interrupt numbers on a small chip called the Programmable Interrupt Controller (Intel 8259). there was no dynamic balancing, no tables, nothing smart — each device fired its signal directly and the cpu handled it in the same strict order every time. it wasn’t scalable, but it was deterministic.
when APIC came, Intel replaced that simple 8259 logic with a two-layer system: IO-APIC inside the chipset and LAPIC on each core. the IO-APIC collects external device interrupts, translates them into vectors, and sends them to LAPICs over the system bus. LAPICs then deliver them to the cores. that design gave us more IRQs and multicore support, but it also added one more layer of logic between the device and the cpu.
so when you disable IO-APIC and ACPI routing, the kernel falls back to that old PIC mode — every device gets a fixed line, nothing gets remapped, and interrupts go straight to the CPU through LAPIC’s compatibility mode. it’s less “smart,” but there’s no dynamic firmware in the middle deciding where to send each signal. that’s why it feels steadier. LAPIC can still do its own job — handle MSI, timers, per-core stuff — without being told by the chipset how to distribute external events.
in other words, you strip the system down to the bare electrical path: device → lapic → core. no acpi tables, no io-apic translations.
so yeah, a few people asked how the system even boots if i kill acpi like that. the thing is, it doesn’t completely disappear. when you use acpi=noirq pci=noacpi noapic, you’re not removing acpi as a whole — you’re just cutting off the part that handles interrupt routing and pci mapping. the rest of it (like basic cpu info, power tables, thermal zones) still exists, it just stops controlling irq logic.
when linux boots in that state, it falls back to legacy 8259 PIC mode or what’s called lapic compatibility mode. the old MP tables (MultiProcessor spec tables) inside the bios kick in before the kernel even starts, and those define the minimal irq layout — basically a backup routing map that existed before acpi took over. it’s not smart, but it’s enough.
so the chain looks like this: bios posts → fills those old mp or pci routing tables → kernel reads them → sets up 15 fixed irq lines → newer devices that support msi talk straight to the lapic, bypassing all that old chipset routing.
so you end up with a hybrid setup. stuff like sata or some usb controllers go through the old pic style fixed irqs, but gpu, nvme, soundcard, those send interrupts as messages straight to lapic. that’s why it still boots and works fine. the firmware still provides the minimal mapping, linux just ignores the fancy acpi layer and does it the old deterministic way.
basically, i cut the “brain” but kept the “wires”. bios and the kernel handle it like it’s 2003 again — fewer layers, less guessing, and no firmware trying to optimize what doesn’t need optimizing. I don't want to promote any fix but i would love to see more people trying this combo. Stop being lazy or scared of Linux , no one will fix it for you , every post about magical "scaling " trick is bullshit.
AND now the very interesting thing i found is this post from 2009 https://forums.virtualbox.org/viewtopic.php?t=21480 he literally says " After installing Windows 7 I noticed that IO APIC was enabled. This is known to cause slowdown etc. I believe that it has been causing problems with my system (slow mouse response, window interaction, etc).
I was able to force it to be disabled on my guest and the system seems to be much more responsive at this point." Sadly u cant do that on win10/win11 anymore. But if you dont mind about faceit or some games with strict kernel anti-cheat trust me, you won't miss a Windows and you can still use dual boot. Oh , and there is my little fps bench , cachy vs 25h2.https://www.youtube.com/watch?v=u-zVidz9DRM thoose 1% lows are super high if you consider its fucking raptor lake cpu. Rtx was fine but amd drivers are super-b on linux and often match or beat Windows performance in games that have vulkan support or native linux build (but proton is fucking awesome too, for example Mafia Definitive Edition runs through proton and i have few more fps on Linux than on Windows ). So .... yeah, fiddling in device manager wont help you , Linux can be our saviour and if its not , the control you get is making him best OS to test low level hardware control.
so, back to the roots. i always return to the d875pbz, that board is my baseline. the one that never had the issue. i compare everything against it and move by elimination. i already ruled out ram behaviour, gpu power states, even pcie mapping. the only consistent difference left was in the chipset — the pch and how it changed everything once intel started merging functions into one chip.
the d875pbz was a clean design. agp slot, northbridge, southbridge, direct irq lines. predictable. the newer boards like i945gc brought acpi 2.0, the io-apic integrated into the chipset, and pci-e instead of agp. on paper it’s progress. in feel, it’s different.
some of you remember that on older Windows builds you could switch in Device Manager between ACPI Uniprocessor PC and Advanced Configuration and Power Interface (ACPI) PC. that wasn’t cosmetic — it changed how HAL routed interrupts. the uniprocessor HAL used simple static mapping, while the full ACPI HAL started sharing and dynamically assigning interrupts between devices. most of my boards from that time had half the system stacked on IRQ 16.
i tried to emulate that old static behaviour again. disabled Message Signaled Interrupts with
bcdedit /set msi ForceDisable
and also switched off MSI in BIOS. doesn’t really make logical sense, but input and that heavy car bug got noticeably better. not perfect, but more consistent.
at that point i had nothing left to try on Windows. i kept thinking — maybe the problem is deeper, maybe modern boards are just too dependent on ACPI tables. MADT, DSDT, FADT — those define device maps, irq routing, power domains, everything. they’re part of the firmware now. editing them by hand is technically possible, but a nightmare. one wrong offset or checksum and the board doesn’t boot. ACPI 2.0 added dynamic routing, power states, hotplug — and i think that’s when the system stopped being deterministic.
so i switched. installed Fedora with the Zen kernel just to see how far Linux gaming has come. tested CS2 on the RTX 4070 Super. fps were lower, around 450, dipping to 350 in 5v5, but the game stayed consistent. that got my attention but i moved to Arch based CachyOs
because i wanted full control over the kernel. The big things Linux allows you , is full control over a kernel and it comes with things disabling I/O-APIC and ACPI routing completely. my current GRUB looks like this:
nowatchdog nvme_load=YES zswap.enabled=0 splash loglevel=3 mitigations=off pcie_aspm=off processor.maxcstate=1 intel_idle.max_cstate=0 pcie_port_pm=off apm=off clk_ignore_unused clocksource=tsc tsc=perfect acpi=noirq noirqbalance nohz=off pci=noacpi noapic pnpbios=off
pcie_aspm=off and pcie_port_pm=off stop the link from retraining mid-load. maxcstate=1 and intel_idle.max_cstate=0 keep cores awake. clocksource=tsc tsc=perfect locks the kernel timer to cpu tsc — no interpolation. acpi=noirq pci=noacpi noapic cut the system off from the firmware’s irq routing, reverting to old PIC-style static interrupts. noirqbalance freezes them in place, so kernel can’t shuffle them around.
PIC-style basically means how interrupts worked before APIC even existed. back in the 90s every device line was hardwired to one of 15 interrupt numbers on a small chip called the Programmable Interrupt Controller (Intel 8259). there was no dynamic balancing, no tables, nothing smart — each device fired its signal directly and the cpu handled it in the same strict order every time. it wasn’t scalable, but it was deterministic.
when APIC came, Intel replaced that simple 8259 logic with a two-layer system: IO-APIC inside the chipset and LAPIC on each core. the IO-APIC collects external device interrupts, translates them into vectors, and sends them to LAPICs over the system bus. LAPICs then deliver them to the cores. that design gave us more IRQs and multicore support, but it also added one more layer of logic between the device and the cpu.
so when you disable IO-APIC and ACPI routing, the kernel falls back to that old PIC mode — every device gets a fixed line, nothing gets remapped, and interrupts go straight to the CPU through LAPIC’s compatibility mode. it’s less “smart,” but there’s no dynamic firmware in the middle deciding where to send each signal. that’s why it feels steadier. LAPIC can still do its own job — handle MSI, timers, per-core stuff — without being told by the chipset how to distribute external events.
in other words, you strip the system down to the bare electrical path: device → lapic → core. no acpi tables, no io-apic translations.
so yeah, a few people asked how the system even boots if i kill acpi like that. the thing is, it doesn’t completely disappear. when you use acpi=noirq pci=noacpi noapic, you’re not removing acpi as a whole — you’re just cutting off the part that handles interrupt routing and pci mapping. the rest of it (like basic cpu info, power tables, thermal zones) still exists, it just stops controlling irq logic.
when linux boots in that state, it falls back to legacy 8259 PIC mode or what’s called lapic compatibility mode. the old MP tables (MultiProcessor spec tables) inside the bios kick in before the kernel even starts, and those define the minimal irq layout — basically a backup routing map that existed before acpi took over. it’s not smart, but it’s enough.
so the chain looks like this: bios posts → fills those old mp or pci routing tables → kernel reads them → sets up 15 fixed irq lines → newer devices that support msi talk straight to the lapic, bypassing all that old chipset routing.
so you end up with a hybrid setup. stuff like sata or some usb controllers go through the old pic style fixed irqs, but gpu, nvme, soundcard, those send interrupts as messages straight to lapic. that’s why it still boots and works fine. the firmware still provides the minimal mapping, linux just ignores the fancy acpi layer and does it the old deterministic way.
basically, i cut the “brain” but kept the “wires”. bios and the kernel handle it like it’s 2003 again — fewer layers, less guessing, and no firmware trying to optimize what doesn’t need optimizing. I don't want to promote any fix but i would love to see more people trying this combo. Stop being lazy or scared of Linux , no one will fix it for you , every post about magical "scaling " trick is bullshit.
AND now the very interesting thing i found is this post from 2009 https://forums.virtualbox.org/viewtopic.php?t=21480 he literally says " After installing Windows 7 I noticed that IO APIC was enabled. This is known to cause slowdown etc. I believe that it has been causing problems with my system (slow mouse response, window interaction, etc).
I was able to force it to be disabled on my guest and the system seems to be much more responsive at this point." Sadly u cant do that on win10/win11 anymore. But if you dont mind about faceit or some games with strict kernel anti-cheat trust me, you won't miss a Windows and you can still use dual boot. Oh , and there is my little fps bench , cachy vs 25h2.https://www.youtube.com/watch?v=u-zVidz9DRM thoose 1% lows are super high if you consider its fucking raptor lake cpu. Rtx was fine but amd drivers are super-b on linux and often match or beat Windows performance in games that have vulkan support or native linux build (but proton is fucking awesome too, for example Mafia Definitive Edition runs through proton and i have few more fps on Linux than on Windows ). So .... yeah, fiddling in device manager wont help you , Linux can be our saviour and if its not , the control you get is making him best OS to test low level hardware control.