Hi, [Kevin: please have a look at the bochs panic below: What's wrong with writing non-zero to CR4 when --enable-cpu-level=5 is mentioned? Is there a quick workaround to this problem? Thanks.] I'm trying to run l4ka under bochs but I'm still fighting with some bochs panic()s. This is what I've found out so far: 1. 3 modules _must_ be attached to rmgr, so that the assertion in startup() about the number of modules doesn't bite. 2. I used the following grub startup commands thru all following tests (bochs simulates disk C: from a 112M bytes regular file): grub> root (hd0,0) Filesystem type is ext2fs, partition type 0x83 grub> kernel (hd0,0)/l4ka/rmgr.debug -sigma0 [Multiboot-elf, <0x111000:0x20734:0x0>, <0x132740:0x48c:0xfcc8>, entry=0x111000] grub> module (hd0,0)/l4ka/x86-kernel [Multiboot-module @ 0x143000, 0x12769 bytes] grub> module (hd0,0)/l4ka/sigma0 [Multiboot-module @ 0x156000, 0x287a bytes] grub> module (hd0,0)/l4ka/glinux [Multiboot-module @ 0x159000, 0x143dd4 bytes] grub> boot rmgr.debug is just original rmgr binary, with another name. I tried to slightly modify rmgr in later steps... rmgr[.debug], x86-kernel and sigma0 were compiled on FreeBSD without problems. Note: compiled for 586, not 686!. They are not stripped. I was not able to compile linux22 from Dresden on FreeBSD, so I just used the binary 'glinux' from your distribution. 3. Without any modifications to the l4-ka sources, bochs panic()s right after displaying the message: check_l4_version 0x00100000 to 0x0011041c with the following error message: MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 protected mode CS.d_b = 32 bit SS.d_b = 32 bit | EAX=00000010 EBX=ff000000 ECX=0010f40f EDX=0010a000 | ESP=0010f3f7 EBP=00109000 ESI=f0109000 EDI=00109000 | IOPL=0 NV UP DI PL NZ NA PO NC | SEG selector base limit G D | SEG sltr(index|ti|rpl) base limit G D | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1 | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1 | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1 | EIP=0010fa55 (0010fa52) >> 77875018 0f77875018 2277875018 e077875018 : mov CR4, EAX bochs was not able to grok the instruction: mov CR4, EAX (that is EAX -> CR4). I compiled bochs-2000_0325a with the following options: ./configure --enable-cpu-level=5 \ --enable-disasm --enable-vga --enable-fpu \ --enable-x86-debugger Support for x86-debugger (DR? registers etc...) is therefore enabled. Looking at the source code of bochs-2000_0325a, file cpu/proc_ctrl.cc says in function void BX_CPU_C::MOV_CdRd(BxInstruction_t *i): [...] case 4: // CR4 #if BX_CPU_LEVEL == 3 bx_panic("MOV_CdRd: write to CR4 of 0x%08x on 386\n", val_32); UndefinedOpcode(i); #else // Protected mode: #GP(0) if attempt to write a 1 to // any reserved bit of CR4 bx_printf("MOV_CdRd: ignoring write to CR4 of 0x%08x\n", val_32); if (val_32) { bx_panic("MOV_CdRd: (CR4) write of 0x%08x\n", val_32); } // Only allow writes of 0 to CR4 for now. // Writes to bits in CR4 should not be 1s as CPUID // returns not-supported for all of these features. BX_CPU_THIS_PTR cr4 = 0; #endif break; [...] So bochs doesn't allow writing 0x00000010 (non-zero) to CR4 for now. To Kevin: Why? To Uwe: Can we avoid having to write to CR4 for now? 4. I tried to localize the exact position of that instruction in l4-ka by adding the following MYDEBUG macro to halt execution before bochs panic()s: #ifndef MYDEBUG #define MYDEBUG(str) { printf(str); for(;;) ; } #endif this helped to track down at least portions of the code that were definitely executed by bochs, as well as to see the output. This is what I've found out so far: 4.1. control definitely reaches the end of l4-ka/apps/rmgr/src/startup.c:startup(), at least just before the final: asm volatile ("pushl $" SYMBOL_NAME_STR(exit)"\n" "pushl %2\n" "ret\n" : /* no output */ : "a" (MULTIBOOT_VALID), "b" (&l4_mbi), "r" (exec_info.entry)); /*NORETURN*/ This is the output in bochs: RMGR: loading (hd0,0)/l4ka/sigma0 check_l4_version 0x00100000 to 0x0011041c RMGR: detected L4-Karlsruhe find kernel info page... found kernel info page at 0x00107000 configuring s0: (0x00200000, 0x00213000), start: 0x00200000 s0 config: 0x00200000,0x00000000,0x00200000,0x00213000 RMGR: reserve modules memory range: 156000 to 29cdd4 RMGR: starting (hd0,0)/l4ka/x86-kernel @ 0x0010f000

...

...

...

rmgr.debug:startup() just before asm volatile... at end of function.

4.2. control doesn't reach even the very beginning of l4-ka/apps/rmgr/src/init.c:init() where I've put the next MYDEBUG call. bochs panic()s with the same error message as before (ignoring write to CR4 of 0x00000010: mov CR4, EAX). Uwe, where does startup() exactly jumps to? I thought it was rmgr's init()??? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.