Reboot while unmasking the PIC

[IanSeyler]

I am running into an odd problem with booting up some new multi-core machines. As soon as the code below runs it causes the machine to reboot.

Inserting a 'CLI' before it doesn't help even though interrupts are already disabled earlier on.

Code: Select all

	; Enable specific interrupts
	in al, 0x21
	mov al, 11111001b		; Enable Cascade, Keyboard
	out 0x21, al
	in al, 0xA1
	mov al, 11111110b		; Enable RTC
	out 0xA1, al

Everything checked out on my 16-core AMD but a 32-core and 64-core both reboot. It does seem that the Timer interrupt works correctly in Pure64 so I know the PIC is ok. The code above is from BareMetal OS.

Thanks,
-Ian

[jbemmel]

What's the IOPL the code is running at?

[M2004]

ReturnInfinity: Have you tried to test whether the problem is interrupt specific?
Enabling/disabling each interrupt one at a time.

Regards
Mac2004

[Owen]

What do the ACPI tables say with regards to the machine's legacy hardware?

Its entirely plausible that the machine only has enough PIC support to pretend to the legacy BIOS code that there's a timer, and that the machine doesn't even claim to have a keyboard controller, etc.

Particularly the missing keyboard controller is a good one. Many machines, I/O to the conventional keyboard controller port will do nasty things to the embedded controller.

[IanSeyler]

This was kernel code and any change to the PIC mask caused a reboot. I was using Pure64 v0.4.9 and have now switched over to v0.5.1 (which uses the IO-APIC for interrupts instead of the PIC). Everything seems to be working now on the 32-core. I will test the 64-core later.

-Ian

[IanSeyler]

The 64-core works as well. Let this be a lesson to dump the PIC and go with the IO-APIC!

Now if only the Intel 82576 was fully reverse-compatible with the 8254x instead of just partially...

-Ian