PS/2 keyboard IRQ1 not firing via IOAPIC on physical hardware

[xoyaa48]

Hi everyone,

I'm working on my own x86_64 UEFI kernel and I'm stuck on PS/2 keyboard interrupts.

I've switched over to the LAPIC/IOAPIC and timer interrupts work fine through the IOAPIC, but IRQ1 never fires on my Lenovo Legion or my old Windows tablet. Polling port 0x60 works perfectly and I can read scancodes, but the keyboard interrupt handler is never entered.

I've checked quite a few things already. The LAPIC is enabled, sti is definitely executed, the IOAPIC is found through the MADT, and IRQ1 maps to GSI1 according to the MADT on both QEMU and my tablet. Neither machine has an ACPI interrupt source override for IRQ1. Both also only have a single IOAPIC with GSI base 0.

The PS/2 controller also seems fine. The config byte ends up as 0x65, scanning is enabled (F4 gets an FA ACK), and polling always reads scancodes.

I'm routing it with:

Code: Select all

ioapic_route_irq(acpi_irq_to_gsi(1), 0x21, 0);

Reading the redirection entry back returns exactly the value I wrote:

Code: Select all

high = 0x0, low = 0x21

One thing that's confusing me is that in QEMU, if I print from my interrupt dispatcher, pressing a key enters vector 33 exactly as expected. On my Lenovo and a Windows tablet, though, the interrupt never arrives even though polling still reads every scancode correctly.

At this point I'm wondering if I'm missing some APIC/firmware transition on real hardware (_PIC, IMCR, chipset routing, etc.), or if there's another common mistake in IOAPIC keyboard setup that I've overlooked. Does anything above jump out as obviously wrong?

[songziming]

Did you setup 8042 properly? check https://wiki.osdev.org/I8042_PS/2_Contr ... Controller

This is how I setup keyboard: https://github.com/songziming/wheel/blo ... kbd.c#L247

[xoyaa48]

I updated my initialization to follow the the wiki page more closely: disabling both ports, flushing the output buffer, configuring the controller, running the controller self test, running the keyboard interface test, restoring the controller configuration after the self test, enabling the keyboard port, resetting the keyboard, and then enabling scanning.

Still the same result, everything works in QEMU, but on two different physical machines IRQ1 is never delivered...

One thing I haven't implemented yet is AML, so _PIC is never evaluated. Does your OS evaluate _PIC, or were keyboard interrupts working on real hardware before you had an AML interpreter?

Here's my keyboard driver if anyone can spot something: https://github.com/oyaa48/mangrove/blob ... ard.c#L259

[Octocontrabass]

PS/2 keyboard

Are you sure your devices have PS/2 keyboards?

One thing I haven't implemented yet is AML, so _PIC is never evaluated.

How about USB? The firmware's "USB legacy support" may not be able to route IRQs through APICs. You can try disabling USB legacy support, but you may not be able to re-enable it without a PS/2 keyboard!

[xoyaa48]

I checked in Linux, and the builtin keyboard is detected as an "AT Translated Set 2 keyboard" on /devices/platform/i8042/serio0, and the kernel logs:

Code: Select all

i8042: PNP: PS/2 Controller [PNP0303:KBC0] at 0x60,0x64 irq 1
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard

So it appears to be using the i8042/PS/2 rather than USB just like what QEMU uses. Unfortunately my firmware doesn't expose a "USB Legacy Support" option since it's a newer laptop.

[Octocontrabass]

In that case, you'll need to enumerate PCI and poke the USB host controller(s) to disable legacy support the same way a proper USB host controller driver would.

Or, if you're feeling ambitious, write some proper USB drivers.