> > Well, my experience on compiling and running nntpcache on BSDI3.0 is very good > > No problem's what's so ever. > > Keep in mind that it is running on a fully patched system. > > We've tried that now, (we were running a plain unpatched 3.0 kernel) > with: BSDI BSD/OS 3.0 Kernel #0: Wed Apr 16 15:15:49 MDT 1997 > polk@demiurge.BSDI.COM:/home/polk/sys-3.0patches/compile/GENERIC > i386 But at no success: same error. > > We've tried something else: > > use only > > #define HAVE_MMAP_DEV_ZERO_PRIVATE 0x4001000 > #define HAVE_MMAP_DEV_ZERO_PRIVATE_CHILD_INHERIT 0x4001000 > #define HAVE_MMAP_DEV_ZERO_SHARED 0x4001000 > #define HAVE_MMAP_DEV_ZERO_SHARED_CHILD_INHERIT 0x4001000 > #define HAVE_MMAP_DEV_ZERO_SHARED_CHILD_READ_PARENT_WRITE 0x4001000 > #define HAVE_MMAP_DEV_ZERO_SHARED_PARENT_READ_CHILD_WRITE 0x4001000 > > and remove: > > all #define HAVE_MMAP_FILE_ and all #define HAVE_MMAP_ANON_ entries > from mmap_results.h This is a success, no more errors. But (of > course) we want MMAP_ANON to work because it's faster. > > > Please tell me the exact problems then I can give it a better try. > > So the problem is with MMAP_ANON... > > The patch > - Mbase = mmalloc_attach (f_anon? -1: fd, (POINTER)MMAP_BASE_ADDRESS, con. > maxMmap); > + Mbase = mmalloc_attach (f_anon? -1: fd, f_anon? 0: (POINTER)MMAP_BASE_AD > DRESS, con.maxMmap); > as suggested by proff@suburbia.net didn't help. I hope the next one does :-) > > What should we try next? (Btw, what results do you get from mmap_tests?) > > regards, > Hans DEV_ZERO should be use the same kernel functions as MAP_ANON (and thus be the same speed). It seems very strange that the MMAP_ANON is failing in nntpcached, where it worked fine in mmap_tests. The only difference that I can see is the allocation size, but I'd expect DEV_ZERO handling to enforce the same restrictions. Try changing MM_SIZE in mmap_tests.c to 16*1024*1024 and see if the tests produce the same result. Cheers, Julian.
