Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Nick Lello moved from IDS 10.0.UC4 on Solaris 9 to IDS 11.10.FC2 on Solaris 10 and saw listener error -25575 with oserr 12 after a couple of days; IBM and Sun deflected, and his ndd TCP tuning did not help. Mike Magie suggested xtrace. Jeff Laube explained it was a failed TLI t_alloc() with ENOMEM and asked whether connections failed at all. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Lello, Nick — — source: IIUG Forums & Mailing Lists
I'm looking for any ideas here as we seem to be getting the usual
round-around from both Informix and Sun...
We have an multi-database installation of IDS 10.0.UC4 on Solaris 9 (Sun
fire v480) which we are replacing with a reloaded engine IDS 11.10.FC2
on Solaris 10 (Sun fire v490).
The Solaris 10 + IDS 11 system runs really well (50%+ speed improvement)
until after a couple of days we start seeing:-
05:49:39 listener-thread: err = -25575: oserr = 12: errstr = :
Network driver cannot allocate the call structure. System error = 12.
The operating system has been configured in accordance with the Machine
Notes for the IDS 11.10.FC2 distribution - curiously there is no mention
of tuning the TCP stack through ndd.
Unfortunately the IBM (Informix) response has been a flat 'its an os
error - speak to Sun' which is correct, but they wont help with any
clues on what the call that is failing possibly is.... Sun are asking
for source code and/or a truss of the failing process.
I have tried setting the following prior to IDS startup:-
ndd -set /dev/tcp tcp_time_wait_interval 15000
ndd -set /dev/tcp tcp_conn_req_max_q 4096
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_max_buf 655350
ndd -set /dev/tcp tcp_cwnd_max 655350
Following my gut instinct for dealing with networking issues that
*appear* to be with the queue depth
However, I'd love to hear from someone who has any solid ideas or
experience with this version mix....
Regards,
Nick
↪ replying to Lello, Nick
MIKE MAGIE — — source: IIUG Forums & Mailing Lists
I am a bit rusty with my asf stuff but I believe that the error indicates that
the informix listener thread is not able to allocate the basic tcp/ip
structures required to accept and allocate resources for a new connection -
errno 12 enomem. I would ask the Informix rep you are working with if they
could help you "xtrace" the problem to get more details for Sun (if xtrace is
still an available tool with v11). If they've already xtraced the issues they
should have some details for you to give to Sun.
Mike
↪ replying to Lello, Nick
MIKE MAGIE — — source: IIUG Forums & Mailing Lists
If this is a double post I apologize - Do you know if the rep you are working
with has used the xtrace utility (internal Informix tool) to gather diagnostic
information relavent to this issue? Yes, it is an os issue, the informix
listener cannot allocate the basic tcp/ip structures required to accept and
setup a new user connection (errorno 12 as you probably know is ENOMEM, not
enough memory) - but the xtrace utility in the past has been able to gather
additional details that Sun would find useful in many cases like this. If
xtrace is no longer a valid utility in v11 - never mind :-)
Mike
↪ replying to Lello, Nick
JEFF LAUBE — — source: IIUG Forums & Mailing Lists
Hi Nick,
The error that you're receiving is from a failed TLI library call, t_alloc().
More specifically, IDS is trying to use t_alloc() to allocate memory and
failing with ENOMEM (error 12) for one of a couple different TLI structures.
The memory could be for a t_call structure that is used as an argument in
either a t_accept() when trying to accept a new connection or a t_connect()
when trying to attempt a remote connection. The memory could also be for a
t_discon structure that is used in a t_rcvdis() for clearing rejected
connection attempts.
Just curious - you mentioned that you start seeing these errors after a couple
days. When the errors start, are they random or would you say they are in sync
with TLI connection attempts? When the errors start, are you able to connect
to IDS via TLI at all?
Jeff
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.