OSDev.org

Hi,

I'm working with RTEMS RTOS on amd64 platform. Using x86_64/amd64 BSP. The BSP is really as simple as possible and supports just UART in polling mode and local APIC based timers, nothing more. Also the BSP author is using a lot of code more or less copy of the code provided on this web site: E.g. https://wiki.osdev.org/8259_PIC.

The BSP runs fine on several amd64 computers:
- supermicro x9sra + e5-2620
- fujitsu tx1320m1 + e3-1220

but it refuses to run on:
- kontron/fujitsu d3598-b13 either with w-2265 or w-2123. I have two boards with those cpus, both exhibit the same behavior. The boards do have w422 chipset and one of them has the newest BIOS another just version older, but still from summer 2020 so nothing that outdated. In comparison with the working boards above, both boards supports newer UEFI/ACPI. Certainly ACPI is 6.x here if that is important. Also BSP example is booted/run from the FreeBSD loader which itself is installed/boots as UEFI setup and not plain old BIOS setup. The BSP is a bit documented here: https://docs.rtems.org/branches/master/ ... 86_64.html

The issue is that when BSP code tries to remap PIC, on the first command issue to PIC1, I get spurious interrupt 7. This happens on this line of code:

outport_byte(PIC1_COMMAND, PIC_ICW1_INIT | PIC_ICW1_ICW4);

which is the line copied from:

outb(PIC1_COMMAND, ICW1_INIT | ICW1_ICW4); // starts the initialization sequence (in cascade mode)

My question is: how is that possible? What's the reason I get spurious interrupt just on the attempt to remap PIC? Has anybody seen this already anywhere else? I'm curious under which condition it may happen so I can fix BSP to run well also on those kontron boards...

Thanks for any idea!
Karel

Also curious about this problem, noticed this behavior on one of my laptops.

Your use of 1GiB pages may cause undefined behavior. Refer to section 11.11.9 "Large Page Size Considerations" in volume 3A of the Intel SDM.

I see usable memory is not dynamically detected. Does that mean you're not parsing the memory map provided by the firmware? You must parse the memory map to determine where usable memory exists. Attempting to use memory that is not marked usable in the memory map may cause all kinds of strange behavior.


Does the PIC exist? (Check the MADT.)

Are any other interrupt controllers enabled?

What happens if you disable interrupts (CLI) before remapping the PIC?