From owner-freebsd-net@FreeBSD.ORG Sun May 4 00:42:26 2008 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 5B28D106566C for ; Sun, 4 May 2008 00:42:26 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA408FC25 for ; Sun, 4 May 2008 00:42:24 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 8EBDD10256 for ; Sat, 3 May 2008 18:29:05 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 4BEB5CA96 for ; Sat, 3 May 2008 18:28:56 +0300 (EEST) Message-ID: <481C84B7.6020205@samoylyk.sumy.ua> Date: Sat, 03 May 2008 18:28:55 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Subject: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 00:42:26 -0000 Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 00:42:26 2008 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 5C4261065670 for ; Sun, 4 May 2008 00:42:26 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 86F0B8FC19 for ; Sun, 4 May 2008 00:42:24 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 2F7F7B81A for ; Sat, 3 May 2008 23:30:35 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 6FE4010166 for ; Sat, 3 May 2008 23:29:51 +0300 (EEST) Message-ID: <481CCB3E.9070302@samoylyk.sumy.ua> Date: Sat, 03 May 2008 23:29:50 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Subject: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 00:42:26 -0000 Hi! I'm running a SMP FreeBSD box with mpd5 on it. # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Somehow em0 begins to eat all CPU time of one core. # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq Everything is OK with outbound interface - em1. Current bandwidth - ~ 80 Mbit/s There are a lot of input errors on em0 (but no on em1): # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 8012 923 2838565 12504 0 7943345 0 7934 874 2469244 12555 0 7728764 0 7931 976 2712035 12482 0 8006760 0 8015 813 2694716 10669 0 7796656 0 7975 733 2475193 12306 0 8032129 0 7871 825 2548198 12269 0 7789452 0 8072 961 2647014 11924 0 7260788 0 7909 983 2576145 10552 0 7479881 0 ^C And systat -v looks strange with no interrupts on em0: 2 users Load 1.34 1.61 1.62 May 3 14:04 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 68152 9452 231584 11936 7786368 count All 108516 10676 4486380 15448 pages Proc: Interrupts r p d s w Csw Trp Sys Int Sof Flt 3981 cow 22705 total 47 46k 10k 268k 6697 23k 10k 3973 zfod atkbd0 1 ozfod ata0 irq14 18.3%Sys 2.3%Intr 1.8%User 0.0%Nice 77.6%Idle %ozfod atapci1 19 | | | | | | | | | | | daefr 2001 cpu0: time =========+> 5699 prcfr 2 em0 irq256 55 dtbuf 12110 totfr 6695 em1 irq257 Namei Name-cache Dir-cache 100000 desvn react 2001 cpu3: time Calls hits % hits % 4217 numvn pdwak 2001 cpu1: time 12005 12004 100 304 frevn pdpgs 2001 cpu2: time 13 intrn 2001 cpu4: time Disks ad4 232692 wire 2001 cpu5: time KB/t 0.00 60640 act 2001 cpu7: time tps 0 28784 inact 2001 cpu6: time MB/s 0.00 336 cache %busy 0 7786032 free 219632 buf Latency grows up to 400 ms: # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=17.619 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=27.497 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=16.481 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=24.535 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=13.058 ms ^C --- 10.0.0.1 ping statistics --- 6 packets transmitted, 5 packets received, 16.7% packet loss round-trip min/avg/max/stddev = 13.058/19.838/27.497/5.346 ms # top -S last pid: 55827; load averages: 3.76, 3.42, 3.08 up 0+03:27:38 16:24:20 104 processes: 11 running, 81 sleeping, 12 waiting CPU states: 1.7% user, 0.0% nice, 21.4% system, 3.0% interrupt, 73.9% idle Mem: 71M Active, 89M Inact, 340M Wired, 336K Cache, 214M Buf, 7418M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq 11 root 1 171 ki31 0K 16K CPU7 7 175:41 94.09% idle: cpu7 16 root 1 171 ki31 0K 16K CPU2 2 175:45 91.26% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 180:18 89.45% idle: cpu3 14 root 1 171 ki31 0K 16K CPU4 4 177:13 87.89% idle: cpu4 17 root 1 171 ki31 0K 16K CPU1 1 165:27 86.87% idle: cpu1 12 root 1 171 ki31 0K 16K CPU6 6 176:18 83.25% idle: cpu6 18 root 1 171 ki31 0K 16K RUN 0 157:44 80.66% idle: cpu0 611 root 6 58 0 133M 44320K select 0 0:00 66.26% mpd5 21 root 1 -44 - 0K 16K CPU4 4 48:38 21.39% swi1: net 30 root 1 -68 - 0K 16K - 6 21:41 10.25% em1 taskq # sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1096 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: -1 I've tried both: options SCHED_ULE options SCHED_4BSD I've added just the following lines in my kernel config: options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options NETGRAPH options NETGRAPH_PPP options NETGRAPH_PPTPGRE My sysctls: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.random_id=1 net.inet.ip.ttl=255 net.inet.ip.intr_queue_maxlen=4096 kern.maxfiles=131072 kern.maxfilesperproc=32768 kern.maxprocperuid=32768 kern.ipc.somaxconn=65535 kern.ipc.maxsockets=32768 kern.ipc.maxsockbuf=16777216 net.inet.tcp.rfc1323=1 net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=32768 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_auto=1 net.inet.tcp.sendbuf_inc=8192 net.inet.tcp.recvbuf_auto=1 net.inet.tcp.recvbuf_inc=16384 net.inet.tcp.maxtcptw=40960 net.inet.tcp.msl=2500 net.inet.tcp.delayed_ack=0 net.inet.tcp.nolocaltimewait=1 net.inet.udp.checksum=0 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.icmp.icmplim=30 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.isr.direct=1 kern.timecounter.hardware=TSC dev.em.0.rx_processing_limit=-1 If I set net.isr.direct to "0", than sw1: net begins to eat 100% of a core, but without errors: # netstat -w 1 -I em0 input (em0) output packets errs bytes packets errs bytes colls 6953 0 2860537 8703 0 4882814 0 6785 0 2587635 7683 0 4443958 0 7006 0 2576630 8718 0 4924591 0 6887 0 2652461 8272 0 4548049 0 6854 0 2610157 8689 0 5152459 0 6889 0 2586067 8265 0 5010795 0 6878 0 2586746 8255 0 4734959 0 ^C Moreover, with net.isr.direct=0 I can't create a PPTP tunnel. Please, help to solve the problem. Thanks! -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 04:46:20 2008 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 2FFAC106566B for ; Sun, 4 May 2008 04:46:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6758FC1D for ; Sun, 4 May 2008 04:46:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so9394wah.3 for ; Sat, 03 May 2008 21:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y4QX+Hj1Q5oO9guEVttHeQmcMkNbV4oFbGAARv2jfdE=; b=HSZfjVL/VdpQwD6SYugW4s3pA45iLcjo55OJ/uQSBiUvWiazGxfHlvNWU/g0/0qdUzUB473ww3JyF1DVP+A8MunFqd8AXjoJzTT1qBMaK5j4isPrlYOjitQMGmeBdyvaoaXwZWWnB642L1vBr1aG6HISiGkfna2A4Q9erQerhEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iOWZ5rurJlRH4M8HPrsZGb+xgYGGVg8hCpROsa/FUEakTXye6yQmiQNIuqZlz8qf1c6JAgX8j2IDSO6siZ7TXUht+8FF+oXOc3Um2AGoYEGmZjz4BhcQAtUs4KF7fku4Z8hkPi0OGa6ldX2ID02pYP8Fx/7DEWc/zUBL3LJGv+g= Received: by 10.115.108.1 with SMTP id k1mr4468181wam.14.1209876379714; Sat, 03 May 2008 21:46:19 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Sat, 3 May 2008 21:46:19 -0700 (PDT) Message-ID: Date: Sat, 3 May 2008 21:46:19 -0700 From: "Kip Macy" To: "freebsd-net@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: Planned contrib/rdma import 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: Sun, 04 May 2008 04:46:20 -0000 On Wed, Apr 16, 2008 at 5:47 PM, Kip Macy wrote: > I plan on committing the generic kernel level rdma verb and iwarp > infrastructure from OFED as well as the Chelsio iwarp driver to HEAD > next week. The RDMA infrastructure doesn't require any kernel changes > so I don't foresee any need for a lengthy discussion. For the most > part this does not include IB support. Nonetheless, for users that > want to add IB support this would be a good starting point. > > To optimally support user level RDMA would require some extension to > the mmap interface but this only supports rdma from the kernel at this > time. > > > The code in question that I plan to commit is at: > http://157.22.130.171/svn/branches/projects/iwarp/sys/contrib/rdma/ Due to some unforeseen events, I did not commit this when I intended to. I plan to finally commit this in the next day or two. -Kip From owner-freebsd-net@FreeBSD.ORG Sun May 4 09:13:01 2008 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 DD0EC1065674 for ; Sun, 4 May 2008 09:13:01 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from mail-out1.fuse.net (mail-out1.fuse.net [216.68.8.175]) by mx1.freebsd.org (Postfix) with ESMTP id AADF98FC1C for ; Sun, 4 May 2008 09:13:01 +0000 (UTC) (envelope-from jonathan@kc8onw.net) X-CNFS-Analysis: v=1.0 c=1 a=DTl47DImNrQA:15 a=tlCHpfXle7AA:10 a=R_1Sod5e6hMA:10 a=xUvkYoQocQKi/8Los98NoQ==:17 a=NUTUgPtKnhotR9SvR0QA:9 a=wRxoRSevKQFrvVnc1mueuLkJ1SAA:4 a=uZQnKKD9fRsA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Received: from [208.102.162.227] ([208.102.162.227:50973] helo=mail.kc8onw.net) by mail-out1.fuse.net (ecelerity 2.1.1.22 r(17669)) with ESMTP id AF/F4-13383-C1E7D184 for ; Sun, 04 May 2008 05:13:00 -0400 Received: from www.kc8onw.net (localhost [127.0.0.1]) by mail.kc8onw.net (Postfix) with ESMTP id 5156228415; Sun, 4 May 2008 05:13:00 -0400 (EDT) Received: from 80.91.220.50 (SquirrelMail authenticated user jonathan) by www.kc8onw.net with HTTP; Sun, 4 May 2008 05:13:00 -0400 (EDT) Message-ID: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> In-Reply-To: <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> Date: Sun, 4 May 2008 05:13:00 -0400 (EDT) From: jonathan@kc8onw.net To: "Jack Vogel" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory 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: Sun, 04 May 2008 09:13:01 -0000 [snip discussion] Sorry to all for the noise, turns out that with a motherboard BIOS update the card is recognized and initialized fine. For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I updated to the 1001 version. Jonathan Stewart From owner-freebsd-net@FreeBSD.ORG Sun May 4 11:25:14 2008 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 4B3921065673 for ; Sun, 4 May 2008 11:25:14 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 11ABB8FC22 for ; Sun, 4 May 2008 11:25:13 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 1651AB831 for ; Sun, 4 May 2008 14:25:11 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 4910AB828 for ; Sun, 4 May 2008 14:25:06 +0300 (EEST) Message-ID: <481D9D13.1040505@samoylyk.sumy.ua> Date: Sun, 04 May 2008 14:25:07 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> In-Reply-To: <481CF009.4050606@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 11:25:14 -0000 Oleksandr Samoylyk wrote: > Alexander Sack wrote: >> Oleksandr: >> >> Are you using DEVICE_POLLING by chance? If so, have you tried turning >> it off (ifconfig use -polling etc.)? Just curious. >> > > Surely, no :) > > # ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > options=19b > > > I'm just trying the same configuration on i386. > The same thing here (i386): PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 745 root 436 104 0 219M 67028K select 1 0:00 4845.65% mpd5 23 root 1 -68 - 0K 8K CPU1 0 333:40 100.00% em0 taskq -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 13:48:29 2008 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 DFA191065675 for ; Sun, 4 May 2008 13:48:29 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id AA90D8FC21 for ; Sun, 4 May 2008 13:48:29 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id B4E641B10EF4; Sun, 4 May 2008 15:48:27 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [10.1.1.2] (unknown [192.168.25.10]) by blah.sun-fish.com (Postfix) with ESMTP id A837D1B10ED2; Sun, 4 May 2008 15:48:24 +0200 (CEST) Message-ID: <481DBEA7.3050309@moneybookers.com> Date: Sun, 04 May 2008 16:48:23 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> In-Reply-To: <481D9D13.1040505@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/7019/Sun May 4 04:17:43 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 13:48:30 -0000 Oleksandr Samoylyk wrote: > Oleksandr Samoylyk wrote: >> Alexander Sack wrote: >>> Oleksandr: >>> >>> Are you using DEVICE_POLLING by chance? If so, have you tried turning >>> it off (ifconfig use -polling etc.)? Just curious. >>> >> >> Surely, no :) >> >> # ifconfig em0 >> em0: flags=8843 metric 0 mtu 1500 >> >> options=19b >> >> >> I'm just trying the same configuration on i386. >> > > The same thing here (i386): > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 745 root 436 104 0 219M 67028K select 1 0:00 4845.65% mpd5 > 23 root 1 -68 - 0K 8K CPU1 0 333:40 100.00% em0 > taskq > how many packets per second ? I've seen this only during syn floods :) Can you show the output of netstat -I em0 2 ? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Sun May 4 13:54:23 2008 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 53FD3106564A for ; Sun, 4 May 2008 13:54:23 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1CB4C8FC1D for ; Sun, 4 May 2008 13:54:22 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 009E2B884; Sun, 4 May 2008 16:54:21 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 69FD8B841; Sun, 4 May 2008 16:54:20 +0300 (EEST) Message-ID: <481DC00E.6050705@samoylyk.sumy.ua> Date: Sun, 04 May 2008 16:54:22 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> <481DBEA7.3050309@moneybookers.com> In-Reply-To: <481DBEA7.3050309@moneybookers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Lambrev Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 13:54:23 -0000 Stefan Lambrev wrote: > how many packets per second ? > I've seen this only during syn floods :) > > Can you show the output of netstat -I em0 2 ? > netstat -I em0 -w 1: input (em0) output packets errs bytes packets errs bytes colls 13440 0 5543030 17270 0 14214946 0 13330 0 5350865 16986 0 13916604 0 13802 0 5726053 17437 0 14234045 0 13383 0 5156923 17368 0 14865294 0 13526 0 5445259 16621 0 13465955 0 13034 0 5198973 16380 0 13649879 0 13562 0 5745386 17104 0 14474587 0 13606 0 5679775 16896 0 14090998 0 13204 0 5102628 16571 0 14323789 0 13266 0 5461232 16565 0 13667754 0 13598 0 5585068 16458 0 13642706 0 13427 0 5494987 16588 0 13605531 0 -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 18:40:42 2008 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 402B0106564A for ; Sun, 4 May 2008 18:40:42 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id DEE098FC21 for ; Sun, 4 May 2008 18:40:41 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 99D55B82F for ; Sun, 4 May 2008 21:40:40 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 51A9AB829 for ; Sun, 4 May 2008 21:40:26 +0300 (EEST) Message-ID: <481E031D.40300@samoylyk.sumy.ua> Date: Sun, 04 May 2008 21:40:29 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <912a71490805031516p3c35f419o62d614fc1649c48d@mail.gmail.com> <3c0b01820805031551m5444d986y9f51f67264643874@mail.gmail.com> <481CF009.4050606@samoylyk.sumy.ua> <481D9D13.1040505@samoylyk.sumy.ua> <481DBEA7.3050309@moneybookers.com> <481DC00E.6050705@samoylyk.sumy.ua> In-Reply-To: <481DC00E.6050705@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 18:40:42 -0000 Moreover, here is a result of profiling: granularity: each sample hit covers 16 byte(s) for 0.00% of 221.50 seconds called/total parents index %time self descendents called+self name index called/total children [1] 68.5 0.00 151.71 taskqueue_thread_loop [1] 0.02 145.30 1391229/1391229 taskqueue_run [2] 0.03 6.37 1391229/1391229 msleep_spin [39] ----------------------------------------------- 0.02 145.30 1391229/1391229 taskqueue_thread_loop [1] [2] 65.6 0.02 145.30 1391229 taskqueue_run [2] 0.16 143.27 1395192/1395192 em_handle_rxtx [3] 0.00 0.96 1395192/1412690 wakeup [119] 0.91 0.00 1395192/93426961 spinlock_exit [12] 0.00 0.00 1395192/39782518 spinlock_enter [173] 0.00 0.00 3/93426961 _mtx_lock_spin [933] ----------------------------------------------- 0.16 143.27 1395192/1395192 taskqueue_run [2] [3] 64.8 0.16 143.27 1395192 em_handle_rxtx [3] 1.00 136.80 1395192/1395192 em_rxeof [4] 0.35 4.74 1395192/1398898 em_txeof [50] 0.30 0.02 12711/749987 _mtx_lock_sleep [21] 0.03 0.00 1395192/1395192 em_enable_intr [333] 0.02 0.01 72300/4819861 em_start_locked [109] 0.00 0.01 2175/1395706 taskqueue_enqueue [47] 0.00 0.00 7/176995 _mtx_unlock_sleep [114] ----------------------------------------------- 1.00 136.80 1395192/1395192 em_handle_rxtx [3] [4] 62.2 1.00 136.80 1395192 em_rxeof [4] 0.68 133.48 3338526/3338526 ether_input [5] 0.14 2.50 3338526/3338526 em_get_buf [79] ----------------------------------------------- 0.68 133.48 3338526/3338526 em_rxeof [4] [5] 60.6 0.68 133.48 3338526 ether_input [5] 0.10 132.73 3338526/3338526 ether_demux [6] 0.15 0.36 3338526/3338700 random_harvest [142] 0.13 0.00 3338526/8161034 bcmp [165] ----------------------------------------------- 0.10 132.73 3338526/3338526 ether_input [5] [6] 60.0 0.10 132.73 3338526 ether_demux [6] 0.18 132.50 3338526/3338526 netisr_dispatch [7] 0.04 0.00 3338526/9831758 m_adj [216] 0.02 0.00 3336226/3336226 ip_fastforward [345] ----------------------------------------------- 0.18 132.50 3338526/3338526 ether_demux [6] [7] 59.9 0.18 132.50 3338526 netisr_dispatch [7] 0.89 131.60 4859336/4860183 ip_input [8] 0.00 0.01 2300/2300 arpintr [486] ----------------------------------------------- 0.00 0.02 847/4860183 netisr_processqueue [343] 0.89 131.60 4859336/4860183 netisr_dispatch [7] [8] 59.8 0.89 131.62 4860183 ip_input [8] 0.13 110.45 1642617/1642617 encap4_input [9] 0.42 17.79 3192274/3192274 ip_forward [22] 0.12 2.55 4860142/11299824 pfil_run_hooks [43] 0.01 0.08 8736/8736 tcp_input [224] 0.00 0.05 2331/2331 icmp_input [272] 0.00 0.01 20490/20490 ip_reass [381] 0.00 0.00 897/897 udp_input [692] 0.00 0.00 16/16 igmp_input [833] 0.00 0.00 41/8214484 m_freem [34] 0.00 0.00 22/6451824 in_cksum_skip [163] ----------------------------------------------- 0.13 110.45 1642617/1642617 ip_input [8] [9] 49.9 0.13 110.45 1642617 encap4_input [9] 93.07 17.27 1642617/1643247 rip_input [10] 0.11 0.00 3285234/40183056 generic_bzero [113] 0.01 0.00 3285234/40183057 bzero [219] ----------------------------------------------- 0.00 0.00 16/1643247 igmp_input [833] 0.03 0.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10] 49.8 93.10 17.27 1643247 rip_input [10] 14.26 0.88 600796/749987 _mtx_lock_sleep [21] 0.16 1.70 1643863/1643863 raw_append [93] 0.00 0.24 36345/176995 _mtx_unlock_sleep [114] 0.01 0.00 1643863/5117962 jailed [278] 0.00 0.00 1292/1843 m_copym [666] 0.00 0.00 676/8214484 m_freem [34] ----------------------------------------------- [11] 27.5 60.76 0.11 93426961+50755313 [11] 60.29 0.00 39782516 spinlock_exit [12] 0.23 0.10 14907668 _thread_lock_flags [164] 0.23 0.00 80459841 critical_exit [180] 0.00 0.02 4486040 sched_switch [380] 0.00 0.00 59579 _mtx_lock_spin [933] 0.00 0.00 295 thread_zombie [1331] 0.00 0.00 4486040 mi_switch [1415] 0.00 0.00 295 thread_stash [1661] ----------------------------------------------- 295 thread_zombie [1331] 52826 _mtx_lock_spin [933] 149280 _thread_lock_flags [164] 1197932 critical_exit [180] 2676133 sched_switch [380] 0.00 0.00 1/93426961 pmap_growkernel [1317] 0.00 0.00 3/93426961 smp_targeted_tlb_shootdown [1329] 0.00 0.00 4/93426961 kern_setitimer [1259] 0.00 0.00 6/93426961 kern_setrlimit [1064] 0.00 0.00 6/93426961 donice [1216] 0.00 0.00 6/93426961 sched_nice [1250] 0.00 0.00 7/93426961 thread_find [1294] 0.00 0.00 24/93426961 sc_draw_cursor_image [1195] 0.00 0.00 24/93426961 sc_puts [1173] 0.00 0.00 26/93426961 signotify [539] 0.00 0.00 30/93426961 turnstile_adjust_thread [1177] 0.00 0.00 47/93426961 pmap_pinit [1021] 0.00 0.00 70/93426961 thread_reap [568] 0.00 0.00 174/93426961 ioapic_enable_source [1017] 0.00 0.00 174/93426961 ioapic_disable_source [1016] 0.00 0.00 216/93426961 sched_balance [657] 0.00 0.00 272/93426961 calcru [555] 0.00 0.00 295/93426961 kse_unlink [976] 0.00 0.00 384/93426961 sleepq_switch [72] 0.00 0.00 565/93426961 sigqueue_delete_set_proc [928] 0.00 0.00 596/93426961 sleepq_remove [686] 0.00 0.00 607/93426961 doselwakeup [199] 0.00 0.00 1833/93426961 exec_setregs [634] 0.00 0.00 1986/93426961 create_thread [463] 0.00 0.00 2088/93426961 pcireg_cfgread [810] 0.00 0.00 2324/93426961 thread_wait [464] 0.00 0.00 2344/93426961 exit1 [209] 0.00 0.00 2344/93426961 cpu_exit [733] 0.00 0.00 2394/93426961 cpu_fork [687] 0.00 0.00 2405/93426961 tdsignal [591] 0.00 0.00 2639/93426961 sched_exit_thread [579] 0.00 0.00 2749/93426961 kern_select [428] 0.00 0.00 2934/93426961 thread_exit [436] 0.00 0.00 3054/93426961 fork_exit [530] 0.00 0.00 3066/93426961 upcall_reap [681] 0.00 0.00 3219/93426961 poll [341] 0.00 0.00 3454/93426961 random_kthread [150] 0.00 0.00 3456/93426961 lim_cb [541] 0.00 0.00 3940/93426961 turnstile_cancel [647] 0.00 0.00 4834/93426961 sleepq_wait_sig [362] 0.00 0.00 5050/93426961 scrn_update [583] 0.00 0.00 5384/93426961 ast [434] 0.00 0.00 5680/93426961 _callout_stop_safe [566] 0.00 0.00 6964/93426961 tdq_unlock_pair [540] 0.00 0.00 7182/93426961 fork1 [156] 0.00 0.00 7367/93426961 timeout [422] 0.01 0.00 8948/93426961 umtx_thread_cleanup [458] 0.01 0.00 9827/93426961 sleepq_timedwait [339] 0.01 0.00 10820/93426961 sysctl_kern_proc [185] 0.01 0.00 10921/93426961 sysctl_out_proc [190] 0.01 0.00 15008/93426961 sleepq_broadcast [120] 0.01 0.00 18153/93426961 smp_tlb_shootdown [403] 0.01 0.00 21842/93426961 fill_kinfo_proc_only [238] 0.02 0.00 26890/93426961 kern_wait [255] 0.02 0.00 34153/93426961 fill_kinfo_thread [223] 0.02 0.00 34153/93426961 rufetch [273] 0.02 0.00 34153/93426961 sched_pctcpu [275] 0.03 0.00 41180/93426961 sched_relinquish [232] 0.04 0.00 57525/93426961 statclock [234] 0.05 0.00 73748/93426961 ithread_loop [13] 0.10 0.00 156611/93426961 tdq_move [186] 0.11 0.00 176584/93426961 turnstile_chain_unlock [213] 0.11 0.00 176584/93426961 turnstile_broadcast [212] 0.14 0.00 216250/93426961 hardclock [133] 0.24 0.00 368000/93426961 propagate_priority [158] 0.27 0.00 419794/93426961 ipi_bitmap_handler [126] 0.28 0.00 432517/93426961 hardclock_cpu [136] 0.29 0.00 442303/93426961 random_harvest_internal [161] 0.36 0.00 551720/93426961 turnstile_wait [117] 0.38 0.00 578026/93426961 sched_idletd [130] 0.46 0.00 713661/93426961 turnstile_unpend [121] 0.65 0.00 1002645/93426961 sleepq_timedwait_sig [58] 0.66 0.00 1007663/93426961 _sleep [36] 0.66 0.00 1009514/93426961 sched_userret [108] 0.66 0.00 1011766/93426961 sleepq_timeout [80] 0.75 0.00 1154115/93426961 callout_reset [128] 0.80 0.00 1223669/93426961 softclock [55] 0.90 0.00 1391229/93426961 msleep_spin [39] 0.90 0.00 1391229/93426961 sleepq_signal [64] 0.91 0.00 1395192/93426961 taskqueue_run [2] 0.91 0.00 1395706/93426961 taskqueue_enqueue [47] 0.91 0.00 1401314/93426961 sleepq_wait [62] 1.31 0.00 2015712/93426961 sleepq_catch_signals [67] 1.55 0.00 2391125/93426961 intr_event_schedule_thread [70] 1.57 0.00 2419000/93426961 sleepq_add [73] 1.69 0.00 2602529/93426961 thread_lock_set [99] 1.74 0.00 2678939/93426961 thread_lock_unblock [97] 1.74 0.00 2678939/93426961 thread_lock_block [96] 1.83 0.00 2814166/93426961 sleepq_release [95] [12] 27.2 60.29 0.00 39782516 spinlock_exit [12] 39782516 critical_exit [180] ----------------------------------------------- [13] 13.2 0.02 29.15 ithread_loop [13] 0.00 24.78 2565/2565 swi_net [18] 0.04 4.19 79840/79840 softclock [55] 0.05 0.00 73748/93426961 spinlock_exit [12] 0.05 0.00 73746/93426961 _thread_lock_flags [164] 0.05 0.00 73604/93426961 mi_switch [1415] 0.00 0.00 348/348 ata_generic_intr [595] 0.00 0.00 174/174 ioapic_enable_source [1017] ----------------------------------------------- [14] 12.7 1.79 26.30 42212703+24208605 [14] 0.73 13.40 19134629 uma_zalloc_arg [23] 0.61 12.53 19122186 uma_zfree_arg [25] 0.11 0.00 9765739 mb_dtor_mbuf [217] 0.03 0.05 233015 pmap_enter [229] 0.08 0.00 11540146 m_tag_delete_chain [236] 0.02 0.04 48306 free [252] 0.02 0.03 3336409 mb_dtor_pack [257] 0.02 0.03 26102 vm_map_delete [258] 0.04 0.01 377027 vm_object_deallocate [262] 0.00 0.04 48083 malloc [267] 0.02 0.02 20817 vm_object_backing_scan [281] 0.00 0.04 41572 vm_map_insert [283] 0.02 0.02 200903 vm_page_free_toq [305] 0.00 0.02 143645 pmap_remove [366] 0.01 0.01 364837 vm_page_remove [378] 0.02 0.00 106608 pmap_remove_entry [390] 0.01 0.01 36267 vm_object_terminate [393] 0.00 0.01 163934 vm_page_rename [396] 0.00 0.01 47009 vm_object_allocate [401] 0.01 0.00 108872 vm_object_collapse [408] 0.01 0.00 116035 vrele [439] 0.01 0.00 290643 vdropl [494] 0.00 0.00 21555 getblk [517] 0.00 0.00 15381 _vm_map_clip_start [526] 0.00 0.00 39920 vm_map_simplify_entry [528] 0.00 0.00 42476 vinactive [538] 0.00 0.00 13881 vm_object_coalesce [543] 0.00 0.00 17436 vm_object_page_remove [559] 0.00 0.00 1666 kmem_malloc [560] 0.00 0.00 247351 v_decr_usecount [601] 0.00 0.00 9529 _vm_map_clip_end [602] 0.00 0.00 106608 free_pv_entry [608] 0.00 0.00 147290 vm_map_entry_create [614] 0.00 0.00 975 ffs_update [641] 0.00 0.00 23941 pmap_remove_pte [689] 0.00 0.00 41733 ufs_inactive [702] 0.00 0.00 145534 vm_map_entry_dispose [753] 0.00 0.00 42476 VOP_INACTIVE_APV [754] 0.00 0.00 1066 inodedep_lookup [756] 0.00 0.00 165 bufwrite [799] 0.00 0.00 365 free_unr [847] 0.00 0.00 6332 vm_map_remove [873] 0.00 0.00 742 alloc_unr [879] 0.00 0.00 742 thread_ctor [897] 0.00 0.00 420 thread_init [946] 0.00 0.00 73 allocbuf [967] 0.00 0.00 297 thread_dtor [972] 0.00 0.00 686 brelse [986] 0.00 0.00 168 g_vfs_strategy [993] 0.00 0.00 1622 slab_zalloc [1051] 0.00 0.00 80 proc_init [1070] 0.00 0.00 8 bufobj_invalbuf [1075] 0.00 0.00 50 getnewbuf [1176] 0.00 0.00 6 softdep_setup_freeblocks [1190] 0.00 0.00 87 softdep_disk_io_initiation [1204] 0.00 0.00 9 vfs_vmio_release [1227] 0.00 0.00 89 ffs_bufwrite [1257] 0.00 0.00 1248 uma_zalloc_internal [1356] 0.00 0.00 22 flushbuflist [1358] 0.00 0.00 184453 vm_page_free [1448] 0.00 0.00 8542 bread [1508] 0.00 0.00 8542 breadn [1510] 0.00 0.00 3076 uma_zone_slab [1554] 0.00 0.00 2176 mb_zinit_pack [1572] 0.00 0.00 1666 page_alloc [1587] 0.00 0.00 1150 clean_unrhdrl [1591] 0.00 0.00 945 softdep_update_inodeblock [1601] 0.00 0.00 733 vdrop [1609] 0.00 0.00 677 m_tag_delete [1612] 0.00 0.00 677 m_tag_free_default [1613] 0.00 0.00 651 vnode_pager_setsize [1618] 0.00 0.00 420 umtx_thread_init [1641] 0.00 0.00 420 umtxq_alloc [1642] 0.00 0.00 420 sleepq_alloc [1639] 0.00 0.00 420 turnstile_alloc [1640] 0.00 0.00 373 kmem_free [1651] 0.00 0.00 168 ffs_geom_strategy [1684] 0.00 0.00 168 g_alloc_bio [1685] 0.00 0.00 105 workitem_free [1694] 0.00 0.00 80 pstats_alloc [1706] 0.00 0.00 76 uma_large_free [1712] 0.00 0.00 76 page_free [1710] 0.00 0.00 76 bufstrategy [1709] 0.00 0.00 76 VOP_STRATEGY_APV [1708] 0.00 0.00 76 ufs_strategy [1711] 0.00 0.00 48 bucket_alloc [1729] 0.00 0.00 44 uma_large_malloc [1735] 0.00 0.00 33 handle_allocdirect_partdone [1746] 0.00 0.00 31 free_inodedep [1748] 0.00 0.00 28 brelvp [1755] 0.00 0.00 19 geteblk [1788] 0.00 0.00 17 softdep_change_linkcnt [1792] 0.00 0.00 8 vinvalbuf [1816] 0.00 0.00 7 free_allocdirect [1817] 0.00 0.00 6 ffs_truncate [1822] 0.00 0.00 2 vnode_destroy_vobject [1846] 0.00 0.00 2 softdep_releasefile [1843] 0.00 0.00 1 vrecycle [1866] 0.00 0.00 1 vgonel [1863] 0.00 0.00 1 VOP_RECLAIM_APV [1847] 0.00 0.00 1 ufs_reclaim [1861] 0.00 0.00 1 ffs_ifree [1854] 0.00 0.00 1 ffs_vfree [1855] 0.00 0.00 1 softdep_freefile [1858] 0.00 0.00 1 startup_alloc [1859] ----------------------------------------------- -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 18:42:15 2008 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 CD7C41065677 for ; Sun, 4 May 2008 18:42:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id B01A48FC19 for ; Sun, 4 May 2008 18:42:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so305340wah.3 for ; Sun, 04 May 2008 11:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qN7cS9xp/wX7V4fcgIEPsHUXDY/9954maraawUS+wRo=; b=Un0niwHB5VonzPn9qupH7A1XqViRqI57dLCnz0p73oIvNNe2SKul9oocidEzYArTiFwj1ujIbGaSQ+bvn9DVp6G2ehPvzxpEhcwDpIgyEvi5gOPe6AjXIiCdjnUaRzE/W8cCkbp3SAStGLw1ycyEiw+Z+npo7QcFne8FoMPLy9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h0S77hWcuAe4p8boYXbgsu7ueUZvyV9xgwweUp76lUKfaO2iGq+bcKu+6y24eIjpTZQBS0+hH3crjUU6NDVjLjWTjA4VQ8bA8aaMsB9c1QjkPI14Ve3VbiWTksIyUaI5JHPGiR238DGB3gg5Zt+sIOQDhIhibJLdfJdkPwDn3hQ= Received: by 10.114.191.1 with SMTP id o1mr4949259waf.117.1209926535261; Sun, 04 May 2008 11:42:15 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sun, 4 May 2008 11:42:15 -0700 (PDT) Message-ID: <2a41acea0805041142q286f605bm3bf2fac5065db246@mail.gmail.com> Date: Sun, 4 May 2008 11:42:15 -0700 From: "Jack Vogel" To: jonathan@kc8onw.net In-Reply-To: <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <58369.214.13.212.26.1209607888.squirrel@www.kc8onw.net> <48192D55.2080604@modulus.org> <2a41acea0804302109r35051d6rcfa99676b392310a@mail.gmail.com> <62563.214.13.212.26.1209617363.squirrel@www.kc8onw.net> <2a41acea0804302155x3d2a1ee0lbda2085fb0d347fe@mail.gmail.com> <55561.80.91.220.50.1209629829.squirrel@www.kc8onw.net> <2a41acea0805010934k4e3980b7w3927b57f9dd54ef6@mail.gmail.com> <58402.80.91.220.50.1209660616.squirrel@www.kc8onw.net> <2a41acea0805010954m3f6f4afdxd3a18a515e0a86e4@mail.gmail.com> <52635.80.91.220.50.1209892380.squirrel@www.kc8onw.net> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em1: Unable to allocate bus resource: memory 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: Sun, 04 May 2008 18:42:15 -0000 On Sun, May 4, 2008 at 2:13 AM, wrote: > [snip discussion] > > Sorry to all for the noise, turns out that with a motherboard BIOS update > the card is recognized and initialized fine. > > For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I > updated to the 1001 version. > > Jonathan Stewart Excellent, glad to hear that it now works, and thanks the most for getting back on this Jonathan, always good for future searching to have closure :) Jack From owner-freebsd-net@FreeBSD.ORG Sun May 4 21:51:02 2008 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 DEC7D106564A for ; Sun, 4 May 2008 21:51:02 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A95A98FC0A for ; Sun, 4 May 2008 21:51:02 +0000 (UTC) (envelope-from mike@sentex.net) Received: from Mobile2.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.14.2/8.14.2) with SMTP id m44Lp10R089004; Sun, 4 May 2008 17:51:01 -0400 (EDT) (envelope-from mike@sentex.net) From: mike@sentex.net To: Oleksandr Samoylyk Date: Sun, 04 May 2008 17:51:22 -0400 Message-ID: References: <481C84B7.6020205@samoylyk.sumy.ua> In-Reply-To: <481C84B7.6020205@samoylyk.sumy.ua> X-Mailer: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 21:51:02 -0000 On Sat, 03 May 2008 18:28:55 +0300, in sentex.lists.freebsd.net you wrote: >Hi! > >I'm running a SMP FreeBSD box with mpd5 on it. > ># uname -a >FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3=20 >12:40:02 EEST 2008 xxxxx@xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX= =20 > amd64 > ># mpd5 -v >Version 5.1 (root@xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > >Somehow em0 begins to eat all CPU time of one core. > A new version of the em drivers went into the tree Friday. >dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x108c subvendor=3D0x15d9 subdevice=3D0x108c class=3D0x020000 dev.em.0.%parent: pci13 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 Also, post some of the stats. Do a=20 sysctl -w dev.em.1.stats=3D1 to all of your em nics em1: Excessive collisions =3D 0 em1: Sequence errors =3D 0 em1: Defer count =3D 0 em1: Missed Packets =3D 0 em1: Receive No Buffers =3D 0 em1: Receive Length Errors =3D 0 em1: Receive errors =3D 0 em1: Crc errors =3D 0 em1: Alignment errors =3D 0 em1: Collision/Carrier extension errors =3D 0 em1: RX overruns =3D 0 em1: watchdog timeouts =3D 0 em1: RX MSIX IRQ =3D 0 TX MSIX IRQ =3D 0 LINK MSIX IRQ =3D 0 em1: XON Rcvd =3D 0 em1: XON Xmtd =3D 0 em1: XOFF Rcvd =3D 0 em1: XOFF Xmtd =3D 0 em1: Good Packets Rcvd =3D 71949 em1: Good Packets Xmtd =3D 2507 em1: TSO Contexts Xmtd =3D 369 em1: TSO Contexts Failed =3D 0 And are you using gigabit or fastE. If fastE, try disabling TSO as some people have said they have problems with it at 100Mb.=20 ---Mike From owner-freebsd-net@FreeBSD.ORG Sun May 4 21:58:28 2008 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 0A14B1065679 for ; Sun, 4 May 2008 21:58:28 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from gtcomm.net (web.gtcomm.net [72.10.164.67]) by mx1.freebsd.org (Postfix) with ESMTP id AE6078FC12 for ; Sun, 4 May 2008 21:58:27 +0000 (UTC) (envelope-from paul@gtcomm.net) Received: from [192.168.1.6] (c-76-108-179-28.hsd1.fl.comcast.net [76.108.179.28]) by gtcomm.net (8.12.20/8.12.10) with ESMTP id m44LwPSG004635 for ; Sun, 4 May 2008 18:58:25 -0300 Message-ID: <481E31E9.2080101@gtcomm.net> Date: Sun, 04 May 2008 18:00:09 -0400 From: Paul User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Network Patches from -RELEASE to -STABLE 7.0 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: Sun, 04 May 2008 21:58:28 -0000 Is there a list of patches that have been applied to -STABLE since the -RELEASE ? I can't seem to find a simple organized list of applied patches (something similar to linux kernel changelog). I want to know if anything has been fixed or udpated in the network area to see if it warrants changing the kernel to -STABLE on a production machine. Thank you From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:03:56 2008 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 007921065672 for ; Sun, 4 May 2008 22:03:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id C9D1D8FC17 for ; Sun, 4 May 2008 22:03:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id D7270104ACD; Sun, 4 May 2008 18:03:54 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 04 May 2008 18:03:54 -0400 X-Sasl-enc: 6o13nYEIv3Ch4LQa4PdT7YKc00h7Qvlb5l7W2a4Sq5Du 1209938634 Received: from empiric.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 5448E22D49; Sun, 4 May 2008 18:03:54 -0400 (EDT) Message-ID: <481E32C9.8010204@FreeBSD.org> Date: Sun, 04 May 2008 23:03:53 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Paul References: <481E31E9.2080101@gtcomm.net> In-Reply-To: <481E31E9.2080101@gtcomm.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Network Patches from -RELEASE to -STABLE 7.0 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: Sun, 04 May 2008 22:03:56 -0000 Paul wrote: > Is there a list of patches that have been applied to -STABLE since > the -RELEASE ? > I can't seem to find a simple organized list of applied patches > (something similar to linux kernel changelog). > I want to know if anything has been fixed or udpated in the network > area to see if it warrants changing the kernel to -STABLE on a > production machine. This information is typically present in commit messages, or in FreeBSD's release notes. It's not something which is compiled on an ad-hoc basis, it is specifically compiled on a per release basis, although you may occasionally see the release engineers updating the release notes for -CURRENT. Cheers BMS From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:07:14 2008 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 B122D1065675 for ; Sun, 4 May 2008 22:07:14 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6733D8FC16 for ; Sun, 4 May 2008 22:07:13 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id B16E9B829; Mon, 5 May 2008 01:07:11 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 37566B825; Mon, 5 May 2008 01:07:10 +0300 (EEST) Message-ID: <481E338D.6040706@samoylyk.sumy.ua> Date: Mon, 05 May 2008 01:07:09 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: mike@sentex.net References: <481C84B7.6020205@samoylyk.sumy.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 22:07:14 -0000 mike@sentex.net wrote: > > A new version of the em drivers went into the tree Friday. > >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > subdevice=0x108c class=0x020000 > dev.em.0.%parent: pci13 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 I tried both: - new drivers: 6.9.0 - rx_processing_limit: 100 Result the same :( > Also, post some of the stats. Do a > sysctl -w dev.em.1.stats=1 > to all of your em nics em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 434970 em0: Receive No Buffers = 290593 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 2929 em0: watchdog timeouts = 0 em0: XON Rcvd = 0 em0: XON Xmtd = 0 em0: XOFF Rcvd = 0 em0: XOFF Xmtd = 0 em0: Good Packets Rcvd = 64182304 em0: Good Packets Xmtd = 84277659 em0: TSO Contexts Xmtd = 832 em0: TSO Contexts Failed = 0 em1: Excessive collisions = 0 em1: Sequence errors = 0 em1: Defer count = 0 em1: Missed Packets = 0 em1: Receive No Buffers = 0 em1: Receive Length Errors = 0 em1: Receive errors = 0 em1: Crc errors = 0 em1: Alignment errors = 0 em1: Collision/Carrier extension errors = 0 em1: RX overruns = 0 em1: watchdog timeouts = 0 em1: XON Rcvd = 0 em1: XON Xmtd = 0 em1: XOFF Rcvd = 0 em1: XOFF Xmtd = 0 em1: Good Packets Rcvd = 62431510 m1: Good Packets Xmtd = 55466567 em1: TSO Contexts Xmtd = 0 em1: TSO Contexts Failed = 0 > And are you using gigabit or fastE. If fastE, try disabling TSO as > some people have said they have problems with it at 100Mb. I'm on GgE. Disabling TSO doesn't help as well. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:20:13 2008 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 EA64B1065676 for ; Sun, 4 May 2008 22:20:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id ABF278FC1B for ; Sun, 4 May 2008 22:20:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m44MKCEA046838; Sun, 4 May 2008 18:20:12 -0400 (EDT) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id m44MKCgK061568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 18:20:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200805042220.m44MKCgK061568@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 May 2008 18:22:20 -0400 To: Oleksandr Samoylyk From: Mike Tancsa In-Reply-To: <481E338D.6040706@samoylyk.sumy.ua> References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 22:20:14 -0000 At 06:07 PM 5/4/2008, Oleksandr Samoylyk wrote: I tried both: >- new drivers: 6.9.0 >- rx_processing_limit: 100 > >Result the same :( > >>Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1 >>to all of your em nics > >em0: Excessive collisions = 0 >em0: Sequence errors = 0 >em0: Defer count = 0 >em0: Missed Packets = 434970 >em0: Receive No Buffers = 290593 >em0: Receive Length Errors = 0 >em0: Receive errors = 0 >em0: Crc errors = 0 >em0: Alignment errors = 0 >em0: Collision/Carrier extension errors = 0 >em0: RX overruns = 2929 >em0: watchdog timeouts = 0 >em0: XON Rcvd = 0 >em0: XON Xmtd = 0 >em0: XOFF Rcvd = 0 >em0: XOFF Xmtd = 0 >em0: Good Packets Rcvd = 64182304 >em0: Good Packets Xmtd = 84277659 >em0: TSO Contexts Xmtd = 832 >em0: TSO Contexts Failed = 0 > >em1: Excessive collisions = 0 >em1: Sequence errors = 0 >em1: Defer count = 0 >em1: Missed Packets = 0 >em1: Receive No Buffers = 0 >em1: Receive Length Errors = 0 >em1: Receive errors = 0 >em1: Crc errors = 0 >em1: Alignment errors = 0 >em1: Collision/Carrier extension errors = 0 >em1: RX overruns = 0 >em1: watchdog timeouts = 0 >em1: XON Rcvd = 0 >em1: XON Xmtd = 0 >em1: XOFF Rcvd = 0 >em1: XOFF Xmtd = 0 >em1: Good Packets Rcvd = 62431510 >m1: Good Packets Xmtd = 55466567 >em1: TSO Contexts Xmtd = 0 >em1: TSO Contexts Failed = 0 > >>And are you using gigabit or fastE. If fastE, try disabling TSO as >>some people have said they have problems with it at 100Mb. > >I'm on GgE. Disabling TSO doesn't help as well. Perhaps time to engage the driver author for insight / help ---Mike From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:29:43 2008 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 541B2106566B for ; Sun, 4 May 2008 22:29:43 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 25CDC8FC16 for ; Sun, 4 May 2008 22:29:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so385466wah.3 for ; Sun, 04 May 2008 15:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DawQECcUudw19dpUDQIFdKlnLKz/c4bf0Bty/offn7M=; b=gMxkzTTeBD0lV19OwyFDvyfFOLfHRpdjR1fgmtLyGT5R+yv/zjQ22tEQrOIOGGaIUoZacUapllXy6G2a+TDvtZB5ivMWhIAE0gaevGYBb1uKm3hZ3d+Ij0r28tfO1poi6i7VkrlrOuEsDK/myDEroeIEI6qixGg7O7prbTSl+ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eb12qXWroE1u2SFBQUIBu3SBA7XQq1wWKCwcpkVtR2/khIoovcFVIG2qpmHw31NvxI1iA0fWNkUDWL+OkvrL/EzuMcmNrYuvc9sEnXQR1DjBF/Ubql4kfFpdUNrpgTbBrc6LVAj7rNtVUUmIzNTDJRNjUCtq3tiIBRokwcaiOoI= Received: by 10.114.12.9 with SMTP id 9mr5104668wal.23.1209940182664; Sun, 04 May 2008 15:29:42 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sun, 4 May 2008 15:29:42 -0700 (PDT) Message-ID: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> Date: Sun, 4 May 2008 15:29:42 -0700 From: "Jack Vogel" To: "Oleksandr Samoylyk" In-Reply-To: <481E338D.6040706@samoylyk.sumy.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> Cc: freebsd-net@freebsd.org, mike@sentex.net Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 22:29:43 -0000 On Sun, May 4, 2008 at 3:07 PM, Oleksandr Samoylyk wrote: > mike@sentex.net wrote: > > > > > A new version of the em drivers went into the tree Friday. > > > > > > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3 > > > > > > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0 > > dev.em.0.%driver: em > > dev.em.0.%location: slot=0 function=0 > > dev.em.0.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x15d9 > > subdevice=0x108c class=0x020000 > > dev.em.0.%parent: pci13 > > dev.em.0.debug: -1 > > dev.em.0.stats: -1 > > dev.em.0.rx_int_delay: 0 > > dev.em.0.tx_int_delay: 66 > > dev.em.0.rx_abs_int_delay: 66 > > dev.em.0.tx_abs_int_delay: 66 > > dev.em.0.rx_processing_limit: 100 > > > > I tried both: > > - new drivers: 6.9.0 > - rx_processing_limit: 100 > > Result the same :( > > > > > Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1 > > to all of your em nics > > > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 434970 > em0: Receive No Buffers = 290593 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 2929 > em0: watchdog timeouts = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 64182304 > em0: Good Packets Xmtd = 84277659 > em0: TSO Contexts Xmtd = 832 > em0: TSO Contexts Failed = 0 > > > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 0 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: RX overruns = 0 > em1: watchdog timeouts = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 62431510 > m1: Good Packets Xmtd = 55466567 > em1: TSO Contexts Xmtd = 0 > > em1: TSO Contexts Failed = 0 > > > > And are you using gigabit or fastE. If fastE, try disabling TSO as > > some people have said they have problems with it at 100Mb. > > > > I'm on GgE. Disabling TSO doesn't help as well. You are running out of RX side resources, did you say this was UDP? I'm guessing upping your mbuf pool at least, I can't think of something in driver-wise that would help. If you have this same load going into a different nic, or different os (like say Linux) can it manage? This will take some thought, I'm not sure off the top of my head here. Jack From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:32:17 2008 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 154671065676 for ; Sun, 4 May 2008 22:32:17 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id DA2BB8FC17 for ; Sun, 4 May 2008 22:32:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so386262wah.3 for ; Sun, 04 May 2008 15:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=gsB6YB4z8oE45n1691VXQ/yEVlgwKE051am1GchO+/A=; b=c159qwmblD7+Hion2t6/9Dw70fe74VL/gLwbpBnN93dhOLmf3x5vmeULV+XsHYS542I6GCJ4PfwOEhN97itj6FRRbQpSGmv6vCFAbQ2/98GtulDti1/6QcMRFWVxNyKs1J+VbH5GMqnnSJm4fKtPtD8i6eZU4GfbuDPwujes9jE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZKQHeT1hWhAFkDOFrCOFmFBVw0vAHspoeMu/YQfLm6e0j18Q9N7c0zdyn6YwSQ0SdpDkxXYxL5btFN3z0uy/YXj9Ay5J+/IJIv+TPJi/MbG6wOOHq+INXsz8QKHwjwpZJTmyVrG5RmQIODPI0FRlMwomV2tIJ43A0TL+1sqIsE0= Received: by 10.114.154.12 with SMTP id b12mr5077721wae.153.1209940336623; Sun, 04 May 2008 15:32:16 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Sun, 4 May 2008 15:32:16 -0700 (PDT) Message-ID: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Date: Sun, 4 May 2008 15:32:16 -0700 From: "Jack Vogel" To: "Oleksandr Samoylyk" In-Reply-To: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> Cc: freebsd-net@freebsd.org, mike@sentex.net Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 22:32:17 -0000 Oh, I just had a thought, increase the RX processing limit, that only allows you to process 100 packets in one pass. First change it to 250 and see what it does, you might also set it to -1 which will allow you to process til you drain the ring, the risk is that you cause other problems by doing that, but heck at this point anything is worth trying, right? Jack From owner-freebsd-net@FreeBSD.ORG Sun May 4 23:07:50 2008 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 39B93106566C for ; Sun, 4 May 2008 23:07:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id DD4998FC17 for ; Sun, 4 May 2008 23:07:49 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 0E680C0F4 for ; Mon, 5 May 2008 02:07:47 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, MISSING_HEADERS=1.581] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 76322BF09 for ; Mon, 5 May 2008 02:07:46 +0300 (EEST) Message-ID: <481E41C2.6020906@samoylyk.sumy.ua> Date: Mon, 05 May 2008 02:07:46 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 CC: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> In-Reply-To: <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 23:07:50 -0000 Jack Vogel wrote: > You are running out of RX side resources, did you say this > was UDP? I'm guessing upping your mbuf pool at least, I > can't think of something in driver-wise that would help. > > If you have this same load going into a different nic, or > different os (like say Linux) can it manage? Linux (latest 2.6.24, e1000 with NAPI) on the same hardware with same same tasks having been successfully coped with this load. I just wanted to move to FreeBSD in order to use mpd5 pptp-server with ng_car. I tried different (and new) Intel PRO 1000 NICs (PCI & PCI Express), but all the same. I'm trying to share load with separate adaptors (3 for LAN with deterrent IPs) and one for external interface (which nearly always eates much less CPU time). Vladimir Ivanov, the developer of SMPable version of EM driver, made a guess that this could be a problem with ng_* staff. I've: # kldstat Id Refs Address Size Name 1 13 0xffffffff80100000 760c78 kernel 2 1 0xffffffffae3bb000 8c73 ipfw.ko 3 1 0xffffffffae3ec000 19ba ng_socket.ko 4 10 0xffffffffae3ee000 8f14 netgraph.ko 7 1 0xffffffffae44f000 a9e ng_tee.ko 8 1 0xffffffffae450000 1a22 ng_pptpgre.ko 9 1 0xffffffffae452000 202a ng_ksocket.ko 10 1 0xffffffffae66c000 13a6 ng_iface.ko 11 1 0xffffffffae66e000 459e ng_ppp.ko 12 1 0xffffffffae678000 9e2 ng_tcpmss.ko 13 1 0xffffffffae45a000 1b24 ng_bpf.ko 14 1 0xffffffffae45c000 13be ng_car.ko 15 1 0xffffffffae4cd000 1ea4 ng_vjc.ko and I couple of ipfw rules (in order not to pass local traffic through the pptp-tunnels): deny ip from any to 10.0.0.0/8 via ng* deny ip from any to 172.16.0.0/12 via ng* deny ip from any to 192.168.0.0/16 via ng* deny ip from any to 224.0.0.0/3 via ng* deny ip from any to 169.254.0.0/16 via ng* Nothing less, nothing more :) -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 23:09:49 2008 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 7E4621065670 for ; Sun, 4 May 2008 23:09:49 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7308FC17 for ; Sun, 4 May 2008 23:09:49 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id D8D72BF09; Mon, 5 May 2008 02:09:47 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 88814B835; Mon, 5 May 2008 02:09:47 +0300 (EEST) Message-ID: <481E423B.2080400@samoylyk.sumy.ua> Date: Mon, 05 May 2008 02:09:47 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 23:09:49 -0000 Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > Tried that also, see my first post. My loader.conf has: hw.em.rxd="4096" -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sun May 4 23:16:47 2008 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 C0B131065671 for ; Sun, 4 May 2008 23:16:47 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7326C8FC1C for ; Sun, 4 May 2008 23:16:47 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 2C7BCBF09; Mon, 5 May 2008 02:16:46 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 9EC2CB840; Mon, 5 May 2008 02:16:45 +0300 (EEST) Message-ID: <481E43DD.8080300@samoylyk.sumy.ua> Date: Mon, 05 May 2008 02:16:45 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> In-Reply-To: <481E3C32.8000507@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Subject: Re: Troubles with em on FreeBSD 7 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: Sun, 04 May 2008 23:16:47 -0000 Paul wrote: > What is your kernel HZ setting? 1000 > in /boot/loader.conf try adding these two lines: > hw.em.rxd=1024 > hw.em.txd=1024 I've already had: # cat /boot/loader.conf loader_logo="beastie" autoboot_delay="3" hw.em.rxd="4096" hw.em.txd="4096" > and then do this in sysctl.conf: > net.inet.ip.intr_queue_maxlen=1024 - already > net.route.netisr_maxqlen=512 Ok. I just increased from default 256 up to 512 > kern.ipc.maxsockbuf=8388608 It was already higher > kern.ipc.nmbclusters=128000 Ok, I just increased nmbclusters. > > I think this should fix your packet loss problem. Are you doing ip > forwarding at all? If so use: > net.inet.ip.fastforwarding=1 It was already in my sysctl.conf -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:06:29 2008 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 993861065677; Mon, 5 May 2008 01:06:29 +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 64B898FC26; Mon, 5 May 2008 01:06:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4516TDS091674; Mon, 5 May 2008 01:06:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4516TjK091670; Mon, 5 May 2008 01:06:29 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:06:29 GMT Message-Id: <200805050106.m4516TjK091670@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/109733: [bge] bge link state issues [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: Mon, 05 May 2008 01:06:29 -0000 Synopsis: [bge] bge link state issues [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:06:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109733 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:06:54 2008 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 6545C106568A; Mon, 5 May 2008 01:06:54 +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 EA6B08FC14; Mon, 5 May 2008 01:06:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4516rHx091753; Mon, 5 May 2008 01:06:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4516rbt091749; Mon, 5 May 2008 01:06:53 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:06:53 GMT Message-Id: <200805050106.m4516rbt091749@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/109308: [pppd] [panic] Multiple panics kernel ppp suspected [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: Mon, 05 May 2008 01:06:54 -0000 Synopsis: [pppd] [panic] Multiple panics kernel ppp suspected [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:06:43 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=109308 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:07:42 2008 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 B6D681065678; Mon, 5 May 2008 01:07:42 +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 825A48FC27; Mon, 5 May 2008 01:07:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4517gxM091891; Mon, 5 May 2008 01:07:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4517gn7091887; Mon, 5 May 2008 01:07:42 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:07:42 GMT Message-Id: <200805050107.m4517gn7091887@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/108895: pppd(8): PPPoE dead connections on 6.2 [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: Mon, 05 May 2008 01:07:42 -0000 Synopsis: pppd(8): PPPoE dead connections on 6.2 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:07:34 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=108895 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:11:02 2008 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 5069C106564A; Mon, 5 May 2008 01:11:02 +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 1C2568FC12; Mon, 5 May 2008 01:11:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m451B2lU092355; Mon, 5 May 2008 01:11:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m451B2RH092351; Mon, 5 May 2008 01:11:02 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:11:02 GMT Message-Id: <200805050111.m451B2RH092351@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/105925: Regression in ifconfig(8) + vlan(4) [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: Mon, 05 May 2008 01:11:02 -0000 Synopsis: Regression in ifconfig(8) + vlan(4) [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:10:38 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=105925 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:16:19 2008 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 4ED93106566B; Mon, 5 May 2008 01:16:19 +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 18BC98FC16; Mon, 5 May 2008 01:16:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m451GImZ094285; Mon, 5 May 2008 01:16:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m451GIsu094281; Mon, 5 May 2008 01:16:18 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:16:18 GMT Message-Id: <200805050116.m451GIsu094281@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/91594: [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [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: Mon, 05 May 2008 01:16:19 -0000 Old Synopsis: FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-ort NIC in PCI slot 3 of DL380 G4 (regression) New Synopsis: [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-port NIC in PCI slot 3 of DL380 G4 [regression] Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:15:40 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=91594 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:41:09 2008 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 0FCFC106566C; Mon, 5 May 2008 01:41:09 +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 CE4458FC13; Mon, 5 May 2008 01:41:08 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m451f8R8098427; Mon, 5 May 2008 01:41:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m451f8Ra098423; Mon, 5 May 2008 01:41:08 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:41:08 GMT Message-Id: <200805050141.m451f8Ra098423@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122858: [nsswitch] nsswitch in 7.0 is f*cked up 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, 05 May 2008 01:41:09 -0000 Synopsis: [nsswitch] nsswitch in 7.0 is f*cked up Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:40:11 UTC 2008 Responsible-Changed-Why: Reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=122858 From owner-freebsd-net@FreeBSD.ORG Mon May 5 01:45:12 2008 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 05C4F1065670; Mon, 5 May 2008 01:45:12 +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 C305C8FC26; Mon, 5 May 2008 01:45:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m451jBMf098797; Mon, 5 May 2008 01:45:11 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m451jBDn098793; Mon, 5 May 2008 01:45:11 GMT (envelope-from linimon) Date: Mon, 5 May 2008 01:45:11 GMT Message-Id: <200805050145.m451jBDn098793@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119516: [ip6] [panic] _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /usr/src/sys/net/route.c:1287 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, 05 May 2008 01:45:12 -0000 Synopsis: [ip6] [panic] _mtx_lock_sleep: recursed on non-recursive mutex rtentry @ /usr/src/sys/net/route.c:1287 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 01:44:51 UTC 2008 Responsible-Changed-Why: This is probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=119516 From owner-freebsd-net@FreeBSD.ORG Mon May 5 05:41:33 2008 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 A1FC91065672 for ; Mon, 5 May 2008 05:41:33 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 264CE8FC1B for ; Mon, 5 May 2008 05:41:32 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id DF0F8B82B; Mon, 5 May 2008 08:41:30 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id BE58CB813; Mon, 5 May 2008 08:41:26 +0300 (EEST) Message-ID: <481E9E06.3040603@samoylyk.sumy.ua> Date: Mon, 05 May 2008 08:41:26 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel , mike@sentex.net Subject: Re: Troubles with em on FreeBSD 7 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, 05 May 2008 05:41:33 -0000 Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > last pid: 55326; load averages: 1.40, 1.24, 1.05 up 0+06:56:52 08:32:41 83 processes: 10 running, 60 sleeping, 13 waiting CPU states: 0.5% user, 0.0% nice, 10.5% system, 1.1% interrupt, 87.9% idle Mem: 42M Active, 265M Inact, 272M Wired, 244K Cache, 214M Buf, 7338M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K CPU6 6 413:05 100.00% idle: cpu6 16 root 1 171 ki31 0K 16K RUN 2 401:28 100.00% idle: cpu2 15 root 1 171 ki31 0K 16K CPU3 3 402:45 96.09% idle: cpu3 17 root 1 171 ki31 0K 16K CPU1 1 398:26 92.68% idle: cpu1 14 root 1 171 ki31 0K 16K CPU4 4 401:24 90.28% idle: cpu4 18 root 1 171 ki31 0K 16K CPU0 0 382:00 89.26% idle: cpu0 13 root 1 171 ki31 0K 16K CPU5 5 392:57 81.40% idle: cpu5 11 root 1 171 ki31 0K 16K CPU7 7 378:44 59.47% idle: cpu7 30 root 1 -68 - 0K 16K CPU7 7 37:24 44.78% em1 taskq 31 root 1 -68 - 0K 16K - 5 23:00 18.26% em2 taskq 19 root 1 -44 - 0K 16K WAIT 3 35:45 14.60% swi1: net 32 root 1 -68 - 0K 16K - 0 19:51 7.08% em3 taskq 722 root 2 5 0 68280K 21652K select 2 0:00 1.46% mpd5 20 root 1 -32 - 0K 16K WAIT 2 3:56 0.00% swi4: clock 29 root 1 -68 - 0K 16K - 6 2:53 0.00% em0 taskq 22 root 1 44 - 0K 16K - 1 0:49 0.00% yarrow I've added more NICs. The thing is that the most busiest interface is em3 (uplink) and it's just 7%. # netstat -I em0 -w 1 (just for the way back traffic) input (em0) output packets errs bytes packets errs bytes colls 13 0 2344 8408 0 4290811 0 20 0 2232 8147 0 4179926 0 12 0 1358 8204 0 3984088 0 33 0 5660 7982 0 3944704 0 25 0 3165 8183 0 4226968 0 10 0 1012 8620 0 4288722 0 25 0 2822 8283 0 4220019 0 ^C # netstat -I em1 -w 1 input (em1) output packets errs bytes packets errs bytes colls 7137 0 2618138 0 0 0 0 6772 0 2565885 0 0 0 0 6982 0 2430458 0 0 0 0 6758 0 2459663 0 0 0 0 7036 0 2665113 0 0 0 0 ^C # netstat -I em2 -w 1 input (em2) output packets errs bytes packets errs bytes colls 1237 0 327276 0 0 0 0 1158 0 328459 0 0 0 0 1243 0 346992 0 0 0 0 1076 0 323918 0 0 0 0 1242 0 363008 0 0 0 0 ^C # netstat -I em3 -w 1 input (em3) output packets errs bytes packets errs bytes colls 5681 0 3822499 6233 0 2443102 0 5958 0 4233009 6692 0 2354643 0 6202 0 4296877 6432 0 2455513 0 6117 0 4146643 6419 0 2327346 0 6324 0 4128040 6695 0 2468243 0 5856 0 4052255 6252 0 2445518 0 ^C Why so? -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Mon May 5 11:07:09 2008 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 F2FBD106568C for ; Mon, 5 May 2008 11:07:09 +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 DD1658FC24 for ; Mon, 5 May 2008 11:07:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m45B79wY070785 for ; Mon, 5 May 2008 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m45B79jf070781 for freebsd-net@FreeBSD.org; Mon, 5 May 2008 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2008 11:07:09 GMT Message-Id: <200805051107.m45B79jf070781@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, 05 May 2008 11:07:10 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109733 net [bge] bge link state issues [regression] o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122082 net [in_pcb] NULL pointer dereference in in_pcbdrop o kern/122195 net [ed] Alignment problems in if_ed f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix f kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar f kern/122858 net [nsswitch] nsswitch in 7.0 is f*cked up o kern/122875 net [nfs] "rstatd: Can't get namelist. 1" - fbsd 7.0-stabl o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/123123 net [re][patch] Realtek RTL8111C detection and failure f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123330 net [nsswitch] Enabling samba wins in nsswitch.conf causes 67 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122145 net error while compiling with device ath_rate_amrr o kern/122295 net [bge] bge Ierr rate increase (since 6.0R) [regression] o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122697 net [ath] Atheros card is not well supported o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge f kern/122839 net [multicast] FreeBSD 7 multicast routing problem f kern/122928 net [em] interface watchdog timeouts and stops receiving p o kern/123053 net [re][patch] re(4) unsupported hardware revision (8168/ o kern/123147 net [ti] [patch] ti(4) doesn't use mii, but kernel configs 45 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 5 11:23:43 2008 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 E483D1065674 for ; Mon, 5 May 2008 11:23:43 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7C31B8FC2E for ; Mon, 5 May 2008 11:23:42 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id E1B0DB80D; Mon, 5 May 2008 14:23:39 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id B5A31B83B; Mon, 5 May 2008 14:23:31 +0300 (EEST) Message-ID: <481EEE34.7060804@samoylyk.sumy.ua> Date: Mon, 05 May 2008 14:23:32 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Jack Vogel References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> In-Reply-To: <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, mike@sentex.net Subject: Re: Troubles with em on FreeBSD 7 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, 05 May 2008 11:23:44 -0000 Jack Vogel wrote: > Oh, I just had a thought, increase the RX processing limit, > that only allows you to process 100 packets in one pass. > > First change it to 250 and see what it does, you might > also set it to -1 which will allow you to process til you > drain the ring, the risk is that you cause other problems > by doing that, but heck at this point anything is worth > trying, right? > Nothing has helped. :( I need to unplug and plug in again patch cords each time when my CPUs with emX go 100% in order to keep my server alive with a descent pings. I mentioned that "100%: emX taskq" occurs only on that interfaces where GRE packets are being processed. External interface to Internet feels great. Pings are <0ms and load is 9.57% with 14kpps (input/output). Maybe interesting: According to kgmon: % cumulative self self total time seconds seconds calls ms/call ms/call name 39.9 93.10 93.10 1643247 0.06 0.07 rip_input [10] Is it em related or mpd related or something else? Back to releng_6? Not sure though. :( -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Mon May 5 13:29:39 2008 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 6F251106564A for ; Mon, 5 May 2008 13:29:39 +0000 (UTC) (envelope-from zinovik@kspu.karelia.ru) Received: from mail.kspu.karelia.ru (mail.kspu.karelia.ru [195.209.249.1]) by mx1.freebsd.org (Postfix) with ESMTP id 217298FC22 for ; Mon, 5 May 2008 13:29:38 +0000 (UTC) (envelope-from zinovik@kspu.karelia.ru) Received: from localhost (localhost.kspu.karelia.ru [127.0.0.1]) by mail.kspu.karelia.ru (Postfix) with ESMTP id 1F599B24205 for ; Mon, 5 May 2008 16:53:30 +0400 (MSD) X-Virus-Scanned: amavisd-new at kspu.karelia.ru Received: from mail.kspu.karelia.ru ([127.0.0.1]) by localhost (mail.kspu.karelia.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWyFpur84GYp for ; Mon, 5 May 2008 16:53:29 +0400 (MSD) Received: from localhost (zinovik.kspu.local [192.168.70.251]) by mail.kspu.karelia.ru (Postfix) with ESMTP id B5CDFB240F4 for ; Mon, 5 May 2008 16:53:29 +0400 (MSD) Date: Mon, 5 May 2008 15:49:38 +0400 From: Igor Zinovik To: freebsd-net@freebsd.org Message-ID: <20080505114938.GA34390@zinovik.kpsu.local> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Disposition: inline X-Comment-To: "Igor Zinovik" Subject: Trying to find source of collisions 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, 05 May 2008 13:29:39 -0000 Hello, net@ readers. I'm relatively new to freebsd networking so i'm asking here, because i did not found information in man netstat. I have a machine that suffers from collisions. Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 134590 ... rl0 1500 00:00:1c:dc:b8:d6 23455543 0 36137069 0 0 This is ordinary RELENG_6_1, with ed0 and rl0 acting as gateway. UTP cat5 is connected to both NICs. So i have three questions: 1. What can cause such big collisions number? Bad UTP cable? Bad NIC? Misbeheaving switch? 2. Ierr -- seems that some input errors. What are these errors and what can cause them? 3. Should i ever bother about this issue? From owner-freebsd-net@FreeBSD.ORG Mon May 5 13:38:03 2008 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 D33931065670 for ; Mon, 5 May 2008 13:38:03 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id 92C2A8FC0C for ; Mon, 5 May 2008 13:38:03 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Mon, 05 May 2008 09:39:46 -0400 id 00056412.481F0E22.0001130E Date: Mon, 5 May 2008 09:38:20 -0400 From: Bill Moran To: Igor Zinovik Message-Id: <20080505093820.ca62fa93.wmoran@collaborativefusion.com> In-Reply-To: <20080505114938.GA34390@zinovik.kpsu.local> References: <20080505114938.GA34390@zinovik.kpsu.local> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Trying to find source of collisions 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, 05 May 2008 13:38:03 -0000 In response to Igor Zinovik : > Hello, net@ readers. > > I'm relatively new to freebsd networking so i'm asking here, because i > did not found information in man netstat. I have a machine that suffers > from collisions. > > Network interface status: > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 134590 > ... > rl0 1500 00:00:1c:dc:b8:d6 23455543 0 36137069 0 0 > > This is ordinary RELENG_6_1, with ed0 and rl0 acting as gateway. UTP > cat5 is connected to both NICs. > > So i have three questions: > 1. What can cause such big collisions number? Bad UTP cable? Bad NIC? > Misbeheaving switch? Collisions are caused by a nearly saturated network. If you're seeing collisions, you need to either reduce the amount of traffic on that network segment, or increase the capacity of that segment. However, switches shouldn't have collisions. Either your switch isn't really a switch, or something else is wrong. > 2. Ierr -- seems that some input errors. What are these errors and what > can cause them? My first guess would be that you've got a duplex/speed mismatch between NIC and switch. If it's a managed switch, force the speed duplex on both the switch and the FreeBSD machine to ensure they match. If it's not a managed switch, replace it because it's not working correctly and there's nothing you can do about it. > 3. Should i ever bother about this issue? Yes. Something is wrong and it will be hurting your network performance. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From owner-freebsd-net@FreeBSD.ORG Mon May 5 15:14:03 2008 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 D6AB2106566C for ; Mon, 5 May 2008 15:14:03 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id A8CA28FC14 for ; Mon, 5 May 2008 15:14:03 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-147-233-204.jan.bellsouth.net [72.147.233.204]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTP id 4CF0337B46B; Mon, 5 May 2008 09:49:28 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id CC75561C41; Mon, 5 May 2008 09:49:27 -0500 (CDT) Date: Mon, 5 May 2008 09:49:27 -0500 From: "Matthew D. Fuller" To: Igor Zinovik Message-ID: <20080505144927.GW67042@over-yonder.net> References: <20080505114938.GA34390@zinovik.kpsu.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080505114938.GA34390@zinovik.kpsu.local> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.17-fullermd.4 (2007-11-01) X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Trying to find source of collisions 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, 05 May 2008 15:14:03 -0000 On Mon, May 05, 2008 at 03:49:38PM +0400 I heard the voice of Igor Zinovik, and lo! it spake thus: > > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > ed0 1500 00:80:48:c6:a1:82 35885806 4 23583716 0 > 134590 ... > > So i have three questions: > 1. What can cause such big collisions number? Bad UTP cable? Bad > NIC? Misbeheaving switch? That's not a particularly big number; it's half a percent of your output packets. That probably doesn't have a measurable effect on your throughput or latency. Now, that said, if you have a switch, you probably SHOULD be running full-duplex, in which case you won't have collisions. But you've got an ed card; some of those may be old enough to not handle FDX. > 2. Ierr -- seems that some input errors. What are these errors and > what can cause them? Cable troubles, NIC troubles, etc. [Un]plugging the cable can cause it. Some forms of on-wire data corruption could cause it. You've got 4 of them, over 36 million input packets. Don't worry about it. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Mon May 5 15:14:29 2008 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 EB2E7106566B for ; Mon, 5 May 2008 15:14:29 +0000 (UTC) (envelope-from ras@gerbil.cluepon.net) Received: from gerbil.cluepon.net (e-gerbil.net [69.31.1.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F0EE8FC14 for ; Mon, 5 May 2008 15:14:29 +0000 (UTC) (envelope-from ras@gerbil.cluepon.net) Received: from gerbil.cluepon.net (ras@localhost.nlayer.net [127.0.0.1]) by gerbil.cluepon.net (8.13.8/8.13.8) with ESMTP id m45GMPdY027267; Mon, 5 May 2008 11:22:25 -0500 (CDT) (envelope-from ras@gerbil.cluepon.net) Received: (from ras@localhost) by gerbil.cluepon.net (8.13.8/8.13.8/Submit) id m45GMPZW027266; Mon, 5 May 2008 11:22:25 -0500 (CDT) (envelope-from ras) Date: Mon, 5 May 2008 11:22:25 -0500 From: Richard A Steenbergen To: mike@sentex.net Message-ID: <20080505162225.GC4889@gerbil.cluepon.net> References: <481C84B7.6020205@samoylyk.sumy.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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, 05 May 2008 15:14:30 -0000 On Sun, May 04, 2008 at 05:51:22PM -0400, mike@sentex.net wrote: > A new version of the em drivers went into the tree Friday. Yes but it also broke kernel builds if you don't add device igb. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From owner-freebsd-net@FreeBSD.ORG Sun May 4 13:56:51 2008 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 0493F1065676 for ; Sun, 4 May 2008 13:56:51 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from mx1.81890.net (mx1.81890.net [210.74.224.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5314C8FC0A for ; Sun, 4 May 2008 13:56:50 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from [210.74.224.42] by [210.74.224.39] with StormMail ESMTP id 56504.1567993108; Sun, 4 May 2008 22:08:29 +0800 (CST) Received: from shtel.net.cn ([127.0.0.1]) by ims.shtel.net.cn (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0K0C0005NIYMRH@ims.shtel.net.cn> for freebsd-net@freebsd.org; Sun, 04 May 2008 21:32:46 +0800 (CST) Received: from [58.24.131.65] by ims.shtel.net.cn (mshttpd); Sun, 04 May 2008 21:32:46 +0800 Date: Sun, 04 May 2008 21:32:46 +0800 From: hlwhyw@shtel.net.cn To: freebsd-net@freebsd.org Message-id: <424543f9f5.3f9f542454@shtel.net.cn> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Mailman-Approved-At: Mon, 05 May 2008 16:23:13 +0000 Subject: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? 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: Sun, 04 May 2008 13:56:51 -0000 Hi, all Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? Kevin Wu From owner-freebsd-net@FreeBSD.ORG Sun May 4 15:56:55 2008 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 C32491065676 for ; Sun, 4 May 2008 15:56:55 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from mx1.81890.net (mx1.81890.net [210.74.224.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC9F8FC12 for ; Sun, 4 May 2008 15:56:54 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from [210.74.224.42] by [210.74.224.39] with StormMail ESMTP id 56504.1567993108; Mon, 5 May 2008 00:18:52 +0800 (CST) Received: from honglan ([58.24.132.80]) by ims.shtel.net.cn (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0K0C000NBOZXRE@ims.shtel.net.cn> for freebsd-net@freebsd.org; Sun, 04 May 2008 23:43:10 +0800 (CST) Date: Sun, 04 May 2008 23:56:33 +0800 From: kevin To: freebsd-net@freebsd.org Message-id: <001b01c8adff$6cd4cbd0$5084183a@honglan> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Mailman-Approved-At: Mon, 05 May 2008 16:24:09 +0000 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Is it possible to change BSD licence to GPL for 4.4BSD-Lite's source code? 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: Sun, 04 May 2008 15:56:55 -0000 Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:31:51 2008 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 3AAAB106566B for ; Sun, 4 May 2008 22:31:51 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from mx1.81890.net (mx1.gchahn.com.cn [210.74.224.39]) by mx1.freebsd.org (Postfix) with ESMTP id 90DFD8FC12 for ; Sun, 4 May 2008 22:31:49 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from [210.74.224.42] by [210.74.224.39] with StormMail ESMTP id 90148.1567993108; Mon, 5 May 2008 06:53:47 +0800 (CST) Received: from honglan ([58.24.132.80]) by ims.shtel.net.cn (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0K0D0008J7A3QR@ims.shtel.net.cn> for freebsd-net@freebsd.org; Mon, 05 May 2008 06:18:03 +0800 (CST) Date: Mon, 05 May 2008 06:31:25 +0800 From: kevin To: freebsd-net@freebsd.org Message-id: <001701c8ae36$96f0f560$5084183a@honglan> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Mailman-Approved-At: Mon, 05 May 2008 16:24:58 +0000 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Change from BSDL to GPL 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: Sun, 04 May 2008 22:31:51 -0000 Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From owner-freebsd-net@FreeBSD.ORG Sun May 4 22:43:32 2008 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 54ED4106564A for ; Sun, 4 May 2008 22:43:32 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from mx1.81890.net (mx1.gchahn.com.cn [210.74.224.39]) by mx1.freebsd.org (Postfix) with ESMTP id A9C038FC12 for ; Sun, 4 May 2008 22:43:31 +0000 (UTC) (envelope-from hlwhyw@shtel.net.cn) Received: from [210.74.224.42] by [210.74.224.39] with StormMail ESMTP id 90148.1567993108; Mon, 5 May 2008 07:05:30 +0800 (CST) Received: from honglan ([58.24.132.80]) by ims.shtel.net.cn (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0K0D000XA7TMRE@ims.shtel.net.cn> for freebsd-net@freebsd.org; Mon, 05 May 2008 06:29:46 +0800 (CST) Date: Mon, 05 May 2008 06:43:09 +0800 From: kevin Cc: freebsd-net@freebsd.org Message-id: <002e01c8ae38$3a343240$5084183a@honglan> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Mailman-Approved-At: Mon, 05 May 2008 16:25:08 +0000 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Change from BSDL to GPL 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: Sun, 04 May 2008 22:43:32 -0000 Hi, all I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. My OS kernel is GPL licenced. Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? BR Kevin Wu From owner-freebsd-net@FreeBSD.ORG Mon May 5 16:27:22 2008 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 39C0C106566B for ; Mon, 5 May 2008 16:27:22 +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 091BB8FC12 for ; Mon, 5 May 2008 16:27:21 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.11.16.99] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 05 May 2008 09:27:13 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C33CB2B1; Mon, 5 May 2008 09:27:13 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.11.18.52]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id ACA9F2B0; Mon, 5 May 2008 09:27:13 -0700 (PDT) Received: from mail-irva-13.broadcom.com (mail-irva-13.broadcom.com [10.11.16.103]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id GVS51604; Mon, 5 May 2008 09:27:13 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com (nt-irva-0751 [10.8.194.65]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 33E5774CFF; Mon, 5 May 2008 09:27:13 -0700 (PDT) Received: from IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) by NT-IRVA-0751.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 May 2008 09:27:13 -0700 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.9.200.129]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 5 May 2008 09:27:10 -0700 From: "David Christensen" To: "Alexander Sack" Date: Mon, 5 May 2008 09:27:10 -0700 Thread-Topic: Not All Symbols Present in a Loadable Kernel Module Thread-Index: AcitLROec8UcZgvYTCaLzY2hWtjZCQBmAlzg Message-ID: <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> In-Reply-To: <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 05 May 2008 16:27:13.0105 (UTC) FILETIME=[DFC80C10:01C8AECC] X-WSS-ID: 6401EAEB4E0225277-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: RE: Not All Symbols Present in a Loadable Kernel Module 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, 05 May 2008 16:27:22 -0000 > > Yes, I'm building a debug kernel. I have the line listed above as > well > > as the following: > > > > options KDB > > options DDB > > options GDB > > options INVARIANTS > > options INVARIANT_SUPPORT > > options WITNESS > > options WITNESS_SKIPSPIN > > Dave: > > What symbols can you not access exactly and how are you > installing/setting up debugging? > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > without a problem. I can examine them and call them. I'm not using > options GDB however, only KDB/DDB. > > I would: > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > generated/installed which contains the debug sections of your ko (from > the objcopy calls during the build - the binary is stripped with a > section pointer to the if_bce.ko.symbols file for debugging > information I believe) > - If you are using GDB, make sure its pointed to the right source base > so it can retrieve symbol information correctly > - If you are using GDB, stub it out and just use DDB to verify that > your build is sane (it works for me!) > - If all else fails, you can always build bce statically (just to move > forward etc.) - Enable the kernel debugger as described above - Build the driver in the /usr/src/sys/modules/bce directory with the command "make". - Run the command "nm if_bce.ko | grep dump_stat" in the same directory with the kernel module just built. In my case I only see a symbol for bce_dump_status_block, but there is a second routine called bce_dump_stats_block. In my working build there are 23 functions that start with "bce_dump" but only 8 are displayed with the command "nm if_bce.ko | grep bce_dump". Of course, I also get the symbol not present error when I try to use any of those missing symbols through a "call" command in the debugger. Dave From owner-freebsd-net@FreeBSD.ORG Mon May 5 16:32:59 2008 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 72C79106564A for ; Mon, 5 May 2008 16:32:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0218FC15 for ; Mon, 5 May 2008 16:32:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jt3cW-0008uP-PW for freebsd-net@freebsd.org; Mon, 05 May 2008 19:32:57 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45GWqeQ068970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 19:32:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m45GWnHQ013645; Mon, 5 May 2008 19:32:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m45GWn93013644; Mon, 5 May 2008 19:32:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 May 2008 19:32:49 +0300 From: Kostik Belousov To: David Christensen Message-ID: <20080505163249.GU18958@deviant.kiev.zoral.com.ua> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="so5AfiLIG9hb9aKM" Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: b11a0dd960b728cbee92fea3b4ac1d10 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2780 [May 05 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: Alexander Sack , "freebsd-net@freebsd.org" Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 05 May 2008 16:32:59 -0000 --so5AfiLIG9hb9aKM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > Yes, I'm building a debug kernel. I have the line listed above as > > well > > > as the following: > > > > > > options KDB > > > options DDB > > > options GDB > > > options INVARIANTS > > > options INVARIANT_SUPPORT > > > options WITNESS > > > options WITNESS_SKIPSPIN > > > > Dave: > > > > What symbols can you not access exactly and how are you > > installing/setting up debugging? > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > without a problem. I can examine them and call them. I'm not using > > options GDB however, only KDB/DDB. > > > > I would: > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > generated/installed which contains the debug sections of your ko (from > > the objcopy calls during the build - the binary is stripped with a > > section pointer to the if_bce.ko.symbols file for debugging > > information I believe) > > - If you are using GDB, make sure its pointed to the right source base > > so it can retrieve symbol information correctly > > - If you are using GDB, stub it out and just use DDB to verify that > > your build is sane (it works for me!) > > - If all else fails, you can always build bce statically (just to move > > forward etc.) >=20 > - Enable the kernel debugger as described above > - Build the driver in the /usr/src/sys/modules/bce directory with the > command "make". > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > with the kernel module just built. >=20 > In my case I only see a symbol for bce_dump_status_block, but there is a > second routine called bce_dump_stats_block. In my working build there > are 23 functions that start with "bce_dump" but only 8 are displayed with > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > symbol not present error when I try to use any of those missing symbols > through a "call" command in the debugger. Most likely, they are optimized out, gcc likes to inline once-called static functions. Aside from playing with the optimization options, the easiest way seems to use functions somewhere else, e.g., put the addresses into some table. Just guessing. --so5AfiLIG9hb9aKM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgfNrAACgkQC3+MBN1Mb4jvtACbB4Z0pjNk6umgyYCM6qFrc9Bh 6e8AoOt11f12NIIUCj4i4O4vVrALSl2l =RRrF -----END PGP SIGNATURE----- --so5AfiLIG9hb9aKM-- From owner-freebsd-net@FreeBSD.ORG Mon May 5 16:35:49 2008 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 AB25F1065677 for ; Mon, 5 May 2008 16:35:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1208FC19 for ; Mon, 5 May 2008 16:35:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2374638rvf.43 for ; Mon, 05 May 2008 09:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1EsS4fSv5z3Du+jzycaTAWPjEs+qGr23j0zPh03jpqQ=; b=XnoUsDFmAdvdF60LoEMqMeaDQFyAMt7Q++9vlKa7SXyHUakxQl3w5TdRA+zcY/C5tHavh99cjMJpmuISYLXP7HEkU+nCeEqkmwltGP+EcrKaeDVpxIKGOhsXrTcuqmPfVVLoDtyLrO/6sSyBPXaYlgxor1JXpzQQx7biZ7pGNSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W1/DtHaFwDyuRYw0/qRoZ9JUy6gSIc/mOjyYI4f6oK9Uo9DyVqyaj8hcaJSIKOJ7yc4r8Vk6gQe/E5zRCIgkkUyblP69ghM0JgXp9y9Wvd6r2/Z+Js6jeuHYfZYFvm2xDsTxD3TMqFWnUy8uhcC70fD+Qga9mETkUI2YqWsSuvI= Received: by 10.114.154.1 with SMTP id b1mr5917662wae.34.1210005349150; Mon, 05 May 2008 09:35:49 -0700 (PDT) Received: by 10.114.177.4 with HTTP; Mon, 5 May 2008 09:35:49 -0700 (PDT) Message-ID: <2a41acea0805050935g28e85c68g5cbdda6fbf1e0b02@mail.gmail.com> Date: Mon, 5 May 2008 09:35:49 -0700 From: "Jack Vogel" To: "Richard A Steenbergen" In-Reply-To: <20080505162225.GC4889@gerbil.cluepon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481C84B7.6020205@samoylyk.sumy.ua> <20080505162225.GC4889@gerbil.cluepon.net> Cc: freebsd-net@freebsd.org, mike@sentex.net Subject: Re: Troubles with em on FreeBSD 7 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, 05 May 2008 16:35:49 -0000 On Mon, May 5, 2008 at 9:22 AM, Richard A Steenbergen wrote: > On Sun, May 04, 2008 at 05:51:22PM -0400, mike@sentex.net wrote: > > A new version of the em drivers went into the tree Friday. > > Yes but it also broke kernel builds if you don't add device igb. :) Only for one pass of the build, I fixed that Friday night. Jack From owner-freebsd-net@FreeBSD.ORG Mon May 5 16:55:24 2008 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 6055B1065675 for ; Mon, 5 May 2008 16:55:24 +0000 (UTC) (envelope-from SRS0=f62761d9b7ead03627f3c82f6e779bc11a149b4d=692=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id D7DD98FC1F for ; Mon, 5 May 2008 16:55:23 +0000 (UTC) (envelope-from SRS0=f62761d9b7ead03627f3c82f6e779bc11a149b4d=692=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id LVI35822; Mon, 05 May 2008 09:55:22 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6D92145010; Mon, 5 May 2008 09:55:22 -0700 (PDT) To: kevin In-Reply-To: Your message of "Sun, 04 May 2008 23:56:33 +0800." <001b01c8adff$6cd4cbd0$5084183a@honglan> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1210006522_38027P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 05 May 2008 09:55:22 -0700 From: "Kevin Oberman" Message-Id: <20080505165522.6D92145010@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ;; X-Sender: X-To_Name: kevin X-To_Domain: 81890.net X-To: kevin X-To_Email: hlwhyw@81890.net X-To_Alias: hlwhyw Cc: freebsd-net@freebsd.org Subject: Re: Is it possible to change BSD licence to GPL for 4.4BSD-Lite's source code? 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, 05 May 2008 16:55:24 -0000 --==_Exmh_1210006522_38027P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 04 May 2008 23:56:33 +0800 > From: kevin > Sender: owner-freebsd-net@freebsd.org > > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change > its licence from 4.4BSD-Lite licence to GPL licence? I am not a lawyer, but it is generally not possible to re-license BSD code to GPL. It might be possible, with the permission of the code's author(s), to dual license it under both BSD and GPL. It is unclear to me why adding BSD code to a GPL OS would violate any of the terms of either license as ling as you maintain the copyright notice for the BSD code and follow the GPL redistribution rules and other conditions. I don't believe that anything in GPL prohibits the use of non-GPL code as long as the terms of the GPL are adhered to. Finally, 4.4BSD-Lite is very, very old and lacks a great many features needed in a modern network stack. I really don't see why you would want to do this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1210006522_38027P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIHzv6kn3rs5h7N1ERAqjSAJ0cfSzSXCAz5RYQxZGoJq4LaqS4jACeJR1D GbUeJKddzy1pr/xPbfXxo/0= =tRo3 -----END PGP SIGNATURE----- --==_Exmh_1210006522_38027P-- From owner-freebsd-net@FreeBSD.ORG Mon May 5 18:00:01 2008 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 85D0D106566B for ; Mon, 5 May 2008 18:00:01 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADE38FC0A for ; Mon, 5 May 2008 18:00:01 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so838863wah.3 for ; Mon, 05 May 2008 11:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=alrYR4Z9qCWPrTXeJ3XkylTclGyFa2fLPEMmYhTmQDY=; b=Zhed1Nsqe5TrQWGME5E7wj/dY8F7ojptd3cdmw8NOYcfMpTLievPdS4KVq40hrDCULVX9Bn4vhh/yrifOYDlKy/G1H3vnYb7gDnXLu622fpk79Fp0TsbrjmWZLKZmMfJjzpM46McLcY+wNdSYBdV8i0eofqZtnoGqzcPRFlc3Zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NfeWiQ4GUiZl54YDlzWrX2fZ9lUiO3ijVOAyaVwUk1SGcm5DxB0K9pWTFwD0gif+9QD5gklvZua6RIdiR9Y0uy43gdxfmDtKOArjaEwEjOZyv4gPPVaPXEbwQVufwGbZ1X9UdYGwsTfdKigz25NN1F/u3eQTGzqLh7YpfsnYbTg= Received: by 10.114.173.15 with SMTP id v15mr6010631wae.63.1210010400926; Mon, 05 May 2008 11:00:00 -0700 (PDT) Received: by 10.115.22.10 with HTTP; Mon, 5 May 2008 11:00:00 -0700 (PDT) Message-ID: Date: Mon, 5 May 2008 11:00:00 -0700 From: "Kip Macy" To: hlwhyw@shtel.net.cn In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <424543f9f5.3f9f542454@shtel.net.cn> Cc: freebsd-net@freebsd.org Subject: Re: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? 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, 05 May 2008 18:00:01 -0000 On Sun, May 4, 2008 at 6:32 AM, wrote: > Hi, all > > Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? > > I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? Yes. BSD licensed code can, by definition, be included in software with any license. The only restriction is that you cannot change the license of the code without permission of the copyright holder. However, I see no reason to do that. -Kip From owner-freebsd-net@FreeBSD.ORG Mon May 5 18:07:01 2008 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 431BA1065675 for ; Mon, 5 May 2008 18:07:01 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id EB71B8FC15 for ; Mon, 5 May 2008 18:07:00 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so504864ywe.13 for ; Mon, 05 May 2008 11:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NMVOUW+lCFxAfSNZHjTtRxyGhQmrtvtUjW7qqQWjGsg=; b=lDcIZJW88EjWNYuSQ31qjz6P7Qt4ykMYGNMjaN/3ulDaP7mW/HjfJURvDUWTcvqDrZiwtTXLpf5VSd1kAhZ6x7xylwo+a26JMc7hv7CnO6BUuEfJ2RZJiIDAH8s47Or3UvJDU7YY2eAtrbwS1u2W9yZw5Q7zFeYsShARHSDQMk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HkZWjSGlN7Y8SU3pRdz6RIIc88sjmPghjVn+1YVB5bVInVVsKxN5bj9lsqvEUBrONA+YZAxLAKeJBJV/VFpwvjuVCZ2S3G+p7263je9sGuwZ+/42iqHahLbPQAcDxVd+R/AX3NlyMBrMh4hzjhnrHG8z89LBBfg5GwbTYJqahPs= Received: by 10.150.49.1 with SMTP id w1mr6361181ybw.4.1210010815000; Mon, 05 May 2008 11:06:55 -0700 (PDT) Received: by 10.151.11.1 with HTTP; Mon, 5 May 2008 11:06:54 -0700 (PDT) Message-ID: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Date: Mon, 5 May 2008 14:06:54 -0400 From: "Alexander Sack" To: "Kostik Belousov" In-Reply-To: <20080505163249.GU18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> Cc: "freebsd-net@freebsd.org" , David Christensen Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 05 May 2008 18:07:01 -0000 For my own edification, unless you specifically mark a function inline, will gcc really optimize them out? That seems a little overboard unless there is some compiler option that says its okay to do that. I guess that would be very easy to test if you do as you say, just sock away the function address pointer somewhere and you should be okay... -aps On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov wrote: > > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > > Yes, I'm building a debug kernel. I have the line listed above as > > > well > > > > as the following: > > > > > > > > options KDB > > > > options DDB > > > > options GDB > > > > options INVARIANTS > > > > options INVARIANT_SUPPORT > > > > options WITNESS > > > > options WITNESS_SKIPSPIN > > > > > > Dave: > > > > > > What symbols can you not access exactly and how are you > > > installing/setting up debugging? > > > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > > without a problem. I can examine them and call them. I'm not using > > > options GDB however, only KDB/DDB. > > > > > > I would: > > > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > > generated/installed which contains the debug sections of your ko (from > > > the objcopy calls during the build - the binary is stripped with a > > > section pointer to the if_bce.ko.symbols file for debugging > > > information I believe) > > > - If you are using GDB, make sure its pointed to the right source base > > > so it can retrieve symbol information correctly > > > - If you are using GDB, stub it out and just use DDB to verify that > > > your build is sane (it works for me!) > > > - If all else fails, you can always build bce statically (just to move > > > forward etc.) > > > > - Enable the kernel debugger as described above > > - Build the driver in the /usr/src/sys/modules/bce directory with the > > command "make". > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > > with the kernel module just built. > > > > In my case I only see a symbol for bce_dump_status_block, but there is a > > second routine called bce_dump_stats_block. In my working build there > > are 23 functions that start with "bce_dump" but only 8 are displayed with > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > > symbol not present error when I try to use any of those missing symbols > > through a "call" command in the debugger. > > Most likely, they are optimized out, gcc likes to inline once-called > static functions. Aside from playing with the optimization options, > the easiest way seems to use functions somewhere else, e.g., put the > addresses into some table. Just guessing. > From owner-freebsd-net@FreeBSD.ORG Mon May 5 18:20:22 2008 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 865D71065677 for ; Mon, 5 May 2008 18:20:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (unknown [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA798FC19 for ; Mon, 5 May 2008 18:20:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 46DF828449 for ; Tue, 6 May 2008 02:20:21 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id CF9C3EB6DB6; Tue, 6 May 2008 02:20:20 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id 4MDHMUzgKEBg; Tue, 6 May 2008 02:20:16 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 391C5EB096A; Tue, 6 May 2008 02:20:12 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=eqeHUFcFuX8mlfzhgUudorrZ5/yU0VsMKBDWxlWVdc4VW0kzxwjJCb15z0cIvMQbM qqZzuoi95St4dWHu6i98w== Message-ID: <481F4FD7.1000609@delphij.net> Date: Mon, 05 May 2008 11:20:07 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: hlwhyw@shtel.net.cn References: <424543f9f5.3f9f542454@shtel.net.cn> In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2008 18:20:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hlwhyw@shtel.net.cn wrote: | Hi, all | | Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? | | I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? I think this is a complex issue, you'd better ask a lawyer who is an expert in copyright affairs. For pure 4.4-BSD Lite, the license is 4-clause BSD license, and the advertisement clause was removed exactly because FSF claims that it would prevent people from being able to combine BSD licensed code with GPL licensed ones, therefore, it is legal to combine 4.4-BSD Lite code with GPL code. However, it is illegal to change license, if you are not the sole copyright holder of the code. There is no point to do this anyway. On the other hand, why not just use some FreeBSD code for your product instead? Let us know if there is some limitation/lack of functionality? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgfT9cACgkQi+vbBBjt66D+8ACbB1VhjNZS8ZvJHr4TuuGQoVYS JGoAoLHukH9mq/hZP219La3jTtwp0CM4 =Aosf -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon May 5 18:22:23 2008 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 17D8E10656AE for ; Mon, 5 May 2008 18:22:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id F36918FC23 for ; Mon, 5 May 2008 18:22:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 05 May 2008 19:24:07 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0B00C2D601B; Mon, 5 May 2008 11:22:21 -0700 (PDT) Message-ID: <481F505F.5010103@elischer.org> Date: Mon, 05 May 2008 11:22:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Kip Macy References: <424543f9f5.3f9f542454@shtel.net.cn> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hlwhyw@shtel.net.cn, freebsd-net@freebsd.org Subject: Re: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? 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, 05 May 2008 18:22:23 -0000 Kip Macy wrote: > On Sun, May 4, 2008 at 6:32 AM, wrote: >> Hi, all >> >> Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licence? >> >> I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced code and change it to GPL licence? > > Yes. BSD licensed code can, by definition, be included in software > with any license. The only restriction is that you cannot change the > license of the code without permission of the copyright holder. > However, I see no reason to do that. so, the full answer is: From the BSD perspective, you can use the code as long as you don't change the copyright or say that you wrote it. We don't care what you link it with.. However from the GPL perspective, they will not let you link the BSD code with GPL code because they will not allow "additional limitations" and there is a clause in the BSD 4.4.-lite copyright that they consider to be an additional limitation. (The advertising clause). Some of the newer BSD code has dropped that clause and teh UC regents have announced they have released users from one of the clauses so it may be better to look at more up to date versions of the code. I do understand however that the original code is smaller and cleaner. > > -Kip > _______________________________________________ > 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 May 5 18:53:16 2008 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 54DCE106566B for ; Mon, 5 May 2008 18:53:16 +0000 (UTC) (envelope-from yusheng.huang@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 380448FC18 for ; Mon, 5 May 2008 18:53:15 +0000 (UTC) (envelope-from yusheng.huang@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id m45IrFbv020328 for ; Mon, 5 May 2008 11:53:15 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 May 2008 11:53:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: timewait state memory leak Thread-Index: Aciu4UPtf0sc4T2ISA+yOzz5gzFzbw== From: "Huang, Yusheng" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: timewait state memory leak 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, 05 May 2008 18:53:16 -0000 Hi, =20 I am looking at the tcp_tw_2msl_scan() code and it looks like there is a bug in there. =20 struct tcptw * tcp_tw_2msl_scan(int reuse) { struct tcptw *tw; =20 INP_INFO_WLOCK_ASSERT(&tcbinfo); for (;;) { tw =3D TAILQ_FIRST(&twq_2msl); if (tw =3D=3D NULL || (!reuse && tw->tw_time > ticks)) ^^^^^^^^^^^^^^^^^^ break; INP_WLOCK(tw->tw_inpcb); tcp_twclose(tw, reuse); if (reuse) return (tw); } return (NULL); } =20 Shouldn't the comparison be TSTMP_GT(tw->tw_time, ticks)?=20 =20 -yusheng =20 From owner-freebsd-net@FreeBSD.ORG Mon May 5 19:18:32 2008 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 A8152106567F for ; Mon, 5 May 2008 19:18:32 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from mon.jinmei.org (mon.jinmei.org [IPv6:2001:4f8:3:36::162]) by mx1.freebsd.org (Postfix) with ESMTP id 99E6F8FC14 for ; Mon, 5 May 2008 19:18:32 +0000 (UTC) (envelope-from Jinmei_Tatuya@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:bb:217:f2ff:fee0:a91f]) by mon.jinmei.org (Postfix) with ESMTP id 32B3133C2E; Mon, 5 May 2008 12:18:32 -0700 (PDT) Date: Mon, 05 May 2008 12:18:32 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edwin Groothuis In-Reply-To: <20080503100043.GA68835@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 05 May 2008 19:18:32 -0000 At Sat, 3 May 2008 20:00:43 +1000, Edwin Groothuis wrote: > Before somebody shoots me down on it: I know that ipfw_divert() is > not suitable for IPv6 packets. [snip] > which is what I expected. So why doesn't this get displayed for the > IPv6 sockets? I don't know much about IPDIVERT, but it seems to me this is simply because the IPv6 stack (sys/netinet6) doesn't support divert sockets. So opening an AF_INET6 socket with the protocol being IPPROTO_DIVERT (which is "unknown") sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); matches a wildcard protosw /* raw wildcard */ { .pr_type = SOCK_RAW, .pr_domain = &inet6domain, .pr_flags = PR_ATOMIC|PR_ADDR, .pr_input = rip6_input, .pr_output = rip6_output, .pr_ctloutput = rip6_ctloutput, .pr_usrreqs = &rip6_usrreqs }, whose pr_protocol is implicitly set to 0, which is (accidentally) interpreted by lsof as "HOPOPTS". This should provide a direct answer to you question of "why"? But I suspect the underlying question is why divert sockets aren't supported for IPv6. I don't know why. --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Mon May 5 20:15:03 2008 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 828CF106566C for ; Mon, 5 May 2008 20:15:03 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 041E68FC27 for ; Mon, 5 May 2008 20:15:02 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 4525C1005D for ; Mon, 5 May 2008 23:14:59 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, MISSING_HEADERS=1.581] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id DCE2D1005C for ; Mon, 5 May 2008 23:14:30 +0300 (EEST) Message-ID: <481F6AA8.60002@samoylyk.sumy.ua> Date: Mon, 05 May 2008 23:14:32 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 CC: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <2a41acea0805041529j5d4dd2f7x5e07a8d6d2eb89b6@mail.gmail.com> <2a41acea0805041532le60cc9cybf22887e9fdcb3f9@mail.gmail.com> <481EEE34.7060804@samoylyk.sumy.ua> In-Reply-To: <481EEE34.7060804@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Troubles with em on FreeBSD 7 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, 05 May 2008 20:15:03 -0000 Oleksandr Samoylyk wrote: > Jack Vogel wrote: >> Oh, I just had a thought, increase the RX processing limit, >> that only allows you to process 100 packets in one pass. >> >> First change it to 250 and see what it does, you might >> also set it to -1 which will allow you to process til you >> drain the ring, the risk is that you cause other problems >> by doing that, but heck at this point anything is worth >> trying, right? >> > > Nothing has helped. :( > > I need to unplug and plug in again patch cords each time when my CPUs > with emX go 100% in order to keep my server alive with a descent pings. > > I mentioned that "100%: emX taskq" occurs only on that interfaces where > GRE packets are being processed. > > External interface to Internet feels great. Pings are <0ms and load is > 9.57% with 14kpps (input/output). > > Maybe interesting: > According to kgmon: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 39.9 93.10 93.10 1643247 0.06 0.07 rip_input [10] > > Is it em related or mpd related or something else? > > Back to releng_6? Not sure though. :( > Now I'm on 6.3-STABLE: last pid: 31566; load averages: 7.61, 7.25, 7.07 up 0+01:34:00 22:30:05 82 processes: 10 running, 58 sleeping, 14 waiting CPU states: 0.2% user, 0.0% nice, 52.1% system, 47.8% interrupt, 0.0% idle Mem: 63M Active, 10M Inact, 152M Wired, 8K Cache, 35M Buf, 1752M Free Swap: 4011M Total, 4011M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 -44 -163 0K 8K WAIT 0 42:43 93.60% swi1: net 24 root 1 43 0 0K 8K CPU0 0 29:50 48.34% em0_rx_kthread_1 23 root 1 43 0 0K 8K RUN 0 29:50 46.78% em0_rx_kthread_0 28 root 1 43 0 0K 8K RORDER 1 3:30 2.25% em1_rx_kthread_0 29 root 1 43 0 0K 8K RUN 0 3:30 2.15% em1_rx_kthread_1 10 root 1 171 52 0K 8K RUN 1 11:22 0.00% idle: cpu1 11 root 1 171 52 0K 8K RUN 0 9:01 0.00% idle: cpu0 The results aren't good as well. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Mon May 5 20:15:29 2008 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 6965A106564A for ; Mon, 5 May 2008 20:15:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 565838FC13 for ; Mon, 5 May 2008 20:15:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 05 May 2008 21:17:29 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 4E6622D6014; Mon, 5 May 2008 13:15:28 -0700 (PDT) Message-ID: <481F6AE1.5020408@elischer.org> Date: Mon, 05 May 2008 13:15:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <20080503100043.GA68835@k7.mavetju> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 05 May 2008 20:15:29 -0000 JINMEI Tatuya / 神明é”哉 wrote: > > This should provide a direct answer to you question of "why"? But I > suspect the underlying question is why divert sockets aren't supported > for IPv6. I don't know why. because no=one has done it and because divert sockaddrs are ipv4 sockaddrs you would have to make a new divert6 protocol. That's not impossible, but no-one has done it. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > _______________________________________________ > 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 May 5 20:54:43 2008 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 9CACB106564A for ; Mon, 5 May 2008 20:54:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 887A18FC19 for ; Mon, 5 May 2008 20:54:43 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 4CADA2AC361B; Mon, 5 May 2008 13:54:43 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 2EA492808B; Mon, 5 May 2008 13:54:43 -0700 (PDT) X-AuditID: 11807134-a8ecdbb000000ed7-ac-481f741352ee Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay14.apple.com (Apple SCV relay) with ESMTP id 095C52804C; Mon, 5 May 2008 13:54:43 -0700 (PDT) Message-Id: <2CE7D37B-CC67-4732-9562-6B2ED0857854@mac.com> From: Chuck Swiger To: hlwhyw@shtel.net.cn In-Reply-To: <424543f9f5.3f9f542454@shtel.net.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 5 May 2008 13:54:42 -0700 References: <424543f9f5.3f9f542454@shtel.net.cn> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-net@freebsd.org Subject: Re: Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS kernel which is GPL Licenced? 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, 05 May 2008 20:54:43 -0000 On May 4, 2008, at 6:32 AM, hlwhyw@shtel.net.cn wrote: > Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own > OS kernel which is GPL Licence? Modern 2- or 3-clause BSD licenses are fully compatible with the GPL, as are most "simple, permissive" licenses like the MIT/X11, Zlib, and similar licenses. The old 4-clause license with the "advertising clause" is not GPL-compatible. > I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD > Licenced code and change it to GPL licence? You are not allowed to remove the copyright statement or the original BSD license, but you can take BSD-licensed code and combine it with other software to create a derivative work which you then distribute under the GPL or even a proprietary license, if you wish. Eric Raymond and his wife, Catherine (who is a lawyer), have written some documentation about this specific issue here: http://catb.org/~esr/Licensing-HOWTO.html#id2787981 http://catb.org/~esr/Licensing-HOWTO.html#changing There was also a thread here: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:sss:15819:200804:ohmgonchmnecmnandlnk#b Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon May 5 23:05:00 2008 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 56A01106564A; Mon, 5 May 2008 23:05:00 +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 329828FC0A; Mon, 5 May 2008 23:05:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m45N50bD006137; Mon, 5 May 2008 23:05:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m45N50vT006133; Mon, 5 May 2008 23:05:00 GMT (envelope-from linimon) Date: Mon, 5 May 2008 23:05:00 GMT Message-Id: <200805052305.m45N50vT006133@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123429: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 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, 05 May 2008 23:05:00 -0000 Synopsis: [nfe] [hang] "ifconfig nfe up" causes a hard system lockup in 7.0-RELEASE and 7.0-STABLE-042008 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 5 23:04:49 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123429 From owner-freebsd-net@FreeBSD.ORG Mon May 5 23:10:15 2008 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 BC95D106566C for ; Mon, 5 May 2008 23:10:15 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 58D9A8FC1B for ; Mon, 5 May 2008 23:10:15 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 4C97C2218A7A; Tue, 6 May 2008 09:10:10 +1000 (EST) X-Viruscan-Id: <481F93D2000027321EEBFD@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 0D48F21B240B; Tue, 6 May 2008 09:10:10 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id B5F742218A64; Tue, 6 May 2008 09:10:09 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id 777FF237; Tue, 6 May 2008 09:10:09 +1000 (EST) Date: Tue, 6 May 2008 09:10:09 +1000 From: Edwin Groothuis To: Julian Elischer Message-ID: <20080505231009.GX44028@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481F6AE1.5020408@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 05 May 2008 23:10:15 -0000 On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: > >This should provide a direct answer to you question of "why"? But I > >suspect the underlying question is why divert sockets aren't supported > >for IPv6. I don't know why. > > because no=one has done it and because divert sockaddrs are ipv4 sockaddrs > > you would have to make a new divert6 protocol. > That's not impossible, but no-one has done it. I've been looking at it, with hints from rwatson@ and bms@, but the problem right now lays in the way you can do dynamic protocol registrations with IPv4 but not yet with IPv6. Every time when I get one step further I end up with a new problem :-( Let's call it a learning excercise! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Mon May 5 23:18:55 2008 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 48E2B106567D for ; Mon, 5 May 2008 23:18:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outY.internet-mail-service.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id 388AE8FC24 for ; Mon, 5 May 2008 23:18:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 06 May 2008 00:21:33 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 0FEA82D601A; Mon, 5 May 2008 16:18:53 -0700 (PDT) Message-ID: <481F95DE.6090201@elischer.org> Date: Mon, 05 May 2008 16:18:54 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Edwin Groothuis References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> In-Reply-To: <20080505231009.GX44028@k7.mavetju> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 05 May 2008 23:18:55 -0000 Edwin Groothuis wrote: > On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: >>> This should provide a direct answer to you question of "why"? But I >>> suspect the underlying question is why divert sockets aren't supported >>> for IPv6. I don't know why. >> because no=one has done it and because divert sockaddrs are ipv4 sockaddrs >> >> you would have to make a new divert6 protocol. >> That's not impossible, but no-one has done it. > > I've been looking at it, with hints from rwatson@ and bms@, but the > problem right now lays in the way you can do dynamic protocol > registrations with IPv4 but not yet with IPv6. Every time when I > get one step further I end up with a new problem :-( > > Let's call it a learning excercise! > > Edwin you could implement a whole new protocol family of which there was a single protocol.. divert. so you would open a socket of type. sock = socket(PF_DIVERT, SOCK_RAW, DIVPROTO_6); instead of sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); From owner-freebsd-net@FreeBSD.ORG Mon May 5 23:59:02 2008 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 3CD291065677 for ; Mon, 5 May 2008 23:59:02 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id 013748FC1E for ; Mon, 5 May 2008 23:59:01 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id B18A12218A9B; Tue, 6 May 2008 09:58:59 +1000 (EST) X-Viruscan-Id: <481F9F430000BE5B8A7751@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 8455221B2893; Tue, 6 May 2008 09:58:59 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 333322218A84; Tue, 6 May 2008 09:58:59 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id E7177387; Tue, 6 May 2008 09:58:58 +1000 (EST) Date: Tue, 6 May 2008 09:58:58 +1000 From: Edwin Groothuis To: Julian Elischer Message-ID: <20080505235858.GB46427@k7.mavetju> References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481F95DE.6090201@elischer.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 05 May 2008 23:59:02 -0000 On Mon, May 05, 2008 at 04:18:54PM -0700, Julian Elischer wrote: > Edwin Groothuis wrote: > >On Mon, May 05, 2008 at 01:15:29PM -0700, Julian Elischer wrote: > >>>This should provide a direct answer to you question of "why"? But I > >>>suspect the underlying question is why divert sockets aren't supported > >>>for IPv6. I don't know why. > >>because no=one has done it and because divert sockaddrs are ipv4 sockaddrs > >> > >>you would have to make a new divert6 protocol. > >>That's not impossible, but no-one has done it. > > > >I've been looking at it, with hints from rwatson@ and bms@, but the > >problem right now lays in the way you can do dynamic protocol > >registrations with IPv4 but not yet with IPv6. Every time when I > >get one step further I end up with a new problem :-( > > > >Let's call it a learning excercise! My adventures are written down at http://www.mavetju.org/weblog/html/00231.html > you could implement a whole new protocol family of which there > was a single protocol.. divert. > so you would open a socket of type. > > sock = socket(PF_DIVERT, SOCK_RAW, DIVPROTO_6); > instead of > > sin = socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT); Euhm... that would make my goal more noble but certainly near impossible for me. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-net@FreeBSD.ORG Tue May 6 06:11:30 2008 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 75C911065680 for ; Tue, 6 May 2008 06:11:30 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCD88FC14 for ; Tue, 6 May 2008 06:11:30 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so378783rvf.43 for ; Mon, 05 May 2008 23:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=VG5u+wmXhed8aeeKTuAOimS26D1EeJSiowIKY3PtgbA=; b=RSkf3q9GxZ9s3es3OG+Tnd6PGca6GYykI32Qf1D+6F28ZOYKTkjepLDUH3P82rFiGsvLcZVO0odPZYWShdjEXLP6G/UDNiFrx2c7mjfxOK/68DQfSDo3BSKj/YT+qfXvN4I89Ssai55jNovOHUby6zuTvuqPw4nMkf1XU4B9NY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=YFnUaz3YWgwag1mI2jrWoZ/MhRTKNtXgU+QUcvgB89O579WNY5VASoOyT/FiUttZTqC4IXTIsrsVXmJ5YKnfJiQkSGfVAKCGEif8D5bTM5MV7X/T2W6sq6CqA8bHYlZMRTxbgLut3tGiI2FdUfKJaeX8jF7ReUqIeCHhWgtfQbE= Received: by 10.142.105.10 with SMTP id d10mr139766wfc.306.1210052704307; Mon, 05 May 2008 22:45:04 -0700 (PDT) Received: from ?192.168.0.160? ( [218.94.128.114]) by mx.google.com with ESMTPS id 24sm631533wfc.3.2008.05.05.22.44.59 (version=SSLv3 cipher=RC4-MD5); Mon, 05 May 2008 22:45:02 -0700 (PDT) Date: Tue, 06 May 2008 13:45:06 +0800 From: Deng XueFeng To: Mark Hills , freebsd-net@freebsd.org In-Reply-To: References: Message-Id: <20080506133208.C2EC.B627C632@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.45.02 [CN] Cc: Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 06 May 2008 06:11:30 -0000 hi I'am also meet this problem in my mss server(missey streaming server). one encoder push stream to mss, then run 100 client player playing the sream, as the client number increase, mss will occur this error sooner or later like this: I'am using kqueue, and will got a event with EV_EOF and fflags = ETIMEDOUT, if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), and the tcpdump also show that server will send RST packet to encoder. > Hello, > > I'm are having a trouble with TCP connections being dropped with "read: > Operation timed out". What is unusual is that this is happening right in > the middle of sending a steady stream of data with no network congestion. > > The system is FreeBSD 7 and a bespoke streaming server with 1Gbit > connection. The server receives a 192kbps inbound stream over TCP, and > broadcasts it over a large number of TCP streams. > > With no visible or obvious pattern, the inbound read() fails with > ETIMEDOUT. The likelihood of this happening seems to increase as the > number of audience connections increases. It's happens every few minutes > even with a small audience (eg. 300 outbound connections and about > 60mbit). > > It doesn't cough and splutter -- steady data is coming in, then it just > drops the connection. > > systat doesn't show problems inbound; all packets received are delivered > to the upper layer. But on outbound, there is consistent 'output drops': > > IP Output > 7028 total packets sent > 7028 - generated locally > 314 - output drops > > As the number of outbound connections increases, the 'output drops' > increases to around 10% of the total packets sent and maintains that > ratio. There's no problems with network capacity. > > I've tried different servers, different network interfaces (bge, em), > different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats > and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat > -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen > in a dedicated, uncontended test environment. > > Can anyone explain why the packets are being dropped outbound, and how > this could affect inbound TCP data in such an abrupt way? What can I do to > solve this? > > Thanks, > > Mark > _______________________________________________ > 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" -- Deng XueFeng From owner-freebsd-net@FreeBSD.ORG Tue May 6 07:28:15 2008 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 4DFB8106567B for ; Tue, 6 May 2008 07:28:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id DCB708FC2B for ; Tue, 6 May 2008 07:28:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m467S5ti005186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 17:28:09 +1000 Date: Tue, 6 May 2008 17:28:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Sack In-Reply-To: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Message-ID: <20080506164634.G10595@delplex.bde.org> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , "freebsd-net@freebsd.org" , David Christensen Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 06 May 2008 07:28:15 -0000 On Mon, 5 May 2008, Alexander Sack wrote: > For my own edification, unless you specifically mark a function > inline, will gcc really optimize them out? That seems a little > overboard unless there is some compiler option that says its okay to > do that. I guess that would be very easy to test if you do as you > say, just sock away the function address pointer somewhere and you > should be okay... This is a regression in gcc-4. The -O option says it. -O implies -funit-at-a-time, which allows inlining of functions irrespective of their order within a file and implies -finline-functions-called-once. Thus even plain -O removes most static functions that are only called once. This doesn't seem to be the problem with the bce functions, since some of the missing ones are called more than once. -O2 seems to remove even more functions, but I'm not sure of the details. It is a regression in FreeBSD-5(?) to use -O2 by default for kernels. This used to give mainly bloat, but it now breaks debugging (including stack traces) and profiling unless full debugging symbols are available and used. Only gdb uses full debugging symbols AFAIK, and at least for old versions of gdb on objects generated with -g -O2, it doesn't handle even explicit inline functions quite right (both explicit and inline functions get replaced by non-call instructions instructions and by symbols to say where the function call was, and debuggers have a hard time making this look like a function call so that stepping over the function call works, especially when -O2 reorders everything). [Context lost to top posting.] Bruce From owner-freebsd-net@FreeBSD.ORG Tue May 6 07:45:13 2008 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 6D0AE106567B for ; Tue, 6 May 2008 07:45:13 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1950F8FC1F for ; Tue, 6 May 2008 07:45:12 +0000 (UTC) (envelope-from yonyossef.lists@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so659768ywe.13 for ; Tue, 06 May 2008 00:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Bhn2/X2cDmt+kj6uobw4RrMkeYqoO0k/kwYVwT1STs4=; b=KwegexvT7Xq6oP6wjSl4boo5oXBE6PGc2FBOPRJ0Z4sBHIKPtlgeOoI0VAJoBh2I5+b2Cz1i8EmM9sDvbfR4azaxANZVuMfr/tB+UYB7sjkV6FNfaQ4pgH6MAApv5JXp7ZzBaPov76BDBYn4B5/ZvlUpb6a2i0vCX9mUCHF0rCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=IFfEfdleMt+JEhTyjqkBp2Wn4/pAhIDYFoyozRRxB3HfhdJR7QeUmIdZ/Vg1KFCOjVIinF+tpL0ZWHOuE4e1S0E7Xt9VjJkZWfSbENwbEqh6+RPicPhs8e7h5Ferwh85ZwXOQIfckoHzh/Qion4f+JUrw5mbSnmV7CyzTiPFQ/U= Received: by 10.150.86.10 with SMTP id j10mr369820ybb.211.1210059907199; Tue, 06 May 2008 00:45:07 -0700 (PDT) Received: by 10.151.84.2 with HTTP; Tue, 6 May 2008 00:45:07 -0700 (PDT) Message-ID: <20def4870805060045l2660b363o5c42631b706f61b6@mail.gmail.com> Date: Tue, 6 May 2008 10:45:07 +0300 From: "Mr Y" To: "Yehonatan Yossef" In-Reply-To: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com> MIME-Version: 1.0 References: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Tom Judge , freebsd-net@freebsd.org, Sam Leffler , freebsd-questions@freebsd.org Subject: Re: OS throws away large packets 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, 06 May 2008 07:45:13 -0000 > > > >>> Hi all, > > >>> > > >>> I'm trying to implement Large Recieve Offload for an > > >>> > > >> Ethernet driver > > >> > > >>> on FreeBSD 6.3, but all my >MTU packets are being thrown > > by the OS. > > >>> I'm using mbuf chains in this imlpementation, each mbuf is > > >>> > > >> a cluster > > >> > > >>> of MCLBYTES bytes. They are linked by the m_next pointer. > > >>> The first packet being thrown away is 2945 bytes long. > > >>> > > >> Wireshark shows > > >> > > >>> the packet that is being passed to the OS is correct. > > >>> > > >>> Do I need to set some OS parameter to make it recieve mbuf chains? > > >>> > > >>> Please help. > > >>> > > >>> > > >> Hi Yony, > > >> > > >> I seem to remember some discussion about this list last > > year see the > > >> following threads: > > >> > > >> > > >> > > > > > > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm > l > > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm > l > > > > > > >From my limited reading of these threads just now and possibly bad > > > memory. It would seem that the MRU to MTU relationship is > > defined in > > > the nic driver rather than > > > > > >> enforced further up the stack or at least that seamed to > > be the case > > >> > > > with the bce driver. > > > > > >> Hope this is helpful, > > >> > > >> Tom > > >> > > > > > > Hi Tom, > > > > > > >From what I understand these threads are referring to the bce > > > >hardware > > > configuration (bus configuration) and driver mbuf > > allocation size. Am > > > I correct? > > > In my case I'm not trying to receive packets >MTU from the > > HW, but to > > > chain mbuf clusters, each is MCLBYTES long, and pass the > > mbuf chain to > > > the OS. > > > Since tcpdump (analyzed by wireshark) catches the packets above the > > > driver and reports a good packet (and 2945 bytes long), I assume my > > > driver functionality is ok. From what I know tcpdump is supposed to > > > immitate the way the stack sees the packet, yet it is discarded. > > > My logic says there is an OS parameter handled by the > > driver (at net > > > device init time for example) that will set the OS to receive large > > > mbuf chains, or a kernel tcp parameter. Is the tcp stack > > submitted to > > > the mtu somehow? > > > > > > > > I don't see where you've identified what version of the os you're > > working with. There's a check in the 802.3 input path on earlier > > systems to discard frames >mtu. This was removed not too long ago > > with LRO in mind; check the history of sys/net/if_ethersubr.c. > > > > Sam > > > > Hi Sam, I have mentioned working on 6.3. > > FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: > > 539 if (m->m_pkthdr.len > > 540 ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { > 541 if_printf(ifp, "discard oversize frame " > 542 "(ether type %x flags %x len %u > > max %lu)\n", > 543 etype, m->m_flags, m->m_pkthdr.len, > 544 ETHER_MAX_FRAME(ifp, etype, > 545 m->m_flags & > M_HASFCS)); > 546 ifp->if_ierrors++; > 547 m_freem(m); > 548 return; > 549 } > > Patching it was explained by neterion in > http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD. > This check no longer exists in 6.3, nor any other oversize packet > handling (I couldn't find any so far). > I also get no error prints from the OS. > The problem was in my packet, after I put some traces in netinet/ip_input.c I found out my m_pkthdr.len was not properly updated. Thanks From owner-freebsd-net@FreeBSD.ORG Tue May 6 11:56:22 2008 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 15E10106564A for ; Tue, 6 May 2008 11:56:22 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by mx1.freebsd.org (Postfix) with ESMTP id C82588FC12 for ; Tue, 6 May 2008 11:56:21 +0000 (UTC) (envelope-from martes@mgwigglesworth.com) Received: from mail.networksolutionsemail.com (ns-omr5.mgt.netsol.com [10.49.6.68]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id m46BuKHh018885 for ; Tue, 6 May 2008 07:56:20 -0400 Received: (qmail 5230 invoked by uid 78); 6 May 2008 11:56:20 -0000 Received: from unknown (HELO ?10.24.53.154?) (martes@mgwigglesworth.com@12.48.144.2) by ns-omr5.lb.hosting.dc2.netsol.com with SMTP; 6 May 2008 11:56:20 -0000 From: Martes G Wigglesworth To: Alexander Sack In-Reply-To: <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> Content-Type: text/plain Organization: M.G.Wigglesworth,LLC Date: Tue, 06 May 2008 07:55:03 -0400 Message-Id: <1210074903.8179.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0-2mdv2008.0 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , "freebsd-net@freebsd.org" , David Christensen Subject: Re: Not All Symbols Present in a Loadable Kernel Module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martes@mgwigglesworth.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2008 11:56:22 -0000 I thought that the "inline" switch was specific to C++ and C and not gcc, hence the standard for the language says to add the inline parameter to explicitly produce optimized code. Unless gcc is not standard, I don't see why the compiler would automatically optimize the coded function to "inline." On Mon, 2008-05-05 at 14:06 -0400, Alexander Sack wrote: > For my own edification, unless you specifically mark a function > inline, will gcc really optimize them out? That seems a little > overboard unless there is some compiler option that says its okay to > do that. I guess that would be very easy to test if you do as you > say, just sock away the function address pointer somewhere and you > should be okay... > > -aps > > On Mon, May 5, 2008 at 12:32 PM, Kostik Belousov wrote: > > > > On Mon, May 05, 2008 at 09:27:10AM -0700, David Christensen wrote: > > > > > Yes, I'm building a debug kernel. I have the line listed above as > > > > well > > > > > as the following: > > > > > > > > > > options KDB > > > > > options DDB > > > > > options GDB > > > > > options INVARIANTS > > > > > options INVARIANT_SUPPORT > > > > > options WITNESS > > > > > options WITNESS_SKIPSPIN > > > > > > > > Dave: > > > > > > > > What symbols can you not access exactly and how are you > > > > installing/setting up debugging? > > > > > > > > I just built a RELENG_7 with DDB and I'm able to access bce symbols > > > > without a problem. I can examine them and call them. I'm not using > > > > options GDB however, only KDB/DDB. > > > > > > > > I would: > > > > > > > > - Make sure you have the right if_bce.ko/if_bce.ko.symbols files > > > > generated/installed which contains the debug sections of your ko (from > > > > the objcopy calls during the build - the binary is stripped with a > > > > section pointer to the if_bce.ko.symbols file for debugging > > > > information I believe) > > > > - If you are using GDB, make sure its pointed to the right source base > > > > so it can retrieve symbol information correctly > > > > - If you are using GDB, stub it out and just use DDB to verify that > > > > your build is sane (it works for me!) > > > > - If all else fails, you can always build bce statically (just to move > > > > forward etc.) > > > > > > - Enable the kernel debugger as described above > > > - Build the driver in the /usr/src/sys/modules/bce directory with the > > > command "make". > > > - Run the command "nm if_bce.ko | grep dump_stat" in the same directory > > > with the kernel module just built. > > > > > > In my case I only see a symbol for bce_dump_status_block, but there is a > > > second routine called bce_dump_stats_block. In my working build there > > > are 23 functions that start with "bce_dump" but only 8 are displayed with > > > the command "nm if_bce.ko | grep bce_dump". Of course, I also get the > > > symbol not present error when I try to use any of those missing symbols > > > through a "call" command in the debugger. > > > > Most likely, they are optimized out, gcc likes to inline once-called > > static functions. Aside from playing with the optimization options, > > the easiest way seems to use functions somewhere else, e.g., put the > > addresses into some table. Just guessing. > > > _______________________________________________ > 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 May 6 14:42:58 2008 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 CC38B1065670 for ; Tue, 6 May 2008 14:42:58 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 854958FC24 for ; Tue, 6 May 2008 14:42:58 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id A9692B81C for ; Tue, 6 May 2008 17:42:55 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 54C7E10027 for ; Tue, 6 May 2008 17:42:19 +0300 (EEST) Message-ID: <48206E43.2070808@samoylyk.sumy.ua> Date: Tue, 06 May 2008 17:42:11 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> <481E43DD.8080300@samoylyk.sumy.ua> <481E4ACC.1080106@gtcomm.net> In-Reply-To: <481E4ACC.1080106@gtcomm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Troubles with em on FreeBSD 7 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, 06 May 2008 14:42:58 -0000 A bit experiments and it's was detected that it is a netgraph related problem. Whom can I address the problem? Thanks to Paul. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 14:47:54 2008 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 35DF9106564A for ; Tue, 6 May 2008 14:47:54 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id B9A258FC12 for ; Tue, 6 May 2008 14:47:53 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so707756tid.3 for ; Tue, 06 May 2008 07:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UBmb05ARF8vgmMH0WQxIruzVLOCL30K237T4I0So498=; b=EAkvEgghZnw1kS3MthG2iOOImIptFyHsAUfN5ph+xEmV0DYhxN75y9psFQ7SjA/5/3sTmQ+jjslCCxaiCicQWlGPTcsUwYrkgBBPaH2yex/FGCPIhzza3tX5C4Xcm2aqfSX70UxkywqIcAzJ0hEaatfH0kd519xI07mugD07SEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IK/mjuWk/HgGSQ98485WjVxQ8Gej/YMZxAHLbHLaUSVMbVgQaTtxodhvAl2YoLX+vh9iDGo+2AyFrXQj8Dz9wICcn32eXFNi3lFeHTdsfZLoRV+hO+53sxhFUa3ZFfXwLRfA1hQUF/eyPahuMY8cLVHHZTU4lT2rO2x0do4rtvc= Received: by 10.150.79.42 with SMTP id c42mr752305ybb.163.1210085269896; Tue, 06 May 2008 07:47:49 -0700 (PDT) Received: by 10.150.152.3 with HTTP; Tue, 6 May 2008 07:47:49 -0700 (PDT) Message-ID: <3c0b01820805060747j79996b73n6cdb5fb87a368912@mail.gmail.com> Date: Tue, 6 May 2008 10:47:49 -0400 From: "Alexander Sack" To: "Bruce Evans" In-Reply-To: <20080506164634.G10595@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5D267A3F22FD854F8F48B3D2B523819324F09D65FA@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805021315i482fe0acg3e9238a2f412770e@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6896@IRVEXCHCCR01.corp.ad.broadcom.com> <3c0b01820805030750k2fc389b0y500914c36069e6cf@mail.gmail.com> <5D267A3F22FD854F8F48B3D2B523819324F09D6A52@IRVEXCHCCR01.corp.ad.broadcom.com> <20080505163249.GU18958@deviant.kiev.zoral.com.ua> <3c0b01820805051106k5faf368etec0851e65de109f8@mail.gmail.com> <20080506164634.G10595@delplex.bde.org> Cc: Kostik Belousov , "freebsd-net@freebsd.org" , David Christensen Subject: Re: Not All Symbols Present in a Loadable Kernel Module 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, 06 May 2008 14:47:54 -0000 On Tue, May 6, 2008 at 3:28 AM, Bruce Evans wrote: > On Mon, 5 May 2008, Alexander Sack wrote: > > For my own edification, unless you specifically mark a function > > inline, will gcc really optimize them out? That seems a little > > overboard unless there is some compiler option that says its okay to > > do that. I guess that would be very easy to test if you do as you > > say, just sock away the function address pointer somewhere and you > > should be okay... > > > > This is a regression in gcc-4. The -O option says it. -O implies > -funit-at-a-time, which allows inlining of functions irrespective of > their order within a file and implies -finline-functions-called-once. > Thus even plain -O removes most static functions that are only called > once. Thanks Bruce, I did some digging and all i can say is YIKES. Got to be careful with gcc optimizations. I suppose to be safe, bge could be compiled with -fno-inline-funcations-called-once to be safe. > This doesn't seem to be the problem with the bce functions, since some > of the missing ones are called more than once. Again, I would assume if you look at the symbols of the generated binary you should be able to figure out if you have a compiler issue or a debugger one! -aps From owner-freebsd-net@FreeBSD.ORG Tue May 6 15:04:54 2008 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 54308106566C for ; Tue, 6 May 2008 15:04:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outs.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0B28FC24 for ; Tue, 6 May 2008 15:04:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 06 May 2008 16:10:12 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 57CF02D6006; Tue, 6 May 2008 08:04:53 -0700 (PDT) Message-ID: <48207394.2090707@elischer.org> Date: Tue, 06 May 2008 08:04:52 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <481C84B7.6020205@samoylyk.sumy.ua> <481E338D.6040706@samoylyk.sumy.ua> <481E3C32.8000507@gtcomm.net> <481E43DD.8080300@samoylyk.sumy.ua> <481E4ACC.1080106@gtcomm.net> <48206E43.2070808@samoylyk.sumy.ua> In-Reply-To: <48206E43.2070808@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Troubles with em on FreeBSD 7 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, 06 May 2008 15:04:54 -0000 Oleksandr Samoylyk wrote: > A bit experiments and it's was detected that it is a netgraph related > problem. > > Whom can I address the problem? > > Thanks to Paul. > net@freebsd.org... send details and one of us will look at it.. From owner-freebsd-net@FreeBSD.ORG Tue May 6 15:58:50 2008 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 C7B1410656AD for ; Tue, 6 May 2008 15:58:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8499C8FC19 for ; Tue, 6 May 2008 15:58:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id A3F9EB826 for ; Tue, 6 May 2008 18:58:48 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 51A641007B for ; Tue, 6 May 2008 18:58:16 +0300 (EEST) Message-ID: <4820801A.90504@samoylyk.sumy.ua> Date: Tue, 06 May 2008 18:58:18 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: net@freebsd.org References: <48207C8B.4020509@samoylyk.sumy.ua> In-Reply-To: <48207C8B.4020509@samoylyk.sumy.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problems with netgraph 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, 06 May 2008 15:58:50 -0000 Oleksandr Samoylyk wrote: > Dear developers, > > Please read this thread: > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html > > I'm using no encryption and no compression in mpd, so netgraph should fly. > It seems to get bad after 500 sessions... > > In FreeBSD 6 - it's swi1: net - 100% CPU > In FreeBSD 7 - it's em0 taskq - 100% CPU > > After playing with it I can make guess that's a netgraph problem. > > Maybe it's a poor design in netgraph the way it handle its tables and > it's is probably not designed to add so many interfaces. > > Might be there something in the source code I can edit to improve the > table lookups or hash table or whatever netgraph use to store and > process the node information and do the ppp/gre work. > I can also offer a shell access to server in order to investigate the problem. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 16:01:15 2008 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 872191065681 for ; Tue, 6 May 2008 16:01:15 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 45B448FC0A for ; Tue, 6 May 2008 16:01:15 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id ED42BDBF0 for ; Tue, 6 May 2008 18:43:48 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 24A73B836 for ; Tue, 6 May 2008 18:43:15 +0300 (EEST) Message-ID: <48207C8B.4020509@samoylyk.sumy.ua> Date: Tue, 06 May 2008 18:43:07 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Problems with netgraph 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, 06 May 2008 16:01:15 -0000 Dear developers, Please read this thread: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html I'm using no encryption and no compression in mpd, so netgraph should fly. It seems to get bad after 500 sessions... In FreeBSD 6 - it's swi1: net - 100% CPU In FreeBSD 7 - it's em0 taskq - 100% CPU After playing with it I can make guess that's a netgraph problem. Maybe it's a poor design in netgraph the way it handle its tables and it's is probably not designed to add so many interfaces. Might be there something in the source code I can edit to improve the table lookups or hash table or whatever netgraph use to store and process the node information and do the ppp/gre work. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 17:53:25 2008 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 44667106564A for ; Tue, 6 May 2008 17:53:25 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id ECBB48FC0C for ; Tue, 6 May 2008 17:53:24 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 0CEF110083 for ; Tue, 6 May 2008 20:53:20 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 8379D1008A for ; Tue, 6 May 2008 20:48:05 +0300 (EEST) Message-ID: <482099CE.5050802@samoylyk.sumy.ua> Date: Tue, 06 May 2008 20:47:58 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: net@freebsd.org References: <48207C8B.4020509@samoylyk.sumy.ua> <4820801A.90504@samoylyk.sumy.ua> In-Reply-To: <4820801A.90504@samoylyk.sumy.ua> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Problems with netgraph 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, 06 May 2008 17:53:25 -0000 Oleksandr Samoylyk ïèøåò: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. >> >> Might be there something in the source code I can edit to improve the >> table lookups or hash table or whatever netgraph use to store and >> process the node information and do the ppp/gre work. >> > > I can also offer a shell access to server in order to investigate the > problem. > # ngctl list ngctl: send msg: No buffer space available However: kern.ipc.maxpipekva="400000000" net.graph.maxalloc="8192" net.graph.maxdgram="256000" net.graph.recvspace="256000" -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 18:08:07 2008 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 E2E5E10656B8 for ; Tue, 6 May 2008 18:08:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outt.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 8026E8FC21 for ; Tue, 6 May 2008 18:08:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 06 May 2008 19:03:44 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id CE4F82D600D; Tue, 6 May 2008 10:56:20 -0700 (PDT) Message-ID: <48209BC4.5080602@elischer.org> Date: Tue, 06 May 2008 10:56:20 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> In-Reply-To: <48207C8B.4020509@samoylyk.sumy.ua> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Problems with netgraph 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, 06 May 2008 18:08:08 -0000 Oleksandr Samoylyk wrote: > Dear developers, > > Please read this thread: > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html > > I'm using no encryption and no compression in mpd, so netgraph should fly. > It seems to get bad after 500 sessions... > > In FreeBSD 6 - it's swi1: net - 100% CPU > In FreeBSD 7 - it's em0 taskq - 100% CPU unfortunatly I've been totally ignoring this thread because it said "trouble with em" in the topic.. If you'd said trouble with mpd then maybe I'd have looked earlier.. > > After playing with it I can make guess that's a netgraph problem. > > Maybe it's a poor design in netgraph the way it handle its tables and > it's is probably not designed to add so many interfaces. how many? > > Might be there something in the source code I can edit to improve the > table lookups or hash table or whatever netgraph use to store and > process the node information and do the ppp/gre work. netgraph just had some work done on it for this exact reason, but you may be jumping the gun a bit.. > From owner-freebsd-net@FreeBSD.ORG Tue May 6 18:33:50 2008 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 E3C691065674 for ; Tue, 6 May 2008 18:33:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 949988FC0A for ; Tue, 6 May 2008 18:33:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id DA48FB9CD; Tue, 6 May 2008 21:33:48 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id CAA9410071; Tue, 6 May 2008 21:33:31 +0300 (EEST) Message-ID: <4820A47D.8010404@samoylyk.sumy.ua> Date: Tue, 06 May 2008 21:33:33 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: net@freebsd.org References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> In-Reply-To: <48209BC4.5080602@elischer.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Elischer Subject: Re: Problems with netgraph 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, 06 May 2008 18:33:51 -0000 Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said > trouble with mpd then maybe I'd have looked earlier.. > >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. > > how many? more than 2500 >> Might be there something in the source code I can edit to improve the >> table lookups or hash table or whatever netgraph use to store and >> process the node information and do the ppp/gre work. > > netgraph just had some work done on it for this exact reason, > but you may be jumping the gun a bit.. > >> > -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 19:43:44 2008 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 CAF15106566C for ; Tue, 6 May 2008 19:43:44 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4390C8FC1C for ; Tue, 6 May 2008 19:43:43 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 4AD501006F; Tue, 6 May 2008 22:43:41 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id D0835B826; Tue, 6 May 2008 22:43:23 +0300 (EEST) Message-ID: <4820B4DD.80105@samoylyk.sumy.ua> Date: Tue, 06 May 2008 22:43:25 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Julian Elischer References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> In-Reply-To: <48209BC4.5080602@elischer.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Problems with netgraph 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, 06 May 2008 19:43:44 -0000 Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Dear developers, >> >> Please read this thread: >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017891.html >> >> I'm using no encryption and no compression in mpd, so netgraph should >> fly. >> It seems to get bad after 500 sessions... >> >> In FreeBSD 6 - it's swi1: net - 100% CPU >> In FreeBSD 7 - it's em0 taskq - 100% CPU > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said > trouble with mpd then maybe I'd have looked earlier.. > >> >> After playing with it I can make guess that's a netgraph problem. >> >> Maybe it's a poor design in netgraph the way it handle its tables and >> it's is probably not designed to add so many interfaces. > > how many? > # vmstat -m | grep netgraph netgraph_msg 0 0K - 1355522 64,128,256,512,1024 netgraph_node 12110 3028K - 28829 256 netgraph_hook 29648 3706K - 66104 128 netgraph 8076 12663K - 15209 64,256,1024,4096 netgraph_sock 4 1K - 5489 128 netgraph_path 1 1K - 728112 16,32 netgraph_mppc 0 0K - 1 1024 netgraph_ksock 1349 169K - 3414 128 netgraph_iface 1346 169K - 2367 128 netgraph_ppp 1346 16152K - 2367 netgraph_bpf 16020 2003K - 33296 128 # ifconfig -a | grep ng | wc -l 1341 I saw a peak with about 1900 ng interfaces. That was tooo sloowwww.... last pid: 39304; load averages: 1.12, 1.23, 1.20 up 0+01:15:38 22:39:04 93 processes: 10 running, 70 sleeping, 13 waiting CPU states: 0.3% user, 0.0% nice, 15.3% system, 3.1% interrupt, 81.3% idle Mem: 46M Active, 7772K Inact, 109M Wired, 128K Cache, 16M Buf, 7756M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 819 root 23 50 0 92764K 36424K select 1 0:00 207.18% mpd5 17 root 1 171 ki31 0K 16K RUN 1 71:41 100.00% idle: cpu1 14 root 1 171 ki31 0K 16K CPU4 4 69:16 100.00% idle: cpu4 15 root 1 171 ki31 0K 16K CPU3 3 68:11 100.00% idle: cpu3 29 root 1 -68 - 0K 16K CPU6 6 60:50 100.00% em0 taskq 18 root 1 171 ki31 0K 16K CPU0 0 71:58 97.17% idle: cpu0 16 root 1 171 ki31 0K 16K CPU2 2 68:13 95.65% idle: cpu2 11 root 1 171 ki31 0K 16K CPU7 7 66:23 86.38% idle: cpu7 13 root 1 171 ki31 0K 16K CPU5 5 65:28 71.97% idle: cpu5 19 root 1 -44 - 0K 16K WAIT 5 19:53 31.59% swi1: net 30 root 1 -68 - 0K 16K - 7 8:41 12.89% em1 taskq 12 root 1 171 ki31 0K 16K RUN 6 12:41 0.00% idle: cpu6 20 root 1 -32 - 0K 16K WAIT 3 1:12 0.00% swi4: clock # uname -v FreeBSD 7.0-STABLE #0: Mon May 5 01:11:23 EEST 2008 CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2000.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0x4e33d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs usable memory = 8580038656 (8182 MB) avail memory = 8292810752 (7908 MB) # ngctl list ngctl: send msg: No buffer space available # cat /boot/loader.conf loader_logo="beastie" autoboot_delay="3" hw.em.rxd="1024" hw.em.txd="1024" net.inet.tcp.tcbhashsize="4096" kern.ipc.maxpipekva="32000000" net.graph.recvspace="128000" net.graph.maxdgram="128000" Linux with poptop was running quit smoothly. I thought that netgraph would be fast as hell. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Tue May 6 20:35:06 2008 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 EB94C106564A for ; Tue, 6 May 2008 20:35:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA708FC1E for ; Tue, 6 May 2008 20:35:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DE1BF41C799; Tue, 6 May 2008 22:35:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ocNbek7uzYDi; Tue, 6 May 2008 22:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6D55A41C798; Tue, 6 May 2008 22:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9A27E44487F; Tue, 6 May 2008 20:33:09 +0000 (UTC) Date: Tue, 6 May 2008 20:33:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4816D1D2.7010603@elischer.org> Message-ID: <20080506202940.K47338@maildrop.int.zabbadoz.net> References: <4816D1D2.7010603@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 06 May 2008 20:35:07 -0000 On Tue, 29 Apr 2008, Julian Elischer wrote: Hi, > The patch can be found at > http://www.freebsd.org/~julian/mrt.diff > (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) > > or source can be taken from perforce at: > //depot/user/julian/routing/src So after looking at the patch a bit more again, could you add wrapper functions for those like you have done for the old KPI (rtrequest, rtrequest1, ..)? + * For now the protocol indepedent versions are the same as the AF_INET ones + * but this will change.. just #define them at this time. + */ +#define in_rt_getifa(_a, _b) rt_getifa_fib(_a, _b) +#define in_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) +#define in_rtalloc(_a, _b) rtalloc_fib(_a, _b) +#define in_rtalloc1(_a, _b, _c, _d) rtalloc1_fib(_a, _b, _c, _d) +#define in_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) +#define in_rtredirect(_a, _b, _c, _d, _e, _f) \ + rtredirect_fib(_a, _b, _c, _d, _e, _f) +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ + rtrequest_fib(_a, _b, _c, _d, _e, _f,_g) +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, _c, _d) +#define in_rt_check(_a, _b, _c, _d) rt_check_fib(_a, _b, _c, _d) The defines will not give you a stable KPI and having that changed again if you are going with a prefix for each AF would be a pain if the _fib versions are going to change in the future. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Tue May 6 21:08:32 2008 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 7DE551065670 for ; Tue, 6 May 2008 21:08:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4E88FC12 for ; Tue, 6 May 2008 21:08:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 06 May 2008 22:38:49 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BC40A2D6019; Tue, 6 May 2008 14:08:31 -0700 (PDT) Message-ID: <4820C8CE.8010309@elischer.org> Date: Tue, 06 May 2008 14:08:30 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> In-Reply-To: <20080506202940.K47338@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 06 May 2008 21:08:32 -0000 Bjoern A. Zeeb wrote: > On Tue, 29 Apr 2008, Julian Elischer wrote: > > Hi, > >> The patch can be found at >> http://www.freebsd.org/~julian/mrt.diff >> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >> >> or source can be taken from perforce at: >> //depot/user/julian/routing/src > > So after looking at the patch a bit more again, could you add wrapper > functions for those like you have done for the old KPI (rtrequest, > rtrequest1, do you really want to do the extra work instructions? > ..)? > > + * For now the protocol indepedent versions are the same as the AF_INET > ones > + * but this will change.. just #define them at this time. > + */ > +#define in_rt_getifa(_a, _b) rt_getifa_fib(_a, _b) > +#define in_rtalloc_ign(_a, _b, _c) rtalloc_ign_fib(_a, _b, _c) > +#define in_rtalloc(_a, _b) rtalloc_fib(_a, _b) > +#define in_rtalloc1(_a, _b, _c, _d) rtalloc1_fib(_a, _b, _c, _d) > +#define in_rtioctl(_a, _b, _c) rtioctl_fib(_a, _b, _c) > +#define in_rtredirect(_a, _b, _c, _d, _e, _f) \ > + rtredirect_fib(_a, _b, _c, _d, > _e, _f) > +#define in_rtrequest(_a, _b, _c, _d, _e, _f, _g) \ > + rtrequest_fib(_a, _b, _c, _d, > _e, _f,_g) > +#define in_rtrequest1(_a, _b, _c, _d) rtrequest1_fib(_a, _b, > _c, _d) > +#define in_rt_check(_a, _b, _c, _d) rt_check_fib(_a, _b, _c, > _d) > > > The defines will not give you a stable KPI and having that changed again > if you are going with a prefix for each AF would be a pain if the _fib > versions > are going to change in the future. hmm fair enough... but let me outline my plans and thoughts so we can see if you still want this.. In order to get away from having every protocol (existing or not) from preallocating N fib heads (currently it is done in protocol independent code) the protocols themselves need to know if they are allocating multiple FIBS and how many. For this reason, the protocol versions will eventually know where their own fibs are stored and act on them as needed, allowing them to be dynamically allocated. (as many as needed). The methods for each protocol family woudl be pointed to in the domain structure, and the protocol independent versions would look them up that way and call them.. so the domain structure would include: struct domain { [...] *(struct rtentry *dom_rtalloc)(mumble); [...] }; (or whatever the syntax is (I always have to look it up) in netinet we would declare struct domain inet_domain = { [...] in_rtalloc, [...] ]; A new function find_domain(family) makes a method independent way to find the domain structure for any given PF/AF. So rtalloc_fib would be: struct rtentry * rtalloc_fib( struct route *ro, int fib) { struct domain *dp; dp = find_domain(ro->ro_dst.sa_family) if (dp) return (*(dp->dom_rtalloc)(ro, fib)); return (NULL); } This all however is not ABI compatible so could not go back to 7.x and I want to check in an initial version that can go back to 7.x which sort of suggests to me that adding in_xxx functions is not really required, until I do the next step. 7.x will never get the next step. because the ABI is already set in stone for 7.x. I would make the in_xxx stubs in the next step in 8.x. after the MFC to 7.x of the ABI compat version. let me know what you think. From owner-freebsd-net@FreeBSD.ORG Wed May 7 04:41:09 2008 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 5F559106566B for ; Wed, 7 May 2008 04:41:09 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by mx1.freebsd.org (Postfix) with ESMTP id 396C98FC15 for ; Wed, 7 May 2008 04:41:09 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 1JtawC-0000Lc-3d for freebsd-net@freebsd.org; Wed, 07 May 2008 04:07:28 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp4.email.verio.net with esmtp id 1JtawC-0001wM-0Q for freebsd-net@freebsd.org; Wed, 07 May 2008 04:07:28 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id C56278E298; Tue, 6 May 2008 23:07:27 -0500 (CDT) Date: Tue, 6 May 2008 23:07:27 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080507040727.GA28983@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48209BC4.5080602@elischer.org> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: Problems with netgraph X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2008 04:41:09 -0000 Julian Elischer wrote: > > unfortunatly I've been totally ignoring this thread because it said > "trouble with em" in the topic.. > If you'd said "trouble with mpd" then maybe I'd have looked earlier.. In the poster's defense, the only symptom that started this was this info from ps: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq So tracking it down to mpd has been a process of elimination in figuring out why packets absorb so much CPU. -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 From owner-freebsd-net@FreeBSD.ORG Wed May 7 04:41:54 2008 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 912281065673 for ; Wed, 7 May 2008 04:41:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 600518FC0C for ; Wed, 7 May 2008 04:41:54 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 97D8F1061A6; Wed, 7 May 2008 00:41:53 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 07 May 2008 00:41:53 -0400 X-Sasl-enc: tHFvPowkjopVB+Y7KdoefyT1dz3onZVkBJhFYOxzvKdA 1210135313 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C044313BF7; Wed, 7 May 2008 00:41:52 -0400 (EDT) Message-ID: <4821330E.8030101@incunabulum.net> Date: Wed, 07 May 2008 05:41:50 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Julian Elischer References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> In-Reply-To: <481F95DE.6090201@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 07 May 2008 04:41:54 -0000 Julian Elischer wrote: > you could implement a whole new protocol family of which there > was a single protocol.. divert. That's sheer overkill for what Edwin needs to be able to do. We already have a bunch of apps which use divert sockets in the IPv4 space, why should the existing semantics change? Divert sockets are still tied to the transport you instantiate them with, and they have always been a special case anyway depending on where one wishes to draw the lines. There is no reason per se, that I can see, why the IPPROTO_DIVERT identifier can't just be re-used along with pf_proto_register() for PF_INET6, and I've said this to Edwin off-list. A PROTO_SPACER entry just needs to be added to in6protosw. I was surprised to learn no-one had gone ahead and actually implemented it already as there are a few cases in IPv6 which might warrant it (6to4, Teredo etc.) If I'm missing anything obvious please let me know. cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed May 7 06:59:39 2008 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 A4317106567A for ; Wed, 7 May 2008 06:59:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outt.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id 86E6B8FC14 for ; Wed, 7 May 2008 06:59:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 07 May 2008 10:21:47 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C407A2D600E; Tue, 6 May 2008 23:59:38 -0700 (PDT) Message-ID: <4821535B.8050001@elischer.org> Date: Tue, 06 May 2008 23:59:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> In-Reply-To: <4821330E.8030101@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 07 May 2008 06:59:39 -0000 Bruce M. Simpson wrote: > Julian Elischer wrote: >> you could implement a whole new protocol family of which there >> was a single protocol.. divert. > That's sheer overkill for what Edwin needs to be able to do. We already > have a bunch of apps which use divert sockets in the IPv4 space, why > should the existing semantics change? Divert sockets are still tied to > the transport you instantiate them with, and they have always been a > special case anyway depending on where one wishes to draw the lines. > > There is no reason per se, that I can see, why the IPPROTO_DIVERT > identifier can't just be re-used along with pf_proto_register() for > PF_INET6, and I've said this to Edwin off-list. A PROTO_SPACER entry > just needs to be added to in6protosw. > > I was surprised to learn no-one had gone ahead and actually implemented > it already as there are a few cases in IPv6 which might warrant it > (6to4, Teredo etc.) If I'm missing anything obvious please let me know. > > cheers > BMS actually the divert sockets should really not be in PF_INET they could deliver both inet and inet6 packets. the sockaddr that they return (and which needs to be read for divert to make sense) could be used to distinguish between them. From owner-freebsd-net@FreeBSD.ORG Wed May 7 07:15:35 2008 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 593DF1065672 for ; Wed, 7 May 2008 07:15:35 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id F3EDE8FC2F for ; Wed, 7 May 2008 07:15:33 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id E7F94C437 for ; Wed, 7 May 2008 10:15:30 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.0.109] (pigeon-work.telesweet [10.0.0.109]) by mail.telesweet.net (Postfix) with ESMTP id 61209B828 for ; Wed, 7 May 2008 10:15:17 +0300 (EEST) Message-ID: <48215706.8080508@samoylyk.sumy.ua> Date: Wed, 07 May 2008 10:15:18 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> In-Reply-To: <20080507040727.GA28983@verio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Problems with netgraph 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, 07 May 2008 07:15:35 -0000 David DeSimone wrote: > Julian Elischer wrote: >> unfortunatly I've been totally ignoring this thread because it said >> "trouble with em" in the topic.. >> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. > > In the poster's defense, the only symptom that started this was this > info from ps: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 taskq > > So tracking it down to mpd has been a process of elimination in figuring > out why packets absorb so much CPU. > Here is a result of profiling: http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Wed May 7 07:24:57 2008 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 67C361065673 for ; Wed, 7 May 2008 07:24:57 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id CED498FC14 for ; Wed, 7 May 2008 07:24:56 +0000 (UTC) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: from ednmsw510.dsto.defence.gov.au (ednmsw510.dsto.defence.gov.au [131.185.68.11]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id m477AEuF023780 for ; Wed, 7 May 2008 16:40:14 +0930 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw510.dsto.defence.gov.au (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Wed, 7 May 2008 16:43:35 +0930 Received: from stlex510.dsto.defence.gov.au ([203.6.60.184]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 17:13:35 +1000 Received: from obelix.dsto.defence.gov.au ([203.6.60.208]) by stlex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 15:13:34 +0800 Received: from obelix.dsto.defence.gov.au (localhost [127.0.0.1]) by obelix.dsto.defence.gov.au (8.14.2/8.14.2) with ESMTP id m477959c000442 for ; Wed, 7 May 2008 15:09:05 +0800 (WST) (envelope-from wilkinsa@obelix.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by obelix.dsto.defence.gov.au (8.14.2/8.14.2/Submit) id m477956Q000441 for freebsd-net@freebsd.org; Wed, 7 May 2008 15:09:05 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 7 May 2008 15:09:05 +0800 From: "Wilkinson, Alex" To: freebsd-net@freebsd.org Message-ID: <20080507070905.GR77510@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Organisation: Defence Science Technology Organisation User-Agent: Mutt/1.5.17 (2007-11-01) X-OriginalArrivalTime: 07 May 2008 07:13:34.0586 (UTC) FILETIME=[DCD3CDA0:01C8B011] X-TM-AS-Product-Ver: SMEX-7.0.0.1526-5.5.1026-15894.003 X-TM-AS-Result: No--9.054700-0.000000-31 Content-Transfer-Encoding: 7bit Subject: Fwd: [networking-discuss] uperf - A network benchmark tool 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, 07 May 2008 07:24:57 -0000 FYI ----- Forwarded message from Neelakanth Nadgir ----- Date: Tue, 06 May 2008 17:34:23 -0700 From: Neelakanth Nadgir To: networking-discuss@opensolaris.org Cc: Neelakanth Nadgir Subject: [networking-discuss] uperf - A network benchmark tool [apologies if you received duplicates] Folks, we just opensourced (under GPL v3) a network benchmarking tool called uperf at http://www.uperf.org. I encourage you to check it out. uperf (just like filebench) takes a description of the networking component of workloads and replays it. Using a "model" allows you to change different parameters (like scale, protocol, etc..) and analyze performance. I hope you find it useful. Uperf is work in progress and we are adding more functionality. If you would like to contribute, please feel free so; we can use all the help. thanks, -neel -- --- Neelakanth Nadgir http://blogs.sun.com/realneel _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org ----- End forwarded message ----- IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-net@FreeBSD.ORG Wed May 7 07:41:00 2008 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 271E81065671 for ; Wed, 7 May 2008 07:41:00 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id E71278FC0A for ; Wed, 7 May 2008 07:40:59 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 42FBBD8B9A; Wed, 7 May 2008 03:40:59 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 07 May 2008 03:40:59 -0400 X-Sasl-enc: PCIhEo071QonTiLvCFYXYxPdJ9OTznV1P+M2N2ieblYN 1210146058 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7E96F1075C; Wed, 7 May 2008 03:40:58 -0400 (EDT) Message-ID: <48215D08.5050500@incunabulum.net> Date: Wed, 07 May 2008 08:40:56 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Julian Elischer References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> In-Reply-To: <4821535B.8050001@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 07 May 2008 07:41:00 -0000 Julian Elischer wrote: > actually the divert sockets should really not be in PF_INET > they could deliver both inet and inet6 packets. > the sockaddr that they return (and which needs to be read for divert > to make sense) could be used to distinguish between them. Good point. I'd forgotten that they were abusing the fields in sin_zero. This is not OK for IPv6, although the kludge can still be perpetuated by looking at sa_len and stashing what divert wants at the end of sockaddr_in6. So there IS a case for making them a separate protocol family if someone's going to do a clean implementation of divert sockets for IPv6. cheers BMS From owner-freebsd-net@FreeBSD.ORG Wed May 7 08:05:07 2008 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 E91CE106567C for ; Wed, 7 May 2008 08:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9C3098FC15 for ; Wed, 7 May 2008 08:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C8F8041C713; Wed, 7 May 2008 10:05:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Y7qq+GXixUxV; Wed, 7 May 2008 10:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6664141C735; Wed, 7 May 2008 10:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4762B44487F; Wed, 7 May 2008 08:04:12 +0000 (UTC) Date: Wed, 7 May 2008 08:04:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Julian Elischer In-Reply-To: <4820C8CE.8010309@elischer.org> Message-ID: <20080507074647.B47338@maildrop.int.zabbadoz.net> References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> <4820C8CE.8010309@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 07 May 2008 08:05:08 -0000 On Tue, 6 May 2008, Julian Elischer wrote: Hi, > Bjoern A. Zeeb wrote: >> On Tue, 29 Apr 2008, Julian Elischer wrote: >> >> Hi, >> >>> The patch can be found at >>> http://www.freebsd.org/~julian/mrt.diff >>> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >>> >>> or source can be taken from perforce at: >>> //depot/user/julian/routing/src >> >> So after looking at the patch a bit more again, could you add wrapper >> functions for those like you have done for the old KPI (rtrequest, >> rtrequest1, > > do you really want to do the extra work instructions? > ... >> >> The defines will not give you a stable KPI and having that changed again >> if you are going with a prefix for each AF would be a pain if the _fib >> versions >> are going to change in the future. > > hmm fair enough... but let me outline my plans and thoughts > so we can see if you still want this.. > [ ... ] > > This all however is not ABI compatible so could not go back to 7.x > and I want to check in an initial version that can go back to 7.x > which sort of suggests to me that adding in_xxx functions is > not really required, until I do the next step. > 7.x will never get the next step. because the ABI is already set > in stone for 7.x. > > I would make the in_xxx stubs in the next step in 8.x. > after the MFC to 7.x of the ABI compat version. > > > let me know what you think. Leaving aside any upcoming enhancement if what we have now is what is going into 7 and possibly 6 we should do the wrapper functions. The point is RELENG_7 will live for $(last release + 2 years) so I guess till 2011 or maybe later. No idea what would happen there in all that time. If people start adding support for other AFs we cannot say that the *_fib variants are not going to change so having the in_* stable sounds like a good thing for 6 and 7. Am I missing anything obvious? I don't mind if they are going to significantly change again in 8 a few weeks later. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Wed May 7 18:05:13 2008 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 27CAB1065677 for ; Wed, 7 May 2008 18:05:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 160E98FC1D for ; Wed, 7 May 2008 18:05:12 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 07 May 2008 21:47:22 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 38D852D600F; Wed, 7 May 2008 11:05:12 -0700 (PDT) Message-ID: <4821EF57.9010600@elischer.org> Date: Wed, 07 May 2008 11:05:11 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> In-Reply-To: <48215706.8080508@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 18:05:13 -0000 Oleksandr Samoylyk wrote: > David DeSimone wrote: >> Julian Elischer wrote: >>> unfortunatly I've been totally ignoring this thread because it said >>> "trouble with em" in the topic.. >>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >> >> In the poster's defense, the only symptom that started this was this >> info from ps: >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% em0 >> taskq >> >> So tracking it down to mpd has been a process of elimination in figuring >> out why packets absorb so much CPU. >> > > Here is a result of profiling: > > http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html > 0.00 0.00 16/1643247 igmp_input [833] 0.03 0.01 614/1643247 icmp_input [272] 93.07 17.27 1642617/1643247 encap4_input [9] [10] 49.8 93.10 17.27 1643247 rip_input [10] 14.26 0.88 600796/749987 _mtx_lock_sleep [21] 0.16 1.70 1643863/1643863 raw_append [93] 0.00 0.24 36345/176995 _mtx_unlock_sleep [114] 0.01 0.00 1643863/5117962 jailed [278] 0.00 0.00 1292/1843 m_copym [666] 0.00 0.00 676/8214484 m_freem [34] 50% of time in rip_input??? that's unexpected.. what is the traffic? also: I see no netgraph in the profile at all. did you statically compile it all in at compile time? (you should if you want to see it) From owner-freebsd-net@FreeBSD.ORG Wed May 7 18:08:03 2008 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 D81BE1065672 for ; Wed, 7 May 2008 18:08:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outJ.internet-mail-service.net (outj.internet-mail-service.net [216.240.47.233]) by mx1.freebsd.org (Postfix) with ESMTP id C4BCA8FC27 for ; Wed, 7 May 2008 18:08:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 07 May 2008 21:50:12 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id ED1AB2D6004; Wed, 7 May 2008 11:08:02 -0700 (PDT) Message-ID: <4821F001.10208@elischer.org> Date: Wed, 07 May 2008 11:08:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <20080503100043.GA68835@k7.mavetju> <481F6AE1.5020408@elischer.org> <20080505231009.GX44028@k7.mavetju> <481F95DE.6090201@elischer.org> <4821330E.8030101@incunabulum.net> <4821535B.8050001@elischer.org> <48215D08.5050500@incunabulum.net> In-Reply-To: <48215D08.5050500@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Edwin Groothuis Subject: Re: IPPROTO_DIVERT and PF_INET6 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, 07 May 2008 18:08:03 -0000 Bruce M. Simpson wrote: > Julian Elischer wrote: >> actually the divert sockets should really not be in PF_INET >> they could deliver both inet and inet6 packets. >> the sockaddr that they return (and which needs to be read for divert >> to make sense) could be used to distinguish between them. > > Good point. I'd forgotten that they were abusing the fields in sin_zero. "they" == "me" :-) if we made it its own protocol family we could define our own sockaddr types too and have actual fields for that stuff... > This is not OK for IPv6, although the kludge can still be perpetuated by > looking at sa_len and stashing what divert wants at the end of > sockaddr_in6. > > So there IS a case for making them a separate protocol family if > someone's going to do a clean implementation of divert sockets for IPv6. > > cheers > BMS From owner-freebsd-net@FreeBSD.ORG Wed May 7 18:16:54 2008 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 28253106567F for ; Wed, 7 May 2008 18:16:54 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id D859B8FC15 for ; Wed, 7 May 2008 18:16:53 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id E9BF710069; Wed, 7 May 2008 21:16:50 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 5378EB81B; Wed, 7 May 2008 21:16:35 +0300 (EEST) Message-ID: <4821F206.10606@samoylyk.sumy.ua> Date: Wed, 07 May 2008 21:16:38 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julian Elischer References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> In-Reply-To: <4821EF57.9010600@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 18:16:54 -0000 Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> David DeSimone wrote: >>> Julian Elischer wrote: >>>> unfortunatly I've been totally ignoring this thread because it said >>>> "trouble with em" in the topic.. >>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>> >>> In the poster's defense, the only symptom that started this was this >>> info from ps: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>> COMMAND >>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>> em0 taskq >>> >>> So tracking it down to mpd has been a process of elimination in figuring >>> out why packets absorb so much CPU. >>> >> >> Here is a result of profiling: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >> > > > 0.00 0.00 16/1643247 igmp_input [833] > 0.03 0.01 614/1643247 icmp_input [272] > 93.07 17.27 1642617/1643247 encap4_input [9] > [10] 49.8 93.10 17.27 1643247 rip_input [10] > 14.26 0.88 600796/749987 _mtx_lock_sleep [21] > 0.16 1.70 1643863/1643863 raw_append [93] > 0.00 0.24 36345/176995 _mtx_unlock_sleep > [114] > 0.01 0.00 1643863/5117962 jailed [278] > 0.00 0.00 1292/1843 m_copym [666] > 0.00 0.00 676/8214484 m_freem [34] > > > > 50% of time in rip_input??? > > that's unexpected.. what is the traffic? more than 20k pps # netstat -I em0 -w 1 input (em0) output packets errs bytes packets errs bytes colls 22247 0 10767499 21079 0 13741924 0 21356 0 10535580 20288 0 13014669 0 21871 0 10565622 20586 0 13165147 0 21894 0 10495771 20964 0 13806336 0 21303 0 10496544 19682 0 12659588 0 21643 0 10561207 20140 0 12692946 0 21534 0 10304466 20289 0 13460444 0 ^C > also: > > I see no netgraph in the profile at all. > did you statically compile it all in at compile time? (you should if you > want to see it) > Tried both variants. Now not statically. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Wed May 7 19:41:44 2008 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 E05B4106566B for ; Wed, 7 May 2008 19:41:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id CCF188FC13 for ; Wed, 7 May 2008 19:41:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 07 May 2008 23:23:55 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1945F2D6006; Wed, 7 May 2008 12:41:44 -0700 (PDT) Message-ID: <482205F7.4010503@elischer.org> Date: Wed, 07 May 2008 12:41:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> In-Reply-To: <4821F206.10606@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 19:41:45 -0000 Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> Oleksandr Samoylyk wrote: >>> David DeSimone wrote: >>>> Julian Elischer wrote: >>>>> unfortunatly I've been totally ignoring this thread because it said >>>>> "trouble with em" in the topic.. >>>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>>> >>>> In the poster's defense, the only symptom that started this was this >>>> info from ps: >>>> >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>> COMMAND >>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>> em0 taskq >>>> >>>> So tracking it down to mpd has been a process of elimination in >>>> figuring >>>> out why packets absorb so much CPU. >>>> >>> >>> Here is a result of profiling: >>> >>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>> >> >> >> 0.00 0.00 16/1643247 igmp_input [833] >> 0.03 0.01 614/1643247 icmp_input [272] >> 93.07 17.27 1642617/1643247 encap4_input [9] >> [10] 49.8 93.10 17.27 1643247 rip_input [10] >> 14.26 0.88 600796/749987 _mtx_lock_sleep >> [21] >> 0.16 1.70 1643863/1643863 raw_append [93] >> 0.00 0.24 36345/176995 _mtx_unlock_sleep >> [114] >> 0.01 0.00 1643863/5117962 jailed [278] >> 0.00 0.00 1292/1843 m_copym [666] >> 0.00 0.00 676/8214484 m_freem [34] >> >> >> >> 50% of time in rip_input??? >> >> that's unexpected.. what is the traffic? > > > more than 20k pps I mean, what KIND of traffic? I'm surprised it 's calling rip_input().. why is it calling encap4_input()? (which calls rip_input).. what is the IP protocol of all these packets? what does a small snippet of traffic show? (tcpdump -i em0 -s0 -e -n -c 64) > >> I see no netgraph in the profile at all. >> did you statically compile it all in at compile time? (you should if >> you want to see it) >> > > Tried both variants. Now not statically. make sure it is static and that the netgraph nodes are all compiled with -pg > From owner-freebsd-net@FreeBSD.ORG Wed May 7 19:46:04 2008 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 4FBEA106564A for ; Wed, 7 May 2008 19:46:04 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id AE8288FC0C for ; Wed, 7 May 2008 19:46:03 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 2AE57B829; Wed, 7 May 2008 22:46:01 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id C9A9FB81B; Wed, 7 May 2008 22:45:46 +0300 (EEST) Message-ID: <482206EE.2050904@samoylyk.sumy.ua> Date: Wed, 07 May 2008 22:45:50 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julian Elischer References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> In-Reply-To: <482205F7.4010503@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 19:46:04 -0000 Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> Oleksandr Samoylyk wrote: >>>> David DeSimone wrote: >>>>> Julian Elischer wrote: >>>>>> unfortunatly I've been totally ignoring this thread because it said >>>>>> "trouble with em" in the topic.. >>>>>> If you'd said "trouble with mpd" then maybe I'd have looked earlier.. >>>>> >>>>> In the poster's defense, the only symptom that started this was this >>>>> info from ps: >>>>> >>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>> COMMAND >>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>>> em0 taskq >>>>> >>>>> So tracking it down to mpd has been a process of elimination in >>>>> figuring >>>>> out why packets absorb so much CPU. >>>>> >>>> >>>> Here is a result of profiling: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>> >>> >>> >>> 0.00 0.00 16/1643247 igmp_input [833] >>> 0.03 0.01 614/1643247 icmp_input [272] >>> 93.07 17.27 1642617/1643247 encap4_input [9] >>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>> 14.26 0.88 600796/749987 _mtx_lock_sleep >>> [21] >>> 0.16 1.70 1643863/1643863 raw_append [93] >>> 0.00 0.24 36345/176995 _mtx_unlock_sleep >>> [114] >>> 0.01 0.00 1643863/5117962 jailed [278] >>> 0.00 0.00 1292/1843 m_copym [666] >>> 0.00 0.00 676/8214484 m_freem [34] >>> >>> >>> >>> 50% of time in rip_input??? >>> >>> that's unexpected.. what is the traffic? >> >> >> more than 20k pps > > I mean, what KIND of traffic? > I'm surprised it 's calling rip_input().. why is it calling > encap4_input()? (which calls rip_input).. what is the IP protocol > of all these packets? > > what does a small snippet of traffic show? > > (tcpdump -i em0 -s0 -e -n -c 64) GRE (pptp-tunnels) tcpdump -i em0 -s0 -e -n -c 64 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P 3482978131:3482978327(196) ack 537019550 win 128 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) ack 239105401 win 58593 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 195.91.147.100.62073 > 77.120.205.18.43463: . 2979675127:2979676487(1360) ack 3166103641 win 65212 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 win 17680 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack 1841830, no-payload, proto PPP (0x880b), length 12 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) ack 3056545326 win 32254 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 win 65212 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack 1687270, no-payload, proto PPP (0x880b), length 12 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: seq 0x039, Flags [begin], length 1400 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq 0x039, Flags [end], length 9 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) ack 1774495680 win 16384 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack 337838744 win 6970 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . 2176487112:2176488472(1360) ack 921656808 win 16446 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win 16446 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack 145663, no-payload, proto PPP (0x880b), length 12 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) ack 1545362008 win 65535 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack 145664, no-payload, proto PPP (0x880b), length 12 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win 32502 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 >> >>> I see no netgraph in the profile at all. >>> did you statically compile it all in at compile time? (you should if >>> you want to see it) >>> >> >> Tried both variants. Now not statically. > > make sure it is static and that the netgraph nodes are all compiled with > -pg > I'll try, but a bit later. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Wed May 7 19:58:31 2008 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 CE1E7106564A for ; Wed, 7 May 2008 19:58:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id B75A08FC15 for ; Wed, 7 May 2008 19:58:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 07 May 2008 23:40:42 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B19642D6017; Wed, 7 May 2008 12:58:30 -0700 (PDT) Message-ID: <482209E5.7010607@elischer.org> Date: Wed, 07 May 2008 12:58:29 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> In-Reply-To: <482206EE.2050904@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 19:58:31 -0000 Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> Oleksandr Samoylyk wrote: >>> Julian Elischer wrote: >>>> Oleksandr Samoylyk wrote: >>>>> David DeSimone wrote: >>>>>> Julian Elischer wrote: >>>>>>> unfortunatly I've been totally ignoring this thread because it said >>>>>>> "trouble with em" in the topic.. >>>>>>> If you'd said "trouble with mpd" then maybe I'd have looked >>>>>>> earlier.. >>>>>> >>>>>> In the poster's defense, the only symptom that started this was this >>>>>> info from ps: >>>>>> >>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>>> COMMAND >>>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 100.00% >>>>>> em0 taskq >>>>>> >>>>>> So tracking it down to mpd has been a process of elimination in >>>>>> figuring >>>>>> out why packets absorb so much CPU. >>>>>> >>>>> >>>>> Here is a result of profiling: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>>> >>>> >>>> >>>> 0.00 0.00 16/1643247 igmp_input [833] >>>> 0.03 0.01 614/1643247 icmp_input [272] >>>> 93.07 17.27 1642617/1643247 encap4_input [9] >>>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>>> 14.26 0.88 600796/749987 >>>> _mtx_lock_sleep [21] >>>> 0.16 1.70 1643863/1643863 raw_append [93] >>>> 0.00 0.24 36345/176995 _mtx_unlock_sleep >>>> [114] >>>> 0.01 0.00 1643863/5117962 jailed [278] >>>> 0.00 0.00 1292/1843 m_copym [666] >>>> 0.00 0.00 676/8214484 m_freem [34] >>>> >>>> >>>> >>>> 50% of time in rip_input??? >>>> >>>> that's unexpected.. what is the traffic? >>> >>> >>> more than 20k pps >> >> I mean, what KIND of traffic? >> I'm surprised it 's calling rip_input().. why is it calling >> encap4_input()? (which calls rip_input).. what is the IP protocol >> of all these packets? >> >> what does a small snippet of traffic show? >> >> (tcpdump -i em0 -s0 -e -n -c 64) > > > GRE (pptp-tunnels) > > tcpdump -i em0 -s0 -e -n -c 64 > > 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P > 3482978131:3482978327(196) ack 537019550 win 128 > 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq > 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) > ack 239105401 win 58593 > 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq > 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 195.91.147.100.62073 > 77.120.205.18.43463: . > 2979675127:2979676487(1360) ack 3166103641 win 65212 > 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq > 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), length > 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 win > 17680 > 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq > 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win 58593 > 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack > 1841830, no-payload, proto PPP (0x880b), length 12 > 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq > 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) > ack 3056545326 win 32254 > 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq > 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 win > 65212 > 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq > 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: > 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 > 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq > 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), length > 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 > 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack > 1687270, no-payload, proto PPP (0x880b), length 12 > 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq > 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: > 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 > 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq > 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: > seq 0x039, Flags [begin], length 1400 > 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq > 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq > 0x039, Flags [end], length 9 > 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq > 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: > 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) ack > 1774495680 win 16384 > 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq > 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: > 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack > 337838744 win 6970 > 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq > 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), length > 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . > 2176487112:2176488472(1360) ack 921656808 win 16446 > 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq > 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win 16446 > 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack > 145663, no-payload, proto PPP (0x880b), length 12 > 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq > 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) ack > 1545362008 win 65535 > 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack > 145664, no-payload, proto PPP (0x880b), length 12 > 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq > 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: > 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 > 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 > (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq > 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: > 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win 32502 > > 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq > 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length > 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 > 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 > (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 > >>> >>>> I see no netgraph in the profile at all. >>>> did you statically compile it all in at compile time? (you should if >>>> you want to see it) >>>> >>> >>> Tried both variants. Now not statically. >> >> make sure it is static and that the netgraph nodes are all compiled >> with -pg >> > > I'll try, but a bit later. ok so we get somewhere.. GRE.. looks like UDP in PPP in GRE is this a pptp session? this may be the issue: http://www.nabble.com/GRE-Mux-td16201899.html > From owner-freebsd-net@FreeBSD.ORG Wed May 7 20:03:36 2008 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 4C19B106564A for ; Wed, 7 May 2008 20:03:36 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.net [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id D3D648FC1A for ; Wed, 7 May 2008 20:03:34 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu ([151.77.252.30]) (authenticated bits=128) by parrot.aev.net (8.14.2/8.13.8) with ESMTP id m47JasNk033133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 May 2008 21:37:05 +0200 (CEST) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.2/8.14.2) with ESMTP id m47JUohj077669 for ; Wed, 7 May 2008 21:30:50 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <48220305.7010605@netfence.it> Date: Wed, 07 May 2008 21:29:09 +0200 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.14 (X11/20080504) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 212.31.247.179 Subject: Routing problem with aliases 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, 07 May 2008 20:03:36 -0000 Hello. A box of mine has an interface configured with two IPs on two different nets: # ifconfig xl0: flags=8943 mtu 1500 options=9 inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:50:da:77:5f:79 media: Ethernet autoselect (100baseTX ) status: active Then I have two gateways: 192.168.2.1 and 192.168.0.6. "ping 192.168.2.1" works correctly (source address 192.168.2.2 is used) "ping 192.168.0.6" also does (source address 192.168.0.2 is used) Setting 192.168.2.1 as my default gateway allows me to ping any host on the Internet (again source address 192.168.2.2 is used). However, if I set 192.168.0.6 as the default router, I can't reach the Internet, since it uses source address 192.168.2.2 and the next router won't obviously like it. Is this normal behaviour? Anything to set or check? Any other hint? Perhaps I should mention that I also have some carp devices on that interface, but I'm not sure whether it matters. bye & Thanks av. From owner-freebsd-net@FreeBSD.ORG Wed May 7 20:37:17 2008 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 69FDE106567C; Wed, 7 May 2008 20:37:17 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 435F58FC26; Wed, 7 May 2008 20:37:17 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m47KbHal044525; Wed, 7 May 2008 20:37:17 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m47KbGc6044521; Wed, 7 May 2008 20:37:16 GMT (envelope-from vwe) Date: Wed, 7 May 2008 20:37:16 GMT Message-Id: <200805072037.m47KbGc6044521@freefall.freebsd.org> To: adam@mhm.lv, vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN 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, 07 May 2008 20:37:17 -0000 Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Wed May 7 20:33:44 UTC 2008 State-Changed-Why: It appears there's no PHY attached but from your dmesg I would expect bge0 to cause trouble. Can you please post output of `pciconf -lv | grep -A 3 bge'? I think the -net maintainers will be able to see the relevant pieces from that output. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From owner-freebsd-net@FreeBSD.ORG Wed May 7 21:00:41 2008 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 B6A9D106567B; Wed, 7 May 2008 21:00:41 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA5F8FC1D; Wed, 7 May 2008 21:00:41 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m47L0fsH045210; Wed, 7 May 2008 21:00:41 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m47L0fAj045206; Wed, 7 May 2008 21:00:41 GMT (envelope-from vwe) Date: Wed, 7 May 2008 21:00:41 GMT Message-Id: <200805072100.m47L0fAj045206@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123463: [panic] repeatable crash related to ipsec-tools 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, 07 May 2008 21:00:41 -0000 Old Synopsis: repeatable crash related to ipsec-tools New Synopsis: [panic] repeatable crash related to ipsec-tools Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Wed May 7 21:00:12 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123463 From owner-freebsd-net@FreeBSD.ORG Wed May 7 21:01:25 2008 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 99C7E1065673 for ; Wed, 7 May 2008 21:01:25 +0000 (UTC) (envelope-from adam@mhm.lv) Received: from mhm.lv (mail.mhm.lv [80.81.39.2]) by mx1.freebsd.org (Postfix) with SMTP id BBAB58FC1A for ; Wed, 7 May 2008 21:01:24 +0000 (UTC) (envelope-from adam@mhm.lv) Received: (qmail 25090 invoked by uid 2853); 7 May 2008 21:31:55 -0000 Received: from 80.81.39.85 by mail.mhm.lv (envelope-from , uid 2850) with qmail-scanner-1.24 ( Clear:RC:1(80.81.39.85):. Processed in 1.016646 secs); 07 May 2008 21:31:55 -0000 Received: from unknown (HELO homee7979e67c1) (80.81.39.85) by mail.mhm.lv with SMTP; 7 May 2008 21:31:53 -0000 Message-ID: <00ad01c8b085$815e77d0$55275150@homee7979e67c1> From: To: Date: Thu, 8 May 2008 00:01:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Fw: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN 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, 07 May 2008 21:01:25 -0000 As a follow-up to my previous output, this is also my custom kernel, just in case: #---------------------------------------------------------------------------------------- # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # FreeBSD 6.3-RELEASE # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.14.2.1 2007/12/15 06:32:32 scottl Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident GBRT2 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 #options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. #To make an SMP kernel, the next two are required options SMP device apic # I/O APIC #IPFIREWALL options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options DUMMYNET options HZ=2000 # Bus support. device eisa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals #device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse #device kbdmux # keyboard multiplexer device vga # VGA video card driver #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. #device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) #----------------------------------------------------------------------------- ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, May 07, 2008 11:44 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > Sure! Here you are! > > GBRT2# pciconf -lv | grep -A 3 bge > bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' > class = network > -- > bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' > class = network > GBRT2# > > ----- Original Message ----- > From: > To: ; ; ; > > Sent: Wednesday, May 07, 2008 11:37 PM > Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate > changed to DOWN > > >> Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN >> >> State-Changed-From-To: open->feedback >> State-Changed-By: vwe >> State-Changed-When: Wed May 7 20:33:44 UTC 2008 >> State-Changed-Why: >> >> It appears there's no PHY attached but from your dmesg I would expect >> bge0 to cause trouble. >> Can you please post output of `pciconf -lv | grep -A 3 bge'? >> I think the -net maintainers will be able to see the relevant pieces >> from that output. >> >> >> Responsible-Changed-From-To: freebsd-bugs->freebsd-net >> Responsible-Changed-By: vwe >> Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 >> Responsible-Changed-Why: >> >> Over to maintainer(s). >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 > From owner-freebsd-net@FreeBSD.ORG Wed May 7 21:10:53 2008 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 F03F41065670 for ; Wed, 7 May 2008 21:10:53 +0000 (UTC) (envelope-from adam@mhm.lv) Received: from mhm.lv (mail.mhm.lv [80.81.39.2]) by mx1.freebsd.org (Postfix) with SMTP id 547CC8FC15 for ; Wed, 7 May 2008 21:10:52 +0000 (UTC) (envelope-from adam@mhm.lv) Received: (qmail 10878 invoked by uid 2853); 7 May 2008 21:14:43 -0000 Received: from 80.81.39.85 by mail.mhm.lv (envelope-from , uid 2850) with qmail-scanner-1.24 ( Clear:RC:1(80.81.39.85):. Processed in 0.80655 secs); 07 May 2008 21:14:43 -0000 Received: from unknown (HELO homee7979e67c1) (80.81.39.85) by mail.mhm.lv with SMTP; 7 May 2008 21:14:42 -0000 Message-ID: <009401c8b083$1aafeac0$55275150@homee7979e67c1> From: To: References: <200805072037.m47KbGc6044521@freefall.freebsd.org> Date: Wed, 7 May 2008 23:44:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN 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, 07 May 2008 21:10:54 -0000 Sure! Here you are! GBRT2# pciconf -lv | grep -A 3 bge bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' class = network -- bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# ----- Original Message ----- From: To: ; ; ; Sent: Wednesday, May 07, 2008 11:37 PM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN > > State-Changed-From-To: open->feedback > State-Changed-By: vwe > State-Changed-When: Wed May 7 20:33:44 UTC 2008 > State-Changed-Why: > > It appears there's no PHY attached but from your dmesg I would expect > bge0 to cause trouble. > Can you please post output of `pciconf -lv | grep -A 3 bge'? > I think the -net maintainers will be able to see the relevant pieces > from that output. > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: vwe > Responsible-Changed-When: Wed May 7 20:33:44 UTC 2008 > Responsible-Changed-Why: > > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From owner-freebsd-net@FreeBSD.ORG Wed May 7 21:42:28 2008 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 7A1BC106564A for ; Wed, 7 May 2008 21:42:28 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id D481D8FC0C for ; Wed, 7 May 2008 21:42:27 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id CB347B827; Thu, 8 May 2008 00:42:25 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, WHOIS_MYPRIVREG=0.156] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 3CF45B81B; Thu, 8 May 2008 00:42:11 +0300 (EEST) Message-ID: <48222236.5090802@samoylyk.sumy.ua> Date: Thu, 08 May 2008 00:42:14 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Julian Elischer References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> <482209E5.7010607@elischer.org> In-Reply-To: <482209E5.7010607@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 07 May 2008 21:42:28 -0000 Julian Elischer wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> Oleksandr Samoylyk wrote: >>>> Julian Elischer wrote: >>>>> Oleksandr Samoylyk wrote: >>>>>> David DeSimone wrote: >>>>>>> Julian Elischer wrote: >>>>>>>> unfortunatly I've been totally ignoring this thread because it >>>>>>>> said >>>>>>>> "trouble with em" in the topic.. >>>>>>>> If you'd said "trouble with mpd" then maybe I'd have looked >>>>>>>> earlier.. >>>>>>> >>>>>>> In the poster's defense, the only symptom that started this was this >>>>>>> info from ps: >>>>>>> >>>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>>>>>> COMMAND >>>>>>> 29 root 1 -68 - 0K 16K CPU5 5 196:41 >>>>>>> 100.00% em0 taskq >>>>>>> >>>>>>> So tracking it down to mpd has been a process of elimination in >>>>>>> figuring >>>>>>> out why packets absorb so much CPU. >>>>>>> >>>>>> >>>>>> Here is a result of profiling: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2008-May/017901.html >>>>>> >>>>> >>>>> >>>>> 0.00 0.00 16/1643247 igmp_input [833] >>>>> 0.03 0.01 614/1643247 icmp_input [272] >>>>> 93.07 17.27 1642617/1643247 encap4_input [9] >>>>> [10] 49.8 93.10 17.27 1643247 rip_input [10] >>>>> 14.26 0.88 600796/749987 >>>>> _mtx_lock_sleep [21] >>>>> 0.16 1.70 1643863/1643863 raw_append [93] >>>>> 0.00 0.24 36345/176995 >>>>> _mtx_unlock_sleep >>>>> [114] >>>>> 0.01 0.00 1643863/5117962 jailed [278] >>>>> 0.00 0.00 1292/1843 m_copym [666] >>>>> 0.00 0.00 676/8214484 m_freem [34] >>>>> >>>>> >>>>> >>>>> 50% of time in rip_input??? >>>>> >>>>> that's unexpected.. what is the traffic? >>>> >>>> >>>> more than 20k pps >>> >>> I mean, what KIND of traffic? >>> I'm surprised it 's calling rip_input().. why is it calling >>> encap4_input()? (which calls rip_input).. what is the IP protocol >>> of all these packets? >>> >>> what does a small snippet of traffic show? >>> >>> (tcpdump -i em0 -s0 -e -n -c 64) >> >> >> GRE (pptp-tunnels) >> >> tcpdump -i em0 -s0 -e -n -c 64 >> >> 22:43:28.818558 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 250: 10.0.0.8.22 > 10.0.14.191.3513: P >> 3482978131:3482978327(196) ack 537019550 win 128 >> 22:43:28.818892 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq >> 949074, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 89.252.42.44.40002 > 77.120.207.229.3038: . 588169704:588171064(1360) >> ack 239105401 win 58593 >> 22:43:28.819014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq >> 28109460, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 195.91.147.100.62073 > 77.120.205.18.43463: . >> 2979675127:2979676487(1360) ack 3166103641 win 65212 >> 22:43:28.819016 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 111: 10.0.197.49 > 10.0.0.8: GREv1, call 39317, seq >> 1841830, ack 2346966, proto PPP (0x880b), length 77: IP (0x0021), >> length 61: 77.120.205.65.1109 > 89.254.129.137.63441: . ack 2160932834 >> win 17680 >> 22:43:28.819025 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.113.178: GREv1, call 256, seq >> 949075, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 89.252.42.44.40002 > 77.120.207.229.3038: . 1360:2720(1360) ack 1 win >> 58593 >> 22:43:28.819109 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.197.49: GREv1, call 16384, ack >> 1841830, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.819152 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq >> 2854449, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 88.81.240.172.80 > 77.120.206.140.3573: . 2985100912:2985102272(1360) >> ack 3056545326 win 32254 >> 22:43:28.819259 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.34.188: GREv1, call 0, seq >> 28109461, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 195.91.147.100.62073 > 77.120.205.18.43463: . 1360:2720(1360) ack 1 >> win 65212 >> 22:43:28.819632 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 87: 10.0.0.8 > 10.0.3.36: GREv1, call 33358, seq >> 809410, proto PPP (0x880b), length 53: IP (0x0021), length 41: >> 89.189.135.94.29934 > 77.120.205.175.64039: . ack 980726719 win 65535 >> 22:43:28.820102 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 91: 10.0.7.198 > 10.0.0.8: GREv1, call 42872, seq >> 1687270, ack 2854449, proto PPP (0x880b), length 57: IP (0x0021), >> length 41: 77.120.206.140.3573 > 88.81.240.172.80: . ack 1360 win 65535 >> 22:43:28.820172 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, ack >> 1687270, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.820255 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 461: 10.0.0.8 > 10.0.7.198: GREv1, call 32768, seq >> 2854450, proto PPP (0x880b), length 427: IP (0x0021), length 415: >> 88.81.240.172.80 > 77.120.206.140.3573: . 1360:1734(374) ack 1 win 32254 >> 22:43:28.820382 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq >> 3749540, proto PPP (0x880b), length 1413: MLPPP (0x003d), length 1401: >> seq 0x039, Flags [begin], length 1400 >> 22:43:28.820386 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 56: 10.0.0.8 > 10.0.42.36: GREv1, call 16384, seq >> 3749541, proto PPP (0x880b), length 22: MLPPP (0x003d), length 10: seq >> 0x039, Flags [end], length 9 >> 22:43:28.820510 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 259: 10.0.0.8 > 10.0.166.29: GREv1, call 256, seq >> 18113, proto PPP (0x880b), length 225: IP (0x0021), length 213: >> 205.188.248.197.80 > 77.120.205.253.1192: P 298024346:298024518(172) >> ack 1774495680 win 16384 >> 22:43:28.820514 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 87: 10.0.0.8 > 10.0.141.78: GREv1, call 32768, seq >> 51008, proto PPP (0x880b), length 53: IP (0x0021), length 41: >> 67.228.189.192.80 > 77.120.207.6.3857: F 98423782:98423782(0) ack >> 337838744 win 6970 >> 22:43:28.820894 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 1451: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq >> 145663, ack 88392, proto PPP (0x880b), length 1417: IP (0x0021), >> length 1401: 77.120.206.128.3591 > 89.178.5.14.22979: . >> 2176487112:2176488472(1360) ack 921656808 win 16446 >> 22:43:28.820972 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 1447: 10.0.162.204 > 10.0.0.8: GREv1, call 41673, seq >> 145664, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 77.120.206.128.3591 > 89.178.5.14.22979: . 1360:2720(1360) ack 1 win >> 16446 >> 22:43:28.821014 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack >> 145663, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.821020 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq >> 39341, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 80.93.56.145.80 > 77.120.206.211.3811: . 1861143175:1861144535(1360) >> ack 1545362008 win 65535 >> 22:43:28.821068 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 46: 10.0.0.8 > 10.0.162.204: GREv1, call 256, ack >> 145664, no-payload, proto PPP (0x880b), length 12 >> 22:43:28.821134 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 1447: 10.0.0.8 > 10.0.4.108: GREv1, call 32768, seq >> 39342, proto PPP (0x880b), length 1413: IP (0x0021), length 1401: >> 80.93.56.145.80 > 77.120.206.211.3811: . 1360:2720(1360) ack 1 win 65535 >> 22:43:28.821264 00:19:d1:03:ce:7e > 00:12:cf:53:61:30, ethertype IPv4 >> (0x0800), length 99: 10.0.0.8 > 10.0.75.234: GREv1, call 16384, seq >> 414573, proto PPP (0x880b), length 65: IP (0x0021), length 53: >> 201.246.146.143.55045 > 77.120.205.245.53009: . ack 1074482170 win >> 32502 >> 22:43:28.821593 00:11:92:c5:a7:40 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 106: 10.0.163.116 > 10.0.0.8: GREv1, call 46363, seq >> 165235, ack 106705, proto PPP (0x880b), length 72: IP (0x0021), length >> 56: 77.120.206.91.27005 > 194.50.85.251.27017: UDP, length 27 >> 22:43:28.821670 00:19:55:d0:df:c0 > 00:19:d1:03:ce:7e, ethertype IPv4 >> (0x0800), length 60: 10.0.14.191.3513 > 10.0.0.8.22: . ack 196 win 64240 >> >>>> >>>>> I see no netgraph in the profile at all. >>>>> did you statically compile it all in at compile time? (you should >>>>> if you want to see it) >>>>> >>>> >>>> Tried both variants. Now not statically. >>> >>> make sure it is static and that the netgraph nodes are all compiled >>> with -pg >>> >> >> I'll try, but a bit later. > > ok so we get somewhere.. GRE.. > > looks like UDP in PPP in GRE > > is this a pptp session? Yes. > this may be the issue: > http://www.nabble.com/GRE-Mux-td16201899.html > I think so. Should we hope for some progress in this direction in future? -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Wed May 7 21:49:04 2008 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 9BEA61065670; Wed, 7 May 2008 21:49:04 +0000 (UTC) (envelope-from prvs=10136994e7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D420D8FC16; Wed, 7 May 2008 21:49:03 +0000 (UTC) (envelope-from prvs=10136994e7=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1210195750; x=1210800550; q=dns/txt; h=Received: Message-ID:From:To:Cc:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=7no/sCaxmQMltmkXihU6g a4rJC3aDdnUf2nnysH9P7Y=; b=LFvO2G5ukBgllrkL+qa1Kvt4zqrmKAF5MrsE0 Q1W51TYXUPXVID/4a6ecL5G/P5P+feRUok0dkjX7IWhmbWd/lp+REzzASbWI++vS ZLlVSl/pkD7xt/fVwBI6BfY4xpWtLAfOQXN8K+bu3rxTENBaR0CQv8xBlIJIM842 yk7Zs4= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.5) with ESMTP id md50005591313.msg; Wed, 07 May 2008 22:29:09 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 212.135.219.182 X-Return-Path: prvs=10136994e7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> From: "Steven Hartland" To: , References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> Date: Wed, 7 May 2008 22:29:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 07 May 2008 22:29:09 +0100 X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 07 May 2008 22:29:10 +0100 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN 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, 07 May 2008 21:49:04 -0000 Does this really warrant a high priority flag? ----- Original Message ----- From: > Sure! Here you are! > > GBRT2# pciconf -lv | grep -A 3 bge > bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' > class = network ... ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed May 7 22:01:33 2008 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 60FCC106568C for ; Wed, 7 May 2008 22:01:33 +0000 (UTC) (envelope-from adam@mhm.lv) Received: from mhm.lv (mail.mhm.lv [80.81.39.2]) by mx1.freebsd.org (Postfix) with SMTP id B63078FC1A for ; Wed, 7 May 2008 22:01:31 +0000 (UTC) (envelope-from adam@mhm.lv) Received: (qmail 32148 invoked by uid 2853); 7 May 2008 22:32:03 -0000 Received: from 80.81.39.85 by mail.mhm.lv (envelope-from , uid 2850) with qmail-scanner-1.24 ( Clear:RC:1(80.81.39.85):. Processed in 0.923863 secs); 07 May 2008 22:32:03 -0000 Received: from unknown (HELO homee7979e67c1) (80.81.39.85) by mail.mhm.lv with SMTP; 7 May 2008 22:32:01 -0000 Message-ID: <146401c8b08d$e7bf2440$55275150@homee7979e67c1> From: To: "Steven Hartland" References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> Date: Thu, 8 May 2008 01:01:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org, vwe@FreeBSD.org Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN 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, 07 May 2008 22:01:33 -0000 I guess it does, since this nightmere is being reported with different NICs and drivers including Intel NICs on em driver and 3Com NICs on bge and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. The mailing list if full of too many questions regarding this issue and no answer! If it realy doesn't worth a high priority flag, then I do appolgize and I shoud fall back to 4.11-RELEASE which worked on the same hardware like a sandwatch! http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 ----- Original Message ----- From: "Steven Hartland" To: ; Cc: ; Sent: Thursday, May 08, 2008 12:29 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN > Does this really warrant a high priority flag? > > ----- Original Message ----- > From: > >> Sure! Here you are! >> >> GBRT2# pciconf -lv | grep -A 3 bge >> bge0@pci5:1:0: class=0x020000 card=0x100410b7 chip=0x164514e4 rev=0x15 >> hdr=0x00 >> vendor = 'Broadcom Corporation' >> device = 'BCM5701 NetXtreme BCM5701 Gigabit Ethernet' >> class = network > ... > -- bge1@pci5:2:0: class=0x020000 card=0x100010b7 chip=0x164414e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5751F NetXtreme Gigabit Ethernet Controller' class = network GBRT2# > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing or > otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-net@FreeBSD.ORG Wed May 7 22:54:26 2008 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 4CEAB106568B for ; Wed, 7 May 2008 22:54:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id AF93A8FC15 for ; Wed, 7 May 2008 22:54:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 54307 invoked from network); 7 May 2008 21:56:11 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 May 2008 21:56:10 -0000 Message-ID: <48223324.6070203@freebsd.org> Date: Thu, 08 May 2008 00:54:28 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Deng XueFeng , Mark Hills References: <20080506133208.C2EC.B627C632@gmail.com> In-Reply-To: <20080506133208.C2EC.B627C632@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 07 May 2008 22:54:26 -0000 I've looked at the code paths again. There are two possibilities: a) the mbuf allocator has some anomaly where it rejects memory requests but doesn't update the statistics (the code is there however). b) the error doesn't come from the mbuf allocation but from ip_output() and further down the chain. To differentiate please try this updated patch and report the log output again (don't forget to set net.inet.tcp.log_debug=1): http://people.freebsd.org/~andre/tcp_output-error-log.diff -- Andre Deng XueFeng wrote: > hi > I'am also meet this problem in my mss server(missey streaming server). > one encoder push stream to mss, then run 100 client player playing the > sream, as the client number increase, mss will occur this error sooner or later > like this: > I'am using kqueue, and will got a event with EV_EOF and fflags = > ETIMEDOUT, > if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), > > and the tcpdump also show that server will send RST packet to encoder. > > >> Hello, >> >> I'm are having a trouble with TCP connections being dropped with "read: >> Operation timed out". What is unusual is that this is happening right in >> the middle of sending a steady stream of data with no network congestion. >> >> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit >> connection. The server receives a 192kbps inbound stream over TCP, and >> broadcasts it over a large number of TCP streams. >> >> With no visible or obvious pattern, the inbound read() fails with >> ETIMEDOUT. The likelihood of this happening seems to increase as the >> number of audience connections increases. It's happens every few minutes >> even with a small audience (eg. 300 outbound connections and about >> 60mbit). >> >> It doesn't cough and splutter -- steady data is coming in, then it just >> drops the connection. >> >> systat doesn't show problems inbound; all packets received are delivered >> to the upper layer. But on outbound, there is consistent 'output drops': >> >> IP Output >> 7028 total packets sent >> 7028 - generated locally >> 314 - output drops >> >> As the number of outbound connections increases, the 'output drops' >> increases to around 10% of the total packets sent and maintains that >> ratio. There's no problems with network capacity. >> >> I've tried different servers, different network interfaces (bge, em), >> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats >> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat >> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen >> in a dedicated, uncontended test environment. >> >> Can anyone explain why the packets are being dropped outbound, and how >> this could affect inbound TCP data in such an abrupt way? What can I do to >> solve this? >> >> Thanks, >> >> Mark >> _______________________________________________ >> 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 Wed May 7 23:21:21 2008 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 E0CA31065680 for ; Wed, 7 May 2008 23:21:21 +0000 (UTC) (envelope-from adam@mhm.lv) Received: from mhm.lv (mail.mhm.lv [80.81.39.2]) by mx1.freebsd.org (Postfix) with SMTP id 0935E8FC1C for ; Wed, 7 May 2008 23:21:20 +0000 (UTC) (envelope-from adam@mhm.lv) Received: (qmail 30408 invoked by uid 2853); 7 May 2008 23:51:52 -0000 Received: from 80.81.39.85 by mail.mhm.lv (envelope-from , uid 2850) with qmail-scanner-1.24 ( Clear:RC:1(80.81.39.85):. Processed in 0.935643 secs); 07 May 2008 23:51:52 -0000 Received: from unknown (HELO homee7979e67c1) (80.81.39.85) by mail.mhm.lv with SMTP; 7 May 2008 23:51:50 -0000 Message-ID: <150c01c8b099$0dcd91c0$55275150@homee7979e67c1> From: To: "Steven Hartland" References: <200805072037.m47KbGc6044521@freefall.freebsd.org> <009401c8b083$1aafeac0$55275150@homee7979e67c1> <522D413218B649BCA1E37C857715AFFC@multiplay.co.uk> <146401c8b08d$e7bf2440$55275150@homee7979e67c1> <6721C20C6813418DBFA2DA2341EB9976@multiplay.co.uk> Date: Thu, 8 May 2008 02:21:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org, vwe@FreeBSD.org Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN 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, 07 May 2008 23:21:22 -0000 This issue is not a personal problem of mine. As I have alrady mentioned a lot of people have been reporting this issue without any answer. It's really sad that you've been unpolite and agressive to me just because I labelled the message HP. Does it really worth this overreaction? Well, let the people of reason answer. As for blocking me, I do respect your freedom of choice. Culture prevents me from responding otherwise! ----- Original Message ----- From: "Steven Hartland" To: Sent: Thursday, May 08, 2008 1:50 AM Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changedto DOWN > Well given you have no consideration to for others and clearly think the > world > revolves around you problems so they every email you send must be flagged > as important, welcome to my blocked senders list. > > ----- Original Message ----- > From: > To: "Steven Hartland" > Cc: ; ; > > Sent: Wednesday, May 07, 2008 11:01 PM > Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate > changedto DOWN > > >>I guess it does, since this nightmere is being reported with different >>NICs and drivers including Intel NICs on em driver and 3Com NICs on bge >>and xl drivers on 6.3-RELEASE , 6-STABLE, 7.0-RELEAE and 7-STABLE. >> >> The mailing list if full of too many questions regarding this issue and >> no answer! >> >> If it realy doesn't worth a high priority flag, then I do appolgize and I >> shoud fall back to 4.11-RELEASE which worked on the same hardware like a >> sandwatch! > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing or > otherwise disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > From owner-freebsd-net@FreeBSD.ORG Thu May 8 02:52:17 2008 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 705FF1065672 for ; Thu, 8 May 2008 02:52:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 41C1C8FC18 for ; Thu, 8 May 2008 02:52:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 72097106C0F; Wed, 7 May 2008 22:52:16 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 07 May 2008 22:52:16 -0400 X-Sasl-enc: RwIjC2GpNnVjDWeOwrvO9TtsCeJwiqgu8RWp/AtDUi3T 1210215135 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 868F5BB02; Wed, 7 May 2008 22:52:15 -0400 (EDT) Message-ID: <48226ADC.1090801@incunabulum.net> Date: Thu, 08 May 2008 03:52:12 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <20080507040727.GA28983@verio.net> <48215706.8080508@samoylyk.sumy.ua> <4821EF57.9010600@elischer.org> <4821F206.10606@samoylyk.sumy.ua> <482205F7.4010503@elischer.org> <482206EE.2050904@samoylyk.sumy.ua> <482209E5.7010607@elischer.org> <48222236.5090802@samoylyk.sumy.ua> In-Reply-To: <48222236.5090802@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 08 May 2008 02:52:17 -0000 Oleksandr Samoylyk wrote: >> >> looks like UDP in PPP in GRE > > I think so. Should we hope for some progress in this direction in future? Probably not, unless someone is willing to come up to the table and commit to writing and maintaining a Netgraph node to demux GRE, although this is only shuffling the fanout elsewhere. If MPD is relying on raw sockets to demultiplex GRE, then this is what it's up against in terms of performance -- repeated acquisitions of the INP sleep lock, and context switches when the socket buffer low water mark is passed. It might have improved slightly in HEAD since the move to rwlocks. Like udp_input(), rip_input() suffers from the fact that the stack has to deal with delivering datagrams to potentially more than one socket, and there is no intermediate data structure to handle the fan-out -- it walks the entire inp list every time. If you look at the comments in udp_input() it's pretty clear this is a historical weakness in the BSD implementation. Windows, by the way, forces socket clients to explicitly request reception of broadcast datagrams as of Windows Server 2003, and multicasts are strictly delivered to group members only, which eliminates that problematic loop -- you can always maintain a tree of receivers that way. I'm happy to review patches if someone else commits to fixing it. cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu May 8 04:06:55 2008 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 A1C7C106566B for ; Thu, 8 May 2008 04:06:55 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 72BF98FC14 for ; Thu, 8 May 2008 04:06:55 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by wa-out-1112.google.com with SMTP id j4so755441wah.3 for ; Wed, 07 May 2008 21:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:cc:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=1N+cdIPhchPj54XsjCdqbWbC6yC4tfjtNQP1hsa+WQA=; b=VRXCpr5v3TIFscNQeKNO6YRuOYZ52/pZYbU+853o7apCac63E4KguvFgJ64nLBRtZXeLsoxZdOoCMkhNF1YpDMzIEK5Nwnxi07e9A/na4q9bLlfQDOH6AGIUrlcgpvSFTe6Lmy/KwwW6rOSVEbDxCBURaedJ4eN4gt1VdKWWuA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:cc:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=j5HXqJQJJwS0or58TmhgNZsSNMSAQrjYwI2Dq6R+fUDtMUzwWaq87Kci6/MwkWeZj90dqDUpNV4uZkvW9dKieI0cNjP8/0QlPm/KfW9JNmpDUlmqRWxdj5GQ6HrSLo/PWCj2+DpXpPcoMnx7fxI2EOy2wWsBQ088p/ITtcXreMo= Received: by 10.114.150.1 with SMTP id x1mr2645604wad.109.1210219614705; Wed, 07 May 2008 21:06:54 -0700 (PDT) Received: from ?192.168.0.160? ( [218.94.128.114]) by mx.google.com with ESMTPS id l27sm4577372waf.27.2008.05.07.21.06.50 (version=SSLv3 cipher=RC4-MD5); Wed, 07 May 2008 21:06:53 -0700 (PDT) Date: Thu, 08 May 2008 12:07:04 +0800 From: Deng XueFeng To: Andre Oppermann In-Reply-To: <48223324.6070203@freebsd.org> References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> Message-Id: <20080508120410.70E4.B627C632@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.45.02 [CN] Cc: freebsd-net@freebsd.org, Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 08 May 2008 04:06:55 -0000 hi, the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? > I've looked at the code paths again. There are two possibilities: > > a) the mbuf allocator has some anomaly where it rejects memory requests > but doesn't update the statistics (the code is there however). > > b) the error doesn't come from the mbuf allocation but from ip_output() > and further down the chain. > > To differentiate please try this updated patch and report the log output > again (don't forget to set net.inet.tcp.log_debug=1): > > http://people.freebsd.org/~andre/tcp_output-error-log.diff > > -- > Andre > > Deng XueFeng wrote: > > hi > > I'am also meet this problem in my mss server(missey streaming server). > > one encoder push stream to mss, then run 100 client player playing the > > sream, as the client number increase, mss will occur this error sooner or later > > like this: > > I'am using kqueue, and will got a event with EV_EOF and fflags = > > ETIMEDOUT, > > if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), > > > > and the tcpdump also show that server will send RST packet to encoder. > > > > > >> Hello, > >> > >> I'm are having a trouble with TCP connections being dropped with "read: > >> Operation timed out". What is unusual is that this is happening right in > >> the middle of sending a steady stream of data with no network congestion. > >> > >> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit > >> connection. The server receives a 192kbps inbound stream over TCP, and > >> broadcasts it over a large number of TCP streams. > >> > >> With no visible or obvious pattern, the inbound read() fails with > >> ETIMEDOUT. The likelihood of this happening seems to increase as the > >> number of audience connections increases. It's happens every few minutes > >> even with a small audience (eg. 300 outbound connections and about > >> 60mbit). > >> > >> It doesn't cough and splutter -- steady data is coming in, then it just > >> drops the connection. > >> > >> systat doesn't show problems inbound; all packets received are delivered > >> to the upper layer. But on outbound, there is consistent 'output drops': > >> > >> IP Output > >> 7028 total packets sent > >> 7028 - generated locally > >> 314 - output drops > >> > >> As the number of outbound connections increases, the 'output drops' > >> increases to around 10% of the total packets sent and maintains that > >> ratio. There's no problems with network capacity. > >> > >> I've tried different servers, different network interfaces (bge, em), > >> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats > >> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat > >> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen > >> in a dedicated, uncontended test environment. > >> > >> Can anyone explain why the packets are being dropped outbound, and how > >> this could affect inbound TCP data in such an abrupt way? What can I do to > >> solve this? > >> > >> Thanks, > >> > >> Mark > >> _______________________________________________ > >> 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" > > -- Deng XueFeng From owner-freebsd-net@FreeBSD.ORG Thu May 8 07:33:50 2008 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 0D0DA1065672 for ; Thu, 8 May 2008 07:33:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id E48218FC0A for ; Thu, 8 May 2008 07:33:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 08 May 2008 11:16:34 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 3AC3C2D600D; Thu, 8 May 2008 00:33:49 -0700 (PDT) Message-ID: <4822ACDB.6040209@elischer.org> Date: Thu, 08 May 2008 00:33:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4816D1D2.7010603@elischer.org> <20080506202940.K47338@maildrop.int.zabbadoz.net> <4820C8CE.8010309@elischer.org> <20080507074647.B47338@maildrop.int.zabbadoz.net> In-Reply-To: <20080507074647.B47338@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: multiple routing tables review patch ready for simple testing. 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, 08 May 2008 07:33:50 -0000 Bjoern A. Zeeb wrote: > On Tue, 6 May 2008, Julian Elischer wrote: > > Hi, > >> Bjoern A. Zeeb wrote: >>> On Tue, 29 Apr 2008, Julian Elischer wrote: >>> >>> Hi, >>> >>>> The patch can be found at >>>> http://www.freebsd.org/~julian/mrt.diff >>>> (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6) >>>> >>>> or source can be taken from perforce at: >>>> //depot/user/julian/routing/src >>> >>> So after looking at the patch a bit more again, could you add wrapper >>> functions for those like you have done for the old KPI (rtrequest, >>> rtrequest1, >> >> do you really want to do the extra work instructions? >> > ... >>> >>> The defines will not give you a stable KPI and having that changed again >>> if you are going with a prefix for each AF would be a pain if the >>> _fib versions >>> are going to change in the future. >> >> hmm fair enough... but let me outline my plans and thoughts >> so we can see if you still want this.. >> > [ ... ] >> >> This all however is not ABI compatible so could not go back to 7.x >> and I want to check in an initial version that can go back to 7.x >> which sort of suggests to me that adding in_xxx functions is >> not really required, until I do the next step. >> 7.x will never get the next step. because the ABI is already set >> in stone for 7.x. >> >> I would make the in_xxx stubs in the next step in 8.x. >> after the MFC to 7.x of the ABI compat version. >> >> >> let me know what you think. > > Leaving aside any upcoming enhancement if what we have now is > what is going into 7 and possibly 6 we should do the wrapper > functions. > > The point is RELENG_7 will live for $(last release + 2 years) so I > guess till 2011 or maybe later. No idea what would happen there in all > that time. > > If people start adding support for other AFs we cannot say that the > *_fib variants are not going to change so having the in_* stable > sounds like a good thing for 6 and 7. > > Am I missing anything obvious? > > > I don't mind if they are going to significantly change again in 8 > a few weeks later. ok, check http://www.freebsd.org/~julian/mrt.diff > > > /bz > From owner-freebsd-net@FreeBSD.ORG Thu May 8 08:32:59 2008 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 77F461065674 for ; Thu, 8 May 2008 08:32:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C02188FC21 for ; Thu, 8 May 2008 08:32:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 68376 invoked from network); 8 May 2008 07:34:38 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 May 2008 07:34:38 -0000 Message-ID: <4822BABB.4020407@freebsd.org> Date: Thu, 08 May 2008 10:32:59 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Deng XueFeng References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> <20080508120410.70E4.B627C632@gmail.com> In-Reply-To: <20080508120410.70E4.B627C632@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 08 May 2008 08:32:59 -0000 Deng XueFeng wrote: > hi, > the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? The logging function is not (yet) present in RELENG_6. I'll post the patch when I've backported the functionality. However it's an important information that it happens on 6.2 too. That means the source of the trouble wasn't introduced with 7.0. -- Andre >> I've looked at the code paths again. There are two possibilities: >> >> a) the mbuf allocator has some anomaly where it rejects memory requests >> but doesn't update the statistics (the code is there however). >> >> b) the error doesn't come from the mbuf allocation but from ip_output() >> and further down the chain. >> >> To differentiate please try this updated patch and report the log output >> again (don't forget to set net.inet.tcp.log_debug=1): >> >> http://people.freebsd.org/~andre/tcp_output-error-log.diff >> >> -- >> Andre >> >> Deng XueFeng wrote: >>> hi >>> I'am also meet this problem in my mss server(missey streaming server). >>> one encoder push stream to mss, then run 100 client player playing the >>> sream, as the client number increase, mss will occur this error sooner or later >>> like this: >>> I'am using kqueue, and will got a event with EV_EOF and fflags = >>> ETIMEDOUT, >>> if i ignore EV_EOF flag, then ETIMEDOUT will be return by read(2), >>> >>> and the tcpdump also show that server will send RST packet to encoder. >>> >>> >>>> Hello, >>>> >>>> I'm are having a trouble with TCP connections being dropped with "read: >>>> Operation timed out". What is unusual is that this is happening right in >>>> the middle of sending a steady stream of data with no network congestion. >>>> >>>> The system is FreeBSD 7 and a bespoke streaming server with 1Gbit >>>> connection. The server receives a 192kbps inbound stream over TCP, and >>>> broadcasts it over a large number of TCP streams. >>>> >>>> With no visible or obvious pattern, the inbound read() fails with >>>> ETIMEDOUT. The likelihood of this happening seems to increase as the >>>> number of audience connections increases. It's happens every few minutes >>>> even with a small audience (eg. 300 outbound connections and about >>>> 60mbit). >>>> >>>> It doesn't cough and splutter -- steady data is coming in, then it just >>>> drops the connection. >>>> >>>> systat doesn't show problems inbound; all packets received are delivered >>>> to the upper layer. But on outbound, there is consistent 'output drops': >>>> >>>> IP Output >>>> 7028 total packets sent >>>> 7028 - generated locally >>>> 314 - output drops >>>> >>>> As the number of outbound connections increases, the 'output drops' >>>> increases to around 10% of the total packets sent and maintains that >>>> ratio. There's no problems with network capacity. >>>> >>>> I've tried different servers, different network interfaces (bge, em), >>>> different kernel (7-RELEASE, 7-STABLE). Have also checked dev.bge.0.stats >>>> and dev.em.0.stats for CRC errors etc. which show no problems. 'netstat >>>> -m' doesn't show any reaching of mbuf and sbuf limits. The problem is seen >>>> in a dedicated, uncontended test environment. >>>> >>>> Can anyone explain why the packets are being dropped outbound, and how >>>> this could affect inbound TCP data in such an abrupt way? What can I do to >>>> solve this? >>>> >>>> Thanks, >>>> >>>> Mark >>>> _______________________________________________ >>>> 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 Thu May 8 09:17:09 2008 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 DB4881065689; Thu, 8 May 2008 09:17:09 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from metheny.ijneb.com (unknown [IPv6:2001:ba8:0:1ba:214:22ff:feb1:2693]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF938FC26; Thu, 8 May 2008 09:17:09 +0000 (UTC) (envelope-from mark@pogo.org.uk) Received: from localhost ([127.0.0.1] ident=mark) by metheny.ijneb.com with esmtp (Exim 4.69) (envelope-from ) id 1Ju2FR-0006Uf-7u; Thu, 08 May 2008 10:17:09 +0100 Date: Thu, 8 May 2008 10:17:09 +0100 (BST) From: Mark Hills To: Andre Oppermann In-Reply-To: <4822BABB.4020407@freebsd.org> Message-ID: References: <20080506133208.C2EC.B627C632@gmail.com> <48223324.6070203@freebsd.org> <20080508120410.70E4.B627C632@gmail.com> <4822BABB.4020407@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: mark@pogo.org.uk Cc: freebsd-net@freebsd.org, Deng XueFeng Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 08 May 2008 09:17:09 -0000 On Thu, 8 May 2008, Andre Oppermann wrote: > Deng XueFeng wrote: >> hi, >> the patch can not apply to 6.2, cound do a new patch for 6.2 or 6.3 ? > > The logging function is not (yet) present in RELENG_6. I'll post the > patch when I've backported the functionality. > > However it's an important information that it happens on 6.2 too. That > means the source of the trouble wasn't introduced with 7.0. I did earlier tests with the same software on FreeBSD 6.3 and never saw ETIMEDOUT -- only on FreeBSD 7.0. But I did have a different issue with 6.3 (lockups under very heavy conditions), although didn't do any specific tuning to try and stop this. Instead I made the jump to 7.0 which stopped this problem but introduced the ETIMEDOUT one. Mark From owner-freebsd-net@FreeBSD.ORG Thu May 8 11:53:27 2008 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 35FB31065671 for ; Thu, 8 May 2008 11:53:27 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from mail.nux.co.uk (mail.nux.co.uk [193.189.140.72]) by mx1.freebsd.org (Postfix) with ESMTP id 0A14E8FC14 for ; Thu, 8 May 2008 11:53:25 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: (qmail 95611 invoked by uid 2226); 8 May 2008 11:15:24 -0000 Received: from localhost (apache-101.nux.co.uk [193.189.140.101]) by mail.nux.co.uk with SMTP; Thu, 08 May 2008 12:15:24 +0100 (BST) (envelope-from tim@gebbettco.com) MIME-Version: 1.0 Date: Thu, 8 May 2008 12:26:44 +0100 From: Tim Gebbett To: Andre Oppermann In-Reply-To: <4822BABB.4020407@freebsd.org> References: <4822BABB.4020407@freebsd.org> Message-ID: X-Sender: tim@gebbettco.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Deng XueFeng , Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tim@gebbettco.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 11:53:27 -0000 Hi all, applied the patch, Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t May 8 12:14:26 timtest kernel: o May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT May 8 12:14:26 timtest kernel: C May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i interspersed with clean blocks of 20 entries or so of: May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) The output did not look appreciably different when the ETIMEDOUT occurred. On stopping the client test program: May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored netstat -m 258/11007/11265 mbufs in use (current/cache/total) 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/36283K/36860K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Thanks again for your help - Tim From owner-freebsd-net@FreeBSD.ORG Thu May 8 16:06:15 2008 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 1A605106566C for ; Thu, 8 May 2008 16:06:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFA58FC41 for ; Thu, 8 May 2008 16:06:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 76578 invoked from network); 8 May 2008 15:07:51 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 May 2008 15:07:51 -0000 Message-ID: <482324F9.7030802@freebsd.org> Date: Thu, 08 May 2008 18:06:17 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Tim@gebbettco.com References: <4822BABB.4020407@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Deng XueFeng , Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 08 May 2008 16:06:15 -0000 Hi Tim, looking at the ip_output() path there are some places that can return ENOBUFS: a) interface queue length check b) packet filter c) destination address rewrite through NAT d) if_output() call e) IP fragmentation if DF was not set The first one of those is the most likely to be the source of the error. The output interface queue length in read unlocked and may be a stale value on an SMP machine. Further down in ether_output() there are some further possibilities for ENOBUFS errors. But lets concentrate on a) first. For testing purposes please apply the following patch to ip_output(): ------------------------------------------------------------------- cvs diff -up ip_output.c Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.276.2.1 diff -u -p -r1.276.2.1 ip_output.c --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 +++ ip_output.c 8 May 2008 16:02:32 -0000 @@ -370,7 +370,7 @@ again: ip->ip_src = IA_SIN(ia)->sin_addr; } } - +#if 0 /* * Verify that we have any chance at all of being able to queue the * packet or packet fragments, unless ALTQ is enabled on the given @@ -390,7 +390,7 @@ again: ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); goto bad; } - +#endif /* * Look for broadcast address and * verify user is allowed to send ------------------------------------------------------------------- If there is a real interface output queue full event the IFQ_HANDOFF() and IFQ_ENQUEUE() macros will report it too. Then we can focus on the interface queues. -- Andre Tim Gebbett wrote: > Hi all, > > applied the patch, > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: > > > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t > May 8 12:14:26 timtest kernel: o > May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT > May 8 12:14:26 timtest kernel: C > May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > interspersed with clean blocks of 20 entries or so of: > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > On stopping the client test program: > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > netstat -m > > 258/11007/11265 mbufs in use (current/cache/total) > 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) > 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 576K/36283K/36860K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/4/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Thanks again for your help - Tim > > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Thu May 8 18:26:52 2008 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 D5EA210656B3 for ; Thu, 8 May 2008 18:26:52 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from mail.nux.co.uk (mail.nux.co.uk [193.189.140.72]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6768FC38 for ; Thu, 8 May 2008 18:26:49 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: (qmail 46677 invoked by uid 2226); 8 May 2008 18:15:28 -0000 Received: from localhost (apache-101.nux.co.uk [193.189.140.101]) by mail.nux.co.uk with SMTP; Thu, 08 May 2008 19:15:28 +0100 (BST) (envelope-from tim@gebbettco.com) MIME-Version: 1.0 Date: Thu, 8 May 2008 19:26:47 +0100 From: Tim Gebbett To: Andre Oppermann In-Reply-To: <482324F9.7030802@freebsd.org> References: <482324F9.7030802@freebsd.org> Message-ID: <32570632be785826455c493ec4d37206@193.189.140.95> X-Sender: tim@gebbettco.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Tim@gebbettco.com, Deng XueFeng , Mark Hills , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tim@gebbettco.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2008 18:26:55 -0000 Hi Andre, Applied the patch, I could not see anything different to the last test. No packet filtering or NAT are enabled, the test is running over a switch. Many thanks - Tim 258/6657/6915 mbufs in use (current/cache/total) 256/1084/1340/25600 mbuf clusters in use (current/cache/total/max) 256/1024 mbuf+clusters out of packet secondary zone in use (current/cache) 0/3565/3565/51200 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/18092K/18668K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/5/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines tcp: 2535986 packets sent 2331504 data packets (3266105457 bytes) 258369 data packets (371873800 bytes) retransmitted 46685 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 27972 ack-only packets (3905 delayed) 0 URG only packets 0 window probe packets 10636 window update packets 4 control packets 1888423 packets received 1172093 acks (for 3256670917 bytes) 425512 duplicate acks 0 acks for unsent data 46363 packets (52992771 bytes) received in-sequence 19 completely duplicate packets (17508 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 293 out-of-order packets (376674 bytes) 0 packets (0 bytes) of data after window 0 window probes 242695 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 2 connection requests 2054 connection accepts 0 bad connection attempts 0 listen queue overflows 597 ignored RSTs in the windows 2056 connections established (including accepts) 2052 connections closed (including 2049 drops) 2048 connections updated cached RTT on close 2048 connections updated cached RTT variance on close 2048 connections updated cached ssthresh on close 0 embryonic connections dropped 1172093 segments updated rtt (of 1057825 attempts) 72399 retransmit timeouts 1 connection dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 4806 correct ACK header predictions 43111 correct data packet header predictions 2054 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 2054 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 2054 cookies sent 0 cookies received 83801 SACK recovery episodes 116632 segment rexmits in SACK recovery episodes 168710294 byte rexmits in SACK recovery episodes 544885 SACK options (SACK blocks) received 14 SACK options (SACK blocks) sent 0 SACK scoreboard overflow udp: 31 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 0 dropped due to no socket 10 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 21 delivered 22 datagrams output 0 times multicast source filter matched sctp: 0 input packets 0 datagrams 0 packets that had data 0 input SACK chunks 0 input DATA chunks 0 duplicate DATA chunks 0 input HB chunks 0 HB-ACK chunks 0 input ECNE chunks 0 input AUTH chunks 0 chunks missing AUTH 0 invalid HMAC ids received 0 invalid secret ids received 0 auth failed 0 fast path receives all one chunk 0 fast path multi-part data 0 output packets 0 output SACKs 0 output DATA chunks 0 retransmitted DATA chunks 0 fast retransmitted DATA chunks 0 FR's that happened more than once to same chunk. 0 intput HB chunks 0 output ECNE chunks 0 output AUTH chunks 0 ip_output error counter Packet drop statistics: 0 from middle box 0 from end host 0 with data 0 non-data, non-endhost 0 non-endhost, bandwidth rep only 0 not enough for chunk header 0 not enough data to confirm 0 where process_chunk_drop said break 0 failed to find TSN 0 attempt reverse TSN lookup 0 e-host confirms zero-rwnd 0 midbox confirms no space 0 data did not match TSN 0 TSN's marked for Fast Retran Timeouts: 0 iterator timers fired 0 T3 data time outs 0 window probe (T3) timers fired 0 INIT timers fired 0 sack timers fired 0 shutdown timers fired 0 heartbeat timers fired 0 a cookie timeout fired 0 an endpoint changed its cookiesecret 0 PMTU timers fired 0 shutdown ack timers fired 0 shutdown guard timers fired 0 stream reset timers fired 0 early FR timers fired 0 an asconf timer fired 0 auto close timer fired 0 asoc free timers expired 0 inp free timers expired 0 packet shorter than header 0 checksum error 0 no endpoint for port 0 bad v-tag 0 bad SID 0 no memory 0 number of multiple FR in a RTT window 0 RFC813 allowed sending 0 RFC813 does not allow sending 0 max burst dosn't allow sending 0 look ahead tells us no memory in interface 0 numbers of window probes sent 0 times an output error to clamp down on next user send. 0 times sctp_senderrors were caused from a user 0 number of in data drops due to chunk limit reached 0 number of in data drops due to rwnd limit reached 0 times a ECN reduced the cwnd 0 used express lookup via vtag 0 collision in express lookup. 0 times the sender ran dry of user data on primary 0 same for above 0 sacks the slow way 0 window update only sacks sent 0 sends with sinfo_flags !=0 0 unordered sends 0 sends with EOF flag set 0 sends with ABORT flag set 0 times protocol drain called 0 times we did a protocol drain 0 times recv was called with peek 0 cached chunks used 0 cached stream oq's used 0 unread messages abandonded by close 0 send burst avoidance, already max burst inflight to net 0 send cwnd full avoidance, already max burst inflight to net 0 number of map array over-runs via fwd-tsn's ip: 1888457 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 1888454 packets for this host 0 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 3 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 2628572 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header On Thu, 08 May 2008 18:06:17 +0200, Andre Oppermann wrote: > Hi Tim, > > looking at the ip_output() path there are some places that can > return ENOBUFS: > > a) interface queue length check > > b) packet filter > > c) destination address rewrite through NAT > > d) if_output() call > > e) IP fragmentation if DF was not set > > The first one of those is the most likely to be the source of the > error. The output interface queue length in read unlocked and may > be a stale value on an SMP machine. Further down in ether_output() > there are some further possibilities for ENOBUFS errors. But lets > concentrate on a) first. > > For testing purposes please apply the following patch to ip_output(): > > ------------------------------------------------------------------- > cvs diff -up ip_output.c > Index: ip_output.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.276.2.1 > diff -u -p -r1.276.2.1 ip_output.c > --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 > +++ ip_output.c 8 May 2008 16:02:32 -0000 > @@ -370,7 +370,7 @@ again: > ip->ip_src = IA_SIN(ia)->sin_addr; > } > } > - > +#if 0 > /* > * Verify that we have any chance at all of being able to queue > the > * packet or packet fragments, unless ALTQ is enabled on the > given > @@ -390,7 +390,7 @@ again: > ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); > goto bad; > } > - > +#endif > /* > * Look for broadcast address and > * verify user is allowed to send > ------------------------------------------------------------------- > > If there is a real interface output queue full event the IFQ_HANDOFF() > and IFQ_ENQUEUE() macros will report it too. Then we can focus on the > interface queues. > > -- > Andre > > Tim Gebbett wrote: >> Hi all, >> >> applied the patch, >> >> Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug > started venting massive quantities of tcp_output error 55 while sending > with syncache noise: >> >> >> y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: > error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t >> May 8 12:14:26 timtest kernel: o >> May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 > while sendingT >> May 8 12:14:26 timtest kernel: C >> May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 > 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. > 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i >> >> interspersed with clean blocks of 20 entries or so of: >> >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending >> May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) >> >> >> The output did not look appreciably different when the ETIMEDOUT > occurred. >> >> On stopping the client test program: >> >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without > matching syncache entry (possibly syncookie only), segment ignored >> >> netstat -m >> >> 258/11007/11265 mbufs in use (current/cache/total) >> 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) >> 256/1536 mbuf+clusters out of packet secondary zone in use > (current/cache) >> 0/7585/7585/51200 4k (page size) jumbo clusters in use > (current/cache/total/max) >> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) >> 576K/36283K/36860K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/4/6656 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> >> Thanks again for your help - Tim >> >> >> >> >> >> >> >> >> > > _______________________________________________ > 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 Thu May 8 19:07:19 2008 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 1DBD11065673; Thu, 8 May 2008 19:07:19 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E81D68FC15; Thu, 8 May 2008 19:07:18 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m48J7IHA053817; Thu, 8 May 2008 19:07:18 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m48J7I2d053813; Thu, 8 May 2008 19:07:18 GMT (envelope-from vwe) Date: Thu, 8 May 2008 19:07:18 GMT Message-Id: <200805081907.m48J7I2d053813@freefall.freebsd.org> To: adam@mhm.lv, vwe@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/123347: [bge] bge1: watchdog timeout -- linkstate changed to DOWN 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, 08 May 2008 19:07:19 -0000 Synopsis: [bge] bge1: watchdog timeout -- linkstate changed to DOWN State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Thu May 8 19:06:56 UTC 2008 State-Changed-Why: Feedback has been provided. http://www.freebsd.org/cgi/query-pr.cgi?pr=123347 From owner-freebsd-net@FreeBSD.ORG Thu May 8 19:20:31 2008 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 6E47E106567B for ; Thu, 8 May 2008 19:20:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 4FE1B8FC1A for ; Thu, 8 May 2008 19:20:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.2/8.14.2) with ESMTP id m48J7oaK066295; Thu, 8 May 2008 12:09:00 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m48J72Bk080302; Thu, 8 May 2008 12:07:02 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m48J710a051889; Thu, 8 May 2008 12:07:01 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Thu, 08 May 2008 15:06:56 -0400 Message-ID: From: gnn@freebsd.org To: kevin In-Reply-To: <001701c8ae36$96f0f560$5084183a@honglan> References: <001701c8ae36$96f0f560$5084183a@honglan> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1.50 (i386-apple-darwin8.11.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Canit-CHI2: 0.50 X-Bayes-Prob: 0.5 (Score 0, tokens from: ) X-Spam-Score: 0.10 () [Tag at 5.00] COMBINED_FROM X-CanItPRO-Stream: default X-Canit-Stats-ID: 275392 - ad5f57cb4518 X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: freebsd-net@freebsd.org Subject: Re: Change from BSDL to GPL 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, 08 May 2008 19:20:31 -0000 At Mon, 05 May 2008 06:31:25 +0800, kevin wrote: > > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change its licence from 4.4BSD-Lite licence to GPL licence? > Alas, the short answer is "Consult an IP lawyer." Best, George From owner-freebsd-net@FreeBSD.ORG Thu May 8 20:45:55 2008 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 99011106566B; Thu, 8 May 2008 20:45:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD8F8FC18; Thu, 8 May 2008 20:45:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id B7E791A4D82; Thu, 8 May 2008 13:25:57 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m48KPjtx006478; Thu, 8 May 2008 16:25:45 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: andre@FreeBSD.org Date: Thu, 8 May 2008 16:25:32 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805081625.33093.jhb@FreeBSD.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 08 May 2008 16:25:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7064/Thu May 8 08:36:43 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-net@FreeBSD.org Subject: Small patch.. 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, 08 May 2008 20:45:55 -0000 At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are spamming the heck out of our dmesg so I am #if 0'ing all of them out and while doing so ran into this case. Specifically, it doesn't actually bump the stat counter unless it succeeds in allocating memory to log the debug message. All the other places in the syncache and tcp input code always bump the stats, so this patch fixes it to do that. Index: tcp_syncache.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.143 diff -u -r1.143 tcp_syncache.c --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 @@ -567,10 +567,11 @@ "connection attempt aborted by remote endpoint\n", s, __func__); tcpstat.tcps_sc_reset++; - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " - "(+WND %u), segment ignored\n", - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); + } else { + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " + "IRS %u (+WND %u), segment ignored\n", + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); tcpstat.tcps_badrst++; } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu May 8 21:15:07 2008 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 B83A2106564A for ; Thu, 8 May 2008 21:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 70C0F8FC1A for ; Thu, 8 May 2008 21:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8F52641C770; Thu, 8 May 2008 23:15:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id c++LHGxhCsR0; Thu, 8 May 2008 23:15:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3659F41C75D; Thu, 8 May 2008 23:15:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id E912B44487F; Thu, 8 May 2008 21:14:12 +0000 (UTC) Date: Thu, 8 May 2008 21:14:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: John Baldwin In-Reply-To: <200805081625.33093.jhb@FreeBSD.org> Message-ID: <20080508211342.M47338@maildrop.int.zabbadoz.net> References: <200805081625.33093.jhb@FreeBSD.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org, andre@FreeBSD.org Subject: Re: Small patch.. 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, 08 May 2008 21:15:07 -0000 On Thu, 8 May 2008, John Baldwin wrote: > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > while doing so ran into this case. Specifically, it doesn't actually bump > the stat counter unless it succeeds in allocating memory to log the debug > message. All the other places in the syncache and tcp input code always bump > the stats, so this patch fixes it to do that. looks good. > Index: tcp_syncache.c > =================================================================== > RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v > retrieving revision 1.143 > diff -u -r1.143 tcp_syncache.c > --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 > +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 > @@ -567,10 +567,11 @@ > "connection attempt aborted by remote endpoint\n", > s, __func__); > tcpstat.tcps_sc_reset++; > - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { > - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " > - "(+WND %u), segment ignored\n", > - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > + } else { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " > + "IRS %u (+WND %u), segment ignored\n", > + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > tcpstat.tcps_badrst++; > } > > > -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Thu May 8 21:29:36 2008 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 1310C106564A; Thu, 8 May 2008 21:29:36 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DEE638FC18; Thu, 8 May 2008 21:29:35 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m48LTZao065184; Thu, 8 May 2008 21:29:35 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m48LTZW9065180; Thu, 8 May 2008 21:29:35 GMT (envelope-from vwe) Date: Thu, 8 May 2008 21:29:35 GMT Message-Id: <200805082129.m48LTZW9065180@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/121080: [bge] IPv6 NUD problem on multi address config on bge0 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, 08 May 2008 21:29:36 -0000 Synopsis: [bge] IPv6 NUD problem on multi address config on bge0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Thu May 8 21:29:08 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121080 From owner-freebsd-net@FreeBSD.ORG Thu May 8 21:36:43 2008 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 729DF1065673 for ; Thu, 8 May 2008 21:36:43 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: from morrison.andev.ch (morrison.andev.ch [78.47.142.202]) by mx1.freebsd.org (Postfix) with ESMTP id C2B098FC1C for ; Thu, 8 May 2008 21:36:42 +0000 (UTC) (envelope-from petar@morrison.andev.ch) Received: by morrison.andev.ch (Postfix, from userid 1000) id E59265DB74; Thu, 8 May 2008 23:37:36 +0200 (CEST) Date: Thu, 8 May 2008 23:35:12 +0200 From: Petar Bogdanovic To: Sam Leffler Message-ID: <20080508213512.GA9389@pintail.smokva.net> Mail-Followup-To: Sam Leffler , freebsd-net@freebsd.org References: <20080502093655.GA3535@pintail.smokva.net> <481BB0E5.8000803@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481BB0E5.8000803@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: authentication timeouts with ath(4) in hostap mode 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, 08 May 2008 21:36:43 -0000 On Fri, May 02, 2008 at 05:25:09PM -0700, Sam Leffler wrote: > Petar Bogdanovic wrote: >> Hi, >> >> I'm using an alix2c0 board with two winstron CM9 ath(4)-cards and >> FreeBSD 7: >> >> ifconfig ath0 (...) mediaopt hostap mode 11a channel 36 ssid sn.a -bgscan >> ifconfig ath1 (...) mediaopt hostap mode 11g channel 11 ssid sn.g -bgscan >> >> >> When I try to raise the traffic (i.e. dd | ssh AP dd) my Linux >> wpa_supplicant drops the connection and has to reassociate. This however >> does not work immediately; The supplicant fails a few times before >> reconnecting: >> >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Authentication with 00:0b:0b:06:0d:09 timed out. >> <2>Trying to associate with 00:0b:0b:06:0d:09 (SSID='sn.a' freq=5320 MHz) >> <2>Associated with 00:0b:0b:06:0d:09 >> <2>WPA: Key negotiation completed with 00:0b:0b:06:0d:09 [PTK=CCMP GTK=CCMP] >> <2>CTRL-EVENT-CONNECTED - Connection to 00:0b:0b:06:0d:09 completed (reauth) [id=0 id_str=] >> >> >> This happens more on the 11a than on the 11g network. When I'm next to >> the AP, the timeouts are almost gone but they still happen. (My laptop >> is just one room away from the AP). Here is the athstats-output of ath0 >> (11a): >> >> # ./athstats -i ath0 >> 481546 data frames received >> 330669 data frames transmit >> 13395 tx frames with an alternate rate >> 78558 long on-chip tx retries >> 1431 tx failed 'cuz too many retries >> 36M current transmit rate >> 78 tx management frames >> 3 tx frames discarded prior to association >> 45 tx frames with no ack marked >> 2894 rx failed 'cuz of bad CRC >> 2 rx failed 'cuz decryption >> 92711 rx failed 'cuz of PHY err >> 92708 OFDM timing >> 3 OFDM restart >> 318332 beacons transmitted >> 1111 periodic calibrations >> 2 rfgain value change >> 22 rssi of last ack >> 23 avg recv rssi >> -96 rx noise floor >> 2530 switched default/rx antenna >> Antenna profile: >> [1] tx 173364 rx 123068 >> [2] tx 155874 rx 358671 > > So the obvious question is whether your system config has enough isolation > of the radios for them not to impact each other? I have no experience with > Alix boards but it's not uncommon for there to be power and signal issues > when operating multiple radios in an enclosure (and yes, even with the > radios on different bands). > > You don't indicate what you've done to diagnose this problem. Have you > verified the packets are present in the air? Have you traced packets > and/or phy errors around the time of the problem? Does turning off one > radio give you stable operation? Have you tried different channels? Have > you tried different boards? > > >> >> >> All this is well known to me, since I had NetBSD running on this device >> for months and it suffered the same problems -- it was even worse, the >> timeouts occured every few minutes. Back then, it seemed that ath had >> some interrupt problems: >> >> ath0: device timeout >> >> as David Young from NetBSD noticed in his mail some time ago: >> >> http://mail-index.netbsd.org/tech-net/2007/11/29/0001.html >> >> >> FreeBSD doesn't seem to have this `device timeouts'. I don't see any in >> /var/log/messages and there are none when I'm connected to the device >> over a serial port. >> >> I'm a bit lost here, but ready to debug if someone knows more. > > netbsd's code base is many _years_ out of date wrt freebsd; comparing > operation of the two systems is unlikely to be useful. Just for the record: After various (client-)tests with Intel 2200BG and 3945ABG chips and one AR5212 chip on FreeBSD, it seems that only the madwifi client caused interrupts or more precisly: interrupts after a missed beacon. My observations correspond with the following madwifi ticket: http://madwifi.org/ticket/848 One beacon miss, one interrupt. The FreeBSD ath-driver does _not_ show any similar behaviour on the same device. Kind regards, Petar From owner-freebsd-net@FreeBSD.ORG Thu May 8 22:30:52 2008 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 9EC42106567F for ; Thu, 8 May 2008 22:30:52 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0FA998FC29 for ; Thu, 8 May 2008 22:30:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 80991 invoked from network); 8 May 2008 21:32:26 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 May 2008 21:32:26 -0000 Message-ID: <48237F1A.6020601@freebsd.org> Date: Fri, 09 May 2008 00:30:50 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: John Baldwin References: <200805081625.33093.jhb@FreeBSD.org> In-Reply-To: <200805081625.33093.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: Small patch.. 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, 08 May 2008 22:30:52 -0000 John Baldwin wrote: > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > while doing so ran into this case. Specifically, it doesn't actually bump sysctl net.inet.tcp.log_debug=0 is simpler than #if 0 and has the same effect. In RELENG_7 it was disabled by default. > the stat counter unless it succeeds in allocating memory to log the debug > message. All the other places in the syncache and tcp input code always bump > the stats, so this patch fixes it to do that. Your fix is correct. -- Andre > Index: tcp_syncache.c > =================================================================== > RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v > retrieving revision 1.143 > diff -u -r1.143 tcp_syncache.c > --- tcp_syncache.c 19 Apr 2008 03:39:17 -0000 1.143 > +++ tcp_syncache.c 8 May 2008 20:22:21 -0000 > @@ -567,10 +567,11 @@ > "connection attempt aborted by remote endpoint\n", > s, __func__); > tcpstat.tcps_sc_reset++; > - } else if ((s = tcp_log_addrs(inc, th, NULL, NULL))) { > - log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != IRS %u " > - "(+WND %u), segment ignored\n", > - s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > + } else { > + if ((s = tcp_log_addrs(inc, th, NULL, NULL))) > + log(LOG_DEBUG, "%s; %s: RST with invalid SEQ %u != " > + "IRS %u (+WND %u), segment ignored\n", > + s, __func__, th->th_seq, sc->sc_irs, sc->sc_wnd); > tcpstat.tcps_badrst++; > } > > From owner-freebsd-net@FreeBSD.ORG Fri May 9 02:48:28 2008 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 EA6D41065679 for ; Fri, 9 May 2008 02:48:28 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id BBAB58FC16 for ; Fri, 9 May 2008 02:48:28 +0000 (UTC) (envelope-from dengxf@gmail.com) Received: by wf-out-1314.google.com with SMTP id 28so921229wfa.7 for ; Thu, 08 May 2008 19:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:cc:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; bh=HSWNnPi/gm25S3XrkTTX49///QL8VqXO5aZitHeiiL8=; b=HqCxcg4WrVvgcXjHQNfuTcFEXZcARaMtZJVCqnaCSqftPfEcXMjBdQFQ5wbTejb4d8ntaMacO1QxOIvMdB6n6sGN/1MgbxC7b+9hu/XK7DEQSQWuXRnpIlmZxKZ1EIj61Dgu0wy/xSKKiZ5yaitQto0sY5uTA5GxCizmvKWO9fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:cc:in-reply-to:references:message-id:mime-version:content-type:content-transfer-encoding:x-mailer; b=fQhVfUFAaJd6M7PLJlH5HoUpT9taa9QQPbo+FwyevOmpcIB0BAER7uMykPT9jG6Rl81NBXzTVzNVJqShBV8EFaZNIDDEEdxKxXhm6XNfp91drMpM7LNPCfiYp8BLH0BvZj2jD2/TwaPt/sjB9Z0NRnl7R1RUMCSJm2n96HTc7Tw= Received: by 10.142.216.9 with SMTP id o9mr1713310wfg.172.1210301308436; Thu, 08 May 2008 19:48:28 -0700 (PDT) Received: from ?192.168.0.160? ( [218.94.128.114]) by mx.google.com with ESMTPS id 24sm9249226wff.12.2008.05.08.19.48.22 (version=SSLv3 cipher=RC4-MD5); Thu, 08 May 2008 19:48:25 -0700 (PDT) Date: Fri, 09 May 2008 10:48:37 +0800 From: Deng XueFeng To: Andre Oppermann In-Reply-To: <482324F9.7030802@freebsd.org> References: <482324F9.7030802@freebsd.org> Message-Id: <20080509104700.A502.B627C632@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.45.02 [CN] Cc: Tim@gebbettco.com, Mark Hills , freebsd-net@freebsd.org Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 09 May 2008 02:48:29 -0000 hi, applied the patch for 6.2, rebuild & install kernel, but nothing changed. ETIMEDOUT still occur. > Hi Tim, > > looking at the ip_output() path there are some places that can > return ENOBUFS: > > a) interface queue length check > > b) packet filter > > c) destination address rewrite through NAT > > d) if_output() call > > e) IP fragmentation if DF was not set > > The first one of those is the most likely to be the source of the > error. The output interface queue length in read unlocked and may > be a stale value on an SMP machine. Further down in ether_output() > there are some further possibilities for ENOBUFS errors. But lets > concentrate on a) first. > > For testing purposes please apply the following patch to ip_output(): > > ------------------------------------------------------------------- > cvs diff -up ip_output.c > Index: ip_output.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > retrieving revision 1.276.2.1 > diff -u -p -r1.276.2.1 ip_output.c > --- ip_output.c 9 Mar 2008 21:04:54 -0000 1.276.2.1 > +++ ip_output.c 8 May 2008 16:02:32 -0000 > @@ -370,7 +370,7 @@ again: > ip->ip_src = IA_SIN(ia)->sin_addr; > } > } > - > +#if 0 > /* > * Verify that we have any chance at all of being able to queue the > * packet or packet fragments, unless ALTQ is enabled on the given > @@ -390,7 +390,7 @@ again: > ifp->if_snd.ifq_drops += (ip->ip_len / ifp->if_mtu + 1); > goto bad; > } > - > +#endif > /* > * Look for broadcast address and > * verify user is allowed to send > ------------------------------------------------------------------- > > If there is a real interface output queue full event the IFQ_HANDOFF() > and IFQ_ENQUEUE() macros will report it too. Then we can focus on the > interface queues. > > -- > Andre > > Tim Gebbett wrote: > > Hi all, > > > > applied the patch, > > > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive quantities of tcp_output error 55 while sending with syncache noise: > > > > > > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t > > May 8 12:14:26 timtest kernel: o > > May 8 12:14:26 timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT > > May 8 12:14:26 timtest kernel: C > > May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > > > interspersed with clean blocks of 20 entries or so of: > > > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > > > On stopping the client test program: > > > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored > > > > netstat -m > > > > 258/11007/11265 mbufs in use (current/cache/total) > > 256/1596/1852/25600 mbuf clusters in use (current/cache/total/max) > > 256/1536 mbuf+clusters out of packet secondary zone in use (current/cache) > > 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > > 576K/36283K/36860K bytes allocated to network (current/cache/total) > > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > > 0/4/6656 sfbufs in use (current/peak/max) > > 0 requests for sfbufs denied > > 0 requests for sfbufs delayed > > 0 requests for I/O initiated by sendfile > > 0 calls to protocol drain routines > > > > Thanks again for your help - Tim > > > > > > > > > > > > > > > > > > -- Deng XueFeng From owner-freebsd-net@FreeBSD.ORG Fri May 9 10:02:06 2008 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 B0ECA1065675 for ; Fri, 9 May 2008 10:02:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 16E198FC1E for ; Fri, 9 May 2008 10:02:05 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 95577 invoked from network); 9 May 2008 09:03:34 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 9 May 2008 09:03:34 -0000 Message-ID: <4824211C.9090105@freebsd.org> Date: Fri, 09 May 2008 12:02:04 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Tim@gebbettco.com References: <4822BABB.4020407@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Deng XueFeng , Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 09 May 2008 10:02:06 -0000 Tim Gebbett wrote: > Hi all, > > applied the patch, > > Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug started venting massive > quantities of tcp_output error 55 while sending with syncache noise: The error seems to be coming from the interface send queue which hits the limit. If you are using em(4) network interface please add this line to loader.conf(5): hw.em.txd=1024 Or even more if problems persist. The maximum is 4096. -- Andre > y 8 12:14:26 timtest kernel: :63859 to [192.168.5.40]:80; tcp_output: error 55 whilTeC Ps:e > n[d1i9n2g. 1(6i8p._5o.u4t3p]u:t64 0371 )t May 8 12:14:26 timtest kernel: o May 8 12:14:26 > timtest kernel: [192.168.5.40]:80; tcp_output: error 55 while sendingT May 8 12:14:26 timtest > kernel: C May 8 12:14:26 timtest kernel: P: [192.168.5.43]:63859 to [192.168.5.40]:80; > tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) May 8 12:14:26 timtest > kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error 55 while sending May 8 > 12:14:26 timtest kernel: TCP: [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 > while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.42]:56421 toT C[P1:9 > 2[.119628..51.6480.]5:.8403;] :6t3c8p57_ otuot p[u1t9:2 .e1r68r.o5r. 40]:8505; whticlpe_ > osuetnpduitn:g e(rirpo_ro utpu5t5 w1h)i > > interspersed with clean blocks of 20 entries or so of: > > May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to [192.168.5.40]:80; tcp_output: error > 55 while sending (ip_output 1) May 8 12:14:26 timtest kernel: TCP: [192.168.5.43]:64037 to > [192.168.5.40]:80; tcp_output: error 55 while sending May 8 12:14:26 timtest kernel: TCP: > [192.168.5.43]:63857 to [192.168.5.40]:80; tcp_output: error 55 while sending (ip_output 1) > > > The output did not look appreciably different when the ETIMEDOUT occurred. > > On stopping the client test program: > > May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment > ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to [192.168.5.40]:80 tcpflags > 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie > only), segment ignored May 8 12:14:46 timtest kernel: TCP: [192.168.5.43]:63978 to > [192.168.5.40]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache > entry (possibly syncookie only), segment ignored > > netstat -m > > 258/11007/11265 mbufs in use (current/cache/total) 256/1596/1852/25600 mbuf clusters in use > (current/cache/total/max) 256/1536 mbuf+clusters out of packet secondary zone in use > (current/cache) 0/7585/7585/51200 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in > use (current/cache/total/max) 576K/36283K/36860K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters > denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 > requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain > routines > > Thanks again for your help - Tim > > > > > > > > > From owner-freebsd-net@FreeBSD.ORG Fri May 9 11:06:21 2008 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 E05E4106564A for ; Fri, 9 May 2008 11:06:21 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2BB8FC16 for ; Fri, 9 May 2008 11:06:21 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JuQQZ-0005JS-7w for freebsd-net@freebsd.org; Fri, 09 May 2008 11:06:15 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 May 2008 11:06:15 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 May 2008 11:06:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 09 May 2008 13:06:00 +0200 Lines: 44 Message-ID: References: <002e01c8ae38$3a343240$5084183a@honglan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5B73E5CBFAC8718FD00B2CA3" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.12 (X11/20080227) In-Reply-To: <002e01c8ae38$3a343240$5084183a@honglan> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Change from BSDL to GPL 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, 09 May 2008 11:06:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B73E5CBFAC8718FD00B2CA3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable kevin wrote: > Hi, all > I want to port 4.4BSD-Lite's TCP/IP source code to my own OS kernel. > My OS kernel is GPL licenced. > Is it possible for me to modify 4.4BSD-Lite's source code and change it= s licence from 4.4BSD-Lite licence to GPL licence? You cannot *change* the license to anything if you don't have explicit permission from the original authors (the people who created the file with the license text in it). You can *use* the BSD licensed source in your GPL project without any restrictions or requirements. You can *add* your own copyright clause and/or license to the files if you change them. In this particular case the virulent aspect of the GPL comes into play so the rest of the source becomes tainted with GPL, and in effect becomes GPL-licensed (which is allowed). But you must not *remove* the original BSD license text and its copyright lines even in this case. If you suspect anyone might sue you for it, don't rely on what I said; you must seek opinion from a lawyer. --------------enig5B73E5CBFAC8718FD00B2CA3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIJDAYldnAQVacBcgRAm9SAKCRTXEDYcXxuvuXRSWErWwNruNLfwCgwvxw aTRgfDrSi2DNpzrTKOzNG4k= =Qdo4 -----END PGP SIGNATURE----- --------------enig5B73E5CBFAC8718FD00B2CA3-- From owner-freebsd-net@FreeBSD.ORG Fri May 9 12:47:27 2008 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 6D07B106564A; Fri, 9 May 2008 12:47:27 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id F35938FC0A; Fri, 9 May 2008 12:47:26 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([193.31.10.34]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 May 2008 14:38:26 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m49CZLtL012385; Fri, 9 May 2008 14:35:21 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 9 May 2008 14:35:21 +0200 From: Matthias Apitz To: freebsd-drivers@freebsd.org, freebsd-net@freebsd.org Message-ID: <20080509123521.GA11366@rebelion.Sisis.de> References: <20080506174359.GA2814@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080506174359.GA2814@rebelion.Sisis.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-RELEASE (i386) X-OriginalArrivalTime: 09 May 2008 12:38:26.0419 (UTC) FILETIME=[93B0FC30:01C8B1D1] Cc: Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 12:47:27 -0000 El día Tuesday, May 06, 2008 a las 07:43:59PM +0200, Matthias Apitz escribió: > > Hello, > > I'm on the way to port the above mentioned driver to FreeBSD 7.0-REL; > the work is based on the Linux driver of this card and of some help I've > got in frebsd-mobile, see thread: > > http://groups.google.com/group/muc.lists.freebsd.mobile/browse_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e > > the current state of the work is: > > - driver attaches fine to the card on insert; > - devices come up as /dev/cuaN0...4; > - serial communication with, for example, kermit to /dev/cuaN0 is fine; > - PPPD can chat with AT-cmd's into UMTS network and sign on; > - LCP layer is fine, IP comes up, routing, etc; > - with real TCP traffic the communication gets stuck, for example with > SSH from the PPPD-laptop to some server in my network; > > I've watched with TCPDUMP the interface ppp0 of the laptop and the eth0 of > the server at the same time, ... Hello, without going into the details of the TCPDUMP, it shows that the three-way-handshake (SYN-SYN-ACK) is fine, the 1st data pkg from SSH server arrives, but the answer from PPPD with the ACK is only to be seen in the TCPDUMP on the PPPD site and does not arrive at server; I've instructed the driver to log a lot of stuff, and as well the contents of the buffers send to the card ... and compared them against the PPP specs I have handy in the TCP/IP Illustraded, Volume I, from Stevens; for the LCP packages the frame look like this: 7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e 7e -- flag ff -- addr, always ff 03 -- control, always 03 c0 21 -- protocol, here LCP and the frame ends with 7e, ok; for the IP datagram containing the 1st (outgoing) SYN it looks like: 7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 cc fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58 00 00 02 04 05 b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79 f2 7e 7e -- flag 21 -- ??? (could be part of 0021 indicating IP datagram) 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 -- IP header already 4d 19 8f b7 -- src addr 77.25.143.183 c1 1f 0b c8 -- dst addr as well the ACK of SYN-SYN-ACK goes out like this: 7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7 c1 1f 0b c8 ... and also the 1st real data (containing the protocol string of the SSH client looks like this: 7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7 c1 1f 0b c8 cc fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd 00 00 01 01 08 0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30 30 36 31 31 31 30 0a f1 62 7e shouldn't they start with 7e ff 03 00 21 ... Stevens explains further more that client and server could handshake to omit the constant flag (7e) and adress field (ff) and reduce the protocol field (0021) to one byte (21), but in the above packages 'flag' is there while 'addr' and 'control' are missing? any PPP expert here to explain this? could this be the reason that the connection gets stuck? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ Don't top-post, read RFC1855 http://www.faqs.org/rfcs/rfc1855.html A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on Usenet and in e-mail? From owner-freebsd-net@FreeBSD.ORG Fri May 9 14:23:21 2008 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 3FFDF106566B for ; Fri, 9 May 2008 14:23:21 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id C06708FC12 for ; Fri, 9 May 2008 14:23:20 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2693486fgb.35 for ; Fri, 09 May 2008 07:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:sender; bh=gT8fw2dempMXEsg8gNvQNgVV5ah+54OAFvLkPhjyoxk=; b=oboLFcZweC7CEN9LBnDWomONjmqmmHhO6l/TzoJpQ+ftlzes5R8laOA0+Af34EYxO77xFnYghTDrACReGDKjgJsFEVfRNgg8TpV2CmlmQIfbbtIL4KXelviEz3viUXrL7Dj2jb+MBbhMf5I1wKjbA9jIRsrIEQaHIeY42WOQ1h0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding:sender; b=Ujjs3uJccrxdZOep9YFW8uS6DXVLp3Rc1evxVvV4qe7lRRElG3HFSRm8t61Rm5Gaq7Or+Nx4hOqevOb04wm6OBnVv8MHFP5IX6cH7v8CS9kJUwPOvUH7QtKF+Oons074zrnkS7LG+lRy2illIwkW6OvAWwjwJg2oTua6J6gmH5U= Received: by 10.86.89.1 with SMTP id m1mr8564383fgb.45.1210342999065; Fri, 09 May 2008 07:23:19 -0700 (PDT) Received: from epsilon.local ( [89.214.217.19]) by mx.google.com with ESMTPS id e20sm4368725fga.7.2008.05.09.07.23.17 (version=SSLv3 cipher=RC4-MD5); Fri, 09 May 2008 07:23:18 -0700 (PDT) Message-ID: <48245E51.1090009@FreeBSD.org> Date: Fri, 09 May 2008 15:23:13 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Rui Paulo Subject: fxp timeouts 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, 09 May 2008 14:23:21 -0000 Hi, On a RELENG_7 machine, after a few days of uptime, I started getting fxp DMA and SBC timeouts: May 8 19:59:33 sigma kernel: fxp0: DMA timeout May 8 19:59:33 sigma kernel: fxp0: SCB timeout: 0xff 0xff 0xff 0xffff And this goes on forever until I reboot: % zcat /var/log/messages.1.bz2 | egrep -c '(SBC|DMA|timeout)' 1785 Has anyone else experienced this problem ? Am I having hardware problems ? I never had any problems with this card, but I recently put some extra load on this server. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri May 9 14:43:30 2008 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 22B081065677; Fri, 9 May 2008 14:43:30 +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 EC79C8FC13; Fri, 9 May 2008 14:43:29 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m49EhTLg062959; Fri, 9 May 2008 14:43:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m49EhT97062955; Fri, 9 May 2008 14:43:29 GMT (envelope-from linimon) Date: Fri, 9 May 2008 14:43:29 GMT Message-Id: <200805091443.m49EhT97062955@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/123552: [ath] [panic] kernel panic during network activity on ath0 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, 09 May 2008 14:43:30 -0000 Synopsis: [ath] [panic] kernel panic during network activity on ath0 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 9 14:43:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123552 From owner-freebsd-net@FreeBSD.ORG Fri May 9 14:49:14 2008 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 A112C1065673 for ; Fri, 9 May 2008 14:49:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3A20A8FC17 for ; Fri, 9 May 2008 14:49:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with ESMTP id AAA21020; Sat, 10 May 2008 00:49:03 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 10 May 2008 00:49:02 +1000 (EST) From: Ian Smith To: Matthias Apitz In-Reply-To: <20080509123521.GA11366@rebelion.Sisis.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R 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, 09 May 2008 14:49:14 -0000 On Fri, 9 May 2008, Matthias Apitz wrote: > El día Tuesday, May 06, 2008 a las 07:43:59PM +0200, Matthias Apitz escribió: > > > > > Hello, > > > > I'm on the way to port the above mentioned driver to FreeBSD 7.0-REL; > > the work is based on the Linux driver of this card and of some help I've > > got in frebsd-mobile, see thread: > > > > http://groups.google.com/group/muc.lists.freebsd.mobile/browse_thread/thread/6e4b18d5d292b0a7/0b1f42404c982b8e > > > > the current state of the work is: > > > > - driver attaches fine to the card on insert; > > - devices come up as /dev/cuaN0...4; > > - serial communication with, for example, kermit to /dev/cuaN0 is fine; > > - PPPD can chat with AT-cmd's into UMTS network and sign on; > > - LCP layer is fine, IP comes up, routing, etc; > > - with real TCP traffic the communication gets stuck, for example with > > SSH from the PPPD-laptop to some server in my network; > > > > I've watched with TCPDUMP the interface ppp0 of the laptop and the eth0 of > > the server at the same time, ... > > Hello, > > without going into the details of the TCPDUMP, it shows that the > three-way-handshake (SYN-SYN-ACK) is fine, the 1st data pkg from SSH > server arrives, but the answer from PPPD with the ACK is only to be seen > in the TCPDUMP on the PPPD site and does not arrive at server; > > I've instructed the driver to log a lot of stuff, and as well the > contents of the buffers send to the card ... and compared them against > the PPP specs I have handy in the TCP/IP Illustraded, Volume I, from > Stevens; > > for the LCP packages the frame look like this: > > 7e ff 03 c0 21 09 00 00 08 b7 b4 30 0b 54 b9 7e > > 7e -- flag > ff -- addr, always ff > 03 -- control, always 03 > c0 21 -- protocol, here LCP > > and the frame ends with 7e, ok; > > for the IP datagram containing the 1st (outgoing) SYN it looks like: > > 7e 21 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 cc > fe 00 16 16 b9 37 7d 5d 00 00 00 00 a0 02 ff ff ef 58 00 00 02 04 05 > b4 01 03 03 03 04 02 08 0a 00 1a 93 8e 00 00 00 00 79 f2 7e > > > 7e -- flag > 21 -- ??? (could be part of 0021 indicating IP datagram) > 45 00 00 3c 00 a7 40 00 40 06 90 5d 4d 19 8f b7 c1 1f 0b c8 -- IP header already > 4d 19 8f b7 -- src addr 77.25.143.183 > c1 1f 0b c8 -- dst addr > > as well the ACK of SYN-SYN-ACK goes out like this: > > 7e 21 45 00 00 34 00 aa 40 00 40 06 90 62 4d 19 8f b7 c1 1f 0b c8 ... > > and also the 1st real data (containing the protocol string of the SSH client > looks like this: > > 7e 21 45 00 00 5b 00 af 40 00 40 06 90 36 4d 19 8f b7 c1 1f 0b c8 cc > fe 00 16 16 b9 37 7d 5e c5 c8 fd cc 80 18 20 50 04 fd 00 00 01 01 08 > 0a 00 1a 95 9e 4b 36 fd 6c 53 53 48 2d 32 2e 30 2d 4f 70 65 6e 53 53 > 48 5f 34 2e 35 70 31 20 46 72 65 65 42 53 44 2d 32 30 30 36 31 31 31 > 30 0a f1 62 7e > > shouldn't they start with > > 7e ff 03 00 21 ... > > Stevens explains further more that client and server could handshake to > omit the constant flag (7e) and adress field (ff) and reduce the > protocol field (0021) to one byte (21), but in the above packages 'flag' is there > while 'addr' and 'control' are missing? > > any PPP expert here to explain this? could this be the reason that the > connection gets stuck? Probably not the sort of help you wanted, and I'm no PPP expert, but having run ppp(8) in and out for ten years and more recently mpd(8) outbound, I have to ask, does this gig depend on using pppd? Just that in that time I've seen very few people using pppd except some people just coming over from linux, or those hoping to use kde's dialer, and have noticed little success reported with apparent pppd bugs. Almost invariably people seem better advised to use ppp or more lately mpd instead, if only because quite a few people here can resolve config and usage problems with either, whereas pppd appears to have been all but deprecated for some years - but perhaps I do it an injustice. HTH, Ian (subscribed only to -net) From owner-freebsd-net@FreeBSD.ORG Fri May 9 16:36:52 2008 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 B03BA1065672 for ; Fri, 9 May 2008 16:36:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 83B228FC0C for ; Fri, 9 May 2008 16:36:52 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2169262rvf.43 for ; Fri, 09 May 2008 09:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=O2FZVl01MnieqbXpDbcj11E69G0cXc3MHJEY5DJG9DI=; b=W/jVpaJRBI1ZmexjKmkbzjKSv8vaxsiiOiF78/tXA51i7Cre4SiOHyC1jheSeGSy8t7/9ZICeYuucfxY6y72RrcphBVY6LfDssy2lpvXpeuiMvp1P/1bRTjHl3r/F4dzIZ3vLF6fLIlcD/mdWIc9Rh3v02nx/PcQyvGEuKBOt9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=wTITpz8W70BbAvvy+0xSEs3WsrTiQSgPuWNWU2wTfBE5Cyurm/64l0jPwI9FfTLGW0+3WdXs8TLK9M6y0YwhetU6MM7h6O1/MJvH5B7i1EfLrhrcP8RxkfYoLmzqDyebDmJ/N6QmzKnjbMsA5GfoXGRTRHxERU+apuGvWmaJfgU= Received: by 10.141.76.21 with SMTP id d21mr2249445rvl.242.1210351012287; Fri, 09 May 2008 09:36:52 -0700 (PDT) Received: by 10.140.135.3 with HTTP; Fri, 9 May 2008 09:36:52 -0700 (PDT) Message-ID: <9a542da30805090936l222a58bcy5b926cba01d62ce6@mail.gmail.com> Date: Fri, 9 May 2008 18:36:52 +0200 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Derek (freebsd-ipfw)" <482254ac@razorfever.net> In-Reply-To: <48247901.3000706@razorfever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30805080844t395c8c81sd313fc2fd1780fcb@mail.gmail.com> <48247901.3000706@razorfever.net> Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: Dummynet, gif, and ipsec 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, 09 May 2008 16:36:52 -0000 On Fri, May 9, 2008 at 6:17 PM, Derek (freebsd-ipfw) <482254ac@razorfever.net> wrote: > Ermal Lu=E7i wrote: >> >> Well this is a patch to shape IPSec tunnels with ALTQ and FreeBSD 6.3 >> as you are running. It is another alternative to dummynet though it >> have been tested with pf but should work with ipfw too since it knows >> about ALTQ. >> Hope it helps! >> > > Hi Ermal, > > Thanks for the response! > > I'm looking to roll this out on 5-7 machines, so I'm really looking for a > solution where we wouldn't have to make changes to the kernel code and wo= uld > be supported by the base system moving forward. > > Are you planning to submit a PR with this patch? > > Also are the m_tag, or altq_tag the same tags created with the ipfw tag > command? > As far as i am aware this should be transparent to ipfw. Meaning it should work since ipfw speaks ALTQ tags so no problems should arise. It is in use in production machines as a patch so you can be sure it works reliably. I can submit the PR but i think it is better if somebody with ipsec competence comments about its eligibility. I CC'd freebsd-net@ so somebody will speak for this more rather than place it on PR that nobody would look at. Ermal > -- Derek > From owner-freebsd-net@FreeBSD.ORG Fri May 9 17:12:17 2008 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 B07B31065676; Fri, 9 May 2008 17:12:17 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86E388FC0C; Fri, 9 May 2008 17:12:17 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (sam@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m49HCHS0074356; Fri, 9 May 2008 17:12:17 GMT (envelope-from sam@freefall.freebsd.org) Received: (from sam@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m49HCGgn074352; Fri, 9 May 2008 17:12:16 GMT (envelope-from sam) Date: Fri, 9 May 2008 17:12:16 GMT Message-Id: <200805091712.m49HCGgn074352@freefall.freebsd.org> To: g.w.roberts@cs.cardiff.ac.uk, sam@FreeBSD.org, freebsd-net@FreeBSD.org, sam@FreeBSD.org From: sam@FreeBSD.org Cc: Subject: Re: kern/123552: [ath] [panic] kernel panic during network activity on ath0 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, 09 May 2008 17:12:17 -0000 Synopsis: [ath] [panic] kernel panic during network activity on ath0 State-Changed-From-To: open->feedback State-Changed-By: sam State-Changed-When: Fri May 9 17:10:24 UTC 2008 State-Changed-Why: need system and network configuration at a minimum Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Fri May 9 17:10:24 UTC 2008 Responsible-Changed-Why: need system and network configuration at a minimum; e.g. provide a dmesg and the output of ifconfig http://www.freebsd.org/cgi/query-pr.cgi?pr=123552 From owner-freebsd-net@FreeBSD.ORG Fri May 9 17:55:24 2008 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 953BC10656CA; Fri, 9 May 2008 17:55:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 79DAA8FC16; Fri, 9 May 2008 17:55:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id E93B81A4D80; Fri, 9 May 2008 10:55:23 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m49Ht2sf016548; Fri, 9 May 2008 13:55:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andre Oppermann Date: Fri, 9 May 2008 12:07:05 -0400 User-Agent: KMail/1.9.7 References: <200805081625.33093.jhb@FreeBSD.org> <48237F1A.6020601@freebsd.org> In-Reply-To: <48237F1A.6020601@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805091207.05611.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 09 May 2008 13:55:09 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7081/Fri May 9 11:52:50 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-net@freebsd.org Subject: Re: Small patch.. 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, 09 May 2008 17:55:24 -0000 On Thursday 08 May 2008 06:30:50 pm Andre Oppermann wrote: > John Baldwin wrote: > > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are > > spamming the heck out of our dmesg so I am #if 0'ing all of them out and > > while doing so ran into this case. Specifically, it doesn't actually bump > > sysctl net.inet.tcp.log_debug=0 is simpler than #if 0 and has the same effect. > In RELENG_7 it was disabled by default. That doesn't shut up log(LOG_DEBUG). That is controlled by syslog settings. Trust me. We enable more crap in syslog at work which is why we were inundated. net.inet.tcp.log_debug was already 0. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri May 9 18:18:53 2008 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 69E991065671 for ; Fri, 9 May 2008 18:18:53 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 55C218FC0A for ; Fri, 9 May 2008 18:18:53 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id DDE9D3C04F9; Fri, 9 May 2008 11:01:52 -0700 (PDT) Date: Fri, 9 May 2008 11:01:52 -0700 From: Christopher Cowart To: freebsd-net@FreeBSD.org Message-ID: <20080509180152.GV89055@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZSRqT0vnbHyWXlI9" Content-Disposition: inline Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: carp and vlan interfaces recovery issue 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, 09 May 2008 18:18:53 -0000 --ZSRqT0vnbHyWXlI9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I have the following configuration: box1:/etc/rc.conf: | ifconfig_bge1=3D"up" | ifconfig_vlan95=3D"inet 10.9.128.2/20 vlan 95 vlandev bge1" | ifconfig_carp15=3D"inet 10.9.128.1/32 vhid 15 pass secret advskew 100" | ifconfig_carp25=3D"inet 10.9.128.1/32 vhid 25 pass secret" box2:/etc/rc.conf: | ifconfig_fxp0=3D"up" | ifconfig_vlan95=3D"inet 10.9.128.3/20 vlan 95 vlandev fxp1" | ifconfig_carp15=3D"inet 10.9.128.1/32 vhid 15 pass secret" | ifconfig_carp25=3D"inet 10.9.128.1/32 vhid 25 pass secret advskew 100" /etc/sysct.conf: | net.inet.carp.arpbalance=3D1 Output from ifconfig: box1: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 25 advbase 1 advskew 0 box2: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: BACKUP vhid 25 advbase 1 advskew 100 Then, on box 1, I `ifconfig vlan95 down'. Updated output from ifconfig: box1: | carp15: flags=3D8 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: INIT vhid 15 advbase 1 advskew 100 | carp25: flags=3D8 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: INIT vhid 25 advbase 1 advskew 0 box2: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 25 advbase 1 advskew 100 Then, on box 1, I `ifconfig vlan95 up'. Again: box1: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: BACKUP vhid 25 advbase 1 advskew 0 box2: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 15 advbase 1 advskew 0 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff | carp: MASTER vhid 25 advbase 1 advskew 100 Notice that both carp interfaces are running in "BACKUP" mode on box1, even after some period of waiting. I would expect things to return to the initial state.=20 If I `tcpdump -i vlan95 vrrp' on both boxes at this point, I see: | 10:57:20.502188 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement,=20 | vrid 15, prio 0, authtype none, intvl 1s, length 36 | 10:57:21.503211 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement,=20 | vrid 15, prio 0, authtype none, intvl 1s, length 36 | 10:57:21.537201 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement,=20 | vrid 25, prio 100, authtype none, intvl 1s, length 36 | 10:57:22.504234 IP 10.9.128.3 > VRRP.MCAST.NET: VRRPv2, Advertisement,=20 | vrid 15, prio 0, authtype none, intvl 1s, length 36 Note that box1 (10.9.128.2) isn't sending any advertisements.=20 If I use the physical interface, not the vlan interface `ifconfig bge1 down' on box1: box1: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 15 advbase 1 advskew 100 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 25 advbase 1 advskew 0 box2: | carp16: flags=3D49 metric 0 mtu 1500 | inet 10.9.144.1 netmask 0xffffffff=20 | carp: MASTER vhid 16 advbase 1 advskew 0 | carp26: flags=3D49 metric 0 mtu 1500 | inet 10.9.144.1 netmask 0xffffffff=20 | carp: MASTER vhid 26 advbase 1 advskew 100 And finally, `ifconfig bge1 up' on box1: | carp15: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: BACKUP vhid 15 advbase 1 advskew 100 | carp25: flags=3D49 metric 0 mtu 1500 | inet 10.9.128.1 netmask 0xffffffff=20 | carp: MASTER vhid 25 advbase 1 advskew 0 Things return to where they should be. Is this a bug? --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --ZSRqT0vnbHyWXlI9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBSCSRkCPHEDszU3zYAQLIRw//QN5k5ul47h5Y84O1a1Zv17DLYiHjYbPg CEIBzI93Y4kFh+OoAwZxJ89rzzgqrcUy18ohXVdbr7WCm28eJHF5KvaX52jrfOSs AJGSCCgSUoi9hAoN4R/7G7ZqoqJhrvVSXzsTuLACEbZVbuor6iV1Ypk+EQNULfyQ p+VLB3cI5mPb/iKeWB/mXNRhgG9Jf6j7FrNrdzlGA3ldHRO4Oci6HP/EXUEDS7rT tXWFwXmMUhhjW5f2XQfyM/5D7ZfaNOmU8ccsRAZHnMcUWA36NyuG98lzUQkrVtJz 2bdM/6C4rF20rYocAbCkc/Xodfr/qAGhdvjv+EG3wwY+rTn+q8sEeBo+a5fNWwDL zKw9ipXaArOljybsLUTQj7dXrjBEPusOuMeYANBs3kp2GaOAHHgOOPT4L6gGNJ8w 62cqta0zw3E2wmR9F2foEVvqdoBAYbPFeaXvnVTMmeIpkCigofWeTCVJfgCZnS9O yjjz3sYQ1csY1oob46uph5s9Yh6yQkTA80YvczMd9MUPlPwF/MkTF+hxTKaMWhSm pGUs63VA6oKjStwR/zrJpcc5BPMTKm85joQpr4271J067eyFp+ycgPJJln07iWLc ZkkDTaWKuEM47fYpC0xhPzGJm0qnRNFFS0Rw+Dc9gH+BThNQMjNsgxseBX8FWpYg brjHp8bu2qw= =sBd8 -----END PGP SIGNATURE----- --ZSRqT0vnbHyWXlI9-- From owner-freebsd-net@FreeBSD.ORG Fri May 9 18:46:12 2008 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 2FF52106566C for ; Fri, 9 May 2008 18:46:12 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFE98FC0C for ; Fri, 9 May 2008 18:46:12 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JuXbf-0003tw-E5 for freebsd-net@freebsd.org; Fri, 09 May 2008 18:46:11 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JuXbf-0005VV-AJ for freebsd-net@freebsd.org; Fri, 09 May 2008 18:46:11 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 1ADE18E298; Fri, 9 May 2008 13:46:11 -0500 (CDT) Date: Fri, 9 May 2008 13:46:11 -0500 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080509184610.GB30415@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20080509180152.GV89055@hal.rescomp.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20080509180152.GV89055@hal.rescomp.berkeley.edu> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: carp and vlan interfaces recovery issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2008 18:46:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Cowart wrote: > > Notice that both carp interfaces are running in "BACKUP" mode on box1, > even after some period of waiting. I would expect things to return to > the initial state. net.inet.carp.preempt=1 ? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIJJvyFSrKRjX5eCoRAoZSAJ9s7sDYTJA+9xJpxjdhJLSkkH9+IQCgk4dE S8UuiFOsNid0Ow9W1PFptEs= =GSdm -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri May 9 19:13:50 2008 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 5350B1065672 for ; Fri, 9 May 2008 19:13:50 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA948FC24 for ; Fri, 9 May 2008 19:13:50 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 1E3403C04F9; Fri, 9 May 2008 12:13:50 -0700 (PDT) Date: Fri, 9 May 2008 12:13:50 -0700 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20080509191350.GW89055@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org References: <20080509180152.GV89055@hal.rescomp.berkeley.edu> <20080509184610.GB30415@verio.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2y8j+ZQnxuzsbzfy" Content-Disposition: inline In-Reply-To: <20080509184610.GB30415@verio.net> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: carp and vlan interfaces recovery issue 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, 09 May 2008 19:13:50 -0000 --2y8j+ZQnxuzsbzfy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable David DeSimone wrote: > Christopher Cowart wrote: > > > > Notice that both carp interfaces are running in "BACKUP" mode on box1, > > even after some period of waiting. I would expect things to return to > > the initial state.=20 >=20 > net.inet.carp.preempt=3D1 ? They return to the initial states when I perform the down/up on the physical parent interface without turning on preempt. My point was the behavior when moving a vlan from down to up is different from moving the physical interface from down to up; I don't think they should be. --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --2y8j+ZQnxuzsbzfy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBSCSibSPHEDszU3zYAQLzZxAAhrIcAHtgHEC1T/oj4Y8hFW4R6mf8pRdv egMcSwX2DHL57J1e/uH7cmhFRUSQN/nwhdNtRBjFeseVlBI+OhoPGL43ZVIQWbxc f4w6bDYnAIWm7CdGQGUPzL9/+4DJ/syccYwKTEzi1MEpaTTJ25hX/G4pYg8nUO9f ln86+XEKexvF/p/K8ZxrKa5UkpRToXUWGRV+5Vo5BioNTVl33zdZoQeNp6/1nQvp 32iav5mWlW6CPcCkN8iUoLu8JaQWUUixlUaAJoxgLDa/MuznptuKcY+lKgawaqYn tmj31B38KSfdvD3xf1HWytPvRV44lmY+UV1hkQ9QyU1blcyXQg1RvrOpr52CJJ67 lEzlQX/QPW0kXxyZzwnV5kY7qcPxqA7qjS84SZfN1EmapTCVLwPXBlOPpV1Hx8cW +xfCqbEDyFkI+9+dlm+wd/41KN19ooSRQpEBEqvoZOYwjK6h7L54SFl3ApLfxjYW 3KAD1RuofyBwifD1yKd5N177hMBPHLyWs+6fdCiE8e8Ju8UUj7HwkHQXTZ+x7i0r BikEMkQyCIIxgmbJI2ajFCL6SVzQjHrtc11CTuZVgmfLZxGnEZUMVfeVBZBgVmvb BeJt/piuwyWHM1hjlXvOICdAnp6ZBnhpYyGYBf8I6/5XgnfhFrP+OIHwjVnSfEww rk8PSsNG02s= =Pz2b -----END PGP SIGNATURE----- --2y8j+ZQnxuzsbzfy-- From owner-freebsd-net@FreeBSD.ORG Sat May 10 09:08:44 2008 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 5711A106566C; Sat, 10 May 2008 09:08:44 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from outmail137080.authsmtp.com (outmail137080.authsmtp.com [62.13.137.80]) by mx1.freebsd.org (Postfix) with ESMTP id 056488FC18; Sat, 10 May 2008 09:08:43 +0000 (UTC) (envelope-from tim@gebbettco.com) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt4.authsmtp.com (8.14.1/8.14.1/Kp) with ESMTP id m4A8ojW1084652; Sat, 10 May 2008 09:50:45 +0100 (BST) Received: from [10.111.0.10] (host217-34-40-180.in-addr.btopenworld.com [217.34.40.180]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m4A8ohpf073413; Sat, 10 May 2008 09:50:44 +0100 (BST) Message-ID: <482561F3.6080701@gebbettco.com> Date: Sat, 10 May 2008 09:50:59 +0100 From: Tim Gebbett User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Andre Oppermann References: <4822BABB.4020407@freebsd.org> <4824211C.9090105@freebsd.org> In-Reply-To: <4824211C.9090105@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Server-Quench: 2d2e8dc9-1e6e-11dd-aecc-001871e930f4 X-AuthRoute: OCdxaQwcClZJTQEy BS4OBiJcVQ4iYBZL BAkGMA9GIUINWEQN c1ADdh12OUxbHwkB C3YLUl5RUFd1XS13 ag1PbgFDZkpQXg1q T0pMQFdNFEs1BW0J WUZeBBl1dAFHezBz YkRlEHIPXhFyIRV0 X08BEzgbZGY0PH1O BRMLagNUcQtNf0pM aVApUD1vNG8XJC8x E09ydyo8IShFLj8d bz0sCH8+Zns3Vjk6 DwseEDwjDAU5bB17 JBsgLFMXAEcWNC05 X-Authentic-SMTP: 61633239343939.cat.dmpriest.net.uk:953/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse Cc: freebsd-net@freebsd.org, Deng XueFeng , Mark Hills Subject: Re: read() returns ETIMEDOUT on steady TCP connection 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, 10 May 2008 09:08:44 -0000 Hi Andre, did some careful testing yesterday and last night. I seem to be still hitting an unknown buffer although the probem is much alleviated. The system achieved a 7hour run at 500mbit where ETIMEDOUT occured. I was feeding 11 other streams to the server whos counters show an uninterrupted eleven hours. The feeder streams are from the same source, so it is unlikely that the one feeding the test could of had a problem without affecting the counters of the others. sysctls are: (loader.conf) hw.em.txd=4096 net.inet.tcp.sendspace=78840 net.inet.tcp.recvspace=78840 kern.ipc.nmbjumbop=51200 kern.ipc.nmbclusters=78840 kern.maxfiles=50000 IP stats are miraculously improved, going from a 10% packet loss within stack (output drops) to a consistent zero at peaks of 80000 pps. I believe the problem is now being shunted to the NIC from the following output: dev.em.0.debug=1 < em0: Adapter hardware address = 0xc520b224 < em0: CTRL = 0x48f00249 RCTL = 0x8002 < em0: Packet buffer = Tx=16k Rx=48k < em0: Flow control watermarks high = 47104 low = 45604 < em0: tx_int_delay = 66, tx_abs_int_delay = 66 < em0: rx_int_delay = 0, rx_abs_int_delay = 66 < em0: fifo workaround = 0, fifo_reset_count = 0 < em0: hw tdh = 3285, hw tdt = 3285 < em0: hw rdh = 201, hw rdt = 200 < em0: Num Tx descriptors avail = 4096 < em0: Tx Descriptors not avail1 = 4591225 < em0: Tx Descriptors not avail2 = 0 < em0: Std mbuf failed = 0 < em0: Std mbuf cluster failed = 0 < em0: Driver dropped packets = 0 < em0: Driver tx dma failure in encap = 0 dev.em.0.stats=1 < em0: Excessive collisions = 0 < em0: Sequence errors = 0 < em0: Defer count = 0 < em0: Missed Packets = 16581181 < em0: Receive No Buffers = 74605555 < em0: Receive Length Errors = 0 < em0: Receive errors = 0 < em0: Crc errors = 0 < em0: Alignment errors = 0 < em0: Collision/Carrier extension errors = 0 < em0: RX overruns = 289717 < em0: watchdog timeouts = 0 < em0: XON Rcvd = 0 < em0: XON Xmtd = 0 < em0: XOFF Rcvd = 0 < em0: XOFF Xmtd = 0 < em0: Good Packets Rcvd = 848158221 < em0: Good Packets Xmtd = 1080368640 < em0: TSO Contexts Xmtd = 0 < em0: TSO Contexts Failed = 0 Does the counter 'Tx Descriptors not avail1' indicate lack of decriptors at the time not available, and would this be symptomatic of something Mark suggested: "(the stack) needs to handle local buffer fills not as a failed attempt on transmission that increments the retry counter, a possible better strategy required for backoff when the hardware buffer is full?" Thanks for your continued time and effort - Tim Andre Oppermann wrote: > Tim Gebbett wrote: >> Hi all, >> >> applied the patch, >> >> Well before a ETIMEDOUT error occurred (around 60secs), the tcp debug >> started venting massive >> quantities of tcp_output error 55 while sending with syncache noise: > > The error seems to be coming from the interface send queue which hits > the limit. > If you are using em(4) network interface please add this line to > loader.conf(5): > > hw.em.txd=1024 > > Or even more if problems persist. The maximum is 4096. > From owner-freebsd-net@FreeBSD.ORG Sat May 10 14:39:30 2008 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 91F521065673; Sat, 10 May 2008 14:39:30 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 433F98FC13; Sat, 10 May 2008 14:39:29 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 2A35BB83E; Sat, 10 May 2008 17:39:28 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, WHOIS_MYPRIVREG=0.156] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 16421B83B; Sat, 10 May 2008 17:39:13 +0300 (EEST) Message-ID: <4825B397.4060005@samoylyk.sumy.ua> Date: Sat, 10 May 2008 17:39:19 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> In-Reply-To: <4825B177.7020503@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 14:39:30 -0000 Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Julian Elischer wrote: >>> this may be the issue: >>> http://www.nabble.com/GRE-Mux-td16201899.html >> >> I think so. Should we hope for some progress in this direction in future? > > This is not an issue any more for mpd. > Originally multiplexing based on peers addresses by socket binding and > connecting was used. There was only problem with multiplexing multiple > calls inside the same tunnel (having the same peer addresses). > Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved > ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and > the latest mpd-5.1 is able to use this feature when it is present at a > build time. > * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 08:01:26 mav Exp $ -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 14:55:25 2008 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 67CC3106566C for ; Sat, 10 May 2008 14:55:25 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DAE548FC25 for ; Sat, 10 May 2008 14:55:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 123739658; Sat, 10 May 2008 17:55:24 +0300 Message-ID: <4825B75B.9050604@FreeBSD.org> Date: Sat, 10 May 2008 17:55:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> In-Reply-To: <4825B397.4060005@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 14:55:25 -0000 Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Oleksandr Samoylyk wrote: >>> Julian Elischer wrote: >>>> this may be the issue: >>>> http://www.nabble.com/GRE-Mux-td16201899.html >>> >>> I think so. Should we hope for some progress in this direction in >>> future? >> >> This is not an issue any more for mpd. >> Originally multiplexing based on peers addresses by socket binding and >> connecting was used. There was only problem with multiplexing multiple >> calls inside the same tunnel (having the same peer addresses). >> Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved >> ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and >> the latest mpd-5.1 is able to use this feature when it is present at a >> build time. >> > > * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 > 08:01:26 mav Exp $ As I can see you have build mpd before system build. Probably mpd was built on a system without this feature present yet: # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 12:40:02 EEST 2008 xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (root at xxx.xxxxxxxxx.xxx 09:53 1-May-2008) Try to rebuild mpd to be sure it uses this feature. Also you can check this by observing the name of any ng_pptpgre hook used. If it is "upper", then ng_pptpgre multiplexing is not used and if it is "session_hhhh" then OK. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 10 15:00:32 2008 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 F317D1065671; Sat, 10 May 2008 15:00:31 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id A2BAD8FC1B; Sat, 10 May 2008 15:00:31 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 01A1BB848; Sat, 10 May 2008 18:00:30 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44, WHOIS_MYPRIVREG=0.156] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id E2680B83B; Sat, 10 May 2008 18:00:13 +0300 (EEST) Message-ID: <4825B884.9030009@samoylyk.sumy.ua> Date: Sat, 10 May 2008 18:00:20 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> In-Reply-To: <4825B75B.9050604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 15:00:32 -0000 Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> Julian Elischer wrote: >>>>> this may be the issue: >>>>> http://www.nabble.com/GRE-Mux-td16201899.html >>>> >>>> I think so. Should we hope for some progress in this direction in >>>> future? >>> >>> This is not an issue any more for mpd. >>> Originally multiplexing based on peers addresses by socket binding >>> and connecting was used. There was only problem with multiplexing >>> multiple calls inside the same tunnel (having the same peer addresses). >>> Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved >>> ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and >>> the latest mpd-5.1 is able to use this feature when it is present at >>> a build time. >>> >> >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.c,v 1.40.2.1 2008/03/30 >> 08:01:26 mav Exp $ > > As I can see you have build mpd before system build. Probably mpd was > built on a system without this feature present yet: > > # uname -a > FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3 > 12:40:02 EEST 2008 > xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 > > # mpd5 -v > Version 5.1 (root at xxx.xxxxxxxxx.xxx 09:53 1-May-2008) > > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > I just tried to rebuild it one more time: # uname -a FreeBSD xxx.xxxxxxxxx.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon May 5 01:11:23 EEST 2008 xxxxx at xxx.xxxxxxxxx.xxx:/usr/obj/usr/src/sys/XXXX amd64 # mpd5 -v Version 5.1 (xxxxx at xxx.xxxxxxxxx.xxx 17:38 10-May-2008) # /usr/local/etc/rc.d/mpd5 restart Stopping mpd5. Waiting for PIDS: 604, 604, 604, 604, 604, 604, 604. Starting mpd5. I'll see if anything will change. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 15:30:18 2008 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 82F6A106564A for ; Sat, 10 May 2008 15:30:18 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id F00958FC0A for ; Sat, 10 May 2008 15:30:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 123732904; Sat, 10 May 2008 17:30:16 +0300 Message-ID: <4825B177.7020503@FreeBSD.org> Date: Sat, 10 May 2008 17:30:15 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> In-Reply-To: <1210209785.00067436.1210197002@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 15:30:18 -0000 Oleksandr Samoylyk wrote: > Julian Elischer wrote: >> this may be the issue: >> http://www.nabble.com/GRE-Mux-td16201899.html > > I think so. Should we hope for some progress in this direction in future? This is not an issue any more for mpd. Originally multiplexing based on peers addresses by socket binding and connecting was used. There was only problem with multiplexing multiple calls inside the same tunnel (having the same peer addresses). Recent time (ng_pptpgre.c rev. 1.41 of Mar 24 2008) I have improved ng_pptpgre node to do multiplexing alike to the ng_l2tp node does and the latest mpd-5.1 is able to use this feature when it is present at a build time. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 10 16:10:51 2008 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 493CA106564A; Sat, 10 May 2008 16:10:51 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id EDA608FC16; Sat, 10 May 2008 16:10:50 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 3736FB84D; Sat, 10 May 2008 19:10:48 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 508E4B848; Sat, 10 May 2008 19:10:04 +0300 (EEST) Message-ID: <4825C8E3.5020501@samoylyk.sumy.ua> Date: Sat, 10 May 2008 19:10:11 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> In-Reply-To: <4825B75B.9050604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 16:10:51 -0000 Alexander Motin wrote: > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > I can't even list all nodes. # ngctl list ngctl: send msg: No buffer space available # sysctl -a | grep graph net.graph.msg_version: 8 net.graph.abi_version: 11 net.graph.maxdata: 512 net.graph.maxalloc: 4096 net.graph.control.proto: 2 net.graph.data.proto: 1 net.graph.family: 32 net.graph.recvspace: 128000 net.graph.maxdgram: 128000 Any other way to check? -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 16:15:52 2008 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 A33A8106566C for ; Sat, 10 May 2008 16:15:52 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9E08FC16 for ; Sat, 10 May 2008 16:15:51 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 123765754; Sat, 10 May 2008 19:15:51 +0300 Message-ID: <4825CA33.4040106@FreeBSD.org> Date: Sat, 10 May 2008 19:15:47 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825C8E3.5020501@samoylyk.sumy.ua> In-Reply-To: <4825C8E3.5020501@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer Subject: Re: Problems with netgraph 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, 10 May 2008 16:15:52 -0000 Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Try to rebuild mpd to be sure it uses this feature. Also you can check >> this by observing the name of any ng_pptpgre hook used. If it is >> "upper", then ng_pptpgre multiplexing is not used and if it is >> "session_hhhh" then OK. > > I can't even list all nodes. > > # ngctl list > ngctl: send msg: No buffer space available Nodes list can be big. This should help you to get it: kern.ipc.maxsockbuf=1048576 net.graph.maxdgram=524288 net.graph.recvspace=524288 -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 10 16:31:15 2008 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 76B391065670; Sat, 10 May 2008 16:31:15 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 26B4E8FC1B; Sat, 10 May 2008 16:31:14 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id 172CDB826; Sat, 10 May 2008 19:31:13 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 1430CB816; Sat, 10 May 2008 19:30:59 +0300 (EEST) Message-ID: <4825CDCA.5020607@samoylyk.sumy.ua> Date: Sat, 10 May 2008 19:31:06 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> In-Reply-To: <4825B75B.9050604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 10 May 2008 16:31:15 -0000 Alexander Motin wrote: > > Try to rebuild mpd to be sure it uses this feature. Also you can check > this by observing the name of any ng_pptpgre hook used. If it is > "upper", then ng_pptpgre multiplexing is not used and if it is > "session_hhhh" then OK. > # ngctl show mpd24375-L-237-lt: Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd24375-B-607 ppp 0008e922 link0 left pptpgre 0008e91b upper It's "upper". And I don't know why :( The sources were updated before building new kernel on May, 5, 2008. The mpd5 port was rebuilt and restarted just few hours ago. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 16:38:07 2008 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 760371065671; Sat, 10 May 2008 16:38:07 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: from hunter.Sisis.de (mail.oclc.de [193.31.11.194]) by mx1.freebsd.org (Postfix) with ESMTP id 90CF18FC16; Sat, 10 May 2008 16:38:06 +0000 (UTC) (envelope-from matthias.apitz@oclc.org) Received: (from mail@localhost) by hunter.Sisis.de (8.8.8/8.8.8) id SAA00281; Sat, 10 May 2008 18:27:12 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) Received: from ppp-88-217-95-224.dynamic.mnet-online.de(88.217.95.224) by hunter.Sisis.de via smap (V2.1) id xma000146; Sat, 10 May 08 18:26:50 +0200 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id m4AGYHwL018619; Sat, 10 May 2008 18:34:17 +0200 (CEST) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Sat, 10 May 2008 18:34:17 +0200 From: Matthias Apitz To: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org Message-ID: <20080510163417.GA17718@rebelion.Sisis.de> References: <20080509123521.GA11366@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-RELEASE (i386) Cc: Ian Smith Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 16:38:07 -0000 El día Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribió: > > Stevens explains further more that client and server could handshake to > > omit the constant flag (7e) and adress field (ff) and reduce the > > protocol field (0021) to one byte (21), but in the above packages 'flag' is there > > while 'addr' and 'control' are missing? > > > > any PPP expert here to explain this? could this be the reason that the > > connection gets stuck? > > Probably not the sort of help you wanted, and I'm no PPP expert, but > having run ppp(8) in and out for ten years and more recently mpd(8) > outbound, I have to ask, does this gig depend on using pppd? ... I've checked a short moment mpd5(8) (installed it from the ports and checked the manual about configuration); it seems that it would me take some time to get the CHAT part working; because, on the other hand, my installed pppd(8) works just fine, with older UMTS cards, I don't think that this is the problem; I've spent some more hours as well on debugging and now I have it clear a) what the problem is with the TCP packages b) why LCP works just nicely c) why CHAT works as well nicely d) why telneting to the ECHO port works also if (and only if) you enter only a few characters on the line, say up to five the problem is the size of the buffer coming down from user space in the nzstart() function: ... data = tty->t_outq.c_cf; cbp = (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND); cnt = min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc); if(cnt == 0) goto out; buf = malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT); memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf->data)); buf->size = cnt; printf("nzdebug: nzstart() -> STAILQ_INSERT_TAIL() of %d bytes\n", cnt); STAILQ_INSERT_TAIL(&fifo_head, buf, fifo_bufs); ndflush(&tty->t_outq, cnt); intr_ul(sc, pidx, ENABLE); ... I saw frames upto 108 bytes length; and later send_data(), which puts the data into the card's buffer, picks the data up like this: buf = STAILQ_FIRST(&fifo_head); size = buf->size; memcpy(sc->send_buf, buf->data, ul_size < SEND_BUF_MAX ? ul_size : SEND_BUF_MAX ); STAILQ_REMOVE_HEAD(&fifo_head, fifo_bufs); free(buf, M_DEVBUF); port->tx_data += size; /* Write length + data */ bus_write_4(sc->res, ul_offs, size); bus_write_region_4(sc->res, ul_offs + 4, (u_int32_t *)sc->send_buf, size); SEND_BUF_MAX is 1024 but the 'ul_size' (size of the up link part of the card) is only 68!! that's why parts of the PPP frames are just thrown away if the frame size is bigger than 64 (4 bytes are needed for the size); I got to know this comparing the hex dumps of the buffer in the nzstart() and send_data() parts; at the moment I have no idea how to fix this :-(( I've put the driver here: http://www.unixarea.de/nozomi/nozomi.c if someone wants to have a look and give me some hint; thanks in advance; it's Saturday evening and sunny, time for go out... matthias From owner-freebsd-net@FreeBSD.ORG Sat May 10 16:51:20 2008 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 E1F3B1065673 for ; Sat, 10 May 2008 16:51:20 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5F2C68FC1A for ; Sat, 10 May 2008 16:51:19 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.11] (account mav@alkar.net HELO [192.168.11.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 123777185; Sat, 10 May 2008 19:51:19 +0300 Message-ID: <4825D280.9080807@FreeBSD.org> Date: Sat, 10 May 2008 19:51:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> In-Reply-To: <4825CDCA.5020607@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 10 May 2008 16:51:21 -0000 Oleksandr Samoylyk wrote: > # ngctl show mpd24375-L-237-lt: > Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > right mpd24375-B-607 ppp 0008e922 link0 > left pptpgre 0008e91b upper > > It's "upper". And I don't know why :( > The sources were updated before building new kernel on May, 5, 2008. > The mpd5 port was rebuilt and restarted just few hours ago. Here is mine: %ngctl show mpd95052-L2-4-lt: Name: mpd95052-L2-4-lt Type: tee ID: 000000eb Num hooks: 2 Local hook Peer name Peer type Peer ID Peer hook ---------- --------- --------- ------- --------- right mpd95052-B1-1 ppp 000000f0 link0 left pptpgre 000000ed session_b826 Have you updated your world also? Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from /usr/include/netgraph/ng_pptpgre.h at the build time to detect this feature presence. One more way to check this feature in mpd-5.1: Without this feature: # grep "PPTP: can't connect to" mpd5 # With this feature present: # grep "PPTP: can't connect to" mpd5 Binary file mpd5 matches # -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 10 17:01:43 2008 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 45C531065678; Sat, 10 May 2008 17:01:43 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id E4F2A8FC15; Sat, 10 May 2008 17:01:42 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id DCE90B82F; Sat, 10 May 2008 20:01:41 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 1BB56B829; Sat, 10 May 2008 20:01:28 +0300 (EEST) Message-ID: <4825D4EE.2060006@samoylyk.sumy.ua> Date: Sat, 10 May 2008 20:01:34 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> In-Reply-To: <4825D280.9080807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 10 May 2008 17:01:43 -0000 Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> # ngctl show mpd24375-L-237-lt: >> Name: mpd24375-L-237-lt Type: tee ID: 0008e919 Num >> hooks: 2 >> Local hook Peer name Peer type Peer ID Peer hook >> ---------- --------- --------- ------- --------- >> right mpd24375-B-607 ppp 0008e922 link0 >> left pptpgre 0008e91b upper >> >> It's "upper". And I don't know why :( >> The sources were updated before building new kernel on May, 5, 2008. >> The mpd5 port was rebuilt and restarted just few hours ago. > > Here is mine: > %ngctl show mpd95052-L2-4-lt: > Name: mpd95052-L2-4-lt Type: tee ID: 000000eb Num hooks: 2 > Local hook Peer name Peer type Peer ID Peer hook > ---------- --------- --------- ------- --------- > right mpd95052-B1-1 ppp 000000f0 link0 > left pptpgre 000000ed session_b826 > > Have you updated your world also? No, just kernel. Should I? > Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from /usr/include/netgraph/ng_pptpgre.h at the build time to detect this feature presence. # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 imp Exp $ > One more way to check this feature in mpd-5.1: > Without this feature: > # grep "PPTP: can't connect to" mpd5 > # > With this feature present: > # grep "PPTP: can't connect to" mpd5 > Binary file mpd5 matches > # > # cd /usr/local/sbin/ # grep "PPTP: can't connect to" mpd5 # -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 17:08:01 2008 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 2BEF11065674 for ; Sat, 10 May 2008 17:08:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id BFA818FC17 for ; Sat, 10 May 2008 17:08:00 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2995967rvf.43 for ; Sat, 10 May 2008 10:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=CFXAzyeY1HvgpUK1XvVFxEliU3x6CcfCs/ylYUH19Mw=; b=IDeEutc8uEwfaaQo29KD3uJBL83LVfqW/jk5I2nZ5HXTiquvF2xPzYDUn5Z8rADpHhgh7K2Hx84nggNEJUuGhUBLMgzy3KWrEdb3u6pGXbIfciMuADCH5gkE3n/MUFuEA8OPwVzkr1Rt63wpnL2IqF7EhbjlOLxHTk0I/fgaBTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=r79E9hp+XoLO2kPuAU4aEInM05MJefYzegTuFGmYayY84NF1Zxngsp9zS4mn8GurpAKiIHX5ErGeWebGH2JS4inLRdXNftNu82i6p4x+4E5dSrZRNpHe7roSMTP7X5Hu2Hl8AQhsPlnvbOLRp6ocFWgyB1o6ksovvm0JteaNTw8= Received: by 10.140.249.20 with SMTP id w20mr2797345rvh.103.1210439280118; Sat, 10 May 2008 10:08:00 -0700 (PDT) Received: by 10.141.171.3 with HTTP; Sat, 10 May 2008 10:08:00 -0700 (PDT) Message-ID: <2e77fc10805101008ybafe7b3g8b9210cb8d2955d@mail.gmail.com> Date: Sat, 10 May 2008 13:08:00 -0400 From: "Niki Denev" Sender: ndenev@gmail.com To: "Matthias Apitz" In-Reply-To: <20080510163417.GA17718@rebelion.Sisis.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20080509123521.GA11366@rebelion.Sisis.de> <20080510163417.GA17718@rebelion.Sisis.de> X-Google-Sender-Auth: 3ca67c6bdfd94d7b Cc: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, Ian Smith Subject: Re: porting "nozomi" driver (Option N.V. GlobeTrotter 3G+ UMTS datacard) to FreeBSD 7.0R 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, 10 May 2008 17:08:01 -0000 On Sat, May 10, 2008 at 12:34 PM, Matthias Apitz wrote: > El d=EDa Saturday, May 10, 2008 a las 12:49:02AM +1000, Ian Smith escribi= =F3: > >> > Stevens explains further more that client and server could handshake = to >> > omit the constant flag (7e) and adress field (ff) and reduce the >> > protocol field (0021) to one byte (21), but in the above packages 'fl= ag' is there >> > while 'addr' and 'control' are missing? >> > >> > any PPP expert here to explain this? could this be the reason that th= e >> > connection gets stuck? >> >> Probably not the sort of help you wanted, and I'm no PPP expert, but >> having run ppp(8) in and out for ten years and more recently mpd(8) >> outbound, I have to ask, does this gig depend on using pppd? > ... > > I've checked a short moment mpd5(8) (installed it from the ports and > checked the manual about configuration); it seems that it would me take > some time to get the CHAT part working; > > because, on the other hand, my installed pppd(8) works just fine, > with older UMTS cards, I don't think that this is the problem; > > I've spent some more hours as well on debugging and now I have it clear > a) what the problem is with the TCP packages > b) why LCP works just nicely > c) why CHAT works as well nicely > d) why telneting to the ECHO port works also if (and only if) you enter > only a few characters on the line, say up to five > > the problem is the size of the buffer coming down from user space in the > nzstart() function: > > ... > data =3D tty->t_outq.c_cf; > cbp =3D (struct cblock *) ((intptr_t) tty->t_outq.c_cf & ~CROUND); > cnt =3D min((char *) (cbp+1) - tty->t_outq.c_cf, tty->t_outq.c_cc)= ; > > if(cnt =3D=3D 0) > goto out; > > buf =3D malloc(sizeof(struct fifo_buf), M_DEVBUF, M_NOWAIT); > memcpy(buf->data, data, cnt < sizeof(buf->data) ? cnt : sizeof(buf= ->data)); > buf->size =3D cnt; > > printf("nzdebug: nzstart() -> STAILQ_INSERT_TAIL() of %d bytes\n",= cnt); > STAILQ_INSERT_TAIL(&fifo_head, buf, fifo_bufs); > ndflush(&tty->t_outq, cnt); > intr_ul(sc, pidx, ENABLE); > ... > > I saw frames upto 108 bytes length; > > and later send_data(), which puts the data into the card's buffer, picks > the data up like this: > > buf =3D STAILQ_FIRST(&fifo_head); > size =3D buf->size; > > memcpy(sc->send_buf, buf->data, ul_size < SEND_BUF_MAX ? ul_size = : SEND_BUF_MAX ); > > STAILQ_REMOVE_HEAD(&fifo_head, fifo_bufs); > free(buf, M_DEVBUF); > > port->tx_data +=3D size; > > /* Write length + data */ > bus_write_4(sc->res, ul_offs, size); > bus_write_region_4(sc->res, ul_offs + 4, (u_int32_t *)sc->send_buf= , size); > > SEND_BUF_MAX is 1024 but the 'ul_size' (size of the up link part of the > card) is only 68!! that's why parts of the PPP frames are just thrown > away if the frame size is bigger than 64 (4 bytes are needed for the > size); I got to know this comparing the hex dumps of the buffer in the > nzstart() and send_data() parts; > > at the moment I have no idea how to fix this :-(( > I've put the driver here: > > http://www.unixarea.de/nozomi/nozomi.c > > if someone wants to have a look and give me some hint; thanks in advance; > > it's Saturday evening and sunny, time for go out... > > matthias > I can see that this is the initial port of the Linux nozomi driver that i d= id back in 2006, and i got stuck exactly with the same problem, ppp connection get's established, but only small packets are passed. I will see if I can get my hands on this HSDPA/UMTS card (i don't have it anymore) and help. Niki From owner-freebsd-net@FreeBSD.ORG Sat May 10 17:24:24 2008 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 771071065671 for ; Sat, 10 May 2008 17:24:24 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E73048FC0C for ; Sat, 10 May 2008 17:24:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 123785469; Sat, 10 May 2008 20:24:23 +0300 Message-ID: <4825DA46.1090400@FreeBSD.org> Date: Sat, 10 May 2008 20:24:22 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Oleksandr Samoylyk References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> In-Reply-To: <4825D4EE.2060006@samoylyk.sumy.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 10 May 2008 17:24:24 -0000 Oleksandr Samoylyk wrote: > Alexander Motin wrote: >> Oleksandr Samoylyk wrote: >>> It's "upper". And I don't know why :( >>> The sources were updated before building new kernel on May, 5, 2008. >>> The mpd5 port was rebuilt and restarted just few hours ago. >> >> Have you updated your world also? > > No, just kernel. Should I? In my experience it is sane to keep kernel and the world in sync. Even if binary compatibility is declared inside the same branch, there could be some minorities like this one. Also it may be hard for developers to track all possible kernel/world combinations. >> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >> feature presence. > > # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 imp > Exp $ HEAD: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 mav Exp $ RELENG_7: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 08:01:26 mav Exp $ RELENG_6: * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 mav Exp $ -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sat May 10 17:28:11 2008 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 D927E106567C; Sat, 10 May 2008 17:28:11 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from mail.telesweet.net (news.telesweet.net [194.110.252.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8826C8FC0C; Sat, 10 May 2008 17:28:11 +0000 (UTC) (envelope-from oleksandr@samoylyk.sumy.ua) Received: from localhost (localhost [127.0.0.1]) by mail.telesweet.net (Postfix) with ESMTP id BFD50B839; Sat, 10 May 2008 20:28:09 +0300 (EEST) X-Virus-Scanned: by Telesweet Mail Virus Scanner X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.44] Received: from [10.0.14.191] (pigeon.telesweet [10.0.14.191]) by mail.telesweet.net (Postfix) with ESMTP id 657DCB82F; Sat, 10 May 2008 20:27:55 +0300 (EEST) Message-ID: <4825DB21.3050902@samoylyk.sumy.ua> Date: Sat, 10 May 2008 20:28:01 +0300 From: Oleksandr Samoylyk User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alexander Motin References: <48207C8B.4020509@samoylyk.sumy.ua> <48209BC4.5080602@elischer.org> <1210148584.00067004.1210135802@10.7.7.3> <1210155784.00067045.1210144801@10.7.7.3> <1210195392.00067265.1210183802@10.7.7.3> <1210195402.00067283.1210184402@10.7.7.3> <1210202586.00067324.1210189802@10.7.7.3> <1210202588.00067326.1210189802@10.7.7.3> <1210202593.00067329.1210190402@10.7.7.3> <1210209785.00067436.1210197002@10.7.7.3> <4825B177.7020503@FreeBSD.org> <4825B397.4060005@samoylyk.sumy.ua> <4825B75B.9050604@FreeBSD.org> <4825CDCA.5020607@samoylyk.sumy.ua> <4825D280.9080807@FreeBSD.org> <4825D4EE.2060006@samoylyk.sumy.ua> <4825DA46.1090400@FreeBSD.org> In-Reply-To: <4825DA46.1090400@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Problems with netgraph 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, 10 May 2008 17:28:11 -0000 Alexander Motin wrote: > Oleksandr Samoylyk wrote: >> Alexander Motin wrote: >>> Oleksandr Samoylyk wrote: >>>> It's "upper". And I don't know why :( >>>> The sources were updated before building new kernel on May, 5, 2008. >>>> The mpd5 port was rebuilt and restarted just few hours ago. >>> >>> Have you updated your world also? >> >> No, just kernel. Should I? > > In my experience it is sane to keep kernel and the world in sync. Even > if binary compatibility is declared inside the same branch, there could > be some minorities like this one. Also it may be hard for developers to > track all possible kernel/world combinations. > >>> Mpd checks NG_PPTPGRE_HOOK_SESSION_F macro from >>> /usr/include/netgraph/ng_pptpgre.h at the build time to detect this >>> feature presence. >> >> # cat /usr/include/netgraph/ng_pptpgre.h | grep FreeBSD: >> * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9 2005/01/07 01:45:39 >> imp Exp $ > > HEAD: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.10 2008/03/24 22:55:22 > mav Exp $ > RELENG_7: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.10.1 2008/03/30 > 08:01:26 mav Exp $ > RELENG_6: > * $FreeBSD: src/sys/netgraph/ng_pptpgre.h,v 1.9.2.1 2008/04/07 10:33:28 > mav Exp $ > Ok, I'll update and rebuild kernel, world and mpd5 and write you back with results. -- Oleksandr Samoylyk OVS-RIPE From owner-freebsd-net@FreeBSD.ORG Sat May 10 19:11:55 2008 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 5FD4B1065675 for ; Sat, 10 May 2008 19:11:55 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from vps1.jcornwall.me.uk (vps1.jcornwall.me.uk [193.227.111.74]) by mx1.freebsd.org (Postfix) with ESMTP id 299408FC1B for ; Sat, 10 May 2008 19:11:55 +0000 (UTC) (envelope-from jay@jcornwall.me.uk) Received: from [82.70.152.17] (cobra.home.jcornwall.me.uk [82.70.152.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vps1.jcornwall.me.uk (Postfix) with ESMTP id 8FF335201D4 for ; Sat, 10 May 2008 19:56:58 +0100 (BST) Message-ID: <4825EF8D.1050304@jcornwall.me.uk> Date: Sat, 10 May 2008 19:55:09 +0100 From: "Jay L. T. Cornwall" User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: if_bridge with two subnets 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, 10 May 2008 19:11:55 -0000 Hi, I have an if_bridge, thus: bridge0: flags=8843 metric 0 mtu 1500 inet XX.XX.XXX.20 netmask 0xfffffff8 broadcast XX.XX.XXX.23 inet 192.168.1.30 netmask 0xffffff00 broadcast 192.168.1.255 On one side of the bridge is a layer 2 switch with clients of a mix of addresses from these two subnets. On the other side is a gateway XX.XX.XXX.22. All clients can communicate through the gateway correctly, with the 192.168.1.x subnet being NAT'd. However, clients from one subnet cannot communicate with clients from the other subnet. Pinging a 192.168.1.X machine from the other subnet shows the packet incorrectly routed out through the gateway, not back through the interface it came. The routing table shows that both subnets should be routed through the bridge: XX.XX.XXX.XX/29 link#5 UC 0 0 bridge 192.168.1.0/24 link#5 UC 0 0 bridge The bridge host itself can ping machines on both subnets. So why is the if_bridge routing packets destined for the private subnet out through the default route instead? (The specific hosts being pinged are present in the routing table from ARP lookups. They are all destined for the bridge interface.) -- Jay L. T. Cornwall http://www.jcornwall.me.uk/ From owner-freebsd-net@FreeBSD.ORG Sat May 10 20:08:11 2008 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 3A24D1065670; Sat, 10 May 2008 20:08:11 +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 102718FC15; Sat, 10 May 2008 20:08:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4AK8AaB018384; Sat, 10 May 2008 20:08:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4AK8Aou018380; Sat, 10 May 2008 20:08:10 GMT (envelope-from linimon) Date: Sat, 10 May 2008 20:08:10 GMT Message-Id: <200805102008.m4AK8Aou018380@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2008 20:08:11 -0000 Old Synopsis: iwi periodically disassociates/assotiates New Synopsis: [iwi] iwi periodically disassociates/associates [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 10 20:07:33 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=123559