9/RC2: start jails (with epair): ifconfig :permission denied
hi, I created and started a V2 jail by hand and it works. Now it should start automatically: From a HowTo: # # Jails configuration # jail_enable="YES" jail_v2_enable="YES" jail_list="web" jail_web_name="web" jail_web_hostname="web.domain.foo" jail_web_devfs_enable="YES" jail_web_devfs_ruleset="devfsrules_jail" jail_web_rootdir="/jails/www" jail_web_vnet_enable="YES" jail_web_exec_prestart0="ifconfig epair0 create" jail_web_exec_prestart1="ifconfig bridge0 addm epair0a" jail_web_exec_prestart2="ifconfig epair0a up" jail_web_exec_earlypoststart0="ifconfig epair0b vnet web" jail_web_exec_afterstart0="ifconfig lo0 127.0.0.1" jail_web_exec_afterstart1="ifconfig epair0b 192.168.1.3 netmask 255.255.255.0 up" jail_web_exec_afterstart2="route add default 130.83.160.62" jail_web_exec_afterstart3="/bin/sh /etc/rc" jail_web_exec_poststop0="ifconfig bridge0 deletem epair0a" jail_web_exec_poststop1="ifconfig epair0a destroy" But: /etc/rc.d/jail start web Configuring jails:. Starting jails:epair0a ifconfig: up: permission denied route: writing to routing socket: Operation not permitted /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Creating and/or trimming log files. Starting syslogd. syslogd: child pid 6510 exited with return code 1 /etc/rc: WARNING: failed to start syslogd ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib Clearing /tmp. Updating motd:. Starting sshd. 554 5.3.0 host "localhost" unknown: Protocol not supported Starting cron. Mon Nov 28 09:24:30 UTC 2011 web.domain.foo. so, I'm sure, that I have something missed. The Jail can't use ifconfig. So maybe, I have to edit: /etc/defaults/devfs.rules ? cu denny ___ 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: Low nfs write throughput
Daryl Sayers writes: > Can anyone suggest why I am getting poor write performance from my nfs setup. > I have 2 x FreeBSD 8.2-STABLE i386 machines with ASUS P5B-plus mother boards, > 4G mem and Dual core 3g processor using 147G 15k Seagate SAS drives with > onboard Gb network cards connected to an idle network. The results below show > that I get nearly 100Mb/s with a dd over rsh but only 15Mbs using nfs. It > improves if I use async but a smbfs mount still beats it. I am using the same > file, source and destinations for all tests. I have tried alternate Network > cards with no resulting benefit. [...] > Looking at a systat -v on the destination I see that the nfs test does not > exceed 16KB/t with 100% busy where the other tests reach up to 128KB/t. > For the record I get reads of 22Mb/s without and 77Mb/s with async turned on > for the nfs mount. On an UFS filesystem you get NFS writes with the same size as the filesystem blocksize. So an easy way to improve performance is to create a filesystem with larger blocks. I accidentally found this out when I had two NFS exported filesystems from the same box with 16K and 64K blocksizes respectively. (Larger blocksize also tremendously improves the performance of UFS snapshots!) Bengt ___ 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"
[releng_9 tinderbox] failure on mips/mips
TB --- 2011-11-28 19:31:08 - tinderbox 2.8 running on freebsd-stable.sentex.ca TB --- 2011-11-28 19:31:08 - starting RELENG_9 tinderbox run for mips/mips TB --- 2011-11-28 19:31:08 - cleaning the object tree TB --- 2011-11-28 19:31:28 - cvsupping the source tree TB --- 2011-11-28 19:31:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/mips/mips/supfile TB --- 2011-11-28 19:37:48 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2011-11-28 19:37:48 - ERROR: unable to cvsup the source tree TB --- 2011-11-28 19:37:48 - 2.37 user 3.73 system 399.80 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full ___ 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"
Sporadic 9.0-RC2 boot-time panic
*Sometimes* when booting 9.0-RC2 on *some* of my machines, I'll get one of the following two panics during multiuser startup, usually while running the /usr/local/etc/rc.d scripts. (The instruction pointer is always exactly one of these two, and they look fairly related.) If after two or three reboots it manages to not panic, the system will run perfectly stable. For some probably-unrelated reason, the dump never finishes in either case. First panic (note em0 warning before it): - em0: discard frame w/o packet header Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x805e4fc5 stack pointer = 0x28:0xff80003299e0 frame pointer = 0x28:0xff8000329a00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x805e4fc5, rsp = 0xff80003299e0, rbp = 0xff8000329a00 --- m_freem() at m_freem+0x25 ether_nh_input() at ether_nh_input+0x82 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 49s Dumping 679 out of 12263 MB: - Second panic (no em0 discard warning this time): - Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8063c0e4 stack pointer = 0x28:0xff8000329a00 frame pointer = 0x28:0xff8000329a40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8063c0e4, rsp = 0xff8000329a00, rbp = 0xff8000329a40 --- ether_nh_input() at ether_nh_input+0x94 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 46s Dumping 657 out of 12263 MB:..3% ___ 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: 9.0-RC2 re(4) "no memory for jumbo buffers" issue
On 11/27/11 8:39 PM, YongHyeon PYUN wrote: On Sat, Nov 26, 2011 at 04:05:58PM -0500, Mike Andrews wrote: I have a Supermicro 5015A-H (Intel Atom 330) server with two Realtek RTL8111C-GR gigabit NICs on it. As far as I can tell, these support jumbo frames up to 7422 bytes. When running them at an MTU of 5000 on Actually the maximum size is 6KB for RTL8111C, not 7422. RTL8111C and newer PCIe based gigabit controllers no longer support scattering a jumbo frame into multiple RX buffers so a single RX buffer has to receive an entire jumbo frame. This adds more burden to system because it has to allocate a jumbo frame even when it receives a pure TCP ACK. OK, that makes sense. FreeBSD 9.0-RC2, after a week or so of update, with fairly light network activity, the interfaces die with "no memory for jumbo buffers" errors on the console. Unloading and reloading the driver (via serial console) doesn't help; only rebooting seems to clear it up. The jumbo code path is the same as normal MTU sized one so I think possibility of leaking mbufs in driver is very low. And the message "no memory for jumbo RX buffers" can only happen either when you up the interface again or interface restart triggered by watchdog timeout handler. I don't think you're seeing watchdog timeouts though. I'm fairly certain the interface isn't changing state when this happens -- it just kinda spontaneously happens after a week or two, with no interface up/down transitions. I don't see any watchdog messages when this happens. When you see "no memory for jumbo RX buffers" message, did you check available mbuf pool? Not yet, that's why I asked for debugging tips -- I'll do that the next time this happens. What's the best way to go about debugging this... which sysctl's should I be looking at first? I have already tried raising kern.ipc.nmbjumbo9 to 16384 and it doesn't seem to help things... maybe prolonging it slightly, but not by much. The problem is it takes a week or so to reproduce the problem each time... I vaguely guess it could be related with other subsystem which leaks mbufs such that driver was not able to get more jumbo RX buffers from system. For instance, r228016 would be worth to try on your box. I can't clearly explain why em(4) does not suffer from the issue though. I've just this morning built a kernel with that fix, so we'll see how that goes. ___ 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: Sporadic 9.0-RC2 boot-time panic
On Mon, 28 Nov 2011 23:37:27 +0100, Mike Andrews wrote: *Sometimes* when booting 9.0-RC2 on *some* of my machines, I'll get one of the following two panics during multiuser startup, usually while running the /usr/local/etc/rc.d scripts. (The instruction pointer is always exactly one of these two, and they look fairly related.) If after two or three reboots it manages to not panic, the system will run perfectly stable. For some probably-unrelated reason, the dump never finishes in either case. First panic (note em0 warning before it): - em0: discard frame w/o packet header Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x805e4fc5 stack pointer = 0x28:0xff80003299e0 frame pointer = 0x28:0xff8000329a00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x805e4fc5, rsp = 0xff80003299e0, rbp = 0xff8000329a00 --- m_freem() at m_freem+0x25 ether_nh_input() at ether_nh_input+0x82 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 49s Dumping 679 out of 12263 MB: - Second panic (no em0 discard warning this time): - Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0x8063c0e4 stack pointer = 0x28:0xff8000329a00 frame pointer = 0x28:0xff8000329a40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: em0:rx 0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x10a calltrap() at calltrap+0x8 --- trap 0x9, rip = 0x8063c0e4, rsp = 0xff8000329a00, rbp = 0xff8000329a40 --- ether_nh_input() at ether_nh_input+0x94 netisr_dispatch_src() at netisr_dispatch_src+0x20b em_rxeof() at em_rxeof+0x1ca em_msix_rx() at em_msix_rx+0x24 intr_event_execute_handlers() at intr_event_execute_handlers+0x104 ithread_loop() at ithread_loop+0xa4 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- Uptime: 46s Dumping 657 out of 12263 MB:..3% ___ 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" Does it help if you disable msix on your em0? Google for 'sysctl em msix'. Or run 'sysctl -a | grep msix'. NB: I know nothing about the details of em of msix, so hopefully somebody with more clue responds also. Ronald. ___ 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: 9.0-RC2 re(4) "no memory for jumbo buffers" issue
On Mon, Nov 28, 2011 at 05:38:16PM -0500, Mike Andrews wrote: > On 11/27/11 8:39 PM, YongHyeon PYUN wrote: > >On Sat, Nov 26, 2011 at 04:05:58PM -0500, Mike Andrews wrote: > >>I have a Supermicro 5015A-H (Intel Atom 330) server with two Realtek > >>RTL8111C-GR gigabit NICs on it. As far as I can tell, these support > >>jumbo frames up to 7422 bytes. When running them at an MTU of 5000 on > > > >Actually the maximum size is 6KB for RTL8111C, not 7422. > >RTL8111C and newer PCIe based gigabit controllers no longer support > >scattering a jumbo frame into multiple RX buffers so a single RX > >buffer has to receive an entire jumbo frame. This adds more burden > >to system because it has to allocate a jumbo frame even when it > >receives a pure TCP ACK. > > OK, that makes sense. > > >>FreeBSD 9.0-RC2, after a week or so of update, with fairly light network > >>activity, the interfaces die with "no memory for jumbo buffers" errors > >>on the console. Unloading and reloading the driver (via serial console) > >>doesn't help; only rebooting seems to clear it up. > >> > > > >The jumbo code path is the same as normal MTU sized one so I think > >possibility of leaking mbufs in driver is very low. And the > >message "no memory for jumbo RX buffers" can only happen either > >when you up the interface again or interface restart triggered by > >watchdog timeout handler. I don't think you're seeing watchdog > >timeouts though. > > I'm fairly certain the interface isn't changing state when this happens > -- it just kinda spontaneously happens after a week or two, with no > interface up/down transitions. I don't see any watchdog messages when > this happens. There is another code path that causes controller reinitialization. If you change MTU or offloading configuration(TSO, VLAN tagging, checksum offloading etc) it will reinitialize the controller. So do you happen to trigger one of these code path during a week or two? > > >When you see "no memory for jumbo RX buffers" message, did you > >check available mbuf pool? > > Not yet, that's why I asked for debugging tips -- I'll do that the next > time this happens. > > >>What's the best way to go about debugging this... which sysctl's should > >>I be looking at first? I have already tried raising kern.ipc.nmbjumbo9 > >>to 16384 and it doesn't seem to help things... maybe prolonging it > >>slightly, but not by much. The problem is it takes a week or so to > >>reproduce the problem each time... > >> > > > >I vaguely guess it could be related with other subsystem which > >leaks mbufs such that driver was not able to get more jumbo RX > >buffers from system. For instance, r228016 would be worth to try on > >your box. I can't clearly explain why em(4) does not suffer from > >the issue though. > > I've just this morning built a kernel with that fix, so we'll see how > that goes. Ok. ___ 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: Low nfs write throughput
> "Bengt" == Bengt Ahlgren writes: > Daryl Sayers writes: >> Can anyone suggest why I am getting poor write performance from my nfs setup. >> I have 2 x FreeBSD 8.2-STABLE i386 machines with ASUS P5B-plus mother boards, >> 4G mem and Dual core 3g processor using 147G 15k Seagate SAS drives with >> onboard Gb network cards connected to an idle network. The results below show >> that I get nearly 100Mb/s with a dd over rsh but only 15Mbs using nfs. It >> improves if I use async but a smbfs mount still beats it. I am using the same >> file, source and destinations for all tests. I have tried alternate Network >> cards with no resulting benefit. > [...] >> Looking at a systat -v on the destination I see that the nfs test does not >> exceed 16KB/t with 100% busy where the other tests reach up to 128KB/t. >> For the record I get reads of 22Mb/s without and 77Mb/s with async turned on >> for the nfs mount. > On an UFS filesystem you get NFS writes with the same size as the > filesystem blocksize. So an easy way to improve performance is to > create a filesystem with larger blocks. I accidentally found this out > when I had two NFS exported filesystems from the same box with 16K and > 64K blocksizes respectively. > (Larger blocksize also tremendously improves the performance of UFS > snapshots!) Thanks to all that answered. I did try the 'sysctl -w vfs.nfsrv.async=1' with no reportable change in performance. We are using a UFS2 filesystem so the zfs command was not required. I did not try the patch as we would like to stay as standard as possible but will upgrade if the patch is released in new kernel. Thanks Bengt for the suggestion of block size. Increasing the block size to 64k made a significant improvement to performance. -- Daryl Sayers Direct: +612 95525510 Corinthian Engineering Office: +612 95525500 Suite 54, Jones Bay Wharf Fax: +612 95525549 26-32 Pirrama Rd email: da...@ci.com.au Pyrmont NSW 2009 Australia www: http://www.ci.com.au ___ 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: Sporadic 9.0-RC2 boot-time panic
On Mon, Nov 28, 2011 at 05:37:27PM -0500, Mike Andrews wrote: > *Sometimes* when booting 9.0-RC2 on *some* of my machines, I'll get > one of the following two panics during multiuser startup, usually > while running the /usr/local/etc/rc.d scripts. (The instruction > pointer is always exactly one of these two, and they look fairly > related.) If after two or three reboots it manages to not panic, > the system will run perfectly stable. > > For some probably-unrelated reason, the dump never finishes in either case. > > First panic (note em0 warning before it): > - > em0: discard frame w/o packet header > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0x805e4fc5 > stack pointer = 0x28:0xff80003299e0 > frame pointer = 0x28:0xff8000329a00 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (irq256: em0:rx 0) > trap number = 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > trap_fatal() at trap_fatal+0x290 > trap() at trap+0x10a > calltrap() at calltrap+0x8 > --- trap 0x9, rip = 0x805e4fc5, rsp = 0xff80003299e0, rbp = > 0xff8000329a00 --- > m_freem() at m_freem+0x25 > ether_nh_input() at ether_nh_input+0x82 > netisr_dispatch_src() at netisr_dispatch_src+0x20b > em_rxeof() at em_rxeof+0x1ca > em_msix_rx() at em_msix_rx+0x24 > intr_event_execute_handlers() at intr_event_execute_handlers+0x104 > ithread_loop() at ithread_loop+0xa4 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- > Uptime: 49s > Dumping 679 out of 12263 MB: > > - > > Second panic (no em0 discard warning this time): > > - > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0x8063c0e4 > stack pointer = 0x28:0xff8000329a00 > frame pointer = 0x28:0xff8000329a40 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 12 (irq256: em0:rx 0) > trap number = 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > trap_fatal() at trap_fatal+0x290 > trap() at trap+0x10a > calltrap() at calltrap+0x8 > --- trap 0x9, rip = 0x8063c0e4, rsp = 0xff8000329a00, rbp = > 0xff8000329a40 --- > ether_nh_input() at ether_nh_input+0x94 > netisr_dispatch_src() at netisr_dispatch_src+0x20b > em_rxeof() at em_rxeof+0x1ca > em_msix_rx() at em_msix_rx+0x24 > intr_event_execute_handlers() at intr_event_execute_handlers+0x104 > ithread_loop() at ithread_loop+0xa4 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8000329d00, rbp = 0 --- > Uptime: 46s > Dumping 657 out of 12263 MB:..3% We need the following things: * uname -a output * dmesg output (only details specific to emX NICs please) * pciconf -lvcb output (only details specific to emX NICs please) CC'ing Jack Vogel (driver author) who can hopefully shed some light on this. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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"
