Hi,
in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360 (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to start the different cores of the processor (I'm using the latest published l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build with this command
make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64"
The ISO image boots fine on another amd64 system. After adding some printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get stuck with this call:
// Send IPI-Sequency to startup the APs Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page);
as it does not return anymore ... any hint how to debug this or drill down to get more information and the AtomC3558 system to boot?
Thanks
Andreas
L4 Bootstrapper Build: #2 Mon Dec 14 12:09:54 PST 2020, x86-64, 7.5.0 RAM: 0000000000000000 - 00000000000997ff: 614kB RAM: 0000000000100000 - 000000003e2dffff: 1017728kB RAM: 000000003e300000 - 0000000078762fff: 954764kB RAM: 0000000078773000 - 000000007de44fff: 88904kB RAM: 000000007f34b000 - 000000007f7fffff: 4820kB RAM: 0000000100000000 - 000000087fffffff: 31457280kB Total RAM: 32738MB Scanning fiasco -serial_esc Scanning sigma0 Scanning moe --init=rom/hello need 272 bytes to copy MBI reserved 272 bytes at 0x2000 Moving up to 5 modules behind 1100000 moving module 00 { 1021000-1246617 } -> { 119b000-13c0617 } [2250264] moving module 04 { 170000-19b95f } -> { 116f000-119a95f } [178528] moving module 03 { 152000-16f72f } -> { 1151000-116e72f } [120624] moving module 02 { 10e000-15175f } -> { 110d000-115075f } [276320] moving module 01 { 101000-10d48f } -> { 1100000-110c48f } [50320] Loading fiasco Loading sigma0 Loading moe find kernel info page... found kernel info page (via ELF) at 400000 Regions of list 'regions' [ 0, fff] { 1000} Arch BIOS [ 1000, 1fff] { 1000} Kern fiasco [ 2000, 210f] { 110} Root mbi_rt [ 99800, 9ffff] { 6800} Arch BIOS [ e0000, fffff] { 20000} Arch BIOS [ 100000, 11247f] { 12480} Sigma0 sigma0 [ 140000, 18007f] { 40080} Root moe [ 182038, 1940e7] { 120b0} Root moe [ 2d0400, 2e1257] { 10e58} Boot bootstrap [ 300000, 34afff] { 4b000} Kern fiasco [ 400000, 62efff] { 22f000} Kern fiasco [ 1019000, 101efff] { 6000} Boot bootstrap-ptab64 [ 1151000, 119afff] { 4a000} Root Module [ 3e2e0000, 3e2fffff] { 20000} Arch BIOS [ 78763000, 78772fff] { 10000} Arch BIOS [ 7de45000, 7df1cfff] { d8000} Arch BIOS [ 7df1d000, 7df99fff] { 7d000} Arch BIOS [ 7df9a000, 7e3aafff] { 411000} Arch BIOS [ 7e3ab000, 7f34afff] { fa0000} Arch BIOS [ 7f800000, 7fffffff] { 800000} Arch BIOS [ e0000000, efffffff] { 10000000} Arch BIOS [ fd000000, fe7fffff] { 1800000} Arch BIOS [ ff000000, ffffffff] { 1000000} Arch BIOS found kernel options (via ELF) at 401000 Sigma0 config ip:00000000001004a0 sp:0000000000000000 Roottask config ip:00000000001419ed sp:0000000000000000 Starting kernel fiasco at 0000000000300910
Welcome to L4/Fiasco.OC! L4/Fiasco.OC microkernel on amd64 Rev: unknown compiled with gcc 7.5.0 for x86-64 [] Build: #7 Mon Dec 14 11:40:53 PST 2020
Performance-critical config option(s) detected: CONFIG_NDEBUG is off
Superpages: yes Kmem:: TSS mem at 8053f9000 (4096Bytes) VMX: enabled VMX: EPT supported VMX: initialized ACPI: RSDP[0xf05b0] r02 OEM:ALASKA FPU0: SSE ACPI: FACS phys=7e3a9080 virt=0x203a9080 ACPI: HW sig=cd SERIAL ESC: allocated IRQ 4 for serial uart VMX: init page sizes SERIAL ESC: allocated IRQ 4 for serial uart Not using serial hack in slow timer handler. CPU[0]: GenuineIntel (6:5F:1:0)[000506f1] Model: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz at 2199MHz
Freeing init code/data: 20480 bytes (5 pages)
MP: detecting APs... After tramp_page
Hi Andreas,
On Mon Dec 14, 2020 at 15:35:08 -0800, Andreas Steinmetzler wrote:
in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360 (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to start the different cores of the processor (I'm using the latest published l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build with this command
make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64"
The ISO image boots fine on another amd64 system. After adding some printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get stuck with this call:
// Send IPI-Sequency to startup the APs Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page);
as it does not return anymore ... any hint how to debug this or drill down to get more information and the AtomC3558 system to boot?
The first thing I'd check is whether it runs on a single core only at least (i.e. commenting out the mp_startup call)? Then it's probably good diving into mp_startup to see at which point therein it is hanging. Then we'll see whether this tells us something.
Thanks, Adam
Hi,
just wanted to close the loop - while discussing with Adam in the background, the root cause of the problem was that the system is using a x2apic which was not supported by the current fiasco kernel. Adam was so kind to provid a patch introducing x2apic support and the board works now.
When I'm not mistaken Adam plans to merge the fix into the next snapshot ...
Thanks again for the quick help!!
Andreas
On 12/15/20 3:17 PM, Adam Lackorzynski wrote:
Hi Andreas,
On Mon Dec 14, 2020 at 15:35:08 -0800, Andreas Steinmetzler wrote:
in some experiments I'm trying to run Fiasco/L4re on a Aaeon FWS2360 (https://www.aaeon.com/en/p/desktop-network-appliance-fws-2360) with an Intel Atom C3558. Unfortunately Fiasco gets stuck on boot when trying to start the different cores of the processor (I'm using the latest published l4re-snapshot-20.10.0). For this test I'm using the "hello world" ISO build with this command
make E=hello grub2iso MODULE_SEARCH_PATH="${PWD}/../build-fiasco-amd64"
The ISO image boots fine on another amd64 system. After adding some printf()'s to the file kernel_thread-ia32.cpp it looks to me that things get stuck with this call:
// Send IPI-Sequency to startup the APs Apic::mp_startup(Cpu::boot_cpu(), Apic::APIC_IPI_OTHERS, tramp_page);
as it does not return anymore ... any hint how to debug this or drill down to get more information and the AtomC3558 system to boot?
The first thing I'd check is whether it runs on a single core only at least (i.e. commenting out the mp_startup call)? Then it's probably good diving into mp_startup to see at which point therein it is hanging. Then we'll see whether this tells us something.
Thanks, Adam
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers@os.inf.tu-dresden.de