ACPICA and PS/2 hang during initialisation when using SMP
Posted: Thu Sep 03, 2020 7:34 am
I've been trying to get my OS to work on real hardware. I am encountering a problem where the computer completely hangs when either ACPICA or PS/2 are initialized, but only if I've enabled SMP (i.e. started the application processors).
The computer hangs when ACPICA tries to write the byte 0xA0 to IO port 0x00B2, which is supposed to enable ACPI mode. (Although, ~20% of the time it works just fine). The computer also hangs when my PS/2 driver tries to write the byte 0xAD (disable keyboard) to IO port 0x0064 (command port). This is the first time I try to write to this port. The hang happens regardless of whether I've completed the BIOS/OS handoff sequence with the XHCI controller.
When SMP is not enabled, neither IO port write hangs the system. After either IO port write with SMP enabled, the CPU that performed the write does not make any further progress, and the other CPUs stop receiving their regular timer interrupts, so I don't know what they're doing.
I've tested the same code on a few other computers, but none of them experience the same issue.
I'm at a loss as to what might cause this behaviour. I suspect it may be related to System Management Mode, but how would SMP affect that? The only other thread running this early on in kernel initialisation is a memory-zeroing thread - and surely that couldn't affect SMM?
The computer hangs when ACPICA tries to write the byte 0xA0 to IO port 0x00B2, which is supposed to enable ACPI mode. (Although, ~20% of the time it works just fine). The computer also hangs when my PS/2 driver tries to write the byte 0xAD (disable keyboard) to IO port 0x0064 (command port). This is the first time I try to write to this port. The hang happens regardless of whether I've completed the BIOS/OS handoff sequence with the XHCI controller.
When SMP is not enabled, neither IO port write hangs the system. After either IO port write with SMP enabled, the CPU that performed the write does not make any further progress, and the other CPUs stop receiving their regular timer interrupts, so I don't know what they're doing.
I've tested the same code on a few other computers, but none of them experience the same issue.
I'm at a loss as to what might cause this behaviour. I suspect it may be related to System Management Mode, but how would SMP affect that? The only other thread running this early on in kernel initialisation is a memory-zeroing thread - and surely that couldn't affect SMM?