Re: Enabling netmap in fbsd9.1
On Tue, 07 May 2013 00:45:15, C. L. Martinez wrote: CLM> According to fbsd 9.1 release notes, netmap is included in this release, CLM> but how do I need to do to enable this feature?. Do I need to recompile CLM> default kernel with 'device netmap' option enabled?. Only load kernel CLM> modules?. Yes, you have to recompile kernel with 'device netmap'. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ifconfig media for ixgbe
I'm testing Intel 82599EB network adapter. Sometimes link is lost. 1. /usr/src/sys/dev/ixgbe/README said When 82599-based SFP+ devices are connected back to back, they should be set to the same Speed setting via Ethtool. Results may vary if you mix speed settings. But manual speed settings for ixgbe don't work under FreeBSD: # ifconfig -m ix0 ix0: flags=8843 metric 0 mtu 1500 options=407bb capabilities=1507bb ... skipped ... media: Ethernet autoselect (10Gbase-SR ) status: active supported media: media autoselect media 10Gbase-SR # ifconfig ix0 media 10Gbase-SR ifconfig: SIOCSIFMEDIA (media): Invalid argument And as I can see it is limited in driver: http://bxr.su/FreeBSD/sys/dev/ixgbe/ixgbe.c#1697 README file is outdated? 2. Link sometimes (but no always) lost aster starting /usr/src/tools/tools/netmap/pkt-gen Sometime link restorted after aboring pkt-gen, sometimes only after power off/on (ifconfig down/up don't help). Is this netmap related issue? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: surprise surprise (VM related) [lu...@freebsd.org: svn commit: r250911 - head/sys/kern]
On Wed, 22 May 2013 20:42:44, Luigi Rizzo wrote: LR> Using polling, a FreeBSD instance under qemu-kvm remains perfectly LR> responsive even when bombed with 10 Mpps over an emulated e1000, LR> and happily processes 1.7 Mpps through ipfw. Can you share qemu network configuration used in tests? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
livelock with full loaded em(4)
Hello.
I have test boxes with em(4) network card - Intel 82563EB
FreeBSD version - 8.2 stable from 2012-01-15, amd64
When this NIC is full loaded livelock occurs - system is unresponsive
even from local console.
To generate load I use netsend from /usr/src/tools/tools/netrate/
but other traffic source (e. g. TCP instead UDP) cause same problem.
There is 2 quese of this livelock:
1. With full load kernel thread "em1 taskq" hogs CPU.
top -zISHP for interface load a bit less, than full.
Traffic is generated by
# netsend 172.16.0.2 9001 8500 14300 3600
where 14300 is packets per second:
112 processes: 10 running, 82 sleeping, 20 waiting
CPU 0: 0.0% user, 0.0% nice, 27.1% system, 0.0% interrupt, 72.9% idle
CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 2: 2.3% user, 0.0% nice, 97.7% system, 0.0% interrupt, 0.0% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 26M Active, 378M Inact, 450M Wired, 132K Cache, 63M Buf, 15G Free
Swap: 8192M Total, 8192M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
7737 ayuzhaninov 1190 5832K 1116K CPU22 0:04 100.00% netsend
0 root -680 0K 144K - 0 2:17 22.27% {em1 taskq}
top -zISHP for full interface load (some drops occurs), load is
generated by
# netsend 172.16.0.2 9001 8500 14400 3600
112 processes: 11 running, 81 sleeping, 20 waiting
CPU 0: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
CPU 1: 4.1% user, 0.0% nice, 95.9% system, 0.0% interrupt, 0.0% idle
CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 26M Active, 378M Inact, 450M Wired, 132K Cache, 63M Buf, 15G Free
Swap: 8192M Total, 8192M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
0 root -680 0K 144K CPU00 2:17 100.00% {em1 taskq}
7759 ayuzhaninov 1190 5832K 1116K CPU11 0:01 100.00% netsend
So pps increased from 14300 to 14400 (0.7%), but CPU load from "em1 taskq"
thread
increased from 27.1% to 100.00%
This at least strange, but system still works fine unil I run
sysctl dev.cpu.0.temperature
2. sysctl handler code for coretemp must be executed on target cpu,
e. g. for dev.cpu.0.temperature code executed on CPU0.
If CPU0 is fully loaded by "em1 taskq" sysctl handler for
dev.cpu.0.temperature acquires Giant mutex lock then tries to run code
on CPU0, but it can't - CPU0 is busy.
If Giant mutex hold for long time system is unresponsive. In my case
Giant mutex acquired when sysctl dev.cpu.0.temperature started and hold
all time while netsend is running.
This seems to be a scheduler problem:
1. Why "em1 taskq" runs only on CPU0 (there is no affinity for this tread)?
# procstat -k 0 | egrep '(PID|em1)'
PIDTID COMM TDNAME KSTACK
0 100038 kernel em1 taskq
# cpuset -g -t 100038
tid 100038 mask: 0, 1, 2, 3, 4, 5, 6, 7
2. Why "em1 taskq" is not preempted to execute sysctl handler code? This
is not short term condition - is netsend running for a hour, "em1 taskq"
is not preempted for a hour - sysctl all this time in running state but
don't have a chance to be executed.
--
Anton Yuzhaninov
P. S. I tried to use EM_MULTIQUEUE, but this is don't help in this case.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
livelock with full loaded em(4)
Hello.
I have test boxes with em(4) network card - Intel 82563EB
FreeBSD version - 8.2 stable from 2012-01-15, amd64
When this NIC is full loaded livelock occurs - system is unresponsive
even from local console.
To generate load I use netsend from /usr/src/tools/tools/netrate/
but other traffic source (e. g. TCP instead UDP) cause same problem.
There is need 2 conditions for this livelock:
1. With full NIC load, kernel thread "em1 taskq" hogs CPU.
top -zISHP for interface load a bit less, than full.
Traffic is generated by
# netsend 172.16.0.2 9001 8500 14300 3600
where 14300 is packets per second:
112 processes: 10 running, 82 sleeping, 20 waiting
CPU 0: 0.0% user, 0.0% nice, 27.1% system, 0.0% interrupt, 72.9% idle
CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 2: 2.3% user, 0.0% nice, 97.7% system, 0.0% interrupt, 0.0% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 26M Active, 378M Inact, 450M Wired, 132K Cache, 63M Buf, 15G Free
Swap: 8192M Total, 8192M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
7737 ayuzhaninov 1190 5832K 1116K CPU22 0:04 100.00% netsend
0 root -680 0K 144K - 0 2:17 22.27% {em1 taskq}
top -zISHP for full interface load (some drops occurs), load is
generated by
# netsend 172.16.0.2 9001 8500 14400 3600
112 processes: 11 running, 81 sleeping, 20 waiting
CPU 0: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
CPU 1: 4.1% user, 0.0% nice, 95.9% system, 0.0% interrupt, 0.0% idle
CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 5: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 6: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
CPU 7: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 26M Active, 378M Inact, 450M Wired, 132K Cache, 63M Buf, 15G Free
Swap: 8192M Total, 8192M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND
0 root -680 0K 144K CPU00 2:17 100.00% {em1 taskq}
7759 ayuzhaninov 1190 5832K 1116K CPU11 0:01 100.00% netsend
So pps increased from 14300 to 14400 (0.7%), but CPU load from "em1 taskq"
thread
increased from 27.1% to 100.00%
This at least strange, but system still works fine until I run
sysctl dev.cpu.0.temperature
2. sysctl handler code for coretemp must be executed on target CPU,
e. g. for dev.cpu.0.temperature code executed on CPU0.
If CPU0 is fully loaded by "em1 taskq" sysctl handler for
dev.cpu.0.temperature acquires Giant mutex lock then tries to run code
on CPU0, but it can't - CPU0 is busy.
If Giant mutex hold for long time system is unresponsive. In my case
Giant mutex acquired when sysctl dev.cpu.0.temperature started and hold
all time while netsend is running.
This seems to be a scheduler problem:
1. Why "em1 taskq" runs only on CPU0 (there is no affinity for this tread)?
# procstat -k 0 | egrep '(PID|em1)'
PIDTID COMM TDNAME KSTACK
0 100038 kernel em1 taskq
# cpuset -g -t 100038
tid 100038 mask: 0, 1, 2, 3, 4, 5, 6, 7
2. Why "em1 taskq" is not preempted to execute sysctl handler code? This
is not short term condition - is netsend running for a hour, "em1 taskq"
is not preempted for a hour - sysctl all this time in running state but
don't have a chance to be executed.
--
Anton Yuzhaninov
P. S. I tried to use EM_MULTIQUEUE, but this is don't help in my case.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Carp configuration errors
On Thu, 24 Jan 2013 21:26:46, Ask Bj?rn Hansen wrote: ABrH> After upgrading to 9.1 it seems like carp doesn't pay attention to advskew anymore. I have two boxes each setup with carp0 and carp1; the intention is that in regular operation proxy1 is master for carp0 and proxy2 for carp1. However, whichever box comes up second is BACKUP for both. 1. Do your have sysctl net.inet.carp.preempt=1 ? With preempt=0 box comes up second should be in backup state. 2. For carp problem troubleshooting it is useful temporary increase carp logs verbosity: sysctl net.inet.carp.log=2 -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
connections in CLOSED state
It seems to be there is some race and/or leak in tcp stack: 1. Netstat show connections in closed state (for a long time): > netstat -n | egrep '(Proto|CLOSED)' Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 10.25.1.54.35543 10.25.1.54.35544 CLOSED tcp4 0 0 10.25.1.54.57273 10.25.1.54.57274 CLOSED tcp4 0 0 10.25.1.54.40445 10.25.1.54.62378 CLOSED tcp4 0 0 10.25.1.54.43403 10.25.1.54.43404 CLOSED tcp4 0 0 10.25.1.54.36380 10.25.1.54.36381 CLOSED ... 2. sockstat don't show any processes to which this sockets can belong to. some info from kgdb: > netstat -nA -p tcp | egrep '(Tcpcb|CLOSED)' TcpcbProto Recv-Q Send-Q Local Address Foreign Address (state) ff01abfb8370 tcp4 0 0 10.25.1.54.35543 10.25.1.54.35544 CLOSED (kgdb) set $t = (struct tcpcb) *0xff01abfb8370 (kgdb) p $t->t_inpcb->inp_socket->so_count $18 = 0 > uname -srp FreeBSD 8.2-PRERELEASE-20110101 amd64 -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
net/mpd5: proxy arp don't work on FreeBSD 8
mdp can't add proxy arp record. From mpd logs: Mar 1 15:10:34 x0001 mpd: [B-1] IFACE: Add address 10.25.1.240/32->10.25.1.241 to ng0 Mar 1 15:10:34 x0001 mpd: [B-1] exec: /usr/sbin/arp -S 10.25.1.241 0:15:17:35:1c:22 pub Mar 1 15:10:34 x0001 mpd: [B-1] system: command "/usr/sbin/arp" returned 256 Same command from shell: # arp -S 10.25.1.241 0:15:17:35:1c:22 pub delete: cannot locate 10.25.1.241 cannot intuit interface index and type for 10.25.1.241 FreeBSD version - RELENG_8 from 2010-02-15 (this changes http://svn.freebsd.org/changeset/base/201614 included in used version) -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net/mpd5: proxy arp don't work on FreeBSD 8
On Mon, 1 Mar 2010 23:33:27 +0100, Bernd Walter wrote: BW> On Mon, Mar 01, 2010 at 03:33:41PM +0000, Anton Yuzhaninov wrote: >> mdp can't add proxy arp record. From mpd logs: >> >> Mar 1 15:10:34 x0001 mpd: [B-1] IFACE: Add address >> 10.25.1.240/32->10.25.1.241 to ng0 >> Mar 1 15:10:34 x0001 mpd: [B-1] exec: /usr/sbin/arp -S 10.25.1.241 >> 0:15:17:35:1c:22 pub >> Mar 1 15:10:34 x0001 mpd: [B-1] system: command "/usr/sbin/arp" returned 256 >> >> Same command from shell: >> >> # arp -S 10.25.1.241 0:15:17:35:1c:22 pub >> delete: cannot locate 10.25.1.241 >> cannot intuit interface index and type for 10.25.1.241 BW> BW> It looks like you don't have a network configured for 10.25.1.241, so BW> arp(8) can't find the interface to configure the ARP entry to. BW> You either need to supply -i in case the host shouldn't get a local BW> IP in the given network or configure the interface to be a real part BW> of it. Network for this ip is configured. Before ng0 created: # route -n get 10.25.1.241 route to: 10.25.1.241 destination: 10.25.1.0 mask: 255.255.255.0 interface: vlan408 flags: When ng0 is created route get point to ng0. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net/mpd5: proxy arp don't work on FreeBSD 8
On Mon, 1 Mar 2010 15:33:41 + (UTC), Anton Yuzhaninov wrote: AY> mdp can't add proxy arp record. From mpd logs: AY> Mar 1 15:10:34 x0001 mpd: [B-1] IFACE: Add address 10.25.1.240/32->10.25.1.241 to ng0 AY> Mar 1 15:10:34 x0001 mpd: [B-1] exec: /usr/sbin/arp -S 10.25.1.241 0:15:17:35:1c:22 pub AY> Mar 1 15:10:34 x0001 mpd: [B-1] system: command "/usr/sbin/arp" returned 256 This problem can be repeated without mpd: # ifconfig vlan408 vlan408: flags=8844 metric 0 mtu 1500 options=3 ether 00:04:23:ba:2a:7a inet 10.25.1.244 netmask 0xff00 broadcast 10.25.1.255 ... # kldload ng_iface # ngctl mkpeer . iface foobar inet # ifconfig ng0 192.168.100.100/32 10.25.1.245 # ifconfig ng0 ng0: flags=88d1 metric 0 mtu 1500 inet 192.168.100.100 --> 10.25.1.245 netmask 0x # arp -s 10.25.1.245 00:04:23:ba:2a:7a pub cannot intuit interface index and type for 10.25.1.245 This commands work fine on RELENG_7, but don't work on RELENG_8 or CURRENT, and it seems to be regression. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net/mpd5: proxy arp don't work on FreeBSD 8
On Tue, 2 Mar 2010 09:44:04 -0300, Luiz Otavio O Souza wrote: >> This problem can be repeated without mpd: >> >> # ifconfig vlan408 >> vlan408: flags=8844 metric 0 mtu 1500 >>options=3 >>ether 00:04:23:ba:2a:7a >>inet 10.25.1.244 netmask 0xff00 broadcast 10.25.1.255 >> ... >> # kldload ng_iface >> # ngctl mkpeer . iface foobar inet >> # ifconfig ng0 192.168.100.100/32 10.25.1.245 >> # ifconfig ng0 >> ng0: flags=88d1 metric 0 mtu >> 1500 >>inet 192.168.100.100 --> 10.25.1.245 netmask 0x >> # arp -s 10.25.1.245 00:04:23:ba:2a:7a pub >> cannot intuit interface index and type for 10.25.1.245 LOOS> LOOS> But what about the 192.168.100.100 ? You are using IPs from this network somewhere else ? 1. No. Why it should be used somewhere else? 2. It works in RELENG7 Other example: vlan408: 10.25.1.244/24 ng0: 10.25.1.245/32 -> 10.25.1.246 same error: cannot intuit interface index and type for 10.25.1.246 LOOS> vlan100: flags=8843 metric 0 mtu 1500 LOOS> ether 00:08:54:0e:55:77 LOOS> inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 LOOS> media: Ethernet autoselect (100baseTX ) LOOS> status: active ... LOOS> Then i just replace the bogus IP to some other valid IP (using the IP from vlan100): LOOS> LOOS> # ifconfig ng0 192.168.10.1/32 192.168.10.2 LOOS> # ifconfig ng0 LOOS> ng0: flags=88d1 metric 0 mtu 1500 LOOS> inet 192.168.10.1 --> 192.168.10.2 netmask 0x LOOS> # arp -S 192.168.10.2 1:2:3:4:5:6 pub; echo $? LOOS> arp: writing to routing socket: Invalid argument LOOS> 0 LOOS> # arp -an | grep 192.168.10.2 LOOS> ? (192.168.10.2) at 01:02:03:04:05:06 on vlan100 permanent published [vlan] Why same ip - 192.168.10.1 should be configuren on two different interfaces: vlan100 and ng0. It looks like ugly hack. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: net/mpd5: proxy arp don't work on FreeBSD 8
On Tue, 2 Mar 2010 11:13:16 + (UTC), Anton Yuzhaninov wrote: AY> This problem can be repeated without mpd: AY> AY> # ifconfig vlan408 AY> vlan408: flags=8844 metric 0 mtu 1500 AY> options=3 AY> ether 00:04:23:ba:2a:7a AY> inet 10.25.1.244 netmask 0xff00 broadcast 10.25.1.255 AY> ... AY> # kldload ng_iface AY> # ngctl mkpeer . iface foobar inet AY> # ifconfig ng0 192.168.100.100/32 10.25.1.245 AY> # ifconfig ng0 AY> ng0: flags=88d1 metric 0 mtu 1500 AY> inet 192.168.100.100 --> 10.25.1.245 netmask 0x AY> # arp -s 10.25.1.245 00:04:23:ba:2a:7a pub AY> cannot intuit interface index and type for 10.25.1.245 AY> AY> This commands work fine on RELENG_7, but don't work on RELENG_8 or AY> CURRENT, and it seems to be regression. Another example: # arp -s 10.25.1.245 auto pub using interface vlan408 for proxy with address 00:04:23:ba:2a:7a cannot intuit interface index and type for 10.25.1.245 arp(8) can find proper intrfeace - vlan408, but this interface is not used (because of strange code in crenel from r201282). -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Workaround for mpd5 and 8.0 broken proxy arp?
On Thu, 15 Apr 2010 10:49:08 -0700, Li, Qing wrote: >> Doesn't seem to have any effect. Please see >> http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html >> on how to reproduce. >> LQ> LQ> Could you please try the patch at: LQ> LQ> http://people.freebsd.org/~qingli/ng-patch.diff LQ> Thanks, this patch help in our case. But there is still same differences between FreeBSD7 and FreeBSD8 related to ng_iface tunnels, but may be not related to ARP. Detailed test of ng_iface + proxy arp is here: http://citrin.ru/stuff/freebsd_ng_iface_and_proxy_arp.txt -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bug in unix sockets garbage collector
On servers where used unix sockets, sometimes thread taskq start to eat 100% CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 Addition info about this problem - when this occurs sysctl net.local.inflight show negative number. % sysctl net.local.inflight net.local.inflight: -3 And this condition become always true: if (local_unp_rights) taskqueue_enqueue(taskqueue_thread, &unp_gc_task); It seems, that unp_rights decremented more often than incremented, or some race exist. -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysctl net.inet.tcp.syncache.count
% sysctl net.inet.tcp.syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 1024 net.inet.tcp.syncache.count: -84 net.inet.tcp.syncache.cachelimit: 102400 net.inet.tcp.syncache.bucketlimit: 100 Why number of entries in syncache is negative? % uname -srp FreeBSD 7.1-PRERELEASE amd64 -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0
The following reply was made to PR kern/122743; it has been noted by GNATS. From: Anton Yuzhaninov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 Date: Tue, 02 Dec 2008 02:00:40 +0300 It looks like similar to this: http://docs.freebsd.org/cgi/mid.cgi?492B2F46.9000709 Try to change type for wire_count in struct vm_page from u_short to u_int (on i386 it has some overhead - sizeof(vm_page) increased by 4 bytes). -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network Card
On Tue, 21 Apr 2009 16:37:29 +0530, Kaushal Shriyan wrote: KS> I have two lan cards em0 and rl0 on my system. is there a way to know on KS> freebsd which is onboard or pci card ?. The issue is my system is located at KS> remote location. KS> install from ports dmidecode, it can show mainboard name. Than read specification for this mainboard. -- Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: faster /etc/services
Monday, May 21, 2007, 11:09:38 AM, Edwin Groothuis wrote: EG> - Instead of reading and parsing /etc/services every time, use a EG> hash or btree file a la the aliases database. A hash one (first EG> key, next key) could be a replacement to use with getservent(), EG> while a btree one could be be a replacement to use with getservbyname(). EG> This doesn't have the startup-penalty, but the sysadmin needs to EG> keep track of changes in /etc/services and needs to rebuild it. I think it will be better solution. /etc/services edited by sysadmin rarely and we can place comments in this file about hash. EG> - Instead of reading and parsing /etc/services every time, open a EG> socket and ask a daemon for the information. Which daemon is a EG> good question, but it can automatically re-read the /etc/services EG> file if it got changed. Connection to external daemon is additional overhead. Anyway, is there need to optimize getservbyname()? Is there any applications, which call getservbyname() on each connection/request? IMHO /etc/services can be kept in current state. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_7: can't connect to Solaris
I can't connect from FreeBSD 7 box to Solaris 9. While between FreeBSD6 and Solaris 9 tcp work fine. I run on FreeBSD, and it nod't work: $ fetch -o /dev/null http://mail6:8274 fetch: transfer timed out OS versions: FreeBSD citrin.rambler.stack.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Fri Oct 19 00:31:03 MSD 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 SunOS mail6 5.9 Generic_117172-07 i86pc i386 i86pc tcpdump on freebsd side: 04:26:28.332895 81.19.65.162.57161 > 81.19.71.6.8274: S [bad tcp cksum 3038!] 3123015513:3123015513(0) win 65535 (DF) (ttl 64, id 27368, len 60, bad cksum 0!) 04:26:28.333213 81.19.71.6.8274 > 81.19.65.162.57161: S [tcp sum ok] 2890615179:2890615179(0) ack 3123015514 win 33304 (DF) (ttl 62, id 16035, len 64) 04:26:28.333290 81.19.65.162.57161 > 81.19.71.6.8274: . [bad tcp cksum 793f!] ack 1 win 260 498561841 622594948> (DF) (ttl 64, id 27369, len 52, bad cksum 0!) 04:26:28.334892 81.19.65.162.57161 > 81.19.71.6.8274: P [bad tcp cksum 572f!] 1:88(87) ack 1 win 260 (DF) (ttl 64, id 27370, len 139, bad cksum 0!) 04:26:28.335148 81.19.71.6.8274 > 81.19.65.162.57161: . [tcp sum ok] ack 88 win 33260 622594948 498561843> (DF) (ttl 62, id 16036, len 52) snoop in Solaris show same: 1 0.0 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Syn Seq=3123015513 Len=0 Win=65535 Options=1460,nop,wscale 8,sackOK,tstamp 498561841 0> 2 0.1 81.19.71.6 -> 81.19.65.162 TCP D=57161 S=8274 Syn Ack=3123015514 Seq=2890615179 Len=0 Win=33304 Options= 3 0.00028 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Ack=2890615180 Seq=3123015514 Len=0 Win=260 Options= 4 0.00162 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Push Ack=2890615180 Seq=3123015514 Len=87 Win=260 Options= 5 0.3 81.19.71.6 -> 81.19.65.162 TCP D=57161 S=8274 Ack=3123015601 Seq=2890615180 Len=0 Win=33260 Options= With net.inet.tcp.rfc1323=0 tcp work, but it should work with rfc1323=1 (and in FreeBSD 6 tcp to SunOS work with rfc1323=1). net.inet.tcp.log_debug=1 and nothing about this connection logged. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: can't connect to Solaris
On 25.10.2007 15:01, Rui Paulo wrote: On 25 Oct 2007, at 11:24, Anton Yuzhaninov wrote: I can't connect from FreeBSD 7 box to Solaris 9. While between FreeBSD6 and Solaris 9 tcp work fine. I run on FreeBSD, and it nod't work: $ fetch -o /dev/null http://mail6:8274 fetch: transfer timed out OS versions: FreeBSD citrin.rambler.stack.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Fri Oct 19 00:31:03 MSD 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 SunOS mail6 5.9 Generic_117172-07 i86pc i386 i86pc tcpdump on freebsd side: 04:26:28.332895 81.19.65.162.57161 > 81.19.71.6.8274: S [bad tcp cksum 3038!] 3123015513:3123015513(0) win 65535 8,sackOK,timestamp 498561841 0> (DF) (ttl 64, id 27368, len 60, bad cksum 0!) 04:26:28.333213 81.19.71.6.8274 > 81.19.65.162.57161: S [tcp sum ok] 2890615179:2890615179(0) ack 3123015514 win 33304 622594948 498561841,mss 1460,nop,wscale 1,nop,nop,sackOK> (DF) (ttl 62, id 16035, len 64) 04:26:28.333290 81.19.65.162.57161 > 81.19.71.6.8274: . [bad tcp cksum 793f!] ack 1 win 260 (DF) (ttl 64, id 27369, len 52, bad cksum 0!) 04:26:28.334892 81.19.65.162.57161 > 81.19.71.6.8274: P [bad tcp cksum 572f!] 1:88(87) ack 1 win 260 (DF) (ttl 64, id 27370, len 139, bad cksum 0!) 04:26:28.335148 81.19.71.6.8274 > 81.19.65.162.57161: . [tcp sum ok] ack 88 win 33260 (DF) (ttl 62, id 16036, len 52) snoop in Solaris show same: 1 0.0 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Syn Seq=3123015513 Len=0 Win=65535 Options=8,sackOK,tstamp 498561841 0> 2 0.1 81.19.71.6 -> 81.19.65.162 TCP D=57161 S=8274 Syn Ack=3123015514 Seq=2890615179 Len=0 Win=33304 Options=622594948 498561841,mss 1460,nop,wscale 1,nop,nop,sackOK> 3 0.00028 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Ack=2890615180 Seq=3123015514 Len=0 Win=260 Options=498561841 622594948> 4 0.00162 81.19.65.162 -> 81.19.71.6 TCP D=8274 S=57161 Push Ack=2890615180 Seq=3123015514 Len=87 Win=260 Options=498561843 622594948> 5 0.3 81.19.71.6 -> 81.19.65.162 TCP D=57161 S=8274 Ack=3123015601 Seq=2890615180 Len=0 Win=33260 Options=622594948 498561843> With net.inet.tcp.rfc1323=0 tcp work, but it should work with rfc1323=1 (and in FreeBSD 6 tcp to SunOS work with rfc1323=1). net.inet.tcp.log_debug=1 and nothing about this connection logged. As silby@ already pointed out to me, try changing TCP_MAX_WINSHIFT in src/sys/netinet/tcp.h to 4. With TCP_MAX_WINSHIFT 4 it works. But from other host with RELENG_7 tcp to Solaris work fine with unmodified kernel: IP (tos 0x0, ttl 64, id 6224, offset 0, flags [DF], proto TCP (6), length 60) 81.19.66.129.58995 > 81.19.71.6.8274: S, cksum 0x8ec9 (correct), 3166145604:3166145604(0) win 65535 8,sackOK,timestamp 671164 0> IP (tos 0x0, ttl 62, id 16631, offset 0, flags [DF], proto TCP (6), length 64) 81.19.71.6.8274 > 81.19.66.129.58995: S, cksum 0xa422 (correct), 3226718107:3226718107(0) ack 3166145605 win 33304 IP (tos 0x0, ttl 64, id 6225, offset 0, flags [DF], proto TCP (6), length 52) 81.19.66.129.58995 > 81.19.71.6.8274: ., cksum 0x6602 (correct), ack 1 win 260 IP (tos 0x0, ttl 64, id 6226, offset 0, flags [DF], proto TCP (6), length 139) 81.19.66.129.58995 > 81.19.71.6.8274: P, cksum 0x5639 (correct), 1:88(87) ack 1 win 260 IP (tos 0x0, ttl 62, id 16632, offset 0, flags [DF], proto TCP (6), length 52) 81.19.71.6.8274 > 81.19.66.129.58995: ., cksum 0xe4c2 (correct), ack 88 win 33260 IP (tos 0x0, ttl 62, id 16633, offset 0, flags [DF], proto TCP (6), length 623) 81.19.71.6.8274 > 81.19.66.129.58995: P, cksum 0x13b8 (correct), 1:572(571) ack 88 win 33260 IP (tos 0x0, ttl 62, id 16634, offset 0, flags [DF], proto TCP (6), length 52) 81.19.71.6.8274 > 81.19.66.129.58995: F, cksum 0xe286 (correct), 572:572(0) ack 88 win 33260 IP (tos 0x0, ttl 64, id 6227, offset 0, flags [DF], proto TCP (6), length 52) 81.19.66.129.58995 > 81.19.71.6.8274: ., cksum 0x6371 (correct), ack 573 win 257 IP (tos 0x0, ttl 64, id 6228, offset 0, flags [DF], proto TCP (6), length 52) 81.19.66.129.58995 > 81.19.71.6.8274: F, cksum 0x636b (correct), 88:88(0) ack 573 win 260 IP (tos 0x0, ttl 62, id 16635, offset 0, flags [DF], proto TCP (6), length 52) 81.19.71.6.8274 > 81.19.66.129.58995: ., cksum 0xe282 (correct), ack 89 win 33260 First 5 packets in session almost same, but connction no stalled after 5th packet. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7: can't connect to Solaris
On 25.10.2007 20:59, Mike Silbersack wrote: On Thu, 25 Oct 2007, Anton Yuzhaninov wrote: As silby@ already pointed out to me, try changing TCP_MAX_WINSHIFT in src/sys/netinet/tcp.h to 4. With TCP_MAX_WINSHIFT 4 it works. I have a fix for this already in HEAD, I'll merge it to releng_7 tonight. But from other host with RELENG_7 tcp to Solaris work fine with unmodified kernel: Is there a firewall in one path, but not the other? Yes problem was in firewall, not Solaris/FreeBSD tcp stacks. On Solaris was used ipfilter 3.4.18, and after 3.4.18 was fixed several bugs, which can cause such problems. Probably this: 4.1.17 - Released 20 January 2007 fix tracking TCP window scaling in the state code Or some other. ipfilter rules (with keep state) permit tcp traffic from freebsd7 host, but really some packets was blocked. Thanks. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known)
The following reply was made to PR kern/93378; it has been noted by GNATS. From: Anton Yuzhaninov <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) Date: Sun, 09 Mar 2008 00:43:45 +0300 Probably it is interact between delayed ack and Nagle's algorithm. They shouldn't be used together: http://developers.slashdot.org/comments.pl?sid=174457&cid=14515105 So application which may be affected by this problem should disable Nagle's algorithm for via socket option TCP_NODELAY. As I can see current postfix uses setsockopt TCP_NODELAY so consider to upgrade postfix to 2.4.7 or 2.5.1 first. Postifx 2.2.8 is too old. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
re TSO: data corruption
When TSO enabled on my re NIC, data transferred via network corrupted. It easy to reproduce using scp: citrin:~>scp some_file.tar.bz2 some_host: .. Received disconnect from 10.10.10.100: 2: Corrupted MAC on input. lost connection And same when data transferred to any other host. re0: flags=8843 metric 0 mtu 1500 options=399b ether 00:1a:4d:2d:82:6e inet 10.10.10.101 netmask 0xfe00 broadcast 10.10.10.255 media: Ethernet autoselect (100baseTX ) status: active [EMAIL PROTECTED]:2:5:0: class=0x02 card=0xe0001458 chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet Known workaround: ifconfig re0 -tso May be TSO should be disabled by default? System is fresh: FreeBSD 8.0-CURRENT #7: Sat Mar 22 20:59:10 MSK 2008 amd64 -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Looking for a Wireless NIC with 802.11ac or 802.11n support
On 02/04/18 23:02, Victor Sudakov wrote: > I'm looking for an internal Wi-Fi NIC with support for > > 1. 802.11n or better 802.11ac > 2. HOSTAP mode > 3. 5 GHz band (better both 2GHz and 5GHz). Atheros AR9382: 1. supports 802.11a and 802.11n 2. works in hostap mode 3. works in 5 GHz band or in 2.4Ghz (one freq at a time). I used TP-LINK TL-WDN3800 (which based on this chip) and it worked under FreeBSD without problems. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: why rtsold ?
On 9/29/18 10:20 PM, Victor Sudakov wrote: > When running FreeBSD as an IPv6 host im SLAAC mode, is > "rtsold_enable=YES" really necessary? I did not enable rtsold and IPv6 > still works fine only with rtsold is needed to write DNS server address from RDNSS RA option to /etc/resolv.conf man rtsold /-R ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: question about fopen fd limit
On 12/22/16 10:57, 盛慧华 wrote:
and even in BSD 10 , it seems this short limit still there , but other OS as
debian , FILE strucnt's fileno is a int .
* Certain members of __sFILE are accessed directly via macros or
* inline functions. To preserve ABI compat, these members must not
* be disturbed. These members are marked below with (*).
*/
struct __sFILE {
short _file; /* (*) fileno, if Unix descriptor, else
-1 */
If _file will be changed to int it will break existing binaries on upgrade.
Other OSes are more liberal in breaking compatibility.
we found an unoffical patch easily change this fileno to unsigned , but we
are a very stready project, we can't afford the risk
to use an unoffical patch.
It is better change this field to int and rebuild all binaries (base
system and ports). But if you mix binaries from patched and unpatched
tree, system will be broken.
Other options are:
- use open instead fopen, write instead fwrite e.t.c. For big
applications it is a lot of work, but almost all scalable applications
don't use f* functions to work with files.
- find some library for file io with similar interface or write one.
- port musl libc to FreeBSD and link your application statically with
musl (not an option really, to much work).
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
fe80::1%lo0
Hello, Why FreeBSD adds fe80::1%lo0 to the loopback interface? I know, that in IPv6 each interface should have a link-local address, but ::1 can be considered as link-local: https://tools.ietf.org/html/rfc4291#section-2.5.3 I think fe80::1 is unnecessary can be removed. For all practical purposes ::1 should be enough. BTW Linux has only ::1 on the loopback interface. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: about that DFBSD performance test
On 03/08/17 10:03, Mateusz Guzik wrote: First and foremost there is general kernel scalability. Certain counters and most locks are purely managed with atomic operations. An atomic operation grabs the entire cacheline with the particular variable (64 bytes in total) in exclusive mode. Isn't problem of atomic counters was solved by counter(9) framework? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ifconfig description
Friday, November 25, 2005, 3:22:17 PM, bart wrote: b> I have couple of bsd routers with dozens vlans b> and missed ability to make comment on interface like cisco description You can use zebra (quagga) daemon for interface description: # sh int vlan17 Interface vlan17 is up, line protocol detection is disabled Description: -- Customer 8140, room 411 index 14 metric 1 mtu 1500 HWaddr: 00:90:27:af:77:f6 inet 192.168.14.1/24 broadcast 192.168.14.255 input packets 5718144, bytes 812660461, dropped 0, multicast packets 119814 input errors 0 output packets 7149073, bytes 2620267769, multicast packets 0 output errors 0 collisions 0 /usr/ports/net/zebra /usr/ports/net/quagga -- WBR, Anton v. Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Creating span port using netgraph
Saturday, January 28, 2006, 10:52:11 PM, Frank wrote: F> # create ngeth0 and bind xl0, xl1, xl2 and xl3 to it F> ngctl mkpeer . eiface hook ether F> ngctl mkpeer ngeth0: one2many lower one F> ngctl connect xl0: ngeth0:lower lower many0 F> ngctl connect xl1: ngeth0:lower lower many1 F> ngctl connect xl2: ngeth0:lower lower many2 F> ngctl connect xl3: ngeth0:lower lower many3 F> # bring up ngeth0 for sniffing duties F> ifconfig ngeth0 monitor up F> After I run this script, all network connections freeze and I lost all F> IP connectvity. If I tcpdup on any inteface (xl? or ngeth0) no traffic F> is visible. Use ng_tee for connect to xl0, xl1... -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CARP howto
Saturday, August 12, 2006, 8:30:00 PM, Mike Jakubik wrote: MJ> Does anyone know a good CARP howto for FreeBSD? I've googled around, but MJ> i cant find anything specific to FreeBSD. You can use CARP howto for OpenBSD. -- WBR, Anton Yuzhaninov
Re[2]: Avoiding natd overhead
Saturday, October 21, 2006, 1:58:08 PM, Matthew D. Fuller wrote: MDF> On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of MDF> Brett Glass, and lo! it spake thus: >> >> How can I replace just the functionality of natd without moving to >> an entirely new firewall? Can I still select which packets are >> routed to the NAT engine, and when this occurs during the processing >> of the packet? MDF> Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might MDF> fit here. It should move the NAT'ing into the kernel and save all the MDF> context switches and copies, and (what has me more interested) make it MDF> much easier to change port forwarding and other rules. The worst MDF> thing about natd for me isn't performance, it's that I have to blow MDF> away all the state to change anything. libalis still have big overhead comparing to ipnat: 1. libalias allocate memory for create each new entry in NAT table. libalias use linear search in linked list to find entry in table. It very slow when you have thousands simultaneous connections via nat 2. ipnat allocate all memory at startup. It better. ipnat uses hash table to fine entry in nat table - it mach faster in heavy loaded case. An next. As I can se libalias not limit maximum size of used memory. When users generate many simultaneous connections (e. g. worm or net scan), libalias may exhaust all kernel memory and so trigger panic. -- WBR, Anton Yuzhaninov
Re[2]: Avoiding natd overhead
Saturday, October 21, 2006, 6:42:15 PM, Eugene Grosbein wrote: >> 1. libalias allocate memory for create each new entry in NAT table. >>libalias use linear search in linked list to find entry in table. >>It very slow when you have thousands simultaneous connections via >>nat EG> In RELENG_4 libalias uses hash table, not linear search. EG> Are you sure it switched to linear search? And why? Yes, I was mistaken. libalis use lookup tables linkTableOut and linkTableIn -- WBR, Anton Yuzhaninov
rl nic don't work on Acer Aspire 3610
Hello. rl from Acer Aspire 3610 don't work under FreeBSD 6.2-BETA3 ifconfig show no carrier. Manual "media 100baseTX" don't help. $ grep rl0 dmesg.boot pcib1: rl0 requested I/O range 0x3000-0x30ff: in range pcib1: rl0 requested I/O range 0x3000-0x30ff: in range rl0: port 0x3000-0x30ff mem 0xb010-0xb01000ff irq 20 at device 7.0 on pci6 pcib1: rl0 requested I/O range 0x3000-0x30ff: in range miibus0: on rl0 rl0: bpf attached rl0: Ethernet address: 00:0a:e4:e4:8c:fa rl0: [MPSAFE] rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout rl0: watchdog timeout [EMAIL PROTECTED]:7:0: class=0x02 card=0x006a1025 chip=0x813910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class= network subclass = ethernet When system boot with acpi I see many errors like: acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS0._TMP] (Node 0xc43b6da0), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: Failed waiting for EC to send data. ACPI-0501: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed [\_TZ_.TZS0._TMP] (Node 0xc43b6da0), AE_NO_HARDWARE_RESPONSE acpi_tz0: error fetching current temperature -- AE_NO_HARDWARE_RESPONSE I try to boot without acpi, but it also don't work. How I can debug this problem? Under WinXP this network card work fine. dmesg output available here: http://citrin.ru/tmp/aspire3610/ -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
zero kern.ipc.nsfbufs on amd64
Hello All, Why on AMD64 kern.ipc.nsfbufs always zero: # sysctl kern.ipc | fgrep nsfbufs kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 # netstat -m | fgrep sfbufs 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed # uname -srim FreeBSD 6.0-RELEASE amd64 GENERIC Is this mean, that on amd64 nsfbufs have no limit? -- WBR, Anton Yuzhaninov.
Re: Automatic TCP send and receive socket buffer sizing
Wednesday, December 13, 2006, 1:30:26 AM, Andre Oppermann wrote: AO> The patch is available here (it may apply with some fuzz): AO> http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff AO> Any tests and test reports are very welcome. Please answer on question from Phil Rosenthal: PR> 1) I've seen in production that some sockets get large very PR> quickly during periods of high latency (eg: when sending to a user PR> downloading from a cablemodem and their headend gets temporarily PR> saturated and has large buffers, which raises the RTT under PR> saturation, which increases the bandwidth delay product), but then PR> as there isn't any code to shrink the buffers. This would probably PR> need to be in the timers to notice the case of the sender PR> temporarily stopping sending - eg in a keepalive http socket (a PR> separate, but related issue). -- WBR, Anton Yuzhaninov
is setsockopt SO_NOSIGPIPE work?
Hello.
Is SO_NOSIGPIPE work?
It try to set on socket option SO_NOSIGPIPE but anyway process
received sigpipe.
Test case:
#include
#include
#include
#include
#define SERVER_PORT 8000
void
sigpipe(int signo __unused)
{
printf("SIGPIPE recivied\n");
}
int
main(int argc, char *argv[])
{
int s , c;
int on = 1;
socklen_t slen, c_len;
struct sockaddr_in serv_addr, client_addr;
if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0)
err(1, "socket() failed");
bzero(&serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
serv_addr.sin_port = htons(SERVER_PORT);
if (bind(s, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0)
err(1, "bind() failed");
if (listen(s, -1) < 0)
err(1, "listen() failed");
(void)signal(SIGPIPE, sigpipe);
for (;;) {
if ((c = accept(s, (struct sockaddr *)&client_addr, &c_len)) < 0) {
warn("accept() failed");
continue;
}
if (setsockopt(c, SOL_SOCKET, SO_NOSIGPIPE, (void *)&on, sizeof(on)) <
0)
err(1, "setsockopt(SOL_SOCKET, SO_NOSIGPIPE) failed");
sleep(2);
if (write(c, "abc", strlen("abc")) < 0)
warn("first write() failed");
if (write(c, "\r\n", strlen("\r\n")) < 0)
warn("second write() failed");
close(c);
}
}
Client connect, than disconnect.
server print:
SIGPIPE recivied
a.out: second write() failed: Broken pipe
Is SO_NOSIGPIPE broken, or something wrong in my code?
system:
6.2-STABLE FreeBSD 6.2-STABLE #0: Mon Feb 19 17:07:12 MSK 2007
--
WBR,
Anton Yuzhaninov
Re[2]: is setsockopt SO_NOSIGPIPE work?
Thursday, March 1, 2007, 6:29:42 PM, Ruslan Ermilov wrote: RE> On Thu, Mar 01, 2007 at 03:17:29PM +0300, Anton Yuzhaninov wrote: >> Is SO_NOSIGPIPE work? >> >> It try to set on socket option SO_NOSIGPIPE but anyway process >> received sigpipe. >> RE> It works, but only if you use send() instead of write(). RE> Alternatively, you can control the behavior on a per RE> message basis, by passing the MSG_NOSIGNAL in the "flags" RE> argument to the send() call (without having to set a RE> socket option). Thanks, with send() it works fine. I think it should be documented in setsockopt(2). -- WBR, Anton Yuzhaninov
Re: [PATCH] Re: is setsockopt SO_NOSIGPIPE work?
Thursday, March 1, 2007, 8:34:50 PM, Bruce M. Simpson wrote:
BMS> Anton Yuzhaninov wrote:
>>
>> Thanks, with send() it works fine.
>> I think it should be documented in setsockopt(2).
BMS> Try this patch. The comment doesn't reflect what the code does. SIGPIPE
BMS> may actually be getting queued twice in your case. It is most likely
BMS> that the process's main thread wasn't preempted before return from the
BMS> syscall.
Works for me.
src/tools/regression/sockets/sigpipe
also pass now (without this patch it failed)
BMS> Perhaps someone more familiar with the signal code than I can chime in.
BMS> --- sys_generic.c 14 Oct 2006 19:01:55 - 1.151
BMS> +++ sys_generic.c 1 Mar 2007 17:30:39 -
BMS> @@ -489,7 +489,7 @@ dofilewrite(td, fd, fp, auio, offset, fl
BMS> error == EINTR || error == EWOULDBLOCK))
BMS> error = 0;
BMS> /* Socket layer is responsible for issuing SIGPIPE. */
BMS> - if (error == EPIPE) {
+ if (fp->>f_type != DTYPE_SOCKET && error == EPIPE) {
BMS> PROC_LOCK(td->td_proc);
BMS> psignal(td->td_proc, SIGPIPE);
BMS> PROC_UNLOCK(td->td_proc);
--
WBR,
Anton Yuzhaninov
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: kern/106722: [net] [patch] ifconfig may not connect an interface to known network
Wednesday, March 14, 2007, 7:00:13 PM, Bruce M. Simpson wrote: BMS> Gleb Smirnoff wrote: >> AFAIK, the problem needs a more generic approach. I see two approaches. >> >> 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, >> deleting all conflicting ones. Use this command in in_addprefix(). >> >> 2) In rt_flags field we still have several extra bits. We can use >> them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, >> where XXX is a routing protocol. When issuing RTM_ADD a route with >> a preferred source (e.g. CONNECTED vs STATIC) will override the old >> one. >> BMS> I understand that they are being proposed to address problems we BMS> currently have in the stack, i.e. that we do not support multipathing, BMS> though it is more than likely they will be blown away in future when the BMS> architecture changes (and it has to change). IMHO question is not related to multipathing. Kernel routes now don't contain administrative distance and it root of this problem. RTS_CONNECTED, RTS_STATIC is a hack adding some fixed AD values without increasing route size in memory. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: kern/106722: [net] [patch] ifconfig may not connect an interface to known network
Thursday, March 15, 2007, 7:30:54 PM, Andre Oppermann wrote: AO> IMO when configuring a interface with an IP address and network it should AO> kick out previous host and/or network routes matching it. Unless those AO> are from locally configured interfaces, then it should reject the new AO> attempt. New route should replace existing one only if it have administrative distance (in cisco terms) smaller than AD for existing route. Preference of network from locally configured interface is only particular case of this general principle. -- WBR, Anton Yuzhaninov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
