> On Mon, Jul 19, 1999 at 10:05:24AM -0700, Ben Woodard wrote:
> > Error rvm_load_segment returns 201
> > 09:38:09 rds_load_heap error RVM_EINTERNAL
> 
> Strange, from looking at the sources this is probably the result of a
> failed mmap of the RVM data partition. What exactly is wrong is unclear,
> but it is either:
>  - The rvm-data partition is not accessible.
>  - The address (range) to which rvm is mapped is already in use.
> 
> > Any clues as to where to look for problems?
> 
> Check whether your scsi driver is loaded, can you f.i. do
>   'dd if=/dev/sdb3 of=/tmp/dump bs=1024 count=1' without errors.
> 

No problmes there.

[ben_at_wythe ben]$ sudo dd if=/dev/sdb3 of=/tmp/dump bs=1024 count=1
1+0 records in
1+0 records out

> Check if there is anything mapped in memory between 0x20000000 and
> 0x2c8000000. On linux when the server is hanging in it's crashed state,
> do "cat /proc/`pidof codasrv`/maps".
> 

Hmm. that appears to be the problem. All the shared libraries are
loaded there. Why do you think that is? The only thing that I can
think of is this. On VA machines, the default kernel is patched so
that you can have more memory in a machine >1Gb. However, this cuts
down on the address space available for a process. It looks like I am
running one of those custom kernels. However, I would almost swear
that I was running one of those for as long as I have been running coda.

[ben_at_wythe ben]$ sudo cat /proc/1070/maps
08048000-08129000 r-xp 00000000 08:04 143495     /usr/sbin/codasrv
08129000-0813a000 rw-p 000e0000 08:04 143495     /usr/sbin/codasrv
0813a000-08165000 rwxp 00000000 00:00 0
15000000-15004000 rw-p 00000000 00:00 0
15006000-1500a000 rw-p 00000000 00:00 0
2aaab000-2aabd000 r-xp 00000000 08:04 30722      /lib/ld-2.1.1.so
2aabd000-2aabe000 rw-p 00011000 08:04 30722      /lib/ld-2.1.1.so
2aabe000-2aabf000 rwxp 00000000 00:00 0
2aabf000-2aac0000 r-xp 00000000 08:04 30726      /lib/libNoVersion-2.1.1.so
2aac0000-2aac1000 rw-p 00000000 08:04 30726      /lib/libNoVersion-2.1.1.so
2aac1000-2aac4000 rw-p 00000000 00:00 0
2aac6000-2aad2000 r-xp 00000000 08:04 30736      /lib/libdb1-2.1.1.so
2aad2000-2aad4000 rw-p 0000b000 08:04 30736      /lib/libdb1-2.1.1.so
2aad4000-2ab05000 r-xp 00000000 08:04 74099      /usr/lib/libstdc++.so.2.8.0
2ab05000-2ab13000 rw-p 00030000 08:04 74099      /usr/lib/libstdc++.so.2.8.0
2ab13000-2ab15000 rw-p 00000000 00:00 0
2ab15000-2ab30000 r-xp 00000000 08:04 30740      /lib/libm-2.1.1.so
2ab30000-2ab31000 rw-p 0001a000 08:04 30740      /lib/libm-2.1.1.so
2ab31000-2ab32000 rw-p 00000000 00:00 0
2ab32000-2ac18000 r-xp 00000000 08:04 30729      /lib/libc-2.1.1.so
2ac18000-2ac1d000 rw-p 000e5000 08:04 30729      /lib/libc-2.1.1.so
2ac1d000-2ac20000 rw-p 00000000 00:00 0
2ac25000-2ac2d000 r-xp 00000000 08:04 30760      /lib/libnss_files-2.1.1.so
2ac2d000-2ac2e000 rw-p 00007000 08:04 30760      /lib/libnss_files-2.1.1.so
2ac2e000-35cce000 rw-p 00000000 00:00 0
7fffd000-80000000 rwxp ffffe000 00:00 0

> > Should I do vice-setup-rvm again?
> 
> That might work, but this is not caused by rvm corruption, the failed
> mmap call is before those checks.
> 

Didn't work.

> Jan