When using the devb-ram driver, it will SEGV a short time after it is started.  The memory addresses it is crashing on 
are within the shared memory it allocates.  We verified this by inspecting the core for the offending instruction and 
register contents it used.  You can replicate this problem by adding the following patch to sim.c and running devb-ram 
by itself.

$ svn diff sim.c
Index: sim.c
===================================================================
--- sim.c       (revision 10453)
+++ sim.c       (working copy)
@@ -521,6 +521,19 @@
       return EXIT_FAILURE;
    }
 
+   // *** This will crash at a random point. ***
+   unsigned int i;
+   for( i=0 ; i<mapSize; i+=8 )
+   {
+      fprintf( stderr, "%p:  %08x %08x %08x %08x  %08x %08x %08x %08x/n",
+               addr + i,
+               addr[i  ],addr[i+1],addr[i+2],addr[i+3],
+               addr[i+4],addr[i+5],addr[i+6],addr[i+7]
+             );
+   }
+   // Never get here.
+   fprintf( stderr, "/n---END OF MEMORY---/n" );
+
        if( ram_ctrl.cflags & RAM_CFLAG_SCAN ) {
                if( ( hba = ram_alloc_hba( ) ) == NULL ) {
                        return( CAM_FAILURE );
===================================================================

Here is how we start it:
     devb-ram cam quiet ram capacity=57344 dos exe=all blk cache=128k

Since we are accessing memory that we allocated, why are we losing permission to access this memory?  How can we work 
around this problem?

Thanks,
Andy