panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD]
On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next week. > OK; I was able to build & install head @r272938 this morning on my laptop; on reboot, I was greeted by a panic. Now, this is a laptop, so I don't have a serial console -- but I was able to "call doadump", then reboot with the wireless NIC disabled (to avoid the panic) and get the dump & core.txt captured. Here's the first chunk of the core.txt file: localhost dumped core - see /var/crash/vmcore.0 Sat Oct 11 07:02:26 PDT 2014 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 panic: resize_storage() notify failure 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: panic: resize_storage() notify failure cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c10ebfd8,d1070720,fc,1000,1,...) at 0xc0528cdd = db_trace_self_wrapper+0x2d/frame 0xfa0cc508 kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = kdb_backtrace+0x30/frame 0xfa0cc570 vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = vpanic+0x11d/frame 0xfa0cc5ac kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = kassert_panic+0xea/frame 0xfa0cc5d0 ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = add_table_entry+0x348/frame 0xfa0cc7c8 manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = manage_table_ent_v1+0x1c9/frame 0xfa0cc828 ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = ipfw_ctl3+0xacd/frame 0xfa0ccb20 rip_ctloutput(d2432dc0,fa0ccbe0,,27f,1f,...) at 0xc0c3cf49 = rip_ctloutput+0x299/frame 0xfa0ccb48 sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = sogetopt+0xb0/frame 0xfa0ccba8 kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = kern_getsockopt+0x116/frame 0xfa0ccc0c sys_getsockopt(d03afc40,fa08,c12ab55e,d5,c1455210,...) at 0xc0b71417 = sys_getsockopt+0x67/frame 0xfa0ccc40 syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 0xbfbfd2e4, ebp = 0xbfbfd300 --- KDB: enter: panic Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols #0 doadump (textdump=0) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=0) at pcpu.h:233 #1 0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888, dummy4=0xfa0cc2b4 "\036\211\220À¸\026MÁ") at /usr/src/sys/ddb/db_command.c:578 #2 0xc05267ab in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc0528e20 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0xc0b226f4 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xc0f7ba87 in trap (frame=) at /usr/src/sys/i386/i386/trap.c:693 #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc0b21f7d in kdb_enter (why=0xc10e77dd "panic", msg=) at cpufunc.h:71 #9 0xc0ae7bb1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:739 #10 0xc0ae7a6a in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc0d25cfd in ipfw_link_table_values (ch=0x0, ts=0xfa0cc6f8) at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 #12 0xc0d1be78 in add_table_entry (ch=0xc1518498, tei=0xfa0cc800, flags=0 '\0', count=1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:620 #
Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD]
On 11.10.2014 18:15, David Wolfskill wrote: On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. OK; I was able to build & install head @r272938 this morning on my laptop; on reboot, I was greeted by a panic. Ups. Not the best greeting, definitely. Can you send me ipfw ruleset? Now, this is a laptop, so I don't have a serial console -- but I was able to "call doadump", then reboot with the wireless NIC disabled (to Do you have some hooks to run ipfw on iface-up? avoid the panic) and get the dump & core.txt captured. Here's the first chunk of the core.txt file: localhost dumped core - see /var/crash/vmcore.0 Sat Oct 11 07:02:26 PDT 2014 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 r...@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 panic: resize_storage() notify failure 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: panic: resize_storage() notify failure cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c10ebfd8,d1070720,fc,1000,1,...) at 0xc0528cdd = db_trace_self_wrapper+0x2d/frame 0xfa0cc508 kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = kdb_backtrace+0x30/frame 0xfa0cc570 vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = vpanic+0x11d/frame 0xfa0cc5ac kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = kassert_panic+0xea/frame 0xfa0cc5d0 ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = add_table_entry+0x348/frame 0xfa0cc7c8 manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = manage_table_ent_v1+0x1c9/frame 0xfa0cc828 ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = ipfw_ctl3+0xacd/frame 0xfa0ccb20 rip_ctloutput(d2432dc0,fa0ccbe0,,27f,1f,...) at 0xc0c3cf49 = rip_ctloutput+0x299/frame 0xfa0ccb48 sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = sogetopt+0xb0/frame 0xfa0ccba8 kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = kern_getsockopt+0x116/frame 0xfa0ccc0c sys_getsockopt(d03afc40,fa08,c12ab55e,d5,c1455210,...) at 0xc0b71417 = sys_getsockopt+0x67/frame 0xfa0ccc40 syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 0xbfbfd2e4, ebp = 0xbfbfd300 --- KDB: enter: panic Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols #0 doadump (textdump=0) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=0) at pcpu.h:233 #1 0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888, dummy4=0xfa0cc2b4 "\036\211\220À¸\026MÁ") at /usr/src/sys/ddb/db_command.c:578 #2 0xc05267ab in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:449 #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc0528e20 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0xc0b226f4 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xc0f7ba87 in trap (frame=) at /usr/src/sys/i386/i386/trap.c:693 #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc0b21f7d in kdb_enter (why=0xc10e77dd "panic", msg=) at cpufunc.h:71 #9 0xc0ae7bb1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:739 #10 0xc0ae7a6a in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc0d25cfd in ipfw_link_table_values (ch=0x0, ts=0xfa0cc6f8) at /usr/src/sys/netpfil/ip
Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD]
On Sat, Oct 11, 2014 at 07:05:12PM +0400, Alexander V. Chernikov wrote: > ... > Whoops. My bad. > It should be fixed in r272940. > ... Confirmed: I'm not running: FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1393 r272938M/272938:1100037: Sat Oct 11 08:45:34 PDT 2014 root@localhost:/common/S4/obj/usr/src/sys/CANARY i386 after having hand-applied the patch in r272940, rebuilt, reinstalled, and rebooted. Thank you for the quick work! :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpGy1a6nWe15.pgp Description: PGP signature
Enabling VIMAGE by default for FreeBSD 11?
Hi, What action items are left to enable VIMAGE by default for FreeBSD 11? Not everyone uses bhyve, so VIMAGE is quite useful when using jails. -- Craig ___ 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: Enabling VIMAGE by default for FreeBSD 11?
On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > Hi, > > What action items are left to enable VIMAGE by default for FreeBSD 11? Are there any tests results showing performance implications on different network-related workloads? > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > -- > Craig > ___ > 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" > ___ 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: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?)
Ping, Luigi - would you mind sending through a diff ? I'd like to get this into -HEAD on both igb and ixgbe. Thanks! -a On 1 October 2014 16:53, Adrian Chadd wrote: > On 1 October 2014 16:53, Luigi Rizzo wrote: >> On Wed, Oct 01, 2014 at 04:47:32PM -0700, Adrian Chadd wrote: >>> On 1 October 2014 16:49, Luigi Rizzo wrote: >>> > On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: >>> >> Yeah, just grab the diffs that I committed to ixgbe and try it out. >>> >> >>> >> The flowdirector initialisation is buggy. :) >>> > >>> > ok but i don't think it is related, see my previous email. >>> >>> I saw - but the verisign people also saw queue stalls as well. >>> >>> So is setting DROP_EN unconditionally fixing it for you? >> >> yes so it seems. > > Interesting. That's a pretty small window to get it wrong in. > > Would you file a PR about it? We'll try to get this fixed soon. > > (Same for igb..) > > Thanks! > > > > -a ___ 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: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?)
On Sat, Oct 11, 2014 at 03:03:13PM -0700, Adrian Chadd wrote:
> Ping,
>
> Luigi - would you mind sending through a diff ? I'd like to get this
> into -HEAD on both igb and ixgbe.
here it is.
As a result of this patch, ixgbe_rx_enable_drop() and the disable function
become useless and should be removed.
Probably the code (or the commit log) should also mention that the DROP_EN
bit is only read when the rx unit is started, this is why the code should
go here and not in the sysctl handler.
cheers
luigi
Index: ixgbe.c
===
--- ixgbe.c (revision 272603)
+++ ixgbe.c (working copy)
@@ -4377,6 +4377,19 @@
srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK;
srrctl |= bufsz;
srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
+ /*
+* Set DROP_EN iff we have no flow control and >1 queue.
+* Note that srrctl was cleared shortly before during reset,
+* so we do not need to clear the bit, but do it just in case
+* this code is moved elsewhere.
+*/
+ if (adapter->num_queues > 1 &&
+ adapter->hw.fc.requested_mode == ixgbe_fc_none) {
+ srrctl |= IXGBE_SRRCTL_DROP_EN;
+ } else {
+ srrctl &= ~IXGBE_SRRCTL_DROP_EN;
+ }
+
IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl);
/* Setup the HW Rx Head and Tail Descriptor Pointers */
___
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: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?)
Thanks! I'll review/commit this to -HEAD now.
-a
On 11 October 2014 15:24, Luigi Rizzo wrote:
> On Sat, Oct 11, 2014 at 03:03:13PM -0700, Adrian Chadd wrote:
>> Ping,
>>
>> Luigi - would you mind sending through a diff ? I'd like to get this
>> into -HEAD on both igb and ixgbe.
>
>
> here it is.
>
> As a result of this patch, ixgbe_rx_enable_drop() and the disable function
> become useless and should be removed.
> Probably the code (or the commit log) should also mention that the DROP_EN
> bit is only read when the rx unit is started, this is why the code should
> go here and not in the sysctl handler.
>
> cheers
> luigi
>
> Index: ixgbe.c
> ===
> --- ixgbe.c (revision 272603)
> +++ ixgbe.c (working copy)
> @@ -4377,6 +4377,19 @@
> srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK;
> srrctl |= bufsz;
> srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF;
> + /*
> +* Set DROP_EN iff we have no flow control and >1 queue.
> +* Note that srrctl was cleared shortly before during reset,
> +* so we do not need to clear the bit, but do it just in case
> +* this code is moved elsewhere.
> +*/
> + if (adapter->num_queues > 1 &&
> + adapter->hw.fc.requested_mode == ixgbe_fc_none) {
> + srrctl |= IXGBE_SRRCTL_DROP_EN;
> + } else {
> + srrctl &= ~IXGBE_SRRCTL_DROP_EN;
> + }
> +
> IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl);
>
> /* Setup the HW Rx Head and Tail Descriptor Pointers */
___
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"
A couple of trivial BIND (dynamic update) questions
I've just been messing around with the nsupdate program, which,
as I'm sure you all know, is part of the BIND 9 package.
For now, I'm just using in in "local" mode, i.e. invoking it with
the -l option.
I did managed to get it to perform a dynamic update, but I encountered
a cople of slight, and perhaps FreeBSD-specific oddities along the
way. I want to ask about those.
Firstly, various online sources, and the nsupdate man page itself
say that the name server should create a file called:
/var/run/named/session.key
when the server is started up with at least one "update-policy local;"
clause within one of the zone {} clauses within the named.conf file.
On my FreeBSD system howver, this file was instead created over here:
/var/named/var/run/named/session.key
So, um, how come? The default location wasn't good enough?
I saw that the pid file, which typically (on other systems) would
have appeared within the /var/run/named directory also, was a symlink
pointing over to /var/named/var/run/named/pid, so in order to make
the nsupdate utility work I just followed suit and created a symlink
called /var/run/named/session.key and pointed it over to the actual
key file, /var/named/var/run/named/session.key. I hope that was
the Right Thing To Do. If not, somebody please tell me.
The more troublesome problem however is that at first, my dynamic
updates were failing with SERVFAIL errors, and I couldn't figure
out why until I looked at the tail of /var/log/messages. Apparently,
BIND wants to write a ".jnl" (journal?) file in the same directory as
the one that contains the actual zone file for the zone being dynamically
updated. On FreeBSD, and for my master zones, that would be the
directory /var/named/etc/namedb/master. Unfortunately, that directory
is owned by root/wheel (with permissions set to 0755) which rendered
it unwritable by named, which is apparently run under the user ID
"bind" (and, I am guessing, with the GID set to the "bind" group).
As soon as I changed the permissions on /var/named/etc/namedb/master
to 0777, sure enough my dynamic updates started to work. But of
course, I _do not_ want to leave it like that. I just set it that
way for a quicky temporary test.
So, um, what is the Right Solution here? Do I need to re-jigger
the permissions on /var/named/etc/namedb/master to 0775 and then
add user-ID "bind" to the wheel group in /etc/groups?
Something tells me that I can't have been the first person to have
ever encountered the above two problems. And it appears like they
may perhaps both be FreeBSD-specific, which is why I'm asking about
them here, rather than on the bind-users mailing list.
___
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[2]: Enabling VIMAGE by default for FreeBSD 11?
--- Original message --- From: "Alexander V. Chernikov" Date: 11 October 2014, 23:20:39 > > On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > > > Hi, > > > > What action items are left to enable VIMAGE by default for FreeBSD 11? > Are there any tests results showing performance implications on different > network-related workloads? https://wiki.freebsd.org/NetworkingPerformanceProject Last item: "Add VNET to any of the above as well." > > > > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. > > > > -- > > Craig > > ___ > > 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" > > > > ___ > 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" > ___ 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: Enabling VIMAGE by default for FreeBSD 11?
... is it enabled by default on pcbsd? -a ___ 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: Enabling VIMAGE by default for FreeBSD 11?
On Sat, Oct 11, 2014 at 11:15 PM, Adrian Chadd wrote: > ... is it enabled by default on pcbsd? > > > -a > It was enabled in PCBSD here: https://github.com/trueos/trueos/commit/3108bbe003bc38339fbd4a26542b184b2ccb271a -- Craig ___ 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"
