Date: Tue, 18 Nov 2008 16:16:19 -0800 From: security <security@jim-liesl.org> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: bce discard frame w/o leading ethernet header and polling (broken?) 7.1-beta2 Message-ID: <49235AD3.1090702@jim-liesl.org> In-Reply-To: <200811181344.20092.jkim@FreeBSD.org> References: <492302E2.4040907@jim-liesl.org> <200811181344.20092.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jung-uk Kim wrote: > On Tuesday 18 November 2008 01:01 pm, security wrote: > >> I'm building a WAN emulation box based on 7.1-beta2-ipfw and >> dummynet. The config is basically a router-on-a-stick. The server >> (FBSD rtr) has two nics which connect to two different switches, >> but both switch ports are in the same untagged interconnected vlan. >> All the other test boxes in the network are also in the same vlan, >> but broken into different nets. The different nets are spread >> across the two nics as primary and alias ip address in different >> nets. I've been getting "bursts" (maybe 8-20 at a time) of the >> discard frame messages. Mostly on bce1 but I've seen them on bce0 >> also. bce1 is probably the busier of the 2 currently. As a shot in >> the dark, I disabled polling system wide and the messages seemed to >> have stopped. >> > > Please try the latest driver from RELENG_7. The following commit > seems interesting: > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184826 > > Jung-uk Kim > > >> thanks >> jim >> >> >> kernel: bce1: discard frame w/o leading ethernet header (len >> 4294967292 pkt len 4294967292) >> >> ipfw/dummynet/pipes are being used to rate limit traffic by src/dst >> ip address. >> >> The FreeBSD box uses the broadcom bcm5706s gigE interfaces. >> class=0x020000 card=0x310c103c chip=0x16aa14e4 rev=0x02 hdr=0x00. >> Based on some readings, I've got the following mods in place: >> i386 sources running on a 2 x dual core athalon64 cpus, 4 cores >> active. 8gig of mem available, but only 4 in use >> kernel >> i486 and i586 commented out >> nfs options commented out >> fbsd 4 and 5 commented out >> hz=1000 >> ipfirewall >> ipfirewall_default_to accept >> dummynet >> eisa commented out as well as the older nics >> >> sysctl settings >> kern.polling.enable=1 (setting this to 0 seems to fix the problem, >> but leaves the cpu's busier) >> kern.ipc.maxsockbuf=16777216 (not sure this helps much in the case >> of a rtr) net.inet.ip.forwarding=1 >> net.inet..tcp.sendbuf_auto=1 >> net.inet..tcp.sendbuf_max=16777216 >> net.inet..tcp.recvbuf_auto=1 >> net.inet..tcp.recvbuf_max=16777216 >> net.inet.tcp.rfc1323=1 >> net.link.ether.inet.log_arp_wrong_iface=0 (to suppress the arp >> messages) >> I'm running the new driver now. It's logging Ierrs on the <Link#n> of "netstat -I bcen -a" @ about 1-2 per second. I don't *think* it was doing that under the original driver, but I couldn't swear to it, and it would be difficult to revert right now to check. The errors seem unrelated to traffic generated by ping repeat count or payload size. Might these be the ARP on the wrong iface errors I'm suppressing ? Ping isn't complaining about any dropped packets and I'm not seeing any drops or collision stats. jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49235AD3.1090702>