Re: mount root from zfs fails under current with error 6
On Mon, 30 May 2011, Garrett Cooper wrote: ... dmesg for starters (boot -v if possible) would be extremely helpful. More details like your disk subsystem that you're booting off of, whether you're using GPT/MBR when booting via ZFS, etc would be helpful. Also being able to better trace down the root cause would be nice (not being able to boot a recent kernel, but being able to boot a kernel from almost a month ago is unfortunately a bit of a non-starter for tracking down the actual issue because that's such a long span of time). Ok. Verbose boot output is available here: http://people.freebsd.org/~mr/boot_fail.txt http://people.freebsd.org/~mr/boot_success.txt Verbose pciconf output: http://people.freebsd.org/~mr/pciconf.txt Disksetup: Im booting from 4 equally GPT partitioned 3TiB Disks: (fs)(root) gpart show ada0 =34 5860533101 ada0 GPT (2.7T) 34 990 1 freebsd-boot (495k) 1024 2098176 2 freebsd-swap (1.0G) 2099200 5858433928 3 freebsd-zfs (2.7T) 5860533128 7- free - (3.5k) (fs)(root) zpool status boot pool: boot state: ONLINE scan: scrub repaired 0 in 5h2m with 0 errors on Mon May 30 08:03:43 2011 config: NAMESTATE READ WRITE CKSUM bootONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 errors: No known data errors (fs)(root) zpool get bootfs boot NAME PROPERTY VALUE SOURCE boot bootfsboot/ROOT/root local # loader.conf: ... vfs.root.mountfrom=zfs:boot/ROOT/root ... BTW: After suspecting the new ada alias code I set: kern.cam.ada.legacy_aliases=0 But without effect. @pjd: Could you tell why/when the ZFS mount code errors with ENXIO? Thanks all for investigating! Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] remove hlt_cpus et al sysctls and related code
on 29/05/2011 06:06 Attilio Rao said the following: 2011/5/28 Attilio Rao atti...@freebsd.org: 2011/5/25 Andriy Gapon a...@freebsd.org: The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff Yes, I agree, thank you. If you are happy with it, just commit as long as Garrett tests that. OK. Waiting for test feedback. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. I almost forgot: this change would also require an UPDATE entry, where you explicitly mention the new way to deal with CPUs. Use your prefer wording. Sure. Thank you! BTW, I guess there would be no reason to MFC this change? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Testing new nfs and VIMAGE
For the list: Attached patch works.
/glz
--On May 28, 2011 19:28:43 -0400 Rick Macklem rmack...@uoguelph.ca wrote:
It worked when I added CURVNET_SET/CURVNET_RESTORE around the
RTFREE_LOCKED
macro too. Attached a complete patch.
Thank you.
and thanks for finding/reporting/testing it. I've attached another
variant of the patch that maybe you could try?
(I don't think it's necessary to do twice, so I just moved the
CURVNET_RESTORE() to after the RTFREE_LOCKED() macro instead.)
I don't know if you are a committer for this stuff or not?
If you are feel free to commit whichever variant of the patch you
find works and prefer.
If not, maybe bz@ could either commit it or review it?
(or whoever is doing the VIMAGE stuff these days?)
rick
--- fs/nfsclient/nfs_clport.c.sav 2011-05-04 19:12:10.0 -0400
+++ fs/nfsclient/nfs_clport.c 2011-05-28 19:14:30.0 -0400
@@ -943,6 +943,7 @@ nfscl_getmyip(struct nfsmount *nmp, int
sad.sin_family = AF_INET;
sad.sin_len = sizeof (struct sockaddr_in);
sad.sin_addr.s_addr = sin-sin_addr.s_addr;
+ CURVNET_SET(TD_TO_VNET(curthread));
rt = rtalloc1((struct sockaddr *)sad, 0, 0UL);
if (rt != NULL) {
if (rt-rt_ifp != NULL
@@ -956,6 +957,7 @@ nfscl_getmyip(struct nfsmount *nmp, int
}
RTFREE_LOCKED(rt);
}
+ CURVNET_RESTORE();
#ifdef INET6
} else if (nmp-nm_nam-sa_family == AF_INET6) {
struct sockaddr_in6 sad6, *sin6;
@@ -966,6 +968,7 @@ nfscl_getmyip(struct nfsmount *nmp, int
sad6.sin6_family = AF_INET6;
sad6.sin6_len = sizeof (struct sockaddr_in6);
sad6.sin6_addr = sin6-sin6_addr;
+ CURVNET_SET(TD_TO_VNET(curthread));
rt = rtalloc1((struct sockaddr *)sad6, 0, 0UL);
if (rt != NULL) {
if (rt-rt_ifp != NULL
@@ -980,6 +983,7 @@ nfscl_getmyip(struct nfsmount *nmp, int
}
RTFREE_LOCKED(rt);
}
+ CURVNET_RESTORE();
#endif
}
return (retp);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] remove hlt_cpus et al sysctls and related code
2011/5/31 Andriy Gapon a...@freebsd.org: on 29/05/2011 06:06 Attilio Rao said the following: 2011/5/28 Attilio Rao atti...@freebsd.org: 2011/5/25 Andriy Gapon a...@freebsd.org: The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff Yes, I agree, thank you. If you are happy with it, just commit as long as Garrett tests that. OK. Waiting for test feedback. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. I almost forgot: this change would also require an UPDATE entry, where you explicitly mention the new way to deal with CPUs. Use your prefer wording. Sure. Thank you! BTW, I guess there would be no reason to MFC this change? You mean no reason to not MFC it? In general, I think that users may expect those sysctls to be alive (IMHO we should consider sysctls to be part of the userland API) so that we can add some more, but we should not axe them. So probabilly MFC is not the best option here. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] remove hlt_cpus et al sysctls and related code
on 31/05/2011 16:34 Attilio Rao said the following: 2011/5/31 Andriy Gapon a...@freebsd.org: on 29/05/2011 06:06 Attilio Rao said the following: 2011/5/28 Attilio Rao atti...@freebsd.org: 2011/5/25 Andriy Gapon a...@freebsd.org: The patch is here: http://people.freebsd.org/~avg/cpu-offline-sysctl.diff It should implement the strategy described above. I don't see the point in keeping alive mp_grab_cpu_hlt() and supporting, actually. On the top of your patch I made some modifies that use directly ap_watchdog() in cpu_idle() which I think is better for the time being: http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff Yes, I agree, thank you. If you are happy with it, just commit as long as Garrett tests that. OK. Waiting for test feedback. On a second round of changes we can discuss mp_watchdog and eventual removal / improvements to it. I almost forgot: this change would also require an UPDATE entry, where you explicitly mention the new way to deal with CPUs. Use your prefer wording. Sure. Thank you! BTW, I guess there would be no reason to MFC this change? You mean no reason to not MFC it? I meant exactly what I asked :-) As in: I didn't see any reason for MFC. In general, I think that users may expect those sysctls to be alive (IMHO we should consider sysctls to be part of the userland API) so that we can add some more, but we should not axe them. So probabilly MFC is not the best option here. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS install from -CURRENT snapshot
Quoting Daniel Staal dst...@usa.net (from Mon, 30 May 2011 11:01:06 -0400): --As of May 29, 2011 9:10:57 AM -0400, George Kontostanos, freebsd-current@freebsd.org is alleged to have said: --As of May 29, 2011 12:06:30 PM +0300, George Kontostanos is alleged to have said: The new bsdinstall has a different layout so the previous guides don't work. I have prepared one that works for recent 9-Current at : http://www.aisecure.net/?p=132; --As for the rest, it is mine. Thanks, that's about what I expected the install procedure to be at this point. Nice to have the reminder about the zpool.cache. (Do I have to use the Live CD mode? Can I use shell mode instead?) --As for the rest, it is mine. Ok, I've tried shell mode and live CD mode. I've re-partitioned my disks several different ways. Nothing gets me a system that will actually boot. Or even recognize that there is an OS loaded anywhere. Help? I did it like this: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ (My preferred partitioning: ada1: 1 freebsd-boot 2 freebsd-swap 8G 3 freebsd-zfs 4G (zil) 4 freebsd-zfs 17G (cache) ada0: Managed by ZFS, ~250G Main filesystem. You show the boot partition on ada1, but you do not tell if ada0 has a boot partition too or not. Did you try to have the boot partition on the same disk as the pool? I hope ada1 is a SSD. If not, it does not make much sense to have a cache there (a cache needs to have lower latency than the main pool, I do not expect that just another spindle gives a significant perf improvement). Bye, Alexander. -- Please don't put a strain on our friendship by asking me to do something for you. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pcib allocation failure
On Saturday, May 28, 2011 9:45:48 pm deeptec...@gmail.com wrote:
On Thu, May 26, 2011 at 3:40 PM, John Baldwin j...@freebsd.org wrote:
Ohh, you have two devices behind this bridge that have prefetch ranges.
As a hack, can you try this:
Index: pci_pci.c
===
--- pci_pci.c (revision 85)
+++ pci_pci.c (working copy)
@@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
{
device_t dev;
uint32_t val;
+ uint16_t cmd;
dev = sc-dev;
+ cmd = pci_read_config(dev, PCIR_COMMAND, 2);
+ if (cmd (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
+ pci_write_config(dev, PCIR_COMMAND,
+ cmd ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
if (sc-io.valid mask WIN_IO) {
val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
if ((val PCIM_BRIO_MASK) == PCIM_BRIO_32) {
@@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
pci_write_config(dev, PCIR_PMBASEL_1, sc-pmem.base 16,
2);
pci_write_config(dev, PCIR_PMLIMITL_1, sc-pmem.limit
16, 2);
}
+ if (cmd (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
+ pci_write_config(dev, PCIR_COMMAND, cmd, 2);
}
static void
@@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc)
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
max = 0x;
}
+ /* XXX: Testing hack */
+ if (device_get_unit(sc-sc_dev) == 1)
i'm assuming that sc-sc_dev should be dev (this fixes a compilation
error).
+ sc-pmem.limit = 0xefff;
pcib_alloc_window(sc, sc-pmem, SYS_RES_MEMORY,
RF_PREFETCHABLE, max);
}
that seems to work!
Hmmm, ok. This may not be easy to fix properly for the time being as it
requires the PCI-PCI bridge to scan all the devices behind the bus to find
what resource ranges are actually needed before programming its windows. Note
that this is all to work around your BIOS being very broken. :(
btw, is my machine a test-pig for an upcoming change to the PCI bus driver?
Well, it's been a good test thus far.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: message buffer scrambling fix
On Sat, May 28, 2011 at 11:26:50 -0700, Julian Elischer wrote: On 5/27/11 3:45 PM, Kenneth D. Merry wrote: Hey folks, I have attached some patches to the kernel message buffer code (this affects dmesg(8) output as well as kernel messages that go to the syslog) to address log scrambling. This fixes the same issue that 'options PRINTF_BUFR_SIZE=128' fixes for the console. The problem is that you can have multiple kernel threads writing to the message buffer at the same time, and so their characters will get interleaved. All of the characters will get in there, because they're written with atomic operations, but the output might looked scrambled. So the fix is to use the same stack buffer that is used for the console output (so the stack size doesn't increase), and use a spin lock instead of atomic operations to insert the string into the message buffer. The result is that dmesg and syslog output should look the same as the console output. As long as individual kernel prints fit in the printf buffer size, they will be put into the message buffer atomically. I also fixed a couple of other long-standing issues. putcons() (in subr_prf.c) was adding a carriage return before calling cnputs(). But cnputs() calls cnputc(), which adds a carriage return before every newline. So much of the console output (the part that came from putcons() at least) had two carriage returns at the end. The other issue was that log_console() was inserting a newline for any console write that didn't already have one at the end. The issue with that can be seen if you do a 'dmesg -a' and compare that to the console output. You'll see something like this on the console: Updating motd:. But this in dmesg -a: Updating motd: . That is because Updating motd: is written first, log_console() appends a newline, and then .\n is written. I added a loader tunable and sysctl to turn the old behavior back on (kern.log_console_add_linefeed) if you want the old behavior, but I think we should be able to safely remove it. Also, the new msgbuf_addstr() function allows the caller to optionally ask for carriage returns to be stripped out. However, in my testing I haven't seen any carriage returns to strip. Let me know if you have any comments. I'm planning to check this into head next week. looks good.. as long as we don't end up with the behaviour that I think I see on Linux (it's hard to tell sometimes) where the last message (the one you really want to see) doesn't make it out. Everything passed into the kernel printf() call should make it out to the console, message buffer, etc. before the printf call completes. The only way that wouldn't happen is if spin locks break for some reason. One thing I forgot to mention is that I think the PRINTF_BUFR_SIZE option should be made non-optional. Even on smaller embedded machines, I think we should be able to afford the 128 bytes of stack space to keep messages from getting scrambled. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mount root from zfs fails under current with error 6
Hi, On Tue, 31 May 2011, Michael Reifenberger wrote: ... (fs)(root) gpart show ada0 =34 5860533101 ada0 GPT (2.7T) 34 990 1 freebsd-boot (495k) 1024 2098176 2 freebsd-swap (1.0G) 2099200 5858433928 3 freebsd-zfs (2.7T) 5860533128 7- free - (3.5k) ... maybe I found something: After setting vfs.zfs.debug=1 I got two new verbose bootlogs: http://people.freebsd.org/~mr/boot_fail2.txt http://people.freebsd.org/~mr/boot_success2.txt As you can see, in the failing case ZFS tries to attach to ada[0123] whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the correct devices) Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mount root from zfs fails under current with error 6
on 31/05/2011 20:38 Michael Reifenberger said the following: Hi, On Tue, 31 May 2011, Michael Reifenberger wrote: ... (fs)(root) gpart show ada0 =34 5860533101 ada0 GPT (2.7T) 34 990 1 freebsd-boot (495k) 1024 2098176 2 freebsd-swap (1.0G) 2099200 5858433928 3 freebsd-zfs (2.7T) 5860533128 7- free - (3.5k) ... maybe I found something: After setting vfs.zfs.debug=1 I got two new verbose bootlogs: http://people.freebsd.org/~mr/boot_fail2.txt http://people.freebsd.org/~mr/boot_success2.txt As you can see, in the failing case ZFS tries to attach to ada[0123] whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the correct devices) Maybe try to enable GEOM debug to see if/when tasting of the GPT partitions occurs. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
lazy mmap for a device driver ?
hi, i have a kernel module implementing a memory mapped special device which exports a large block of memory to the process. I see that when the process calls mmap(), my routine foo_mmap() is called immediately once per page, even though the process is not actually touching the pages. I believe this happens through dev_pager_alloc(). Right now i can live with that because all the memory is allocated at module load time, but i might want to have a sparse memory region which is populated dynamically, so i was wondering if there is a way to achieve this. I see there are two other device routines, d_mmap2 and d_mmap_single, any pointer to documentation or comments on how they differ ? thanks luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lazy mmap for a device driver ?
On Tue, May 31, 2011 at 10:21:42PM +0200, Luigi Rizzo wrote: hi, i have a kernel module implementing a memory mapped special device which exports a large block of memory to the process. I see that when the process calls mmap(), my routine foo_mmap() is called immediately once per page, even though the process is not actually touching the pages. I believe this happens through dev_pager_alloc(). Right now i can live with that because all the memory is allocated at module load time, but i might want to have a sparse memory region which is populated dynamically, so i was wondering if there is a way to achieve this. I see there are two other device routines, d_mmap2 and d_mmap_single, any pointer to documentation or comments on how they differ ? During the porting of GEM to our kernel, I had to make a device pager interface more flexible. In particular, the updated pager allows the device to handle individual faults and return an explicit page to satisfy the fault, instead of the physical address. More, the driver can do any appropriate setup by ctr method. The new interface is supposed to be used with d_mmap_single(). http://people.freebsd.org/~kib/misc/device_pager.2.patch pgpfgx7IJpxNf.pgp Description: PGP signature
Re: Boot halts on Thinkpad X220 (Sandy Bridge)
On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote: I got BIOS dump from gnn last week. I've been scratching my head cause it should just fail and exit gracefully unless I am totally missing something. :-( Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is the real culprit (which is more probable, BTW)? BTW, it shouldn't call INT 16h at all unless INT 15h succeeded somehow. So, I am totally lost. :-( Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot halts on Thinkpad X220 (Sandy Bridge)
On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote: On Friday 27 May 2011 01:14 pm, Xin LI wrote: On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich dieterich@googlemail.com wrote: On Wed, May 18, 2011 at 7:40 PM, Xin LI delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Try this patch? The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o any hints or BIOS fixes needed. Thanks a lot! :-) (I'm still opted to disable the typematic rate detection by default at least for amd64, as we don't do it in the past for amd64) What does this mean concerning getting the fix into CURRENT? Well, that's not a perfect fix and we do lose the ability of detecting typematic rate (by default), so technically it's a workaround (sufficient to make the kernel boot and work, though) and doesn't fix anything. I have committed it anyway since we do not have better fix (yet), and have updated atkbd(4) manual page so one can enable it again when wanted. The problem we had was that it seems that running the BIOS in the x86emu emulator on amd64 would cause problem. This doesn't seem to be fixable without hands-on experiments on a system in question, it's either a BIOS bug or an emulator bug. The strange part of the problem is that the functionality is quite common in the Good Old Days (TM). I got BIOS dump from gnn last week. I've been scratching my head cause it should just fail and exit gracefully unless I am totally missing something. :-( Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is the real culprit (which is more probable, BTW)? I found something strange about this BIOS (well, if we can call it that). Please try this: Index: sys/dev/atkbdc/atkbd.c === --- sys/dev/atkbdc/atkbd.c (revision 222550) +++ sys/dev/atkbdc/atkbd.c (working copy) @@ -1100,7 +1100,8 @@ get_typematic(keyboard_t *kbd) if (!(kbd-kb_config KB_CONF_PROBE_TYPEMATIC)) return (ENODEV); - if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0) + if (x86bios_get_intr(0x15) != 0xf000f859 || + x86bios_get_intr(0x16) != 0xf000e82e) return (ENODEV); /* Is BIOS system configuration table supported? */ You must re-enable typematic probing from loader to test it, of course. I think the following line should do: hint.atkbd.0.flags=0x10 Note: You may add printf() before and after the check to make sure it is being called (and it fails immediately). A long answer goes like this. INT 0x15 and 0x16 vectors have fixed entry points in *real* BIOS, i.e., 0xf000:0xf859 and 0xf000:0xe82e. For this BIOS (or CSM), INT 0x16 vector is correct but INT 0x15 vector is not (0xf000:0xb4f1). Funny thing is 0xf000:0xf859 actually points to a working INT 15h handler, it seems, which confused me totally. Probably it was done like this because (U)EFI CSM spec. mandated it to be located @ 0xf000:0xf859. If we follow the interrupt vector (0xf000:0xb4f1), it gets nowhere (or jumps to an unknown external interrupt handler). If we follow the fixed address, it will exit gracefully. So, actually there are two possible solutions, i.e., 1) check whether the interrupt vector is modified (the above patch), or 2) jump directly to the fixed interrupt entry point. I chose Option #1 because it is very hard to find BIOS typematic support these days (as you pointed out). Cheers, Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
