On Thursday 25 October 2012, David Christensen wrote: > > sysctl -a | g bce.3|g -vE '(%|stat)'; echo; sleep 10; sysctl -a | g bce.3| > > g -vE '(%|stat)'; echo; netstat -m > > > > dev.bce.3.l2fhdr_error_count: 0 > > dev.bce.3.mbuf_alloc_failed_count: 2098854 > > dev.bce.3.mbuf_frag_count: 2655285 > > dev.bce.3.dma_map_addr_rx_failed_count: 0 > > dev.bce.3.dma_map_addr_tx_failed_count: 57 > > dev.bce.3.unexpected_attention_count: 0 > > dev.bce.3.com_no_buffers: 0 > > > > dev.bce.3.l2fhdr_error_count: 0 > > dev.bce.3.mbuf_alloc_failed_count: 2098856 > > dev.bce.3.mbuf_frag_count: 2655288 > > dev.bce.3.dma_map_addr_rx_failed_count: 0 > > dev.bce.3.dma_map_addr_tx_failed_count: 57 > > dev.bce.3.unexpected_attention_count: 0 > > dev.bce.3.com_no_buffers: 0 > > > > > > Any suggestions? What is the reason of this? > > It's normal in a system under load, the kernel can't always > allocate memory when requested by the driver. The result > is that RX frames will be dropped as the driver reuses an > existing mbuf, a response taken by many other drivers. > > If you notice rapid increases during certain system operations > then you should consider increasing the amount of system > memory. >
Thanks for you answer, Dave. What do you mean under "systems memory"? Is it the physical memory or the virtual one? -- EVM7-RIPE _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
