Re: [POLLING] strange interrupt/system load
Bruce Evans wrote: On Sat, 12 Sep 2009, rihad wrote: The box experiences ~230 mbit/s traffic flow through it. I've doubled some sysctls after reading polling(4): kern.polling.each_burst=10 # was: 5 kern.polling.burst_max=350 # was: 150 FreeBSD 7.2-RELEASE-p3 amd64 HZ=1000 How much better does it work without POLLING? Without polling (current load around 190-200 mbit/s, around 24-26 kpps): top: CPU: 0.0% user, 0.0% nice, 8.4% system, 0.0% interrupt, 91.6% idle Interrupts/s: 18322 total 28 mpt0 irq16 1999 cpu0: time 6906 em0 irq256 3392 em1 irq257 1999 cpu1: time 1999 cpu2: time 1999 cpu3: time ___ 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"
Intel Dual port pro/1000: watchdog timeouts and no packets received
This is a very new card which I haven't seen before on the market until recently. Card: E1G42ET (Intel Gigabit PCIe ET Dual Port Adapter 82576) Server: Supermicro X7SLA-H Operating system: FreeBSD 7.2-RELEASE and 7.2-STABLE IGB Drivers: 1.4.1 and updated 1.7.3 from intel website igb0: port 0xcc00-0xcc1f mem 0xfe9e-0xfe9f,0xfe40-0xfe7f,0xfe9dc000-0xfe9d irq 10 at device 0.0 on pci1 igb0: Using MSIX interrupts with 0 vectors igb0: [FILTER] igb0: Ethernet address: 00:1b:21:43:2f:a0 igb1: port 0xc880-0xc89f mem 0xfe9a-0xfe9b,0xfdc0-0xfdff,0xfe9d8000-0xfe9dbfff irq 11 at device 0.1 on pci1 igb1: Using MSIX interrupts with 0 vectors igb1: [FILTER] igb1: Ethernet address: 00:1b:21:43:2f:a1 i...@pci0:1:0:0:class=0x02 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet i...@pci0:1:0:1:class=0x02 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet Card detects OK but when you assign an IP and try to ping, no packets are received, not even ARP replies. This appears on the console: igb0: watchdog timeout -- resetting igb0: Queue(0) tdh = 9, tdt = 9 igb0: Queue(0) desc avail = 247, Next Desc to Clean = 0 igb0: link state changed to DOWN igb0: link state changed to UP Thanks, - Andrew ___ 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"
Re: [POLLING] strange interrupt/system load
--- On Sun, 9/13/09, rihad wrote: > From: rihad > Subject: Re: [POLLING] strange interrupt/system load > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Sunday, September 13, 2009, 9:11 AM > Barney Cordoba wrote: > > > 1) Why are you polling with a NIC that can be > precisely set to > > interrupt as often or as little as you like? > How? > > > 2) Why do so many people run systems with high network > load with > > AMD64 builds when its significantly slower to do so? > Do you have > > google sized databases so you need 64-bit pointers? > What's wrong with 64 bits? Suit yourself, but the empirical evidence suggests otherwise. Barney ___ 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"
Re: [POLLING] strange interrupt/system load
--- On Mon, 9/14/09, rihad wrote: > From: rihad > Subject: Re: [POLLING] strange interrupt/system load > To: "Bruce Evans" > Cc: freebsd-net@FreeBSD.org > Date: Monday, September 14, 2009, 3:38 AM > Bruce Evans wrote: > > On Sat, 12 Sep 2009, rihad wrote: > > > >> The box experiences ~230 mbit/s traffic flow > through it. I've doubled some sysctls after reading > polling(4): > >> kern.polling.each_burst=10 # was: 5 > >> kern.polling.burst_max=350 # was: 150 > >> > >> FreeBSD 7.2-RELEASE-p3 amd64 > >> HZ=1000 > > > > How much better does it work without POLLING? > > > Without polling (current load around 190-200 mbit/s, around > 24-26 kpps): > > top: > CPU: 0.0% user, 0.0% nice, 8.4% > system, 0.0% interrupt, 91.6% idle > > Interrupts/s: 18322 total > 28 mpt0 irq16 > 1999 cpu0: time > 6906 em0 irq256 > 3392 em1 irq257 > 1999 cpu1: time > 1999 cpu2: time > 1999 cpu3: time You really need to look at the taskq usage as averaging on a 4 core system muddies things up. em will generally run on 1 core per NIC, and interrupts are filtered so you won't see any interrupt usage. On a 4 core system you could exhaust a core and still be at 25% overall, so you need to watch the max usage per core. Things aren't measured properly in polling mode so its difficult to compare them one to one. You really don't need to; intuitively it makes zero sense to use polling with em. You'll do a lot better setting your ITR to 2000 or so. You really don't need an interrupt every 4 packets at those traffic levels. Barney ___ 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"
Re: Intel Dual port pro/1000: watchdog timeouts and no packets received
--- On Mon, 9/14/09, Andrew Snow wrote: > From: Andrew Snow > Subject: Intel Dual port pro/1000: watchdog timeouts and no packets received > To: "FreeBSD Net" > Cc: "Jack Vogel" > Date: Monday, September 14, 2009, 3:40 AM > > This is a very new card which I haven't seen before on the > market until recently. > > Card: E1G42ET (Intel Gigabit PCIe ET Dual Port > Adapter 82576) > Server: Supermicro X7SLA-H > Operating system: FreeBSD 7.2-RELEASE and 7.2-STABLE > IGB Drivers: 1.4.1 and updated 1.7.3 from intel website > > > > igb0: 1.7.3> port 0xcc00-0xcc1f mem > 0xfe9e-0xfe9f,0xfe40-0xfe7f,0xfe9dc000-0xfe9d > irq 10 at device 0.0 on pci1 > igb0: Using MSIX interrupts with 0 vectors > igb0: [FILTER] > igb0: Ethernet address: 00:1b:21:43:2f:a0 > > igb1: 1.7.3> port 0xc880-0xc89f mem > 0xfe9a-0xfe9b,0xfdc0-0xfdff,0xfe9d8000-0xfe9dbfff > irq 11 at device 0.1 on pci1 > igb1: Using MSIX interrupts with 0 vectors > igb1: [FILTER] > igb1: Ethernet address: 00:1b:21:43:2f:a1 > > i...@pci0:1:0:0: class=0x02 > card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 > vendor = 'Intel > Corporation' > class = network > subclass = ethernet > > i...@pci0:1:0:1: class=0x02 > card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 > vendor = 'Intel > Corporation' > class = network > subclass = ethernet > > Card detects OK but when you assign an IP and try to ping, > no packets are received, not even ARP replies. > > This appears on the console: > > igb0: watchdog timeout -- resetting > igb0: Queue(0) tdh = 9, tdt = 9 > igb0: Queue(0) desc avail = 247, Next Desc to Clean = 0 > igb0: link state changed to DOWN > igb0: link state changed to UP > 0 MSI/X vectors can't be a good thing. Another late night for Jack... BC ___ 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"
Re: [POLLING] strange interrupt/system load
--- On Sun, 9/13/09, rihad wrote: > From: rihad > Subject: Re: [POLLING] strange interrupt/system load > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Sunday, September 13, 2009, 10:33 AM > Barney Cordoba wrote: > > > > --- On Sun, 9/13/09, rihad > wrote: > >> What's wrong with 64 bits? > > > > I haven't spent a large portion of my life trying to > figure > > it out exactly, but I'd guess that the larger size of > the structures and code results in fewer cache hits. > > Then what's wrong with also doubling cache sizes? Your logic is faulty here. Doubling the cache size also would increase the performance of the 32 bit version. In fact you'd probably increase the advantage of running in 32 bit mode. > Besides, apart from other benefits, 64-bit makes every-day > big number arithmetic a single CPU instruction as opposed to > several instructions required on 32-bit CPUs through bignum > emulation. You move a lot more memory than you do math in an OS. Perhaps a benchmark to calculate the US national debt would benefit, but its not going to do much for the FreeBSD network stack. Barney ___ 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"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/138782 net[panic] sbflush_internal: cc 0 || mb 0xff004127b00 o kern/138739 net[wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net[bge] FreeBSD 6.3 release does not recognize Broadcom p kern/138691 net[netinet] [patch] Multicast: Keep membership and filte p kern/138690 net[netinet] [patch] multicast: uninited memory used in f p kern/138689 net[netinet] patch] Multicast: IP_DROP_MEMBERSHIP should o amd64/138688 net[rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net[lo] FreeBSD does not assign linklocal address to loop o kern/138676 net[route] after buildworld not work local routes [regres o kern/138666 net[multicast] [panic] not working multicast through igmp o kern/138660 net[igb] igb driver troubles in 8.0-BETA4 o kern/138652 netTCP window scaling value calculated incorrectly? o kern/138632 net[ndis] [patch] race at vap destroy o kern/138620 net[lagg] [patch] lagg port bpf-writes blocked o kern/138427 net[wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net[gre] gre(4) interface does not come up after reboot o kern/138390 net[gif] [patch] NULL pointer dereference in gif_input() o kern/138378 net[altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net[tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net[panic] kernel panic when udp benchmark test used as r o kern/138130 net[netinet] [patch] Resource leak in LibAliasRefreshModu o kern/138046 net[tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net[netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net[patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137795 net[sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net[rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net[netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 netifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net[ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net[patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net[ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net[ral] FreeBSD doesn't support wireless interface from o kern/137317 net[tcp] logs full of syncache problems o kern/137292 net[ste] DFE-580TX not working properly o kern/137279 net[bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137170 net[ath] atheros AR9285 not recognised p kern/137164 net[netinet] [patch] assert panic imo_match_source() o kern/137089 net[lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net[patch] ifconfig(8) print carp mac address o kern/136943 net[wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net[netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net[bge] bge will not resume properly after suspend o kern/136836 net[ath] atheros card stops functioning after about 12 ho o kern/136618 net[pf][stf] panic on cloning interface without unit numb o kern/136482 net[age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136168 net[em] em driver initialization fails on Intel 5000PSL m o kern/135836 net[bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net[periodic] Warning message raised by rtfree function i o kern/135222 net[igb] low speed routing between two igb interfaces o kern/135067 net[patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net[em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net[route] [fib] Route messages sent to all socket listen o kern/134658 net[bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net[hang] Machine with jail freezes after random amount o o kern/134531 net[route] [panic] kernel crash related to routes/zebra o kern/134401 net[msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net[route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net[ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net[dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net[em] "em0: Inv
Re: [POLLING] strange interrupt/system load
Barney Cordoba wrote: Without polling (current load around 190-200 mbit/s, around 24-26 kpps): top: CPU: 0.0% user, 0.0% nice, 8.4% system, 0.0% interrupt, 91.6% idle Interrupts/s: 18322 total 28 mpt0 irq16 1999 cpu0: time 6906 em0 irq256 3392 em1 irq257 1999 cpu1: time 1999 cpu2: time 1999 cpu3: time You really need to look at the taskq usage as averaging on a 4 core CPU: 0.0% user, 0.0% nice, 10.0% system, 0.0% interrupt, 90.0% idle 27 root1 -68- 0K16K - 1 137:47 40.28% em0 taskq 28 root1 -68- 0K16K - 2 5:05 0.88% em1 taskq You'll do a lot better setting your ITR to 2000 or so. You really don't need an interrupt every 4 packets at those traffic levels. Sorry, how would I do that? And how do I find the current ITR value? ___ 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"
Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family
The following reply was made to PR kern/127587; it has been noted by GNATS. From: matthieu To: bug-follo...@freebsd.org, n...@freebsd.org Cc: Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X family Date: Mon, 14 Sep 2009 14:38:16 +0200 --0016364c76519f4566047388f05a Content-Type: text/plain; charset=ISO-8859-1 Hi, Here a minimalist patch against 8.0-BETA1 to make it works on dell E5400 (BCM5761, dev_id=0x1680). It may be useful for someone. -- matthieu --0016364c76519f4566047388f05a Content-Type: application/octet-stream; name="patch_5761.patch" Content-Disposition: attachment; filename="patch_5761.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 LS0tIGlmX2JnZS5jLmJhY2sJMjAwOS0wNy0wOCAyMDozNjo0NS4wMDAwMDAwMDAgKzAyMDAKKysr IGlmX2JnZS5jCTIwMDktMDktMTIgMDA6MTI6NTMuMDAwMDAwMDAwICswMjAwCkBAIC0yNzIsNiAr MjcyLDcgQEAKIAl7IEJHRV9DSElQSURfQkNNNTc1NV9BMSwJIkJDTTU3NTUgQTEiIH0sCiAJeyBC R0VfQ0hJUElEX0JDTTU3NTVfQTIsCSJCQ001NzU1IEEyIiB9LAogCXsgQkdFX0NISVBJRF9CQ001 NzIyX0EwLAkiQkNNNTcyMiBBMCIgfSwKKwl7IEJHRV9DSElQSURfQkNNNTc2MSwJCSJCQ001NzYx IiB9LCAKIAkvKiA1NzU0IGFuZCA1Nzg3IHNoYXJlIHRoZSBzYW1lIEFTSUMgSUQgKi8KIAl7IEJH RV9DSElQSURfQkNNNTc4N19BMCwJIkJDTTU3NTQvNTc4NyBBMCIgfSwgCiAJeyBCR0VfQ0hJUElE X0JDTTU3ODdfQTEsCSJCQ001NzU0LzU3ODcgQTEiIH0sCkBAIC0yNDE3LDYgKzI0MTgsMTIgQEAK IAlzYy0+YmdlX2FzaWNyZXYgPSBCR0VfQVNJQ1JFVihzYy0+YmdlX2NoaXBpZCk7CiAJc2MtPmJn ZV9jaGlwcmV2ID0gQkdFX0NISVBSRVYoc2MtPmJnZV9jaGlwaWQpOwogCisJaWYgKHNjLT5iZ2Vf YXNpY3JldiA9PSBCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRykKKwkgIHsKKwkgICAgc2MtPmJnZV9j aGlwaWQgPSBwY2lfcmVhZF9jb25maWcoZGV2LCBCR0VfUENJX1BST0RJRF9BU0lDUkVWLCA0KTsK KwkgIH0KKworCiAJLyoKIAkgKiBEb24ndCBlbmFibGUgRXRoZXJuZXRAV2lyZVNwZWVkIGZvciB0 aGUgNTcwMCwgNTkwNiwgb3IgdGhlCiAJICogNTcwNSBBMCBhbmQgQTEgY2hpcHMuCkBAIC0yNDI0 LDggKzI0MzEsOSBAQAogCWlmIChzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTcw MCAmJgogCSAgICBzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTkwNiAmJgogCSAg ICBzYy0+YmdlX2NoaXBpZCAhPSBCR0VfQ0hJUElEX0JDTTU3MDVfQTAgJiYKLQkgICAgc2MtPmJn ZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001NzA1X0ExKQotCQlzYy0+YmdlX2ZsYWdzIHw9IEJH RV9GTEFHX1dJUkVTUEVFRDsKKwkgICAgc2MtPmJnZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001 NzA1X0ExICYmCisJICAgIHNjLT5iZ2VfY2hpcGlkICE9IEJHRV9DSElQSURfQkNNNTc2MSkKKwkg IHNjLT5iZ2VfZmxhZ3MgfD0gQkdFX0ZMQUdfV0lSRVNQRUVEOwogCiAJaWYgKGJnZV9oYXNfZWFk ZHIoc2MpKQogCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0VBRERSOwpAQCAtMjQ3NCw2ICsy NDgyLDEwIEBACiAJCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0JFUl9CVUc7CiAJfQogCisJ aWYgKHNjLT5iZ2VfY2hpcGlkID09IEJHRV9DSElQSURfQkNNNTc2MSkKKwkgIHsKKwkgICAgc2Mt PmJnZV9mbGFncyB8PSBCR0VfRkxBR181NzA1X1BMVVM7CisJICB9CiAKIAkvKgogCSAqIFdlIGNv dWxkIHBvc3NpYmx5IGNoZWNrIGZvciBCQ09NX0RFVklDRUlEX0JDTTU3ODggaW4gYmdlX3Byb2Jl KCkKLS0tIGlmX2JnZXJlZy5oLm9sZAkyMDA5LTAzLTIzIDE1OjM2OjUwLjAwMDAwMDAwMCArMDEw MAorKysgaWZfYmdlcmVnLmgJMjAwOS0wOS0xNCAxMjoyMzozOC4wMDAwMDAwMDAgKzAyMDAKQEAg LTIxOCw2ICsyMTgsNyBAQAogI2RlZmluZQlCR0VfUENJX1VORElfVFhfQkRfUFJPRElEWF9MTwkw eEFDCiAjZGVmaW5lCUJHRV9QQ0lfSVNSX01CWF9ISQkJMHhCMAogI2RlZmluZQlCR0VfUENJX0lT Ul9NQlhfTE8JCTB4QjQKKyNkZWZpbmUJQkdFX1BDSV9QUk9ESURfQVNJQ1JFVgkJMHhCQwogCiAv KiBQQ0kgTWlzYy4gSG9zdCBjb250cm9sIHJlZ2lzdGVyICovCiAjZGVmaW5lCUJHRV9QQ0lNSVND Q1RMX0NMRUFSX0lOVEEJMHgwMDAwMDAwMQpAQCAtMzAyLDYgKzMwMyw3IEBACiAjZGVmaW5lCUJH RV9DSElQSURfQkNNNTc4N19BMgkJMHhiMDAyMDAwMAogI2RlZmluZQlCR0VfQ0hJUElEX0JDTTU5 MDZfQTEJCTB4YzAwMTAwMDAKICNkZWZpbmUJQkdFX0NISVBJRF9CQ001OTA2X0EyCQkweGMwMDIw MDAwCisjZGVmaW5lCUJHRV9DSElQSURfQkNNNTc2MQkJMHgwNTc2MTEwMAogCiAvKiBzaG9ydGhh bmQgb25lICovCiAjZGVmaW5lCUJHRV9BU0lDUkVWKHgpCQkJKCh4KSA+PiAyOCkKQEAgLTMxOSw2 ICszMjEsOSBAQAogI2RlZmluZQlCR0VfQVNJQ1JFVl9CQ001NzU0CQkweDBiCiAjZGVmaW5lCUJH RV9BU0lDUkVWX0JDTTU3ODcJCTB4MGIKICNkZWZpbmUJQkdFX0FTSUNSRVZfQkNNNTkwNgkJMHgw YworI2RlZmluZQlCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRwkJMHgwZgorCisjZGVmaW5lCUJHRV9B U0lDUkVWX0JDTTU3NjEJCTB4NTc2MQogCiAvKiBjaGlwIHJldmlzaW9ucyAqLwogI2RlZmluZQlC R0VfQ0hJUFJFVih4KQkJCSgoeCkgPj4gMjQpCkBAIC0yMDk4LDYgKzIxMDMsNyBAQAogI2RlZmlu ZQlCQ09NX0RFVklDRUlEX0JDTTU3MTRTCQkweDE2NjkKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9C Q001NzE1CQkweDE2NzgKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9CQ001NzE1UwkJMHgxNjc5Cisj ZGVmaW5lCUJDT01fREVWSUNFSURfQkNNNTc2MUUJCTB4MTY4MAogI2RlZmluZQlCQ09NX0RFVklD RUlEX0JDTTU3MjAJCTB4MTY1OAogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjEJCTB4MTY1 OQogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjIJCTB4MTY1QQo= --0016364c76519f4566047388f05a-- ___ 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"
Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
The following reply was made to PR kern/138782; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-follo...@freebsd.org, univers...@ukr.net Cc: Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xff004127b000 || mbcnt 2304 Date: Mon, 14 Sep 2009 19:27:14 +0300 http://otrada.od.ua/FreeBSD/crash/core.txt.gz ___ 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"
Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
The following reply was made to PR kern/138782; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-follo...@freebsd.org, univers...@ukr.net Cc: Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xff004127b000 || mbcnt 2304 Date: Mon, 14 Sep 2009 19:27:21 +0300 http://otrada.od.ua/FreeBSD/crash/core.txt.gz ___ 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"
Re: [POLLING] strange interrupt/system load
--- On Mon, 9/14/09, rihad wrote: > From: rihad > Subject: Re: [POLLING] strange interrupt/system load > To: "Barney Cordoba" > Cc: freebsd-net@FreeBSD.org > Date: Monday, September 14, 2009, 7:23 AM > Barney Cordoba wrote: > > > >> Without polling (current load around 190-200 > mbit/s, around > >> 24-26 kpps): > >> > >> top: > >> CPU: 0.0% user, 0.0% nice, 8.4% > >> system, 0.0% interrupt, 91.6% idle > >> > >> Interrupts/s: 18322 total > >> 28 mpt0 irq16 > >> 1999 cpu0: time > >> 6906 em0 irq256 > >> 3392 em1 irq257 > >> 1999 cpu1: time > >> 1999 cpu2: time > >> 1999 cpu3: time > > > > You really need to look at the taskq usage as > averaging on a 4 core > CPU: 0.0% user, 0..0% nice, 10.0% system, > 0.0% interrupt, 90.0% idle > 27 root 1 > -68 - 0K > 16K - 1 137:47 40.28% em0 taskq > 28 root 1 > -68 - 0K > 16K - 2 5:05 > 0.88% em1 taskq > > > You'll do a lot better setting your ITR to 2000 or so. > You really don't > > need an interrupt every 4 packets at those traffic > levels. > > Sorry, how would I do that? And how do I find the current > ITR value? > I made mine a sysctl long ago, so I'm not sure what the current state of em is. It used to be a macro MAX_INTS_PER_SEC Barney ___ 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"
8.0-BETA4 not responding to ARP for published entries
Hello, We have a system which makes heavy use of published arp entries. I know the arp code has been significantly overhauled in 8, but it looks like this functionality is now broken. $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub If I watch tcpdump on the interface, I see arp requests come in but no replies are sent. This is a clean build with no firewalls enabled. The syntax and descriptions don't appear to have changed in the man page, so I would expect this to still work as it has in the past. Please let me know if you need any other information and/or if I should get a PR open for this. If this is a regression, it would be great if it could get committed before the 8.0 release. Thanks, -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgpV1lj9tfiRW.pgp Description: PGP signature
RE: 8.0-BETA4 not responding to ARP for published entries
Could you please email me your routing table privately? Thanks, -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Chris Cowart Sent: Mon 9/14/2009 10:43 AM To: freebsd-net@freebsd.org Subject: 8.0-BETA4 not responding to ARP for published entries Hello, We have a system which makes heavy use of published arp entries. I know the arp code has been significantly overhauled in 8, but it looks like this functionality is now broken. $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub If I watch tcpdump on the interface, I see arp requests come in but no replies are sent. This is a clean build with no firewalls enabled. The syntax and descriptions don't appear to have changed in the man page, so I would expect this to still work as it has in the past. Please let me know if you need any other information and/or if I should get a PR open for this. If this is a regression, it would be great if it could get committed before the 8.0 release. Thanks, -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley ___ 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"
bpf issues
Good day, I hope this is the appropriate list. I am having issues using BPFs to filter out traffic captures. If I want to block a specific host by IP, the traffic is still recorded. I tried tcpdump and get the same results. Am I missing something? Examples: # tcpdump -nt -i igb2 -w tcpdump.pcap not host 10.100.66.31 # tcpdump -nt -r tcpdump.pcap | less IP 10.100.66.31.13724 > 10.100.66.30.3090: . 42904:44352(1448) ack 1 win 64340 IP 10.100.66.31.13724 > 10.100.66.30.3090: . 44352:45800(1448) ack 1 win 64340 IP 10.100.66.30.3090 > 10.100.66.31.13724: . ack 5792 win 65535 IP 10.100.66.31.13724 > 10.100.66.30.3090: . 45800:47248(1448) ack 1 win 64340 It gets stranger, if I read the pcap file and filter for the host it returns blank: # tcpdump -nt -r tcpdump.pcap host 10.100.66.31 reading from file tcpdump.pcap, link-type EN10MB (Ethernet) # I have tried several variations of syntax and had no luck. Also used several tools (tcpdump, tshark, daemonlogger) and have had the same results so I suspect it may be libpcap related. The system is running FreeBSD 7.2 GENERIC amd64 Any suggestions would be much appreciated. Cheers! ___ 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"
Re: bpf issues
> I hope this is the appropriate list. I am having issues using BPFs to > filter out traffic captures. If I want to block a specific host by IP, the > traffic is still recorded. I tried tcpdump and get the same results. > > Am I missing something? Does your igb2 interface use VLAN encapsulation? If it does, you won't see it in the tcpdump output unless you use -e, but you still need to specify it together with your IP based filters - or tcpdump will apply the wrong (off by 4 bytes) offset. E.g. "tcpdump -nt -r tcpdump.pcap vlan and host 10.100.66.31" Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
Re: 8.0-BETA4 not responding to ARP for published entries
At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote: > We have a system which makes heavy use of published arp entries. I know > the arp code has been significantly overhauled in 8, but it looks like > this functionality is now broken. > > $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub > > If I watch tcpdump on the interface, I see arp requests come in but no > replies are sent. This is a clean build with no firewalls enabled. Just for another datapoint, I see the same symptom. I am currently running ports/net-mgmt/choparp as a workaround. At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote: > Subject: proxy arp on 8.0-current? > Date: Thu, 23 Apr 2009 21:13:51 +0900 > To: freebsd-net@freebsd.org > > Hi, > > I'm trying to setup an proxy arp on a dual homed host. > > I noticed that I cannot set it up on 8.0-current the same way as I > could on 6.2; hence the question: have the setup procedure changed > recently (when the arp table was separated from the routing table, > maybe?)? My 8.0-current is from 200902 snapshot. > > Here is a simple demonstration using two single-interfaced hosts: > > setup: > host6.2# ifconfig em0 inet 192.168.0.1/24 > host6.2# arp -s 192.168.0.11 auto pub > host6.2# arp -an | grep permanent > ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet] > ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet] > host6.2# tcpdump -np arp > > host8.0# ifconfig em0 inet 192.168.0.2/24 > host8.0# arp -s 192.168.0.12 auto pub > host8.0# arp -an | grep permanent > ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet] > ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet] > host8.0# tcpdump -np arp > > then, I do: > host6.2# arp -d 192.168.0.2; ping -c 1 192.168.0.2 > host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12 > host8.0# arp -d 192.168.0.1; ping -c 1 192.168.0.1 > host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11 > > I am not caring about 'arp -d' errors (cannot locate) nor ping not > responding (for proxied addresses). I just cared about arp requests and > replys for now. The output of tcpdump on both sides are like this: > > arp who-has 192.168.0.2 tell 192.168.0.1 > arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx > > arp who-has 192.168.0.12 tell 192.168.0.1 > >no reply > > arp who-has 192.168.0.1 tell 192.168.0.2 > arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx > > arp who-has 192.168.0.11 tell 192.168.0.2 > arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx > > As you can see from the above, > 'arp -s 192.168.0.12 auto pub' on 8.0-current host > seems not to be producing proxy arp's. > > What am I missing? > > Thanks. > -- > Hiroharu Tamaru ___ 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"
RE: 8.0-BETA4 not responding to ARP for published entries
Hi, Please try patch at http://people.freebsd.org/~qingli/proxy-arp-patch.diff -- Qing -Original Message- From: owner-freebsd-...@freebsd.org on behalf of Hiroharu Tamaru Sent: Mon 9/14/2009 6:34 PM To: freebsd-net@freebsd.org Subject: Re: 8.0-BETA4 not responding to ARP for published entries At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote: > We have a system which makes heavy use of published arp entries. I know > the arp code has been significantly overhauled in 8, but it looks like > this functionality is now broken. > > $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub > > If I watch tcpdump on the interface, I see arp requests come in but no > replies are sent. This is a clean build with no firewalls enabled. Just for another datapoint, I see the same symptom. I am currently running ports/net-mgmt/choparp as a workaround. At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote: > Subject: proxy arp on 8.0-current? > Date: Thu, 23 Apr 2009 21:13:51 +0900 > To: freebsd-net@freebsd.org > > Hi, > > I'm trying to setup an proxy arp on a dual homed host. > > I noticed that I cannot set it up on 8.0-current the same way as I > could on 6.2; hence the question: have the setup procedure changed > recently (when the arp table was separated from the routing table, > maybe?)? My 8.0-current is from 200902 snapshot. > > Here is a simple demonstration using two single-interfaced hosts: > > setup: > host6.2# ifconfig em0 inet 192.168.0.1/24 > host6.2# arp -s 192.168.0.11 auto pub > host6.2# arp -an | grep permanent > ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet] > ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet] > host6.2# tcpdump -np arp > > host8.0# ifconfig em0 inet 192.168.0.2/24 > host8.0# arp -s 192.168.0.12 auto pub > host8.0# arp -an | grep permanent > ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet] > ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet] > host8.0# tcpdump -np arp > > then, I do: > host6.2# arp -d 192.168.0.2; ping -c 1 192.168.0.2 > host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12 > host8.0# arp -d 192.168.0.1; ping -c 1 192.168.0.1 > host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11 > > I am not caring about 'arp -d' errors (cannot locate) nor ping not > responding (for proxied addresses). I just cared about arp requests and > replys for now. The output of tcpdump on both sides are like this: > > arp who-has 192.168.0.2 tell 192.168.0.1 > arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx > > arp who-has 192.168.0.12 tell 192.168.0.1 > >no reply > > arp who-has 192.168.0.1 tell 192.168.0.2 > arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx > > arp who-has 192.168.0.11 tell 192.168.0.2 > arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx > > As you can see from the above, > 'arp -s 192.168.0.12 auto pub' on 8.0-current host > seems not to be producing proxy arp's. > > What am I missing? > > Thanks. > -- > Hiroharu Tamaru ___ 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" ___ 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"
