Re: Vimage Jail kernel crashed
On Sat, May 04, 2013 at 02:52:23PM +0900, KIRIYAMA Kazuhiko wrote: > May 4 11:19:46 xx kernel: Fatal trap 12: page fault while in kernel mode > May 4 11:19:46 xx kernel: cpuid = 2; apic id = 02 > May 4 11:19:46 xx kernel: fault virtual address = 0x7818c3798 > May 4 11:19:46 xx kernel: fault code = supervisor write > data, page not present > May 4 11:19:46 xx kernel: instruction pointer= > 0x20:0x8162c19e > May 4 11:19:46 xx kernel: stack pointer = > 0x28:0xff8121b22860 > May 4 11:19:46 xx kernel: frame pointer = > 0x28:0xff8121b22870 > May 4 11:19:46 xx kernel: code segment = base 0x0, limit > 0xf, type 0x1b > May 4 11:19:46 xx kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > May 4 11:19:46 xx kernel: processor eflags = interrupt enabled, > resume, IOPL = 0 > May 4 11:19:46 xx kernel: current process= 15360 > (ifconfig) > May 4 11:19:46 xx kernel: trap number= 12 > May 4 11:19:46 xx kernel: panic: page fault > May 4 11:19:46 xx kernel: cpuid = 2 > May 4 11:19:46 xx kernel: KDB: stack backtrace: > May 4 11:19:46 xx kernel: #0 0x80923446 at kdb_backtrace+0x66 > May 4 11:19:46 xx kernel: #1 0x808ed0be at panic+0x1ce > May 4 11:19:46 xx kernel: #2 0x80c7e330 at trap_fatal+0x290 > May 4 11:19:46 xx kernel: #3 0x80c7e668 at trap_pfault+0x1e8 > May 4 11:19:46 xx kernel: #4 0x80c7ec6e at trap+0x3be > May 4 11:19:46 xx kernel: #5 0x80c682ef at calltrap+0x8 > May 4 11:19:46 xx kernel: #6 0x8162c76d at > pfi_change_group_event+0x4d > May 4 11:19:46 xx kernel: #7 0x809a0d3b at if_delgroup+0x38b > May 4 11:19:46 xx kernel: #8 0x809a7846 at > if_clone_destroyif+0x136 > May 4 11:19:46 xx kernel: #9 0x809a831a at if_clone_destroy+0x17a > May 4 11:19:46 xx kernel: #10 0x809a5892 at ifioctl+0x482 > May 4 11:19:46 xx kernel: #11 0x80934ef6 at kern_ioctl+0x106 > May 4 11:19:46 xx kernel: #12 0x8093513d at sys_ioctl+0xfd > May 4 11:19:46 xx kernel: #13 0x80c7dc10 at amd64_syscall+0x540 > May 4 11:19:46 xx kernel: #14 0x80c685d7 at Xfast_syscall+0xf7 It looks like it crashed when referring vnet that had already been destroyed, in pfi_change_group_event hook. > Is there any suggestions? VIMAGE+pf support is fragile. If it works for someone it is rather by accident. I expect replacing pf with ipfw_nat or natd will give better results. If you still prefer pf, you may try destroying epair interface before destroying vnet, e.g. using prestop rc.d/jail hooks instead of poststop, if it is possible. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Vimage Jail kernel crashed
Hi, At Sat, 4 May 2013 15:07:11 +0300, Mikolaj Golub wrote: > > On Sat, May 04, 2013 at 02:52:23PM +0900, KIRIYAMA Kazuhiko wrote: > > > May 4 11:19:46 xx kernel: Fatal trap 12: page fault while in kernel > > mode > > May 4 11:19:46 xx kernel: cpuid = 2; apic id = 02 > > May 4 11:19:46 xx kernel: fault virtual address= 0x7818c3798 > > May 4 11:19:46 xx kernel: fault code = supervisor write > > data, page not present > > May 4 11:19:46 xx kernel: instruction pointer = > > 0x20:0x8162c19e > > May 4 11:19:46 xx kernel: stack pointer= > > 0x28:0xff8121b22860 > > May 4 11:19:46 xx kernel: frame pointer= > > 0x28:0xff8121b22870 > > May 4 11:19:46 xx kernel: code segment = base 0x0, limit > > 0xf, type 0x1b > > May 4 11:19:46 xx kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 > > May 4 11:19:46 xx kernel: processor eflags = interrupt enabled, > > resume, IOPL = 0 > > May 4 11:19:46 xx kernel: current process = 15360 > > (ifconfig) > > May 4 11:19:46 xx kernel: trap number = 12 > > May 4 11:19:46 xx kernel: panic: page fault > > May 4 11:19:46 xx kernel: cpuid = 2 > > May 4 11:19:46 xx kernel: KDB: stack backtrace: > > May 4 11:19:46 xx kernel: #0 0x80923446 at kdb_backtrace+0x66 > > May 4 11:19:46 xx kernel: #1 0x808ed0be at panic+0x1ce > > May 4 11:19:46 xx kernel: #2 0x80c7e330 at trap_fatal+0x290 > > May 4 11:19:46 xx kernel: #3 0x80c7e668 at trap_pfault+0x1e8 > > May 4 11:19:46 xx kernel: #4 0x80c7ec6e at trap+0x3be > > May 4 11:19:46 xx kernel: #5 0x80c682ef at calltrap+0x8 > > May 4 11:19:46 xx kernel: #6 0x8162c76d at > > pfi_change_group_event+0x4d > > May 4 11:19:46 xx kernel: #7 0x809a0d3b at if_delgroup+0x38b > > May 4 11:19:46 xx kernel: #8 0x809a7846 at > > if_clone_destroyif+0x136 > > May 4 11:19:46 xx kernel: #9 0x809a831a at > > if_clone_destroy+0x17a > > May 4 11:19:46 xx kernel: #10 0x809a5892 at ifioctl+0x482 > > May 4 11:19:46 xx kernel: #11 0x80934ef6 at kern_ioctl+0x106 > > May 4 11:19:46 xx kernel: #12 0x8093513d at sys_ioctl+0xfd > > May 4 11:19:46 xx kernel: #13 0x80c7dc10 at amd64_syscall+0x540 > > May 4 11:19:46 xx kernel: #14 0x80c685d7 at Xfast_syscall+0xf7 > > It looks like it crashed when referring vnet that had already been > destroyed, in pfi_change_group_event hook. > > > Is there any suggestions? > > VIMAGE+pf support is fragile. If it works for someone it is rather by > accident. I expect replacing pf with ipfw_nat or natd will give better > results. I've been used natd before using VIMAGE Jail private network. And I tried to use with ipfw+natd like this: /etc/rc.conf: defaultrouter="X.X.X.X" hostname="hoge.org" ifconfig_em0="inet X.X.X.X netmask 255.255.255.240" cloned_interfaces="bridge0" ifconfig_bridge0="inet 192.168.1.254 netmask 255.255.255.0 up" jail_v2_enable="YES" ezjail_enable="YES" gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="em0" natd_flags="-config /etc/natd.cf" keymap="jp.106" sshd_enable="YES" ntpd_enable="YES" sendmail_enable="NONE" dumpdev="NO" /etc/natd.cf: log no deny_incoming yes use_sockets no same_ports yes verbose no port8668 interface em0 unregistered_only yes redirect_port tcp 192.168.1.1:domain domain redirect_port udp 192.168.1.1:domain domain redirect_port tcp 192.168.1.3:cvspserver cvspserver redirect_port udp 192.168.1.4:cvspserver cvspserver redirect_port tcp 192.168.1.4:smtpsmtp redirect_port tcp 192.168.1.4:pop3pop3 redirect_port tcp 192.168.1.5:httphttp redirect_port tcp 192.168.1.254:ABCDE ABCDE redirect_port tcp 192.168.1.1:ssh ABBCA redirect_port tcp 192.168.1.2:ssh ABBCB redirect_port tcp 192.168.1.3:ssh ABBCC redirect_port tcp 192.168.1.4:ssh ABBCD redirect_port tcp 192.168.1.5:ssh ABBCE /boot/loader.conf: ipdivert_load="YES" ipfw_load="YES" But all packet redirection were neglected except 192.168.1.254 namely firewall itself ;) > If you still prefer pf, you may try destroying epair interface before > destroying vnet, e.g. using prestop rc.d/jail hooks instead of > poststop, if it is possible. In particular, execute following sequence? # ifconfig epairXa destroy # ifconfig bridge0 deletem epairXa > -- > Mikolaj Golub > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-u
Re: Vimage Jail kernel crashed
On Sat, May 04, 2013 at 10:41:46PM +0900, KIRIYAMA Kazuhiko wrote: > > If you still prefer pf, you may try destroying epair interface before > > destroying vnet, e.g. using prestop rc.d/jail hooks instead of > > poststop, if it is possible. > > In particular, execute following sequence? > > # ifconfig epairXa destroy > # ifconfig bridge0 deletem epairXa Yes, but in the revers order, delete from the bridge first. It is about lines like these in your configuration: export jail_web_exec_poststop0="ifconfig bridge0 deletem epair4a" export jail_web_exec_poststop1="ifconfig epair4a destroy" The crash happened when executing ifconfig epair destroy. You might want to try running commands manually before using the rc script. -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Possible DoS in mpd 5.6 pppoe server
Em 21/04/13 10:59, Eugene Grosbein escreveu: On 21.04.2013 06:08, Marcelo Gondim wrote: Em 20/04/13 14:33, Eugene Grosbein escreveu: On 21.04.2013 00:26, Marcelo Gondim wrote: You seem to use dummynet and the problem is not in mpd/pppoe code, it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 for workarounds. Ok :) I will try this: - net.isr.bindthreads=1 in /boot/loader.conf; - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf For 9.x and newer, net.isr.XXX knobs names have changed but defaults are fine - if you have not messed them, you should be OK. Eugene, Does FreeBSD 8.3-STABLEis best for this use or this problem also occurs in 8.x? I have not tried anything newer than 8.x for this task yet. With noted tuning, this problem within dummynet occurs very seldom for me. I had about two or three panics for many months. Another one described here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171711 Perhaps, using ng_car would be even more stable, I have not tried it. Eugene Grosbein Hi all, I changed hardware for motherboard Supermicro X9SCM-F and Xeon processor 3.2Ghz E31230 with 8Gb ram ECC. The problem stopped and the server was very stable. The problem could be with the Intel motherboard S5500BC? Because this was installed with 2 Xeon processors and two memory banks 4Gb. Could be FreeBSD incompatibility with the hardware or faulty hardware? Thanks and best regards, Gondim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
