Bug 20927

Summary: dmesg output: looutput: mbuf allocation failed
Product: Base System Reporter: Robert Watson <rwatson>
Component: kernAssignee: silby
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.1-STABLE   
Hardware: Any   
OS: Any   

Description Robert Watson freebsd_committer freebsd_triage 2000-08-29 22:30:00 UTC
Found a weird message in my dmesg.  Exploration below; don't know what
prompted it, but the exploration suggests some possibilities.

% dmesg | grep looutput
looutput: mbuf allocation failed
looutput: mbuf allocation failed
looutput: mbuf allocation failed
looutput: mbuf allocation failed
looutput: mbuf allocation failed
looutput: mbuf allocation failed

from src/sys/net/if_loop.c:
        if (0) {
contiguousfail:
                printf("looutput: mbuf allocation failed\n");
        }

So apparently contiguousfail is being jumped to.  One of the following
conditions:

        /*
         * KAME requires that the packet to be contiguous on the
         * mbuf.  We need to make that sure.
         * this kind of code should be avoided.
         * XXX: fails to join if interface MTU > MCLBYTES.  jumbogram?
         */
        if (m && m->m_next != NULL && m->m_pkthdr.len < MCLBYTES) {
                struct mbuf *n;

                MGETHDR(n, M_DONTWAIT, MT_HEADER);
                if (!n)
                        goto contiguousfail;
                MCLGET(n, M_DONTWAIT);
                if (! (n->m_flags & M_EXT)) {
                        m_freem(n);
                        goto contiguousfail;
                }

                m_copydata(m, 0, m->m_pkthdr.len, mtod(n, caddr_t));
                n->m_pkthdr = m->m_pkthdr;
                n->m_len = m->m_pkthdr.len;
                m_freem(m);
                m = n;
        }

From src/sys/i386/include/param.h:

#define MCLSHIFT        11              /* convert bytes to m_buf clusters */
#endif  /* MCLSHIFT */
#define MCLBYTES        (1 << MCLSHIFT) /* size of an m_buf cluster */

For reference, MTU on lo0 is 16k, and MCLBYTES is 2048 on i386.  I'm guessing
this means that lo0 has problems with packets over 2k in size.  I could be
wrong.

Fix: 

Not available.
How-To-Repeat: 
Unfortunately, have no idea.  Don't know what was going on on the system
at the time, and it's a multi-user machine with an average of 10 - 20
people logged in at any moment.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-30 08:57:36 UTC
Responsible Changed
From-To: freebsd-bugs->ume

Over to a KAME maintainer.
Comment 2 itojun freebsd_committer freebsd_triage 2000-08-31 01:59:07 UTC
State Changed
From-To: open->feedback

this is because you are out of mbuf on the system. 
try increasing max # of mbuf clusters in the kernel, if you care.
Comment 3 Hajimu UMEMOTO freebsd_committer freebsd_triage 2001-03-13 13:04:33 UTC
State Changed
From-To: feedback->closed

No response from originator for a long time.
Comment 4 silby freebsd_committer freebsd_triage 2002-01-10 18:40:21 UTC
State Changed
From-To: closed->open

If not a bug, this certainly looks like a problem waiting to happen 
to me.  If the comment is true that KAME needs mcls to be contiguous, 
something needs to be done to the allocator, or loopback needs to use 
a smaller MTU.  If the comment is no longer true, then the code 
added in rev 1.44 should be removed.  Either way, this issue isn't 
quite closed.
Comment 5 silby freebsd_committer freebsd_triage 2003-05-23 07:00:02 UTC
Responsible Changed
From-To: ume->silby

I shall fix this in an upcoming commit.
Comment 6 silby freebsd_committer freebsd_triage 2003-06-02 22:56:18 UTC
State Changed
From-To: open->closed

I've committed a good fix to this problem to both -current 
and -stable. 

(In the long run, I hope for the KAME code to be fixed as 
to not need it so that all of this can be removed.)