OSDev.org

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?

nakst wrote: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?

My guess is that AP startup puts the firmware into a state where it thinks the OS that is running is modern, and so changes its behavior for the PS/2 emulation. I would suggest ditching PS/2 support until you have working EHCI/xHCI drivers and can talk to USB mouse and keyboard. That should disable buggy SMM emulation and actually show you whether or not a real PS/2 controller/device is present. However, there is also the possibility that your memory-zeroing thread is zeroing memory it's not supposed to, like memory the firmware still needs. Maybe to do things for PS/2 emulation. That would also explain the hang when enabling ACPI. So maybe zeroing random memory is not the best idea.

nakst wrote:I suspect it may be related to System Management Mode,

It definitely is.

nakst wrote:but how would SMP affect that?

Firmware is stupid. It probably expects you to do something specific before you start the APs, like calling _PIC(1) or INT 0x15 EAX=0xEC00.

Also, if the FADT says there's no PS/2 keyboard controller and you try poking it anyway, bad things can happen.

nakst wrote:The only other thread running this early on in kernel initialisation is a memory-zeroing thread - and surely that couldn't affect SMM?

You're not zeroing anything the firmware might use, right?

Octocontrabass wrote:

nakst wrote:I suspect it may be related to System Management Mode,

It definitely is.

nakst wrote:but how would SMP affect that?

Firmware is stupid. It probably expects you to do something specific before you start the APs, like calling _PIC(1) or INT 0x15 EAX=0xEC00.

Also, if the FADT says there's no PS/2 keyboard controller and you try poking it anyway, bad things can happen.

nakst wrote:The only other thread running this early on in kernel initialisation is a memory-zeroing thread - and surely that couldn't affect SMM?

You're not zeroing anything the firmware might use, right?

What is your motherboard/firmware @nullplan? I've had similar issues with ACPICA, and I never thought to try putting the ACPi initialisation before the AP startup...

bellezzasolo wrote:What is your motherboard/firmware @nullplan? I've had similar issues with ACPICA, and I never thought to try putting the ACPi initialisation before the AP startup...

Erm... I'm not the OP. Did you want to ask nakst that? Anyway, AP startup must necessarily happen after ACPI initialization since ACPI initialization tells you about the other CPUs (that was the stuff in the MADT).

My guess is that AP startup puts the firmware into a state where it thinks the OS that is running is modern, and so changes its behavior for the PS/2 emulation. I would suggest ditching PS/2 support until you have working EHCI/xHCI drivers and can talk to USB mouse and keyboard. That should disable buggy SMM emulation and actually show you whether or not a real PS/2 controller/device is present.

You can see my BIOS/OS handoff code for XHCI here: https://bitbucket.org/nakst/essence/src ... #lines-793. Attempting to access the PS/2 controller before or after initializing XHCI though does not make a difference, as I noted in my original post.

However, there is also the possibility that your memory-zeroing thread is zeroing memory it's not supposed to, like memory the firmware still needs. Maybe to do things for PS/2 emulation. That would also explain the hang when enabling ACPI. So maybe zeroing random memory is not the best idea.

It's not zeroing "random memory"; it's zeroing memory returned in the 0xE820 memory map. There might be a bug causing the memory map to get corrupted, and although I find this unlikely, I can't think of anything else that could be going wrong. I'll add some more checks just in case.

Firmware is stupid. It probably expects you to do something specific before you start the APs, like calling _PIC(1) or INT 0x15 EAX=0xEC00.

I tried calling INT 0x15 0xEC00, but it didn't make a difference.

Also, if the FADT says there's no PS/2 keyboard controller and you try poking it anyway, bad things can happen.

I don't check the FADT yet, but since I have a PS/2 keyboard connected to this computer that Windows and Linux detect as a PS/2 keyboard, am I safe to assume that this computer does have a PS/2 controller?

What is your motherboard/firmware

"Intel Corporation 100 Series/C230 Series"

Anyway, AP startup must necessarily happen after ACPI initialization since ACPI initialization tells you about the other CPUs (that was the stuff in the MADT).

Since the ACPICA function AcpiFindRootPointer is "always available, regardless of the initialization state of the rest of ACPICA", it seems the kernel is expected to want access to some ACPI tables before ACPI is fully initialized. I did try moving AP startup after ACPI initialization, but then I discovered that shutdown (going to sleep state 5) also hangs (which didn't happen when I disabled SMP). I need to investigate exactly where this hang occurred though. And this doesn't help solve the PS/2 initialization problem, regardless.