SCHREINER@iravcl.ira.uka.de (Guenther Schreiner) (06/28/90)
In article <1865@runxtsa.runx.oz.au> brucee@runxtsa.runx.oz.au (Bruce Evans) writes: >Minix-386 uses NR_BUFS = 320 and NR_BUF_HASH = 512. I think a much smaller >number of hash entries will work, but hash entries are cheap compared with >buffers, so I used more. I think about 25% of memory should be used for >buffers and 0% for a RAM disk, except a floppy-only system needs a RAM disk >(assuming the number of buffers is not limited by the address space as on a >PC). > >Recompiling the kernel (just misc.c, and floppy.c on the PC) is important. >The memory for the I/O vector(s) is a bit extravagant for a large number of >buffers. The vector copying should be rewritten some day. If i do this on my 2 MB ATARI-ST with the given values the system isn't able to boot. I got a message like 'unable to report size to mm'. I must reduce the values to something like NR_BUFS = 100 NR_BUF_HASH = 64 to get it running. Perhaps this comes from the 16 bit ST MINIX int's - MINIX-386 (Bruce ?) uses 32 bit i believe. Ralf Wenk, using a friends account
andreas@nixhhs.UUCP (Andreas Wettengel) (06/29/90)
Hello, In article <90.179.12:00:44@ira.uka.de> Guenther Schreiner <SCHREINER@iravcl.ira.uka.de> writes: >In article <1865@runxtsa.runx.oz.au> brucee@runxtsa.runx.oz.au (Bruce >Evans) writes: >>Minix-386 uses NR_BUFS = 320 and NR_BUF_HASH = 512. I think a much smaller [...] >If i do this on my 2 MB ATARI-ST with the given values the system isn't able >to boot. I got a message like 'unable to report size to mm'. I must reduce >the values to something like NR_BUFS = 100 NR_BUF_HASH = 64 to get it running. >Perhaps this comes from the 16 bit ST MINIX int's - MINIX-386 (Bruce ?) uses >32 bit i believe. I am running NR_BUFS=160 and NR_BUF_HASH = 256 without problems on a 1 MB ST. The sizes are computed in clicks (256 bytes), so at least 8 MB (16 if there is no bug in unsigned arithmetic...) can be expressed that way. Recompiling fs and kernel was sufficient for me. Andreas -- Andreas Wettengel | Nixdorf Computer AG Tel. +49 40/6371-2423 | Ueberseering 33 (...uunet!)unido!nixhhs!andreas | 2000 Hamburg 60 NERV: nixhhs!andreas.eunet | West Germany
jf@walhalla.informatik.uni-dortmund.de (Jan-Hinrich Fessel) (07/03/90)
In article <1297@nixhhs.UUCP> andreas@nixhhs.UUCP (Andreas Wettengel) writes: >In article <90.179.12:00:44@ira.uka.de> Guenther Schreiner <SCHREINER@iravcl.ira.uka.de> writes: >>In article <1865@runxtsa.runx.oz.au> brucee@runxtsa.runx.oz.au (Bruce >>Evans) writes: >>>Minix-386 uses NR_BUFS = 320 and NR_BUF_HASH = 512. I think a much smaller >[...] >>If i do this on my 2 MB ATARI-ST with the given values the system isn't able >>to boot. I got a message like 'unable to report size to mm'. I must reduce >>the values to something like NR_BUFS = 100 NR_BUF_HASH = 64 to get it running. >I am running NR_BUFS=160 and NR_BUF_HASH = 256 without problems on a 1 MB ST. OK, I think this is a compiler bug, but I haven't tested out with c68... What I observed was: if((NR_BUFS > 200) || (NR_BUF_HASH > 512)) { kenrnel_does_not_boot_on_ST(); } Cheers Jan-Hinrich ~~~~ Jan-Hinrich Fessel, Universitaet Dortmund, IRB jf@unido.uni-dortmund.de atari-{sources,binaries}@unido.uni-dortmund.de -- ~~~~ Jan-Hinrich Fessel, Universitaet Dortmund, IRB jf@unido.uni-dortmund.de atari-{sources,binaries}@unido.uni-dortmund.de
evans@ditsyda.oz (Bruce.Evans) (07/04/90)
In article <2004@unido.UUCP> jf@walhalla.UUCP (Jan-Hinrich Fessel) writes: >OK, I think this is a compiler bug, but I haven't tested out with c68... >What I observed was: >if((NR_BUFS > 200) || (NR_BUF_HASH > 512)) { > kenrnel_does_not_boot_on_ST(); >} The boot loader for Minix-ST has the magic number ldaddr = 0x40000. I think the loader may be getting tangled up with the system when the system is bigger than 256K. This might not matter if only unimportant data in the bss gets clobbered, and this might be compiler dependent. Minix-PC has a similar arbitrary limit as well as a hardware barrier at 640K. A too-big kernel always clobbers the loader. -- Bruce Evans evans@ditsyda.syd.dit.csiro.au
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/04/90)
When I stated that big buffersizes cause no problem to me, I forgot to say that I use a homemode 68000 box, so the problem might come from the bootstrap process, as Bruce Evans pointed out. BTW, I considered the ST bootstrapper inadequate after the first look, a much better solution (this goes with my bootstrap process) is to load the target image, copy a position-independent copy-routine after this and call this routine. An assumption the like ,,the MINIX image won't be bigger than XXX KBytes'' is silly. C.v.W.