Can i add a new HDD to an encrypted array?
Hi Guys, This seems liek a really basic question, I expect a simple 'no', but I havn't found anything definative yet. I currently have a hardware RAID5 array, using the Intel Matrix RAID capability onboard, encrypted with GELI. I need to add 2 new discs to the array. If I add a disc to the array and have it rebuilt with the Intel Matrix Storage Manager, prior to booting FreeBSD will that destroy the encrypted data? If so, how can I decrypt the disk without copying the data to another partition? Please let me know if you need any other info. Thanks Using: OS: FreeBSD 7.0 Mobo: Asus p5b-e http://www.asus.com.au/products.aspx?l1=3l2=11l3=307l4=0model=1347modelmenu=1 HDDs: Seagate 500g SATA2 ___ 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: Can i add a new HDD to an encrypted array?
On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote: Hi Guys, This seems liek a really basic question, I expect a simple 'no', but I havn't found anything definative yet. I currently have a hardware RAID5 array, using the Intel Matrix RAID capability onboard, encrypted with GELI. According to ataraid(4), Intel MatrixRAID is software RAID, not real hardware RAID. I need to add 2 new discs to the array. If I add a disc to the array and have it rebuilt with the Intel Matrix Storage Manager, prior to booting FreeBSD will that destroy the encrypted data? In short, no. The long answer is that the raid array functions at a level below GELI which in turn is below the filesystem layer. GELI writes its metadata in the last sector of the device, and the ffs(7) filesystem records the size of the underlying device at creation time. Adding the two disks will make the array larger. The metadata for geli will probably not be on the last sector anymore, so geli will not recognize the enlarged device. So you'll have to save your data elsewhere, put in the extra disks, recreate the array, re-initialize and attach the geli device for the new array and newfs(8) the new geli device. If so, how can I decrypt the disk without copying the data to another partition? There are no tools for that at this time, although it should be feasable by reading a (multiple of) block(s) from the geli device and then writing it to the non-encrypted device. Note that whenever you write a block to the unencrypted device, the contents of that block on the geli device become gibberish! So you'll have to do the whole device, unless you can beforehand make a list of all the blocks that are in use by the filesystem. And if even a single block failed in transit, you're potentially screwed. And even if you could perform this in-place decryption, you should make a full backup anyway in case the procedure goes horribly wrong, which is always a possibility. :-) If you want to decrypt the device in place because you don't have enough backup capacity to store the contents of you raid array, you're aleady in trouble even if you don't know it yet. What will you do if your RAID5 fails? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpG1ojnX5EXt.pgp Description: PGP signature
Re: Help ! Regarding libpcap issue.
Hi, I recently updated the port, but didn't see this condition in testing. Are you able to build libpcap *without* using the port from the same tarball? do-patch in the port doesn't touch those files. Leo wrote: Hi All, I want to install libpcap from ports. But when I make install clean, the box output: ... config.status: creating pcap_open_dead.3pcap config.status: creating pcap_open_offline.3pcap config.status: creating config.h === Building for libpcap-1.0.0 cc -O2 -O2 -fno-strict-aliasing -pipe -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -c ./pcap-null.c ./pcap-null.c:44: error: conflicting types for 'pcap_activate' ./pcap/pcap.h:266: error: previous declaration of 'pcap_activate' was here gmake: *** [pcap-null.o] Error 1 *** Error code 1 thanks, BMS ___ 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: Can i add a new HDD to an encrypted array?
Thanks Roland, You have confirmed my worst fears. One thing though, apparently MatrixRAID is a 'Firmware RAID' system as opposed to hard or software. I don't quite know how that would effect anything but that's all I can say really. It looks like I'm buying some more disks. http://en.wikipedia.org/wiki/Intel_Matrix_RAID Regards On Fri, May 1, 2009 at 7:53 PM, Roland Smith rsm...@xs4all.nl wrote: On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote: Hi Guys, This seems liek a really basic question, I expect a simple 'no', but I havn't found anything definative yet. I currently have a hardware RAID5 array, using the Intel Matrix RAID capability onboard, encrypted with GELI. According to ataraid(4), Intel MatrixRAID is software RAID, not real hardware RAID. I need to add 2 new discs to the array. If I add a disc to the array and have it rebuilt with the Intel Matrix Storage Manager, prior to booting FreeBSD will that destroy the encrypted data? In short, no. The long answer is that the raid array functions at a level below GELI which in turn is below the filesystem layer. GELI writes its metadata in the last sector of the device, and the ffs(7) filesystem records the size of the underlying device at creation time. Adding the two disks will make the array larger. The metadata for geli will probably not be on the last sector anymore, so geli will not recognize the enlarged device. So you'll have to save your data elsewhere, put in the extra disks, recreate the array, re-initialize and attach the geli device for the new array and newfs(8) the new geli device. If so, how can I decrypt the disk without copying the data to another partition? There are no tools for that at this time, although it should be feasable by reading a (multiple of) block(s) from the geli device and then writing it to the non-encrypted device. Note that whenever you write a block to the unencrypted device, the contents of that block on the geli device become gibberish! So you'll have to do the whole device, unless you can beforehand make a list of all the blocks that are in use by the filesystem. And if even a single block failed in transit, you're potentially screwed. And even if you could perform this in-place decryption, you should make a full backup anyway in case the procedure goes horribly wrong, which is always a possibility. :-) If you want to decrypt the device in place because you don't have enough backup capacity to store the contents of you raid array, you're aleady in trouble even if you don't know it yet. What will you do if your RAID5 fails? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/http://www.xs4all.nl/%7Ersmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) ___ 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: Can i add a new HDD to an encrypted array?
On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote: Thanks Roland, You have confirmed my worst fears. One thing though, apparently MatrixRAID is a 'Firmware RAID' system as opposed to hard or software. That just means that the BIOS understands that RAID layout and knows how to boot from a RAID array. Otherwise it is just like any other software RAID. (It is a fairly safe assumption that any 'RAID-controller' that is built-in on a motherboard is actually software RAID.) I don't quite know how that would effect anything but that's all I can say really. It looks like I'm buying some more disks. http://en.wikipedia.org/wiki/Intel_Matrix_RAID Regards On Fri, May 1, 2009 at 7:53 PM, Roland Smith rsm...@xs4all.nl wrote: On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote: Hi Guys, This seems liek a really basic question, I expect a simple 'no', but I havn't found anything definative yet. I currently have a hardware RAID5 array, using the Intel Matrix RAID capability onboard, encrypted with GELI. According to ataraid(4), Intel MatrixRAID is software RAID, not real hardware RAID. I need to add 2 new discs to the array. If I add a disc to the array and have it rebuilt with the Intel Matrix Storage Manager, prior to booting FreeBSD will that destroy the encrypted data? In short, no. The long answer is that the raid array functions at a level below GELI which in turn is below the filesystem layer. GELI writes its metadata in the last sector of the device, and the ffs(7) filesystem records the size of the underlying device at creation time. Adding the two disks will make the array larger. The metadata for geli will probably not be on the last sector anymore, so geli will not recognize the enlarged device. So you'll have to save your data elsewhere, put in the extra disks, recreate the array, re-initialize and attach the geli device for the new array and newfs(8) the new geli device. If so, how can I decrypt the disk without copying the data to another partition? There are no tools for that at this time, although it should be feasable by reading a (multiple of) block(s) from the geli device and then writing it to the non-encrypted device. Note that whenever you write a block to the unencrypted device, the contents of that block on the geli device become gibberish! So you'll have to do the whole device, unless you can beforehand make a list of all the blocks that are in use by the filesystem. And if even a single block failed in transit, you're potentially screwed. And even if you could perform this in-place decryption, you should make a full backup anyway in case the procedure goes horribly wrong, which is always a possibility. :-) If you want to decrypt the device in place because you don't have enough backup capacity to store the contents of you raid array, you're aleady in trouble even if you don't know it yet. What will you do if your RAID5 fails? Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/http://www.xs4all.nl/%7Ersmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) ___ 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 -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: Can i add a new HDD to an encrypted array?
On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote: Thanks Roland, You have confirmed my worst fears. Well, there is one thing that _might_ work. It might also destroy your data, hence the first step: - Make a backup and verify it. - Remove the array from fstab, so it isn't mounted automatically. - Add the disks to the array. - Re-initialize and attach the new array as a geli(8) device, using the same password and/or key file and algorithm. - Try to grow the filesystem with growfs(8). - If that works, mount the array and restore it to fstab. Whether this works or not will depend on how the new disks are added to the array. If they are added as a continious space at the rear it will probably be fine. If the extra space shows up as patches in between or at the front it will not work because your filesystem will be hosed. :-) I'm also _assuming_ that if you initialize two geli devices with the same parameters, the on-disk data will be the same. This might not be true, in which case you've lost all your data. Alternatively, you can use dd(1) to make a copy of the geli data from the last sector of the old array, and write it to the last sector of the new array. Again, this might blow up in your face if some of the metadata isn't correct for the new array. So don't try this without a solid backup, for obvious reasons. If this works, you can write it up and submit it as a new section for the Handbook, gaining eternal glory. ;-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpAFtB6kSu2F.pgp Description: PGP signature
Re: kernel compile fails without AH_SUPPORT_AR5416
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing these
ath(4) changes to RELENG_7.
I can't remember if I tested the kernel compile without the
AH_SUPPORT_AR5416 option or not, I have been so incredibly busy.
...
ru had a change to fix this but decided not to; can't say why.
Otherwise there is a better way to fix this which I alluded to in
previous mail--use the config-generated #define that is generated for
the ath_hal device.
thanks,
BMS
Index: UPDATING
===
--- UPDATING(revision 191718)
+++ UPDATING(working copy)
@@ -8,6 +8,11 @@
/usr/ports/UPDATING. Please read that file before running
portupgrade.
+20090505:
+ The kernel compile-time option AH_SUPPORT_AR5416 has been
+ removed; it is now enabled by default as if_ath.c depends on it
+ in order to build.
+
20090504:
FreeBSD 7.2-RELEASE
Index: sys/arm/conf/AVILA
===
--- sys/arm/conf/AVILA (revision 191718)
+++ sys/arm/conf/AVILA (working copy)
@@ -133,7 +133,6 @@
#devicewlan_tkip # 802.11 TKIP support
device ath # Atheros pci/cardbus NIC's
device ath_hal # Atheros HAL (Hardware Access Layer)
-optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx
descriptors
device ath_rate_sample # SampleRate tx rate control for ath
optionsATH_DEBUG
Index: sys/sparc64/conf/GENERIC
===
--- sys/sparc64/conf/GENERIC(revision 191718)
+++ sys/sparc64/conf/GENERIC(working copy)
@@ -191,7 +191,6 @@
device wlan_scan_sta # 802.11 STA mode scanning
device ath # Atheros pci/cardbus NIC's
device ath_hal # Atheros HAL (Hardware Access Layer)
-optionsAH_SUPPORT_AR5416 # enable AR5416 tx/rx
descriptors
device ath_rate_sample # SampleRate tx rate control for ath
# Pseudo devices.
Index: sys/conf/options
===
--- sys/conf/options(revision 191718)
+++ sys/conf/options(working copy)
@@ -731,8 +731,6 @@
ATH_TX99_DIAG opt_ath.h
# options for the Atheros hal
-AH_SUPPORT_AR5416 opt_ah.h
-
AH_DEBUG opt_ah.h
AH_ASSERT opt_ah.h
AH_DEBUG_ALQ opt_ah.h
Index: sys/modules/ath/Makefile
===
--- sys/modules/ath/Makefile(revision 191718)
+++ sys/modules/ath/Makefile(working copy)
@@ -76,8 +76,9 @@
#
# AR5416, AR9160 support; these are 11n parts but only really
# supported (right now) operating in legacy mode. Note enabling
-# this support requires defining AH_SUPPORT_AR5416 in opt_ah.h
+# this support requires defining AH_SUPPORT_AR5416
# so the 11n tx/rx descriptor format is handled.
+# This support is now enabled by default.
#
# NB: 9160 depends on 5416 but 5416 does not require 9160
#
@@ -106,7 +107,4 @@
CFLAGS+= -I. -I${.CURDIR}/../../dev/ath -I${.CURDIR}/../../dev/ath/ath_hal
-opt_ah.h:
- echo '#define AH_SUPPORT_AR5416 1' $@
-
.include bsd.kmod.mk
Index: sys/dev/ath/ath_hal/ah_desc.h
===
--- sys/dev/ath/ath_hal/ah_desc.h (revision 191718)
+++ sys/dev/ath/ath_hal/ah_desc.h (working copy)
@@ -20,8 +20,12 @@
#ifndef _DEV_ATH_DESC_H
#define _DEV_ATH_DESC_H
-#include opt_ah.h/* NB: required for AH_SUPPORT_AR5416 */
+#include opt_ah.h
+#ifndef AH_SUPPORT_AR5416
+#define AH_SUPPORT_AR5416 /* always support AR5416 */
+#endif
+
/*
* Transmit descriptor status. This structure is filled
* in only after the tx descriptor process method finds a
Index: sys/dev/ath/if_ath.c
===
--- sys/dev/ath/if_ath.c(revision 191718)
+++ sys/dev/ath/if_ath.c(working copy)
@@ -3399,7 +3399,7 @@
rix = rs-rs_rate;
sc-sc_rx_th.wr_rate = sc-sc_hwmap[rix].ieeerate;
sc-sc_rx_th.wr_flags = sc-sc_hwmap[rix].rxflags;
-#if HAL_ABI_VERSION = 0x07050400
+#if HAL_ABI_VERSION = 0x07050400 defined(AH_SUPPORT_AR5416)
if (sc-sc_curchan.channelFlags CHANNEL_HT) {
/*
* For HT operation we must specify the channel
Index: sys/i386/conf/GENERIC
===
--- sys/i386/conf/GENERIC (revision 191718)
+++ sys/i386/conf/GENERIC (working copy)
@@ -255,7 +255,6 @@
device an # Aironet 4500/4800 802.11 wireless NICs.
device ath # Atheros pci/cardbus NIC's
device ath_hal
Re: kern/133756: [bce] bce commit r190582 breaks lagg in 7.2-PRERELASE
This is just a quick update about some further investigations on this. I tested out the patch that Niki Denev kindly sent me which apparently fixes a length issue when zero copy sockets are not in use. This did not, however, solve the problem, but as part of this I ran tcpdump on the bce0 and bce1 interfaces for the working and non working kernels. On the kernel which does not work I never see any packets being received, though LACP packets are being transmitted. The switch to which the devices are connected is (I believe) configured in a mode where it will only send LACP packets back when it has received some. So the lack of incomming pa ckets in tcpdump does not necessarily mean that the recive side is failing, as it may be that the transmitted packets are not making it out of the interface. On identical hardware with no LACP in place the bce interfaces work fine. What I have yet to try is runnign a simple lagg bundle on this machine, to see if the problem is specific to LACP. I also rolled the system back to 7.1 and tested a patch from Doug Ambrisko which adds the support for the 5709 but contains none of the other changes. This did work, so that has excluded those changes from the cause of the problems. -pete. ___ 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: kernel compile fails without AH_SUPPORT_AR5416
Bruce Simpson wrote: Hi, Can you please try this patch? I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. Sam Leffler wrote: Bruce Simpson wrote: Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. ... ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the ath_hal device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. Also changes must go in head first. Sam ___ 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: Garbled output from kgdb?
On Wednesday 29 April 2009 4:28:09 pm Alan Amesbury wrote: One of my systems (FreeBSD 7.1-RELEASE-p3/amd64) has panicked a couple times recently without an identified cause. This most recent time I was able to obtain a crash dump from the system, but output from kgdb is garbled. Output #1 % pwd /usr/obj/usr/src/sys/[REDACTED] % sudo kgdb kernel.debug ~/crash/vmcore.0 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 amd64-marcel-freebsd... Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 07 fault virtual addresske rn= el0 xt60r afapul t 1co2de w= isutpehrv isiorn twerritreu pdtasta d,i spaagbe lnoet dpres ent instruction pointer = 0x8:0x80424561 s tack pFoianttera l= 0x10t:0xfffrffaffpfac057af0 frame pointer = 0x10:0xff00010f86e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu3) trap number = 12 panic: page fault cpuid = 3 Uptime: 40d10h35m18s Physical memory: 8176 MB Dumping 691 MB: 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/daemon_saver.ko #0 doadump () at pcpu.h:195 195 __asm __volatile(movq %%gs:0,%0 : =r (td)); (kgdb) list *0x8:0x80424561 A syntax error in expression, near `:0x80424561'. Drop the '0x8:' from this and it will work better. Also, 'bt' output would be good. -- John Baldwin ___ 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: lock up in 6.2 (procs massively stuck in Giant)
On Thursday 30 April 2009 2:36:34 am pluknet wrote: Hi folks. Today I got a new locking issue. This is the first time I got it, and it's merely reproduced. The box has lost both remote connection and local access. No SIGINFO output on the local console even. Jumping in ddb shows the next: 1) first, this is a 8-way web server. No processes on runqueue except one httpd (i.e. ps shows R in its state): You need to find who owns Giant and what that thread is doing. You can try using 'show lock Giant' as well as 'show lockchain 11568'. -- John Baldwin ___ 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: kernel compile fails without AH_SUPPORT_AR5416
Sam Leffler wrote: Bruce Simpson wrote: Hi, Can you please try this patch? I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut. Sam Leffler wrote: Bruce Simpson wrote: Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. ... ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the ath_hal device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. Also changes must go in head first. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Sam ___ 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: dri + ATI: dramatic performance slowdown
On Fri, 2009-05-01 at 07:52 +0200, Oliver Lehmann wrote: Hi Robert Oliver Lehmann wrote: Robert Noland wrote: It still might be useful... Option BusType PCI any new here? No, sorry... I got distracted by over heating and trashing the disk in my test machine... Note to self... Saphire cards shouldn't exhaust into drive cage... robert. -- Robert Noland rnol...@freebsd.org FreeBSD signature.asc Description: This is a digitally signed message part
Re: Garbled output from kgdb?
John Baldwin wrote: Drop the '0x8:' from this and it will work better. Also, 'bt' output would be good. Thanks for the pointer (no pun intended). (kgdb) list *0x80424561 0x80424561 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:727). 722 else 723 TAILQ_INSERT_TAIL(ts-ts_blocked[queue], td, td_lockq); 724 MPASS(owner == ts-ts_owner); 725 mtx_unlock_spin(td_contested_lock); 726 MPASS(td-td_turnstile != NULL); 727 LIST_INSERT_HEAD(ts-ts_free, td-td_turnstile, ts_hash); 728 } 729 thread_lock(td); 730 thread_lock_set(td, ts-ts_lock); 731 td-td_turnstile = NULL; The backtrace looked odd (lots of stuff apparently missing), which is why I didn't include it before. Here it is with repeated lines collapsed for brevity: (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x in ?? () #2 0x803ee713 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x803ee9c5 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x8062478e in trap_fatal (frame=0xac057a40, eva=96) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0x806251c6 in trap (frame=0xac057a40) at /usr/src/sys/amd64/amd64/trap.c:290 #6 0x8060aafe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0x80424561 in turnstile_wait (ts=0xff000105dd20, owner=Variable owner is not available. ) at /usr/src/sys/kern/subr_turnstile.c:727 #8 0x803e0915 in _mtx_lock_sleep (m=0xff00011ff600, tid=18446742974215718624, opts=Variable opts is not available. ) at /usr/src/sys/kern/kern_mutex.c:420 #9 0x801ee1e9 in AcpiOsAcquireLock (Handle=0xff000105dd20) at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377 #10 0x801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at /usr/src/sys/contrib/dev/acpica/hwregs.c:444 #11 0x801f5f6e in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:928 #12 0x806119a9 in cpu_idle () at /usr/src/sys/amd64/amd64/machdep.c:581 #13 0x8040f0e4 in sched_idletd (dummy=Variable dummy is not available. ) at /usr/src/sys/kern/sched_ule.c:2676 #14 0x803caa30 in fork_exit (callout=0x8040ee00 sched_idletd, arg=0x0, frame=0xac057c80) at /usr/src/sys/kern/kern_fork.c:804 #15 0x8060aece in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 #16 0x in ?? () [identical lines 17-38 removed] #39 0x in ?? () #40 0x00afe000 in ?? () #41 0x808b08c0 in tdq_cpu () #42 0x in ?? () #43 0x808bacc0 in tdq_groups () #44 0xff00010f86e0 in ?? () #45 0xff00010f8a10 in ?? () #46 0xac057a18 in ?? () #47 0x0006 in ?? () #48 0x8040e963 in sched_switch (td=0x8040ee00, newtd=Variable newtd is not available. ) at /usr/src/sys/kern/sched_ule.c:1938 #49 0x in ?? () [identical lines 50-114 removed] #115 0x in ?? () #116 0x in ?? () Cannot access memory at address 0xac058000 -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ 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: kernel compile fails without AH_SUPPORT_AR5416
Sam Leffler wrote: ... the ath_hal device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device name gets pulled into config(5) with the 'device' keyword. Thanks for the reminder... This is a much cleaner fix for the issue than forcing the option to be set on always. It looks like HEAD has this issue too and this can go right in there. Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? The 'out of box' config hasn't been broken by the change and this is identical to to the situation in HEAD as far as I can see. thanks, BMS ___ 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: kernel compile fails without AH_SUPPORT_AR5416
Bruce Simpson wrote: Sam Leffler wrote: ... the ath_hal device. Do not modify ah_desc.h like you've done. Add this to conf/options ATH_HAL opt_ah.h and use that to enable AH_SUPPORT_AR5416. To clarify the first comment: you've made it impossible to build code w/o the extended format descriptor; this is what I find unacceptable. Ah, of course, duh -- I forgot about the CaPiTalIzAtion of the device name gets pulled into config(5) with the 'device' keyword. Thanks for the reminder... This is a much cleaner fix for the issue than forcing the option to be set on always. It looks like HEAD has this issue too and this can go right in there. Are we happy with AH_SUPPORT_AR5416 being enabled in 7.x GENERIC? The 'out of box' config hasn't been broken by the change and this is identical to to the situation in HEAD as far as I can see. Not sure I understand your last question. If you fix the code so it's not dependent on options AH_SUPPORT_AR5416 then you can just remove it from the GENERIC config files. Otherwise the intent was that device ath_hal would enable all available chip support so yes we want support for 5416 and later parts. In fact AH_SUPPORT_AR5416 is probably not needed at all; we can conditionalize the code according to the device config; e.g. #if defined(ATH_HAL) || defined(ATH_AR5416) || defined(ATH_AR9160) || defined(ATH_AR9280) or possibly consolidate this check in one spot and define something like AH_SUPPORT_AR5416 to enable the extended descriptor format support. Beware of driver code that depends on AH_SUPPORT_AR5416 (grep shows several uses). For now just fixing the immediate problem is sufficient; I'll get to cleaning this stuff up later (unless you care to deal with it). Sam ___ 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: Garbled output from kgdb?
On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote: John Baldwin wrote: Drop the '0x8:' from this and it will work better. Also, 'bt' output would be good. Thanks for the pointer (no pun intended). (kgdb) list *0x80424561 0x80424561 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:727). 722 else 723 TAILQ_INSERT_TAIL(ts-ts_blocked[queue], td, td_lockq); 724 MPASS(owner == ts-ts_owner); 725 mtx_unlock_spin(td_contested_lock); 726 MPASS(td-td_turnstile != NULL); 727 LIST_INSERT_HEAD(ts-ts_free, td-td_turnstile, ts_hash); 728 } 729 thread_lock(td); 730 thread_lock_set(td, ts-ts_lock); 731 td-td_turnstile = NULL; This is odd. The backtrace looked odd (lots of stuff apparently missing), which is why I didn't include it before. Here it is with repeated lines collapsed for brevity: (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x in ?? () #2 0x803ee713 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x803ee9c5 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x8062478e in trap_fatal (frame=0xac057a40, eva=96) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0x806251c6 in trap (frame=0xac057a40) at /usr/src/sys/amd64/amd64/trap.c:290 #6 0x8060aafe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0x80424561 in turnstile_wait (ts=0xff000105dd20, owner=Variable owner is not available. ) at /usr/src/sys/kern/subr_turnstile.c:727 #8 0x803e0915 in _mtx_lock_sleep (m=0xff00011ff600, tid=18446742974215718624, opts=Variable opts is not available. ) at /usr/src/sys/kern/kern_mutex.c:420 #9 0x801ee1e9 in AcpiOsAcquireLock (Handle=0xff000105dd20) at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377 #10 0x801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at /usr/src/sys/contrib/dev/acpica/hwregs.c:444 #11 0x801f5f6e in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:928 #12 0x806119a9 in cpu_idle () at /usr/src/sys/amd64/amd64/machdep.c:581 #13 0x8040f0e4 in sched_idletd (dummy=Variable dummy is not available. ) at /usr/src/sys/kern/sched_ule.c:2676 #14 0x803caa30 in fork_exit (callout=0x8040ee00 sched_idletd, arg=0x0, frame=0xac057c80) at /usr/src/sys/kern/kern_fork.c:804 #15 0x8060aece in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 The trace actually ends here. There is nothing super bad here but there is a big problem actually in that the idle threads cannot block on a lock, so it is a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks protecting the idle registers need to use spin locks instead. The problem with blocking in the idle thread is that the scheduler assumes (even requires) that the idle thread is _always_ runnable. -- John Baldwin ___ 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: Garbled output from kgdb?
John Baldwin wrote: This is odd. [snip] The trace actually ends here. There is nothing super bad here but there is a big problem actually in that the idle threads cannot block on a lock, so it is a problem for the ACPI code to be acquiring a mutex here. Perhaps the locks protecting the idle registers need to use spin locks instead. The problem with blocking in the idle thread is that the scheduler assumes (even requires) that the idle thread is _always_ runnable. I'm a bit out of my depth when it comes to kernel debugging. That said, if you can think of anything I can do or provide which might help narrow down the scope and nature of the bug (ACPI code in the host's firmware, an error in FreeBSD's ACPI support, etc.), let me know what needs to be done. I'll provide it to the list. It's a production host, so I'd like to keep disruptions to a minimum. That said, it's panicked more than once, so I think I can justify using it towards elimination of the cause of that panic if necessary. I appreciate you taking the time to look at it this far! Thanks! -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ 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
current zfs tuning in RELENG_7 (AMD64) suggestions ?
I gave the AMD64 version of 7.2 RC2 a spin and all installed as expected off the dvd INTEL S3200SHV MB, Core2Duo, 4G of RAM In the past it had been suggested that for zfs tuning, something like vm.kmem_size_max=1073741824 vm.kmem_size=1073741824 vfs.zfs.prefetch_disable=1 However doing a simple test with bonnie and dd, there does not seem to be very much difference in 4 configs. Am I better off just with the defaults ? The machine is acting as anoffline storage site, so a steady stream of data via rsync/ssh The writes are all within the normal variance of the tests except for b). Is there anything else that should be tuned ? Not that I am looking for any magic bullets but I just want to run this backup server as best as possible ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU a5000 98772 54.7 153111 31.5 100015 21.1 178730 85.3 368782 32.5 161.6 0.6 b5000 101271 57.9 154765 31.5 61325 13.9 176741 84.6 372477 32.8 149.3 0.6 c5000 102331 57.1 159559 29.5 105767 17.4 144410 63.8 299317 19.9 167.9 0.6 d5000 107308 58.6 175004 32.4 117926 18.8 143657 63.4 305126 20.0 167.6 0.6 a) defaults b) vm.kmem_size_max=1073741824 vm.kmem_size=1073741824 c) vfs.zfs.prefetch_disable=1 plus b) d) vfs.zfs.zil_disable=1 plus c) plus b) Results tend to fluctuate a bit. offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000 1000+0 records in 1000+0 records out 2097152000 bytes transferred in 10.016818 secs (209363092 bytes/sec) offsitetmp# offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000 1000+0 records in 1000+0 records out 2097152000 bytes transferred in 10.733547 secs (195382943 bytes/sec) offsitetmp# Drives are raidz ad1: 1430799MB Seagate ST31500341AS CC1H at ata3-master SATA300 ad2: 1430799MB Seagate ST31500341AS CC1H at ata4-master SATA300 ad3: 1430799MB Seagate ST31500341AS CC1H at ata5-master SATA300 ad4: 1430799MB Seagate ST31500341AS CC1H at ata6-master SATA300 on ich9 ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: current zfs tuning in RELENG_7 (AMD64) suggestions ?
In the past it had been suggested that for zfs tuning, something like vm.kmem_size_max=1073741824 vm.kmem_size=1073741824 vfs.zfs.prefetch_disable=1 However doing a simple test with bonnie and dd, there does not seem to be very much difference in 4 configs. Am I better off just with The tuning isn't there to improve performance, it's there to prevent the box going titus due to a panic when the ARC gets too big, and you are missing the mian one, which is to limit the size of the ARC. On recent versions of BSD (and you are running 7.2, so thats fine) then the defaults for kmem size are fine, but you still need something like this: vfs.zfs.arc_max=256M In there to stop the ARC growing. thats the only tuning I have on my 4 gig machine, which takes a steady stream of data and is used for taking backup snapshots. ZFS is excellent, and for me is perfectly stable, to the point where I am starting to roll it out to production machines, with the above tuning. -pete. ___ 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: current zfs tuning in RELENG_7 (AMD64) suggestions ?
At 04:53 PM 5/1/2009, Pete French wrote: The tuning isn't there to improve performance, it's there to prevent the box going titus due to a panic when the ARC gets too big, and you are missing the mian one, which is to limit the size of the ARC. On recent versions of BSD (and you are running 7.2, so thats fine) then the defaults for kmem size are fine, but you still need something like this: vfs.zfs.arc_max=256M In there to stop the ARC growing. thats the only tuning I have on my 4 gig machine, which takes a steady stream of data and is used for taking backup snapshots. ZFS is excellent, and for me is perfectly stable, to the point where I am starting to roll it out to production machines, with the above tuning. Thanks for the feedback. We too have had good results with zfs for what we have used it for. Our primary backup server has a traditional raid5 spool as well as a zfs spool and it has been working quite well in the last 6months. In that period we did swap out a dead drive, a dying drive and added a new drive to expand the pool. We are just expanding our DR site's backup server and will make use of ZFS there. Stability / reliability is our main goal for this app so I will take a look at the arc_max setting ---Mike ___ 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: kern/133756: [bce] bce commit r190582 breaks lagg in 7.2-PRERELASE
One more test I just managed to do - using bce and lagg in 'failover' mode works fine, so it would appear that the problem lies with LACP. -pete. ___ 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: current zfs tuning in RELENG_7 (AMD64) suggestions ?
On May 1, 2009, at 1:53 PM, Pete French wrote: ... The tuning isn't there to improve performance, it's there to prevent the box going titus due to a panic when the ARC gets too big, and you are missing the mian one, which is to limit the size of the ARC. On recent versions of BSD (and you are running 7.2, so thats fine) then the defaults for kmem size are fine, but you still need something like this: vfs.zfs.arc_max=256M In there to stop the ARC growing. thats the only tuning I have on my 4 gig machine, which takes a steady stream of data and is used for taking backup snapshots. ZFS is excellent, and for me is perfectly stable, to the point where I am starting to roll it out to production machines, with the above tuning. I agree, although I'm using 384 instead of 256. My systems have been running in production for almost a year now w/o any ZFS issues. -- Louis Kowolowskilou...@cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.org/~louisk Making life more interesting for people since 1977 ___ 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: current zfs tuning in RELENG_7 (AMD64) suggestions ?
On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski lou...@cryptomonkeys.org wrote: On May 1, 2009, at 1:53 PM, Pete French wrote: ... The tuning isn't there to improve performance, it's there to prevent the box going titus due to a panic when the ARC gets too big, and you are missing the mian one, which is to limit the size of the ARC. On recent versions of BSD (and you are running 7.2, so thats fine) then the defaults for kmem size are fine, but you still need something like this: vfs.zfs.arc_max=256M In there to stop the ARC growing. thats the only tuning I have on my 4 gig machine, which takes a steady stream of data and is used for taking backup snapshots. ZFS is excellent, and for me is perfectly stable, to the point where I am starting to roll it out to production machines, with the above tuning. I agree, although I'm using 384 instead of 256. My systems have been running in production for almost a year now w/o any ZFS issues. The exact value to use will depend on the system. Particularly on the amount of RAM in the system, and what kmem_max is set to. A rule-of-thumb we've been using is: kmem_max should be half of the amount of RAM (or 1.5 GB as that's the current max) arc_max should be half of kmem_max Using those, we've been able to run our ZFS boxes without any kmem panics, even when doing rsync backups for 102 remote servers every night to a single box. Finding those values was fun. :( -- Freddie Cash fjwc...@gmail.com ___ 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: current zfs tuning in RELENG_7 (AMD64) suggestions ?
On Fri, May 01, 2009 at 04:42:09PM -0400, Mike Tancsa wrote: I gave the AMD64 version of 7.2 RC2 a spin and all installed as expected off the dvd INTEL S3200SHV MB, Core2Duo, 4G of RAM snip The writes are all within the normal variance of the tests except for b). Is there anything else that should be tuned ? Not that I am looking for any magic bullets but I just want to run this backup server as best as possible ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU a5000 98772 54.7 153111 31.5 100015 21.1 178730 85.3 368782 32.5 161.6 0.6 b5000 101271 57.9 154765 31.5 61325 13.9 176741 84.6 372477 32.8 149.3 0.6 c5000 102331 57.1 159559 29.5 105767 17.4 144410 63.8 299317 19.9 167.9 0.6 d5000 107308 58.6 175004 32.4 117926 18.8 143657 63.4 305126 20.0 167.6 0.6 begin brain dump You might want to try running gstat -I 10 during the test to see how fast each drive flushes the cache from ram and if there are any disks slower than the others. I've found some cards or slots cause drives to perform slower than other drives in the system, dragging down performance of the raid to the slowest drive(s). Individual performance testing of the drives outside of the raid might reveal something too, even just to find out what the maximum sequential speed of one drive is so you know that 4x(speed) is the best to hope for in raid tests. ZFS tends to cache heavily at the start of each write and you will probably see it bounce between no IO and furious writes, until the ram cache fills up more and it has no choice but to write almost constantly. This can affect the results between runs. I would recommend a larger count= that results in a test run of 30-60 seconds at least. Additionally, try other zfs raid types such as mirror and stripe to see if raidz is acting as an unexpectedly large bottleneck, I've found its serial write speed usually leaves something to be desired. Even if the other raid levels won't work realistically in the long run, its useful to raise the bar to find out what extra performance your IO setup can push. It could be useful to compare with gstripe and graid3 for further hardware performance evaluation. On the other hand, if you can read/write data faster than your network connection can push, you're probably at a workable level. Also, I believe that zfs uses a cluster size up to 128k (queueing multiple writes if it can, depending on the disk subsystem) so I think the computer has to do extra work if you are giving it bs=2048k since zfs will have to cut that into 16 pieces, sending one piece to each drive. You might try bs=512k or bs=128k for example to see if this has a positive effect. In a traditional raid5 setup, I've found I get head over heals the best performance when my bs= is the same size as the raid stripe size multiplied by the number of drives, and this gets weird when you have an odd number of drives because your optimum write size might be something like 768k which probably no application is going to produce :) Also it makes it hard to optimize UFS for a larger stripe size when the cluster sizes are generally limited to 16k such as in Solaris. Results tend to fluctuate a bit. offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000 1000+0 records in 1000+0 records out 2097152000 bytes transferred in 10.016818 secs (209363092 bytes/sec) offsitetmp# offsitetmp# dd if=/dev/zero of=/tank1/test bs=2048k count=1000 1000+0 records in 1000+0 records out 2097152000 bytes transferred in 10.733547 secs (195382943 bytes/sec) offsitetmp# Drives are raidz ad1: 1430799MB Seagate ST31500341AS CC1H at ata3-master SATA300 ad2: 1430799MB Seagate ST31500341AS CC1H at ata4-master SATA300 ad3: 1430799MB Seagate ST31500341AS CC1H at ata5-master SATA300 ad4: 1430799MB Seagate ST31500341AS CC1H at ata6-master SATA300 on ich9 ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to
FreeBSD supported branches update
Hello Everyone, The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 7.0. The new list is below and at URL: http://security.freebsd.org/ . Please note that FreeBSD 7.0 was originally announced with an EoL date of February 28, 2009, but the EoL was delayed by two months in order to allow a 3 month window for systems to be upgraded to FreeBSD 7.1. Users of FreeBSD 7.0 are advised to upgrade promptly to FreeBSD 7.1, either by downloading an updated source tree and building updates manually, or (for i386 and amd64 systems) using the FreeBSD Update utility as described in the FreeBSD 7.1 release announcement. Some users may wish to wait for the upcoming FreeBSD 7.2-RELEASE; however, they should be aware that FreeBSD 7.2-RELEASE will only receive normal support (i.e., support for 12 months) and consequently it will not be supported for as long as FreeBSD 7.1. [Excerpt from http://security.freebsd.org/ follows] FreeBSD Security Advisories The FreeBSD Security Officer provides security advisories for several branches of FreeBSD development. These are the -STABLE Branches and the Security Branches. (Advisories are not issued for the -CURRENT Branch.) * The -STABLE branch tags have names like RELENG_7. The corresponding builds have names like FreeBSD 7.0-STABLE. * Each FreeBSD Release has an associated Security Branch. The Security Branch tags have names like RELENG_7_0. The corresponding builds have names like FreeBSD 7.0-RELEASE-p1. Isses affecting the FreeBSD Ports Collection are covered in the FreeBSD VuXML document. Each branch is supported by the Security Officer for a limited time only, and is designated as one of `Early adopter', `Normal', or `Extended'. The designation is used as a guideline for determining the lifetime of the branch as follows. Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release, and for sufficient additional time (if needed) to ensure that there is a newer release for at least 3 months before the older Normal release expires. Extended Selected releases (normally every second release plus the last release from each -STABLE branch) will be supported by the Security Officer for a minimum of 24 months after the release, and for sufficient additional time (if needed) to ensure that there is a newer Extended release for at least 3 months before the older Extended release expires. The current designation and estimated lifetimes of the currently supported branches are given below. The Estimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch's support being dropped earlier than the date listed. ++ | Branch | Release | Type | Release date | Estimated EoL | |---+---++-+-| |RELENG_6 |n/a|n/a |n/a |November 30, 2010| |---+---++-+-| |RELENG_6_3 |6.3-RELEASE|Extended|January 18, 2008 |January 31, 2010 | |---+---++-+-| |RELENG_6_4 |6.4-RELEASE|Extended|November 28, 2008|November 30, 2010| |---+---++-+-| |RELENG_7 |n/a|n/a |n/a |last release + 2y| |---+---++-+-| |RELENG_7_1 |7.1-RELEASE|Extended|January 4, 2009 |January 31, 2011 | ++ [End excerpt] -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ 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
