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

[Joel Sherrill]

On Tue, Dec 29, 2020, 5:07 PM Karel Gardas <karel.gardas at centrum.cz> wrote:

>
> 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!
>

I didn't even know the x86_64 port was mature enough to run on real
hardware.

On the old PC PIC, irq 7 was the daisy chain from one 8259 to the other a d
some hardware was prone to spurious interrupts. Google for "spurious irq
7". It may mean irq 13 (on the second 8259) has an interrupt at program
start which should be cleared. But that's a guess

>
> Thanks,
> Karel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201229/cb95b6df/attachment.html>