- l4-hackers - example.com Site

Re: L4ka and Bochs (was: L4ka and plex86?)
by Farid Hajji 16 Oct '00

16 Oct '00

Hi Volkmar and Kevin, trying to get l4ka running under bochs would probably require slight modifications to the bochs sources, so that 4 MB pages (bit 4 PSE of CR4) can be supported (please see summary below). > ------------------ BoSnip ------------------- > > // 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. > ------------------ EoSnip ------------------- > > So what happens is that we initialize 4MB pages (located in the first level > page dirs). > If bochs does not support 4MB pages - you are pretty much out of luck - we > currently do not support > 4K pages only. The kernels virtual view of physical memory is mapped as 4MB > pages. Furthermore, > RMGR and L4Linux assumes 4MB/Super-pages. So if you have absolutely no > possibility to get a normal > Pentium System - we have to do some mid-major :) changes of the startup > code. I don't hope that it would be necessary to tweak the l4ka sources so much (at least not for that 4MB problem). Looking at the sources of bochs, I think that it would be _much_ easier to add support for the PSE bit (bit 4 of CR4) to bochs itself at two places, rather than modifying l4ka. This is what I've found out so far (sorry for lengthy message): ---------- cut here ----------- cut here ------------- cut here -------------- Summary: ======== 1. About superpages, PSE bit etc... - - - - - - - - - - - - - - - - - - Intel Architecture Software Developer's Manual Volume 3: System Programming Order-Nr: 243192 http://developer.intel.com/design/pentiumii/manuals/24319202.pdf Section 3.6 Paging (Virtual Memory): PG-Flag (Bit 31 of CR0) enables paging translation, >= 386 PSE-Flag (Bit 4 of CR4) 4k or 4MB pages, >= 586 PAE-Flag (Bit 5 of CR4) 36Bit physical addr, >= 686 Section 3.6.2.1 Linear Address Translation (4 kByte Pages) Section 3.6.2.2 Linear Address Translation (4 MByte Pages) Section 3.6.2.3 Mixing 4kByte and 4MByte pages Section 3.8.2 Linear Address Translation With Extended Adressing Enabled (2 MByte or 4 MByte Pages). ====> PSE bit is only used while translating linear addresses to physical ====> addresses. paging directory entries and page table entries have slighly ====> different format (?) when 4 MB pages are involved. See figures ====> 3-14, 3-15, 3-18, 3-19, 3-20, 3-21. ====> In bochs, this is mainly located in the file: ====> bochs-2000_0325a/cpu/paging.cc 2. L4ka sources - - - - - - - - 2.1: l4-ka/kernel/src/x86/init.c:init_paging() .............................................. #if defined(CONFIG_ARCH_X86_I586) || defined(CONFIG_ARCH_X86_I686) /* Turn on super pages. */ enable_super_pages(); #endif ====> I configured with CONFIG_ARCH_X86_I586 to avoid having to: ====> #if defined(CONFIG_ARCH_X86_I686) ====> enable_global_pages(); ====> setup_sysenter_msrs(); ====> #endif 2.2: l4-ka/kernel/include/x86/cpu.h:enable_super_pages() ........................................................ INLINE void enable_super_pages() { __asm__ __volatile__ ("mov %%cr4, %%eax\n" "orl $0x10, %%eax\n" "mov %%eax, %%cr4\n" : : : "eax"); } ====> Turning on bit 4 of CR4 (PSE) enables 4 MB pages. ====> Volkmar: In Section 3.6.2.2 (at the End), the note says ====> Volkmar: that the TLBs _must_ be flushed (invalidated) after setting ====> Volkmar: or clearing the PSE bit. Forgot to do it? ====> This is the instruction that crashes bochs. 3. Bochs sources: - - - - - - - - - 3.1 output of bochs.out logfile: ................................ WBINVD: (ignoring) MOV_RdCd: read of CR4 MOV_CdRd: ignoring write to CR4 of 0x00000010 bochs: panic, MOV_CdRd: (CR4) write of 0x00000010 >> mov CR4, EAX ====> Bochs panic()s because it doesn't support CR4 bits yet (see below). ====> l4ka (enable_super_pages()) tries to set the PSE bit in CR4 because ====> it needs 4 MB superpages. 3.2 bochs-2000_0325a/cpu/proc_ctrl.cc: ...................................... This file contains the implementation of the x86-instructions. Let's look at the missing/buggy parts that were reported in bochs.out above: 3.2.1: WBINVD: (ignoring): . . . . . . . . . . . . . void BX_CPU_C::WBINVD(BxInstruction_t *i) { bx_printf("WBINVD: (ignoring)\n"); #if BX_CPU_LEVEL >= 4 invalidate_prefetch_q(); if (BX_CPU_THIS_PTR cr0.pe) { if (CPL!=0) { bx_printf("WBINVD: CPL!=0\n"); exception(BX_GP_EXCEPTION, 0, 0); } } BX_INSTR_CACHE_CNTRL(BX_INSTR_WBINVD); #else UndefinedOpcode(i); #endif } ====> BX_CPU_LEVEL was defined to be 5, so invalidate_prefetch_q() ====> was called. WBINVD (invalidates TLB etc...) seems to be okay. 3.2.2: read of CR4: . . . . . . . . . . void BX_CPU_C::MOV_RdCd(BxInstruction_t *i) { // mov control register data to register <snip> case 4: // CR4 #if BX_CPU_LEVEL == 3 val_32 = 0; bx_printf("MOV_RdCd: read of CR4 causes #UD\n"); UndefinedOpcode(i); #else bx_printf("MOV_RdCd: read of CR4\n"); val_32 = BX_CPU_THIS_PTR cr4; #endif break; <snip> } ====> This seems to be okay once more. The contents of the variable ====> cr4 can be read on this BX_CPU_LEVEL of 5. 3.2.3: ignoring write to CR4 of 0x00000010....., then panic() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . void BX_CPU_C::MOV_CdRd(BxInstruction_t *i) { // mov general register data to control register <snip> 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; <snip> } ====> This has to be tweaked, perhaps by adding a call to a new ====> CR4_change() function (like CR3_change()), which can ====> then be added to paging.cc. If the change is minimal, ====> modifying variable cr4 directly may be enough. Anyway, ====> in paging.cc, the translation functions must take into ====> account the PSE bit it cr4!!! 3.3 bochs-2000_0325a/cpu/paging.cc .................................. // Translate a linear address to a physical address, for // a data access (D) Bit32u BX_CPU_C::dtranslate_linear(Bit32u laddress, unsigned pl, unsigned rw) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } // Translate a linear address to a physical address, for // an instruction fetch access (I) Bit32u BX_CPU_C::itranslate_linear(Bit32u laddress, unsigned pl) { <snip long code which uses cr0, cr3 but not cr4 (yet)> } ====> these functions will have to additionally take into ====> account the value in cr4 (e.g. PSE bit), so that ====> 4 MB pages are supported. ---------- cut here ----------- cut here ------------- cut here -------------- Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

3 2

Trying L4ka under Bochs/FreeBSD (the saga continues...).
by Farid Hajji 14 Oct '00

14 Oct '00

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(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Real-time Fiasco
by kargahi 11 Oct '00

11 Oct '00

Hi L4 Hackers Would you please say me why Fiasco is a real-time u-kernel & what are the real-time properties of Fiasco? After that, please say me how the priorities affect the timeslice of a task and where the timeslice of a task is allocated to it. Thanks.

1 0

Task generation & Fiasco scheduler
by kargahi 18 Sep '00

18 Sep '00

Hi L4 hackers I am trying to write some servers on the L4 MK but i have two problems, please guide me with enough details and simple examples. my problems are here : 1. I tried more than a few times to create a 'task' with the l4_task_new system call but i couldn't. If possible, please send me some examples and describtion on creating tasks except the L4 manuals. 2. I am looking for the manager of resource CPU( scheduler ). Please guide me that where is the scheduler and how i can change it with my algorithm. thanks so much M. KARGAHI

1 0

Compiling L4 on FreeBSD (Part 2)
by Farid Hajji 15 Sep '00

15 Sep '00

Hi Michael, I tried again to compile l4 and I'm a step further: cd l4 mkdir include/l4/log cd include/l4/log ln -s ../../../pkg/log/include/l4/log/l4log.h . Now, gmake bombs with gmake[4]: Entering directory `/tmp/l4-devel/l4/pkg/l4util/examples/perf' gmake[4]: *** No rule to make target `main.ld', needed by `perf_p6'. Stop. How can a main.ld be generated? The two other main.ld I've found: ./pkg/log/server/src/main.ld ./pkg/names/server/src/main.ld were quite old (nov 1999) and certainly not generated by gmake! I'm still suspecting an incomplete l4 distribution, probably due to CVS. Trying to compile oskit10, I'm also missing files (I already told you this). I generated a oskit10/modules.x86.pc manually by putting the name of each subdirectory of oskit10 by itself on a line. Using gcc-2.95.2, configure resumes but misses the following files: sed: ./unsupported/scripts/sym-trace.in: No such file or directory sed: ./boot/GNUmakefile.in: No such file or directory sed: ./examples/GNUmakefile.in: No such file or directory sed: ./freebsd/GNUmakefile.in: No such file or directory sed: ./fs/GNUmakefile.in: No such file or directory sed: ./fsnamespace/GNUmakefile.in: No such file or directory sed: ./linux/GNUmakefile.in: No such file or directory sed: ./netbsd/GNUmakefile.in: No such file or directory sed: ./posix/GNUmakefile.in: No such file or directory sed: ./video/GNUmakefile.in: No such file or directory sed: ./wimp/GNUmakefile.in: No such file or directory sed: ./x11/GNUmakefile.in: No such file or directory Here again, I'm suspecting an incomplete distribution due to cvs problems. Thank you, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

2 3

CVS Server broken? + compiling L4 on FreeBSD
by Farid Hajji 13 Sep '00

13 Sep '00

Hi Michael, I already asked this on l4-hackers, but I didn't get any replies (yet): -------- begin forwarded message ----------- begin forwarded message -------- 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too, not only .html's] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) --------- end forwarded message ------------ end forwarded message -------- I did a complete "checkout l4" again in a fresh directory today, but the problem remained (the same with cvs update -d). One guess may be that the files are not present in the repository or that they have wrong permissions. Could you please check that the cvs server is running correctly (at least for l4 and oskit10)? I'm trying to compile l4 on a FreeBSD machine. I was able to compile oskit (_not_ oskit10) with gcc-2.7.2.3 and binutils-2.9.1 without problems (gcc-2.95.2 couldn't grok some asm directives because of forbidden use of certain x86 regs) except for the usual warnings. Compiling l4 with gcc-2.95.2 and binutils-2.9.1 went well, up to the point where liblog.h is required. I was not able to proceed any further at this point (liblog.h was not present either in l4-990428.tar.gz). BTW, I had to modify l4/Makeconf slightly, so that the native gcc(-2.95.2) of FreeBSD be used instead of the cross-compiler i486-linux-gcc. This is the modified part of l4/Makeconf: ifdef CROSS CPPFLAGS+= -DCROSS ifeq ($(SYSTEM),Linux) SYSTEM_TARGET= FLOPPY=/dev/fd0 else ifeq ($(SYSTEM),FreeBSD) SYSTEM_TARGET= FLOPPY=/dev/rfd0.1440 else SYSTEM_TARGET=i386-linux- endif endif endif I also tried to compile oskit10, but to no avail. Probably due to the missing files problem reported earlier (I'm not sure though...), even oskit10/configure bombed at a very early stage with the following error message: checking if compiler groks __attribute__((packed)) on structs... yes checking if compiler groks __attribute__((pure))... yes checking if compiler groks __attribute__((noreturn))... yes checking if compiler groks __attribute__((constructor))... yes configure: error: OSKit modules file ./modules.x86.pc was not found. It didn't matter wether I used gcc-2.95.2 or gcc-2.7.2.3: env CC=gcc27 MAKE=gmake ./configure env CC=gcc MAKE=gmake ./configure This is my compile environment: gcc -v Using builtin specs. gcc version 2.95.2 19991024 (release) gcc27 -v Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/2.7.2.3/specs gcc version 2.7.2.3 as -v GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1 ld -v GNU ld version 2.9.1 (with BFD 2.9.1) gmake -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for i386--freebsd5.0 uname -rs FreeBSD 5.0-20000506-CURRENT Please help! Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

CVS server problems?
by Farid Hajji 12 Sep '00

12 Sep '00

Hi, is the CVS server currently broken? 1. I'm missing some files, like e.g. in l4 module the file pkg/log/lib/include/l4/liblog.h (among others). [oskit10 is missing _a lot_ of files too] 2. In l4-hackers archive http://www.mail-archive.com/l4-hackers@os.inf.tu-dresden.de/msg00399.html Michael refers to an additional "log" package. This is fine, but this package (included in l4) doesn't include liblog.h (cvs server says: nothing known about pkg/log/lib/include/l4/liblog.h) Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji(a)ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds.

1 0

Re: How to run Linux 2.2
by Jean Wolter 09 Aug '00

09 Aug '00

Fabio Riccardi <fabio.riccardi(a)free.fr> writes: > Hi, > > I have downloaded the last CVS sources of fiasco, oskit and linux. > > I managed to get fiasco + oskit (old and new version, all example > applications) to run, and I have succesfully recompiled Linux 2.2. I can > even boot Linux, but as soon as it frees the unused kernel memory I get > an infinite sequence of messages like this: > > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > root: rcvd 4bb5bc, 4bb5bc, src: a.0 > unknown request from a.0 > etc... This is a bug in L4Linux. It took a while to figure out what happens since the bug only happens if you say no to "Use flat clan structure". The following fix will correct this: Index: l4_pager.c =================================================================== RCS file: /home/cvs/linux22/arch/l4/x86/lib/l4_pager.c,v retrieving revision 1.2 retrieving revision 1.4 diff -u -r1.2 -r1.4 --- l4_pager.c 2000/05/12 12:29:48 1.2 +++ l4_pager.c 2000/08/09 12:58:23 1.4 @@ -77,6 +77,7 @@ ping_pong_id = template_id; ping_pong_id.id.task = n; + ping_pong_id.id.lthread = 0; pager.id.lthread = LTHREAD_NO_ROOT_PAGER; Jean -- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger

1 0

How to run Linux 2.2
by Fabio Riccardi 07 Aug '00

07 Aug '00

Hi, I have downloaded the last CVS sources of fiasco, oskit and linux. I managed to get fiasco + oskit (old and new version, all example applications) to run, and I have succesfully recompiled Linux 2.2. I can even boot Linux, but as soon as it frees the unused kernel memory I get an infinite sequence of messages like this: root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 root: rcvd 4bb5bc, 4bb5bc, src: a.0 unknown request from a.0 etc... Do I have to configure the rmgr in a special way? I found a configuration file on the diskette image, but it doesn't work either... What am I doing wrong? Thank you very much in advance for your help, ciao, - Fabio

1 0

Sigma0 bug?
by Christian Stueble 25 Jul '00

25 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Hello again, Last week I had some problems using fiasco on a 196 MB machine. Suzuki told me to modify l4/pkg/rmgr/server/src/memmap.h, but this does not help. (I set MEM_MAX to 256MB and the RMGR told me: "WARNING: All memory above 256 is wasted", on a 196MB machine!!). I noticed that sigma0 also defines MEM_MAX, and after setting it to 256MB, too, it works now. But, isn't it wrong that sigma0 returns memory pages up to RMGR's MEM_MAX value, even if only 196MB are available? Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Christian Stueble......................stueble(a)cs.uni-sb.de PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A To be or not to be is true... (apocrypha of George Boole) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: wEaiE9zGKl756mb1+UDwYiIm1DkcNdUa iQCVAwUBOX2vsfyJjJy/cQT1AQGyxQQArkMBqWKaIOditHQIuoh+so+7mL0GK3i7 uPYdvQ5Ys6QDw12xhR1zhtPBA1KZcg4DE5CHzqiTY4RfKMx9X5wovIOVu1thujUv Z1OyvqjNTbCwinOoijq+yH53W7hz3aNA+ljbuJ8JghQE5lbFlHjJMkl5aFLwX93u knN6nHmSqPA= =e4UE -----END PGP SIGNATURE-----

1 0