panic in soabort
Hi all. Please, give me comment on this. The panic is on 6.2-REL. Is it known to be fixed in the latter releases? Thanks. db> bt Tracing pid 14677 tid 101677 td 0xcf8e2640 _mtx_lock_sleep(ce7b9a30,cf8e2640,0,0,0) at _mtx_lock_sleep+0x9d soabort(ce7b99bc) at soabort+0x82 soclose(c83a2858) at soclose+0x21a soo_close(cf1c8750,cf8e2640) at soo_close+0x63 fdrop_locked(cf1c8750,cf8e2640,cb18d400,f1872cb4,c06607eb,...) at fdrop_locked+0xac fdrop(cf1c8750,cf8e2640,c991b5a0,cf8e2640,0,...) at fdrop+0x41 closef(cf1c8750,cf8e2640,0,cf8e2640,a,...) at closef+0x42f close(cf8e2640,f1872d04) at close+0x211 syscall(816003b,816003b,bfbf003b,8151034,811a434,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp = 0xbfbfe6dc, ebp = 0xbfbfe6f8 --- db> show msgbuf msgbufp = 0xc1042fe4 magic = 63062, size = 65508, r= 388996, w = 389463, ptr = 0xc1033000, cksum= 5411375 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc067a01d stack pointer = 0x28:0xf1872bbc frame pointer = 0x28:0xf1872bc8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 14677 (proftpd) db> show allpcpu Current CPU: 5 cpuid= 0 curthread= 0xc7cfec80: pid 18 "swi4: clock sio" curpcb = 0xe6892d90 fpcurthread = none idlethread = 0xc7cfeaf0: pid 17 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid= 1 curthread= 0xce9b1c80: pid 63915 "sc_trans_freebsd" curpcb = 0xf1263d90 fpcurthread = none idlethread = 0xc7cfe000: pid 16 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid= 2 curthread= 0xd1b944b0: pid 63619 "sc_serv" curpcb = 0xf2435d90 fpcurthread = none idlethread = 0xc7cfde10: pid 15 "idle: cpu2" APIC ID = 2 currentldt = 0x58 cpuid= 3 curthread= 0xd2340af0: pid 5086 "sc_serv" curpcb = 0xf2e08d90 fpcurthread = none idlethread = 0xc7cfdc80: pid 14 "idle: cpu3" APIC ID = 3 currentldt = 0x58 cpuid= 4 curthread= 0xca46b640: pid 14743 "httpd" curpcb = 0xeefbbd90 fpcurthread = none idlethread = 0xc7cfdaf0: pid 13 "idle: cpu4" APIC ID = 4 currentldt = 0x50 cpuid= 5 curthread= 0xcf8e2640: pid 14677 "proftpd" curpcb = 0xf1872d90 fpcurthread = none idlethread = 0xc7cfd960: pid 12 "idle: cpu5" APIC ID = 5 currentldt = 0x50 cpuid= 6 curthread= 0xc833a7d0: pid 10882 "httpd" curpcb = 0xf2651d90 fpcurthread = none idlethread = 0xc7cfd7d0: pid 11 "idle: cpu6" APIC ID = 6 currentldt = 0x50 cpuid= 7 curthread= 0xc7d02000: pid 20 "swi1: net" curpcb = 0xe6898d90 fpcurthread = none idlethread = 0xc7cfd640: pid 10 "idle: cpu7" APIC ID = 7 currentldt = 0x50 db> bt 63619 Tracing pid 63619 tid 103691 td 0xd24e8640 sched_switch(3528361536,0,2) at sched_switch+323 mi_switch(2,0) at mi_switch+442 critical_exit(3231785568,4070575232,3230238960,0,3227844616,...) at critical_exit+157 lapic_handle_timer(0) at lapic_handle_timer+201 Xtimerint(3231785568,3528361536,0,0,0) at Xtimerint+48 accept1(3528361536,4070575364,0,4070575408,3230324027,...) at accept1+254 accept(3528361536,4070575364) at accept+16 syscall(135659579,59,138870843,135738880,0,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (30, FreeBSD ELF32, accept), eip = 672261683, esp = 3215908652, ebp = 3215908696 --- db> bt 5086 Tracing pid 5086 tid 103669 td 0xc8494640 sched_switch(3360245312,0,1) at sched_switch+323 mi_switch(1,0,3435481780,4041956464,3228189038,...) at mi_switch+442 sleepq_switch(3435481780) at sleepq_switch+135 sleepq_timedwait_sig(3435481780) at sleepq_timedwait_sig+30 msleep(3435481780,3451159168,360,3230803656,3,...) at msleep+560 kse_release(3360245312,4041956612) at kse_release+567 syscall(135659579,59,138870843,135713536,0,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (383, FreeBSD ELF32, kse_release), eip = 671810103, esp = 138899336, ebp = 138899396 --- db> bt 10882 Tracing pid 10882 tid 102711 td 0xc833a7d0 sched_switch(3358828496,3352291680,6) at sched_switch+323 mi_switch(6,3352291680,3352292024,3231754688,4066712232,...) at mi_switch+442 maybe_preempt(3352291680) at maybe_preempt+196 sched_add(3352291680,4,3358828496,3352291680,4066712268,...) at sched_add+600 setrunqueue(3358828840,3499884544,3231754688,4066712304,3228131795,...) at setrunqueue+99 _end() at 3358828496 db> bt 20 Tracing pid 20 tid 100013 td 0xc7d02000 sched_switch(3352305664,3352291680,6) at sched_switch+323 mi_switch(6,3352291680,3352292024,3231754688,3867773608,...) at mi_switch+442 maybe_preempt(3352291680) at maybe_preempt+196 sched_add(3352
Re: panic in soabort
On Thu, 23 Apr 2009, pluknet wrote: Please, give me comment on this. The panic is on 6.2-REL. Is it known to be fixed in the latter releases? It may well be -- there have been quite significant architectural improvements to socket life cycle (etc) between 6.2 and 7.x releases, which may well close the race causing this panic. However, we'll probably need to learn a bit more in order to decide for sure. Could you convert the trapping instruction pointer to file+offset in the source code? Robert N M Watson Computer Laboratory University of Cambridge Thanks. db> bt Tracing pid 14677 tid 101677 td 0xcf8e2640 _mtx_lock_sleep(ce7b9a30,cf8e2640,0,0,0) at _mtx_lock_sleep+0x9d soabort(ce7b99bc) at soabort+0x82 soclose(c83a2858) at soclose+0x21a soo_close(cf1c8750,cf8e2640) at soo_close+0x63 fdrop_locked(cf1c8750,cf8e2640,cb18d400,f1872cb4,c06607eb,...) at fdrop_locked+0xac fdrop(cf1c8750,cf8e2640,c991b5a0,cf8e2640,0,...) at fdrop+0x41 closef(cf1c8750,cf8e2640,0,cf8e2640,a,...) at closef+0x42f close(cf8e2640,f1872d04) at close+0x211 syscall(816003b,816003b,bfbf003b,8151034,811a434,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x2832230f, esp = 0xbfbfe6dc, ebp = 0xbfbfe6f8 --- db> show msgbuf msgbufp = 0xc1042fe4 magic = 63062, size = 65508, r= 388996, w = 389463, ptr = 0xc1033000, cksum= 5411375 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer = 0x20:0xc067a01d stack pointer = 0x28:0xf1872bbc frame pointer = 0x28:0xf1872bc8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 14677 (proftpd) db> show allpcpu Current CPU: 5 cpuid= 0 curthread= 0xc7cfec80: pid 18 "swi4: clock sio" curpcb = 0xe6892d90 fpcurthread = none idlethread = 0xc7cfeaf0: pid 17 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid= 1 curthread= 0xce9b1c80: pid 63915 "sc_trans_freebsd" curpcb = 0xf1263d90 fpcurthread = none idlethread = 0xc7cfe000: pid 16 "idle: cpu1" APIC ID = 1 currentldt = 0x50 cpuid= 2 curthread= 0xd1b944b0: pid 63619 "sc_serv" curpcb = 0xf2435d90 fpcurthread = none idlethread = 0xc7cfde10: pid 15 "idle: cpu2" APIC ID = 2 currentldt = 0x58 cpuid= 3 curthread= 0xd2340af0: pid 5086 "sc_serv" curpcb = 0xf2e08d90 fpcurthread = none idlethread = 0xc7cfdc80: pid 14 "idle: cpu3" APIC ID = 3 currentldt = 0x58 cpuid= 4 curthread= 0xca46b640: pid 14743 "httpd" curpcb = 0xeefbbd90 fpcurthread = none idlethread = 0xc7cfdaf0: pid 13 "idle: cpu4" APIC ID = 4 currentldt = 0x50 cpuid= 5 curthread= 0xcf8e2640: pid 14677 "proftpd" curpcb = 0xf1872d90 fpcurthread = none idlethread = 0xc7cfd960: pid 12 "idle: cpu5" APIC ID = 5 currentldt = 0x50 cpuid= 6 curthread= 0xc833a7d0: pid 10882 "httpd" curpcb = 0xf2651d90 fpcurthread = none idlethread = 0xc7cfd7d0: pid 11 "idle: cpu6" APIC ID = 6 currentldt = 0x50 cpuid= 7 curthread= 0xc7d02000: pid 20 "swi1: net" curpcb = 0xe6898d90 fpcurthread = none idlethread = 0xc7cfd640: pid 10 "idle: cpu7" APIC ID = 7 currentldt = 0x50 db> bt 63619 Tracing pid 63619 tid 103691 td 0xd24e8640 sched_switch(3528361536,0,2) at sched_switch+323 mi_switch(2,0) at mi_switch+442 critical_exit(3231785568,4070575232,3230238960,0,3227844616,...) at critical_exit+157 lapic_handle_timer(0) at lapic_handle_timer+201 Xtimerint(3231785568,3528361536,0,0,0) at Xtimerint+48 accept1(3528361536,4070575364,0,4070575408,3230324027,...) at accept1+254 accept(3528361536,4070575364) at accept+16 syscall(135659579,59,138870843,135738880,0,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (30, FreeBSD ELF32, accept), eip = 672261683, esp = 3215908652, ebp = 3215908696 --- db> bt 5086 Tracing pid 5086 tid 103669 td 0xc8494640 sched_switch(3360245312,0,1) at sched_switch+323 mi_switch(1,0,3435481780,4041956464,3228189038,...) at mi_switch+442 sleepq_switch(3435481780) at sleepq_switch+135 sleepq_timedwait_sig(3435481780) at sleepq_timedwait_sig+30 msleep(3435481780,3451159168,360,3230803656,3,...) at msleep+560 kse_release(3360245312,4041956612) at kse_release+567 syscall(135659579,59,138870843,135713536,0,...) at syscall+703 Xint0x80_syscall() at Xint0x80_syscall+31 --- syscall (383, FreeBSD ELF32, kse_release), eip = 671810103, esp = 138899336, ebp = 138899396 --- db> bt 10882 Tracing pid 10882 tid 102711 td 0xc833a7d0 sched_switch(3358828496,3352291680,6) at sched_switch+323 mi_switch(6,3352291680,3352292024,3231754688,4066712232,...) at mi_switch+442 maybe_preempt(3352291680) at ma
Re: kern/131153: [iwi] iwi doesn't see a wireless network
The following reply was made to PR kern/131153; it has been noted by GNATS. From: Adam K Kirchhoff To: bug-follo...@freebsd.org, ad...@voicenet.com Cc: Subject: Re: kern/131153: [iwi] iwi doesn't see a wireless network Date: Thu, 23 Apr 2009 06:31:56 -0400 Can anyone at least confirm that the iwi and ath drivers work with 802.11n networks with WPA? ___ 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: Network Card
--- On Thu, 4/23/09, Peter Jeremy wrote: > From: Peter Jeremy > Subject: Re: Network Card > To: "Barney Cordoba" > Cc: "ovi freebsd" , freebsd-net@freebsd.org > Date: Thursday, April 23, 2009, 2:28 AM > On 2009-Apr-21 14:02:38 -0700, Barney Cordoba > wrote: > >On all of the MBs that I have, the slot NIC appears > before the onboard > >ports in the pciconf -l listing. Its certainly not for > sure. > > As a datapoint to add to the uncertainty, the SunFire V440 > has 4 > motherboard NICs - two come before the PCI slots and two > after (so > adding a PCI-based Cassini nic moves ce2 from the MB to the > plugin). > > Even slot numbering on larger boxes (with multiple physical > PCI buses) > can be non (or counter) intuitive. > > Also note that FreeBSD has also changed its PCI probe order > at least > once in the past (effectively re-numbering devices). > > -- > Peter Jeremy 4 port NICs generally have a bridge chip on it, so they always tend to muck things up. If the nics are PCI-X, you can probably add some trace to the em driver to see what the bus speed is. Onboard NICs are usually 33mhz or 66Mhz (I've never seen on onboard that runs 133Mhz)..however if the add-on card is 33mhz or PCI-E than you won't know. But if the em NIC is running at 133 than its almost definitely (hows that for certainty?) a plug in card. Who would buy a realtek plug in card anyway? Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
proxy arp on 8.0-current?
Hi, I'm trying to setup an proxy arp on a dual homed host. I noticed that I cannot set it up on 8.0-current the same way as I could on 6.2; hence the question: have the setup procedure changed recently (when the arp table was separated from the routing table, maybe?)? My 8.0-current is from 200902 snapshot. Here is a simple demonstration using two single-interfaced hosts: setup: host6.2# ifconfig em0 inet 192.168.0.1/24 host6.2# arp -s 192.168.0.11 auto pub host6.2# arp -an | grep permanent ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet] ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet] host6.2# tcpdump -np arp host8.0# ifconfig em0 inet 192.168.0.2/24 host8.0# arp -s 192.168.0.12 auto pub host8.0# arp -an | grep permanent ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet] ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet] host8.0# tcpdump -np arp then, I do: host6.2# arp -d 192.168.0.2; ping -c 1 192.168.0.2 host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12 host8.0# arp -d 192.168.0.1; ping -c 1 192.168.0.1 host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11 I am not caring about 'arp -d' errors (cannot locate) nor ping not responding (for proxied addresses). I just cared about arp requests and replys for now. The output of tcpdump on both sides are like this: arp who-has 192.168.0.2 tell 192.168.0.1 arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx arp who-has 192.168.0.12 tell 192.168.0.1 >no reply arp who-has 192.168.0.1 tell 192.168.0.2 arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx arp who-has 192.168.0.11 tell 192.168.0.2 arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx As you can see from the above, 'arp -s 192.168.0.12 auto pub' on 8.0-current host seems not to be producing proxy arp's. What am I missing? Thanks. -- Hiroharu Tamaru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPFW MAX RULES COUNT PERFORMANCE
Hi,
My system is a FreeBSD 7.1R.
When I add rules IPFW COUNT to 254 IPS from my network, one of my
interfaces increases the latency, causing large delays in the network,
when I delete COUNT rules, everything returns to normal, which can be ?
My script:
ipcount.php
-- CUT --
system("/sbin/ipfw -q add $a count { tcp or udp } from
any to $ip/32");
system("/sbin/ipfw -q add $a count { tcp or udp } from
$ip/32 to any");
#system("/sbin/ipfw delete $a");
$c++;
$a++;
}
}
echo "\n\nTotal: $c\n";
?>
-- CUT --
net.inet.ip.fw.dyn_keepalive: 1
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.static_count: 262
net.inet.ip.fw.dyn_max: 1
net.inet.ip.fw.dyn_count: 0
net.inet.ip.fw.curr_dyn_buckets: 256
net.inet.ip.fw.dyn_buckets: 1
net.inet.ip.fw.default_rule: 65535
net.inet.ip.fw.verbose_limit: 0
net.inet.ip.fw.verbose: 1
net.inet.ip.fw.debug: 0
net.inet.ip.fw.one_pass: 1
net.inet.ip.fw.autoinc_step: 100
net.inet.ip.fw.enable: 1
net.link.ether.ipfw: 1
net.link.bridge.ipfw: 0
net.link.bridge.ipfw_arp: 0
Thanks,
Daniel
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/133902: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault
The following reply was made to PR kern/133902; it has been noted by GNATS. From: Mikolaj Golub To: bug-follo...@freebsd.org Cc: freebsd-b...@freebsd.org, freebsd-net@FreeBSD.org, lsantagost...@gmail.com Subject: Re: kern/133902: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault Date: Thu, 23 Apr 2009 17:14:02 +0300 I have asked Leonardo to provide more info and backtrace. So here is backtrace: cobra4# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x65656c7b fault code = supervisor write, page not present instruction pointer = 0x20:0xc0786e00 stack pointer = 0x28:0xe958fac4 frame pointer = 0x28:0xe958fac4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 66873 (ssh) trap number = 12 panic: page fault cpuid = 1 Uptime: 54d11h21m54s Physical memory: 2023 MB Dumping 277 MB: 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe958fa84, eva=1701145723) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe958fa84, usermode=0, eva=1701145723) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe958fa84) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0786e00 in clear_selinfo_list (td=0xca3fc840) at /usr/src/sys/kern/sys_generic.c:1065 #8 0xc0788efc in kern_select (td=0xca3fc840, nd=8, fd_in=0x284010b8, fd_ou=0x284010bc, fd_ex=0x0, tvp=0x0) at /usr/src/sys/kern/sys_generic.c:794 #9 0xc07890de in select (td=0xca3fc840, uap=0xe958fcfc) at /usr/src/sys/kern/sys_generic.c:663 #10 0xc0a49635 in syscall (frame=0xe958fd38) at /usr/src/sys/i386/i386/trap.c:1035 #11 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #12 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) The system panics on ifconfig tun0 destroy This issue is related to kern/116837. Leonardo, you can try the patch attached to that pr. -- Mikolaj Golub ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/133902: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault
I have asked Leonardo to provide more info and backtrace. So here is backtrace: cobra4# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x65656c7b fault code = supervisor write, page not present instruction pointer = 0x20:0xc0786e00 stack pointer = 0x28:0xe958fac4 frame pointer = 0x28:0xe958fac4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 66873 (ssh) trap number = 12 panic: page fault cpuid = 1 Uptime: 54d11h21m54s Physical memory: 2023 MB Dumping 277 MB: 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe958fa84, eva=1701145723) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe958fa84, usermode=0, eva=1701145723) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe958fa84) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0786e00 in clear_selinfo_list (td=0xca3fc840) at /usr/src/sys/kern/sys_generic.c:1065 #8 0xc0788efc in kern_select (td=0xca3fc840, nd=8, fd_in=0x284010b8, fd_ou=0x284010bc, fd_ex=0x0, tvp=0x0) at /usr/src/sys/kern/sys_generic.c:794 #9 0xc07890de in select (td=0xca3fc840, uap=0xe958fcfc) at /usr/src/sys/kern/sys_generic.c:663 #10 0xc0a49635 in syscall (frame=0xe958fd38) at /usr/src/sys/i386/i386/trap.c:1035 #11 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #12 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) The system panics on ifconfig tun0 destroy This issue is related to kern/116837. Leonardo, you can try the patch attached to that pr. -- Mikolaj Golub ___ 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: IPFW MAX RULES COUNT PERFORMANCE
In response to Daniel Dias Gonçalves :
>
> My system is a FreeBSD 7.1R.
> When I add rules IPFW COUNT to 254 IPS from my network, one of my
> interfaces increases the latency, causing large delays in the network,
> when I delete COUNT rules, everything returns to normal, which can be ?
Not sure what you mean by the "which can be" part of the question.
But the answer, is "of course latency increases".
Did you expect that this kind of traffic tracking to be free? It's
not on any operating system or other networking device in existence.
It takes CPU cycles and memory to do the tracking, and flipping bits
in memory takes time. Therefore, your latency will increase when you
add 512 counters to your rules. It's the overhead associated with
such logging.
Of course, you don't mention _how_much_ latency increases. I can
only assume that it's to a degree that you find unacceptable. You
also don't mention what hardware you're doing this on, but I would
expect that on sufficiently beefy hardware the added latency is low
enough not to be a problem. However, without those details, I expect
that the following answer is the best you're going to get: If you
need to so such logging and the latency increase is unacceptable, then
get faster hardware to do it on or concoct some method to do it out
of band so that the latency doesn't slow down the connections.
> My script:
>
> ipcount.php
> -- CUT --
> $c=0;
> $a=50100;
> for($x=0;$x<=0;$x++) {
> for($y=1;$y<=254;$y++) {
> $ip = "192.168.$x.$y";
> system("/sbin/ipfw -q add $a count { tcp or udp } from
> any to $ip/32");
> system("/sbin/ipfw -q add $a count { tcp or udp } from
> $ip/32 to any");
> #system("/sbin/ipfw delete $a");
> $c++;
> $a++;
> }
> }
> echo "\n\nTotal: $c\n";
> ?>
> -- CUT --
>
> net.inet.ip.fw.dyn_keepalive: 1
> net.inet.ip.fw.dyn_short_lifetime: 5
> net.inet.ip.fw.dyn_udp_lifetime: 10
> net.inet.ip.fw.dyn_rst_lifetime: 1
> net.inet.ip.fw.dyn_fin_lifetime: 1
> net.inet.ip.fw.dyn_syn_lifetime: 20
> net.inet.ip.fw.dyn_ack_lifetime: 300
> net.inet.ip.fw.static_count: 262
> net.inet.ip.fw.dyn_max: 1
> net.inet.ip.fw.dyn_count: 0
> net.inet.ip.fw.curr_dyn_buckets: 256
> net.inet.ip.fw.dyn_buckets: 1
> net.inet.ip.fw.default_rule: 65535
> net.inet.ip.fw.verbose_limit: 0
> net.inet.ip.fw.verbose: 1
> net.inet.ip.fw.debug: 0
> net.inet.ip.fw.one_pass: 1
> net.inet.ip.fw.autoinc_step: 100
> net.inet.ip.fw.enable: 1
> net.link.ether.ipfw: 1
> net.link.bridge.ipfw: 0
> net.link.bridge.ipfw_arp: 0
>
> Thanks,
>
> Daniel
> ___
> 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"
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmo...@collaborativefusion.com
Phone: 412-422-3463x4023
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
___
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: IPFW MAX RULES COUNT PERFORMANCE
Daniel Dias Gonçalves wrote: Hi, My system is a FreeBSD 7.1R. When I add rules IPFW COUNT to 254 IPS from my network, one of my interfaces increases the latency, causing large delays in the network, when I delete COUNT rules, everything returns to normal, which can be ? My script: of course adding 512 rules, *all of which hav eto be evaluated* will add latency. you have several ways to improve this situation. 1/ use a differnet tool. By using the netgraph netflow module you can get accunting information that may be more useful and less impactful. 2/ you could make your rules smarter.. use skipto rules to make the average packet traverse less rules.. off the top of my head.. (not tested..) Assuming you have machines 10.0.0.1-10.0.0.254 the rules below have an average packet traversing 19 rules and not 256 for teh SYN packet and 2 rules for others.. you may not be able to do the keep state trick if you use state for other stuff but in that case worst case will still be 19 rules. 2 check-state 5 skipto 1 ip from not 10.0.0.0/24 to any 10 skipto 2020 ip from not 10.0.0.0/25 to any # 0-128 20 skipto 1030 ip from not 10.0.0.0/26 to any # 0-64 30 skipto 240 ip from not 10.0.0.0/27 to any # 0-32 40 skipto 100 ip from not 10.0.0.0/28 to any # 0-16 [16 count rules for 0-15] 80 skipto 1 ip from any to any 100 [16 count rules for 16-31] keep-state 140 skipto 1 ip from any to any 240 skipto 300 ip from not 10.0.0.32/28 [16 rules for 32-47] keep-state 280 skipto 1 ip from any to any 300 [16 count rules for 48-63] keep-state 340 skipto 1 ip from any to any 1030 skipto 1240 ip from not 10.0.0.64/27 to any 1040 skipto 1100 ip from not 10.0.0.64/28 to any [16 count rules for 64-79] keep-state 1080 skipto 1 ip from any to any 1100 [16 rules for 80-95] keep-state 1140 skipto 1 ip from any to any 1240 skipto 1300 ip from not 10.0.0.96/28 to any [16 count rules for 96-111] keep-state 1280 skipto 1 ip from any to any 1300 [16 rules for 112-127] keep-state 1340 skipto 1 ip from any to any 2020 skipto 3030 ip from not 10.0.0.128/26 to any 2030 skipto 2240 ip from not 10.0.0.128/28 to any [16 count rules for 128-143] keep-state 2080 skipto 1 ip from any to any 2100 [16 rules for 144-159] keep-state 2140 skipto 1 ip from any to any 2240 skipto 2300 ip from not 10.0.0.32/28 to any [16 count rules for 160-175] keep-state 2280 skipto 1 ip from any to any 2300 [16 count rules for 176-191] keep-state 2340 skipto 1 ip from any to any 3030 skipto 3240 ip from not 10.0.0.192/27 to any 3040 skipto 3100 ip from not 10.0.0.192/28 to any [16 count rules for 192-207] keep-state 3080 skipto 1 ip from any to any 3100 [16 rules for 208-223] keep-state 3240 skipto 1 ip from any to any 3240 skipto 3300 ip from not 10.0.0.224/28 to any [16 count rules for 224-239] keep-state 3280 skipto 1 ip from any to any 3300 [16 count rules for 240-255] keep-state 3340 skipto 1 ip from any to any 1 #other stuff in fact you could improve it further with: 1/ either going down to a netmask of 29 (8 rules per set) or 2/ instead of having count rules make them skipto so you would have: 3300 skipto 1 ip from 10.0.0.240 to any 3301 skipto 1 ip from 10.0.0.241 to any 3302 skipto 1 ip from 10.0.0.242 to any 3303 skipto 1 ip from 10.0.0.243 to any 3304 skipto 1 ip from 10.0.0.244 to any 3305 skipto 1 ip from 10.0.0.245 to any 3306 skipto 1 ip from 10.0.0.246 to any 3307 skipto 1 ip from 10.0.0.247 to any 3308 skipto 1 ip from 10.0.0.248 to any 3309 skipto 1 ip from 10.0.0.249 to any 3310 skipto 1 ip from 10.0.0.240 to any 3311 skipto 1 ip from 10.0.0.241 to any 3312 skipto 1 ip from 10.0.0.242 to any 3313 skipto 1 ip from 10.0.0.243 to any 3314 skipto 1 ip from 10.0.0.244 to any 3315 skipto 1 ip from 10.0.0.245 to any thus on average, a packet would traverse half the rules (8). 3/ both the above so on average they would traverse 4 rules plus one extra skipto. you should be able to do the above in a script. I'd love to see it.. (you can also do skipto tablearg in -current (maybe 7.2 too) which may also be good.. (or not)) julian ___ 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: Interrupts + Polling mode (similar to Linux's NAPI)
On Fri, Mar 27, 2009 at 11:05:00AM +, Andrew Brampton wrote: > 2009/3/27 Luigi Rizzo : > > The load of polling is pretty low (within 1% or so) even with > > polling. The advantage of having interrupts is faster response > > to incoming traffic, not CPU load. > > oh, I was under the impression that polling spun in a tight loop, thus > using 100% of the processor. After a quick test I see this is not the > case. I assume it will get to 100% CPU load if I saturate my network. Yes, polling has a limit on the maximum CPU time it will use, and also will use less than the limit if there is no traffic. There are a number of sysctls under kern.polling that control its behaviour: * kern.polling.user_frac: Desired user fraction of cpu time This attempts to reserve at least a specified percentage of available CPU time for user processes; polling tries to limit its percentage use to 100 less this value. * kern.polling.burst: Current polling burst size * kern.polling.burst_max: Max Polling burst size * kern.polling.each_burst: Max size of each burst These three control the number of packets that polling processes per call / tick. Packets are processed in batches of each_burst, up to burst packets total per tick. The value of burst is capped at busrt_max. In order to keep the user_frac CPU percentage available for non-polling, a feedback loop is used that controls the value of burst. Each time a bach of packets is processed, burst is incremented or decremented by 1, depending on how much CPU time polling actually used. In addition, if polling extends beyond the next tick it's scaled back to 7/8ths of the current value. Polling was originally implemented as a livelock-avoidance technique for the single-core case -- the primary goal is to guarantee the availability of CPU time specified in user_frac. The current algorithm does not behave that well if user_frac is set low. Setting it low is reasonable if the workload is largely in-kernel (i.e., bridging or routing), or when running SMP. Another downside of the current implementation is that interfaces will be polled multiple times per tick (burst / each_burst times), even if there are no packets to process. At work we've developed a replacement polling algorithm that keeps track of the actual amount of time spent per packet, and uses that as the feedback to control the number of packets in each batch. This work requires a change to the polling KPI: the polling handlers have to return the count of packets actually handled. My hope is to get the KPI change committed in time for 8.0, even if we don't switch the algorithm yet. Attilio (on CC:) and I will make the patch set for the KPI change available shortly for comment. -Ed ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132734: panic in net/if_mib.c
The following reply was made to PR kern/132734; it has been noted by GNATS.
From: Mikolaj Golub
To: Alexey Illarionov
Cc: bug-follo...@freebsd.org, Robert Watson
Subject: Re: kern/132734: panic in net/if_mib.c
Date: Thu, 23 Apr 2009 22:29:36 +0300
SVN rev 191435 on 2009-04-23 18:23:08Z by rwatson
Merge r191434 from stable/7 to releng/7.2:
In sysctl_ifdata(), query the ifnet pointer using the index only
once, rather than querying it, validating it, and then re-querying
it without validating it. This may avoid a NULL pointer
dereference and resulting kernel page fault if an interface is
being deleted while bsnmp or other tools are querying data on the
interface.
The full fix, to properly refcount the interface for the duration
of the sysctl, is in 8.x, but is considered too high-risk for
7.2, so instead will appear in 7.3 (if all goes well).
So, Alexey, can you try upgrading to the latest stable/7 or releng/7.2 or
apply attached patch to see if this tweak at least eliminates the instant
panic?
--- if_mib.c (revision 191424)
+++ if_mib.c (working copy)
@@ -82,11 +82,9 @@
return EINVAL;
if (name[0] <= 0 || name[0] > if_index ||
- ifnet_byindex(name[0]) == NULL)
+ (ifp = ifnet_byindex(name[0])) == NULL)
return ENOENT;
- ifp = ifnet_byindex(name[0]);
-
switch(name[1]) {
default:
return ENOENT;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/132734: panic in net/if_mib.c
The following reply was made to PR kern/132734; it has been noted by GNATS. From: Robert Watson To: Mikolaj Golub Cc: Alexey Illarionov , bug-follo...@freebsd.org Subject: Re: kern/132734: panic in net/if_mib.c Date: Thu, 23 Apr 2009 20:33:43 +0100 (BST) On Thu, 23 Apr 2009, Mikolaj Golub wrote: > SVN rev 191435 on 2009-04-23 18:23:08Z by rwatson > > Merge r191434 from stable/7 to releng/7.2: > > In sysctl_ifdata(), query the ifnet pointer using the index only > once, rather than querying it, validating it, and then re-querying > it without validating it. This may avoid a NULL pointer > dereference and resulting kernel page fault if an interface is > being deleted while bsnmp or other tools are querying data on the > interface. > > The full fix, to properly refcount the interface for the duration > of the sysctl, is in 8.x, but is considered too high-risk for > 7.2, so instead will appear in 7.3 (if all goes well). > > So, Alexey, can you try upgrading to the latest stable/7 or releng/7.2 or > apply attached patch to see if this tweak at least eliminates the instant > panic? I'll try to get the refcount fix into 7-STABLE in about two weeks, assuming no hitches in the 8.x version. This will close a number of related race conditions, which we've had occasional reports of (and others that we haven't). Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Interrupts + Polling mode (similar to Linux's NAPI)
2009/4/23 Ed Maste : > On Fri, Mar 27, 2009 at 11:05:00AM +, Andrew Brampton wrote: > >> 2009/3/27 Luigi Rizzo : >> > The load of polling is pretty low (within 1% or so) even with >> > polling. The advantage of having interrupts is faster response >> > to incoming traffic, not CPU load. >> >> oh, I was under the impression that polling spun in a tight loop, thus >> using 100% of the processor. After a quick test I see this is not the >> case. I assume it will get to 100% CPU load if I saturate my network. > > Yes, polling has a limit on the maximum CPU time it will use, and also > will use less than the limit if there is no traffic. > > There are a number of sysctls under kern.polling that control its > behaviour: > > * kern.polling.user_frac: Desired user fraction of cpu time > > This attempts to reserve at least a specified percentage of available > CPU time for user processes; polling tries to limit its percentage use > to 100 less this value. > > * kern.polling.burst: Current polling burst size > * kern.polling.burst_max: Max Polling burst size > * kern.polling.each_burst: Max size of each burst > > These three control the number of packets that polling processes per > call / tick. Packets are processed in batches of each_burst, up to > burst packets total per tick. The value of burst is capped at > busrt_max. > > In order to keep the user_frac CPU percentage available for non-polling, > a feedback loop is used that controls the value of burst. Each time a > bach of packets is processed, burst is incremented or decremented by 1, > depending on how much CPU time polling actually used. In addition, if > polling extends beyond the next tick it's scaled back to 7/8ths of the > current value. > > Polling was originally implemented as a livelock-avoidance technique > for the single-core case -- the primary goal is to guarantee the > availability of CPU time specified in user_frac. The current algorithm > does not behave that well if user_frac is set low. Setting it low is > reasonable if the workload is largely in-kernel (i.e., bridging or > routing), or when running SMP. > > Another downside of the current implementation is that interfaces will > be polled multiple times per tick (burst / each_burst times), even if > there are no packets to process. > > At work we've developed a replacement polling algorithm that keeps track > of the actual amount of time spent per packet, and uses that as the > feedback to control the number of packets in each batch. > > This work requires a change to the polling KPI: the polling handlers > have to return the count of packets actually handled. My hope is to get > the KPI change committed in time for 8.0, even if we don't switch the > algorithm yet. Attilio (on CC:) and I will make the patch set for the > KPI change available shortly for comment. This is the KPI breakage patch: http://people.freebsd.org/~attilio/Sandvine/polling/polling_kpi.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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 as a module; followup thoughts
On 2009.04.21 23:16:58 -0600, Will Andrews wrote: > Hello, > > I've written a patch (against 8.0-CURRENT as of r191369) which makes > it possible to build, load, run, & unload CARP as a module, using the > GENERIC kernel. It can be obtained from: > > http://firepipe.net/patches/carp-as-module-20090421.diff I don't have any comments on the specific patch, but with my FreeBSD end-user hat, being able to have CARP in GENERIC would be really great. This would allow me to update my systems which use CARP with freebsd-update without manually compiling a kernel. So if the patch doesn't penalize the non-CARP case much, I think it would be great to have this functionality for now, even if it's not the way to go in the long run. -- Simon L. Nielsen ___ 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"
Hi John
Hi John, Just wanted you to know that yesterday I joined Socialmoto. Actually I keep on travelling and thus like making friends from different places so that i can know more about places and I can feel comfortable on unknown places because of known friends, but it gonna be with some gud people, my friend she gave me your email id .John you gottaa join me now and come online , I am online during office hours,and i have lots of spare time nowadays, kidding hehe :) . To join simply come here. [1]http://www.socialmoto.com/signup.php?inviteby=geetikai When you come here ping me, i will be online if by any sence i am not there. Thanks, Geetikai. -- I have attached my details . My profile: [2]http://www.socialmoto.com/geetikai My album: [3]http://www.socialmoto.com/album.php?user=geetikai&album_id=2889 My group: [4]http://www.socialmoto.com/group.php?group_id=829 References Visible links 1. http://www.socialmoto.com/signup.php?inviteby=geetikai 2. http://www.socialmoto.com/geetikai 3. http://www.socialmoto.com/album.php?user=geetikai&album_id=2889 4. http://www.socialmoto.com/group.php?group_id=829 Hidden links: 5. http://www.socialmoto.com/sowmyas 6. http://www.socialmoto.com/group.php?group_id=520 ___ 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"
IPv6 Ideas
I started playing with IPv6 on my home network with the intent to transition over. While many things work quite well, IPv6 technology in general still seems to have some rough edges. In terms of FreeBSD support, rtadvd and rtsol do not yet support (easily? -O option in rtadvd/rtsold) RFC5006 (Router Advertisements Option for DNS Configuration) which make it inconvenient to use mobile devices (like laptops) on an IPv6 network. I haven't had much luck with net/radvd. Is this something that could be improved? I'd be willing to implement this support, but I have very little time to spare (writing thesis). To be backward compatible with IPv4, I had a look at faith and faithd and while these tools are ingenius, I don't think they are good enough for transitioning to IPv6. I imagine it is possible to write an IPv6->IPv4 NAT daemon that uses faith to capture and restructure IPv6/IPv4 packets. Though, it really seems like this is the firewall's job A pf rule like: nat on $inet4_if inet to any from $lan_if:network6 -> ($inet4_if) would be extremely convenient. I'm aware pf doesn't support the token :network6 ... its just a wishful example. The IPv6 mapped IPv4 addresses would be the standard :::0:0/96 prefix. I imagine that this is very difficult to implement but I don't see why it wouldn't be possible. If a firewall supported this kind of NAT, a home network could easily deploy IPv6 and be backward compatible. Well, not quite, I guess BIND would have to serve IPv6 mapped IPv4 addresses to IPv6 queries. Oh yeah, one annoyance on 7-STABLE, it seems like pf is started before IPv6 rc.conf options are processed (including IPv6 address assignment) breaking inet6 rules that involve $if:network. Comments? Other than that, this has been one hell of a fun experience. Best Regards, Nathan Lay ___ 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: panic in soabort
2009/4/23 Robert Watson : > On Thu, 23 Apr 2009, pluknet wrote: > >> Please, give me comment on this. The panic is on 6.2-REL. Is it known to >> be fixed in the latter releases? > > It may well be -- there have been quite significant architectural > improvements to socket life cycle (etc) between 6.2 and 7.x releases, which > may well close the race causing this panic. However, we'll probably need to > learn a bit more in order to decide for sure. Could you convert the > trapping instruction pointer to file+offset in the source code? Looks I've lost the corresponding kernel.debug. Anyway I have such bt the first time. -- wbr, pluknet ___ 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"
