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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel