Re: occasional filesystem corruption
On Tue, 20 Feb 2001, Vallo Kallaste wrote: > I have experienced two filesystem corruption cases recently. Both > took place in /usr filesystem, the first was file with very big [skip] > lock order reversal > ../../kern/kern_synch.c:429: sleeping with "vnode interlock" locked from >/usr/ports/net/smbfs/work/smbfs-1.3.5/kernel/modules/smbfs2/../../fs/smbfs/smbfs_vnops.c:280 Thanks, this particular bug is fixed. Not sure if it can cause filesystem corruption (in fact it shouldn't). However, it is not advisable to use kernel modules with WITNESS enabled. P.S. setting more appropriate subject might give a faster response :) -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf lack of CPUTYPE=k6-3 support
Maxim Sobolev wrote: > > > > > > --AhhlLboLdkugWU4S > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wr= > > ote: > > > Hi, > > >=20 > > > Is there anything against adding support for > > > k6-3 to the just added CPUTYPE mechanism? :) > > > My little machine feels left out. Hehehhe > > > I made a simple patch to etc/defaults/make.conf > > > and share/mk/bsd.cpu.mk > > > Should I have touched anything else? > > >=20 > > > Regards, > > >=20 > > > ps: I think this can be MFCed asap (even during the > > > veil period) since it is very straightforward. > > > > Looks fine to me. I'll commit it. > > I see no reason for it. k6-3 is essentially k6-2 core with extra cache on > chip. Threre are no other significant differencies in the features or > instruction set. Not even to mention that there is such a beast as k6-2+ I would suggest to rename k6-2 into k6/3dnow (similarly to what we have for i586/mmx) and put a note saying that k6/3dnow should be used for k6-2/k6-2+/k6-3. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf lack of CPUTYPE=k6-3 support
> > > --AhhlLboLdkugWU4S > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wr= > ote: > > Hi, > >=20 > > Is there anything against adding support for > > k6-3 to the just added CPUTYPE mechanism? :) > > My little machine feels left out. Hehehhe > > I made a simple patch to etc/defaults/make.conf > > and share/mk/bsd.cpu.mk > > Should I have touched anything else? > >=20 > > Regards, > >=20 > > ps: I think this can be MFCed asap (even during the > > veil period) since it is very straightforward. > > Looks fine to me. I'll commit it. I see no reason for it. k6-3 is essentially k6-2 core with extra cache on chip. Threre are no other significant differencies in the features or instruction set. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Greg Lehey <[EMAIL PROTECTED]> [010311 21:20] wrote: > On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: > > * Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote: > >> On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: > >>> > >>> Vinum+DEVFS doesn't make the million symlinks that non-devfs > >>> vinum does. > >> > >> The only symlinks that the non-devfs version makes are to the drives. > >> Everything else is device nodes. But yes, it doesn't make as many > >> device nodes, and that is a Good Thing. > >> > >>> Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 > >>> > >>> (notice you need the '/vol/' path component) > >> > >> I missed that. This is not correct. The directory /dev/vinum/vol > >> should go away. > > > > Er, too late. :) > > > > On a devfs system here's what you'll see: > > > >>> ls -lR /dev/vinum/ > > total 0 > > crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control > > crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control > > crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld > > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex > > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd > > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol > > > > /dev/vinum/plex: > > total 0 > > crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 > > > > /dev/vinum/sd: > > total 0 > > crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 > > crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 > > > > /dev/vinum/vol: > > total 0 > > crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 > > > > > > I'd like to keep it this way, it just makes sense. > > No, that's a gratuitous change. All the docco talks about keeping the > volumes in the main directory. That's why people are having trouble. > Yes, it looks more uniform, but the objects aren't uniform. Since both you and Poul refused to fix the code I choose how I thought it should be. Can you explain why: > Yes, it looks more uniform, but the objects aren't uniform. It just doesn't make sense to me to mix these device nodes in with the control/Control/controld nodes. Also, why not have a /dev/vinum/ctl/ directory for those nodes? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf lack of CPUTYPE=k6-3 support
On Mon, Mar 12, 2001 at 12:29:58AM -0300, Mario Sergio Fujikawa Ferreira wrote: > Hi, > > Is there anything against adding support for > k6-3 to the just added CPUTYPE mechanism? :) > My little machine feels left out. Hehehhe > I made a simple patch to etc/defaults/make.conf > and share/mk/bsd.cpu.mk > Should I have touched anything else? > > Regards, > > ps: I think this can be MFCed asap (even during the > veil period) since it is very straightforward. Looks fine to me. I'll commit it. Kris PGP signature
Re: swap-backed md-based /tmp to replace mfs-based one
On Sun, 11 Mar 2001 15:11:09 PST, Kris Kennaway wrote: > We really need to provide a better rc.conf hook for doing this -- > expecting people to write their own script just to create a /tmp is > lame. Hello? Anybody there? Am I alone in this universe? Throw the goddamned ball! [Apologies to Eddie Murphy] I sent patches for this in this message: Message-ID: <[EMAIL PROTECTED]> You can grab the message from: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=385910+0+current/cvs-all Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FYI: nfs performance suboptimal
Warning: The following is a somewhat vague report, given as a fyi. I don't need a resolution on this problem, but wanted to report it. NFS server: Sony VAIO PCG-505TS uname -a: FreeBSD anvil.village.org 5.0-CURRENT FreeBSD 5.0-CURRENT #569: Sat Mar 10 13:17:30 MST 2001 (really Mar 3 current) NFS client: PPro-200 uname -a FreeBSD billy-club.village.org 5.0-CURRENT FreeBSD 5.0-CURRENT #59: Sat Feb 24 14:49:35 MST 2001 The Sony VAIO has a ep0 (3C589E). It has 1 2.5" IDE drive. The PPro has dc0: <82c169 PNIC 10/100BaseTX> on pci0. It has a scsi drive and an IDE drive. I'm seeing about 100kbps on nfs read performance. When I try to copy about 300MB of mp3s like so mount laptop:/mp3 /mnt cd /mnt/path/to/files tar cf - . | (cd /mp3 ; tar xvf -) After about 10 minutes of really bad network performance, the network dies. All network traffic on the server gives errors with no buffers available. netstat -m shows that there are plenty of mbufs available (10% are used). I had to reboot to get the network back. The client survived just fine. I have no clue if I can reproduce this, but thought I'd let people know there might be dragons here. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
> Mikhail Teterin <[EMAIL PROTECTED]> writes: > > Here is the trace with my attempts to browse through it. > > If you can, please reproduce the panic on a kernel compiled with the > INVARIANTS, INVARIANT_SUPPORT and WITNESS options. Well, with this options on, the machine does not crash, but the program segfaults on startup: [] 430 ktrace NAMI "/usr/games/civctp" 430 ktrace RET execve -1 errno 2 No such file or directory 430 ktrace CALL execve(0xbfbff730,0xbfbffc40,0xbfbffc48) 430 ktrace NAMI "/usr/local/sbin/civctp" 430 ktrace RET execve -1 errno 2 No such file or directory 430 ktrace CALL execve(0xbfbff730,0xbfbffc40,0xbfbffc48) 430 ktrace NAMI "/usr/local/bin/civctp" 430 civctp RET execve 0 430 civctp PSIG SIGSEGV SIG_DFL 430 civctp NAMI "civctp.core" The points of interest: . I had to brandelf the binary manually after I untarred the stuff from the CD Loki Games sent me. . The Linux Netscape continues to work properly . The binary crashes in the same fashion even when the /compat/linux is not available (not mounted), which leads me to believe, it is not recognized as a Linux binary . One does not need to be root to cause the crash (on the system without INVARIANTS and WITNESS) . The kernel has already complained twice since reboot: # dmesg [] lock order reversal 1st lockmgr interlock last acquired @ ../../kern/kern_lock.c:239 2nd 0xcefa0520 process lock @ ../../kern/kern_sig.c:183 3rd 0xc1029f80 lockmgr interlock @ ../../kern/kern_lock.c:560 lock order reversal 1st vnode interlock last acquired @ ../../kern/vfs_vnops.c:625 2nd 0xc0419680 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:939 3rd 0xcefb986c vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:948 -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: > * Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote: >> On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: >>> >>> Vinum+DEVFS doesn't make the million symlinks that non-devfs >>> vinum does. >> >> The only symlinks that the non-devfs version makes are to the drives. >> Everything else is device nodes. But yes, it doesn't make as many >> device nodes, and that is a Good Thing. >> >>> Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 >>> >>> (notice you need the '/vol/' path component) >> >> I missed that. This is not correct. The directory /dev/vinum/vol >> should go away. > > Er, too late. :) > > On a devfs system here's what you'll see: > >>> ls -lR /dev/vinum/ > total 0 > crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control > crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control > crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd > drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol > > /dev/vinum/plex: > total 0 > crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 > > /dev/vinum/sd: > total 0 > crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 > crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 > > /dev/vinum/vol: > total 0 > crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 > > > I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Boris Popov <[EMAIL PROTECTED]> [010311 20:52] wrote: > On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: > > > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > > > >What's up with devfs not gc'ing itself? Ie, after a directory > > >becomes empty it seems to still exist within the devfs namespace > > >instead of disappearing. > > > > That was a deliberate decision, removing a directory(-inode) which > > might have a valid vnode is kind of a nasty thing to attempt. > > Err, "might" ? These things are well defined by VFS interface. You hand it off to deadfs no? You want to have the same sort of handling that the common FS does when let's say you have two xterms open, one in your homedir and the other in homedir/foo, in the first you rmdir foo and suddenly the second is a bit confused, but it doesn't panic the box... -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > >What's up with devfs not gc'ing itself? Ie, after a directory > >becomes empty it seems to still exist within the devfs namespace > >instead of disappearing. > > That was a deliberate decision, removing a directory(-inode) which > might have a valid vnode is kind of a nasty thing to attempt. Err, "might" ? These things are well defined by VFS interface. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Matthew Jacob <[EMAIL PROTECTED]> [010311 20:45] wrote: > > > > Yeah... don't really need that. :) > > > > In vinum's case there's a directory /dev/vinum/drive that points > > to the device backing the vinum device: > > > > /dev/vinum % ls -lR > > total 7 > > brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control > > brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control > > brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd > > crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol > > drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd > > brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 > > drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol > > > > ./drive: > > total 0 > > lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 -> /dev/da1e > > lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 -> /dev/da2s1e > > > > Ok, now is there a way to get rid of these symlinks when vinum goes > > away? Ok, if there isn't a way to delete them, what if I unload > > and reload vinum then try to make them again? > > > > I'm afraid to answer. DES will stay angry. Well now that was a giant waste of my time, wasn't it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
> > Yeah... don't really need that. :) > > In vinum's case there's a directory /dev/vinum/drive that points > to the device backing the vinum device: > > /dev/vinum % ls -lR > total 7 > brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control > brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control > brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld > drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive > drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd > crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 > drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol > drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd > brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 > drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol > > ./drive: > total 0 > lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 -> /dev/da1e > lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 -> /dev/da2s1e > > Ok, now is there a way to get rid of these symlinks when vinum goes > away? Ok, if there isn't a way to delete them, what if I unload > and reload vinum then try to make them again? > I'm afraid to answer. DES will stay angry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Greg Lehey <[EMAIL PROTECTED]> [010311 15:21] wrote: > On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: > > > > Vinum+DEVFS doesn't make the million symlinks that non-devfs > > vinum does. > > The only symlinks that the non-devfs version makes are to the drives. > Everything else is device nodes. But yes, it doesn't make as many > device nodes, and that is a Good Thing. > > > Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 > > > > (notice you need the '/vol/' path component) > > I missed that. This is not correct. The directory /dev/vinum/vol > should go away. Er, too late. :) On a devfs system here's what you'll see: ~ % ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Matthew Jacob <[EMAIL PROTECTED]> [010311 12:19] wrote: > On Sun, 11 Mar 2001, Alfred Perlstein wrote: > > > * Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote: > > > In message <[EMAIL PROTECTED]>, Matthew >Jacob writes: > > > > > > > >> Lastly make_dev_alias() is undocumented. > > > > > > Right, just like most of the rest of the kernel. > > > > > > >Really? That's a deficiency. It should be. > > > > > > Yes, ideally, yes. > > I've updated the man page. > > > > > The problem with make_dev_alias() not being documented is that it would > > have been an effort to figure out if duplicate make_dev_alias() calls > > were idempotent, done with refcounts or a good way to panic your > > machine. > > ...I'm not following this. Too many dime or more expensive words! What you at? > > > > > There's also no destroy_dev_alias() that I can see. So when vinum > > goes away I didn't realize how one unpopulates the /dev/vinum/ tree. > > The destroy_dev destroys all aliases. Yeah... don't really need that. :) In vinum's case there's a directory /dev/vinum/drive that points to the device backing the vinum device: /dev/vinum % ls -lR total 7 brwx-- 1 root wheel 25, 0x4001 Sep 26 1999 Control brwx-- 1 root wheel 25, 0x4002 Sep 26 1999 control brwx-- 1 root wheel 25, 0x4000 Sep 26 1999 controld drwxr-xr-x 2 root wheel 512 Sep 26 1999 drive drwxr-xr-x 2 root wheel 512 Sep 26 1999 plex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rplex drwxr-xr-x 2 root wheel 512 Sep 26 1999 rsd crwxr-xr-- 1 root wheel 91, 0 Sep 26 1999 rvinum0 drwxr-xr-x 2 root wheel 512 Sep 26 1999 rvol drwxr-xr-x 2 root wheel 512 Sep 26 1999 sd brwxr-xr-- 1 root wheel 25, 0 Sep 26 1999 vinum0 drwxr-xr-x 3 root wheel 512 Sep 26 1999 vol ./drive: total 0 lrwxr-xr-x 1 root wheel 9 Sep 26 1999 vinumdrive0 -> /dev/da1e lrwxr-xr-x 1 root wheel 11 Sep 26 1999 vinumdrive1 -> /dev/da2s1e Ok, now is there a way to get rid of these symlinks when vinum goes away? Ok, if there isn't a way to delete them, what if I unload and reload vinum then try to make them again? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make.conf lack of CPUTYPE=k6-3 support
Hi,
Is there anything against adding support for
k6-3 to the just added CPUTYPE mechanism? :)
My little machine feels left out. Hehehhe
I made a simple patch to etc/defaults/make.conf
and share/mk/bsd.cpu.mk
Should I have touched anything else?
Regards,
ps: I think this can be MFCed asap (even during the
veil period) since it is very straightforward.
--
Mario S F Ferreira - UnB - Brazil - "I guess this is a signature."
lioux at ( freebsd dot org | linf dot unb dot br )
flames to beloved [EMAIL PROTECTED]
--- etc/defaults/make.conf.orig Sat Mar 10 04:35:47 2001
+++ etc/defaults/make.conf Mon Mar 12 00:23:16 2001
@@ -22,7 +22,7 @@
# NO_CPU_CFLAGS variable below.
# Currently the following CPU types are recognised:
# Intel x86 architecture:
-# (AMD CPUs) k7 k6-2 k6 k5
+# (AMD CPUs) k7 k6-3 k6-2 k6 k5
# (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386
# Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4
#
--- share/mk/bsd.cpu.mk.origSun Mar 4 06:40:11 2001
+++ share/mk/bsd.cpu.mk Mon Mar 12 00:21:16 2001
@@ -30,6 +30,8 @@
. if ${MACHINE_ARCH} == "i386"
. if ${CPUTYPE} == "k7"
CFLAGS += -march=k6# gcc doesn't support athlon yet, but it will
+. elif ${CPUTYPE} == "k6-3"
+CFLAGS += -march=k6
. elif ${CPUTYPE} == "k6-2"
CFLAGS += -march=k6
. elif ${CPUTYPE} == "k6"
@@ -75,6 +77,8 @@
.if ${MACHINE_ARCH} == "i386"
. if ${CPUTYPE} == "k7"
MACHINE_CPU = k7 3dnow k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == "k6-3"
+MACHINE_CPU = 3dnow k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6-2"
MACHINE_CPU = 3dnow k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6"
Re: swap-backed md-based /tmp to replace mfs-based one
Kris Kennaway <[EMAIL PROTECTED]> writes: > On Sun, Mar 11, 2001 at 03:15:27PM -0800, David O'Brien wrote: > > It should be a wrapper called mount_mdfs or mount_mfs so people upgrading > > can keep their /etc/fstab [mostly] the same. > > The latter would be best, IMO. I wrote a program to do this, but noone showed very much interest on -hackers. The pros are that it makes it very convenient to do all sorts of things with md without having to write different scripts to do it. The cons are that it "calls itself a mount_* but isn't a mount_* since it just runs a bunch of programs", and that it breaks `mount -p` because the filesystem shows up as "ufs" (which is technically correct). I'll post a URL to the code (it's a C program) if someone wants to look at it. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
>Date: Sun, 11 Mar 2001 15:11:09 -0800
>From: Kris Kennaway <[EMAIL PROTECTED]>
>To: Hajimu UMEMOTO <[EMAIL PROTECTED]>
>We really need to provide a better rc.conf hook for doing this --
>expecting people to write their own script just to create a /tmp is
>lame.
I appreciate the validation that what I'm trying to do makes sense (at
least to some folks). And I appreciate Hajimu Umemoto's contribution,
since I hadn't been aware of the "diskless_mount" specification.
But basically, I agree with the sentiment re: making it easier.
I would be very pleased if it were made as easy as the use of an
mfs-based /tmp (merely specify "filesystem type" as "mfs"), but my
(very!) brief acquaintance with the semantics of the md device gives me
the impression that the exact approach is unlikely to be useful.
But if we could have a set of variables defined in /etc{/defaults,}/rc.conf
for providing the parameters for creating the md-based /tmp, as well as
the decision as to whether or not this is wanted, and have some code in
/etc/rc* that pays attention to it, I believe that could be quite
satisfactory. So far, it seems to me that the critical parameters would
be the binary go/no go decision and the size. (It appears that the md
device name can be dynamically assigned at creation time.)
(I believe it would also be useful if /etc/rc.shutdown were to unmount
and de-allocate the resources for such things -- not becasue of any
familiarity with the code, but because that just seems to be the Right
Thing To Do. And to that end, it might be useful to have a somewhat
separate script (from the rest of the existing /etc/rc* scripts) that
could be invoked to create or destroy the /tmp.)
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
On Sun, Mar 11, 2001 at 03:15:27PM -0800, David O'Brien wrote: > On Sun, Mar 11, 2001 at 03:11:09PM -0800, Kris Kennaway wrote: > > We really need to provide a better rc.conf hook for doing this -- > > expecting people to write their own script just to create a /tmp is > > lame. > > It should be a wrapper called mount_mdfs or mount_mfs so people upgrading > can keep their /etc/fstab [mostly] the same. The latter would be best, IMO. Kris PGP signature
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: > * Niels Chr. Bank-Pedersen <[EMAIL PROTECTED]> [010311 02:29] wrote: >> >> I'll sneak in my experience with DEVFS+vinum here as well: >> >> vinum: loaded >> vinum: reading configuration from /dev/da3s1f >> vinum: updating configuration from /dev/da1s1e >> vinum: updating configuration from /dev/da2s1e >> vinum: updating configuration from /dev/da0s1e >> swapon: adding /dev/da1s1b as swap device >> swapon: adding /dev/da2s1b as swap device >> Automatic boot in progress... >> /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS >> /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation) >> Can't stat /dev/vinum/raid01: No such file or directory >> Can't stat /dev/vinum/raid01: No such file or directory >> /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM. >> /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. >> >> This was with a -current from around March 1. (don't think >> anything has changed since). Booting a non-DEVFS kernel >> passes the fs-check and works as expected. > > Vinum+DEVFS doesn't make the million symlinks that non-devfs > vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. > Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 > > (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
On Sun, Mar 11, 2001 at 03:11:09PM -0800, Kris Kennaway wrote: > We really need to provide a better rc.conf hook for doing this -- > expecting people to write their own script just to create a /tmp is > lame. It should be a wrapper called mount_mdfs or mount_mfs so people upgrading can keep their /etc/fstab [mostly] the same. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
We really need to provide a better rc.conf hook for doing this -- expecting people to write their own script just to create a /tmp is lame. Kris PGP signature
Re: how's vinum these days with DEVFS?
In message <[EMAIL PROTECTED]>, Matthew Jacob writes: > >> Lastly make_dev_alias() is undocumented. Right, just like most of the rest of the kernel. >Really? That's a deficiency. It should be. Yes, ideally, yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>What's up with devfs not gc'ing itself? Ie, after a directory
>becomes empty it seems to still exist within the devfs namespace
>instead of disappearing.
That was a deliberate decision, removing a directory(-inode) which
might have a valid vnode is kind of a nasty thing to attempt.
>Since you guys are in docco mode, you might as well document how one
>detects a devfs system in a running system. There's an example
>in the vinum(8) source:
>
>if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
>devfs_is_active = 1;
>else
>devfs_is_active = 0;
Which is the correct and blessed way to find out.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: swap-backed md-based /tmp to replace mfs-based one
> On Sun, 11 Mar 2001 13:17:58 -0800 (PST)
> David Wolfskill <[EMAIL PROTECTED]> said:
david> Accordingly, I created the following shell script to accomplish a
david> similar objective, based upon the above-mentioned example in the
david> mdconfig man page. At present, I have it sitting in
david> /usr/local/etc/rc.d, which isn't ideal, but I wanted to find out if
david> anyone had better approaches for doing this, suggestions for
david> improvement, or arguments that what I'm trying to do is misguided and
david> shouldn't be done:
I wrote following script obtained from manpage:
#!/bin/sh
mdconfig -a -t swap -s 128M -u 10
disklabel -r -w md10 auto
newfs /dev/md10c
tunefs -n enable /dev/md10c
mount /dev/md10c /tmp
chmod 1777 /tmp
Then, I put diskless_mount="/etc/rc.mount_tmp" into /etc/rc.conf.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
> Matthew Jacob <[EMAIL PROTECTED]> writes: > > > Matthew Jacob <[EMAIL PROTECTED]> writes: > > > > Hmm. Sounds to me more like an argument for requiring devfs if you > > > > use vinum. > > > Not until vinum works equally well with devfs as without it. > > Har har har har har > > Please take your sarcasm and shove it. And get acquainted with the > issue at hand before joining the discussion. I am acquainted with this issue. I actually started it with the subject above. I have been mostly reading the threads. I think you owe me an apology. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
swap-backed md-based /tmp to replace mfs-based one
During the past week, I've been tracking -STABLE (daily) & -CURRENT (about
2 days out of 3) on a new laptop. (More stuff about that in the recent
-mobile archives, for folks who might have an interest.)
Although I realize that there are significant differences between the
FreeBSD mfs vs. the Sun tmpfs, using an mfs-based, swap-backed /tmp has
generally been working well for me over the last 3 years of using FreeBSD.
(I tend to be generous with swap diskspace allocations, which helps.)
And on this laptop, I have 3 different bootable "root" (& associated /usr)
partitions, so I can run -CURRENT, as well as run either of a couple of
-STABLEs. But since I'm running no more than one at a time, it made sense
to me to have the swap space be common to all three environments, and to
make /tmp be swap-backed.
In -STABLE, I merely stuffed an appropriate entry in /etc/fstab, and It
Just Worked. However, based on the example in the mdconfig man page on
-CURRENT, I get the impression that the process is a little more
involved.
Accordingly, I created the following shell script to accomplish a
similar objective, based upon the above-mentioned example in the
mdconfig man page. At present, I have it sitting in
/usr/local/etc/rc.d, which isn't ideal, but I wanted to find out if
anyone had better approaches for doing this, suggestions for
improvement, or arguments that what I'm trying to do is misguided and
shouldn't be done:
#!/bin/sh
size=512M # Plugged directly in to the mdconfig command,
# so use an expression that's compatible with that.
case "$1" in
start)
# Taken from the mdconfig man page, then lightly hacked:
# To create and mount a 128MByte swap backed filesystem on /tmp:
if [ -x /sbin/mdconfig ]; then
/sbin/mdconfig -a -t swap -s $size -u 10 && \
/sbin/disklabel -r -w md10 auto && \
/sbin/newfs /dev/md10c && \
/sbin/tunefs -n enable /dev/md10c && \
/sbin/mount /dev/md10c /tmp && \
/bin/chmod 1777 /tmp && \
exit 0
fi
;;
stop)
dev=`/sbin/mount | /usr/bin/awk '/ \/tmp / {print $1}'` || exit 1
/sbin/umount /tmp && [ -c $dev ] && /sbin/mdconfig -d -u $dev
exit 0
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
;;
esac
exit 2
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob <[EMAIL PROTECTED]> writes: > > Matthew Jacob <[EMAIL PROTECTED]> writes: > > > Hmm. Sounds to me more like an argument for requiring devfs if you > > > use vinum. > > Not until vinum works equally well with devfs as without it. > Har har har har har Please take your sarcasm and shove it. And get acquainted with the issue at hand before joining the discussion. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic trying to play Civillization (with trace, etc.)
Mikhail Teterin <[EMAIL PROTECTED]> writes: > Here is the trace with my attempts to browse through it. If you can, please reproduce the panic on a kernel compiled with the INVARIANTS, INVARIANT_SUPPORT and WITNESS options. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
> Matthew Jacob <[EMAIL PROTECTED]> writes: > > Hmm. Sounds to me more like an argument for requiring devfs if you > > use vinum. > > Not until vinum works equally well with devfs as without it. Har har har har har Almost a Catch-22... "We have to do really wierd things so vinum will work equally well without devfs as with it... so we can, then, remove all the wierd things we did to make vinum work equally well without devfs as with it"... I think what you really meant to say was "No, we won't require devfs". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
I think I'm assuming that DEVFS will become standard. I really see it working very very well and solving lots of problems. I have yet to really find cases where it really *can't* work (modulo broken drivers). > > > Matthew Jacob <[EMAIL PROTECTED]> writes: > > > Hmm. Sounds to me more like an argument for requiring devfs if you > > > use vinum. > > > > Not until vinum works equally well with devfs as without it. > > Har har har har har > > Almost a Catch-22... "We have to do really wierd things so vinum will work > equally well without devfs as with it... so we can, then, remove all the > wierd things we did to make vinum work equally well without devfs as with > it"... > > I think what you really meant to say was "No, we won't require devfs". > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob <[EMAIL PROTECTED]> writes: > Hmm. Sounds to me more like an argument for requiring devfs if you > use vinum. Not until vinum works equally well with devfs as without it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
On 11 Mar 2001, Dag-Erling Smorgrav wrote: > Matthew Jacob <[EMAIL PROTECTED]> writes: > > > Since you guys are in docco mode, you might as well document how one > > > detects a devfs system in a running system. > > Why should you care? > > Because if the system doesn't have devfs, the userland vinum code > needs to create the device nodes "manually". Hmm. Sounds to me more like an argument for requiring devfs if you use vinum. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
Matthew Jacob <[EMAIL PROTECTED]> writes: > > Since you guys are in docco mode, you might as well document how one > > detects a devfs system in a running system. > Why should you care? Because if the system doesn't have devfs, the userland vinum code needs to create the device nodes "manually". DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS (second part)
> Since you guys are in docco mode, you might as well document how one
> detects a devfs system in a running system. There's an example
> in the vinum(8) source:
>
> if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
> devfs_is_active = 1;
> else
> devfs_is_active = 0;
Why should you care? You should be calling make_dev/make_dev_alias/destroy_dev
whether DEVFS is running or not. Why on earth would you want things to be
different? Is it because you see DEVFS as not offering something you can get
w/o it or what
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Alfred Perlstein wrote:
> * Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote:
> > In message <[EMAIL PROTECTED]>, Matthew
>Jacob writes:
> > >
> > >> Lastly make_dev_alias() is undocumented.
> >
> > Right, just like most of the rest of the kernel.
> >
> > >Really? That's a deficiency. It should be.
> >
> > Yes, ideally, yes.
I've updated the man page.
>
> The problem with make_dev_alias() not being documented is that it would
> have been an effort to figure out if duplicate make_dev_alias() calls
> were idempotent, done with refcounts or a good way to panic your
> machine.
...I'm not following this. Too many dime or more expensive words! What you at?
>
> There's also no destroy_dev_alias() that I can see. So when vinum
> goes away I didn't realize how one unpopulates the /dev/vinum/ tree.
The destroy_dev destroys all aliases.
>
> What's up with devfs not gc'ing itself? Ie, after a directory
> becomes empty it seems to still exist within the devfs namespace
> instead of disappearing.
>
> Since you guys are in docco mode, you might as well document how one
> detects a devfs system in a running system. There's an example
> in the vinum(8) source:
>
> if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
> devfs_is_active = 1;
> else
> devfs_is_active = 0;
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Poul-Henning Kamp <[EMAIL PROTECTED]> [010311 12:02] wrote:
> In message <[EMAIL PROTECTED]>, Matthew Jacob
>writes:
> >
> >> Lastly make_dev_alias() is undocumented.
>
> Right, just like most of the rest of the kernel.
>
> >Really? That's a deficiency. It should be.
>
> Yes, ideally, yes.
The problem with make_dev_alias() not being documented is that it would
have been an effort to figure out if duplicate make_dev_alias() calls
were idempotent, done with refcounts or a good way to panic your
machine.
There's also no destroy_dev_alias() that I can see. So when vinum
goes away I didn't realize how one unpopulates the /dev/vinum/ tree.
What's up with devfs not gc'ing itself? Ie, after a directory
becomes empty it seems to still exist within the devfs namespace
instead of disappearing.
Since you guys are in docco mode, you might as well document how one
detects a devfs system in a running system. There's an example
in the vinum(8) source:
if (sysctlbyname("vfs.devfs.generation", NULL, NULL, NULL, 0) == 0)
devfs_is_active = 1;
else
devfs_is_active = 0;
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, 11 Mar 2001, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Matthew Jacob >writes: > > > >> Lastly make_dev_alias() is undocumented. > > Right, just like most of the rest of the kernel. > > >Really? That's a deficiency. It should be. > > Yes, ideally, yes. I'm hacking the man page now.. Feel free to correct the change To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
> Lastly make_dev_alias() is undocumented. Really? That's a deficiency. It should be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [010311 09:02] wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Vinum+DEVFS doesn't make the million symlinks that non-devfs > > vinum does. > > Why not? make_dev_alias() is cheap and easy to use. Take a look at the /dev/vinum tree under devfs and non-devfs systems and you'll understand why I wanted to get rid of the symlinks. Basically, I found them to be distasteful and not worth keeping around. To completely emulate the rats' nest of symlinks I would have had to link to outside disks as well, I really didn't want to do that. Lastly make_dev_alias() is undocumented. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Threaded linux should work again
I fixed the bug in linux_clone() that made caused the 'not SRUN' panics in -CURRENT. Opera, Tivoli and other threaded Linux apps should now work again. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libg2c missing?
Solved! I had NO_FORTRAN=true on master, but not on slave. After I sync'ed the make.conf's, I could install. Leif - Original Message - From: "Leif Neland" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 10, 2001 4:03 PM Subject: libg2c missing? > I've got two machines, called say master and slave. > > Master got the sources, and I do a cvsup and make world almost every > night. > > Occationally (once a month or so, when current is in a not too bad shape) > I mount master:/usr/src and master:/usr/obj on slave, and do an > installworld. > > Now it fails in gnu/lib/libg2c: > install -c -o root -g wheel -m 444 libg2c.a /usr/lib > install: libg2c.a: No such file or directory > *** Error code 71 > > The typescript for make world on master doesn't mention libg2c. > I've got libg2c.a dated feb 8 and libg2c.so.1 dated feb 4 on master, while > the other libs are from tonights buildworld. > > I copied /usr/lib/libg2c* from master to slave, but that didn't do any > difference. > > So the question is: Why will this buildworld, which can installworld on > master, not installworld on slave, which is not that much older? > > Leif > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs
On Sun, 11 Mar 2001 14:13:38 +0100 Andrea Campi <[EMAIL PROTECTED]> wrote: AC> I was about to fill in a doc PR on this but then I thought I'm better off AC> checking other people experiences... A completely different question about growfs - is it fit for -stable ? If so could it be MFC'd (after 4.3 I suppose). -- Life is complex - it has real and imaginary parts. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
Alfred Perlstein <[EMAIL PROTECTED]> writes: > Vinum+DEVFS doesn't make the million symlinks that non-devfs > vinum does. Why not? make_dev_alias() is cheap and easy to use. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT no longer boots
Booting [/boot/kernel/kernel]...
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #51: Sun Mar 11 17:31:08 CET 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/DES
Timecounter "i8254" frequency 1193182 Hz
CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping = 12
Features=0x8021bf
AMD Features=0x8800
real memory = 201310208 (196592K bytes)
avail memory = 191782912 (187288K bytes)
Preloaded elf kernel "kernel" at 0xc03c1000.
K6-family MTRR support enabled (2 registers)
VESA: v2.0, 8192k memory, flags:0x1, mode table:0xc033ffa2 (122)
VESA: Matrox Graphics Inc.
Using $PIR table, 8 entries at 0xc00f0b40
apm0: on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0: on motherboard
npx0: INT 16 interface
pcib0: at pcibus 0 on motherboard
pci0: on pcib0
agp0: mem 0xe000-0xe3ff at device 0.0 on pci0
pcib1: at device 1.0 on pci0
pci1: on pcib1
pci1: at 0.0 (no driver attached)
pci0: at 3.0 (no driver attached)
isab0: at device 7.0 on pci0
isa0: on isab0
xl0: <3Com 3c900-COMBO Etherlink XL> port 0xd800-0xd83f irq 12 at device 11.0 on pci0
xl0: Ethernet address: 00:60:08:cf:a8:e4
xl0: selecting 10baseT transceiver, half duplex
atapci0: port 0xd400-0xd40f irq 0 at device 15.0
on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ed0 at port 0x280-0x29f iomem 0xd8000 irq 5 on isa0
ed0: address 00:20:18:64:9b:b6, type NE2000 (16 bit)
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A, console
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sbc0: at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 7 drq 0,1 on
isa0
pcm0: on sbc0
unknown: can't assign resources
unknown: can't assign resources
sio1: <16550A-compatible COM port> at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
fdc0: at port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0: at port 0x60,0x64 irq 1 on isa0
atkbd0: irq 1 on atkbdc0
unknown: can't assign resources
IP packet filtering initialized, divert disabled, rule-based forwarding disabled,
default to deny, unlimited logging
panic: blockable mtx_lock() of Giant when not legal @ ../../kern/kern_intr.c:503
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c02aab03) at Debugger+0x44
panic(c02a9a60,c02c70b4,c02a7950,1f7,c21c3700) at panic+0x70
witness_enter(c035c2a0,2,c02a7950,1f7) at witness_enter+0x396
ithread_loop(c21c6880,cef07fa8) at ithread_loop+0x266
fork_exit(c0184bf0,c21c6880,cef07fa8) at fork_exit+0xec
fork_trampoline() at fork_trampoline+0x8
db> show mutex
db> show witness
Sleep mutexes:
0 xl0 -- last acquired @ ../../pci/if_xl.c:1241
0 rman -- last acquired @ ../../kern/subr_rman.c:196
0 rman head -- last acquired @ ../../kern/subr_rman.c:107
0 sf_bufs list lock -- last acquired @ ../../kern/uipc_syscalls.c:1437
0 m_ext counter free list lock -- last acquired @ ../../kern/uipc_mbuf.c:216
0 mcluster free list lock -- last acquired @ ../../kern/uipc_mbuf.c:381
0 vm86pcb lock -- last acquired @ ../../i386/i386/vm86.c:579
0 Giant -- last acquired @ ../../kern/kern_mutex.c:835
1 mbuf free list lock -- last acquired @ ../../netinet/igmp.c:108
1 random reseed -- last acquired @ ../../dev/random/yarrow.c:265
1 fork list -- last acquired @ ../../kern/kern_sx.c:138
1 bpf global lock -- last acquired @ ../../net/bpf.c:1221
1 zone subsystem -- last acquired @ ../../vm/vm_zone.c:176
1 eventhandler -- last acquired @ ../../kern/subr_eventhandler.c:76
2 lockmgr interlock -- last acquired @ ../../kern/kern_lock.c:239
3process lock -- last acquired @ ../../kern/kern_lock.c:260
4 ucred -- last acquired @ ../../kern/kern_prot.c:1162
4 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
5 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:781
2 malloc -- last acquired @ ../../kern/kern_malloc.c:157
1 lockmgr -- last acquired @ ../../kern/kern_lock.c:239
1 zone -- last acquired @ ../../vm/vm_zone.c:366
1 proctree -- last acquired @ order list:0
2 allproc -- last acquired @ order list:0
3process lock -- last acquired @ ../../kern/kern_lock.c:260
4 ucred -- last acquired @ ../../kern/kern_prot.c:1162
4 uidinfo hash -- last acquired @ ../../kern/kern_resource.c:745
5 uidinfo struct -- last acquired @ ../../kern/kern_resource.c:781
Spin mutexes:
Mutexes which were never acquired:
arp_inq
ip_inq
lo
ufs ihash
ifsvgt
cd9660_ihash
vnode_free_list
spechash
mntid
mntvnode
mountlist
ed
bpf interface lock
xl
buftime lock
vm object_list
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
panic trying to play Civillization (with trace, etc.)
Hi! All of a sudden I can't play my game :( The new kernels all crash
just trying to start the executable...
Here is the trace with my attempts to browse through it. The bzip2-ed
kernel and vmcore, as well as the /sys subtree are available for
examination at:
http://aldan.algebra.com:8015/~mi/civctp-crash/
The panic-triggering (Linux) binary is also there (civctp). I don't
think you can play the game with it without the data-files and
libraries, so Loki games should not object :) Most probably you will be
able to get the same panic by just trying to run the executable, which
worked just fine with the Feb 22 current-kernel. I link all of the
modules into the kernel.
I can also give an account or two (the machine is on a static-IP DSL
link) to those who wish to take a closer look, but can not reproduce
this locally. Thanks!
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc01de0d0 in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#3 0xc02e8f65 in trap_fatal (frame=0xcf02adc4, eva=0)
at ../../i386/i386/trap.c:987
#4 0xc02e8c99 in trap_pfault (frame=0xcf02adc4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#5 0xc02e858f in trap (frame={tf_fs = -1069744104, tf_es = 16,
tf_ds = -821952496, tf_edi = -822364608, tf_esi = -1069645600,
tf_ebp = -821907952, tf_isp = -821907984, tf_ebx = 0,
tf_edx = -822364608, tf_ecx = 86, tf_eax = 1, tf_trapno = 12,
tf_err = 0, tf_eip = -1071804515, tf_cs = 8, tf_eflags = 65538,
tf_esp = 4, tf_ss = 1}) at ../../i386/i386/trap.c:448
#6 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=4,
file=0xc0324024 "../../kern/kern_shutdown.c", line=258)
at ../../kern/kern_mutex.c:525
#7 0xc01ddde5 in boot (howto=256) at ../../kern/kern_shutdown.c:258
#8 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#9 0xc02e8f65 in trap_fatal (frame=0xcf02aef4, eva=0)
at ../../i386/i386/trap.c:987
#10 0xc02e8c99 in trap_pfault (frame=0xcf02aef4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#11 0xc02e858f in trap (frame={tf_fs = -1051459560, tf_es = 16, tf_ds = 16,
tf_edi = -822364608, tf_esi = -1069645600, tf_ebp = -821907648,
tf_isp = -821907680, tf_ebx = 0, tf_edx = 1, tf_ecx = 598, tf_eax = 598,
tf_trapno = 12, tf_err = 0, tf_eip = -1071804515, tf_cs = 8,
tf_eflags = 65666, tf_esp = -822364608, tf_ss = -1069645600})
at ../../i386/i386/trap.c:448
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
#14 0xc02d705d in syscall_with_err_pushed ()
#15 0x8461eab in ?? ()
#16 0x83e012f in ?? ()
#17 0x83dfeeb in ?? ()
#18 0x81be0df in ?? ()
#19 0x81aa7c9 in ?? ()
#20 0x804b271 in ?? ()
#21 0x84b2f66 in ?? ()
#22 0x80480de in ?? ()
#23 0x846dc94 in ?? ()
(kgdb) up 12
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
(kgdb) p m
$1 = (struct mtx *) 0xc03e80e0
(kgdb) p *m
$2 = {mtx_lock = 3472602691, mtx_recurse = 1, mtx_saveintr = 0, mtx_flags = 2,
mtx_description = 0xc0341df9 "Giant", mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xcefbd400}, mtx_contested = {le_next = 0xc03e80e0,
le_prev = 0xcefbb7e0}, mtx_next = 0xc03dae60, mtx_prev = 0xc03e82a0,
mtx_debug = 0x0}
(kgdb) p m->mtx_blocked
$3 = {tqh_first = 0x0, tqh_last = 0xcefbd400}
(kgdb) l
520
521 mtx_lock_spin(&sched_lock);
522 if ((opts & MTX_QUIET) == 0)
523 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
524
525 p1 = TAILQ_FIRST(&m->mtx_blocked);
526 MPASS(p->p_magic == P_MAGIC);
527 MPASS(p1->p_magic == P_MAGIC);
528
529 TAILQ_REMOVE(&m->mtx_blocked, p1, p_procq);
(kgdb) up
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
1247mtx_unlock(&Giant);
(kgdb) l
1242
1243/*
1244 * Release Giant if we had to get it
Re: make installworld 'kinda' broken in perl
On Sun, 11 Mar 2001, Julian Elischer wrote: > I often do 'make buildworld' on one machine > and on many other machines I do: > mount -r /usr/src > mount -r /usr/obj > > through nfs so I can do a 'make installworld' > using the prebuilt system. > > Unfortunatly the perl distribution is trying to write > back to /usr/obj or /usr/src. > > it is the only place that does this. And it's new becasue > I've done this in the past. > > here's the error: > ===> gnu/usr.bin/perl/library/SDBM_File > cd sdbm && make all > rm -rf libsdbm.a<- why does it try to do this? > surely it should have been done in the > 'buildworld' phase. I'm not sure if > it's trying to rm in /usr/obj or /usr/src, > but either way, it's wrong.. > > > rm: libsdbm.a: Read-only file system > *** Error code 1 (continuing) > `all' not remade because of errors. This is an old bug: >From [EMAIL PROTECTED] Mon Nov 6 03:05:35 2000 +1100 Date: Mon, 6 Nov 2000 03:05:31 +1100 (EST) From: Bruce Evans <[EMAIL PROTECTED]> X-Sender: [EMAIL PROTECTED] To: Don Lewis <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], Steven Farmer <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: installworld failure - libsdbm.a In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: O X-Status: X-Keywords: X-UID: 1357 On Sun, 5 Nov 2000, Don Lewis wrote: > On Nov 4, 11:54am, Kent Stewart wrote: > } Subject: Re: installworld failure - libsdbm.a > } > } > } Steven Farmer wrote: > } > > } > After this morning's cvsup and buildworld, installworld failed trying > } > to build libsdbm.a. I worked around the problem by adding chmod to > } > Makefile.inc1 as shown below. BTW - isn't it kind of wierd for a > } > library to be _built_ at installworld time? > } > } Yes, it is. It is supposed to be build in buildworld where is also > } chmod'ed appropriately. Something triggers the build during > } installworld, which is a place they don't want to add chmod to. I have > } had it hit me once. > > I had the same thing happen to me yesterday abuse six hours into > a -current "make release". The problem didn't recur when I reran > "make release". One possible quirk is that I am mounting the scratch > area from a 4.1-stable NFS server. Notice that only the .a file is > getting built, and not the .o files. I suspect that the file > timestamps are getting messed up, causing make to rebuild the .a > file. That is another bug. The main bug is that the perl install looks at timestamps (install targets shouldn't depend on anything). > } > ===> gnu/usr.bin/perl/library/SDBM_File > } > cd /usr/obj/usr/src/gnu/usr.bin/perl/library/SDBM_File/ext/SDBM_File ; make -B >install INSTALLPRIVLIB=/usr/libdata/perl/5.00503 >INSTALLARCHLIB=/usr/libdata/perl/5.00503/mach This is from gnu/usr.bin/perl/library/SDBM_File/../Makefile.inc. No problems yet. > } > cd sdbm && make all This is from the automatically generated Makefile in the obj directory. This Makefile is nothing like a BSD makefile and has bugs like: install :: all pure_install doc_install This causes things to be built at install time if they are out of date. > } > rm -rf libsdbm.a > } > ar cr libsdbm.a sdbm.o pair.o hash.o && : libsdbm.a > } > chmod 755 libsdbm.a > } > chmod:No such file or directory > } > *** Error code 1 Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
growfs
I was about to fill in a doc PR on this but then I thought I'm better off checking other people experiences... I just used growfs on my / filesystem, after shrinking the swap partition which just happened to be after it. I had to do nothing magic beside dropping to single user so as to have a ro /. This is in contrast to what the man page says: system on the specified special file. Currently growfs can only grow un- mounted file systems. Do not try growing a mounted file system, your system may panic and you will not be able to use the file system any longer. Most of the options you have used with newfs(8) once can not be changed. In fact you can only increase the size of the file system. Use Is this just extra paranoia or was I very lucky? Do we need to fix the doc? Bye, Andrea -- Yes, I've heard of "decaf." What's your point? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
* Niels Chr. Bank-Pedersen <[EMAIL PROTECTED]> [010311 02:29] wrote: > > I'll sneak in my experience with DEVFS+vinum here as well: > > vinum: loaded > vinum: reading configuration from /dev/da3s1f > vinum: updating configuration from /dev/da1s1e > vinum: updating configuration from /dev/da2s1e > vinum: updating configuration from /dev/da0s1e > swapon: adding /dev/da1s1b as swap device > swapon: adding /dev/da2s1b as swap device > Automatic boot in progress... > /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS > /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation) > Can't stat /dev/vinum/raid01: No such file or directory > Can't stat /dev/vinum/raid01: No such file or directory > /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM. > /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > > This was with a -current from around March 1. (don't think > anything has changed since). Booting a non-DEVFS kernel > passes the fs-check and works as expected. Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make installworld 'kinda' broken in perl
I often do 'make buildworld' on one machine and on many other machines I do: mount -r /usr/src mount -r /usr/obj through nfs so I can do a 'make installworld' using the prebuilt system. Unfortunatly the perl distribution is trying to write back to /usr/obj or /usr/src. it is the only place that does this. And it's new becasue I've done this in the past. here's the error: ===> gnu/usr.bin/perl/library/SDBM_File cd sdbm && make all rm -rf libsdbm.a<- why does it try to do this? surely it should have been done in the 'buildworld' phase. I'm not sure if it's trying to rm in /usr/obj or /usr/src, but either way, it's wrong.. rm: libsdbm.a: Read-only file system *** Error code 1 (continuing) `all' not remade because of errors. rm -rf libsdbm.a rm: libsdbm.a: Read-only file system *** Error code 1 (continuing) `all' not remade because of errors. Installing /usr/libdata/perl/5.6.0/mach/SDBM_File.pm Installing /usr/libdata/perl/5.6.0/mach/auto/sdbm/extralibs.ld Installing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/SDBM_File.so Installing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/SDBM_File.bs Writing /usr/libdata/perl/5.6.0/mach/auto/SDBM_File/.packlist Appending installation info to /usr/libdata/perl/5.6.0/mach/perllocal.pod ===> gnu/usr.bin/perl/library/Socket -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sun, Mar 11, 2001 at 12:03:34AM -0800, Matthew Jacob wrote:
>
>
> On Sun, 11 Mar 2001, Greg Lehey wrote:
>
> > On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
> > > (top of tree within the last day or so):
> > >
> > > Things seem *almost* okay, but:
> > >
> > > nellie.feral.com > root vinum
> > > vinum -> stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
> > > /dev/da9a /dev/da10a /dev/da11a /dev/da12a
> > > drive vinumdrive0 device /dev/da3a
> > >
> > > Can't get config for plex 0: Invalid argument
> > >
> > > and at the console:
> > >
> > > WARNING: Driver mistake: repeat make_dev("vinum/control")
> >
> > Hmm.
> >
> > > Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from
>process 682 (vinum): c1384644
> >
> > This looks like a mismatch between the plex size in the userland and
> > kernel code. Did you rebuild vinum(8)?
>
> Complete fresh build, top of tree... I'll try again...
I'll sneak in my experience with DEVFS+vinum here as well:
vinum: loaded
vinum: reading configuration from /dev/da3s1f
vinum: updating configuration from /dev/da1s1e
vinum: updating configuration from /dev/da2s1e
vinum: updating configuration from /dev/da0s1e
swapon: adding /dev/da1s1b as swap device
swapon: adding /dev/da2s1b as swap device
Automatic boot in progress...
/dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS
/dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation)
Can't stat /dev/vinum/raid01: No such file or directory
Can't stat /dev/vinum/raid01: No such file or directory
/dev/vinum/raid01: CAN'T CHECK FILE SYSTEM.
/dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
This was with a -current from around March 1. (don't think
anything has changed since). Booting a non-DEVFS kernel
passes the fs-check and works as expected.
/Niels Chr.
--
Niels Christian Bank-Pedersen, NCB1-RIPE.
Network Manager, Tele Danmark NET, IP-section.
"Hey, are any of you guys out there actually *using* RFC 2549?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
On Sat, 10 Mar 2001, David O'Brien wrote: > On Fri, Mar 09, 2001 at 01:39:58PM -0800, Matthew Jacob wrote: > > > Erm, just so you know. The 4100 here at WC doesn't even make it past > > > the SCSI probe due to interrupt issues. > > > > Hmm. Well, it *was* working a couple of days ago :-) > > Uh, actually _your_ 4100 is the only I've ever known to work on > post-SMPng. The WC 4100 has *never* worked on post SMPng. I don't > believe I've heard that DFR's runs SMPng either. > > I guess I should get a `dd' of your system disk, or get you a console on > the WC box. My 4100 was working after the last set of mcpcia fixes. I haven't updated it for about a week so it may be broken again I guess. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unsubscribe daniel@everad.com
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
