From the keyboard of "Lello, Nick" <Nick.Lello@nielsen.com>:

from /usr/include/sys/errno.h:

#define         ENOMEM  12      /* Not enough core      */

I'd look for memory issues.

HTH
Christian

Well the 25575 error only seems to be generated in a couple spots.
The majority of those spots is a t_alloc() call where the type
arguement to t_alloc() is a T_CALL structure.  Then 1 spot we are
doing a t_alloc() call where the type is T_DIS.  So in that sense the
call that would be failing is t_alloc(), but it could be possibly
trying to allocate 1 of 2 types of structures, either a T_CALL or a
T_DIS.

Once you get the 25575 error on a connection attempt do all connection
attempts fail,  or is it just occasional new connections?  Do you just
bring the instance off-line to clear it up, or do you have to reboot
the box?  As the previous poster mentioned, errno 12 is ENOMEM.

If Sun wants a truss and all new connection attempts start to get the
error, I wouldn't think it would be a problem to truss the oninit
process, or multiple oninit processes.  I would however request from
sun the specific truss output they'd want though, as the oninit
process is going to be making, generally speaking, a large number of
system calls that would show up in the truss output.

Jacques

I'm posting this as general information for other people that might
show up here with the same problem.  I was working with the engineer
at IBM who was working on your PMR and we discovered that it looks
like the cause of your ENOMEM errors was the default address for
SHMBASE from the onconfig.std and even from the release notes for
11.10.FCx appears to be far too close to the address that Solaris
wants to use for the starting heap address.  So the process does not
have much space for it's private heap before it runs into SHMBASE
which will then prohibit private heap growth.  The solution appears to
be to just use a larger address for SHMBASE to give more space between
the private memory heap and the IDS shared memory segments.   You can
use the pmap tool so show the addresses for where things are being
mapped out in your oninit proccesses address space, then find a good
empty spot to change your SHMBASE too and that should resolve the
issue.

Example of the problem, pmap output for 11.10.FC1

10754:  oninit
0000000100000000      14320K r-x--  /spare1/product/1110FC1/bin/oninit
0000000100EFA000       2480K rwx--  /spare1/product/1110FC1/bin/oninit
0000000101166000       1000K rwx--    [ heap ]
000000010A000000      16384K rwxs-    [ shmid=0x330 ]
000000010B000000       8192K rwxs-    [ shmid=0x331 ]
000000010B800000       9216K rwxs-    [ shmid=0x76 ]

So from this output you can see the Solaris private heap starts at
0x101166000 and SHMBASE from the onconfig file would appear to be set
to 0x10A000000, and those addresses are just far too close together to
allow sufficient private memory heap growth.

Jacques