From: Bob Marcan (bob@interstudio.homeunix.net)
Date: Tue Apr 18 2006 - 03:52:52 EDT
Thanks to Eric Werme, Dr. Thomas P. Blin and Vincent Jean-Marc.
Explanation from Eric Werme hits the nail.
Best regards, Bob
-----------------------------------------------------------------------
From Eric Werme USG:
Apr 10 11:38:07 facko vmunix: recmbuf_avail: Too long RPC, tlen
1212498248, rlen 1212498248
Apr 10 11:38:09 facko vmunix: recmbuf_avail: Too long RPC, tlen
1195725860, rlen 1195725860
Apr 10 11:38:18 facko vmunix: recmbuf_avail: Too long RPC, tlen
1212498248, rlen 1212498248
Typically that comes from someone telnetting to NFS and the RPC/XDR
code expressing its annoyance at weird RPC record lengths.
$ bc
obase=16
1212498248
48454148
1195725860
47455424
The lengths are data from the TCP stream, and it looks 4 bytes greater
than the raw data
48454148 -> 48454144 == "HEAD"
47455424 -> 47455420 == "GET "
I could reproduce these via "telnet localhost 2049" and typing
"HEAD" or "GET "
My guess is that some SMTP application thinks that the mail
server is at port 2049.
Only reference, which i can find, is patch for the VMS TCP/IP services.
And we don't use nfs. Our main aplication is Oracle.
Off hand, I'm not sure what other kernel subsystem might be waiting for
RPC over TCP messages. Usermode applications won't reach that kernel
printf.
At any rate, the messages can be ignored for the most part. If you
want to chase them down, tcpdump can help out as long as the kernel
messages are appearing fairly frequently.
-Ric Werme
-- Eric (Ric) Werme | werme@zk3.dec.com Hewlett-Packard Co. |
http://werme.8m.net/
-----------------------------------------------------------------------
From Dr. Thomas P. Blin:
Without access to kernel sources (which I no longer have), it's really hard
to know exactly what the circumstances are that trigger this message, but it
looks like it's related to an internal kernel remote procedure call, this is
just an informed guess, but from the routine name, I'd suspect there is some
internal memory buffer (an "mbuf") that needs to be transmitted, and that
the routine that's called to allocate space for it is "recmbuf_avail" which
probably checks for available space. I don't know what the tlen and rlen
values are, but I'd guess they are related to the buffer length in bytes,
and if so, those look absurdly large. But who knows.. This may be one of
those things that can only happen in a TruCluster configuration, and if so,
the code may be in the cluster sources, not in the base OS. But you can't
figure that out if you don't have the sources, and I don't.
You cite three specific instances of the message, all quite close together
in time. Has this happened before? Is it still happening? Was something
odd occurring on the system during that time frame, particularly on any of
the other cluster members? Has any member crashed and rebooted since those
messages were displayed?
If the problem has not been seen before and isn't happening still, I'd say
it's a fluke and there is no value in reporting it (assuming that you have a
formal support contract), since the number of people left around to work on
problems like this keeps getting smaller and smaller.
Good luck.
Tom (formerly HP kernel technical support for Tru64 UNIX and TruCluster, now
retired)
-----------------------------------------------------------------------
From Vincent Jean-Marc:
Hi Bob,
Do you have also this kind of messages:
...: ... vmunix: Incoming fragment excessively long, recmark ..., len
...
Could you provide me with if any?
As found in the Tru64 sources code, these messages come only from NFS
over TCP.
Second sort of messages can give us an idea about who is in trouble.
VINCENT Jean-Marc
HP France
Groupe Support Unix
Tru64(tm) UNIX Technical Consultant - Tru64(tm) UNIX Ambassador HP
France
+33 1 5762-8861
jean-marc.vincent@hp.com
-----------------------------------------------------------------------
Original message:
Bob Marcan wrote:
> Hi.
>
> Did anybody knows what can trigger this?
>
> Apr 10 11:38:07 facko vmunix: recmbuf_avail: Too long RPC, tlen
> 1212498248, rlen 1212498248
> Apr 10 11:38:09 facko vmunix: recmbuf_avail: Too long RPC, tlen
> 1195725860, rlen 1195725860
> Apr 10 11:38:18 facko vmunix: recmbuf_avail: Too long RPC, tlen
> 1212498248, rlen 1212498248
>
> Tru64 5.1B cluster ECO: T64V51BB26AS0005-20050502
>
> Only reference, which i can find, is patch for the VMS TCP/IP services.
> And we don't use nfs. Our main aplication is Oracle.
>
>
> TIA, Bob
-- Bob Marcan, Consultant mailto:bob.marcan@snt.si S&T Hermes Plus d.d. tel: +386 (1) 5895-300 Leskoskova cesta 6 fax: +386 (1) 5895-202 1000 Ljubljana, Slovenia url: http://www.snt.si
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:50:29 EDT