X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=README;h=5fed77ae5185404c8906b39b9dc87d2df1383c89;hb=1b650be8b800cf96e2c268ae317fb26d0bf36827;hp=f07d4cf9605be50598a1a96911228477d52c3dc9;hpb=722703e7cbd3a4b279a4c1baab5d95df2c23cce9;p=sbcl.git

diff --git a/README b/README
index f07d4cf..5fed77a 100644
--- a/README
+++ b/README
@@ -27,11 +27,13 @@ system, please send mail to one of the mailing lists:
 SYSTEM-SPECIFIC HINTS
 
 for OpenBSD:
-  It's reported for CMU CL (by Darren Bane on the comp.lang.lisp newsgroup,
-  2002-04-22) that OpenBSD 3.0 has stricter ulimit values, and/or enforces
-  them more strictly, than its predecessors, and so CMU CL's initial mmap()
-  won't work unless you increase the limit on the data segment, e.g. with
-    ulimit -S -d 524288
-  before you run CMU CL. The same is probably true of SBCL, but hasn't been
-  tested yet. (As of sbcl-0.7.3, SBCL has only been tested on OpenBSD 2.9
-  and earlier.)
+  OpenBSD 3.0 has stricter ulimit values, and/or enforces them more
+  strictly, than its predecessors. Therefore SBCL's initial mmap()
+  won't work unless you increase the limit on the data segment from
+  the OpenBSD defaults, e.g. with
+    ulimit -S -d 1000000
+  before you run SBCL. Otherwise SBCL fails with a message like
+  "ensure_space: failed to validate xxxxxxx bytes at yyyyy". (SBCL
+  is just allocating this huge address space, not actually using this
+  huge memory at this point. OpenBSD <3.0 had no problem with this,
+  but OpenBSD 3.0 is less hospitable.)