| Summary: | dmesg output: looutput: mbuf allocation failed | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Robert Watson <rwatson> |
| Component: | kern | Assignee: | silby |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->ume Over to a KAME maintainer. 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. State Changed From-To: feedback->closed No response from originator for a long time. 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. Responsible Changed From-To: ume->silby I shall fix this in an upcoming commit. 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.) |
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.