From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 11:06:58 2009 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B49A1065672 for ; Mon, 30 Nov 2009 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 378828FC1B for ; Mon, 30 Nov 2009 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUB6wk9043500 for ; Mon, 30 Nov 2009 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUB6vh9043498 for freebsd-net@FreeBSD.org; Mon, 30 Nov 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Nov 2009 11:06:57 GMT Message-Id: <200911301106.nAUB6vh9043498@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 11:06:58 -0000 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/140970 net [bce] The two NetXtreme II BCM5709S NICs on our HP Bl4 o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140684 net [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection f bin/140571 net [patch] ifconfig(8) does not set country DE o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140358 net 8.0RC2: [arp] arp: writing to routing socket: Invalid o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net [iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139559 net [tun] several tun(4) interfaces can be created with sa o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 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 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 f 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 net TCP window scaling value calculated incorrectly? 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/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/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 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 p 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 net ifconfig(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/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/136426 net [panic] spawning several dhclients in parallel panics 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: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [if_em] FreeBSD 7 multicast routing problem o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] ppp(8): fix local stack overflow in ppp o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 372 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 16:39:34 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732491065696 for ; Mon, 30 Nov 2009 16:39:34 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 18DF08FC1C for ; Mon, 30 Nov 2009 16:39:33 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 30 Nov 2009 08:12:16 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.3) with ESMTP id nAUGK9Jx085079; Mon, 30 Nov 2009 08:20:09 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id nAUGK9U3085078; Mon, 30 Nov 2009 08:20:09 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200911301620.nAUGK9U3085078@ambrisko.com> In-Reply-To: To: pluknet Date: Mon, 30 Nov 2009 08:20:09 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: svn commit: r198994 - in stable/6/sys/dev: bce mii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:39:34 -0000 pluknet writes: [ Charset ISO-8859-1 unsupported, converting... ] | 2009/11/6 Doug Ambrisko : | > Author: ambrisko | > Date: Fri Nov ?6 17:58:44 2009 | > New Revision: 198994 | > URL: http://svn.freebsd.org/changeset/base/198994 | > | > Log: | > ?MFC: Merge in minimal 5709/5716 support into 6.X extracted from current. | > ?This is not a direct merge since I tried to only extra the changes to | > ?support the 5709 from all of the other changes that have happened in | > ?head. ?This should not introduce any issues that the other changes may | > ?have caused. ?We have been running this code for months on Dell r710's. | > ?It has been lightly tested on systems with 5716's. | > | > ?This is to allow people to run newer hardware on 6.X. | | Very nice. Thank you. | | I'm afraid not all the chunks were merged since I cannot run on 6.x | with my BCM5709. | | FreeBSD 7.2 - works | FreeBSD 6.4-stable - does not | | It locks up somewhere in the late stage of multiuser (usually in a | random step of rc.d) and getty cannot take the control. | Here it still pings via network, I can achieve ssh stage where ssh | warns me "The authenticity of host '$HOST' can't be established." | If I type "yes", then it stops here and no go. After return from ddb | it stops even ping until next reboot. | | I use boot via NFS/PXE, so it may interfere there, since rc.d usually | write something to disk, which is NFS-mounted here. | So it probably could run fine if booting from a local disk (I can't | test this setup). You might try to instrument the rc stuff even though you mention it appears random. Might try to make sure that it isn't re-initializing the network or something like that. I tried with a fresh checkout of 6-stable and I PXE booted it fine. A side note is that Dell's have a bug with their uarts starting with the 2950 rev 2 in which the TX does work with the speed that we do the reset. RX works fine so you can recover it with a {Ctrl}d since it doesn't always fail. | I've attached dmesg (doesn't differs much from 7.2) and some ddb output below. | Looking in alltrace I see no obvious lockups, no nfs stuck. But | sometimes sh stucks somewhere in nfsreq. | | The same box boots fine via NFS on different NFS setup with 7.2, | a different (in h/w) box boots fine on these NFS setup and NFS root, | so no mistakes in setup part. | | I remember that back to August I tried to boot 6.4 with what is in bce | of RELENG_7 on this box and it booted fine and I xmitted some traffic | with it. | So I guess the problem is in NFS-boot. | | I'll try to find ways to boot the system locally and report back.. I didn't see anything in the logs. Doug A. From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 19:18:04 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E65E5106566B; Mon, 30 Nov 2009 19:18:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BC52A8FC18; Mon, 30 Nov 2009 19:18:04 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 75A7E46B09; Mon, 30 Nov 2009 14:18:04 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AEA358A021; Mon, 30 Nov 2009 14:18:03 -0500 (EST) From: John Baldwin To: Hajimu UMEMOTO Date: Mon, 30 Nov 2009 13:00:03 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200911231255.26279.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200911301300.03324.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 30 Nov 2009 14:18:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:18:05 -0000 On Wednesday 25 November 2009 11:01:16 am Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Mon, 23 Nov 2009 12:55:25 -0500 > >>>>> John Baldwin said: > > I updated the patch. > > jhb> I had missed the me vs any. It is true that the equivalent rule would use > jhb> me6. I would rather figure out the IPv6 bug so that TCP is treated the > jhb> same for both protocols instead of having a weaker firewall for IPv6 than > jhb> IPV4. > > Yes, it is better, definitely. I thought that we could change to use > dynamic rule, once it was fixed. > Since the PR kern/117234 fixed it, I changed to use dynamic rule for > IPv6 as well. So, it requires the patch in the PR. > > jhb> I do find the shorter version easier to read, and it matches the existing > jhb> style as well as the examples in the manual page, handbook, etc. > > Okay, I changed 'ip6' to 'all' where we can use it, and stopped use of > 'proto xxx'' as possible. > > I reconsidered oif vs oif6 and iif vs iif6 issue. Now, if > $firewall_simple_oif_ipv6 is not set, $firewall_simple_oif is assumed > for oif6, and, $firewall_simple_iif_ipv6 is not set, > $firewall_simple_iif is assumed for iif6. > Further, I think we don't assign a global IPv6 address to oif in > usual. So, I made $firewall_simple_onet_ipv6 optional. > One more change is that DHCPv6 is allowed as well as IPv4 DHCP for > WORKSTATION type. I'm using DHCPv6 in usual; L2TP + DHCPv6 PD, DHCPv6 > DNS option ... > > Sincerely, I think you can just remove the ipv6_firewall_* variables from /etc/defaults/rc.conf completely. Perhaps you can use 'set_rcvar_obsolete' in /etc/rc.firewall to emit a warning if ipv6_firewall_enable is defined? Or maybe just emit an explicit warning in /etc/rc.firewall in that case? Other than that I think this patch looks good. Thanks for fixing this! -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 19:30:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE3901065670 for ; Mon, 30 Nov 2009 19:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AE9DF8FC15 for ; Mon, 30 Nov 2009 19:30:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAUJU2Yt078903 for ; Mon, 30 Nov 2009 19:30:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAUJU269078891; Mon, 30 Nov 2009 19:30:02 GMT (envelope-from gnats) Date: Mon, 30 Nov 2009 19:30:02 GMT Message-Id: <200911301930.nAUJU269078891@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Korba Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Korba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 19:30:04 -0000 The following reply was made to PR kern/134079; it has been noted by GNATS. From: Korba To: bug-followup@FreeBSD.org, g.zhengming@gmail.com Cc: Subject: Re: kern/134079: [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8.0) Date: Mon, 30 Nov 2009 19:52:45 +0100 I had the same problem. I changed the e1000_read_mac_addr_generic() function in /usr/src/sys/dev/e1000/e1000_nvm.c to the 7.2 version. It works for me. Good luck, Piotr "Korba" Tomczyk From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 21:22:52 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90266106566B; Mon, 30 Nov 2009 21:22:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 691468FC0A; Mon, 30 Nov 2009 21:22:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAULMqJe083438; Mon, 30 Nov 2009 21:22:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAULMqTl083434; Mon, 30 Nov 2009 21:22:52 GMT (envelope-from linimon) Date: Mon, 30 Nov 2009 21:22:52 GMT Message-Id: <200911302122.nAULMqTl083434@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141023: [carp] CARP arp replays with wrong src mac X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:22:52 -0000 Old Synopsis: CARP arp replays with wrong src mac New Synopsis: [carp] CARP arp replays with wrong src mac Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 30 21:21:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141023 From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 21:43:12 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28EB1065670 for ; Mon, 30 Nov 2009 21:43:12 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out10.libero.it (cp-out10.libero.it [212.52.84.110]) by mx1.freebsd.org (Postfix) with ESMTP id B72A88FC24 for ; Mon, 30 Nov 2009 21:43:12 +0000 (UTC) Received: from soth.ventu (151.51.164.240) by cp-out10.libero.it (8.5.107) id 4B1363870027BCA8 for freebsd-net@freebsd.org; Mon, 30 Nov 2009 22:43:11 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.3/8.14.2) with ESMTP id nAULhACS041202 for ; Mon, 30 Nov 2009 22:43:10 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <4B143C6E.3030609@netfence.it> Date: Mon, 30 Nov 2009 22:43:10 +0100 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.23 (X11/20090828) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Connecting to a WatchGuard box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 21:43:13 -0000 Hello. A customer of mine was connecting to a remote WatchGuard box through their Mobile VPN client. Now I'd like the server to take over that and le the whole network connect. Did anyone ever succeded in this? Is it possible? Should be IPSEC, but anyone has an how-to? bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 22:17:05 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9229106566B for ; Mon, 30 Nov 2009 22:17:04 +0000 (UTC) (envelope-from thodoriss@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 58DB78FC08 for ; Mon, 30 Nov 2009 22:17:04 +0000 (UTC) Received: by ewy26 with SMTP id 26so4630210ewy.3 for ; Mon, 30 Nov 2009 14:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=9aTsq1k2HczmM4K9qpX2aOXd/2rkYIpcfXFMCGjM5VQ=; b=ODCs3WuVyN9Tqar/J8HO5Vb1z9y8A8QraIknuc/BHN5rIW2IvwT+GCPpwudQfzCk0h AQ7hPnVxSVFzwt0tM+qbVKKSM4/reD9sdrvKYCdwCbjMgvR0qid7L4+ljzF936fQ2OAt r96Sv1J/CRCwJFXnsdSa8cagVid4l0gDWYq7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=LNVOtmd+1STeBSxQKv/RKkIDBjNzMpqi7w9dccvvBnNjSCpkLm2iGHi7k5EbtJKJs4 PwwHYlSdLs4EvdldaVyUN5l2AEENZ8ky+OOPbAn/oy+ju9oxtqSO1oLTp5H0FO2CeCgZ 8skCwwyZ8IvpNG9HQuSpVITVvhUXOXPKkot/Y= Received: by 10.213.110.9 with SMTP id l9mr227279ebp.14.1259619423229; Mon, 30 Nov 2009 14:17:03 -0800 (PST) Received: from paranic7b99.lan (ppp-94-67-212-111.home.otenet.gr [94.67.212.111]) by mx.google.com with ESMTPS id 13sm2792301ewy.9.2009.11.30.14.17.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 14:17:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Thodoris Stamatopoulos In-Reply-To: <4B08214F.8070204@gmx.com> Date: Tue, 1 Dec 2009 00:17:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3739D5B5-5AA3-47A5-B8FA-AC35EF6B273E@gmail.com> References: <927edfce0911190736r3f202001h2082052b7922c723@mail.gmail.com> <4B08214F.8070204@gmx.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1077) Subject: Re: MPD Multiple PPPoE to same ISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 22:17:05 -0000 Thank you very much Nikos, at first it didnt worked with the 7.2 Release = kernel (cant compile kernel with radix option), but with 8 it worked = like a charm, all interface now have the same gateway and all ng interfaces have ip at last... Thanks Thodoris (euxaristw:)) On Nov 21, 2009, at 7:20 PM, Nikos Vassiliadis wrote: > Thodoris S. wrote: >> I am trying to make Multiple PPPoE Connections to the Same ISP for >> Load Balancing reasons >> my mpd.conf is: >> default: >> load adsl0 >> load adsl1 >> load adsl2 >> adsl0: >> new -i ng0 pppoe0 pppoe0 >> set iface route default >> set iface disable on-demand >> set iface idle 0 >> set bundle disable multilink >> set bundle authname "***" >> set bundle password "***" >> set bundle no noretry >> set link keep-alive 10 60 >> set link max-redial 0 >> set link no acfcomp protocomp >> set link disable pap chap >> set link accept chap >> set link mtu 1492 >> set ipcp yes vjcomp >> set ipcp ranges 0.0.0.0/0.0.0.0/0 >> set ipcp enable req-pri-dns >> set ipcp enable req-sec-dns >> open >> adsl1: >> new -i ng1 pppoe1 pppoe1 >> set iface route default >> set iface disable on-demand >> set iface idle 0 >> set bundle disable multilink >> set bundle authname "***" >> set bundle password "***" >> set bundle no noretry >> set link keep-alive 10 60 >> set link max-redial 0 >> set link no acfcomp protocomp >> set link disable pap chap >> set link accept chap >> set link mtu 1492 >> set ipcp yes vjcomp >> set ipcp ranges 0.0.0.0/0.0.0.0/0 >> set ipcp enable req-pri-dns >> set ipcp enable req-sec-dns >> open >> adsl2: >> new -i ng2 pppoe2 pppoe2 >> set iface route default >> set iface disable on-demand >> set iface idle 0 >> set bundle disable multilink >> set bundle authname "***" >> set bundle password "***" >> set bundle no noretry >> set link keep-alive 10 60 >> set link max-redial 0 >> set link no acfcomp protocomp >> set link disable pap chap >> set link accept chap >> set link mtu 1492 >> set ipcp yes vjcomp >> set ipcp ranges 0.0.0.0/0.0.0.0/0 >> set ipcp enable req-pri-dns >> set ipcp enable req-sec-dns >> open >> And mpd.links is: >> pppoe0: >> set link type pppoe >> set pppoe iface em0 >> set pppoe service "we" >> set pppoe enable originate >> set pppoe disable incoming >> pppoe1: >> set link type pppoe >> set pppoe iface em1 >> set pppoe service "we1" >> set pppoe enable originate >> set pppoe disable incoming >> pppoe2: >> set link type pppoe >> set pppoe iface bce1 >> set pppoe service "we2" >> set pppoe enable originate >> set pppoe disable incoming >> The problem is tha only one (the first logged in) ng interface gets = ip >> assigned to it, all others assigned to lo0 interface >> and when i am trying to NAT them with PF it gives me this error: >> /etc/pf.conf:26: could not parse host specification >> im giving you ifconfig and netstat -nr >> ifconfig: >> [root@emperor ~]# ifconfig >> bce0: flags=3D8843 metric 0 = mtu 1500 >> = options=3D1bb >> ether 00:1e:c9:db:24:7f >> inet 192.168.0.1 netmask 0xfffffff8 broadcast 192.168.0.7 >> media: Ethernet autoselect (1000baseTX ) >> status: active >> em0: flags=3D8843 metric 0 = mtu 1500 >> = options=3D19b >> ether 00:15:17:78:fd:56 >> inet 192.168.101.1 netmask 0xffffff00 broadcast 192.168.101.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> em1: flags=3D8843 metric 0 = mtu 1500 >> = options=3D19b >> ether 00:15:17:78:fb:41 >> inet 192.168.102.1 netmask 0xffffff00 broadcast 192.168.102.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> bce1: flags=3D8843 metric 0 = mtu 1500 >> = options=3D1bb >> ether 00:1e:c9:db:24:7d >> inet 192.168.103.1 netmask 0xffffff00 broadcast 192.168.103.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> lo0: flags=3D8049 metric 0 mtu 16384 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> pflog0: flags=3D141 metric 0 mtu 33204 >> ng0: flags=3D88d1 = metric >> 0 mtu 1492 >> inet 11.11.11.11 --> 12.12.12.2 netmask 0xffffffff >> ng1: flags=3D88d1 = metric >> 0 mtu 1492 >> ng2: flags=3D88d1 = metric >> 0 mtu 1492 >> nestat -nr: >> Routing tables >> Internet: >> Destination Gateway Flags Refs Use Netif = Expire >> default 192.168.0.2 UGS 0 13812 bce0 >> 192.168.0.0/29 link#1 UC 0 0 bce0 >> 12.12.12.2 11.11.11.11 UH 0 0 ng0 >> 33.33.33.33 lo0 UHS 0 4797 lo0 >> 22.22.22.22 lo0 UHS 0 1370 lo0 >> 11.11.11.11 lo0 UHS 0 0 lo0 >> 127.0.0.1 127.0.0.1 UH 0 0 lo0 >> 192.168.101.0/24 link#2 UC 0 0 em0 >> 192.168.102.0/24 link#3 UC 0 0 em1 >> 192.168.103.0/24 link#4 UC 0 0 bce1 >=20 > Could you add to your kernel config "options RADIX_MPATH" and give it > a go then? >=20 > It seems that you try to add a second point-to-point interface with > the same destination address. For example: > ng0 1.1.1.1 2.2.2.2 and > ng1 1.1.1.2 2.2.2.2 etc >=20 > This is not valid without the aforementioned kernel option. >=20 > I *think* it will be ok then, but do try and report back to the list > your findings. >=20 > HTH, Nikos >=20 From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 22:42:31 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD14106568B for ; Mon, 30 Nov 2009 22:42:31 +0000 (UTC) (envelope-from ol@csa.ru) Received: from ol.homeunix.org (home.obaranov.spb.ru [93.100.48.130]) by mx1.freebsd.org (Postfix) with ESMTP id 15CED8FC0A for ; Mon, 30 Nov 2009 22:42:30 +0000 (UTC) Received: by ol.homeunix.org (Postfix, from userid 110) id C68F815342F; Tue, 1 Dec 2009 01:25:56 +0300 (MSK) X-Virus-Scanned: amavisd-new at csa.ru Received: from ol.homeunix.org ([127.0.0.1]) by localhost (mail.csa.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aCXf8U0y+ox; Tue, 1 Dec 2009 01:25:55 +0300 (MSK) Received: from [192.168.239.248] (unknown [192.168.239.248]) by ol.homeunix.org (Postfix) with ESMTPSA id 78C3B153421; Tue, 1 Dec 2009 01:25:55 +0300 (MSK) Message-ID: <4B144673.9000403@csa.ru> Date: Tue, 01 Dec 2009 01:25:55 +0300 From: Oleg Baranov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andrea Venturoli References: <4B143C6E.3030609@netfence.it> In-Reply-To: <4B143C6E.3030609@netfence.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Connecting to a WatchGuard box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 22:42:31 -0000 Hi! I've been working with Watchguard 8.3 & 9.0 for some time. In general it was fine but we've suffered connection recovery problems after ISP blackouts from time to time. Here is my section of racoon.conf remote a.b.c.d { exchange_mode main; lifetime time 8 hour ; # sec,min,hour my_identifier fqdn "my.dom.ain"; peers_identifier fqdn "watchguard.fw.dn"; initial_contact on; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 1; } proposal_check obey; } Setkey and PSK file records are standard as well as gif interfaces setup. On Watchguard it was Branch Office Gateway and tunnel set up accordingly to the parameters above... Andrea Venturoli wrote: > Hello. > A customer of mine was connecting to a remote WatchGuard box through > their Mobile VPN client. > Now I'd like the server to take over that and le the whole network > connect. > > Did anyone ever succeded in this? Is it possible? > Should be IPSEC, but anyone has an how-to? > > bye & Thanks > av. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 30 23:18:29 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8975E10656C7 for ; Mon, 30 Nov 2009 23:18:29 +0000 (UTC) (envelope-from thodoriss@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1410E8FC20 for ; Mon, 30 Nov 2009 23:18:28 +0000 (UTC) Received: by ewy26 with SMTP id 26so4687037ewy.3 for ; Mon, 30 Nov 2009 15:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=X1+09U7BwpPieyOft730VN/b/ijvqu5aV5C9jCjD9XA=; b=JC3B6AuWkQPsCs0A2aTSCLWpFb5w9UDABTMkTWlFvBOWWwRKp57ufi6qsif5dNIY5i xXx4dFGFNBXS8AMEJNP5UR67TWCPdXiQgj/DgRJPChU2Pe85KC2K9/3NxhzraQcCR0lg AkTialYhVow6OEQ28wv6cwkLvw4e3mC10YeHc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=qiXdW+e61QpJT5SPUS4t849NVIePglFz2jgWFYZbZceELezKoPwAIMXS6mjXus56oR mkayJ79S/I/6MQIbBAH28tcWGgUBQK5EE8fwQIFXv+LCgSAPWT8vFuGnMqZUpfg08F7m acTZafqsSCsv17Rh7mlrz9sDaXcqkWx8jZJ4A= Received: by 10.213.26.138 with SMTP id e10mr5142236ebc.67.1259623108248; Mon, 30 Nov 2009 15:18:28 -0800 (PST) Received: from paranic7b99.lan (ppp-94-67-212-111.home.otenet.gr [94.67.212.111]) by mx.google.com with ESMTPS id 14sm2811932ewy.15.2009.11.30.15.18.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 15:18:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Thodoris Stamatopoulos In-Reply-To: <4B1446AE.2010602@elischer.org> Date: Tue, 1 Dec 2009 01:18:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0495E801-AE87-4DDF-97E4-5D997B221701@gmail.com> References: <927edfce0911190736r3f202001h2082052b7922c723@mail.gmail.com> <4B08214F.8070204@gmx.com> <3739D5B5-5AA3-47A5-B8FA-AC35EF6B273E@gmail.com> <4B1446AE.2010602@elischer.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1077) Subject: Re: MPD Multiple PPPoE to same ISP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 23:18:29 -0000 I didnt knew it!, thanks again guys :) very nice tip especially when you = have a bunch of connections On Dec 1, 2009, at 12:26 AM, Julian Elischer wrote: > Thodoris Stamatopoulos wrote: >> Thank you very much Nikos, at first it didnt worked with the 7.2 = Release kernel (cant compile kernel with radix option), but with 8 it = worked like a charm, all interface now have the same gateway >> and all ng interfaces have ip at last... >> Thanks >> Thodoris >> (euxaristw:)) >> On Nov 21, 2009, at 7:20 PM, Nikos Vassiliadis wrote: >>> Thodoris S. wrote: >>>> I am trying to make Multiple PPPoE Connections to the Same ISP for >>>> Load Balancing reasons >>>> my mpd.conf is: >>>> default: >>>> load adsl0 >>>> load adsl1 >>>> load adsl2 >>>> adsl0: >>>> new -i ng0 pppoe0 pppoe0 >>>> set iface route default >>>> set iface disable on-demand >>>> set iface idle 0 >>>> set bundle disable multilink >>>> set bundle authname "***" >>>> set bundle password "***" >>>> set bundle no noretry >>>> set link keep-alive 10 60 >>>> set link max-redial 0 >>>> set link no acfcomp protocomp >>>> set link disable pap chap >>>> set link accept chap >>>> set link mtu 1492 >>>> set ipcp yes vjcomp >>>> set ipcp ranges 0.0.0.0/0.0.0.0/0 >>>> set ipcp enable req-pri-dns >>>> set ipcp enable req-sec-dns >>>> open >>>> adsl1: >>>> new -i ng1 pppoe1 pppoe1 >>>> set iface route default >>>> set iface disable on-demand >>>> set iface idle 0 >>>> set bundle disable multilink >>>> set bundle authname "***" >>>> set bundle password "***" >>>> set bundle no noretry >>>> set link keep-alive 10 60 >>>> set link max-redial 0 >>>> set link no acfcomp protocomp >>>> set link disable pap chap >>>> set link accept chap >>>> set link mtu 1492 >>>> set ipcp yes vjcomp >>>> set ipcp ranges 0.0.0.0/0.0.0.0/0 >>>> set ipcp enable req-pri-dns >>>> set ipcp enable req-sec-dns >>>> open >>>> adsl2: >>>> new -i ng2 pppoe2 pppoe2 >>>> set iface route default >>>> set iface disable on-demand >>>> set iface idle 0 >>>> set bundle disable multilink >>>> set bundle authname "***" >>>> set bundle password "***" >>>> set bundle no noretry >>>> set link keep-alive 10 60 >>>> set link max-redial 0 >>>> set link no acfcomp protocomp >>>> set link disable pap chap >>>> set link accept chap >>>> set link mtu 1492 >>>> set ipcp yes vjcomp >>>> set ipcp ranges 0.0.0.0/0.0.0.0/0 >>>> set ipcp enable req-pri-dns >>>> set ipcp enable req-sec-dns >>>> open > As a side issue, to improve readability, might I suggest > something like: >=20 > adsl0: > new -i ng0 pppoe0 pppoe0 > set bundle authname "***" > set bundle password "***" > load adsldflt >=20 > adsl1: > new -i ng1 pppoe1 pppoe1 > set bundle authname "***" > set bundle password "***" > load adsldflt >=20 > adsl2: > new -i ng2 pppoe2 pppoe2 > set bundle authname "***" > set bundle password "***" > load adsldflt >=20 > adsldflt: > set iface route default > set iface disable on-demand > set iface idle 0 > set bundle disable multilink > set bundle no noretry > set link keep-alive 10 60 > set link max-redial 0 > set link no acfcomp protocomp > set link disable pap chap > set link accept chap > set link mtu 1492 > set ipcp yes vjcomp > set ipcp ranges 0.0.0.0/0.0.0.0/0 > set ipcp enable req-pri-dns > set ipcp enable req-sec-dns > open >=20 >=20 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 10:49:54 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D0E1065670 for ; Tue, 1 Dec 2009 10:49:54 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id A7A5D8FC15 for ; Tue, 1 Dec 2009 10:49:53 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 4318A39824; Tue, 1 Dec 2009 12:49:51 +0200 (SAST) Date: Tue, 1 Dec 2009 12:49:51 +0200 From: John Hay To: freebsd-net@freebsd.org Message-ID: <20091201104951.GA42629@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: wlan adhoc mode crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 10:49:54 -0000 Hi, I'm not sure if this is the best list. I'm trying to get our Avila (arm) boards with atheros wireless cards upgraded from 7.2 to 8.0. We use adhoc mode and I get a panic in ieee80211_getcapinfo() because the chan pointer is 0xffff which seems to mean IEEE80211_CHAN_ANY in other places. So the question is, should ieee80211_getcapinfo() never be called with chan being 0xffff or should it know how to handle that case? John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org Additional routing options: IP gateway=YES. add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 -> 1 net.inet6.ip6.accept_rtadv: 0 -> 0 npe1: ixpnpe_intr: status 0x60000 npe1: link state changed to DOWN Fatal kernel mode data abort: 'Alignment Fault 3' trapframe: 0xc5df7cb0 FSR=00000013, FAR=0000ffff, spsr=00000013 r0 =00000002, r1 =0000ffff, r2 =c0bd9000, r3 =000c2408 r4 =c104a96e, r5 =c104a964, r6 =c101e000, r7 =c1026000 r8 =c101e884, r9 =c102bb00, r10=c0bd9000, r11=c5df7d08 r12=400c3008, ssp=c5df7cfc, slr=c03e20a0, pc =c03df248 [thread pid 0 tid 100020 ] Stopped at ieee80211_getcapinfo+0x70: ldr r1, [r1] db> tr Tracing pid 0 tid 100020 td 0xc0bcf250 db_trace_thread() at db_trace_thread+0xc scp=0xc04c45cc rlv=0xc021ad44 (db_command_init+0x4d8) rsp=0xc5df79a4 rfp=0xc5df79c4 r10=0x00000001 r9=0xc05d9f7c r8=0xc05d0f50 r7=0xc05d0724 r6=0x00000010 r5=0x00000000 r4=0xc0bcf250 db_command_init() at db_command_init+0x454 scp=0xc021acc0 rlv=0xc021a4e8 (db_skip_to_eol+0x390) rsp=0xc5df79c8 rfp=0xc5df7a6c r6=0x00000001 r5=0x00000000 r4=0xc0597c38 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc021a328 rlv=0xc021a704 (db_command_loop+0x50) rsp=0xc5df7a70 rfp=0xc5df7a80 r10=0x00000000 r8=0x00000013 r7=0xc5df7cb0 r6=0xc05d9f78 r5=0x000000c0 r4=0xc05d0720 db_command_loop() at db_command_loop+0xc scp=0xc021a6c0 rlv=0xc021c950 (X_db_sym_numargs+0xa0) rsp=0xc5df7a84 rfp=0xc5df7ba0 r4=0xc5df7a88 X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc021c8c4 rlv=0xc0336c54 (kdb_trap+0xb0) rsp=0xc5df7ba4 rfp=0xc5df7bcc r4=0x000000c0 kdb_trap() at kdb_trap+0xc scp=0xc0336bb0 rlv=0xc04d3c58 (badaddr_read+0x214) rsp=0xc5df7bd0 rfp=0xc5df7bec r10=0xc5df7cb0 r9=0xc5df7ef8 r8=0xc101e884 r7=0xc0bcf250 r6=0x0000ffff r5=0x00000013 r4=0xc5df7cb0 badaddr_read() at badaddr_read+0xe8 scp=0xc04d3b2c rlv=0xc04d413c (prefetch_abort_handler+0x444) rsp=0xc5df7bf0 rfp=0xc5df7c08 r6=0xc101e000 r5=0xc5df7cb0 r4=0xc0bcf250 prefetch_abort_handler() at prefetch_abort_handler+0x3c8 scp=0xc04d40c0 rlv=0xc04d4564 (data_abort_handler+0x424) rsp=0xc5df7c0c rfp=0xc5df7cac r5=0xffff1004 r4=0x00000003 data_abort_handler() at data_abort_handler+0xc scp=0xc04d414c rlv=0xc04c605c (address_exception_entry+0x50) rsp=0xc5df7cb0 rfp=0xc5df7d08 r10=0xc0bd9000 r9=0xc102bb00 r8=0xc101e884 r7=0xc1026000 r6=0xc101e000 r5=0xffff1004 r4=0xc104a96e ieee80211_getcapinfo() at ieee80211_getcapinfo+0xc scp=0xc03df1e4 rlv=0xc03e20a0 (ieee80211_send_probereq+0x544) rsp=0xc5df7d0c rfp=0xc5df7d38 ieee80211_send_probereq() at ieee80211_send_probereq+0x4e4 scp=0xc03e2040 rlv=0xc03e2bbc (ieee80211_beacon_alloc+0xa0) rsp=0xc5df7d3c rfp=0xc5df7d68 r10=0xc0c49c00 r9=0xc101e000 r8=0xc1026000 r7=0xc101e000 r6=0x0000069b r5=0xc101e884 r4=0xc102bb00 ieee80211_beacon_alloc() at ieee80211_beacon_alloc+0xc scp=0xc03e2b28 rlv=0xc024862c (ath_attach+0x1ec4) rsp=0xc5df7d6c rfp=0xc5df7e0c r10=0xc0bd7000 r8=0xc0bdb000 r7=0x00000005 r6=0x00000001 r5=0xc0bd72d4 r4=0xc101e000 ath_attach() at ath_attach+0x1d20 scp=0xc0248488 rlv=0xc03e72f0 (ieee80211_proto_vattach+0x1f8) rsp=0xc5df7e10 rfp=0xc5df7e40 r10=0xc0bd9000 r9=0xc0bd9014 r8=0xffffffff r7=0x00000000 r6=0x00000005 r5=0xc101e000 r4=0xc101e2d4 ieee80211_proto_vattach() at ieee80211_proto_vattach+0x150 scp=0xc03e7248 rlv=0xc0341e48 (taskqueue_run+0x7c) rsp=0xc5df7e44 rfp=0xc5df7e64 r10=0xc0bd9074 r9=0x00000000 r8=0x00000001 r7=0xc0bb9b98 r6=0x00000004 r5=0xc0bb9b80 r4=0xc101e2d4 taskqueue_run() at taskqueue_run+0xc scp=0xc0341dd8 rlv=0xc0341fc8 (taskqueue_thread_loop+0x4c) rsp=0xc5df7e68 rfp=0xc5df7e80 r8=0xc5df7eac r7=0xc05d38f8 r6=0xc0341f7c r5=0xc0bb9b98 r4=0xc0bb9b80 taskqueue_thread_loop() at taskqueue_thread_loop+0xc scp=0xc0341f88 rlv=0xc02e8a0c (fork_exit+0x7c) rsp=0xc5df7e84 rfp=0xc5df7ea8 r5=0xc05f1880 r4=0xc0bcf250 fork_exit() at fork_exit+0xc scp=0xc02e899c rlv=0xc04d3910 (fork_trampoline+0x14) rsp=0xc5df7eac rfp=0x00000000 r10=0x00000000 r8=0x00000000 r7=0x00000000 r6=0x00000000 r5=0xc0bd9074 r4=0xc0341f7c db> From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 13:00:10 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8274106566B for ; Tue, 1 Dec 2009 13:00:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2738FC0A for ; Tue, 1 Dec 2009 13:00:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB1D0Ai1024224 for ; Tue, 1 Dec 2009 13:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB1D0Adp024223; Tue, 1 Dec 2009 13:00:10 GMT (envelope-from gnats) Date: Tue, 1 Dec 2009 13:00:10 GMT Message-Id: <200912011300.nB1D0Adp024223@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: ocean Cc: Subject: Re: kern/123559: [iwi] iwi periodically disassociates/associates [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ocean List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 13:00:10 -0000 The following reply was made to PR kern/123559; it has been noted by GNATS. From: ocean To: bug-followup@FreeBSD.org, uyamba@gmail.com Cc: Subject: Re: kern/123559: [iwi] iwi periodically disassociates/associates [regression] Date: Tue, 01 Dec 2009 13:53:57 +0100 it's not a fix, but you could try this temporary workaround and see if it gets better. change the interface bmiss parameter: ifconfig iwi0 bmiss 50 (bmiss/bmissthreshold can be a value between 1 and 255) (or ifconfig wlan0 bmiss 50 on 8.0) regards ocean From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 14:50:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 981111065679 for ; Tue, 1 Dec 2009 14:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF068FC12 for ; Tue, 1 Dec 2009 14:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB1Eo2mZ019505 for ; Tue, 1 Dec 2009 14:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB1Eo2cm019504; Tue, 1 Dec 2009 14:50:02 GMT (envelope-from gnats) Date: Tue, 1 Dec 2009 14:50:02 GMT Message-Id: <200912011450.nB1Eo2cm019504@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Miroslav Lachman <000.fbsd@quip.cz> Cc: Subject: Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Miroslav Lachman <000.fbsd@quip.cz> List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 14:50:03 -0000 The following reply was made to PR kern/140684; it has been noted by GNATS. From: Miroslav Lachman <000.fbsd@quip.cz> To: bug-followup@FreeBSD.org, mksmith@adhost.com Cc: Subject: Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot Date: Tue, 01 Dec 2009 15:46:13 +0100 I think it is related to kern/134788 http://www.freebsd.org/cgi/query-pr.cgi?pr=134788 And is already fixed in 7-STABLE http://lists.freebsd.org/pipermail/freebsd-net/2009-November/023706.html http://lists.freebsd.org/pipermail/freebsd-net/2009-November/023815.html From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 15:40:58 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 592951065697 for ; Tue, 1 Dec 2009 15:40:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id E50A38FC0A for ; Tue, 1 Dec 2009 15:40:57 +0000 (UTC) Received: by ewy1 with SMTP id 1so5209455ewy.14 for ; Tue, 01 Dec 2009 07:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=y1lD9AJQjUCZ56t+l296JohHM01EktDw2jbBSxyn/rA=; b=EOlWReJauPy1ODw8cWddJyeTAsZwLsR+i80zIZVW3aKE2rd8LTQ2K4QTOLIXoLgILF 1VZOJzr7wYNe70FJe05FF3ixZGR736UGHCldniQBM1hc3SqLozcXeZ8+vngk4JFXJSmD Hkepc83fXnC6MmBadACPEGluv0sgXy7kyMXj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R+tRsjcHb2L33X7hg0RftThM6lMUs8VEs1MFRg04ESTSuIyVlCgesCbWNOBJF8XVHH X3HKZelAes83kSrZ+Wv9fjScHGFnqkCAfP/vGod5gwMI+RxbN2ZH26xAHPJr/7jrwq4w boESmLOls8iKQ7IK59ric6gPMv7GEx24qvhpA= MIME-Version: 1.0 Received: by 10.213.43.195 with SMTP id x3mr981420ebe.19.1259682056167; Tue, 01 Dec 2009 07:40:56 -0800 (PST) In-Reply-To: <20091201104951.GA42629@zibbi.meraka.csir.co.za> References: <20091201104951.GA42629@zibbi.meraka.csir.co.za> Date: Tue, 1 Dec 2009 16:40:56 +0100 Message-ID: <3a142e750912010740wc69464btbdeea834b0d4e516@mail.gmail.com> From: Paul B Mahol To: John Hay Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: wlan adhoc mode crash X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 15:40:58 -0000 On 12/1/09, John Hay wrote: > Hi, > > I'm not sure if this is the best list. > > I'm trying to get our Avila (arm) boards with atheros wireless cards > upgraded from 7.2 to 8.0. We use adhoc mode and I get a panic in > ieee80211_getcapinfo() because the chan pointer is 0xffff which seems > to mean IEEE80211_CHAN_ANY in other places. So the question is, should > ieee80211_getcapinfo() never be called with chan being 0xffff or should > it know how to handle that case? IEEE80211_CHAN_ANY is there to mean no channel is selected, so you can not call getcapinfo with such argument. From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 17:31:38 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58C0B1065692 for ; Tue, 1 Dec 2009 17:31:38 +0000 (UTC) (envelope-from rganascim@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 18E138FC16 for ; Tue, 1 Dec 2009 17:31:37 +0000 (UTC) Received: by yxe1 with SMTP id 1so2918182yxe.3 for ; Tue, 01 Dec 2009 09:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=VrFOZe5wM/PVBX/nAHTyPWqCR6oDiTdhTNt/K/5BxTE=; b=sowSQhkSiCc6i3OwNWh92MHj0KZCwNxysVRhHogZSEcTFnTetQjbRdIqLY/q38TQFR WiEfADAU+gNDk/2X3jzHnSvPYRvkIIyK6RNMuG1HpoW8LE/hxtkT9D+GtTW+nyX1PaLq pzZdY11PpjoQZ79alZeZOnqFvGDj5xeZ9QgFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UGECaRD60yEYq69CzwA/wuqkQA4/y6s7goEaQmxRYr1x8QYLZtmizYptqqJhwXx5Y6 zB7oj0TB3AycBP0pwbTr9+R2HYaOEQgAgv6sWxZDPFMMryykjcLXeKBJ+OnHCVZ7eyxQ +OvkVWqL4Skr8CMstBsemFzCb99qyKCiFEoXA= MIME-Version: 1.0 Received: by 10.91.49.13 with SMTP id b13mr8470876agk.34.1259688697243; Tue, 01 Dec 2009 09:31:37 -0800 (PST) Date: Tue, 1 Dec 2009 15:31:37 -0200 Message-ID: <2f7feda40912010931i3cf7d90dmb2a8d08ecd40589f@mail.gmail.com> From: Rafael Ganascim To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bge driver and MSI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:31:38 -0000 Hi list, Can the bge driver use more than one MSI message? If possible, what the advantage of this on a SMP system (better CPU distribution on interrupts?)? I have an Broadcom BCM5703X, with 8 MSI messages: -- bge0@pci0:1:2:0: class=0x020000 card=0x00cb0e11 chip=0x16a714e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5703X NetXtreme Gigabit Ethernet' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit -- Thanks. -- Rafael From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 18:37:36 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10D81065672 for ; Tue, 1 Dec 2009 18:37:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f188.google.com (mail-vw0-f188.google.com [209.85.212.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4C08FC20 for ; Tue, 1 Dec 2009 18:37:35 +0000 (UTC) Received: by vws26 with SMTP id 26so1646033vws.7 for ; Tue, 01 Dec 2009 10:37:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=HDAIhd/NydExRBFbJhR/K+VkR2pXkf33d9pBwDYAbXA=; b=QnLwd6kGWAlyLHjjGqg62haA0uXUsdm9u9yYxvvLwPLUaVDMfK+lGmeZqvikm+ArVn KxUJLhP180s+CjNLOWDRZnYjMCcNBL4xVleLyt8gG+npri2sX1tuKVmSzCjB1ZWQVuO9 FBFBGZD/x7W3/XTAM7p4DJXq/XFCpBxssB0Pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=CAB6vrdayIhGCExV7nRwoKgVk7YHQkfXrg3RV2+SZkfJZ103JDQ3FRJfJVJ0X606wT M6VgKyDLw/f9sxYKfM2kQdI8msNxPiHelq10MHbrH31JE4BkjP0aiLOI+qCO0heYT96g FCLbU6LqVLHr9SMjqQQILxvdpLE+dLinT7yE8= Received: by 10.220.122.35 with SMTP id j35mr7429312vcr.46.1259692655331; Tue, 01 Dec 2009 10:37:35 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm637904vws.9.2009.12.01.10.37.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 10:37:34 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 1 Dec 2009 10:36:23 -0800 From: Pyun YongHyeon Date: Tue, 1 Dec 2009 10:36:23 -0800 To: Rafael Ganascim Message-ID: <20091201183623.GK1172@michelle.cdnetworks.com> References: <2f7feda40912010931i3cf7d90dmb2a8d08ecd40589f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f7feda40912010931i3cf7d90dmb2a8d08ecd40589f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge driver and MSI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:37:36 -0000 On Tue, Dec 01, 2009 at 03:31:37PM -0200, Rafael Ganascim wrote: > Hi list, > > Can the bge driver use more than one MSI message? If possible, what the > advantage of this on a SMP system (better CPU distribution on interrupts?)? > > I have an Broadcom BCM5703X, with 8 MSI messages: > -- > bge0@pci0:1:2:0: class=0x020000 card=0x00cb0e11 chip=0x16a714e4 rev=0x02 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5703X NetXtreme Gigabit Ethernet' > class = network > subclass = ethernet > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split > transaction > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 8 messages, 64 bit I think supporting more than one MSI message does not have benefit. If controller support multiple MSIX message with RSS it could be configured to distribute interrupts among CPUs. But I think FreeBSD still lacks a capability to dynamically redistribute loads while RSS is active. Controller also should support multi-Tx/Rx queues to take advantage of it. BCM5717 seems to support MSIX with RSS but bge(4) has no support for the controller at the moment. I think supporting multi-Tx/Rx queue requires major driver overhauling which would take a lot of time and experiments. bge(4) in HEAD takes full advantage of MSI. Special interrupt handler optimized for MSI is used for MSI capable controllers and this seems to work well. I don't have BCM5703X so I didn't enable that feature on PCIX controller though. > -- > > Thanks. > > -- > Rafael From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 19:52:56 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F801065693 for ; Tue, 1 Dec 2009 19:52:56 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8BED98FC1E for ; Tue, 1 Dec 2009 19:52:55 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id MAA12927 for ; Tue, 1 Dec 2009 12:52:52 -0700 (MST) Message-Id: <200912011952.MAA12927@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Dec 2009 12:50:33 -0700 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:52:56 -0000 All: I have several large PPTP servers which are currently using ppp(8) and PoPTop (a userland PPTP server daemon which is, unfortunately, GPLed). They're having trouble under heavy loads, and so I'd like to switch to mpd5. However, even though mpd5 handles network connections in the kernel, via netgraph, I am worried about performance. As far as I can see, all netgraph operations are performed by a single kernel thread named "ng_queue", while ppp(8) and PoPToP use many processes and thus can distribute their work among multiple CPU cores. Is netgraph able to multithread, or is there a way to make it do so? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 20:47:27 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9011065676 for ; Tue, 1 Dec 2009 20:47:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 388848FC1B for ; Tue, 1 Dec 2009 20:47:27 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B4EB9961CA; Tue, 1 Dec 2009 12:47:26 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 77FB32D6011; Tue, 1 Dec 2009 12:47:26 -0800 (PST) Message-ID: <4B1580E2.4080006@elischer.org> Date: Tue, 01 Dec 2009 12:47:30 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brett Glass References: <200912011952.MAA12927@lariat.net> In-Reply-To: <200912011952.MAA12927@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:47:27 -0000 Brett Glass wrote: > All: > > I have several large PPTP servers which are currently using ppp(8) and > PoPTop (a userland PPTP server daemon which is, unfortunately, GPLed). > They're having trouble under heavy loads, and so I'd like to switch to > mpd5. However, even though mpd5 handles network connections in the > kernel, via netgraph, I am worried about performance. > > As far as I can see, all netgraph operations are performed by a single > kernel thread named "ng_queue", while ppp(8) and PoPToP use many > processes and thus can distribute their work among multiple CPU cores. > > Is netgraph able to multithread, or is there a way to make it do so? well, not all work is done by that thread. It is the backup-doer-of-things, but many netgraph operations are done in the context of a caller such as teh user of a socket. netgraph is more efficient than the user layer however because it doesn't have to cross the kernel boundary to process the work. why not just try it? > > --Brett Glass > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 20:54:26 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35E22106566C for ; Tue, 1 Dec 2009 20:54:26 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 04A088FC1D for ; Tue, 1 Dec 2009 20:54:25 +0000 (UTC) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 01 Dec 2009 12:54:14 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 1 Dec 2009 12:55:36 -0800 From: "David Christensen" To: "Tom Judge" Date: Tue, 1 Dec 2009 12:54:13 -0800 Thread-Topic: bce(4) BCM5907 CTX write errors on 7.2 driver Thread-Index: Acptans6jvua+f7FQu+Nr4kOaHH2ZgFXbvHw Message-ID: <5D267A3F22FD854F8F48B3D2B52381933A31581B0D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4AE72910.8090708@tomjudge.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> <4B0C80FB.5040901@tomjudge.com> In-Reply-To: <4B0C80FB.5040901@tomjudge.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 670B5DFC3C821697310-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Gideon Naim , "rwilliams@borderware.com" , Miroslav Lachman <000.fbsd@quip.cz>, "net@freebsd.org" Subject: RE: bce(4) BCM5907 CTX write errors on 7.2 driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 20:54:26 -0000 > > Does the attached patch make a difference for you? > > This patch seems to do the trick, on at least one of the=20 > R610's that we have. >=20 > Just did cold boot, 5 warm boots, cold boot, 5 warm boots and=20 > have not had any issues. > Thanks for testing. I want to pass the changes by a couple other people before I go ahead with a commit. Dave=20 From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 22:57:28 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 153F01065670; Tue, 1 Dec 2009 22:57:28 +0000 (UTC) (envelope-from misho@aitbg.com) Received: from mail.aitbg.com (fire.aitbg.com [95.158.168.150]) by mx1.freebsd.org (Postfix) with ESMTP id 83A478FC12; Tue, 1 Dec 2009 22:57:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.aitbg.com (Postfix) with ESMTP id BCE2B19733; Wed, 2 Dec 2009 00:40:35 +0200 (EET) X-Virus-Scanned: amavisd-new at aitbg.com Received: from mail.aitbg.com ([127.0.0.1]) by localhost (mail.aitbg.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwgNVJKcHK-M; Wed, 2 Dec 2009 00:40:30 +0200 (EET) Received: from smurf.insecurebg.org (unknown [77.70.127.109]) by mail.aitbg.com (Postfix) with ESMTPSA id 8B3DC196D6; Wed, 2 Dec 2009 00:40:30 +0200 (EET) Date: Wed, 2 Dec 2009 00:39:31 +0200 From: Michael Pounov To: freebsd-net@freebsd.org Message-Id: <20091202003931.255e3aed.misho@aitbg.com> Organization: AITNET ltd X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__2_Dec_2009_00_39_31_+0200_9Rt3U3Pd9AOft84e" Cc: emaste@freebsd.org Subject: [patch] for missing TACACS+ accounting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 22:57:28 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__2_Dec_2009_00_39_31_+0200_9Rt3U3Pd9AOft84e Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all, I am sending a patch that adds support for TACACS+ accounting to libtacplus(3). Comments welcome. -- M.Punov --------------------- AITNET - Sofia/Bulgaria - Software & Network Solutions (+359) 888 73 73 58;(+359) 2 402 4000 --Multipart=_Wed__2_Dec_2009_00_39_31_+0200_9Rt3U3Pd9AOft84e Content-Type: text/x-diff; name="libtacplus-20091201-01.patch" Content-Disposition: attachment; filename="libtacplus-20091201-01.patch" Content-Transfer-Encoding: 7bit Index: libtacplus.3 =================================================================== RCS file: /home/ncvs/src/lib/libtacplus/libtacplus.3,v retrieving revision 1.14 diff -u -r1.14 libtacplus.3 --- libtacplus.3 28 Oct 2006 10:53:39 -0000 1.14 +++ libtacplus.3 1 Dec 2009 22:26:11 -0000 @@ -44,6 +44,8 @@ .Fn tac_create_authen "struct tac_handle *h" "int action" "int type" "int service" .Ft int .Fn tac_create_author "struct tac_handle *h" "int method" "int type" "int service" +.Ft int +.Fn tac_create_acct "struct tac_handle *h" "int acct" "int action" "int type" "int service" .Ft char * .Fn tac_get_av "struct tac_handle *h" "u_int index" .Ft char * @@ -59,6 +61,8 @@ .Ft int .Fn tac_send_author "struct tac_handle *h" .Ft int +.Fn tac_send_acct "struct tac_handle *h" +.Ft int .Fn tac_set_av "struct tac_handle *h" "u_int index" "const char *av_pair" .Ft int .Fn tac_set_data "struct tac_handle *h" "const void *data" "size_t data_len" @@ -193,6 +197,20 @@ The .In taclib.h header file contains symbolic constants for these values. +.Sh CREATING A TACACS+ ACCOUNTING REQUEST +To begin constructing a new accounting request, call +.Fn tac_create_acct . +The +.Va acct , +.Va action , +.Va type , +and +.Va service +arguments must be set to appropriate values as defined in the +TACACS+ protocol specification. +The +.In taclib.h +header file contains symbolic constants for these values. .Sh SETTING OPTIONAL PARAMETERS ON A REQUEST After creating a request, various optional parameters may be attached to it through calls to @@ -354,6 +372,29 @@ .Pp The number of AV pairs received is obtained using .Fn TAC_AUTHEN_AV_COUNT . +.Sh SENDING THE ACCOUNTING REQUEST AND RECEIVING THE RESPONSE +After the TACACS+ authorization request has been constructed, it +is sent by means of +.Fn tac_send_acct . +This function connects to a server if not already connected, sends +the request, and waits for a reply. +On failure, +.Fn tac_send_acct +returns \-1. +Otherwise, it returns the TACACS+ status code +Possible status codes, defined in +.In taclib.h , +include: +.Pp +.Bl -item -compact -offset indent +.It +.Dv TAC_ACCT_STATUS_SUCCESS +.It +.Dv TAC_ACCT_STATUS_ERROR +.It +.Dv TAC_ACCT_STATUS_FOLLOW +.El +.Pp .Sh EXTRACTING INFORMATION FROM THE SERVER'S AUTHORIZATION RESPONSE Like an authentication response packet, an authorization response packet from the @@ -418,10 +459,14 @@ .It .Fn tac_create_author .It +.Fn tac_create_acct +.It .Fn tac_send_authen .It .Fn tac_send_author .It +.Fn tac_send_acct +.It .Fn tac_set_av .It .Fn tac_set_data Index: taclib.c =================================================================== RCS file: /home/ncvs/src/lib/libtacplus/taclib.c,v retrieving revision 1.7 diff -u -r1.7 taclib.c --- taclib.c 25 Nov 2009 14:59:28 -0000 1.7 +++ taclib.c 1 Dec 2009 20:58:35 -0000 @@ -211,6 +211,8 @@ } break; + case TAC_ACCT: + default: minor = 0; break; @@ -967,6 +969,23 @@ return 0; } +int +tac_create_acct(struct tac_handle *h, int acct, int action, int type, int service) +{ + struct tac_acct_start *as; + + create_msg(h, TAC_ACCT, action, type); + + as = &h->request.u.acct_start; + as->action = acct; + as->authen_action = action; + as->priv_lvl = TAC_PRIV_LVL_USER; + as->authen_type = type; + as->authen_service = service; + + return 0; +} + static void create_msg(struct tac_handle *h, int msg_type, int var, int type) { @@ -1158,6 +1177,49 @@ } int +tac_send_acct(struct tac_handle *h) +{ + register int i, current; + struct tac_acct_start *as = &h->request.u.acct_start; + struct tac_acct_reply *ar = &h->response.u.acct_reply; + + /* start */ + as = &h->request.u.acct_start; + h->request.length = htonl(offsetof(struct tac_acct_start, rest[0])); + for (as->av_cnt = 0, i = 0; i < MAXAVPAIRS; i++) + if (h->avs[i].len && h->avs[i].data) + as->av_cnt++; + h->request.length = ntohl(htonl(h->request.length) + as->av_cnt); + + if (add_str_8(h, &as->user_len, &h->user) == -1 || + add_str_8(h, &as->port_len, &h->port) == -1 || + add_str_8(h, &as->rem_addr_len, &h->rem_addr) == -1) + return -1; + + for (i = current = 0; i < MAXAVPAIRS; i++) + if (h->avs[i].len && h->avs[i].data) + if (add_str_8(h, &as->rest[current++], &(h->avs[i])) == -1) + return -1; + + /* send */ + if (send_msg(h) == -1 || recv_msg(h) == -1) + return -1; + + /* reply */ + h->srvr_pos = offsetof(struct tac_acct_reply, rest[0]); + if (get_srvr_str(h, "msg", &h->srvr_msg, ntohs(ar->msg_len)) == -1 || + get_srvr_str(h, "data", &h->srvr_data, ntohs(ar->data_len)) == -1 || + get_srvr_end(h) == -1) + return -1; + + /* Sanity checks */ + if (!h->single_connect) + close_connection(h); + + return ar->status; +} + +int tac_set_rem_addr(struct tac_handle *h, const char *addr) { return save_str(h, &h->rem_addr, addr, addr != NULL ? strlen(addr) : 0); Index: taclib.h =================================================================== RCS file: /home/ncvs/src/lib/libtacplus/taclib.h,v retrieving revision 1.2 diff -u -r1.2 taclib.h --- taclib.h 25 Sep 2002 23:18:51 -0000 1.2 +++ taclib.h 1 Dec 2009 20:29:18 -0000 @@ -103,6 +103,17 @@ #define TAC_AUTHOR_STATUS_FAIL 0x10 #define TAC_AUTHOR_STATUS_ERROR 0x11 +/* Accounting actions */ +#define TAC_ACCT_MORE 0x1 +#define TAC_ACCT_START 0x2 +#define TAC_ACCT_STOP 0x4 +#define TAC_ACCT_WATCHDOG 0x8 + +/* Accounting status */ +#define TAC_ACCT_STATUS_SUCCESS 0x1 +#define TAC_ACCT_STATUS_ERROR 0x2 +#define TAC_ACCT_STATUS_FOLLOW 0x21 + __BEGIN_DECLS int tac_add_server(struct tac_handle *, const char *, int, const char *, int, int); @@ -127,6 +138,8 @@ char *tac_get_av(struct tac_handle *, u_int); char *tac_get_av_value(struct tac_handle *, const char *); void tac_clear_avs(struct tac_handle *); +int tac_create_acct(struct tac_handle *, int, int, int, int); +int tac_send_acct(struct tac_handle *); __END_DECLS #endif /* _TACLIB_H_ */ Index: taclib_private.h =================================================================== RCS file: /home/ncvs/src/lib/libtacplus/taclib_private.h,v retrieving revision 1.2 diff -u -r1.2 taclib_private.h --- taclib_private.h 25 Sep 2002 23:18:51 -0000 1.2 +++ taclib_private.h 1 Dec 2009 20:41:15 -0000 @@ -132,6 +132,26 @@ unsigned char rest[1]; }; +struct tac_acct_start { + u_int8_t action; + u_int8_t authen_action; + u_int8_t priv_lvl; + u_int8_t authen_type; + u_int8_t authen_service; + u_int8_t user_len; + u_int8_t port_len; + u_int8_t rem_addr_len; + u_int8_t av_cnt; + unsigned char rest[1]; +}; + +struct tac_acct_reply { + u_int16_t msg_len; + u_int16_t data_len; + u_int8_t status; + unsigned char rest[1]; +}; + struct tac_msg { u_int8_t version; u_int8_t type; @@ -145,6 +165,8 @@ struct tac_authen_cont authen_cont; struct tac_author_request author_request; struct tac_author_response author_response; + struct tac_acct_start acct_start; + struct tac_acct_reply acct_reply; unsigned char body[BODYSIZE]; } u; }; --Multipart=_Wed__2_Dec_2009_00_39_31_+0200_9Rt3U3Pd9AOft84e-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 1 23:33:48 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 826581065692 for ; Tue, 1 Dec 2009 23:33:48 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1CFA18FC12 for ; Tue, 1 Dec 2009 23:33:47 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id QAA16055; Tue, 1 Dec 2009 16:33:42 -0700 (MST) Message-Id: <200912012333.QAA16055@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Dec 2009 16:33:25 -0700 To: Julian Elischer From: Brett Glass In-Reply-To: <4B1580E2.4080006@elischer.org> References: <200912011952.MAA12927@lariat.net> <4B1580E2.4080006@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 23:33:48 -0000 At 01:47 PM 12/1/2009, Julian Elischer wrote: >well, not all work is done by that thread. It is the >backup-doer-of-things, but many netgraph operations are done in the >context of a caller such as teh user of a socket. In the case of a PPTP session, the data (ignoring the control session for the moment) flows from the interface (as GRE packets) through PPP (also implemented in netgraph) to an "ng" pseudo-interface, where it enters the ordinary FreeBSD IP stack. There isn't a user process listening on a socket anywhere in that path, so I assume that the netgraph kernel thread has to handle all of the work of encryption, decryption, handshaking, etc. Am I incorrect about this? I am concerned that the performance of a single core will be the bottleneck. --Brett Glass P.S. -- By the way, when I compiled netgraph into the kernel to begin my test, I began to get the message WARNING: attempt to domain_add(netgraph) after domainfinalize() each time the system boots. Why? Does it have anything to do with the fact that I compiled netgraph itself in, but did not compile in all of the modules I might be using? From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 00:01:37 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3719106566C for ; Wed, 2 Dec 2009 00:01:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id CC5778FC08 for ; Wed, 2 Dec 2009 00:01:37 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 70F4E39EC5; Tue, 1 Dec 2009 16:01:37 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 2286D2D6018; Tue, 1 Dec 2009 16:01:37 -0800 (PST) Message-ID: <4B15AE65.30604@elischer.org> Date: Tue, 01 Dec 2009 16:01:41 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brett Glass References: <200912011952.MAA12927@lariat.net> <4B1580E2.4080006@elischer.org> <200912012333.QAA16055@lariat.net> In-Reply-To: <200912012333.QAA16055@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:01:38 -0000 Brett Glass wrote: > At 01:47 PM 12/1/2009, Julian Elischer wrote: > >> well, not all work is done by that thread. It is the >> backup-doer-of-things, but many netgraph operations are done in the >> context of a caller such as teh user of a socket. > > In the case of a PPTP session, the data (ignoring the control session > for the moment) flows from the interface (as GRE packets) through PPP > (also implemented in netgraph) to an "ng" pseudo-interface, where it > enters the ordinary FreeBSD IP stack. There isn't a user process listening > on a socket anywhere in that path, so I assume that the netgraph > kernel thread has to handle all of the work of encryption, decryption, > handshaking, etc. Am I incorrect about this? I am concerned that the > performance of a single core will be the bottleneck. The work will be split between the sender of outgoing packets, the thread responding to the incoming packets from the interface and the netgraph threads. There was a patch to make more netgraph threads but I don't remember if it was checked in. > > --Brett Glass > > P.S. -- By the way, when I compiled netgraph into the kernel to begin my > test, I began to get the message > > WARNING: attempt to domain_add(netgraph) after domainfinalize() yes, it is known. we really cant domainfinalize() on a system where a protocol may be added later (like in a module). Luckily it doesn't matter in this case. "One day" someone will remove the printf. > > each time the system boots. Why? Does it have anything to do with the > fact that I compiled netgraph itself in, but did not compile in all of > the modules I might be using? From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 00:08:06 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C4A1065676 for ; Wed, 2 Dec 2009 00:08:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id E5DAA8FC20 for ; Wed, 2 Dec 2009 00:08:05 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 6EA8728BD3; Tue, 1 Dec 2009 16:08:05 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id C661C2D6018; Tue, 1 Dec 2009 16:08:04 -0800 (PST) Message-ID: <4B15AFE9.5070606@elischer.org> Date: Tue, 01 Dec 2009 16:08:09 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Brett Glass References: <200912011952.MAA12927@lariat.net> <4B1580E2.4080006@elischer.org> <200912012333.QAA16055@lariat.net> In-Reply-To: <200912012333.QAA16055@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:08:06 -0000 Brett Glass wrote: > At 01:47 PM 12/1/2009, Julian Elischer wrote: > >> well, not all work is done by that thread. It is the >> backup-doer-of-things, but many netgraph operations are done in the >> context of a caller such as teh user of a socket. > > In the case of a PPTP session, the data (ignoring the control session > for the moment) flows from the interface (as GRE packets) through PPP > (also implemented in netgraph) to an "ng" pseudo-interface, where it > enters the ordinary FreeBSD IP stack. There isn't a user process listening > on a socket anywhere in that path, so I assume that the netgraph > kernel thread has to handle all of the work of encryption, decryption, > handshaking, etc. Am I incorrect about this? I am concerned that the > performance of a single core will be the bottleneck. > in the netgraph code I see: /* Autoconfigure number of threads. */ if (numthreads <= 0) numthreads = mp_ncpus; and the default value of numthreads (it's a tunable) is 0 so you should have one netgraph thread per cpu. try top -HS From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 01:36:04 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08A51065670 for ; Wed, 2 Dec 2009 01:36:04 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5A38FC0A for ; Wed, 2 Dec 2009 01:36:04 +0000 (UTC) Received: from anne-o1dpaayth1.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id SAA17434; Tue, 1 Dec 2009 18:35:58 -0700 (MST) Message-Id: <200912020135.SAA17434@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Dec 2009 18:35:44 -0700 To: Julian Elischer From: Brett Glass In-Reply-To: <4B15AFE9.5070606@elischer.org> References: <200912011952.MAA12927@lariat.net> <4B1580E2.4080006@elischer.org> <200912012333.QAA16055@lariat.net> <4B15AFE9.5070606@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: Question regarding netgraph and threading X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:36:04 -0000 At 05:08 PM 12/1/2009, Julian Elischer wrote: >in the netgraph code I see: > > /* Autoconfigure number of threads. */ > if (numthreads <= 0) > numthreads = mp_ncpus; Ah.... Found this in /sys/netgraph/ng_base.c. Yes, it does seem to have a pool of worker threads. This is good. It means that if there's a single thread or single CPU bottleneck for a busy PPTP server, it would not be the netgraph traffic but rather the one process handling the TCP control connections for the PPTP sessions. I'll give it a try and see if this causes any problems. Still wondering about that boot time message, though. --Brett From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 14:33:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF256106566B for ; Wed, 2 Dec 2009 14:33:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 88FD58FC14 for ; Wed, 2 Dec 2009 14:33:59 +0000 (UTC) Received: (qmail 28365 invoked by uid 60001); 2 Dec 2009 14:33:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259764438; bh=SRnDvwBKzGDNDK2/V3bfMRHQh3GyBbek9z5Mp/9gWpA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0NldB2g4E/LBwVC9cC23Z+N+xmKunvNQATG7c6uURANdEdAohvA27Lnwcx+8xu/Ez9y1pCKcZ6Jf6nz6gSCQNYkTe9sUbCs+97iPwPHKXR/jg1yz73Ldhvvk8X0+ybxTkXQC9V9/vN3yfToIa1zHCPcmkQEgE70T0q1+m8ro+ic= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KiluLuUuyNsvbc4lT3iNtygmgwP3jIXhyK6J+aBSKzN+3IAhSl2i456vluKbXpVv/nFBuAQ5xG5O/y05K72LNTPrzNtJT8kDpnIOOXBHzUVTCCXDa0UPQptYVcS4gsHdOcBD0oa5tNO9OAcYx6AuIwAttCy1VPQ0PrBEZc5/BU8=; Message-ID: <913529.24196.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: fRJ2OlcVM1n7xLG9csELfEBwDBdT6NbM7NWhwr_ZCPOnGByLsEJTF7tgwvJpwhT1TIU1TSgs6BMi5M92T1zwk_UCPK5YXmafdVlPoGawiFZLD7XwhLMAk.qEW3ov1Lc2OYPhxko5lZQeR82Au2IrX62u8tBPzDXwzMTDgg0VtvxO.LMvslQPKuvYFmMcByp2TW78RPkaAPyF3f0zy6ROyXFD0dACyHT9aYe0PBrV1UY9PKzIGz5b6qY.8mbt2vavcBwpjf7FR2khzymhUCFNndpJeHJoRaQNb5Txvzk- Received: from [98.203.21.152] by web63906.mail.re1.yahoo.com via HTTP; Wed, 02 Dec 2009 06:33:58 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Wed, 2 Dec 2009 06:33:58 -0800 (PST) From: Barney Cordoba To: "Yuriy A. Korobko" In-Reply-To: <1258998140.3015.34.camel@stormi-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Reducing number of interrupts from intel pro 1000 et adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:33:59 -0000 =0A=0A--- On Mon, 11/23/09, Yuriy A. Korobko wro= te:=0A=0A> From: Yuriy A. Korobko =0A> Subject: R= educing number of interrupts from intel pro 1000 et adapter=0A> To: freebsd= -net@freebsd.org=0A> Date: Monday, November 23, 2009, 12:42 PM=0A> Hi,=0A> = =0A> I'd like to know a way to control tx interrupts on intel=0A> pro 1000 = et=0A> adapter with igb driver. Just installed one in the router=0A> and sy= stat=0A> shows 8-9k rx interrupts and 20k tx interrupts from igb0=0A> and i= gb1=0A> adapters. Box is a router running freebsd 7.2 release, I've=0A> tri= ed=0A> default driver from kernel source and latest from intel=0A> site, ef= fect is=0A> the same with automatic interrupt moderation enabled and=0A> di= sabled. I=0A> have the same box with intel pro 1000 pt adapter which=0A> ha= ve=0A> tx(rx)_int_delay sysctls in em driver, I was able to reduce=0A> numb= er of=0A> tx/rx interrupts to 7-8k per interface and got much more=0A> cpu = idle=0A> because of less context switches with same pps.=0A> =0A> Interfaca= e load=0A> =0A> border# netstat -I igb0 -w 1=0A> =A0 =A0 =A0 =A0 =A0 =A0 in= put=A0=0A> =A0 =A0 =A0=A0=A0(igb0)=A0 =A0 =A0=0A> =A0 =A0=A0=A0output=0A> = =A0=A0=A0packets=A0 errs=A0 =A0 =A0=0A> bytes=A0 =A0 packets=A0 errs=A0 =A0= =A0=0A> bytes colls=0A> =A0 =A0=A0=A041438=A0=0A> =A0=A0=A00=A0=A0=A037923= 274=A0 =A0=0A> =A0 51173=A0=0A> =A0=A0=A00=A0=A0=A024539512=A0=0A> =A0=A0= =A00=0A> =A0 =A0=A0=A044827=A0=0A> =A0=A0=A00=A0=A0=A041626876=A0 =A0=0A> = =A0 53408=A0=0A> =A0=A0=A00=A0=A0=A024595412=A0=0A> =A0=A0=A00=0A> =A0 =A0= =A0=A043300=A0=0A> =A0=A0=A00=A0=A0=A039736056=A0 =A0=0A> =A0 53118=A0=0A> = =A0=A0=A00=A0=A0=A024574219=A0=0A> =A0=A0=A00=0A> =A0 =A0=A0=A043146=A0=0A>= =A0=A0=A00=A0=A0=A040399285=A0 =A0=0A> =A0 53455=A0=0A> =A0=A0=A00=A0=A0= =A024368290=A0=0A> =A0=A0=A00=0A> =A0 =A0=A0=A044827=A0=0A> =A0=A0=A00=A0= =A0=A042463307=A0 =A0=0A> =A0 53921=A0=0A> =A0=A0=A00=A0=A0=A023959752=A0= =0A> =A0=A0=A00=0A> =0A> Here is sysctls=0A> =0A> dev.igb.0.%desc: Intel(R)= PRO/1000 Network Connection=0A> version - 1.7.4=0A> dev.igb.0.%driver: igb= =0A> dev.igb.0.%location: slot=3D0 function=3D0=0A> dev.igb.0.%pnpinfo: ven= dor=3D0x8086 device=3D0x10c9=0A> subvendor=3D0x8086=0A> subdevice=3D0xa03c = class=3D0x020000=0A> dev.igb.0.%parent: pci1=0A> dev.igb.0.debug: -1=0A> de= v.igb.0.stats: -1=0A> dev.igb.0.flow_control: 0=0A> dev.igb.0.enable_aim: 1= =0A> dev.igb.0.low_latency: 1000=0A> dev.igb.0.ave_latency: 4000=0A> dev.ig= b.0.bulk_latency: 8000=0A> dev.igb.0.rx_processing_limit: 1000=0A> =0A> dev= .igb.1.%desc: Intel(R) PRO/1000 Network Connection=0A> version - 1.7.4=0A> = dev.igb.1.%driver: igb=0A> dev.igb.1.%location: slot=3D0 function=3D1=0A> d= ev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x10c9=0A> subvendor=3D0x8086= =0A> subdevice=3D0xa03c class=3D0x020000=0A> dev.igb.1.%parent: pci1=0A> de= v.igb.1.debug: -1=0A> dev.igb.1.stats: -1=0A> dev.igb.1.flow_control: 0=0A>= dev.igb.1.enable_aim: 1=0A> dev.igb.1.low_latency: 1000=0A> dev.igb.1.ave_= latency: 4000=0A> dev.igb.1.bulk_latency: 8000=0A> dev.igb.1.rx_processing_= limit: 1000=0A> =0A> And debug =0A> =0A> kernel: igb0: Adapter hardware ad= dress =3D 0xc796ec1c =0A> kernel: igb0: CTRL =3D 0x40c00241 RCTL =3D 0x480= 02 =0A> kernel: igb0: Packet buffer =3D Tx=3D0k Rx=3D0k =0A> kernel: igb0= : Flow control watermarks high =3D 63488 low =3D=0A> 61988=0A> kernel: igb= 0: Queue(0) tdh =3D 3023, tdt =3D 3025=0A> kernel: igb0: TX(0) no descript= ors avail event =3D 0=0A> kernel: igb0: TX(0) MSIX IRQ Handled =3D 3754097= 484=0A> kernel: igb0: TX(0) Packets sent =3D 4815628967=0A> kernel: igb0:= Queue(0) rdh =3D 3658, rdt =3D 3645=0A> kernel: igb0: RX(0) Packets recei= ved =3D 7611879022=0A> kernel: igb0: RX(0) Split Packets =3D 0=0A> kernel= : igb0: RX(0) Byte count =3D 7013625984942=0A> kernel: igb0: RX(0) MSIX IR= Q Handled =3D 3232986641=0A> kernel: igb0: RX(0) LRO Queued=3D 0=0A> kern= el: igb0: RX(0) LRO Flushed=3D 0=0A> kernel: igb0: LINK MSIX IRQ Handled = =3D 3=0A> kernel: igb0: Mbuf defrag failed =3D 0=0A> kernel: igb0: Std mb= uf header failed =3D 0=0A> kernel: igb0: Std mbuf packet failed =3D 0=0A> = kernel: igb0: Driver dropped packets =3D 0=0A> kernel: igb0: Driver tx dm= a failure in xmit =3D 0=0A> =0A> kernel: igb1: Adapter hardware address = =3D 0xc796dc1c =0A> kernel: igb1: CTRL =3D 0x40c00241 RCTL =3D 0x48002 =0A= > kernel: igb1: Packet buffer =3D Tx=3D0k Rx=3D0k =0A> kernel: igb1: Flow= control watermarks high =3D 63488 low =3D=0A> 61988=0A> kernel: igb1: Que= ue(0) tdh =3D 4093, tdt =3D 4093=0A> kernel: igb1: TX(0) no descriptors av= ail event =3D 0=0A> kernel: igb1: TX(0) MSIX IRQ Handled =3D 10882048108= =0A> kernel: igb1: TX(0) Packets sent =3D 31169311987=0A> kernel: igb1: Q= ueue(0) rdh =3D 2515, rdt =3D 2513=0A> kernel: igb1: RX(0) Packets receive= d =3D 30747961847=0A> kernel: igb1: RX(0) Split Packets =3D 0=0A> kernel:= igb1: RX(0) Byte count =3D 26511993282060=0A> kernel: igb1: RX(0) MSIX IR= Q Handled =3D 4834518320=0A> kernel: igb1: RX(0) LRO Queued=3D 0=0A> kern= el: igb1: RX(0) LRO Flushed=3D 0=0A> kernel: igb1: LINK MSIX IRQ Handled = =3D 5=0A> kernel: igb1: Mbuf defrag failed =3D 0=0A> kernel: igb1: Std mb= uf header failed =3D 0=0A> kernel: igb1: Std mbuf packet failed =3D 0=0A> = kernel: igb1: Driver dropped packets =3D 0=0A> kernel: igb1: Driver tx dm= a failure in xmit =3D 0=0A> =0A> =0A> =0A=0AI'm curious as to why you are d= oing a load test on a single core system=0Awith a part that is clearly desi= gned to be used on a multicore system?=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 15:08:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70C481065692; Wed, 2 Dec 2009 15:08:48 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 281ED8FC14; Wed, 2 Dec 2009 15:08:48 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nB2F8bkX078209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 00:08:41 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 03 Dec 2009 00:08:37 +0900 Message-ID: From: Hajimu UMEMOTO To: John Baldwin In-Reply-To: <200911301300.03324.jhb@freebsd.org> References: <200911231255.26279.jhb@freebsd.org> <200911301300.03324.jhb@freebsd.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 03 Dec 2009 00:08:41 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:08:48 -0000 Hi, >>>>> On Mon, 30 Nov 2009 13:00:03 -0500 >>>>> John Baldwin said: jhb> I think you can just remove the ipv6_firewall_* variables from jhb> /etc/defaults/rc.conf completely. Perhaps you can use 'set_rcvar_obsolete' jhb> in /etc/rc.firewall to emit a warning if ipv6_firewall_enable is defined? jhb> Or maybe just emit an explicit warning in /etc/rc.firewall in that case? jhb> Other than that I think this patch looks good. Thanks for fixing this! Thank you for the comment. I've changed to use 'set_rcvar_obsolete', and committed it. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 16:05:41 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD97106566B for ; Wed, 2 Dec 2009 16:05:41 +0000 (UTC) (envelope-from administrator@shtorm.com) Received: from ns.shtorm.com (ns.shtorm.com [195.62.14.3]) by mx1.freebsd.org (Postfix) with ESMTP id 55AD58FC0C for ; Wed, 2 Dec 2009 16:05:41 +0000 (UTC) Received: from [195.62.15.4] (unknown [195.62.15.4]) by ns.shtorm.com (Postfix) with ESMTP id 7DD4D2E4004; Wed, 2 Dec 2009 18:02:25 +0200 (EET) From: "Yuriy A. Korobko" To: Barney Cordoba In-Reply-To: <913529.24196.qm@web63906.mail.re1.yahoo.com> References: <913529.24196.qm@web63906.mail.re1.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 02 Dec 2009 18:05:42 +0200 Message-ID: <1259769942.6739.33.camel@stormi-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Reducing number of interrupts from intel pro 1000 et adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:05:41 -0000 > > > > I'd like to know a way to control tx interrupts on intel > > pro 1000 et > > adapter with igb driver. Just installed one in the router > > and systat > > shows 8-9k rx interrupts and 20k tx interrupts from igb0 > > and igb1 > > adapters. Box is a router running freebsd 7.2 release, I've > > tried > > default driver from kernel source and latest from intel > > site, effect is > > the same with automatic interrupt moderation enabled and > > disabled. I > > have the same box with intel pro 1000 pt adapter which > > have > > tx(rx)_int_delay sysctls in em driver, I was able to reduce > > number of > > tx/rx interrupts to 7-8k per interface and got much more > > cpu idle > > because of less context switches with same pps. > > > I'm curious as to why you are doing a load test on a single core system > with a part that is clearly designed to be used on a multicore system? > > Barney Box have core quad cpu: 87 processes: 7 running, 58 sleeping, 22 waiting CPU 0: 0.0% user, 0.0% nice, 3.1% system, 36.4% interrupt, 60.5% idle CPU 1: 0.0% user, 0.0% nice, 15.5% system, 41.1% interrupt, 43.4% idle CPU 2: 0.0% user, 0.0% nice, 11.6% system, 27.1% interrupt, 61.2% idle CPU 3: 0.0% user, 0.0% nice, 2.3% system, 41.5% interrupt, 56.2% idle Mem: 192M Active, 206M Inact, 246M Wired, 716K Cache, 112M Buf, 1356M Anyway, high interrupt rate fixed by border# cat /boot/loader.conf | grep igb if_igb_load="YES" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.num_queues=1 hw.igb.enable_aim=1 hw.igb.low_latency=1000 hw.igb.ave_latency=2000 hw.igb.bulk_latency=4000 hw.igb.rx_process_limit=200 hw.igb.fc_setting=0 hw.igb.lro=0 border# Have no idea why, but it seems like setting dev.igb. sysctls at runtime just ignored by the driver. Now I have 1000-1200 rx and around 2000 tx interrupts per second from interface with 100 kpps flow in each direction, main cpu eater on the router is dummynet right now, it will be awesome if one day we can have it multithreaded. I'm using latest igb driver from intel site, default driver from kernel may not have this issue. Thanks. From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 17:48:35 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE4D1065670 for ; Wed, 2 Dec 2009 17:48:35 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 7823D8FC18 for ; Wed, 2 Dec 2009 17:48:35 +0000 (UTC) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 18:48:33 +0100 Date: Wed, 2 Dec 2009 18:48:31 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: freebsd-net@freebsd.org Message-ID: <20091202184310.J78398@beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Dec 2009 17:48:33.0684 (UTC) FILETIME=[AAC54D40:01CA7377] Subject: generating routing message on LL address change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:48:36 -0000 Hi all, I would like to commit the following patch. It generates an RTM_IFINFO message when the link-layer address of an interface is changed. This should be no problem for routing daemons, because the same messages are also generated when other interface state changes. Are there any reasons not to do this? harti Index: /sys/net/if.c =================================================================== RCS file: /freebsd/cvsup/src/sys/net/if.c,v retrieving revision 1.370 diff -u -r1.370 if.c --- /sys/net/if.c 30 Nov 2009 21:25:57 -0000 1.370 +++ /sys/net/if.c 2 Dec 2009 17:33:56 -0000 @@ -3136,6 +3136,10 @@ } #endif } + + /* inform daemons */ + rt_ifmsg(ifp); + return (0); } From owner-freebsd-net@FreeBSD.ORG Wed Dec 2 23:54:00 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 339D8106566B for ; Wed, 2 Dec 2009 23:54:00 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id C06EF8FC0C for ; Wed, 2 Dec 2009 23:53:59 +0000 (UTC) Received: by bwz5 with SMTP id 5so687318bwz.3 for ; Wed, 02 Dec 2009 15:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=f4jRf3edD+vZBnjl+oVrnpUEdR8vzhkAf/cAnghCrkE=; b=r7RiMCtJq4vLz2G3W95QQK3NbRdVGK0R7+zwaV33rbRQlRMwc9G++lPvS+uf2ttIDB HXXVbHMdBgpNofJ841q0R1pmHXDlJD6lNIuO0TabgVMaBle2l/8AaHH9fVJzX5OHRHCs r+TWt8F7DAlE5td4wvpiM3IkbgH3zf9u5AgHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Mzv93lsDttHVbrANc+Knqcl53HxA5ikHcIVqr9WA4WtQKeshj1u/E6S/c38nctVd5Y WBCvwSoOLy1lfDtOW1KOyX6cAaIoTXUEWe1zCm8YG3Ac1zU8ruSD3USyaDG+iN51+xSQ I2jugR/rpROkWinCSSXSHPqkvOU0PK+Em8/54= MIME-Version: 1.0 Received: by 10.204.2.209 with SMTP id 17mr863333bkk.31.1259798038579; Wed, 02 Dec 2009 15:53:58 -0800 (PST) Date: Thu, 3 Dec 2009 01:53:58 +0200 Message-ID: <9e20d71e0912021553p104b4370nb34085257ba6119d@mail.gmail.com> From: Artis Caune To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: [patch] truncated fields in netstat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 23:54:00 -0000 Hi, I'm parsing 'netstat -Wnibd' and found that on some boxes interface names, networks and addresses are truncated. Not just IPV6 addresses/networks, but even ipv4. It's nice to see/graph separate statistics for each network/aliase attached to the interface. Here is a patch http://www.nic.lv/sofq/patch-netstat.txt which will: - add new flag '-H' to print fields in script friendly format (just like zfs -H) - add this flag to netstat man page - fix space at the end of collisions/drops fields - fix few style(9) entries -- Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 00:21:40 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 962EC1065696 for ; Thu, 3 Dec 2009 00:21:40 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 37D248FC22 for ; Thu, 3 Dec 2009 00:21:39 +0000 (UTC) Received: (qmail 47054 invoked by uid 60001); 3 Dec 2009 00:21:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259799698; bh=I9sTsREev3D8+LVzHxmw/lRFGuwx/eyJWpSp3vlAKCs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NTBj4+T2AX9cRNfCpM+BBh+7QeweZE3XWMgQ5ayXzgt3CxSqSuUQCttSnX/V++f4gmSJH5j9dzUV3UZbPkacKW3w4puy9QiTBUji1GOMgSJH+Bep2Bn2UyTBQaNeOu3f77YbjT4cEVj5G3fAhBt95xsfxOzpxSZHCUtgAja4ngE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KHnhAoR/upSejpF9nfl783M/wA6DlgDPwUJmtFi1s75THf4akZCW3i3z2rBaY1CJpHPsZBvHgnmo1P5zqrSlJ39peMihvLNUjLSU3vhk614BM8MqDbXhg7gDHHhnRCFo5kRhrEOW4g7C7yiE1A+J8z+WxV9HMmtmEDWjqa562/g=; Message-ID: <501706.46449.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: 96JUrEUVM1nH.R9Oh5gwF3AgYMn7.fB0RnVBiSdSvkxwv6kH0NOWpOiDbNI_7qv38PoOiOWy48es_4wPKZXkgQseVHYq7R.X_zJ6Tg5UCCIk82uWPdWfn_ae6J9K0NAb_IZYodFw1zDblygJGVpSEuWN.fn6QAOfFXqIOW.vqwvg4Ynroia_n6dHZR8S3glh6IZP7dINoiu3QOFSkVReK9iLwSwAcsbn3Wh_AeKxCjh8xonuJdcaRQ14xD5bfKRLGy7himymfgM2Ye1RNugtA9fEuXK_A4suKPNQ Received: from [98.203.21.152] by web63906.mail.re1.yahoo.com via HTTP; Wed, 02 Dec 2009 16:21:38 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Wed, 2 Dec 2009 16:21:38 -0800 (PST) From: Barney Cordoba To: "Yuriy A. Korobko" In-Reply-To: <1259769942.6739.33.camel@stormi-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Reducing number of interrupts from intel pro 1000 et adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:21:40 -0000 =0A=0A--- On Wed, 12/2/09, Yuriy A. Korobko wrot= e:=0A=0A> From: Yuriy A. Korobko =0A> Subject: Re= : Reducing number of interrupts from intel pro 1000 et adapter=0A> To: "Bar= ney Cordoba" =0A> Cc: freebsd-net@freebsd.org=0A>= Date: Wednesday, December 2, 2009, 11:05 AM=0A> > > =0A> > > I'd like to k= now a way to control tx interrupts=0A> on intel=0A> > > pro 1000 et=0A> > >= adapter with igb driver. Just installed one in=0A> the router=0A> > > and = systat=0A> > > shows 8-9k rx interrupts and 20k tx interrupts=0A> from igb0= =0A> > > and igb1=0A> > > adapters. Box is a router running freebsd 7.2=0A>= release, I've=0A> > > tried=0A> > > default driver from kernel source and = latest from=0A> intel=0A> > > site, effect is=0A> > > the same with automat= ic interrupt moderation=0A> enabled and=0A> > > disabled. I=0A> > > have th= e same box with intel pro 1000 pt adapter=0A> which=0A> > > have=0A> > > tx= (rx)_int_delay sysctls in em driver, I was able=0A> to reduce=0A> > > numbe= r of=0A> > > tx/rx interrupts to 7-8k per interface and got=0A> much more= =0A> > > cpu idle=0A> > > because of less context switches with same pps.= =0A> > > =0A> =0A> =0A> =0A> > I'm curious as to why you are doing a load t= est on a=0A> single core system=0A> > with a part that is clearly designed = to be used on a=0A> multicore system?=0A> > =0A> > Barney=0A> =0A> Box have= core quad cpu:=0A> =0A> 87 processes:=A0 7 running, 58 sleeping, 22 waitin= g=0A> CPU 0:=A0 0.0% user,=A0 0.0% nice,=A0 3.1% system,=0A> 36.4% interrup= t, 60.5% idle=0A> CPU 1:=A0 0.0% user,=A0 0.0% nice, 15.5% system,=0A> 41.1= % interrupt, 43.4% idle=0A> CPU 2:=A0 0.0% user,=A0 0.0% nice, 11.6% system= ,=0A> 27.1% interrupt, 61.2% idle=0A> CPU 3:=A0 0.0% user,=A0 0.0% nice,=A0= 2.3% system,=0A> 41.5% interrupt, 56.2% idle=0A> Mem: 192M Active, 206M In= act, 246M Wired, 716K Cache, 112M=0A> Buf, 1356M =0A> =0A> Anyway, high int= errupt rate fixed by=0A> =0A> border# cat /boot/loader.conf | grep igb=0A> = if_igb_load=3D"YES"=0A> hw.igb.rxd=3D4096=0A> hw.igb.txd=3D4096=0A> hw.igb.= num_queues=3D1=0A> hw.igb.enable_aim=3D1=0A> hw.igb.low_latency=3D1000=0A> = hw.igb.ave_latency=3D2000=0A> hw.igb.bulk_latency=3D4000=0A> hw.igb.rx_proc= ess_limit=3D200=0A> hw.igb.fc_setting=3D0=0A> hw.igb.lro=3D0=0A> border# = =0A> =0A> Have no idea why, but it seems like setting dev.igb.=0A> sysctls = at runtime=0A> just ignored by the driver. Now I have 1000-1200 rx and=0A> = around 2000 tx=0A> interrupts per second from interface with 100 kpps flow = in=0A> each=0A> direction, main cpu eater on the router is dummynet right= =0A> now, it will=0A> be awesome if one day we can have it multithreaded. = =0A> =0A> I'm using latest igb driver from intel site, default driver=0A> f= rom kernel=0A> may not have this issue.=0A> =0A> Thanks.=0A> =0A> =0A> ____= ___________________________________________=0A> freebsd-net@freebsd.org=0A>= mailing list=0A> http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A>= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A>= =0A=0AAh, dummynet. Explains much. I've never seen livelock on a quad core= =0Asystem.=0A=0AThe igb driver in FreeBSD needs a complete and total overha= ul. Don't =0Awaste alot of time tweeking it. Turn off AIM and hard code som= ething=0Athat suits your network. Intel's aim algorithm is ill-conceived IM= O.=0A=0A=0ABarney=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 02:00:16 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 853B5106566B for ; Thu, 3 Dec 2009 02:00:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5B4D68FC0C for ; Thu, 3 Dec 2009 02:00:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB320FjG093098 for ; Thu, 3 Dec 2009 02:00:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB320F4M093097; Thu, 3 Dec 2009 02:00:15 GMT (envelope-from gnats) Date: Thu, 3 Dec 2009 02:00:15 GMT Message-Id: <200912030200.nB320F4M093097@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: David Horn Cc: Subject: Re: kern/139117: [lagg] + wlan boot timing (EBUSY) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Horn List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 02:00:16 -0000 The following reply was made to PR kern/139117; it has been noted by GNATS. From: David Horn To: bug-followup@freebsd.org Cc: Subject: Re: kern/139117: [lagg] + wlan boot timing (EBUSY) Date: Wed, 2 Dec 2009 20:58:06 -0500 Just for anyone else running into this problem, a "hack" workaround is to force the raw wireless interface (wlan0) and the raw wired interface (bfe0 in my case) to not accept IPv6 router advertisements, and just allow the lagg0 interface to accept them. This causes the timing window for OACTIVE (and thus the EBUSY response) to be MUCH smaller, and now I only very rarely see this issue. Example 8.0 rc.conf hack to use ndp to disable accepting IPv6 rtadv: ifconfig_bfe0="ether 00:1c:23:98:2c:5d `ndp -i bfe0 nud -accept_rtadv >/dev/null 2>&1`" ifconfig_wlan0="WPA `ndp -i wlan0 nud -accept_rtadv >/dev/null 2>&1`" ifconfig_iwn0="ether 00:1c:23:98:2c:5d" cloned_interfaces="lagg0" ipv6_network_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport bfe0 laggport wlan0 DHCP" ipv6_enable="YES" Note, you will need to ignore any ndp error messages out of rc.conf at boot time, as this will cause spurious (but innocuous) console error messages about ndp. Example 9.0 rc.conf settings: ifconfig_iwn0="ether 00:1c:23:98:2c:5d" wlans_iwn0="wlan0" ifconfig_bfe0="UP" ifconfig_bfe0_ipv6="inet6 ifdisabled -nud -auto_linklocal" ifconfig_wlan0="WPA" ifconfig_wlan0_ipv6="inet6 ifdisabled -nud -auto_linklocal" cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport bfe0 laggport wlan0 DHCP" ifconfig_lagg0_ipv6="inet6 accept_rtadv" ipv6_prefer="YES" This was thanks to sam@ for pointing me away from wpa_supplicant and towards IPv6 as a likely culprit for causing the OACTIVE flag to be set on the interface causing the ifconfig lagg0 call to not add the wireless interface. Of course in 9.0 (-current as of the moment), there is the new facility to disable IPv6 router advertisements (and other ipv6 flags) via ifconfig so this hack is not needed there. The contention/timing issue still exists, but since users likely to NOT want the non-lagg interfaces to get IPv6 addresses from a router advertisement message anyway, the work around makes this problem less severe. The 9.0 example here is of course subject to change... ---Dave Horn From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 10:49:27 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4BC1065679 for ; Thu, 3 Dec 2009 10:49:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id DF4848FC0C for ; Thu, 3 Dec 2009 10:49:26 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9FE9CC5C3D; Thu, 3 Dec 2009 05:49:25 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 03 Dec 2009 05:49:25 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=SRQtnTLVs5O6c2qo5pryM5OTEME=; b=bte4fdtdiVJ44esKgQ2SwX3BvoGV+fpydlufhOZhUN+s1sFXPrE7wWW5X1t9RPvKwobGYj+MIkvdtHJB9pgr7Tq2d4bUVTCfi2UWGTcV5xqarWIp9zk38hePPq0sV4qeOoLitGcyzGFx0evCrmiKH7w3DoiLVEFuGjKyc5IUQvY= X-Sasl-enc: CrDeTTWLYa2S4eD2HJ+FYe6K0tiV9Qc62ewg5f+t3e7q 1259837365 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 26EAF2B386; Thu, 3 Dec 2009 05:49:25 -0500 (EST) Message-ID: <4B1797A9.3060101@incunabulum.net> Date: Thu, 03 Dec 2009 10:49:13 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Harti Brandt References: <20091202184310.J78398@beagle.kn.op.dlr.de> In-Reply-To: <20091202184310.J78398@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: generating routing message on LL address change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 10:49:27 -0000 Harti Brandt wrote: > Hi all, > > I would like to commit the following patch. It generates an RTM_IFINFO > message when the link-layer address of an interface is changed. This > should be no problem for routing daemons, because the same messages > are also generated when other interface state changes. Are there any > reasons not to do this? None from my end, looks OK. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 11:18:16 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE3F41065670 for ; Thu, 3 Dec 2009 11:18:16 +0000 (UTC) (envelope-from return@smartcrm.com.br) Received: from smtp77163.smartcrm.com.br (smtp77163.smartcrm.com.br [189.77.218.163]) by mx1.freebsd.org (Postfix) with ESMTP id 55C908FC08 for ; Thu, 3 Dec 2009 11:18:16 +0000 (UTC) Received: from script22 (unknown [10.1.77.148]) by smtp77163.smartcrm.com.br (Postfix) with ESMTP id 96A81D3BE7 for ; Thu, 3 Dec 2009 09:16:05 -0200 (BRST) Date: Thu, 3 Dec 2009 09:18:18 -0200 (BRST) From: Lojas Rai To: freebsd-net@freebsd.org Message-ID: <1220102329.22351661259839098371.JavaMail.root@script22> Content-Transfer-Encoding: quoted-printable X-Mailer: SmartCRM 276742_41106 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: O maior Natal de todos os tempos - Celular Motorola W233 10 x 16, 94 ou a vista R$ 140,00 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Lojas Rai List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 11:18:16 -0000 Caso n=E3o esteja visualizando este e-mail, [1]veja aqui. [2]3D"" [3][LINK]-[4]=3D"" [5]3D"" [6]3D"" [7]3D"" [8]3D"" [9]3D"" Descadastre-se caso n=E3o queira receber mais e-mails. [log_em=] References 1. file://localhost/tmp/3D"ht= 2. 3D"http://cache.easymailing.com=/ 3. 3D"http://cache.easymailing.com.br/links.php?= 4. LYNXIMGMAP:file://localhost/tmp/3D"#Map3" 5. LYNXIMGMAP:file://localhost/tmp/3D"#Map"= 6. LYNXIMGMAP:file://localhost/tmp/3D"#Map2= 7. 3D"http://cache.easymailing.com.br/links.php?AGE_ID=3D258576&PE= 8. 3D"http://cache.easymailing.com.br/links.php?= 9. 3D"http://cache.easymailing.com.br/links.php?= From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 18:19:52 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CC051065670 for ; Thu, 3 Dec 2009 18:19:52 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4918FC19 for ; Thu, 3 Dec 2009 18:19:51 +0000 (UTC) Received: (qmail 73744 invoked from network); 3 Dec 2009 18:19:51 -0000 Received: from unknown (HELO ?10.0.0.158?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 3 Dec 2009 18:19:51 -0000 Message-ID: <4B1800E9.8030501@acm.poly.edu> Date: Thu, 03 Dec 2009 13:18:17 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ifconfig: BRDGADD tun0: Invalid argument X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:19:52 -0000 Ahoy. I have an 8.0-RELEASE/i386 machine (installed clean from the CD, so no kernel/world mismatches are possible) on which I am trying to add a tun device to a bridge: # ifconfig tun0 create # ifconfig bridge0 create # ifconfig ... tun0: flags=8010 metric 0 mtu 1500 bridge0: flags=8843 metric 0 mtu 1500 ether 5e:e7:af:1b:14:d3 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 # ifconfig bridge0 addm tun0 ifconfig: BRDGADD tun0: Invalid argument # ifconfig tun0 promisc # ifconfig bridge0 addm tun0 ifconfig: BRDGADD tun0: Invalid argument I have looked at http://lists.freebsd.org/pipermail/freebsd-net/2007-December/016114.html, but none of the three possibilities appear to apply. Any clues? -Boris From owner-freebsd-net@FreeBSD.ORG Thu Dec 3 23:43:39 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 033D71065670; Thu, 3 Dec 2009 23:43:38 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E82F8FC0C; Thu, 3 Dec 2009 23:43:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB3NhbG4016658; Thu, 3 Dec 2009 23:43:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB3NhbTu016654; Thu, 3 Dec 2009 23:43:37 GMT (envelope-from linimon) Date: Thu, 3 Dec 2009 23:43:37 GMT Message-Id: <200912032343.nB3NhbTu016654@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141134: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:43:39 -0000 Old Synopsis: "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces New Synopsis: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 3 23:42:59 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141134 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 07:54:43 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81857106566B for ; Fri, 4 Dec 2009 07:54:43 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 398398FC0C for ; Fri, 4 Dec 2009 07:54:43 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 7E547130C73; Fri, 4 Dec 2009 10:54:41 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 32957130C43; Fri, 4 Dec 2009 10:54:40 +0300 (MSK) Date: Fri, 4 Dec 2009 10:54:40 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20091204075440.GH14822@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Cc: Pyun YongHyeon Subject: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:54:43 -0000 I saw commit introducing hw.bge.forced_collapse loader tunable. Just intresting, why it can not be a sysctl ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 08:47:39 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48CC1106566B for ; Fri, 4 Dec 2009 08:47:39 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id D7B748FC08 for ; Fri, 4 Dec 2009 08:47:38 +0000 (UTC) Received: by fxm10 with SMTP id 10so2201740fxm.34 for ; Fri, 04 Dec 2009 00:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XICWU39ZtZ3tl78+WJv85iRL/FqdBYTsHo9qdOw8xss=; b=EIGX7A0j+B24x8ey9OewC60v3qruHig+Bnqs+meW4I/Yf0fVS0A4FMNB7bk60AsEm2 YSGXTLSTTxE+ihx1yF/qKxaAI2H7Mu3WKWAOxyVzpM6ycQbEw15CWEOD/tDXMc0f7CHK eD5+HJC4Ts5B3UxIKPIWgV9vp5od7Bq51kWy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Mh8nRlFRY0p5Ca4GnlZ/q3kEWRAv8Lrc9a0Cl7Y5pX3uMl7j/xiDBUQ7gcaFXd/bcg SFYzOZ3q8vfpdq1gdFjgo/F9wBrHiqDMOtTALQ+VS4AfyRwy+DZCP7afv5coAwcu+hPb Aq86Ib65BnP4smLkvAnXBVhf8VNg5SIUi0vQ0= MIME-Version: 1.0 Received: by 10.239.185.77 with SMTP id b13mr279691hbh.158.1259916457748; Fri, 04 Dec 2009 00:47:37 -0800 (PST) Date: Fri, 4 Dec 2009 11:47:37 +0300 Message-ID: <933fa9790912040047k64aa11a7s736688e7382725ad@mail.gmail.com> From: Lytochkin Boris To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD 8: ipfw fwd and pf route-to broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 08:47:39 -0000 Hi! It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning: 1) ipfw fwd a) net.inet.ip.forwarding = 0 Packets altered by fwd rule are silently dropped somewhere between ip_output() checking forward tag and bpf (tcpdump does not show these packets) b) net.inet.ip.forwarding = 1 Packets altered by fwd rule are forwarded according to normal routing table (in my case they were forwarded to default gateway), not fwd statement 2) pf route-to Both values of net.inet.ip.forwarding replicates 1b case. Sample configs 1) ipfw add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out add 65534 allow ip from any to any 2) pf scrub in all fragment reassemble pass in all flags S/SA keep state pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24 to any flags S/SA keep state ~>uname -a FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec 2 13:43:48 MSK 2009 root@thost:/usr/obj/usr/src/sys/CSUP amd64 -- Regards, Boris Lytochkin From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 08:48:30 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78D2B10656C4 for ; Fri, 4 Dec 2009 08:48:30 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 14A7F8FC23 for ; Fri, 4 Dec 2009 08:48:29 +0000 (UTC) Received: by fxm10 with SMTP id 10so2202257fxm.34 for ; Fri, 04 Dec 2009 00:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+qiEgBMgssWpOh82vmFk6CJvUpcHs/vJ1liNQUacGeQ=; b=IRDLXkC9a19bmNdibpP+pX+poz/AJQNEQ1F2VSABpFIILNTfku+BBaZiBxH2VSlTOP itibtSTJQUyGtq1jqbnIeXkJMYdmnCQLPWBetLnRqcLHcRCfoZhZSfsRotagRhgqTvDT tUFoOoAXSiUCSMQ9/gCZhK7rSk3ZxhNybVm+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TvDCkZw9nAVP5bWKyFsj8TUTXRK0OVI5OZJ0jAAhxSYLfDpmIU/N7EBNF3jMClml2q v2iTV3lwzx1+KHgbsruaBX/b32dk++14CNCzheOmsCIeRCAaGrD3S80rOWMqUwylzZKq nAZ5rGkPX3MpqQmYybZpqJVP4L1Fc2YL6/+RI= MIME-Version: 1.0 Received: by 10.239.156.14 with SMTP id k14mr263794hbc.181.1259915200638; Fri, 04 Dec 2009 00:26:40 -0800 (PST) Date: Fri, 4 Dec 2009 11:26:40 +0300 Message-ID: <933fa9790912040026j6ca450c5qb355cf7f9efcdeb@mail.gmail.com> From: Lytochkin Boris To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD 8: ipfw fwd and pf's route-to (reply-to) broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 08:48:30 -0000 Hi! It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning: 1) ipfw fwd a) net.inet.ip.forwarding = 0 Then packets altered by fwd rule are silently dropped somewhere between ip_output() checking forward tag and bpf (tcpdump does not show these packets) b) net.inet.ip.forwarding = 1 Packets altered by fwd rule are forwarded according to normal routing table (in my case they were forwarded to default gateway), not fwd statement 2) pf route-to Both values of net.inet.ip.forwarding replicates 1b case. Sample configs 1) ipfw add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out add 65534 allow ip from any to any 2) pf scrub in all fragment reassemble pass in all flags S/SA keep state pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24 to any flags S/SA keep state ~>uname -a FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec 2 13:43:48 MSK 2009 root@thost:/usr/obj/usr/src/sys/CSUP amd64 -- Regards, Boris Lytochkin From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 17:33:59 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C353E1065676 for ; Fri, 4 Dec 2009 17:33:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 73EA28FC12 for ; Fri, 4 Dec 2009 17:33:59 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so561747qwb.7 for ; Fri, 04 Dec 2009 09:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=fxrAK8ykfnQXEVfL+porsODd3AgpzxlQMf0bdmYQLco=; b=rks+LzGJYWp/P3wpsyvrofYVmeJrd+vFEONg/tJsIm6wXypKq0A5bPj6WxS1Nc8Hfl mA1+RVDLhwYVan+WGUTHeciVXMTHKfA+ap9XENs4Pm2/4TJOzCBcB9bZcJSRH/olDe2f thfIJsw0zxpBlZFsdRhMym4aErHG5dESLeDMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ubpxYpAXIDdSXnXV7PA9/E1NaJOdrX7oHcedo/NzptCUZm1+GMIB39dRBtvUX71ntC xUNpY8nFUEwnQLZNFSgfCp1bNiiG38M7152Hea4z9SWAehM0eOUe/CoCQ8dQ2IgdjEzf egicHhLgvCA2nocJuSVAJcwdtyQtZrRD8aImc= Received: by 10.224.87.194 with SMTP id x2mr1049885qal.153.1259948036964; Fri, 04 Dec 2009 09:33:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm7889700qwg.28.2009.12.04.09.33.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Dec 2009 09:33:55 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 4 Dec 2009 09:32:43 -0800 From: Pyun YongHyeon Date: Fri, 4 Dec 2009 09:32:43 -0800 To: Igor Sysoev Message-ID: <20091204173243.GC16491@michelle.cdnetworks.com> References: <20091204075440.GH14822@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091204075440.GH14822@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:33:59 -0000 On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > I saw commit introducing hw.bge.forced_collapse loader tunable. > Just intresting, why it can not be a sysctl ? > I didn't think the sysctl variable would be frequently changed in runtime except debugging driver so I took simple path. > > -- > Igor Sysoev > http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 18:15:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 154701065670; Fri, 4 Dec 2009 18:15:05 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0C8E8FC14; Fri, 4 Dec 2009 18:15:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4IF4Rw094839; Fri, 4 Dec 2009 18:15:04 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4IF4dX094835; Fri, 4 Dec 2009 18:15:04 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 18:15:04 GMT Message-Id: <200912041815.nB4IF4dX094835@freefall.freebsd.org> To: qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/141134: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:15:05 -0000 Synopsis: [ppp] "ioctl (SIOCAIFADDR): File exists" error when configuring ppp interfaces Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 18:05:10 UTC 2009 Responsible-Changed-Why: Take ownership of this bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=141134 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 18:54:36 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F21DC1065693; Fri, 4 Dec 2009 18:54:36 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C95318FC08; Fri, 4 Dec 2009 18:54:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4Isao7029276; Fri, 4 Dec 2009 18:54:36 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4IsaLC029272; Fri, 4 Dec 2009 18:54:36 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 18:54:36 GMT Message-Id: <200912041854.nB4IsaLC029272@freefall.freebsd.org> To: sten@blinkenlights.nl, qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/139145: [ip6] IPv6 blackhole / reject routes broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:54:37 -0000 Synopsis: [ip6] IPv6 blackhole / reject routes broken State-Changed-From-To: open->closed State-Changed-By: qingli State-Changed-When: Fri Dec 4 18:53:31 UTC 2009 State-Changed-Why: The fix had been committed and verified by the submitter. Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 18:53:31 UTC 2009 Responsible-Changed-Why: The fix had been committed and verified by the submitter. http://www.freebsd.org/cgi/query-pr.cgi?pr=139145 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 18:56:22 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0798B106568D; Fri, 4 Dec 2009 18:56:22 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D2C2B8FC0A; Fri, 4 Dec 2009 18:56:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4IuLoU029352; Fri, 4 Dec 2009 18:56:21 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4IuLZc029348; Fri, 4 Dec 2009 18:56:21 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 18:56:21 GMT Message-Id: <200912041856.nB4IuLZc029348@freefall.freebsd.org> To: mclone@gmail.com, qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/139113: [arp] removing IP alias doesn't delete permanent arp entry X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:56:22 -0000 Synopsis: [arp] removing IP alias doesn't delete permanent arp entry State-Changed-From-To: open->closed State-Changed-By: qingli State-Changed-When: Fri Dec 4 18:55:40 UTC 2009 State-Changed-Why: The patch has been committed and the fix has been verified. Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 18:55:40 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=139113 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 18:58:54 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119C11065697; Fri, 4 Dec 2009 18:58:54 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD6F78FC1A; Fri, 4 Dec 2009 18:58:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4IwrHK029432; Fri, 4 Dec 2009 18:58:53 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4IwrMh029428; Fri, 4 Dec 2009 18:58:53 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 18:58:53 GMT Message-Id: <200912041858.nB4IwrMh029428@freefall.freebsd.org> To: qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/138676: [route] after buildworld not work local routes [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:58:54 -0000 Synopsis: [route] after buildworld not work local routes [regression] Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 18:58:35 UTC 2009 Responsible-Changed-Why: Take ownership of this bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=138676 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 19:11:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFF07106566B for ; Fri, 4 Dec 2009 19:11:16 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 732558FC14 for ; Fri, 4 Dec 2009 19:11:16 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 480B1130C8F for ; Fri, 4 Dec 2009 22:11:15 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id ABA6B130C4B for ; Fri, 4 Dec 2009 22:11:14 +0300 (MSK) Date: Fri, 4 Dec 2009 22:11:14 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20091204191114.GB76992@rambler-co.ru> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20091204173243.GC16491@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:11:17 -0000 On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > Just intresting, why it can not be a sysctl ? > > I didn't think the sysctl variable would be frequently changed > in runtime except debugging driver so I took simple path. I do not think it's worth to reboot server just to look how various values affect on bandwidth and CPU usage, expecially in production. As I understand the change is trivial: - CTLFLAG_RD + CTLFLAG_RW since bge_forced_collapse is used atomically. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 19:44:27 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5DEE1065692; Fri, 4 Dec 2009 19:44:27 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AD65B8FC0C; Fri, 4 Dec 2009 19:44:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4JiRFA072727; Fri, 4 Dec 2009 19:44:27 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4JiRub072723; Fri, 4 Dec 2009 19:44:27 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 19:44:27 GMT Message-Id: <200912041944.nB4JiRub072723@freefall.freebsd.org> To: qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/139559: [tun] several tun(4) interfaces can be created with same dst addr X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:44:27 -0000 Synopsis: [tun] several tun(4) interfaces can be created with same dst addr Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 19:44:12 UTC 2009 Responsible-Changed-Why: Take ownership of this bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=139559 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 19:46:50 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546A31065785; Fri, 4 Dec 2009 19:46:50 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C99788FC1D; Fri, 4 Dec 2009 19:46:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4JknE3072791; Fri, 4 Dec 2009 19:46:49 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4Jknxn072787; Fri, 4 Dec 2009 19:46:49 GMT (envelope-from qingli) Date: Fri, 4 Dec 2009 19:46:49 GMT Message-Id: <200912041946.nB4Jknxn072787@freefall.freebsd.org> To: rrs@FreeBSD.org, qingli@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: qingli@FreeBSD.org Cc: Subject: Re: kern/134369: [route] [ip6] IPV6 in Head broken for routing table updates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:46:50 -0000 Synopsis: [route] [ip6] IPV6 in Head broken for routing table updates State-Changed-From-To: open->closed State-Changed-By: qingli State-Changed-When: Fri Dec 4 19:46:08 UTC 2009 State-Changed-Why: The patch had been committed and verified by the submitted in May 2009. Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: qingli Responsible-Changed-When: Fri Dec 4 19:46:08 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=134369 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 19:52:56 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 207A3106566B for ; Fri, 4 Dec 2009 19:52:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-vw0-f173.google.com (mail-vw0-f173.google.com [209.85.212.173]) by mx1.freebsd.org (Postfix) with ESMTP id B953A8FC08 for ; Fri, 4 Dec 2009 19:52:55 +0000 (UTC) Received: by vws3 with SMTP id 3so1306012vws.3 for ; Fri, 04 Dec 2009 11:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=E0nlUzWZLOje//vBu31XD4FmCWq6oWg0mBdzGHvrjRc=; b=vnkuwmwrtJMZRBMrd4migFU65S08Zjz3wp6oEoZwD6LsuiR8iNvtDz4ZeadJdqwQ6g gWWxFj+l4jM//KjLpnWFgRYGHQwMPpQclWeQvk4mYelHDDskw4jG+vOhJdRzW9jKDewP q5KzazZ4ucRXca7WqUXH+hyO8ZThQKe83OItM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=isUVmlEQEkaJ/Iy46Y7d7aSYt1iDGK5gkSzviwG4X/VARuk2B8OENGkOBZ6laP2Po1 0MpQo646bsMZxLE15hNDU45rS29KLxHzpZ/QWoFJtwuV5D4NXQAAQIW/UNK3VTKkuxeY nIFRIWrKt5fENfRbeiMT8frVI5HLgbAtw51GE= Received: by 10.220.126.144 with SMTP id c16mr4647815vcs.43.1259956374917; Fri, 04 Dec 2009 11:52:54 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm6947841vws.8.2009.12.04.11.52.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Dec 2009 11:52:53 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 4 Dec 2009 11:51:40 -0800 From: Pyun YongHyeon Date: Fri, 4 Dec 2009 11:51:40 -0800 To: Igor Sysoev Message-ID: <20091204195140.GH16491@michelle.cdnetworks.com> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <20091204191114.GB76992@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:52:56 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > Just intresting, why it can not be a sysctl ? > > > > I didn't think the sysctl variable would be frequently changed > > in runtime except debugging driver so I took simple path. > > I do not think it's worth to reboot server just to look how various > values affect on bandwidth and CPU usage, expecially in production. > > As I understand the change is trivial: > > - CTLFLAG_RD > + CTLFLAG_RW > > since bge_forced_collapse is used atomically. > I have no problem changing it to RW but that case I may have to create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead of hw.bge.forced_collapse which may affect all bge(4) controllers on system. Attached patch may be what you want. You can change the value at any time. --jq0ap7NbKX2Kqbes Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.collapse.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 200104) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -2647,6 +2647,7 @@ int bge_link; /* link state */ int bge_link_evt; /* pending link event */ int bge_timer; + int bge_forced_collapse; struct callout bge_stat_ch; uint32_t bge_rx_discards; uint32_t bge_tx_discards; Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 200104) +++ sys/dev/bge/if_bge.c (working copy) @@ -449,6 +449,7 @@ #endif static void bge_add_sysctls(struct bge_softc *); static int bge_sysctl_stats(SYSCTL_HANDLER_ARGS); +static int bge_sysctl_forced_collapse(SYSCTL_HANDLER_ARGS); static device_method_t bge_methods[] = { /* Device interface */ @@ -483,29 +484,12 @@ DRIVER_MODULE(miibus, bge, miibus_driver, miibus_devclass, 0, 0); static int bge_allow_asf = 1; -/* - * A common design characteristic for many Broadcom client controllers - * is that they only support a single outstanding DMA read operation - * on the PCIe bus. This means that it will take twice as long to fetch - * a TX frame that is split into header and payload buffers as it does - * to fetch a single, contiguous TX frame (2 reads vs. 1 read). For - * these controllers, coalescing buffers to reduce the number of memory - * reads is effective way to get maximum performance(about 940Mbps). - * Without collapsing TX buffers the maximum TCP bulk transfer - * performance is about 850Mbps. However forcing coalescing mbufs - * consumes a lot of CPU cycles, so leave it off by default. - */ -static int bge_forced_collapse = 0; TUNABLE_INT("hw.bge.allow_asf", &bge_allow_asf); -TUNABLE_INT("hw.bge.forced_collapse", &bge_forced_collapse); SYSCTL_NODE(_hw, OID_AUTO, bge, CTLFLAG_RD, 0, "BGE driver parameters"); SYSCTL_INT(_hw_bge, OID_AUTO, allow_asf, CTLFLAG_RD, &bge_allow_asf, 0, "Allow ASF mode if available"); -SYSCTL_INT(_hw_bge, OID_AUTO, forced_collapse, CTLFLAG_RD, &bge_forced_collapse, - 0, "Number of fragmented TX buffers of a frame allowed before " - "forced collapsing"); #define SPARC64_BLADE_1500_MODEL "SUNW,Sun-Blade-1500" #define SPARC64_BLADE_1500_PATH_BGE "/pci@1f,700000/network@2" @@ -3933,17 +3917,17 @@ } if ((m->m_pkthdr.csum_flags & CSUM_TSO) == 0 && - bge_forced_collapse > 0 && (sc->bge_flags & BGE_FLAG_PCIE) != 0 && - m->m_next != NULL) { + sc->bge_forced_collapse > 0 && + (sc->bge_flags & BGE_FLAG_PCIE) != 0 && m->m_next != NULL) { /* * Forcedly collapse mbuf chains to overcome hardware * limitation which only support a single outstanding * DMA read operation. */ - if (bge_forced_collapse == 1) + if (sc->bge_forced_collapse == 1) m = m_defrag(m, M_DONTWAIT); else - m = m_collapse(m, M_DONTWAIT, bge_forced_collapse); + m = m_collapse(m, M_DONTWAIT, sc->bge_forced_collapse); if (m == NULL) { m_freem(*m_head); *m_head = NULL; @@ -4879,6 +4863,7 @@ struct sysctl_ctx_list *ctx; struct sysctl_oid_list *children, *schildren; struct sysctl_oid *tree; + int error; ctx = device_get_sysctl_ctx(sc->bge_dev); children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); @@ -4898,6 +4883,32 @@ #endif + /* + * A common design characteristic for many Broadcom client controllers + * is that they only support a single outstanding DMA read operation + * on the PCIe bus. This means that it will take twice as long to fetch + * a TX frame that is split into header and payload buffers as it does + * to fetch a single, contiguous TX frame (2 reads vs. 1 read). For + * these controllers, coalescing buffers to reduce the number of memory + * reads is effective way to get maximum performance(about 940Mbps). + * Without collapsing TX buffers the maximum TCP bulk transfer + * performance is about 850Mbps. However forcing coalescing mbufs + * consumes a lot of CPU cycles, so leave it off by default. + */ + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "forced_collapse", + CTLTYPE_INT | CTLFLAG_RW, &sc->bge_forced_collapse, 0, + bge_sysctl_forced_collapse, "I", "Number of fragmented TX " + "buffers of a frame allowed before forced collapsing"); + sc->bge_forced_collapse = 0; + error = resource_int_value(device_get_name(sc->bge_dev), + device_get_unit(sc->bge_dev), "forced_collapse", + &sc->bge_forced_collapse); + if (error == 0) { + if (sc->bge_forced_collapse < 0 || + sc->bge_forced_collapse > BGE_NSEG_NEW); + sc->bge_forced_collapse = 0; + } + if (BGE_IS_5705_PLUS(sc)) return; @@ -5143,6 +5154,23 @@ #endif static int +bge_sysctl_forced_collapse(SYSCTL_HANDLER_ARGS) +{ + int error, value; + + if (arg1 == NULL) + return (EINVAL); + value = *(int *)arg1; + error = sysctl_handle_int(oidp, &value, 0, req); + if (error || req->newptr == NULL) + return (error); + if (value < 0 || value > BGE_NSEG_NEW) + return (EINVAL); + *(int *)arg1 = value; + return (0); +} + +static int bge_get_eaddr_fw(struct bge_softc *sc, uint8_t ether_addr[]) { --jq0ap7NbKX2Kqbes-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 20:13:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11EAB106568B for ; Fri, 4 Dec 2009 20:13:06 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id B95C68FC17 for ; Fri, 4 Dec 2009 20:13:05 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 1A3F4130C26 for ; Fri, 4 Dec 2009 23:13:04 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 95375130C1F for ; Fri, 4 Dec 2009 23:13:03 +0300 (MSK) Date: Fri, 4 Dec 2009 23:13:03 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20091204201303.GD76992@rambler-co.ru> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20091204195140.GH16491@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 20:13:06 -0000 On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > Just intresting, why it can not be a sysctl ? > > > > > > I didn't think the sysctl variable would be frequently changed > > > in runtime except debugging driver so I took simple path. > > > > I do not think it's worth to reboot server just to look how various > > values affect on bandwidth and CPU usage, expecially in production. > > > > As I understand the change is trivial: > > > > - CTLFLAG_RD > > + CTLFLAG_RW > > > > since bge_forced_collapse is used atomically. > > > > I have no problem changing it to RW but that case I may have to > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > of hw.bge.forced_collapse which may affect all bge(4) controllers > on system. Attached patch may be what you want. You can change the > value at any time. Thank you for the patch. Can it be installed on 8-STABLE ? -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 20:23:24 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED901065672 for ; Fri, 4 Dec 2009 20:23:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id D382E8FC19 for ; Fri, 4 Dec 2009 20:23:23 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so593065qwb.7 for ; Fri, 04 Dec 2009 12:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Vy8xWfaMnjUh9a7t4V7vAC9IMI56qPUsByxPDwFsQ+c=; b=S0MZpSEggsGmJ5Qff2CepBTVxRw0sarVCLMByuLLA604sww+zDtO12oG+lSd8pDSbi P/oXDBADEszbtyrdntiqLL8BG6w3wCqc0pYgAdK+DeXoFXr7TipFaJooAMUWGOeiuyNt q+HfbMd+HgHNO8m/bqGerUy8YZ4Gxt6fLrhMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=A9HNKvKCO7f1eYGyypM3nfhj9ch0kN6gWwRFVnS0/+w4unohkAd7q8kcDryMGTe+ev OI+ctI3z+FW8nb6FMGnDCoCn2C98mrtqDEHGHqSzb7Ldxj4V9orcBtw8BixT1T7Hdlu6 TfDIKQzbyyML8AzHqoB1/r/2bcUvandml7GlM= Received: by 10.224.24.84 with SMTP id u20mr1969057qab.160.1259958203076; Fri, 04 Dec 2009 12:23:23 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 26sm8176849qwa.0.2009.12.04.12.23.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Dec 2009 12:23:22 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 4 Dec 2009 12:22:13 -0800 From: Pyun YongHyeon Date: Fri, 4 Dec 2009 12:22:13 -0800 To: Igor Sysoev Message-ID: <20091204202213.GI16491@michelle.cdnetworks.com> References: <20091204075440.GH14822@rambler-co.ru> <20091204173243.GC16491@michelle.cdnetworks.com> <20091204191114.GB76992@rambler-co.ru> <20091204195140.GH16491@michelle.cdnetworks.com> <20091204201303.GD76992@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091204201303.GD76992@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: hw.bge.forced_collapse X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 20:23:24 -0000 On Fri, Dec 04, 2009 at 11:13:03PM +0300, Igor Sysoev wrote: > On Fri, Dec 04, 2009 at 11:51:40AM -0800, Pyun YongHyeon wrote: > > > On Fri, Dec 04, 2009 at 10:11:14PM +0300, Igor Sysoev wrote: > > > On Fri, Dec 04, 2009 at 09:32:43AM -0800, Pyun YongHyeon wrote: > > > > > > > On Fri, Dec 04, 2009 at 10:54:40AM +0300, Igor Sysoev wrote: > > > > > I saw commit introducing hw.bge.forced_collapse loader tunable. > > > > > Just intresting, why it can not be a sysctl ? > > > > > > > > I didn't think the sysctl variable would be frequently changed > > > > in runtime except debugging driver so I took simple path. > > > > > > I do not think it's worth to reboot server just to look how various > > > values affect on bandwidth and CPU usage, expecially in production. > > > > > > As I understand the change is trivial: > > > > > > - CTLFLAG_RD > > > + CTLFLAG_RW > > > > > > since bge_forced_collapse is used atomically. > > > > > > > I have no problem changing it to RW but that case I may have to > > create actual sysctl node(e.g. dev.bge.0.forced_collapse) instead > > of hw.bge.forced_collapse which may affect all bge(4) controllers > > on system. Attached patch may be what you want. You can change the > > value at any time. > > Thank you for the patch. Can it be installed on 8-STABLE ? > bge(4) in HEAD has many fixes which were not MFCed to stable/8 so I'm not sure that patch could be applied cleanly. But I guess you can manually patch it. I'll wait a couple of days for wider testing/review and commit the patch. From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 21:31:37 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07111065698; Fri, 4 Dec 2009 21:31:37 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 84FCE8FC19; Fri, 4 Dec 2009 21:31:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4LVb8B068026; Fri, 4 Dec 2009 21:31:37 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4LVbHb068022; Fri, 4 Dec 2009 21:31:37 GMT (envelope-from remko) Date: Fri, 4 Dec 2009 21:31:37 GMT Message-Id: <200912042131.nB4LVbHb068022@freefall.freebsd.org> To: info@thaisolution.net, remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: i386/141171: when ping FreeBSD crash and reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 21:31:37 -0000 Synopsis: when ping FreeBSD crash and reboot State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Fri Dec 4 21:30:07 UTC 2009 State-Changed-Why: The information is rather ''limited'', to say the least. Please try to obtain a kernel crash dump so that we might be able to investigate what is going on. Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009 Responsible-Changed-Why: Reassign to the networking team. http://www.freebsd.org/cgi/query-pr.cgi?pr=141171 From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 22:15:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD2CC1065670; Fri, 4 Dec 2009 22:15:48 +0000 (UTC) (envelope-from info@thaisolution.net) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8A21D8FC12; Fri, 4 Dec 2009 22:15:48 +0000 (UTC) Received: by pwj15 with SMTP id 15so2526807pwj.3 for ; Fri, 04 Dec 2009 14:15:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.236.23 with SMTP id j23mr4770856wah.164.1259963392127; Fri, 04 Dec 2009 13:49:52 -0800 (PST) In-Reply-To: <200912042131.nB4LVbHb068022@freefall.freebsd.org> References: <200912042131.nB4LVbHb068022@freefall.freebsd.org> Date: Sat, 5 Dec 2009 04:49:52 +0700 Message-ID: <88238c960912041349o4947da9wa04763abb9688369@mail.gmail.com> From: Prommart Saelua To: remko@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-i386@freebsd.org, bug-followup@FreeBSD.org Subject: Re: i386/141171: when ping FreeBSD crash and reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:15:48 -0000 This is my core dump. http://www.thaisolution.net/tmp/core-dump.tar.gz Thank you 2009/12/5 > Synopsis: when ping FreeBSD crash and reboot > > State-Changed-From-To: open->feedback > State-Changed-By: remko > State-Changed-When: Fri Dec 4 21:30:07 UTC 2009 > State-Changed-Why: > The information is rather ''limited'', to say the least. Please > try to obtain a kernel crash dump so that we might be able to > investigate what is going on. > > > Responsible-Changed-From-To: freebsd-i386->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009 > Responsible-Changed-Why: > Reassign to the networking team. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141171 > From owner-freebsd-net@FreeBSD.ORG Fri Dec 4 22:20:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70ADB1065695 for ; Fri, 4 Dec 2009 22:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7DA8FC2E for ; Fri, 4 Dec 2009 22:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB4MK3LK002131 for ; Fri, 4 Dec 2009 22:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB4MK3TG002130; Fri, 4 Dec 2009 22:20:03 GMT (envelope-from gnats) Date: Fri, 4 Dec 2009 22:20:03 GMT Message-Id: <200912042220.nB4MK3TG002130@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Prommart Saelua Cc: Subject: Re: i386/141171: when ping FreeBSD crash and reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Prommart Saelua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:20:03 -0000 The following reply was made to PR i386/141171; it has been noted by GNATS. From: Prommart Saelua To: remko@freebsd.org Cc: freebsd-i386@freebsd.org, freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: i386/141171: when ping FreeBSD crash and reboot Date: Sat, 5 Dec 2009 04:49:52 +0700 --0016e64bfde06af3b00479ee1656 Content-Type: text/plain; charset=ISO-8859-1 This is my core dump. http://www.thaisolution.net/tmp/core-dump.tar.gz Thank you 2009/12/5 > Synopsis: when ping FreeBSD crash and reboot > > State-Changed-From-To: open->feedback > State-Changed-By: remko > State-Changed-When: Fri Dec 4 21:30:07 UTC 2009 > State-Changed-Why: > The information is rather ''limited'', to say the least. Please > try to obtain a kernel crash dump so that we might be able to > investigate what is going on. > > > Responsible-Changed-From-To: freebsd-i386->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009 > Responsible-Changed-Why: > Reassign to the networking team. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=141171 > --0016e64bfde06af3b00479ee1656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is my core dump.
http://www.thaisolution.net/tmp/core-dump.tar.gz
Thank yo= u

2009/12/5 <remko@freebsd.org>
Synopsis: when ping FreeBSD crash and reboot

State-Changed-From-To: open->feedback
State-Changed-By: remko
State-Changed-When: Fri Dec 4 21:30:07 UTC 2009
State-Changed-Why:
The information is rather ''limited'', to say the least. Pl= ease
try to obtain a kernel crash dump so that we might be able to
investigate what is going on.


Responsible-Changed-From-To: freebsd-i386->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Fri Dec 4 21:30:07 UTC 2009
Responsible-Changed-Why:
Reassign to the networking team.

--0016e64bfde06af3b00479ee1656-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 02:50:05 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1799C106566C for ; Sat, 5 Dec 2009 02:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E13E18FC12 for ; Sat, 5 Dec 2009 02:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB52o4jE035346 for ; Sat, 5 Dec 2009 02:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB52o4P0035345; Sat, 5 Dec 2009 02:50:04 GMT (envelope-from gnats) Date: Sat, 5 Dec 2009 02:50:04 GMT Message-Id: <200912050250.nB52o4P0035345@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 02:50:05 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt , sam@freebsd.org Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Fri, 4 Dec 2009 21:49:42 -0500 (EST) Okay, I've been getting these lockups fairly frequently -- in fact, there was this one room where I was getting them every five minutes or so. I hypothesized that dissociation/association events might be triggers, so I set dev.iwn.0.debug=-1 and started wandering around this building (which is chock full of APs). I get: panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254 Unfortunately, it appears to have messed up my machine pretty badly, as only numlock blinks the LED, and I don't have a db> prompt ... Trying again without the debugging spew gets a useful debugger, though. "show alllocks" produces empty output (?!). backtrace is: kdb_enter panic witness_unlock _mtx_unlock_flags iwn_raw_xmit ieee80211_send_probereq beacom_miss taskqueue_run taskqueue_thread_loop fork_exit Looking at the coredump, I'm inclined to suspect this block of ieee80211_proto.c (in beacon_miss() ): 1.46 sam 1379: /* XXX locking */ 1380: TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) { 1.38 sam 1381: /* 1.46 sam 1382: * We only pass events through for sta vap's in RUN state; 1383: * may be too restrictive but for now this saves all the 1384: * handlers duplicating these checks. 1.38 sam 1385: */ 1.46 sam 1386: if (vap->iv_opmode == IEEE80211_M_STA && 1.64 sam 1387: vap->iv_state >= IEEE80211_S_RUN && 1.46 sam 1388: vap->iv_bmiss != NULL) 1389: vap->iv_bmiss(vap); Sam, do you have any thoughts as to why throwing a IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH might not be a good idea? I'm currently running with that, which gives me a new LOR (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289) but it hasn't locked up or panic()ed on me, yet. I am happy to pull more information from the coredump if needed. Thanks, Ben Kaduk From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 03:46:06 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C036B1065670 for ; Sat, 5 Dec 2009 03:46:06 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by mx1.freebsd.org (Postfix) with ESMTP id 546978FC12 for ; Sat, 5 Dec 2009 03:46:06 +0000 (UTC) Received: by ewy8 with SMTP id 8so3562675ewy.35 for ; Fri, 04 Dec 2009 19:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=44GT0iAEMFQngcSdVLZb9keZTF7ls/D1QfPyLUz5YCs=; b=WoGCQXv7+RDwpbtDe8NKfrje2QZ18H9OLA8xlJM5EnT+VFxR0Wyt8Br51nFK++q2Az HvGM8EDdSUM0OekhBju9a0sAZ5l3qdcyKRcHgrr6x5a/F/4cGRqg6bODNfC6sG70tLhT WhemX7w/NAWZBa6yx7jTZKnVVF39izgrCaDtE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uoz6kaTWm9sLd4rX1tOLxWGn9NkviKTrbzNMTaCHugQpFbYXR84KWMp+czyqo/v8i0 Dq/YwCWIA+P7Dr8HbUCOP9T+Ux43tBYrBh8GCvZkMZ3An4bHOX9aEMdHImm4y53jORtv ZfADl2ke8HJrtQGgAIJg/CNv2D0M1lF0kyp1I= MIME-Version: 1.0 Received: by 10.213.23.80 with SMTP id q16mr3660732ebb.3.1259984763798; Fri, 04 Dec 2009 19:46:03 -0800 (PST) In-Reply-To: <200912050250.nB52o4P0035345@freefall.freebsd.org> References: <200912050250.nB52o4P0035345@freefall.freebsd.org> Date: Sat, 5 Dec 2009 03:46:03 +0000 Message-ID: <179b97fb0912041946j13760914ycc2c5145d8df9ee@mail.gmail.com> From: Brandon Gooch To: Benjamin Kaduk , freebsd-net@freebsd.org, Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 03:46:06 -0000 On Sat, Dec 5, 2009 at 2:50 AM, Benjamin Kaduk wrote: > The following reply was made to PR kern/140036; it has been noted by GNAT= S. > > From: Benjamin Kaduk > To: Bernhard Schmidt , sam@freebsd.org > Cc: bug-followup@freebsd.org > Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_l= ock > =A0and iwn0 softc lock > Date: Fri, 4 Dec 2009 21:49:42 -0500 (EST) > > =A0Okay, I've been getting these lockups fairly frequently -- in fact, > =A0there was this one room where I was getting them every five minutes > =A0or so. =A0I hypothesized that dissociation/association events might > =A0be triggers, so I set dev.iwn.0.debug=3D-1 and started wandering aroun= d > =A0this building (which is chock full of APs). > =A0I get: > =A0panic: lock (sleep mutex) iwn0_com_lock not locked @ > =A0/usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254 > > =A0Unfortunately, it appears to have messed up my machine pretty badly, > =A0as only numlock blinks the LED, and I don't have a db> prompt ... > > =A0Trying again without the debugging spew gets a useful debugger, though= . > =A0"show alllocks" produces empty output (?!). > =A0backtrace is: > =A0kdb_enter > =A0panic > =A0witness_unlock > =A0_mtx_unlock_flags > =A0iwn_raw_xmit > =A0ieee80211_send_probereq > =A0beacom_miss > =A0taskqueue_run > =A0taskqueue_thread_loop > =A0fork_exit > > =A0Looking at the coredump, I'm inclined to suspect this block of > =A0ieee80211_proto.c (in beacon_miss() ): > =A01.46 =A0 =A0 =A0sam =A0 1379: =A0 =A0 =A0 =A0/* XXX locking */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01380: =A0 =A0 =A0 =A0TAILQ_FOREACH(vap= , &ic->ic_vaps, iv_next) { > =A01.38 =A0 =A0 =A0sam =A0 1381: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A01.46 =A0 =A0 =A0sam =A0 1382: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * We onl= y pass events through for sta vap's in RUN state; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01383: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = * may be too restrictive but for now this saves all the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01384: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = * handlers duplicating these checks. > =A01.38 =A0 =A0 =A0sam =A0 1385: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ > =A01.46 =A0 =A0 =A0sam =A0 1386: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (vap->= iv_opmode =3D=3D IEEE80211_M_STA && > =A01.64 =A0 =A0 =A0sam =A0 1387: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0v= ap->iv_state >=3D IEEE80211_S_RUN && > =A01.46 =A0 =A0 =A0sam =A0 1388: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0v= ap->iv_bmiss !=3D NULL) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01389: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0vap->iv_bmiss(vap); > > > =A0Sam, do you have any thoughts as to why throwing a > =A0IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH > =A0might not be a good idea? > =A0I'm currently running with that, which gives me a new LOR > =A0(iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and > =A0iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3= 289) > =A0but it hasn't locked up or panic()ed on me, yet. > > > =A0I am happy to pull more information from the coredump if needed. > Ben, have you tried Bernhard Schmidt's driver? He's recently updated it with a reordering of locking code: http://svn.techwires.net/viewvc/viewvc.cgi/svnrepos/projects/freebsd/sys/de= v/iwn/if_iwn.c?view=3Dlog I've been using the code from his repository for a while, and it's much more stable than what's in the tree currently. -Brandon From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 04:02:08 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548DF1065672 for ; Sat, 5 Dec 2009 04:02:08 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 11FCB8FC0C for ; Sat, 5 Dec 2009 04:02:07 +0000 (UTC) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id nB53orxk018529; Fri, 4 Dec 2009 22:50:53 -0500 (EST) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id nB53pRUT004865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Dec 2009 22:51:28 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id nB53pIRA013743; Fri, 4 Dec 2009 22:51:18 -0500 (EST) Date: Fri, 4 Dec 2009 22:51:18 -0500 (EST) From: Benjamin Kaduk To: Brandon Gooch In-Reply-To: <179b97fb0912041946j13760914ycc2c5145d8df9ee@mail.gmail.com> Message-ID: References: <200912050250.nB52o4P0035345@freefall.freebsd.org> <179b97fb0912041946j13760914ycc2c5145d8df9ee@mail.gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Cc: freebsd-net@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 04:02:08 -0000 On Sat, 5 Dec 2009, Brandon Gooch wrote: > > Ben, have you tried Bernhard Schmidt's driver? He's recently updated > it with a reordering of locking code: > > http://svn.techwires.net/viewvc/viewvc.cgi/svnrepos/projects/freebsd/sys/dev/iwn/if_iwn.c?view=log > > I've been using the code from his repository for a while, and it's > much more stable than what's in the tree currently. Sorry if the PR history was not clear -- this panic is with Bernhard's driver in place. (And a `svn diff` in my working copy doesn't show any changes.) -Ben Kaduk From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 04:40:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32399106566C for ; Sat, 5 Dec 2009 04:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 205C18FC08 for ; Sat, 5 Dec 2009 04:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB54e2gZ030972 for ; Sat, 5 Dec 2009 04:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB54e2DQ030970; Sat, 5 Dec 2009 04:40:02 GMT (envelope-from gnats) Date: Sat, 5 Dec 2009 04:40:02 GMT Message-Id: <200912050440.nB54e2DQ030970@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Jason Loretz Cc: Subject: Re: kern/132554: [ipl] There is no ippool start script/ipfilter magic to load them X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jason Loretz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 04:40:03 -0000 The following reply was made to PR kern/132554; it has been noted by GNATS. From: Jason Loretz To: bug-followup@FreeBSD.org, axel@axel.truedestiny.net Cc: Subject: Re: kern/132554: [ipl] There is no ippool start script/ipfilter magic to load them Date: Fri, 4 Dec 2009 23:10:12 -0500 The ippools feature is quite useful and would be nice to have automatically start with the IPF startup script (as part of FreeBSD rather than a system administrator insert/tweek). The actual functionality already exists in the current 7.1 release and just needs hooks to properly startup and reload/flush configurations in sync with ipfilter. This functionality appears that it should reside in the ipfilter rc.d script since ippools will not work until "ipf -E" has been executed but also needs to be configure d previous to the "ipf -f" commands. Therefore I submit these diffs as a possible solution, which will provide the appropriate rc.conf options and modifications to rc.d/ipfilter to make it load and flush in the correct places during the ipf configuration. I took a stab, but needs work, at modifications to the firewall handbook page to include information on ippools. This no doubt will need some work if it can be included. Thanks, Jason --- rc.conf.diff begins here --- --- /usr/src/etc/defaults/rc.conf 2008-11-24 21:59:29.000000000 -0500 +++ /etc/defaults/rc.conf 2009-11-30 20:43:10.000000000 -0500 @@ -152,6 +152,12 @@ ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags="" # additional flags for ipfilter +ipfilter_ippool_enable="NO" # Set to YES to enable ippool functionality +ippool_program="/sbin/ippool" # where the ippool program lives +ippool_rules="/etc/ippool.conf" # rules definition file for ippool, see + # /usr/src/contrib/ipfilter/rules/pool.conf + # for example +ippool_flags="" # additional flags for ippool ipnat_enable="NO" # Set to YES to enable ipnat functionality ipnat_program="/sbin/ipnat" # where the ipnat program lives ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat --- rc.conf.diff ends here --- --- ipfilter.diff begins here --- --- /usr/src/etc/rc.d/ipfilter 2008-11-24 21:59:29.000000000 -0500 +++ /etc/rc.d/ipfilter 2009-12-01 09:19:43.000000000 -0500 @@ -33,6 +33,14 @@ if [ `sysctl -n net.inet.ipf.fr_running` -le 0 ]; then ${ipfilter_program:-/sbin/ipf} -E fi + if checkyesno ipfilter_ippool_enable; then + if [ -r "${ippool_rules}" ]; then + echo "Loading ippool rules." + ${ippool_program:-/sbin/ippool} \ + -f "${ippool_rules}" ${ippool_flags} + fi + fi + echo "Loading ipfilter rules." ${ipfilter_program:-/sbin/ipf} -Fa if [ -r "${ipfilter_rules}" ]; then ${ipfilter_program:-/sbin/ipf} \ @@ -58,8 +66,16 @@ ipfilter_reload() { - echo "Reloading ipfilter rules." + if checkyesno ipfilter_ippool_enable; then + if [ -r "${ippool_rules}" ]; then + echo "Reloading ippool rules." + ${ippool_program:-/sbin/ippool} -F + ${ippool_program:-/sbin/ippool} \ + -f "${ippool_rules}" ${ippool_flags} + fi + fi + echo "Reloading ipfilter rules." ${ipfilter_program:-/sbin/ipf} -I -Fa if [ -r "${ipfilter_rules}" ]; then ${ipfilter_program:-/sbin/ipf} -I \ --- ipfilter.diff ends here --- --- chapter.sgml.diff begins here --- --- /usr/doc/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml 2009-11-27 12:11:33.000000000 -0500 +++ /tmp/chapter.sgml 2009-12-04 20:19:23.000000000 -0500 @@ -653,6 +653,16 @@ # v = log tcp window, ack, seq # n = map IP & port to names + If the use of ippools is desired, the following lines need to be + added to enable the ippool functionality: + + ipfilter_ippool_enable="NO" # Set to YES to enable ippool functionality +ippool_program="/sbin/ippool" # where the ippool program lives +ippool_rules="/etc/ippool.conf" # rules definition file for ippool, see + # /usr/src/contrib/ipfilter/rules/pool.conf + # for example +ippool_flags="" # additional flags for ippool + If there is a LAN behind this firewall that uses the reserved private IP address ranges, the following lines will have to be added to enable NAT @@ -701,6 +711,26 @@ + IPPOOL + + ippool + + The &man.ippool.8; command is used to load your ippool + configuration file. The following commands can be used to flush + the loaded pools from the kernel and then load a pool configuration + from a file: + + &prompt.root; ippool -F + &prompt.root; ippool -f /etc/ippool.conf + + See the &man.ippool.8; manual page for details on the other + flags available with this command. + + The &man.ippool.8; command expects the configuration file to be a + standard text file. + + + IPFSTAT ipfstat --- chapter.sgml.diff ends here --- From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 09:00:09 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2C841065679 for ; Sat, 5 Dec 2009 09:00:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 379378FC15 for ; Sat, 5 Dec 2009 09:00:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB5908sf089302 for ; Sat, 5 Dec 2009 09:00:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB5908Vc089301; Sat, 5 Dec 2009 09:00:08 GMT (envelope-from gnats) Date: Sat, 5 Dec 2009 09:00:08 GMT Message-Id: <200912050900.nB5908Vc089301@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bernhard Schmidt Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernhard Schmidt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 09:00:09 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Bernhard Schmidt To: Benjamin Kaduk Cc: sam@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Sat, 5 Dec 2009 09:56:23 +0100 On Saturday 05 December 2009 03:49:42 Benjamin Kaduk wrote: > Okay, I've been getting these lockups fairly frequently -- in fact, > there was this one room where I was getting them every five minutes > or so. I hypothesized that dissociation/association events might > be triggers, so I set dev.iwn.0.debug=-1 and started wandering around > this building (which is chock full of APs). > I get: > panic: lock (sleep mutex) iwn0_com_lock not locked @ > /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254 Are you sure your code is in sync? there is nothing accessing the lock in if_iwn.c:3254 3251 if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) { 3252 ieee80211_free_node(ni); 3253 m_freem(m); 3254 return ENETDOWN; 3255 } > Unfortunately, it appears to have messed up my machine pretty badly, > as only numlock blinks the LED, and I don't have a db> prompt ... > > Trying again without the debugging spew gets a useful debugger, though. > "show alllocks" produces empty output (?!). > backtrace is: > kdb_enter > panic > witness_unlock > _mtx_unlock_flags > iwn_raw_xmit > ieee80211_send_probereq > beacom_miss > taskqueue_run > taskqueue_thread_loop > fork_exit > > Looking at the coredump, I'm inclined to suspect this block of > ieee80211_proto.c (in beacon_miss() ): > 1.46 sam 1379: /* XXX locking */ > 1380: TAILQ_FOREACH(vap, &ic->ic_vaps, iv_next) { > 1.38 sam 1381: /* > 1.46 sam 1382: * We only pass events through for sta > vap's in RUN state; 1383: * may be too restrictive but for > now this saves all the 1384: * handlers duplicating these > checks. 1.38 sam 1385: */ > 1.46 sam 1386: if (vap->iv_opmode == IEEE80211_M_STA > && 1.64 sam 1387: vap->iv_state >= > IEEE80211_S_RUN && 1.46 sam 1388: vap->iv_bmiss > != NULL) > 1389: vap->iv_bmiss(vap); > > > Sam, do you have any thoughts as to why throwing a > IEEE80211_LOCK(ic)/IEEE80211_UNLOCK(ic) block around the TAILQ_FOREACH > might not be a good idea? > I'm currently running with that, which gives me a new LOR > (iwn_com_lock @ /usr/src/sys/net80211/ieee80211_scan.c:683 and > iwn0 @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289) > but it hasn't locked up or panic()ed on me, yet. > > > I am happy to pull more information from the coredump if needed. > > Thanks, > > Ben Kaduk > -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 19:24:48 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7296D1065672 for ; Sat, 5 Dec 2009 19:24:47 +0000 (UTC) (envelope-from lytboris@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 33DC38FC21 for ; Sat, 5 Dec 2009 19:24:46 +0000 (UTC) Received: by fxm2 with SMTP id 2so1015695fxm.13 for ; Sat, 05 Dec 2009 11:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ooWt2NOymU9X6T0dIyTFwNM9RAw4Ws1GDAk1FDhm/Ss=; b=agtDRmDNkWIZL80bAd0mpy4lolmzADa2o3GowtJtSjcUvE6R9/dd9JexCUPrrKRIEO lLkaInI5Ms8vcEgvJWVGTP/cLBp/ug3OcE77Mkk7VoRmAWI+hKhJHmMRDujTLxwZ754S K0f7oPh68Ll17F/42/TAF2mCwLOxkYj4jv37Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IlyfW11chktFqyAW9cSSkUzrEWDk6Ovdhgs+e+RChudgo+CfcmrFh9pVNprt1kKCv+ y/WOF9pmf7/Us706+BGMpeBCqyjfdcoC1eaWPjBxEN4YzcDNJGYK96veACRyFthKZ/fv aj+p4ewH41xe53eqwvzfahQAp3nO2ca9/ZPAs= MIME-Version: 1.0 Received: by 10.239.141.136 with SMTP id c8mr417278hba.148.1260041086100; Sat, 05 Dec 2009 11:24:46 -0800 (PST) In-Reply-To: <933fa9790912040047k64aa11a7s736688e7382725ad@mail.gmail.com> References: <933fa9790912040047k64aa11a7s736688e7382725ad@mail.gmail.com> Date: Sat, 5 Dec 2009 22:24:46 +0300 Message-ID: <933fa9790912051124x77f33878tfe588c0cbdb1fe4@mail.gmail.com> From: Lytochkin Boris To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gleb Smirnoff Subject: Re: FreeBSD 8: ipfw fwd and pf route-to broken? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 19:24:48 -0000 Hi! sbin/ipfw in RELENG_8 do not set sin_len in fwd rule, so sockaddr_in from ipfw is sucked into rtalloc1_fib() at last with zero length and is routed to lo0 instead of correct interface. Returning sin_len into sbin/ipfw resolves issue. sin_len setting was removed in revision 1.146 by luigi. What is correct solution? Return sin_len setting into sbin/ipfw or something else? On Fri, Dec 4, 2009 at 11:47 AM, Lytochkin Boris wrote= : > Hi! > > It seems that FreeBSD 8 has ipfw fwd and pf's route-to malfunctioning: > 1) ipfw fwd > a) net.inet.ip.forwarding =3D 0 > =A0Packets altered by fwd rule are silently dropped somewhere > between ip_output() checking forward tag and bpf (tcpdump does not > show these packets) > b) net.inet.ip.forwarding =3D 1 > =A0Packets altered by fwd rule are forwarded according to normal > routing table (in my case they were forwarded to default gateway), not > fwd statement > > 2) pf route-to > Both values of net.inet.ip.forwarding replicates 1b case. > > > Sample configs > > 1) ipfw > add 60 fwd 10.60.128.254 ip from 10.60.128.0/24 to any out > add 65534 allow ip from any to any > > 2) pf > scrub in all fragment reassemble > pass in all flags S/SA keep state > pass out quick route-to (em0 10.60.128.254) inet from 10.60.128.0/24 > to any flags S/SA keep state > > ~>uname -a > FreeBSD thost 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #5: Wed Dec =A02 > 13:43:48 MSK 2009 =A0 =A0 root@thost:/usr/obj/usr/src/sys/CSUP =A0amd64 > > -- Regards, Boris Lytochkin From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 20:30:04 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26934106568F for ; Sat, 5 Dec 2009 20:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 153818FC14 for ; Sat, 5 Dec 2009 20:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB5KU3WN087308 for ; Sat, 5 Dec 2009 20:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB5KU3D9087301; Sat, 5 Dec 2009 20:30:03 GMT (envelope-from gnats) Date: Sat, 5 Dec 2009 20:30:03 GMT Message-Id: <200912052030.nB5KU3D9087301@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 20:30:04 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: sam@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Sat, 5 Dec 2009 15:25:25 -0500 (EST) On Sat, 5 Dec 2009, Bernhard Schmidt wrote: > On Saturday 05 December 2009 03:49:42 Benjamin Kaduk wrote: >> Okay, I've been getting these lockups fairly frequently -- in fact, >> there was this one room where I was getting them every five minutes >> or so. I hypothesized that dissociation/association events might >> be triggers, so I set dev.iwn.0.debug=-1 and started wandering around >> this building (which is chock full of APs). >> I get: >> panic: lock (sleep mutex) iwn0_com_lock not locked @ >> /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3254 > > Are you sure your code is in sync? there is nothing accessing the lock in > if_iwn.c:3254 > > 3251 if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0) { > 3252 ieee80211_free_node(ni); > 3253 m_freem(m); > 3254 return ENETDOWN; > 3255 } > Apparently not -- `svn info` claims that I only have r13, and the web the web interface shows up to r20. I guess I've been using cvs for too long, and expected `${VCS_COMMAND} diff` to default to showing differences from the head of the repository/current branch. I'll update and revert my change to net80211/ieee80211_proto.c and see what changes. Sorry for the noise, Ben From owner-freebsd-net@FreeBSD.ORG Sat Dec 5 21:40:03 2009 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503BA106566C for ; Sat, 5 Dec 2009 21:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEC18FC0C for ; Sat, 5 Dec 2009 21:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB5Le3AK048934 for ; Sat, 5 Dec 2009 21:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB5Le3FR048933; Sat, 5 Dec 2009 21:40:03 GMT (envelope-from gnats) Date: Sat, 5 Dec 2009 21:40:03 GMT Message-Id: <200912052140.nB5Le3FR048933@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 21:40:03 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Sat, 5 Dec 2009 16:30:35 -0500 (EST) On Sat, 5 Dec 2009, Benjamin Kaduk wrote: > > I'll update and revert my change to net80211/ieee80211_proto.c and > see what changes. Okay, now I only get a LOR on beacon miss (no panic): lock order reversal: 1st 0xffffff8000309010 iwn0 (network driver) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:2655 2nd 0xffffff800033d018 iwn0_com_lock (iwn0_com_lock) @ /usr/src/sys/net80211/ieee80211_proto.c:1365 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 ieee80211_beacon_miss() at ieee80211_beacon_miss+0x2e iwn_notif_intr() at iwn_notif_intr+0x33a iwn_intr() at iwn_intr+0x334 intr_event_execute_handlers() at intr_event_execute_handlers+0x66 ithread_loop() at ithread_loop+0xb2 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff803a97ed30, rbp = 0 --- I kind of expect that it's a bad idea to drop the softc lock around the call to ieee80211_beacom_miss() from iwn_notif_intr(), but don't see an easy alternative. More concerning, though, is the firmware error that was logged some twenty seconds after the beacon miss, leaving networking in an unuseable state: firmware error log: error type = "SYSASSERT" (0x00000005) program counter = 0x00001E28 source line = 0x00000696 error data = 0x0000000100000696 branch link = 0x000008FA000008FA interrupt link = 0x000008B200000000 time = 2190683577 driver status: tx ring 0: qid=0 cur=99 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=7 queued=0 tx ring 4: qid=4 cur=186 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=26 Hm, maybe I should move this to not-this-ticket ... -Ben