Bug 78968
| Summary: | FreeBSD freezes on mbufs exhaustion (network interface independent) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Jakub Kruszona-Zawadzki <acid> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | chris, rew |
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
I am seeing this too: The fxp driver is receiving a return of ENOBUFS from m_getcl() (no surprise there). However, since there are no clusters available and the fxp driver has frames to DMA from its FIFO; it keeps calling for clusters which never happens successfully. It appears the system is hung but; in fact, it is in a tight loop. I believe BSD 4.x had a patch that fixed a panic for the exhaustion situation since the code would be de-referencing a NULL pointer. So, now we have a test for NULL and the return of ENOBUFS. That's one way of not seeing the current problem ;-) Another way is to fix this. The test for NULL is certainly appropriate however, what happens next isn't. I am looking to contact the relevant committer(s) for a discussion as to how to resolve this problem. Regards, Ernie ;-) Responsible Changed From-To: freebsd-bugs->gnn This shoiuld be verified or closed. Responsible Changed From-To: gnn->freebsd-net 5.3 bug, probably no longer relevant. For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped |
We are using all of our output bandwidth. Tcp stack allocates mbufs for output queues. When mbufs space is exhausted system freezes. Even 'numlock' on keyboard don't work. It looks like kernel is going into an infinite loop or something - system is dead and the only thing you can do is reboot. Fix: This problem doesn't exist in FreeBSD 4.x How-To-Repeat: Set max mbufs to a small number (only for testing). Generate a file about 300kB (i.e. dd if=/dev/urandom of=/tmp/file bs=1024 count=300). Add to inetd.conf line like this: telnet stream tcp nowait root /bin/cat cat /tmp/file Restart inetd with these options (maybe not all are necessary): inetd -c 0 -C 0 -R 0 -s 0 On remote machine run many processes that will open many connections to your serwer on telent port, but WILL NOT download the file. You can use these programs: In python: #!/usr/bin/env python from socket import socket from time import sleep socks = [] for i in xrange(240): try: s = socket() s.connect(('192.168.0.1',23)) socks.append(s) except Exception: pass print "opened" sleep(100) for i in socks: i.close() In php: <? for ($i=0;$i<1000;$i++) { if(!($file[$i]=fsockopen('192.168.0.1',23))) break; fgets($file[$i],1); } ?> FreeBSD 5.3 with default number of mbufs (about 17000) freezes after a few minutes, when both these programs work in several (6 pythons an 15 phps) copies. While these programs are active, "netstat -n" should be showing many "ESTABLISHED" connections with full output queue. In "netstat -m" output number of "mbufs in use" and "mbuf clusters in use" should increase. When current number of "mbuf clusters in use" reaches max value, system freezes in a few seconds. During normal work "netstat -m" looks like this: 334 mbufs in use 198/17088 mbuf clusters in use (current/max) 0/3/4528 sfbufs in use (current/peak/max) 479 KBytes allocated to network 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 104 calls to protocol drain routines