amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.
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 0xd000, 0x30 dimensions 1024 x 768 stride 1024 masks 0x00ff, 0xff00, 0x00ff, 0xff00 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.
On Tue, Dec 29, 2020, 5:07 PM Karel Gardas 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 0xd000, 0x30 > dimensions 1024 x 768 > stride 1024 > masks 0x00ff, 0xff00, 0x00ff, 0xff00 > 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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: amd64 bsp issue on modern Kontron/Fujitsu board: spurious interrupt 7 on attempt to remap PIC.
On 12/30/20 12:17 AM, Joel Sherrill wrote: > I didn't even know the x86_64 port was mature enough to run on real > hardware. > It is, at least hello world and ticker seem to run fine! I'm hacking in multiboot support but more and more tinker with an idea to play with real uefi support. But for this I need to have reference point working on my reference boards -- and unluckily those are those Kontron beauties... > 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 https://wiki.osdev.org/8259_PIC -- I've thought second PIC is hooked to the IRQ2 line of the master... Also since PIC is not remapped, then we probably can't decide if the event happening here is CPU exception or real IRQ right? Anyway, I've forgot to mention that linux/freebsd/openbsd run fine on those boards so in the worst case I would need to debug/printf one of these to find out required trick. Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
