amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.

[Karel Gardas]

Hi,

I'm playing with amd64/x86_64 bsp and found out it is not working on my
Fujitsu/Kontron D3598-B13 boards. I do have two of this kind. One runs
with W-2123 and one with W-2265 xeon.

The code I'm using is 2 days old from git. The tooling too.

The issue shows as:


Type '?' for a list of commands, 'help' for more detailed help.
OK boot /boot/kernel/rtems/ticker.exe
Loading kernel...
/boot/kernel/rtems/ticker.exe text=0x116008 data=0xc10+0x7a50
data=0x0+0x2000 syms=[0x8+0x6228+0x8+0x4ca1]
Loading configured modules...
/boot/entropy size=0x1000
/etc/hostid size=0x25
Start @ 0x1001d0 ...
EFI framebuffer information:
addr, size     0xd0000000, 0x300000
dimensions     1024 x 768
stride         1024
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
spurious interrupt: 7
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13spurious interrupt: 0

spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13
spurious interrupt: 13


I've verified the same ticker.exe binary runs fine on Supermicro X9SRA
with E5-2620 and on Fujitsu TX1320M1 with E3-1220v3. Kontron/Fujitsu
D3598-B13 is the newest board I'm using here. It has newest UEFI/ACPI
spec impl from those tested.

I've enabled debugging by adding printf here and there and I've been
able to hunt the issue down to the problematic code line which is inside
the pic.c, pic_remap function, the line is:

  outport_byte(PIC1_COMMAND, PIC_ICW1_INIT | PIC_ICW1_ICW4);

this is basically the first line which tries to communicate with i8259
PIC by issuing some command to it. Up to this line, I'm able to follow
up BSP/ticker.exe execution by using debug messages. I've never been
able to pass this line due to spurious interrupt complains above.

When I comment out whole pic_remap call inside the clock.c, then I'm
able to run ticker.exe on this board successfully.

My question here is: has anybody here seen such strange behavior? My
idea here is that first spurious report is crucial and perhaps it's a
bit buggy causing general protection fault reported as spurious int 13
later in a loop. But why I get #7 at all is mystery to me.

Any idea why is this happening is highly appreciated!

Thanks,
Karel