From owner-freebsd-current Sun Aug 20 1:33: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from mnw.eas.slu.edu (mnw.eas.slu.edu [165.134.8.248]) by hub.freebsd.org (Postfix) with ESMTP id 2FF4537B424 for ; Sun, 20 Aug 2000 01:32:58 -0700 (PDT) Received: from ejhslu.eas.slu.edu (ejhslu.eas.slu.edu [165.134.8.243]) by mnw.eas.slu.edu (8.10.1/8.10.1) with ESMTP id e7K8WgJ11200 for ; Sun, 20 Aug 2000 03:32:42 -0500 (CDT) Received: (from ejh@localhost) by ejhslu.eas.slu.edu (8.9.3+Sun/8.9.3) id DAA29779 for current@freebsd.org; Sun, 20 Aug 2000 03:32:41 -0500 (CDT) Date: Sun, 20 Aug 2000 03:32:41 -0500 (CDT) From: "Eric J. Haug" Message-Id: <200008200832.DAA29779@ejhslu.eas.slu.edu> To: current@freebsd.org Subject: problems with make release Aug 18 sources Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sigh, In my attempt to make a cdrom to install 5.0-CURRENT-20000818 I stumbled across a problem with the fixit floppy. The /dev/MAKEDEV acd0 created 209 entries. The fixit floppy only starts out with some 382. So the fixit floppy fails to be properly populated with executables. Tar does not deal with the minor number of these entries either. tar: acd0t32: minor number too large; not dumped I suspect that not creating all 99 of the track specific devices or removing them after creating them would work around both problems. eric haug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 14: 2:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 6D30C37B422 for ; Sun, 20 Aug 2000 14:02:42 -0700 (PDT) Received: from kilt.nothing-going-on.org (root@kilt.nothing-going-on.org [192.168.1.18]) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) with ESMTP id VAA52348; Sun, 20 Aug 2000 21:40:27 +0100 (BST) (envelope-from nik@catkin.nothing-going-on.org) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id MAA02341; Sun, 20 Aug 2000 12:14:19 GMT (envelope-from nik) Date: Sun, 20 Aug 2000 12:14:05 +0000 From: Nik Clayton To: Jason Evans Cc: current@freebsd.org Subject: Re: HEADS UP: Destabilization due to SMP development Message-ID: <20000820121405.A2298@kilt.nothing-going-on.org> References: <20000619115330.D79318@blitz.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000619115330.D79318@blitz.canonware.com>; from jasone@canonware.com on Mon, Jun 19, 2000 at 11:53:30AM -0700 Organization: FreeBSD Project Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote: > Summary: -current will be destabilized for an extended period (on the order > of months). A tag (not a branch) will be laid down before the initial > checkin, and non-developers should either stick closely to that tag until > the kernel stabilizes, or expect large doses of pain. This tag will be > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning > beforehand. Is there any news on this work? Unless I've missed the significance of recent commits, I haven't seen anything approaching this sort of destabilisation in -current. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 14:44:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.32.208]) by hub.freebsd.org (Postfix) with ESMTP id 937A637B422 for ; Sun, 20 Aug 2000 14:44:39 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id XAA90392 for ; Sun, 20 Aug 2000 23:44:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/bktr bktr_os.c src/sys/dev/md md.c src/sys/fs/devfs devfs.h devfs_devs.c devfs_vfsops.c devfs_vnops.c src/sys/i386/conf GENERIC src/sys/i4b/driver i4b_ctl.c i4b_rbch.c i4b_tel.c i4b_trace.c ... In-Reply-To: Your message of "Sun, 20 Aug 2000 14:34:39 PDT." <200008202134.OAA42108@freefall.freebsd.org> Date: Sun, 20 Aug 2000 23:44:38 +0200 Message-ID: <90390.966807878@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok gang, time to test DEVFS in real life! Put option DEVFS in your kernel configs, and tell me if it works and if it doesnt give me all the details you can in private emails. The outstanding issues right now are these: Subdirs are not fully implemented. vinum will not work use fdescfs if you need /dev/fd/%d Rename is not implemented. For now there is a hardcoded upper limit of 1024 device "lives" right now. This might affect pccard/usb users after some time. Some races may exist, I need to add specific atomicity to certain operations to close these holes. Mount rdonly meaning "no new devices" is not yet implemented. Apart from this, I think a lot of "normal" machines will run happily with this DEVFS. If your favourite driver is not showing up in /dev, it's most likely because the driver doesn't do the right thing with make_dev(). Bug the maintainer before you bug me. isa/fd.c is probably the most interesting file to examine for people looking for advanced interfacing with DEVFS from device drivers. Try this: ls -l /dev/fd* ls -l /dev/fd0a ls -l /dev/fd0.1200 ls -l /dev/fd* Have fun, Sorry it's taken so long to get to here... Poul-Henning In message <200008202134.OAA42108@freefall.freebsd.org>, Poul-Henning Kamp writ es: >phk 2000/08/20 14:34:39 PDT > > Modified files: > sys/conf files > sys/dev/bktr bktr_os.c > sys/dev/md md.c > sys/i386/conf GENERIC > sys/i4b/driver i4b_ctl.c i4b_rbch.c i4b_tel.c > i4b_trace.c > sys/i4b/layer4 i4b_i4bdrv.c > sys/isa fd.c > sys/kern init_main.c kern_conf.c subr_disk.c > subr_diskslice.c tty_pty.c > sys/net bpf.c if_tun.c > sys/sys conf.h kernel.h > sys/ufs/mfs mfs_vfsops.c > Added files: > sys/fs/devfs devfs.h devfs_devs.c devfs_vfsops.c > devfs_vnops.c > Removed files: > sys/miscfs/devfs README devfs_proto.h devfs_tree.c > devfs_vfsops.c devfs_vnops.c devfsdefs.h > reproto.sh > sys/sys devfsext.h > Log: > Remove all traces of Julians DEVFS (incl from kern/subr_diskslice.c) > > Remove old DEVFS support fields from dev_t. > > Make uid, gid & mode members of dev_t and set them in make_dev(). > > Use correct uid, gid & mode in make_dev in disk minilayer. > > Add support for registering alias names for a dev_t using the > new function make_dev_alias(). These will show up as symlinks > in DEVFS. > > Use makedev() rather than make_dev() for MFSs magic devices to prevent > DEVFS from noticing this abuse. > > Add a field for DEVFS inode number in dev_t. > > Add new DEVFS in fs/devfs. > > Add devfs cloning to: > disk minilayer (ie: ad(4), sd(4), cd(4) etc etc) > md(4), tun(4), bpf(4), fd(4) > > If DEVFS add -d flag to /sbin/inits args to make it mount devfs. > > Add commented out DEVFS to GENERIC -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 21:37:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 1C7E237B424; Sun, 20 Aug 2000 21:37:18 -0700 (PDT) Received: (from jhb@localhost) by pike.osd.bsdi.com (8.9.3/8.9.3) id VAA84092; Sun, 20 Aug 2000 21:36:57 -0700 (PDT) (envelope-from jhb) From: John Baldwin Message-Id: <200008210436.VAA84092@pike.osd.bsdi.com> Subject: Re: HEADS UP: Destabilization due to SMP development In-Reply-To: <20000820121405.A2298@kilt.nothing-going-on.org> from Nik Clayton at "Aug 20, 2000 12:14:05 pm" To: Nik Clayton Date: Sun, 20 Aug 2000 21:36:57 -0700 (PDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nik Clayton wrote: > On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote: > > Summary: -current will be destabilized for an extended period (on the order > > of months). A tag (not a branch) will be laid down before the initial > > checkin, and non-developers should either stick closely to that tag until > > the kernel stabilizes, or expect large doses of pain. This tag will be > > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning > > beforehand. > > Is there any news on this work? Unless I've missed the significance of > recent commits, I haven't seen anything approaching this sort of > destabilisation in -current. It's not all that unstable actually. Well, it currently panics an SMP box within minutes of starting a make world, but single processor seems to be relatively stable. You can get more info at http://www.freebsd.org/~jasone/smp/. > N > -- > Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. > Telephone line, $24.95 a month. Software, free. USENET transmission, > hundreds if not thousands of dollars. Thinking before posting, priceless. > Somethings in life you can't buy. For everything else, there's MasterCard. > -- Graham Reed, in the Scary Devil Monastery -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 22:25:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id D676A37B424 for ; Sun, 20 Aug 2000 22:25:18 -0700 (PDT) Received: (qmail 99194 invoked by uid 1142); 21 Aug 2000 05:25:13 -0000 Date: 20 Aug 2000 22:25:13 -0700 Date: Sun, 20 Aug 2000 22:22:44 -0700 From: Jason Evans To: Nik Clayton Cc: current@freebsd.org Subject: Re: HEADS UP: Destabilization due to SMP development Message-ID: <20000820222244.O14875@blitz.canonware.com> References: <20000619115330.D79318@blitz.canonware.com> <20000820121405.A2298@kilt.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000820121405.A2298@kilt.nothing-going-on.org>; from nik@freebsd.org on Sun, Aug 20, 2000 at 12:14:05PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Aug 20, 2000 at 12:14:05PM +0000, Nik Clayton wrote: > On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote: > > Summary: -current will be destabilized for an extended period (on the order > > of months). A tag (not a branch) will be laid down before the initial > > checkin, and non-developers should either stick closely to that tag until > > the kernel stabilizes, or expect large doses of pain. This tag will be > > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning > > beforehand. > > Is there any news on this work? Unless I've missed the significance of > recent commits, I haven't seen anything approaching this sort of > destabilisation in -current. No, there has not been a commit yet, but we're quite close at this point to making one. Chances are good that this will happen within the next two weeks. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 23:30:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from ego.mind.net (ego.mind.net [206.99.66.9]) by hub.freebsd.org (Postfix) with ESMTP id 85D8E37B43E for ; Sun, 20 Aug 2000 23:30:26 -0700 (PDT) Received: from takhus-home.ashlandfn.org (AFN-Dynamic-21924.ashlandfiber.net [208.46.219.24]) by ego.mind.net (8.9.3/8.9.3) with ESMTP id XAA16091; Sun, 20 Aug 2000 23:30:24 -0700 Received: from localhost (fleisher@localhost) by takhus-home.ashlandfn.org (8.11.0/8.9.3) with ESMTP id e7L6UOS14944; Sun, 20 Aug 2000 23:30:24 -0700 (PDT) (envelope-from takhus@takhus.mind.net) Date: Sun, 20 Aug 2000 23:30:24 -0700 (PDT) From: Tony Fleisher X-Sender: fleisher@takhus-home.ashlandfn.org To: Poul-Henning Kamp Cc: current@FreeBSD.ORG In-Reply-To: <90390.966807878@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Not sure if this is related to the recent commit of DEVFS code, but a build of both the GERNERIC kernel and a custom kernel from a very recent (last few hours) cvsup of -current failed during the 'make depend' with an error trying to include "opt_devfs.h". The following following is the ouput from a custom kernel (/usr/local/src/freebsd/src is the base of my src): ===> md @ -> /usr/local/src/freebsd/src/sys machine -> /usr/local/src/freebsd/src/sys/i386/include touch opt_mfs.h touch opt_md.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/include /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/local/src/freebsd/src/sys/modules/md. *** Error code 1 Commenting out the line: #include "opt_devfs.h" from src/sys/dev/md/md.c got rid of this error, although I am not sure that this is the correct fix. Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Aug 20 23:45:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9A82237B422 for ; Sun, 20 Aug 2000 23:45:39 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA01904; Sun, 20 Aug 2000 23:41:32 -0700 Date: Sun, 20 Aug 2000 23:41:30 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Tony Fleisher Cc: Poul-Henning Kamp , current@FreeBSD.ORG Subject: Re: your mail In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Already told him. It is. On Sun, 20 Aug 2000, Tony Fleisher wrote: > Not sure if this is related to the recent commit of DEVFS code, but a > build of both the GERNERIC kernel and a custom kernel from a very recent > (last few hours) cvsup of -current failed during the 'make depend' with > an error trying to include "opt_devfs.h". > The following following is the ouput from a custom kernel > (/usr/local/src/freebsd/src is the base of my src): > > ===> md > @ -> /usr/local/src/freebsd/src/sys > machine -> /usr/local/src/freebsd/src/sys/i386/include > touch opt_mfs.h > touch opt_md.h > rm -f .depend > mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ > -I@/../includ > e -I/usr/include > /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c > /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No > such file or directory > mkdep: compile failed > *** Error code 1 > Stop in /usr/local/src/freebsd/src/sys/modules/md. > *** Error code 1 > > > Commenting out the line: #include "opt_devfs.h" from > src/sys/dev/md/md.c got rid of this error, although > I am not sure that this is the correct fix. > > Tony. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 0: 1:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from lamborghini.indocyber.com (lamborghini.indocyber.com [202.180.0.86]) by hub.freebsd.org (Postfix) with SMTP id 159F937B43C for ; Mon, 21 Aug 2000 00:01:05 -0700 (PDT) Received: (qmail 1482 invoked from network); 21 Aug 2000 07:00:21 -0000 Received: from unknown (HELO maverick.indocyber.com) (202.155.43.94) by lamborghini.indocyber.com with SMTP; 21 Aug 2000 07:00:21 -0000 Received: (qmail 29987 invoked by uid 1000); 21 Aug 2000 06:59:52 -0000 Date: Mon, 21 Aug 2000 13:59:52 +0700 From: John Indra To: current@freebsd.org Subject: Sound support in -CURRENT Message-ID: <20000821135952.A68790@indocyber.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: Mutt 1.2.5i on FreeBSD 4.1-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi FreeBSD fans and developers... This is my first question in -CURRENT. Yesterday was the first time I tried to follow the -STABLE line. And I must admit that once again FreeBSD amazed me ;) Running -STABLE rite now (I used to run only -RELEASE before cause I'm haunted by the feeling that the upgrading process will be very complicated, but that's my mistake... The upgrading process was really simple and easy... ;) ) Now to the real question... I have a Compaq Deskpro EP system with onboard Intel 810e AGP VGA Card and onboard sound support (which maybe is AC97 or something similar). After running -STABLE I can use my VGA Card. How about the sound card? Does - -CURRENT support the sound card? Cause if -CURRENT can make my sound card sings, I'd love to give it a try. After all, this isn't a production machine. Regards, John Indra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (FreeBSD) Comment: Be the best! iD8DBQE5oNNhxcp0HIxafmQRAnm/AJsH99EctqjU2YukF3o0PfOIxNAx4ACgvmx0 YhugvQc/j2TtVcbHRvi6zrk= =wwoJ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 0: 4:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id 4F0DF37B42C for ; Mon, 21 Aug 2000 00:04:52 -0700 (PDT) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.0/8.9.3) id e7L74jm00251; Mon, 21 Aug 2000 14:04:45 +0700 (NOVST) (envelope-from nnd) Date: Mon, 21 Aug 2000 14:04:45 +0700 (NOVST) Message-Id: <200008210704.e7L74jm00251@wint.itfs.nsk.su> From: Nickolay Dudorov To: current@freebsd.org Subject: Re: none In-Reply-To: X-Newsgroups: itfs.freebsd.current User-Agent: tin/1.5.6-20000803 ("Dust") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you wrote: > Not sure if this is related to the recent commit of DEVFS code, but a > build of both the GERNERIC kernel and a custom kernel from a very recent > (last few hours) cvsup of -current failed during the 'make depend' with > an error trying to include "opt_devfs.h". ..... > Commenting out the line: #include "opt_devfs.h" from > src/sys/dev/md/md.c got rid of this error, although > I am not sure that this is the correct fix. I can successfully {build,install}kernel (without DEVFS option configured) with the next patch: N.Dudorov Index: src/sys/modules/md/Makefile =================================================================== RCS file: /store/CVS/src/sys/modules/md/Makefile,v retrieving revision 1.5 diff -r1.5 Makefile 5c5 < SRCS= md.c opt_mfs.h opt_md.h --- > SRCS= md.c opt_mfs.h opt_md.h opt_devfs.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 0:53:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id 8574237B422 for ; Mon, 21 Aug 2000 00:53:12 -0700 (PDT) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.0/8.9.3) id e7L7rBw00311; Mon, 21 Aug 2000 14:53:11 +0700 (NOVST) (envelope-from nnd) Date: Mon, 21 Aug 2000 14:53:11 +0700 (NOVST) Message-Id: <200008210753.e7L7rBw00311@wint.itfs.nsk.su> From: Nickolay Dudorov To: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/modules/md opt_devfs.h Makefile In-Reply-To: <200008210745.AAA13051@freefall.freebsd.org> X-Newsgroups: itfs.freebsd.cvs.all User-Agent: tin/1.5.6-20000803 ("Dust") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200008210745.AAA13051@freefall.freebsd.org> you wrote: > phk 2000/08/21 00:45:38 PDT > > Modified files: > sys/modules/md Makefile > Added files: > sys/modules/md opt_devfs.h > Log: > Add dummy opt_devfs.h file. It seems to me that my patch is better ;-) N.Dudorov Index: src/sys/modules/md/Makefile =================================================================== RCS file: /store/CVS/src/sys/modules/md/Makefile,v retrieving revision 1.5 diff -r1.5 Makefile 5c5 < SRCS= md.c opt_mfs.h opt_md.h --- > SRCS= md.c opt_mfs.h opt_md.h opt_devfs.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 1:32:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from rgz.ru (mail.rgz.ru [213.184.140.100]) by hub.freebsd.org (Postfix) with ESMTP id 451E937B423 for ; Mon, 21 Aug 2000 01:32:52 -0700 (PDT) Received: (from lg@localhost) by rgz.ru (8.9.3/8.9.3) id MAA01513 for current@freebsd.org; Mon, 21 Aug 2000 12:31:51 GMT (envelope-from lg) From: Zajcev Evgeny Message-Id: <200008211231.MAA01513@rgz.ru> Subject: sysinstall trouble To: current@freebsd.org Date: Mon, 21 Aug 2000 12:31:16 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have trouble with sysinstall while installing bin destribution, sysinstall said Write failure on transfer ! wrote -1 bytes of 234567 bytes. i install from cdrom in single mode i DO mount / with wr mode! -- zev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 2:39: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from ockle.dev.nanoteq.co.za (ockle.dev.nanoteq.co.za [196.7.114.28]) by hub.freebsd.org (Postfix) with ESMTP id 4380537B422 for ; Mon, 21 Aug 2000 02:39:01 -0700 (PDT) Received: (from johan@localhost) by ockle.dev.nanoteq.co.za (8.9.3/8.9.3) id LAA27222; Mon, 21 Aug 2000 11:37:16 +0200 (SAST) (envelope-from johan) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200008211231.MAA01513@rgz.ru> Date: Mon, 21 Aug 2000 11:37:16 +0200 (SAST) Organization: Nanoteq From: Johan Kruger To: Zajcev Evgeny Subject: RE: sysinstall trouble Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you sure it's writable, try touching a file on the filesystem. mount -w /dev/ad0s1 / P.S. Before you mount it, do a fsck on it, whether it's clean or not, and then mount it. Hope it helps ... Good luck On 21-Aug-00 Zajcev Evgeny wrote: > I have trouble with sysinstall > while installing bin destribution, sysinstall said > > Write failure on transfer ! wrote -1 bytes of 234567 bytes. > > i install from cdrom in single mode > i DO mount / with wr mode! > -- > zev > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message ---------------------------------- Unix Software Developer/Engineer E-Mail: Johan Kruger Date: 21-Aug-00 Time: 11:34:36 All good things come to those who ... runs FreeBSD ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 3: 7:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2DA4F37B42C; Mon, 21 Aug 2000 03:07:25 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.9.3/1.13) id NAA98503; Mon, 21 Aug 2000 13:04:48 +0300 (EEST) Date: Mon, 21 Aug 2000 13:04:46 +0300 From: Ruslan Ermilov To: John Indra Cc: current@freebsd.org, Dan Moschuk Subject: Re: Sound support in -CURRENT Message-ID: <20000821130446.E91965@sunbay.com> Mail-Followup-To: John Indra , current@freebsd.org, Dan Moschuk References: <20000821135952.A68790@indocyber.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000821135952.A68790@indocyber.com>; from john@indocyber.com on Mon, Aug 21, 2000 at 01:59:52PM +0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 01:59:52PM +0700, John Indra wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi FreeBSD fans and developers... > > This is my first question in -CURRENT. > > Yesterday was the first time I tried to follow the -STABLE line. And I must > admit that once again FreeBSD amazed me ;) > > Running -STABLE rite now (I used to run only -RELEASE before cause I'm > haunted by the feeling that the upgrading process will be very complicated, > but that's my mistake... The upgrading process was really simple and easy... > ;) ) > > Now to the real question... > I have a Compaq Deskpro EP system with onboard Intel 810e AGP VGA Card and > onboard sound support (which maybe is AC97 or something similar). After > running -STABLE I can use my VGA Card. How about the sound card? Does > - -CURRENT support the sound card? Cause if -CURRENT can make my sound card > sings, I'd love to give it a try. After all, this isn't a production > machine. > Not yet. Dan Moschuk is working (?) on the driver. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 9: 2: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom1-182.telepath.com [216.14.1.182]) by hub.freebsd.org (Postfix) with SMTP id 8FBD237B424 for ; Mon, 21 Aug 2000 09:02:07 -0700 (PDT) Received: (qmail 50911 invoked by uid 100); 21 Aug 2000 15:54:49 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.20681.165961.352066@guru.mired.org> Date: Mon, 21 Aug 2000 10:54:49 -0500 (CDT) To: current@freebsd.org Subject: Why no CDR ioctls for SCSI cds? X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm curious - is there some reason that the CDR ioctls (in /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like doing them for MMC would be straightforward, it's the kind of thing that an OS is supposed to do, and it would allow people with MMC drives to cdrecord for the much (much, *much*) smaller burncd. Thanx, ; Mon, 21 Aug 2000 09:41:17 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA68036; Mon, 21 Aug 2000 10:41:15 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 10:41:15 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821104114.A67935@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.20681.165961.352066@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 10:54:49AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote: > I'm curious - is there some reason that the CDR ioctls (in > /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like > doing them for MMC would be straightforward, it's the kind of thing > that an OS is supposed to do, and it would allow people with MMC > drives to cdrecord for the much (much, *much*) smaller burncd. Well, doing that sort of thing for MMC-compliant CD-Rs will open the door to doing it for all CD-Rs. We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM supported with the cd(4) driver..." cdrecord supports a much wider variety of drives out of the box, it is actively supported, and it works. If we put all of cdrecord's functionality into the kernel and burncd, it would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck with maintaining it.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 9:53:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 027CB37B422 for ; Mon, 21 Aug 2000 09:53:50 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA06102 for ; Mon, 21 Aug 2000 09:53:49 -0700 (PDT) Date: Mon, 21 Aug 2000 09:53:49 -0700 (PDT) From: Julian Elischer To: current@freebsd.org Subject: how to set flags on sio2? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG since config has changed.. where do I set the flags on my debug port (sio2?) the sio man page has no hints.. it looks to me as it if is now controlled differently unles I've made a mistake.... julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10: 7: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from usamail.texasonline.net (texasonline.net [208.207.16.31]) by hub.freebsd.org (Postfix) with ESMTP id 16D6C37B424 for ; Mon, 21 Aug 2000 10:07:01 -0700 (PDT) Received: from radius (unverified [209.211.36.192]) by usamail.texasonline.net (Vircom SMTPRS 4.2.181) with ESMTP id for ; Mon, 21 Aug 2000 12:07:00 -0500 Message-ID: <200008211205530812.0DA63AC7@texasonline.net> In-Reply-To: References: X-Mailer: Calypso Version 3.00.03.02 (1) Date: Mon, 21 Aug 2000 12:05:53 -0500 Reply-To: gzeigler@texasonline.net From: "Gordon Zeigler" To: current@freebsd.org Subject: Question from a neophyte... Why isn't rc.local being read? Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've added startup commands to /etc/rc.local on my 3.4 Stable machine. /usr/local/etc/webmin/start # Start webmin /usr/local/sbin/sshd # Start open ssh /etc/init.d/apachectl start # Start apache web server Yet, these are not starting at reboot... What am I missing? Probably something obvious, but it escapes me... *********** REPLY SEPARATOR *********** On 8/21/00 at 9:53 AM Julian Elischer wrote: >since config has changed.. where do I set the flags on my debug port >(sio2?) >the sio man page has no hints.. >it looks to me as it if is now controlled differently >unles I've made a mistake.... > > >julian > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10:10:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id CFC4D37B42C for ; Mon, 21 Aug 2000 10:10:23 -0700 (PDT) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id NAA96546; Mon, 21 Aug 2000 13:10:22 -0400 (EDT) (envelope-from mwlucas) From: Michael Lucas Message-Id: <200008211710.NAA96546@blackhelicopters.org> Subject: Re: Question from a neophyte... Why isn't rc.local being read? In-Reply-To: <200008211205530812.0DA63AC7@texasonline.net> from Gordon Zeigler at "Aug 21, 2000 12: 5:53 pm" To: gzeigler@texasonline.net Date: Mon, 21 Aug 2000 13:10:22 -0400 (EDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gordon, This sort of question is better suited to freebsd-questions@freebsd.org than current@freebsd.org. In the future, please ask there first. rc.local is deprecated. Drop a shell script in /usr/local/etc/rc.d ==ml The short answer > I've added startup commands to /etc/rc.local on my 3.4 Stable machine. > > /usr/local/etc/webmin/start # Start webmin > /usr/local/sbin/sshd # Start open ssh > /etc/init.d/apachectl start # Start apache web server > > Yet, these are not starting at reboot... > > What am I missing? Probably something obvious, but it escapes me... > > > > *********** REPLY SEPARATOR *********** > > On 8/21/00 at 9:53 AM Julian Elischer wrote: > > >since config has changed.. where do I set the flags on my debug port > >(sio2?) > >the sio man page has no hints.. > >it looks to me as it if is now controlled differently > >unles I've made a mistake.... > > > > > >julian > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-current" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10:13:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from cepheus.azstarnet.com (cepheus.azstarnet.com [169.197.56.195]) by hub.freebsd.org (Postfix) with ESMTP id 2A22A37B424 for ; Mon, 21 Aug 2000 10:13:32 -0700 (PDT) Received: from full.planing.jibe (dialup19ip060.tus.azstarnet.com [169.197.39.60]) by cepheus.azstarnet.com (8.9.3/8.9.3) with SMTP id KAA15275 for ; Mon, 21 Aug 2000 10:13:29 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ From: BoB KoT To: freebsd-current@FreeBSD.ORG Subject: Re: make buildworld failed Date: Mon, 21 Aug 2000 09:24:44 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00082110132702.00342@full.planing.jibe> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll chime in here with a "me too". My make buildworld(s) failed with the *identical* error as originally posted by daniel on 16-Aug-2000. I tried #make -j4 buildworld and another attempt of #make buildworld. Both attempts failed with the same error. I tried this on a 3.4-RELEASE system with -current cvsup'd on 20-Aug-2000 @ 07:00 (MST). OK, now there are 2 of us with the identical symptom. Where did we go astray? BoB KoT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10:15:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 83C9B37B42C for ; Mon, 21 Aug 2000 10:15:49 -0700 (PDT) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id TAA20918 for current@freebsd.org; Mon, 21 Aug 2000 19:15:47 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 648A18806; Mon, 21 Aug 2000 19:13:09 +0200 (CEST) Date: Mon, 21 Aug 2000 19:13:09 +0200 From: Ollivier Robert To: current@freebsd.org Subject: Re: how to set flags on sio2? Message-ID: <20000821191309.A64730@keltia.freenix.fr> Mail-Followup-To: current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian@elischer.org on Mon, Aug 21, 2000 at 09:53:49AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Julian Elischer: > the sio man page has no hints.. > it looks to me as it if is now controlled differently > unles I've made a mistake.... Modify /boot/device.hints. hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.irq="4" just add a hint.sio.0.flags="0x20". -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10:25:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id BA73237B42C for ; Mon, 21 Aug 2000 10:25:25 -0700 (PDT) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA06240; Mon, 21 Aug 2000 10:25:08 -0700 (PDT) Date: Mon, 21 Aug 2000 10:25:07 -0700 (PDT) From: Julian Elischer To: Ollivier Robert Cc: current@freebsd.org Subject: Re: how to set flags on sio2? In-Reply-To: <20000821191309.A64730@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG so I don;t have such file.. do I need to do anything special to make it beused if I create it? On Mon, 21 Aug 2000, Ollivier Robert wrote: > According to Julian Elischer: > > the sio man page has no hints.. > > it looks to me as it if is now controlled differently > > unles I've made a mistake.... > > Modify /boot/device.hints. > > hint.sio.0.at="isa" > hint.sio.0.port="0x3F8" > hint.sio.0.irq="4" > > just add a hint.sio.0.flags="0x20". > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 10:36:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 17BC437B43C for ; Mon, 21 Aug 2000 10:36:57 -0700 (PDT) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.7/nospam) with UUCP id TAA21866; Mon, 21 Aug 2000 19:36:50 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 32A368806; Mon, 21 Aug 2000 19:35:48 +0200 (CEST) Date: Mon, 21 Aug 2000 19:35:48 +0200 From: Ollivier Robert To: Julian Elischer Cc: current@freebsd.org Subject: Re: how to set flags on sio2? Message-ID: <20000821193548.A64902@keltia.freenix.fr> Mail-Followup-To: Julian Elischer , current@freebsd.org References: <20000821191309.A64730@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from julian@elischer.org on Mon, Aug 21, 2000 at 10:25:07AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT K6-3D/266 & 2x PPro/200 SMP Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Julian Elischer: > so I don;t have such file.. > do I need to do anything special to make it beused if I create it? If you have current after around the 10th of June, you need it. It is created by running "gethints.pl /boot/device.hints" (gethints.pl is in /sys/i386/conf). Or you use the GENERIC.hints file at the same place (see GENERIC). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 11:20:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f78.pav1.hotmail.com [64.4.31.78]) by hub.freebsd.org (Postfix) with ESMTP id C6F4337B43C for ; Mon, 21 Aug 2000 11:20:19 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 21 Aug 2000 11:20:19 -0700 Received: from 209.213.222.214 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 21 Aug 2000 GMT X-Originating-IP: [209.213.222.214] Reply-To: jake@3ware.com From: "Joel Jacobson" To: freebsd-current@freebsd.org Subject: compaq proliant Date: Mon, 21 Aug 2000 18:20:19 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Aug 2000 18:20:19.0559 (UTC) FILETIME=[76663F70:01C00B9C] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG has anyone gotten freebsd (current or other) running on one of these? i've tried 4.0, 4.1, and -current, and the kernel panics on me with the following: sym0: <895a> port 0x1000=0x10ff mem 0xb1100000-0xb1101fff,0xb1400000-0xb14003ff irq 11 at device 4.0 on pci1 sym0: failed to allocate RAM resources any ideas? - j ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 12: 4:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 560BD37B43C for ; Mon, 21 Aug 2000 12:04:33 -0700 (PDT) Received: (qmail 28807 invoked by uid 1001); 21 Aug 2000 19:04:26 +0000 (GMT) To: jake@3ware.com, biffey@hotmail.com Cc: freebsd-current@freebsd.org Subject: Re: compaq proliant From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 21 Aug 2000 18:20:19 GMT" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 21 Aug 2000 21:04:26 +0200 Message-ID: <28805.966884666@verdi.nethelp.no> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > has anyone gotten freebsd (current or other) running on one of these? Which Proliant model are you talking about? > i've tried 4.0, 4.1, and -current, and the kernel panics on me with > the following: > > sym0: <895a> port 0x1000=0x10ff mem > 0xb1100000-0xb1101fff,0xb1400000-0xb14003ff irq 11 at device 4.0 on pci1 > sym0: failed to allocate RAM resources We're running 3.4-STABLE on a Proliant 3000 here, and it's working great. Mind you, this has a Symbios 875 based controller, not 895a as in your case. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-20000124-STABLE #0: Sat Feb 19 23:14:12 CET 2000 sthaug@newsfeed1.telia.no:/local/freebsd/src/sys/compile/NEWSFEED1_SYM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 603979776 (589824K bytes) avail memory = 584105984 (570416K bytes) Programming 28 pins in IOAPIC #0 EISA INTCONTROL = 00000620 IOAPIC #0 intpint 24 -> irq 5 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 8, version: 0x001b0011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02d6000. Pentium Pro MTRR support enabled eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 vga0: rev 0x22 int a irq 255 on pci0.6.0 chip1: rev 0x07 on pci0.15.0 chip2: rev 0x03 on pci0.17.0 Probing for devices on PCI bus 1: sym0: <875> rev 0x14 int a irq 19 on pci1.4.0 sym0: No NVRAM, ID 7, Fast-20, parity checking sym1: <875> rev 0x14 int b irq 18 on pci1.4.1 sym1: No NVRAM, ID 7, Fast-20, parity checking fxp0: rev 0x05 int a irq 18 on pci1.7.0 fxp0: Ethernet address 00:90:27:13:f6:21 tl0: rev 0x10 int a irq 17 on pci1.8.0 tl0: Ethernet address: 00:08:c7:1e:a7:35 tl0: autoneg complete, link status good (full-duplex, 100Mbps) Probing for devices on PCI bus 2: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0: failed to get data. psm0 irq 12 on isa psm0: model IntelliMouse, device ID 3 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): , removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IO APIC int pin 2 APIC_IO: routing 8254 via 8259 on pin 0 ccd0-3: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da2 at sym0 bus 0 target 4 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da3 at sym0 bus 0 target 5 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 12: 6:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 0A5A437B422 for ; Mon, 21 Aug 2000 12:06:43 -0700 (PDT) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.16 #1) id 13QweN-000FDN-00; Mon, 21 Aug 2000 19:50:23 +0100 Received: (from ben@localhost) by strontium.scientia.demon.co.uk (8.9.3/8.9.3) id TAA86298; Mon, 21 Aug 2000 19:50:23 +0100 (BST) (envelope-from ben) Date: Mon, 21 Aug 2000 19:50:23 +0100 From: Ben Smithurst To: Michael Lucas Cc: gzeigler@texasonline.net, current@FreeBSD.ORG Subject: Re: Question from a neophyte... Why isn't rc.local being read? Message-ID: <20000821195023.F20036@strontium.scientia.demon.co.uk> References: <200008211205530812.0DA63AC7@texasonline.net> <200008211710.NAA96546@blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200008211710.NAA96546@blackhelicopters.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Lucas wrote: > rc.local is deprecated. Drop a shell script in /usr/local/etc/rc.d Not really. Some of us prefer to have commands to start things in one nice list in /etc/rc.local, rather than loads of separate shell scripts in /usr/local/etc/rc.d. There's no reason I can see for rc.local not to get read at boot time. I'd recommend the original poster compare his other /etc/rc* files with those in /usr/src/etc to make sure there has been no local modification to remove the code which calls rc.local. -- Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 12:20:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 3D3C537B7F3 for ; Mon, 21 Aug 2000 12:20:13 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA94117; Mon, 21 Aug 2000 21:19:53 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Sheldon Hearn Cc: current@freebsd.org Subject: Re: PATCH: devfs mkIII test & review please. In-Reply-To: Your message of "Mon, 21 Aug 2000 11:15:45 +0200." <21077.966849345@axl.fw.uunet.co.za> Date: Mon, 21 Aug 2000 21:19:53 +0200 Message-ID: <94115.966885593@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <21077.966849345@axl.fw.uunet.co.za>, Sheldon Hearn writes: > > >On Sat, 19 Aug 2000 21:26:24 +0200, Poul-Henning Kamp wrote: > >> Ahh, right, this is something else than I thought: These are >> symlinks in the normal case, for instance: >> >> /dev/audio -> /dev/audio0 > >What's the plan for things like these? Are we going to take the soft >option and teach /etc/rc to create symlinks for device nodes found on >startup and require folks to make the rest themselves? Or can this be >handled gracefully in the kernel? DEVFS supports symlinks. Symlinks can be made from userland with the normal "ln -s" They can also be made by the driver using make_dev_alias(). Who makes the symlinks and when should be decided by the driver writer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 13: 5:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 3981137B422 for ; Mon, 21 Aug 2000 13:05:43 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13QxpE-00014D-00 for current@freebsd.org; Mon, 21 Aug 2000 22:05:40 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id WAA15073 for ; Mon, 21 Aug 2000 22:05:39 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 15059; Mon Aug 21 22:05:30 2000 Prev-Resent: Mon, 21 Aug 2000 18:39:12 +0200 Prev-Resent: current@FreeBSD.org From: Sheldon Hearn To: current@freebsd.org Subject: HEADS UP: random module no longer loaded by default Date: Mon, 21 Aug 2000 16:44:08 +0200 Message-ID: <553.966869048@axl.fw.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, The logic for seeding the random device on start-up in /etc/rc has changed slightly. Between revs 1.221 and 1.229 inclusive, the randomdev module was automatically loaded if the write of the entropy seed file to /dev/random failed. After chatting to Mark Murray, I agree that this isn't such a hot plan. If the random device isn't present, it may very well be because it's not wanted. There are several things on the horizon that will moot this point, so there's no need to jump up and down about it. The bottom line is this: If you do NOT have ``options RANDOMDEV'' in your kernel and you DO want the random device then add randomdev_load="YES" to /boot/loader.conf . Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 15: 2:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-012.telepath.com [216.14.2.12]) by hub.freebsd.org (Postfix) with SMTP id 828CD37B424 for ; Mon, 21 Aug 2000 15:02:13 -0700 (PDT) Received: (qmail 55397 invoked by uid 100); 21 Aug 2000 22:01:20 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.42672.286077.409965@guru.mired.org> Date: Mon, 21 Aug 2000 17:01:20 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821104114.A67935@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth D. Merry writes: > On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote: > > I'm curious - is there some reason that the CDR ioctls (in > > /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like > > doing them for MMC would be straightforward, it's the kind of thing > > that an OS is supposed to do, and it would allow people with MMC > > drives to cdrecord for the much (much, *much*) smaller burncd. > Well, doing that sort of thing for MMC-compliant CD-Rs will open the door > to doing it for all CD-Rs. No more so than has already been done by supporting SCSI cdrom at all. > We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM > supported with the cd(4) driver..." Which should actually be smaller than the flood of mail saying things like "why doesn't burncd support my nice, standard-compliant CD-R?" In fact, according to the documentation that comes with cdrecord, it would be *much* smaller, because all the SCSI CD-Rs released in the last few years have been MMC. > cdrecord supports a much wider variety of drives out of the box, it is > actively supported, and it works. Yup. Since it's native OS isn't FreeBSD, it wouldn't vanish even if we *did* put all of cdrecord in the kernel. I don't even see the port vanishing, because of the need to support legacy hardware. > If we put all of cdrecord's functionality into the kernel and burncd, it > would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck > with maintaining it.) Correct. I'm not asking why cdrecord's functionality isn't in the kernel, and wouldn't argue that it should be. I'm asking why there isn't support for a widely deployed standard interface to this functionality when there's already a kernel API for it. If it's a matter of not wanting to maintain that little bit of code, I'm willing to do that. ; Mon, 21 Aug 2000 15:35:01 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA71092; Mon, 21 Aug 2000 16:34:58 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 16:34:58 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821163458.A70871@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.42672.286077.409965@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 05:01:20PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 17:01:20 -0500, Mike Meyer wrote: > Kenneth D. Merry writes: > > On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote: > > We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM > > supported with the cd(4) driver..." > > Which should actually be smaller than the flood of mail saying things > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > fact, according to the documentation that comes with cdrecord, it > would be *much* smaller, because all the SCSI CD-Rs released in the > last few years have been MMC. I think it would generate a fair amount of mail, certainly a lot more than the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. (which is very, very little) > > If we put all of cdrecord's functionality into the kernel and burncd, it > > would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck > > with maintaining it.) > > Correct. I'm not asking why cdrecord's functionality isn't in the > kernel, and wouldn't argue that it should be. I'm asking why there > isn't support for a widely deployed standard interface to this > functionality when there's already a kernel API for it. > > If it's a matter of not wanting to maintain that little bit of code, > I'm willing to do that. It's not there because I'd rather not do a halfway solution. Adding support for only MMC drives will mean that users with non-MMC SCSI CD burners will just get confused when burncd doesn't work. ("But it worked for my friend Joe...") Just because the API is there doesn't mean we should go through the work to support that API when we have something else that already works. It would be a duplication of functionality. Why reinvent the wheel when the wheel we have works very well? If you want standard burner support with the OS (isn't that what you're really getting at here?), why not just import cdrecord into the contrib tree and be done with it? It's GPLed, so it wouldn't be any more onerous license-wise than many of the other tools we have in the tree. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 16:20:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-008.telepath.com [216.14.2.8]) by hub.freebsd.org (Postfix) with SMTP id E804837B616 for ; Mon, 21 Aug 2000 16:20:23 -0700 (PDT) Received: (qmail 56835 invoked by uid 100); 21 Aug 2000 23:19:47 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.47379.141329.994631@guru.mired.org> Date: Mon, 21 Aug 2000 18:19:47 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821163458.A70871@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth D. Merry writes: > > Which should actually be smaller than the flood of mail saying things > > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > > fact, according to the documentation that comes with cdrecord, it > > would be *much* smaller, because all the SCSI CD-Rs released in the > > last few years have been MMC. > I think it would generate a fair amount of mail, certainly a lot more than > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. > (which is very, very little) What evidence do you have that it would generate a fair amount of mail? I agree that there's very little about burncd - probably because most people get dual pointers when they ask what to use to record cds. Improving what burncd works for shouldn't change that, especially if the kernel boot sequence said whether or not the drive supported MMC. > > Correct. I'm not asking why cdrecord's functionality isn't in the > > kernel, and wouldn't argue that it should be. I'm asking why there > > isn't support for a widely deployed standard interface to this > > functionality when there's already a kernel API for it. > > If it's a matter of not wanting to maintain that little bit of code, > > I'm willing to do that. > It's not there because I'd rather not do a halfway solution. Adding > support for only MMC drives will mean that users with non-MMC SCSI CD > burners will just get confused when burncd doesn't work. ("But it worked > for my friend Joe...") I'd say that you've *already* got a halfway solution, in that you only support half the functionality of the standard. Just curious - do you feel that you have to support old disk drives that don't properly adhere to the SCSI standard, or otherwise behave in strange ways? Say some of DEC's old drives that don't spin up on power on, but have to be told to do so by the OS? A quick check doesn't reveal any support for such things, but I may have missed it. > Just because the API is there doesn't mean we should go through the work > to support that API when we have something else that already works. > It would be a duplication of functionality. Why reinvent the wheel > when the wheel we have works very well? For the same reason that CAM replaced the old SCSI system - because the replacement is an improvement! Sure, it won't work with non-standard devices, but those should be a shrinking minority. This also solves the problem of keeping the two in sync. I've been bit more than once by the system and cdrecord being out of sync. > If you want standard burner support with the OS (isn't that what you're > really getting at here?), why not just import cdrecord into the contrib > tree and be done with it? It's GPLed, so it wouldn't be any more onerous > license-wise than many of the other tools we have in the tree. Well, that would certainly solve the sync problem - but I'm not willing to support cdrecord; it's an ugly mess. I'd rather support (including write) the MMC code. I just don't want to write it if it will never go in the distribution. ; Mon, 21 Aug 2000 16:57:00 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA72074; Mon, 21 Aug 2000 17:56:57 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 17:56:57 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821175657.A71753@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.47379.141329.994631@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 06:19:47PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote: > Kenneth D. Merry writes: > > > Which should actually be smaller than the flood of mail saying things > > > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > > > fact, according to the documentation that comes with cdrecord, it > > > would be *much* smaller, because all the SCSI CD-Rs released in the > > > last few years have been MMC. > > I think it would generate a fair amount of mail, certainly a lot more than > > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. > > (which is very, very little) > > What evidence do you have that it would generate a fair amount of > mail? Prior experience. People get confused relatively easily, no matter how many places something is documented and no matter how many times you explain something on a mailing list. It might not be that bad, though, since cdrecord would still be available and still work. > > > Correct. I'm not asking why cdrecord's functionality isn't in the > > > kernel, and wouldn't argue that it should be. I'm asking why there > > > isn't support for a widely deployed standard interface to this > > > functionality when there's already a kernel API for it. > > > If it's a matter of not wanting to maintain that little bit of code, > > > I'm willing to do that. > > It's not there because I'd rather not do a halfway solution. Adding > > support for only MMC drives will mean that users with non-MMC SCSI CD > > burners will just get confused when burncd doesn't work. ("But it worked > > for my friend Joe...") > > I'd say that you've *already* got a halfway solution, in that you only > support half the functionality of the standard. You mean reading and not writing? One piece of writing functionality I *do* intend to put in the kernel is support for DVD-RAM drives. (It's mainly hung up with disklabel problems at the moment.) > Just curious - do you feel that you have to support old disk drives > that don't properly adhere to the SCSI standard, or otherwise behave > in strange ways? Say some of DEC's old drives that don't spin up on > power on, but have to be told to do so by the OS? A quick check > doesn't reveal any support for such things, but I may have missed it. You missed it. In the error recovery code. If a drive returns an error code that we understand to mean "spin me up", we send a start unit command to the disk. (No more than four start units may be oustanding at one time, to avoid overloading power supplies.) We also have various quirk tables for devices that do odd things. So yes, I think we do need to support older and/or quirky hardware, to a certain point. > > Just because the API is there doesn't mean we should go through the work > > to support that API when we have something else that already works. > > It would be a duplication of functionality. Why reinvent the wheel > > when the wheel we have works very well? > > For the same reason that CAM replaced the old SCSI system - because > the replacement is an improvement! Sure, it won't work with > non-standard devices, but those should be a shrinking minority. I don't think you've made the case that the replacement is an improvement. cdrecord at the moment has more features than burncd, and seems to work well. The only thing you've said about cdrecord is that the code is a mess (below). I don't think it's that bad. I might do things differently, but things are going to be more complicated when you try to support a large number of OSes. > This also solves the problem of keeping the two in sync. I've been bit > more than once by the system and cdrecord being out of sync. > > > If you want standard burner support with the OS (isn't that what you're > > really getting at here?), why not just import cdrecord into the contrib > > tree and be done with it? It's GPLed, so it wouldn't be any more onerous > > license-wise than many of the other tools we have in the tree. > > Well, that would certainly solve the sync problem - but I'm not > willing to support cdrecord; it's an ugly mess. I'd rather support > (including write) the MMC code. I just don't want to write it if it > will never go in the distribution. What you're willing to support isn't the whole picture here. As the driver author, I'd rather not support a solution that only goes halfway. If doing burncd support for MMC drives were a step on the way for getting support for the various other types of drives that cdrecord supports, it would be a different story. (We'd also want to see what features were available in cdrecord but not burncd and look into adding those as well.) As it is, importing cdrecord into the tree would solve what seem to be your major objections -- that cdrecord gets out of sync with the OS because it isn't built with the OS, and that we don't ship a way of burning SCSI CDs with the OS. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 17:16:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from vallesnet.org (vallesnet.org [194.224.210.5]) by hub.freebsd.org (Postfix) with ESMTP id 30AB237B422 for ; Mon, 21 Aug 2000 17:16:53 -0700 (PDT) Received: from daemon (40-BARC-X105.libre.retevision.es [62.82.28.40]) by vallesnet.org (8.9.3/8.9.3) with SMTP id CAA17566 for ; Tue, 22 Aug 2000 02:18:01 +0200 Message-ID: <002901c00bce$7b936680$0164a8c0@daemon> From: "undergra" To: Subject: error sysinstall Date: Tue, 22 Aug 2000 02:18:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, when i execute sysinstall i have this error: Device char-major=254 minor=0x0 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x0 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x0 failed attempt t o open in block mode Device char-major=254 minor=0x1 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x1 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x1 failed attempt t o open in block mode Device char-major=254 minor=0x2 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x2 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x2 failed attempt t o open in block mode Device char-major=254 minor=0x3 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x3 failed attempt to open in block mode anyone help me please? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 17:17:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-149.telepath.com [216.14.0.149]) by hub.freebsd.org (Postfix) with SMTP id 6B73937B422 for ; Mon, 21 Aug 2000 17:17:38 -0700 (PDT) Received: (qmail 58438 invoked by uid 100); 22 Aug 2000 00:17:37 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.50849.16035.805395@guru.mired.org> Date: Mon, 21 Aug 2000 19:17:37 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821175657.A71753@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth D. Merry writes: > On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote: > > Kenneth D. Merry writes: > > > > Which should actually be smaller than the flood of mail saying things > > > > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > > > > fact, according to the documentation that comes with cdrecord, it > > > > would be *much* smaller, because all the SCSI CD-Rs released in the > > > > last few years have been MMC. > > > I think it would generate a fair amount of mail, certainly a lot more than > > > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. > > > (which is very, very little) > > What evidence do you have that it would generate a fair amount of > > mail? > Prior experience. People get confused relatively easily, no matter how many > places something is documented and no matter how many times you explain > something on a mailing list. Um - that's not evidence, that's an argument. But prior experience shows that having two tools for burning cd's generates - in your own words - "very, very little" mail. By the same argument, including some drives in both sets of tools shouldn't raise the confusion level. > > > > Correct. I'm not asking why cdrecord's functionality isn't in the > > > > kernel, and wouldn't argue that it should be. I'm asking why there > > > > isn't support for a widely deployed standard interface to this > > > > functionality when there's already a kernel API for it. > > > > If it's a matter of not wanting to maintain that little bit of code, > > > > I'm willing to do that. > > > It's not there because I'd rather not do a halfway solution. Adding > > > support for only MMC drives will mean that users with non-MMC SCSI CD > > > burners will just get confused when burncd doesn't work. ("But it worked > > > for my friend Joe...") > > I'd say that you've *already* got a halfway solution, in that you only > > support half the functionality of the standard. > You mean reading and not writing? Yes. > One piece of writing functionality I *do* intend to put in the kernel is > support for DVD-RAM drives. (It's mainly hung up with disklabel problems > at the moment.) Why those and not CD-R drives? Especially when, from what I can tell, the situation with those is even *more* confused than it is with CD-Rs, as there are multiple writable DVD formats, and they are changing. Or are you talking about support for the non-9660 file system that some of them use? > > Just curious - do you feel that you have to support old disk drives > > that don't properly adhere to the SCSI standard, or otherwise behave > > in strange ways? Say some of DEC's old drives that don't spin up on > > power on, but have to be told to do so by the OS? A quick check > > doesn't reveal any support for such things, but I may have missed it. > You missed it. In the error recovery code. If a drive returns an error > code that we understand to mean "spin me up", we send a start unit command > to the disk. (No more than four start units may be oustanding at one time, > to avoid overloading power supplies.) > We also have various quirk tables for devices that do odd things. So yes, > I think we do need to support older and/or quirky hardware, to a certain > point. Does this extend to the point of supporting things that happen to share a physical connector with SCSI, but otherwise aren't SCSI? Because that's what supporting non-MMC CD-R drives would amount to. Supporting quirky MMC drives should be done just like most other hardware, though. > > > Just because the API is there doesn't mean we should go through the work > > > to support that API when we have something else that already works. > > > It would be a duplication of functionality. Why reinvent the wheel > > > when the wheel we have works very well? > > For the same reason that CAM replaced the old SCSI system - because > > the replacement is an improvement! Sure, it won't work with > > non-standard devices, but those should be a shrinking minority. > I don't think you've made the case that the replacement is an improvement. > cdrecord at the moment has more features than burncd, and seems to work > well. Well, I don't agree on that assesment about how well cdrecord works. I've found it to be finicky and a PITA. > The only thing you've said about cdrecord is that the code is a mess > (below). I don't think it's that bad. I might do things differently, > but things are going to be more complicated when you try to support a large > number of OSes. You forgot the problems of it staying in sync with the OS. I've had both build breakages, and binaries that quit working after starting to write a blank (thus ruining it) after doing an OS upgrade. > > > If you want standard burner support with the OS (isn't that what you're > > > really getting at here?), why not just import cdrecord into the contrib > > > tree and be done with it? It's GPLed, so it wouldn't be any more onerous > > > license-wise than many of the other tools we have in the tree. > > Well, that would certainly solve the sync problem - but I'm not > > willing to support cdrecord; it's an ugly mess. I'd rather support > > (including write) the MMC code. I just don't want to write it if it > > will never go in the distribution. > What you're willing to support isn't the whole picture here. As the driver > author, I'd rather not support a solution that only goes halfway. Of course that isn't the entire picture - that's why I asked. Again, arguing about this solution being "halfway" when you're ignoring half the functionality of the standard seems hypocritical. > If doing burncd support for MMC drives were a step on the way for getting > support for the various other types of drives that cdrecord supports, it > would be a different story. (We'd also want to see what features were > available in cdrecord but not burncd and look into adding those as well.) In other words, supporting the standard would only be reasonable if it's a start towards embedding cdrecord in the kernel, which we have already agreed is unreasonable. > As it is, importing cdrecord into the tree would solve what seem to be > your major objections -- that cdrecord gets out of sync with the OS because > it isn't built with the OS, and that we don't ship a way of burning SCSI > CDs with the OS. Your doing that would certainly be a step in the right direction. ; Mon, 21 Aug 2000 19:17:35 -0700 (PDT) Received: from takhus-home.ashlandfn.org (AFN-Dynamic-21924.ashlandfiber.net [208.46.219.24]) by ego.mind.net (8.9.3/8.9.3) with ESMTP id TAA08902 for ; Mon, 21 Aug 2000 19:17:34 -0700 Received: from localhost (fleisher@localhost) by takhus-home.ashlandfn.org (8.11.0/8.9.3) with ESMTP id e7M2HVA20092 for ; Mon, 21 Aug 2000 19:17:31 -0700 (PDT) (envelope-from takhus@takhus.mind.net) Date: Mon, 21 Aug 2000 19:17:31 -0700 (PDT) From: Tony Fleisher X-Sender: fleisher@takhus-home.ashlandfn.org To: freebsd-current@freebsd.org Subject: problems with /usr/bin/awk Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been running cvsup nightly to grab -current and -ports, and noticed some strangeness with awk that seemed to start last week sometime. When building /usr/ports/lang/guile, the build exited with an awk 'internal error' and a log on the console that awk had exited on signal 6. To test my theory that the problem was indeed awk (rather than the guile port), I copied over a copy of awk from a 4.1-R system. After doing so, the guile port was able to build and install without any problems. Here is the output from the make build: PATH=.:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin :/usr/X11R6/bin:/root/bin ./guile-doc-snarf eval.c -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -O -pipe -Wall -Wmissing-prototypes eval.c > eval.x || { rm eval.x; false; } awk: ./guile-snarf.awk:17: (FILENAME=- FNR=9680) fatal error: internal error Abort trap - core dumped *** Error code 1 Regards, Tony. #include ".sig" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 20: 0:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 3950B37B423 for ; Mon, 21 Aug 2000 20:00:50 -0700 (PDT) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id XAA13958; Mon, 21 Aug 2000 23:00:38 -0400 (EDT) Message-ID: <20000821230037.A17035@netmonger.net> Date: Mon, 21 Aug 2000 23:00:37 -0400 From: Christopher Masto To: Mike Meyer , "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <14753.42672.286077.409965@guru.mired.org>; from Mike Meyer on Mon, Aug 21, 2000 at 05:01:20PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 20:25:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id A3FA037B422 for ; Mon, 21 Aug 2000 20:25:19 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA73365; Mon, 21 Aug 2000 21:25:17 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 21:25:17 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821212517.B73232@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.50849.16035.805395@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 07:17:37PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 19:17:37 -0500, Mike Meyer wrote: > Kenneth D. Merry writes: > > On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote: > > > Kenneth D. Merry writes: > > > > > Which should actually be smaller than the flood of mail saying things > > > > > like "why doesn't burncd support my nice, standard-compliant CD-R?" In > > > > > fact, according to the documentation that comes with cdrecord, it > > > > > would be *much* smaller, because all the SCSI CD-Rs released in the > > > > > last few years have been MMC. > > > > I think it would generate a fair amount of mail, certainly a lot more than > > > > the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. > > > > (which is very, very little) > > > What evidence do you have that it would generate a fair amount of > > > mail? > > Prior experience. People get confused relatively easily, no matter how many > > places something is documented and no matter how many times you explain > > something on a mailing list. > > Um - that's not evidence, that's an argument. But prior experience > shows that having two tools for burning cd's generates - in your own > words - "very, very little" mail. By the same argument, including some > drives in both sets of tools shouldn't raise the confusion level. Hopefully not, but people have a tendency to make simple things complicated. :) > > One piece of writing functionality I *do* intend to put in the kernel is > > support for DVD-RAM drives. (It's mainly hung up with disklabel problems > > at the moment.) > > Why those and not CD-R drives? Especially when, from what I can tell, > the situation with those is even *more* confused than it is with > CD-Rs, as there are multiple writable DVD formats, and they are > changing. > > Or are you talking about support for the non-9660 file system that > some of them use? Well, DVD-RAM drives have a totally different read/write model than CD-R or CD-RW drives. They function pretty much like a MO disk, at least when there is a writable disk in them. Supporting them, at least minimally, is a one line change. (To add write support to the cdevsw in the driver. They really are that much like disks. There's really no additional detection required, since the drive will spit out the command if the media isn't writeable.) CD-R's don't fit within the normal Unix read/write semantics, thus the reason that we have to use userland programs and an ioctl mechanism (whether with burncd or cdrecord) in order to go through the different states required to get the data written. You can't just say "write" and be done. You have to fixate, etc. I'm not working on filesystems at all. Several other folks have talked about doing UDF support, and I'm not really up for tackling that anyway. You can put a UFS filesystem on a DVD-RAM, or you can put an ISO9660 filesystem on one, or whatever other filesystem you want. All I'm working on is the driver-level mechanism to enable write support. > > > Just curious - do you feel that you have to support old disk drives > > > that don't properly adhere to the SCSI standard, or otherwise behave > > > in strange ways? Say some of DEC's old drives that don't spin up on > > > power on, but have to be told to do so by the OS? A quick check > > > doesn't reveal any support for such things, but I may have missed it. > > You missed it. In the error recovery code. If a drive returns an error > > code that we understand to mean "spin me up", we send a start unit command > > to the disk. (No more than four start units may be oustanding at one time, > > to avoid overloading power supplies.) > > We also have various quirk tables for devices that do odd things. So yes, > > I think we do need to support older and/or quirky hardware, to a certain > > point. > > Does this extend to the point of supporting things that happen to > share a physical connector with SCSI, but otherwise aren't SCSI? > Because that's what supporting non-MMC CD-R drives would amount to. Not really. Non-MMC CD-Rs not only use the same connectors and cables, they also comply with the SCSI standard. They use the same bus protocol, respond to inquiries and test unit ready commands just like everything else. They also act like standard CDROM drives when you're reading data. They primarily differ in the mechanisms and quirks needed to do writes. > Supporting quirky MMC drives should be done just like most other > hardware, though. > > > > > Just because the API is there doesn't mean we should go through the work > > > > to support that API when we have something else that already works. > > > > It would be a duplication of functionality. Why reinvent the wheel > > > > when the wheel we have works very well? > > > For the same reason that CAM replaced the old SCSI system - because > > > the replacement is an improvement! Sure, it won't work with > > > non-standard devices, but those should be a shrinking minority. > > I don't think you've made the case that the replacement is an improvement. > > cdrecord at the moment has more features than burncd, and seems to work > > well. > > Well, I don't agree on that assesment about how well cdrecord > works. I've found it to be finicky and a PITA. You might want to talk to Joerg Schilling if you've got suggestions. He watches the cdwrite mailing list (cdwrite@other.debian.org) closely, or you can send mail to schilling@fokus.gmd.de. > > The only thing you've said about cdrecord is that the code is a mess > > (below). I don't think it's that bad. I might do things differently, > > but things are going to be more complicated when you try to support a large > > number of OSes. > > You forgot the problems of it staying in sync with the OS. I've had > both build breakages, and binaries that quit working after starting to > write a blank (thus ruining it) after doing an OS upgrade. I mentioned a solution below -- putting it in the contrib tree. > > > > If you want standard burner support with the OS (isn't that what you're > > > > really getting at here?), why not just import cdrecord into the contrib > > > > tree and be done with it? It's GPLed, so it wouldn't be any more onerous > > > > license-wise than many of the other tools we have in the tree. > > > Well, that would certainly solve the sync problem - but I'm not > > > willing to support cdrecord; it's an ugly mess. I'd rather support > > > (including write) the MMC code. I just don't want to write it if it > > > will never go in the distribution. > > What you're willing to support isn't the whole picture here. As the driver > > author, I'd rather not support a solution that only goes halfway. > > Of course that isn't the entire picture - that's why I asked. Again, > arguing about this solution being "halfway" when you're ignoring half > the functionality of the standard seems hypocritical. Not really. We've had a solution for supporting the other (writing) half of the standard from the beginning -- cdrecord. That solution has also covered non-MMC drives from the beginning. The disagreement we're having here is about how that write functionality should be supplied. You want it as part of burncd, I think cdrecord does a good job. > > If doing burncd support for MMC drives were a step on the way for getting > > support for the various other types of drives that cdrecord supports, it > > would be a different story. (We'd also want to see what features were > > available in cdrecord but not burncd and look into adding those as well.) > > In other words, supporting the standard would only be reasonable if > it's a start towards embedding cdrecord in the kernel, which we have > already agreed is unreasonable. Yes. > > As it is, importing cdrecord into the tree would solve what seem to be > > your major objections -- that cdrecord gets out of sync with the OS because > > it isn't built with the OS, and that we don't ship a way of burning SCSI > > CDs with the OS. > > Your doing that would certainly be a step in the right direction. Well, I didn't say I wanted to be the one to do it. :) I really know very little about vendor branch imports, etc. I would certainly be supportive if someone more knowledgeable wanted to import and maintain cdrecord. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 20:38:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom1-018.telepath.com [216.14.1.18]) by hub.freebsd.org (Postfix) with SMTP id 6183237B424 for ; Mon, 21 Aug 2000 20:38:13 -0700 (PDT) Received: (qmail 60866 invoked by uid 100); 22 Aug 2000 03:38:11 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.62883.183839.508028@guru.mired.org> Date: Mon, 21 Aug 2000 22:38:11 -0500 (CDT) To: "Kenneth D. Merry" Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821212517.B73232@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth D. Merry writes: > > Does this extend to the point of supporting things that happen to > > share a physical connector with SCSI, but otherwise aren't SCSI? > > Because that's what supporting non-MMC CD-R drives would amount to. > Not really. Non-MMC CD-Rs not only use the same connectors and cables, > they also comply with the SCSI standard. They use the same bus protocol, > respond to inquiries and test unit ready commands just like everything else. > They also act like standard CDROM drives when you're reading data. They > primarily differ in the mechanisms and quirks needed to do writes. No, they comply with *part* of the SCSI standard - the part needed to do reads. But drives with the same connectors comply with *part* of the standard - the part that defines the connector. > > Of course that isn't the entire picture - that's why I asked. Again, > > arguing about this solution being "halfway" when you're ignoring half > > the functionality of the standard seems hypocritical. > Not really. We've had a solution for supporting the other (writing) half > of the standard from the beginning -- cdrecord. That solution has also > covered non-MMC drives from the beginning. I've been told (repeatedly) that ports are *not* part of FreeBSD. Therefore, we don't have a solution. We have a pointer to one provided by someone else. > > > If doing burncd support for MMC drives were a step on the way for getting > > > support for the various other types of drives that cdrecord supports, it > > > would be a different story. (We'd also want to see what features were > > > available in cdrecord but not burncd and look into adding those as well.) > > In other words, supporting the standard would only be reasonable if > > it's a start towards embedding cdrecord in the kernel, which we have > > already agreed is unreasonable. > Yes. That sounds like "I don't want to do it for religious reasons" to me. > > > As it is, importing cdrecord into the tree would solve what seem to be > > > your major objections -- that cdrecord gets out of sync with the OS because > > > it isn't built with the OS, and that we don't ship a way of burning SCSI > > > CDs with the OS. > > Your doing that would certainly be a step in the right direction. > Well, I didn't say I wanted to be the one to do it. :) I really know very > little about vendor branch imports, etc. Well, you have someone willing to fix the problem - but you object to the fix for religious reasons. The fix you're willing to accept you're not willing to implement. Sounds like a bureaucracy to me. Do you claim ownership of all the drivers in cam/scsi, or can someone with more tolerant religious convictions add a driver that's a clone of the CD driver + MMC extensions that gets first crack at CDROM drives, and recognizes MMC drives, but not others? ; Mon, 21 Aug 2000 20:50:49 -0700 (PDT) Received: (qmail 61049 invoked by uid 100); 22 Aug 2000 03:50:12 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.63604.143328.758397@guru.mired.org> Date: Mon, 21 Aug 2000 22:50:11 -0500 (CDT) To: Christopher Masto Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821230037.A17035@netmonger.net> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821230037.A17035@netmonger.net> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto writes: > I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of > trouble. As cdrecord isn't part of FreeBSD, this is clearly the wrong place to ask about that. Joe Schilling watches cdwrite@other.debian.org, and that's the place to ask. I've been told that ATAPI CD-Rs use the same basic command set (MMC) as SCSI ones, only they don't have legacy problems - so it should be possible. ; Mon, 21 Aug 2000 21:02:07 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA73649; Mon, 21 Aug 2000 22:02:05 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 22:02:05 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821220205.A73533@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <14753.62883.183839.508028@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.62883.183839.508028@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 10:38:11PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 22:38:11 -0500, Mike Meyer wrote: > Kenneth D. Merry writes: > > > Of course that isn't the entire picture - that's why I asked. Again, > > > arguing about this solution being "halfway" when you're ignoring half > > > the functionality of the standard seems hypocritical. > > Not really. We've had a solution for supporting the other (writing) half > > of the standard from the beginning -- cdrecord. That solution has also > > covered non-MMC drives from the beginning. > > I've been told (repeatedly) that ports are *not* part of > FreeBSD. Therefore, we don't have a solution. We have a pointer to one > provided by someone else. That's been good enough for most everyone else.... I said I'm open to having it in the contrib tree, what more do you want here??? > > > > If doing burncd support for MMC drives were a step on the way for getting > > > > support for the various other types of drives that cdrecord supports, it > > > > would be a different story. (We'd also want to see what features were > > > > available in cdrecord but not burncd and look into adding those as well.) > > > In other words, supporting the standard would only be reasonable if > > > it's a start towards embedding cdrecord in the kernel, which we have > > > already agreed is unreasonable. > > Yes. > > That sounds like "I don't want to do it for religious reasons" to me. *sigh* > > > > As it is, importing cdrecord into the tree would solve what seem to be > > > > your major objections -- that cdrecord gets out of sync with the OS because > > > > it isn't built with the OS, and that we don't ship a way of burning SCSI > > > > CDs with the OS. > > > Your doing that would certainly be a step in the right direction. > > Well, I didn't say I wanted to be the one to do it. :) I really know very > > little about vendor branch imports, etc. > > Well, you have someone willing to fix the problem - but you object to > the fix for religious reasons. The fix you're willing to accept you're > not willing to implement. Sounds like a bureaucracy to me. There are over 200 committers, and there are plenty of them who are capable of doing it. I'm willing to support its inclusion in the tree, but what I'm not willing to do is commit to spending the time to put cdrecord in the tree and keep it up to date. Would you rather I stick it in the tree and then never update it for lack of time? > Do you claim ownership of all the drivers in cam/scsi, or can someone > with more tolerant religious convictions add a driver that's a clone > of the CD driver + MMC extensions that gets first crack at CDROM > drives, and recognizes MMC drives, but not others? Talk to Matt , or Justin , and see what they have to say. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 21:13:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8881537B424 for ; Mon, 21 Aug 2000 21:13:38 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA05590; Mon, 21 Aug 2000 21:13:35 -0700 Date: Mon, 21 Aug 2000 21:10:12 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Mike Meyer , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821220205.A73533@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm sorry- I really haven't been paying much attention to this, but it seems it's sort of on the wrong mailing list, isn't it? Mike- can you take a deep breath and send a summary of what you see the techical problems/requirements are to the freebsd-scsi alias? I'll admit that I'm not up on a lot of this...oops- I just saw mail from you... taking offline.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 21:18:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-088.telepath.com [216.14.0.88]) by hub.freebsd.org (Postfix) with SMTP id 8E15A37B43C for ; Mon, 21 Aug 2000 21:18:51 -0700 (PDT) Received: (qmail 61613 invoked by uid 100); 22 Aug 2000 04:18:50 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14753.65322.139615.822253@guru.mired.org> Date: Mon, 21 Aug 2000 23:18:50 -0500 (CDT) To: Christopher Masto Cc: "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821230037.A17035@netmonger.net> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821230037.A17035@netmonger.net> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Masto writes: > I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of > trouble. Spoke to soon - according to the pkg/DESCR file, it should work on them now. ; Mon, 21 Aug 2000 21:24:11 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA73920; Mon, 21 Aug 2000 22:24:07 -0600 (MDT) (envelope-from ken) Date: Mon, 21 Aug 2000 22:24:07 -0600 From: "Kenneth D. Merry" To: Mike Meyer Cc: Christopher Masto , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000821222407.A73879@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821230037.A17035@netmonger.net> <14753.65322.139615.822253@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <14753.65322.139615.822253@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 11:18:50PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 23:18:50 -0500, Mike Meyer wrote: > Christopher Masto writes: > > I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of > > trouble. > > Spoke to soon - according to the pkg/DESCR file, it should work on > them now. It needs an ATAPI passthrough mechanism to work. (FreeBSD doesn't have one at the moment.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 21:25:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.bmr.net.au (www.bmr.com.au [203.35.231.131]) by hub.freebsd.org (Postfix) with ESMTP id 9CDEB37B42C for ; Mon, 21 Aug 2000 21:25:32 -0700 (PDT) Received: from cybersite.com.au (ppp13.as3.bmr.net.au [203.42.33.23]) by ns.bmr.net.au (8.9.3/8.9.3) with ESMTP id OAA29936 for ; Tue, 22 Aug 2000 14:36:43 +1000 Message-ID: <39A20170.B63129A9@cybersite.com.au> Date: Tue, 22 Aug 2000 14:28:32 +1000 From: User Tim X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe freebsd-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 21:59:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-226.telepath.com [216.14.0.226]) by hub.freebsd.org (Postfix) with SMTP id 8E8AA37B423 for ; Mon, 21 Aug 2000 21:59:27 -0700 (PDT) Received: (qmail 62337 invoked by uid 100); 22 Aug 2000 04:59:26 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14754.2222.927759.462718@guru.mired.org> Date: Mon, 21 Aug 2000 23:59:26 -0500 (CDT) To: current@freebsd.org Subject: People running with LOCALBASE set to something other than /usr/local? X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm curious - are there any committers who regularly use a system with LOCALBASE set to something other than /usr/local? Thanx, ; Mon, 21 Aug 2000 23:07:17 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA57073; Tue, 22 Aug 2000 00:07:15 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA01652; Tue, 22 Aug 2000 00:07:05 -0600 (MDT) Message-Id: <200008220607.AAA01652@harmony.village.org> To: Mike Meyer Subject: Re: Why no CDR ioctls for SCSI cds? Cc: "Kenneth D. Merry" , current@FreeBSD.ORG In-reply-to: Your message of "Mon, 21 Aug 2000 22:38:11 CDT." <14753.62883.183839.508028@guru.mired.org> References: <14753.62883.183839.508028@guru.mired.org> <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> Date: Tue, 22 Aug 2000 00:07:05 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14753.62883.183839.508028@guru.mired.org> Mike Meyer writes: : Do you claim ownership of all the drivers in cam/scsi, or can someone : with more tolerant religious convictions add a driver that's a clone : of the CD driver + MMC extensions that gets first crack at CDROM : drives, and recognizes MMC drives, but not others? Ken wrote the cd driver as well as large parts of CAM. Chances are good that what you are calling religious convictions were actually hard fought engineering decisions that have the backing of hard experience plus many more "details" that Ken might not recall off the top of his head but that lead to his views. Having said this, if you can come up with a foolproof way to get the ioctls right on all the drives that do support them, even the whacked out ones that need all kinds of quirky entries, and do it in a way that doesn't needlessly bloat the kernel for little gain (few people, in the scheme of things, have cd-r or cd-rw on their machines and use them to burn disks), then he might reconsider his views. However, much of your posts have had an "airchair quarterback" feel to them and unless and until you have working code, nobody's opinions are going to change. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 23:26:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id 7D98937B424 for ; Mon, 21 Aug 2000 23:26:14 -0700 (PDT) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id CAA24564; Tue, 22 Aug 2000 02:26:11 -0400 (EDT) Message-ID: <20000822022611.A24369@netmonger.net> Date: Tue, 22 Aug 2000 02:26:11 -0400 From: Christopher Masto To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821230037.A17035@netmonger.net> <14753.63604.143328.758397@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <14753.63604.143328.758397@guru.mired.org>; from Mike Meyer on Mon, Aug 21, 2000 at 10:50:11PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 10:50:11PM -0500, Mike Meyer wrote: > Christopher Masto writes: > > I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of > > trouble. > > As cdrecord isn't part of FreeBSD, this is clearly the wrong place to > ask about that. Joe Schilling watches cdwrite@other.debian.org, and > that's the place to ask. > > I've been told that ATAPI CD-Rs use the same basic command set (MMC) > as SCSI ones, only they don't have legacy problems - so it should be > possible. Actually, that's why this would be the appropriate place. cdrecord is designed to do that sort of thing - it separates out the driver interface and has several already, including support for Linux's "ATAPI over SCSI". It just doesn't work with FreeBSD because our ATAPI driver doesn't make available the low-level communication it needs. But whatever. I've personally decided to give up on it and get a SCSI CD-R at some point. I'm just confused by the desire to avoid cdrecord, since in my experience, it has worked great. It also has a lot of nifty options. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 23:40:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-172.telepath.com [216.14.0.172]) by hub.freebsd.org (Postfix) with SMTP id C641A37B422 for ; Mon, 21 Aug 2000 23:40:34 -0700 (PDT) Received: (qmail 64298 invoked by uid 100); 22 Aug 2000 06:39:57 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14754.8253.80322.822607@guru.mired.org> Date: Tue, 22 Aug 2000 01:39:57 -0500 (CDT) To: Warner Losh Cc: Mike Meyer , "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <200008220607.AAA01652@harmony.village.org> References: <14753.62883.183839.508028@guru.mired.org> <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <200008220607.AAA01652@harmony.village.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > Having said this, if you can come up with a foolproof way to get the > ioctls right on all the drives that do support them, even the whacked > out ones that need all kinds of quirky entries, and do it in a way > that doesn't needlessly bloat the kernel for little gain (few people, > in the scheme of things, have cd-r or cd-rw on their machines and use > them to burn disks), then he might reconsider his views. However, > much of your posts have had an "airchair quarterback" feel to them and > unless and until you have working code, nobody's opinions are going to > change. You may well be right, and there are good technical reasons for not doing this. The only real reason that's been presented for not doing MMC is that all the non-MMC drives might cause a support headache. There are sound technical reasons for *not* doing non-MMC drives, and Ken and I agree on that. If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time? References: <20000821135952.A68790@indocyber.com> <20000821130446.E91965@sunbay.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000822153956V.haro@tk.kubota.co.jp> Date: Tue, 22 Aug 2000 15:39:56 +0900 From: haro@tk.kubota.co.jp (Munehiro Matsuda) X-Dispatcher: imput version 990905(IM130) Lines: 39 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Ruslan Ermilov Date: Mon, 21 Aug 2000 13:04:46 +0300 ::> Hi FreeBSD fans and developers... ::> ::> This is my first question in -CURRENT. ::> ::> Yesterday was the first time I tried to follow the -STABLE line. And I must ::> admit that once again FreeBSD amazed me ;) ::> ::> Running -STABLE rite now (I used to run only -RELEASE before cause I'm ::> haunted by the feeling that the upgrading process will be very complicated, ::> but that's my mistake... The upgrading process was really simple and easy... ::> ;) ) ::> ::> Now to the real question... ::> I have a Compaq Deskpro EP system with onboard Intel 810e AGP VGA Card and ::> onboard sound support (which maybe is AC97 or something similar). After ::> running -STABLE I can use my VGA Card. How about the sound card? Does ::> - -CURRENT support the sound card? Cause if -CURRENT can make my sound card ::> sings, I'd love to give it a try. After all, this isn't a production ::> machine. ::> ::Not yet. Dan Moschuk is working (?) on the driver. There seems to be some work done in Japan. I'm not sure if it works for 810e, but try: http://www.katsurajima.seya.yokohama.jp/ich/ich.c.gz The HomePage is in Japanese, so you have to guess what you have to do. :-) Hope this helps, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: haro@kubota.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 23:44:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E418537B42C for ; Mon, 21 Aug 2000 23:44:47 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA06090; Mon, 21 Aug 2000 23:44:41 -0700 Date: Mon, 21 Aug 2000 23:44:42 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Meyer Cc: Warner Losh , "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <14754.8253.80322.822607@guru.mired.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If the answer from the person who would have to approve the code had > come back "Ok, provide the code and we'll see how well it works in > practice", I'd do the code. But when it appears the code would never > make it into the tree to be used, why waste my time? 'coz we're taking a page from Linus. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Aug 21 23:47:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E823A37B42C for ; Mon, 21 Aug 2000 23:47:53 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA57404; Tue, 22 Aug 2000 00:47:52 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA02074; Tue, 22 Aug 2000 00:47:42 -0600 (MDT) Message-Id: <200008220647.AAA02074@harmony.village.org> To: Mike Meyer Subject: Re: Why no CDR ioctls for SCSI cds? Cc: "Kenneth D. Merry" , current@FreeBSD.ORG In-reply-to: Your message of "Tue, 22 Aug 2000 01:39:57 CDT." <14754.8253.80322.822607@guru.mired.org> References: <14754.8253.80322.822607@guru.mired.org> <14753.62883.183839.508028@guru.mired.org> <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <200008220607.AAA01652@harmony.village.org> Date: Tue, 22 Aug 2000 00:47:42 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14754.8253.80322.822607@guru.mired.org> Mike Meyer writes: : You may well be right, and there are good technical reasons for not : doing this. The only real reason that's been presented for not doing : MMC is that all the non-MMC drives might cause a support : headache. There are sound technical reasons for *not* doing non-MMC : drives, and Ken and I agree on that. Actually, the real reason is that MMC drives that mostly support the standard, but do it wrong in ways that are hard to detect. Those are going to be the worst to try to support. There are some drives out there that just hang when you issue them certain MMC commands, as an example. They shouldn't but they do and you have to be careful not to send them these commands. : If the answer from the person who would have to approve the code had : come back "Ok, provide the code and we'll see how well it works in : practice", I'd do the code. But when it appears the code would never : make it into the tree to be used, why waste my time? I think that you overstate ken's reluctance. If you can come up with a good way to deal with this and have a good error mechanism for those drives that don't support this then I think he might (and I repeat might) be talked into it. I've found Ken quite accepting of code in the past when I've gone to the trouble of doing something. I've found in the past that working code has a way of making people reconsider their opinions of things. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 0:21:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-023.telepath.com [216.14.0.23]) by hub.freebsd.org (Postfix) with SMTP id 7410E37B42C for ; Tue, 22 Aug 2000 00:21:26 -0700 (PDT) Received: (qmail 65801 invoked by uid 100); 22 Aug 2000 07:21:25 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14754.10741.609954.81702@guru.mired.org> Date: Tue, 22 Aug 2000 02:21:25 -0500 (CDT) To: mjacob@feral.com Cc: Warner Losh , "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: References: <14754.8253.80322.822607@guru.mired.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob writes: > > If the answer from the person who would have to approve the code had > > come back "Ok, provide the code and we'll see how well it works in > > practice", I'd do the code. But when it appears the code would never > > make it into the tree to be used, why waste my time? > 'coz we're taking a page from Linus. Does Linus tell people something is a bad idea, and then use it anyway? Or does he just not bother to respond to questions about whether or not something would be a usefull addition? ; Tue, 22 Aug 2000 01:38:57 -0700 (PDT) Received: by teletubbie.het.net.je (Postfix, from userid 500) id 4F2721B21C; Tue, 22 Aug 2000 10:38:56 +0200 (CEST) Date: Tue, 22 Aug 2000 10:38:56 +0200 To: freebsd-current@freebsd.org Subject: Q: encrypted swap Message-ID: <20000822103856.A18347@teletubbie.het.net.je> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i From: walter@belgers.com (Walter Belgers) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Last week I was at USENIX where Niels Provos talked about his implementation of encrypted swap in OpenBSD. What is does is encrypting all memory that gets swapped out, keeping the encryption keys in memory. A test showed that all kinds of interesting things wind up in the swap partition; Niels himself found several passwords and his PGP passphrase on his own laptop.. So, I think having the option to use encrypted swap on FreeBSD would be nice. Is anybody already working on this? If not, how do I get somebody to work on it? ;-) Cheers, Walter. -- Walter Belgers "Si hoc signum legere potes, operis boni in rebus walter@belgers.com Latinis alacribus et fructuosis potiri potes!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 3:30: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from ockle.dev.nanoteq.co.za (ockle.dev.nanoteq.co.za [196.7.114.28]) by hub.freebsd.org (Postfix) with ESMTP id 1656337B423 for ; Tue, 22 Aug 2000 03:29:49 -0700 (PDT) Received: (from johan@localhost) by ockle.dev.nanoteq.co.za (8.9.3/8.9.3) id MAA00806; Tue, 22 Aug 2000 12:40:43 +0200 (SAST) (envelope-from johan) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200008211205530812.0DA63AC7@texasonline.net> Date: Tue, 22 Aug 2000 12:40:43 +0200 (SAST) Organization: Nanoteq From: Johan Kruger To: Gordon Zeigler Subject: RE: Question from a neophyte... Why isn't rc.local being read? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Make sure it's not commented out in rc # Run rc.devfs if readable to customize devfs # if [ -r /etc/rc.devfs ]; then sh /etc/rc.devfs fi # Do traditional (but rather obsolete) rc.local file if it exists. If you # use this file and want to make it programmatic, source /etc/defaults/rc.conf # in /etc/rc.local and add your custom variables to /etc/rc.conf, as # shown below. Please do not put local extensions into /etc/rc itself. # Use /etc/rc.local # # ---- rc.local ---- # if [ -r /etc/defaults/rc.conf ]; then # . /etc/defaults/rc.conf # source_rc_confs # elif [ -r /etc/rc.conf ]; then # . /etc/rc.conf # fi # # ... additional startup conditionals ... # ---- rc.local ---- # if [ -r /etc/rc.local ]; then echo -n 'starting local daemons:' sh /etc/rc.local echo '.' fi On 21-Aug-00 Gordon Zeigler wrote: > I've added startup commands to /etc/rc.local on my 3.4 Stable machine. > > /usr/local/etc/webmin/start # Start webmin > /usr/local/sbin/sshd # Start open ssh > /etc/init.d/apachectl start # Start apache web server > > Yet, these are not starting at reboot... > > What am I missing? Probably something obvious, but it escapes me... > > > > *********** REPLY SEPARATOR *********** > > On 8/21/00 at 9:53 AM Julian Elischer wrote: > >>since config has changed.. where do I set the flags on my debug port >>(sio2?) >>the sio man page has no hints.. >>it looks to me as it if is now controlled differently >>unles I've made a mistake.... >> >> >>julian >> >> >> >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-current" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message ---------------------------------- Unix Software Developer/Engineer E-Mail: Johan Kruger Date: 22-Aug-00 Time: 12:38:46 All good things come to those who ... runs FreeBSD ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 3:37: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from ockle.dev.nanoteq.co.za (ockle.dev.nanoteq.co.za [196.7.114.28]) by hub.freebsd.org (Postfix) with ESMTP id B1E5937B423 for ; Tue, 22 Aug 2000 03:36:44 -0700 (PDT) Received: (from johan@localhost) by ockle.dev.nanoteq.co.za (8.9.3/8.9.3) id MAA00823; Tue, 22 Aug 2000 12:46:53 +0200 (SAST) (envelope-from johan) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <002901c00bce$7b936680$0164a8c0@daemon> Date: Tue, 22 Aug 2000 12:46:53 +0200 (SAST) Organization: Nanoteq From: Johan Kruger To: undergra Subject: RE: error sysinstall Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Probably need a newer sysinstall, now uses character devices Where did you get this sysinstall from, is in on a boot floppy ? If it is, then either the kernel with it's devices doesn't work with the sysinstall you use, or the devices do not exist. On your PC, do a make depend ; make ; make install in /usr/src/release/sysinstall then you use the sysinstall in the installed dir /stand/sysinstall Remember to remake your devices - char devices probably needed. ---------------------------------- Unix Software Developer/Engineer E-Mail: Johan Kruger Date: 22-Aug-00 Time: 12:43:29 All good things come to those who ... runs FreeBSD ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 3:45:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from giasbg01.vsnl.net.in (giasbg01.vsnl.net.in [202.54.12.17]) by hub.freebsd.org (Postfix) with ESMTP id E9D6F37B422 for ; Tue, 22 Aug 2000 03:45:32 -0700 (PDT) Received: from local.vsnl (PPP-174-52.bng.vsnl.net.in [203.197.174.52]) by giasbg01.vsnl.net.in (8.9.3/8.9.3) with SMTP id QAA05988; Tue, 22 Aug 2000 16:11:57 +0500 (GMT+0500) Message-ID: <002601c00c25$aa8f1180$020fe9df@local.vsnl> From: "Infopac Software Ltd" To: "to whom it may concern" Subject: Date: Tue, 22 Aug 2000 15:31:43 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C00C53.C4474D80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C00C53.C4474D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Sirs, =20 =20 JOINT VENTURE OPPORTUNITY =20 =20 INFOPAC Software (India) is interested in a business relationship with = your company in the area of ERP / software projects and solutions: =20 Our capability profile includes: a.. Software projects (offshore / onshore development)=20 b.. ERP development=20 c.. Internet, e-commerce based development=20 d.. Manpower services=20 e.. Wet lease / incubation service for projects We are visiting your country shortly and would like to meet you to = discuss the opportunity further. =20 We are a 55 people company specializing in ERP and E Commerce. Please = do visit our web site www.infopac-erp.com =20 Looking forward to hearing from you, =20 Yours Sincerely, for INFOPAC SOFTWARE LTD Ms.Bhagya Nair Intl. Business Division =20 _________________________________________________________________________= ___________ Infopac Software Limited, No.67, Rustam Bagh, Bangalore-560017, India, = Ph:+91-80-5250767/5255461 Fax:+91-80-5262180, E mail: cas@vsnl.com ------=_NextPart_000_0023_01C00C53.C4474D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Sirs,
 
 
JOINT VENTURE=20 OPPORTUNITY
 
 
INFOPAC Software (India) is interested in a business = relationship with your company in the area of ERP /  software = projects and=20 solutions:
 
Our capability profile includes:
  • Software projects (offshore / = onshore=20 development)=20
  • ERP development=20
  • Internet, e-commerce based = development=20 =20
  • Manpower services=20
  • Wet lease / incubation service = for=20 projects
We are visiting your country shortly = and would=20 like to meet you to discuss the opportunity further.
 
We are a 55 people company = specializing in ERP=20 and E Commerce.  Please do visit our web site www.infopac-erp.com
 
Looking forward to hearing from=20 you,
 
 
Yours Sincerely,
for INFOPAC SOFTWARE=20 LTD
Ms.Bhagya Nair
Intl. Business Division
 
________________________________________________________________= ____________________
Infopac Software Limited, No.67, Rustam Bagh,=20 Bangalore-560017, India, Ph:+91-80-5250767/5255461
Fax:+91-80-5262180, E mail: cas@vsnl.com
------=_NextPart_000_0023_01C00C53.C4474D80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 6:23:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from jarrow.dev.nanoteq.co.za (jarrow.dev.nanoteq.co.za [196.7.114.30]) by hub.freebsd.org (Postfix) with ESMTP id E611E37B422 for ; Tue, 22 Aug 2000 06:23:06 -0700 (PDT) Received: (from rbezuide@localhost) by jarrow.dev.nanoteq.co.za (8.9.3/8.9.3) id PAA00325 for freebsd-current@freebsd.org; Tue, 22 Aug 2000 15:21:18 +0200 (SAST) (envelope-from rbezuide) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 22 Aug 2000 15:21:18 +0200 (SAST) Reply-To: rbezuide@oskar.nanoteq.co.za From: Reinier Bezuidenhout To: freebsd-current@freebsd.org Subject: Realplayer and Yamaha 740C on current Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ... I have a 5.0-current .. kernel compiled of a day or so ago. When I'm using Realplayer7 or plaympeg (package smpeg) to play real audio or mpegs I just get this load "hissing" noise. When I use mpg123 to play a mp3 the sound is OK .. CD sound works fine and games too. Any idea why realaudio (even when playing a local file) and plaympeg seems to corrupt the sound ?? Somehow I recall that this used to work .. but I can't confirm it :) Thanx Reinier ################################################################### # # # R.N. Bezuidenhout NetSeq Firewall # # rbezuide@oskar.nanoteq.co.za http://www.nanoteq.co.za # # # ################################################################### ---------------------------------- Date: 22-Aug-00 Time: 15:16:54 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 6:43:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 90E3A37B423 for ; Tue, 22 Aug 2000 06:43:10 -0700 (PDT) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 1266B1925E; Tue, 22 Aug 2000 08:43:10 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id IAA38838; Tue, 22 Aug 2000 08:43:09 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Tue, 22 Aug 2000 08:43:09 -0500 From: "Jacques A. Vidrine" To: Mike Meyer Cc: current@freebsd.org Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000822084309.D38787@hamlet.nectar.com> References: <14754.2222.927759.462718@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14754.2222.927759.462718@guru.mired.org>; from mwm@mired.org on Mon, Aug 21, 2000 at 11:59:26PM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Aug 21, 2000 at 11:59:26PM -0500, Mike Meyer wrote: > I'm curious - are there any committers who regularly use a system with > LOCALBASE set to something other than /usr/local? I have LOCALBASE=/opt for a couple of years now. OTOH, I also have a symlink from /usr/local -> /opt due to a small but significant number of ports that are not PREFIX clean. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:15:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 0795B37B43C for ; Tue, 22 Aug 2000 07:15:17 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13REpe-0006Yi-00 for current@freebsd.org; Tue, 22 Aug 2000 16:15:14 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id QAA18531 for ; Tue, 22 Aug 2000 16:15:13 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 18004; Tue Aug 22 16:11:21 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7MDqbG00418 for ; Tue, 22 Aug 2000 15:52:37 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008221352.e7MDqbG00418@grimreaper.grondar.za> To: current@freebsd.org Subject: Review requested for /dev/random driver improvements! Date: Tue, 22 Aug 2000 15:52:36 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All Please could those of you with the time and computrons available please review the patches for the entropy (/dev/random) driver at http://people.freebsd.org/~markm/randomdev.patch. NOTES: This code may injure your cat, your computer and/or your bank account; be careful! The code puts the responsibility of reseeding the entropy state variables into a kernel thread; this should make userland a lot snappier. There is a FIFO constructed from TAILQ's to buffer the entropy harvesting; this should further insulate userland from the internal workings. All the crypto and hashing has been broken out into a separate file to make the whole driver less dependant on particular algorithms. There is an (unresolved) issue with panics when the module is unloaded; I'm working on that, but if you get to it before me, your help would be appreciated. Not included in here is a direct tap into the random event stream to allow folks who need to "distill bits" to do their own entropy processing. This is being worked on. Other comments, patches and suggestions welcome! Many thanks to Brian Feldman for the kthreads example, and others for answering my questions online! M To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:18: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from jarrow.dev.nanoteq.co.za (jarrow.dev.nanoteq.co.za [196.7.114.30]) by hub.freebsd.org (Postfix) with ESMTP id 6CEF437B422; Tue, 22 Aug 2000 07:17:52 -0700 (PDT) Received: (from rbezuide@localhost) by jarrow.dev.nanoteq.co.za (8.9.3/8.9.3) id QAA00506; Tue, 22 Aug 2000 16:16:06 +0200 (SAST) (envelope-from rbezuide) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 22 Aug 2000 16:16:05 +0200 (SAST) Reply-To: rbezuide@oskar.nanoteq.co.za From: Reinier Bezuidenhout To: freebsd-multimedia@freebsd.org Subject: Realplayer and Yamaha 740C on current - update Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dit another test ... Used mpg123 with the "-m" option for mono sound (all the thins that "broke" was in mono) and got the same noise ... seems like "mono" sound for the 740C Yamaha is broken ?? Reinier On 22-Aug-00 Reinier Bezuidenhout wrote: > Hi ... > > I have a 5.0-current .. kernel compiled of a day or so ago. > > When I'm using Realplayer7 or plaympeg (package smpeg) to play > real audio or mpegs I just get this load "hissing" noise. > > When I use mpg123 to play a mp3 the sound is OK .. CD sound > works fine and games too. > > Any idea why realaudio (even when playing a local file) and > plaympeg seems to corrupt the sound ?? > > Somehow I recall that this used to work .. but I can't confirm it :) > > Thanx > Reinier > >################################################################### ># # ># R.N. Bezuidenhout NetSeq Firewall # ># rbezuide@oskar.nanoteq.co.za http://www.nanoteq.co.za # ># # >################################################################### > > ---------------------------------- > Date: 22-Aug-00 > Time: 15:16:54 > > This message was sent by XFMail > ---------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message ################################################################### # # # R.N. Bezuidenhout NetSeq Firewall # # rbezuide@oskar.nanoteq.co.za http://www.nanoteq.co.za # # # ################################################################### ---------------------------------- Date: 22-Aug-00 Time: 16:14:17 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:21:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id DB29D37B423 for ; Tue, 22 Aug 2000 07:21:18 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13REti-0006cf-00; Tue, 22 Aug 2000 16:19:26 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id QAA19222; Tue, 22 Aug 2000 16:19:24 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 19080; Tue Aug 22 16:18:47 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7MEJcK00705; Tue, 22 Aug 2000 16:19:39 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008221419.e7MEJcK00705@grimreaper.grondar.za> To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: PATCH: devfs mkIII test & review please. References: <94115.966885593@critter> In-Reply-To: <94115.966885593@critter> ; from Poul-Henning Kamp "Mon, 21 Aug 2000 21:19:53 +0200." Date: Tue, 22 Aug 2000 16:19:38 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > They can also be made by the driver using make_dev_alias(). Cool! Man page please? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:28:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 6A40F37B424 for ; Tue, 22 Aug 2000 07:28:14 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RF24-0006kr-00; Tue, 22 Aug 2000 16:28:04 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id QAA20761; Tue, 22 Aug 2000 16:28:03 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 20405; Tue Aug 22 16:26:31 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7MERFK00829; Tue, 22 Aug 2000 16:27:15 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008221427.e7MERFK00829@grimreaper.grondar.za> To: walter@belgers.com (Walter Belgers) Cc: freebsd-current@FreeBSD.ORG Subject: Re: Q: encrypted swap References: <20000822103856.A18347@teletubbie.het.net.je> In-Reply-To: <20000822103856.A18347@teletubbie.het.net.je> ; from walter@belgers.com (Walter Belgers) "Tue, 22 Aug 2000 10:38:56 +0200." Date: Tue, 22 Aug 2000 16:27:15 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So, I think having the option to use encrypted swap on FreeBSD > would be nice. Is anybody already working on this? If not, how do > I get somebody to work on it? ;-) Ever since the Phoenecians invented money, there has been at least one guaranteed answer to that :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:41:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 9762837B43E for ; Tue, 22 Aug 2000 07:41:07 -0700 (PDT) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.11.0/8.11.0) id e7MEbVu25315; Tue, 22 Aug 2000 15:37:31 +0100 (BST) (envelope-from nik) Date: Tue, 22 Aug 2000 15:37:30 +0100 From: Nik Clayton To: Tony Fleisher Cc: freebsd-current@freebsd.org Subject: Re: problems with /usr/bin/awk Message-ID: <20000822153730.A2180@canyon.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from takhus@takhus.mind.net on Mon, Aug 21, 2000 at 07:17:31PM -0700 Organization: FreeBSD Project Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony, On Mon, Aug 21, 2000 at 07:17:31PM -0700, Tony Fleisher wrote: > I have been running cvsup nightly to grab -current and -ports, > and noticed some strangeness with awk that seemed to start last > week sometime. > > When building /usr/ports/lang/guile, the build exited with an > awk 'internal error' and a log on the console that awk had > exited on signal 6. To test my theory that the problem was > indeed awk (rather than the guile port), I copied over a copy > of awk from a 4.1-R system. After doing so, the guile port was able to > build and install without any problems. Interesting. I bumped into the same problem on -current, but also had the problem if I tried using gawk from the ports (d'oh. I've just realised, our awk is GNU awk). You can get around it by installed nawk from lang/nawk first, and then doing "make AWK=nawk" you build it. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:43: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 297D537B423; Tue, 22 Aug 2000 07:42:58 -0700 (PDT) Received: from cs.strath.ac.uk (posh.dmem.strath.ac.uk [130.159.202.3]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id PAA21743 Tue, 22 Aug 2000 15:42:13 +0100 (BST) Message-ID: <39A2919A.14EB2F14@cs.strath.ac.uk> Date: Tue, 22 Aug 2000 15:43:38 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: rbezuide@oskar.nanoteq.co.za Cc: freebsd-multimedia@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Realplayer and Yamaha 740C on current - update References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Reinier > seems like "mono" sound for the 740C Yamaha is broken ?? I found 'mono' audio was broken on my Yamaha 724F PCI card at the weekend. Cameron said several users have reported this and he has reworked the code in -current to hopefully work around this problem. Roger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:46:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from jarrow.dev.nanoteq.co.za (jarrow.dev.nanoteq.co.za [196.7.114.30]) by hub.freebsd.org (Postfix) with ESMTP id 0EF2537B43C; Tue, 22 Aug 2000 07:46:41 -0700 (PDT) Received: (from rbezuide@localhost) by jarrow.dev.nanoteq.co.za (8.9.3/8.9.3) id QAA11391; Tue, 22 Aug 2000 16:44:08 +0200 (SAST) (envelope-from rbezuide) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <39A2919A.14EB2F14@cs.strath.ac.uk> Date: Tue, 22 Aug 2000 16:44:08 +0200 (SAST) Reply-To: rbezuide@oskar.nanoteq.co.za From: Reinier Bezuidenhout To: Roger Hardiman Subject: Re: Realplayer and Yamaha 740C on current - update Cc: freebsd-current@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Roger .. I cvs-ed the sources for the kernel from yesterday .. but I'll get the latest ones now .. I'm just not sure if Cameron has committed the changes yet .. but in any case ... thanx Cameron !! :) Rgds Reinier On 22-Aug-00 Roger Hardiman wrote: > Reinier > >> seems like "mono" sound for the 740C Yamaha is broken ?? > > > I found 'mono' audio was broken on my Yamaha 724F PCI card > at the weekend. > > Cameron said several users have reported this and he has > reworked the code in -current to hopefully work around > this problem. > > Roger ################################################################### # # # R.N. Bezuidenhout NetSeq Firewall # # rbezuide@oskar.nanoteq.co.za http://www.nanoteq.co.za # # # ################################################################### ---------------------------------- Date: 22-Aug-00 Time: 16:42:39 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:51:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from fleming.cs.strath.ac.uk (fleming.cs.strath.ac.uk [130.159.196.126]) by hub.freebsd.org (Postfix) with ESMTP id 0788937B424; Tue, 22 Aug 2000 07:51:42 -0700 (PDT) Received: from cs.strath.ac.uk (posh.dmem.strath.ac.uk [130.159.202.3]) by fleming.cs.strath.ac.uk (8.8.8/8.8.8) with ESMTP id PAA21956 Tue, 22 Aug 2000 15:51:19 +0100 (BST) Message-ID: <39A293BC.2E78EC01@cs.strath.ac.uk> Date: Tue, 22 Aug 2000 15:52:44 +0100 From: Roger Hardiman Organization: University of Strathclyde X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: rbezuide@oskar.nanoteq.co.za Cc: freebsd-current@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG Subject: Re: Realplayer and Yamaha 740C on current - update References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Reinier Bezuidenhout wrote: > > Roger .. > > I cvs-ed the sources for the kernel from yesterday .. but I'll > get the latest ones now .. I'm just not sure if Cameron has > committed the changes yet .. but in any case ... thanx > Cameron !! :) Cameron changed the 'feeder' code which drives the cards. So, our cards may not work, but he said it is now much easier to work around the problem with the new feeder code. Anyway, we should be able to get this sorted out in the near future. Roger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 7:55: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 784F637B423; Tue, 22 Aug 2000 07:55:02 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id QAA46745; Tue, 22 Aug 2000 16:55:01 +0200 (CEST) (envelope-from asmodai) Date: Tue, 22 Aug 2000 16:55:00 +0200 From: Jeroen Ruigrok van der Werven To: Brian Fundakowski Feldman Cc: current@FreeBSD.ORG Subject: Re: Anyone have newmidi working? Message-ID: <20000822165500.R86398@lucifer.bart.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from green@FreeBSD.ORG on Sat, Aug 19, 2000 at 12:14:26PM -0400 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000819 18:15], Brian Fundakowski Feldman (green@FreeBSD.ORG) wrote: >Newmidi doesn't seem to work. The oplsbc device handling had to be >hacked a bit to support non-PnP SBs, but that's inconsequential. >It probes and boots fine. It seems that newmidi is completely >disconnected from actually being able to work. Doesn't work here. I could forward you my mail I sent the to the other, mayhaps our problems are quite alike. >I haven't gotten any response from the author :-( Does anyone have it >working? I don't see how it could with the current state of the code. Same here. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl The spirit indeed is willing, but the flesh is weak... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:22:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 7F91737B43F for ; Tue, 22 Aug 2000 08:22:28 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id RAA77433; Tue, 22 Aug 2000 17:21:56 +0200 (CEST) (envelope-from asmodai) Date: Tue, 22 Aug 2000 17:21:56 +0200 From: Jeroen Ruigrok van der Werven To: Warner Losh Cc: Mike Meyer , "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000822172155.S86398@lucifer.bart.nl> References: <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <14753.50849.16035.805395@guru.mired.org> <20000821212517.B73232@panzer.kdm.org> <200008220607.AAA01652@harmony.village.org> <14754.8253.80322.822607@guru.mired.org> <200008220647.AAA02074@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200008220647.AAA02074@harmony.village.org>; from imp@village.org on Tue, Aug 22, 2000 at 12:47:42AM -0600 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 08:50], Warner Losh (imp@village.org) wrote: > >Actually, the real reason is that MMC drives that mostly support the >standard, but do it wrong in ways that are hard to detect. Those are >going to be the worst to try to support. There are some drives out >there that just hang when you issue them certain MMC commands, as an >example. They shouldn't but they do and you have to be careful not to >send them these commands. This got parsed by me as: mmc-quirk.h It wouldn't be hard to keep it tracked in a quirk file as per the SCSI disk quirk file. But I am not sure it is elegant. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl There is no joy in smallness. Joy is in the infinite... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:24:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 7F2CC37B43C for ; Tue, 22 Aug 2000 08:24:10 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id RAA80500; Tue, 22 Aug 2000 17:23:38 +0200 (CEST) (envelope-from asmodai) Date: Tue, 22 Aug 2000 17:23:38 +0200 From: Jeroen Ruigrok van der Werven To: "Kenneth D. Merry" Cc: Mike Meyer , Christopher Masto , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000822172337.T86398@lucifer.bart.nl> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821230037.A17035@netmonger.net> <14753.65322.139615.822253@guru.mired.org> <20000821222407.A73879@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <20000821222407.A73879@panzer.kdm.org>; from ken@kdm.org on Mon, Aug 21, 2000 at 10:24:07PM -0600 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 06:25], Kenneth D. Merry (ken@kdm.org) wrote: >It needs an ATAPI passthrough mechanism to work. (FreeBSD doesn't have >one at the moment.) Søren, Matt and me were discussing the ATA/CAM issues so that we might be able to approach ATA through CAM. That would clear a lot. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Another morning, black sunday, coming down again... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:28:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id 1B51437B43F; Tue, 22 Aug 2000 08:28:48 -0700 (PDT) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.51.214]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "caerdonn.eurocontrol.fr", Issuer CN "CA ITM" (verified OK)) by matrix.eurocontrol.fr (Postfix/TLS) with ESMTP id 012B958DC; Tue, 22 Aug 2000 17:28:46 +0200 (CEST) Received: by caerdonn.eurocontrol.fr (Postfix/TLS, from userid 1193) id 1E1824E5C; Tue, 22 Aug 2000 17:28:46 +0200 (CEST) Date: Tue, 22 Aug 2000 17:28:46 +0200 From: Ollivier Robert To: FreeBSD Current Users' list Cc: green@freebsd.org Subject: make buildworld br0ken in libutil Message-ID: <20000822172846.A76574@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian, I'm afraid you broke libutil... Every program using libutil now must depend on libcrypt too. -=-=- ===> libexec/fingerd cc -O -pipe -I/usr/obj/src/src/i386/usr/include -c /src/src/libexec/fingerd/fi ngerd.c cc -O -pipe -I/usr/obj/src/src/i386/usr/include -o fingerd fingerd.o -lutil /usr/obj/src/src/i386/usr/lib/libutil.so: undefined reference to `crypt_set_form at' *** Error code 1 Stop in /src/src/libexec/fingerd. *** Error code 1 -=-=- -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:53:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 31FBA37B423; Tue, 22 Aug 2000 08:53:13 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id RAA26203; Tue, 22 Aug 2000 17:53:09 +0200 (CEST) (envelope-from asmodai) Date: Tue, 22 Aug 2000 17:53:09 +0200 From: Jeroen Ruigrok van der Werven To: Ollivier Robert Cc: "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <20000822175309.U86398@lucifer.bart.nl> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000822172846.A76574@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Tue, Aug 22, 2000 at 05:28:46PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: >Brian, I'm afraid you broke libutil... Every program using libutil now must >depend on libcrypt too. Alternatively the sentiment just rose why we couldn't just collapse the crypt/hash functions of libcrypt into libc. It would make sense. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl I walk, I walk alone, into the promised land... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:54:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id 085CF37B423; Tue, 22 Aug 2000 08:54:40 -0700 (PDT) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.51.214]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "caerdonn.eurocontrol.fr", Issuer CN "CA ITM" (verified OK)) by matrix.eurocontrol.fr (Postfix/TLS) with ESMTP id F21715920; Tue, 22 Aug 2000 17:54:38 +0200 (CEST) Received: by caerdonn.eurocontrol.fr (Postfix/TLS, from userid 1193) id 7A88E4E5C; Tue, 22 Aug 2000 17:54:38 +0200 (CEST) Date: Tue, 22 Aug 2000 17:54:38 +0200 From: Ollivier Robert To: Jeroen Ruigrok van der Werven Cc: FreeBSD Current Users' list , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <20000822175438.B76789@caerdonn.eurocontrol.fr> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000822175309.U86398@lucifer.bart.nl>; from jruigrok@via-net-works.nl on Tue, Aug 22, 2000 at 05:53:09PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Jeroen Ruigrok van der Werven: > Alternatively the sentiment just rose why we couldn't just collapse the > crypt/hash functions of libcrypt into libc. > > It would make sense. It would make even make more sense to convince the other BSD to do the same (haven't checked recently what they do) and do the merge. -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 8:55:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from outland.cyberwar.com (outland.cyberwar.com [208.17.174.42]) by hub.freebsd.org (Postfix) with ESMTP id 88D7E37B424 for ; Tue, 22 Aug 2000 08:55:20 -0700 (PDT) Received: from localhost (billg@localhost) by outland.cyberwar.com (8.11.0/8.11.0) with ESMTP id e7MFtFS55466 for ; Tue, 22 Aug 2000 11:55:15 -0400 (EDT) Date: Tue, 22 Aug 2000 11:55:15 -0400 (EDT) From: "Bill G." To: freebsd-current@freebsd.org Subject: Crash - Build World - Fatal double fault: eip esp ebp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have searched the mailing lists, to no avail (hope I did not miss the answer). I am getting the following output on make world (FreeBSD 5.0-20000820-CURRENT installed, cvsup current source at 11:00AM Eastern Time).. Fatal double fault: eip = 0xc030343c esp = 0xcd025000 ebp = 0xcd025074 panic: double fault syncing disks... 577 577 577 ... I have been having some trouble getting this server up and running with latest code. It's a Dual 600EB running on a Supermicro PIIIDM3 motherboard with 2 128MB PC133 DIMMs (Non-ECC). I am using the on-board U160 SCSI with two 9GB U160 drives.. I am running the R1.5 BIOS for the motherboard.. Any ideas on why I am having trouble or possible suggestions would be much appreciated. Thank you, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9: 0:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 1F0B237B423; Tue, 22 Aug 2000 09:00:40 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id SAA28730; Tue, 22 Aug 2000 18:00:38 +0200 (CEST) (envelope-from asmodai) Date: Tue, 22 Aug 2000 18:00:38 +0200 From: Jeroen Ruigrok van der Werven To: Ollivier Robert Cc: "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <20000822180037.B28016@lucifer.bart.nl> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> <20000822175438.B76789@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000822175438.B76789@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Tue, Aug 22, 2000 at 05:54:38PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 17:55], Ollivier Robert (roberto@eurocontrol.fr) wrote: >According to Jeroen Ruigrok van der Werven: >> Alternatively the sentiment just rose why we couldn't just collapse the >> crypt/hash functions of libcrypt into libc. >> >> It would make sense. > >It would make even make more sense to convince the other BSD to do the same >(haven't checked recently what they do) and do the merge. I very much agree. Would it be sensible for the regular cypherpunks to discuss this with the NetBSD and OpenBSD brothers? Otherwise I would be willing to open this discussion on the appropriate lists. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl The administration of justice is the firmest pillar of government... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9: 8:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5296F37B422 for ; Tue, 22 Aug 2000 09:08:22 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA05683; Tue, 22 Aug 2000 12:08:04 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 22 Aug 2000 12:08:04 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Walter Belgers Cc: freebsd-current@freebsd.org Subject: Re: Q: encrypted swap In-Reply-To: <20000822103856.A18347@teletubbie.het.net.je> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 22 Aug 2000, Walter Belgers wrote: > Last week I was at USENIX where Niels Provos talked about his > implementation of encrypted swap in OpenBSD. What is does is encrypting > all memory that gets swapped out, keeping the encryption keys in memory. > A test showed that all kinds of interesting things wind up in the swap > partition; Niels himself found several passwords and his PGP passphrase > on his own laptop.. > > So, I think having the option to use encrypted swap on FreeBSD would be > nice. Is anybody already working on this? If not, how do I get somebody > to work on it? ;-) Walter, There has been discussion and substantial interest in an encrypted swap interface on the freebsd-security mailing list in the last month or so. It was concluded that it was best to wait until Poul-Henning Kemp finished improved infrastructure, allowing the stacking of devices and layers above devices. This would allow an abstracted "encrypted device" interface, supporting everything from encrypted swap (using a randomized key) to generic protected file systems (one key per partition protecting the file system). This would give substantial protection for those of us with mobile computing devices (generally notebooks) that have a tendancy to walk off in airports, for example :-). As an interim solution, I believe we support swap over NFS, so could swap to a local CFS partition. We could also look at solutions that cause swap partitions to be blanked at shutdown, although that's an inferior solution to true encrypted swap, as one tends to trust strong crypto a little more than the ability to delete the contents of magnetic disk platters :-). So the short of it: infrastructure work is under way that should make encrypted swap an easy addition in the near future. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:15:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from ds-01.itg.discovery.com (ops.itg.discovery.com [198.147.13.130]) by hub.freebsd.org (Postfix) with ESMTP id 8903637B424 for ; Tue, 22 Aug 2000 09:15:34 -0700 (PDT) Received: by ds-01.itg.discovery.com; id MAA02898; Tue, 22 Aug 2000 12:15:12 -0400 (EDT) Received: by bet-su5-23.itg.discovery.com; id QAA01734; Tue, 22 Aug 2000 16:15:10 GMT Message-ID: <39A2A70D.E1198B31@whetstonelogic.com> Date: Tue, 22 Aug 2000 16:15:09 +0000 From: Patrick Gardella X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Kernel panic on fxp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been working for a while to try to figure out a problem I'm having here. I did a buildworld Sunday, and started to get kernel panics on boot when it probed fxp. So I removed fxp from my kernel and loaded it as a module (via loader.conf.local). It paniced. Then I unloaded the if_fxp.ko on startup, and it booted. But if I load the fxp module now, after a full boot, everything is great. Rebooting with fxp in the kernel or loading the module on boot will cause a panic *every* time. Thinking it might be build problem, I redid the build/install/kernel again on Monday, and am having the same problems. The panics only started on the upgrade from a -current dated sometime in early July. As you will see from below, this is an SMP machine (dual P200) with 256 Megs RAM. I am also using NETGRAPH to run PPPoE. Any ideas? Patrick The panic is: Fatal trap 12: page fault while in kernel mode mp_lock=00000005; cpuid = 0; lapic.id=00000000 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc034e304 stack pointer = 0x10:0xc038bea8 frame pointer = 0x10=0xc038bebc code segment = base 0x0, limit 0xfffff, type 0x1b = DPC 0, pres 1, def 32 1, gran 1 processor eflag = interrupt enabled, resume, IOPC=0 current process = 0 (swapper) interrupt mask = net tty bio cam <- SMP:XXX trap number = 12 panic: page fault To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:25:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id EA8D937B43E; Tue, 22 Aug 2000 09:25:53 -0700 (PDT) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id BF9001D147; Tue, 22 Aug 2000 17:25:50 +0100 (BST) Message-ID: <39A2A98E.EC1D33C4@originative.co.uk> Date: Tue, 22 Aug 2000 17:25:50 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok van der Werven Cc: Ollivier Robert , FreeBSD Current Users' list , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> <20000822175438.B76789@caerdonn.eurocontrol.fr> <20000822180037.B28016@lucifer.bart.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok van der Werven wrote: > > -On [20000822 17:55], Ollivier Robert (roberto@eurocontrol.fr) wrote: > >According to Jeroen Ruigrok van der Werven: > >> Alternatively the sentiment just rose why we couldn't just collapse the > >> crypt/hash functions of libcrypt into libc. > >> > >> It would make sense. > > > >It would make even make more sense to convince the other BSD to do the same > >(haven't checked recently what they do) and do the merge. > > I very much agree. > > Would it be sensible for the regular cypherpunks to discuss this with > the NetBSD and OpenBSD brothers? > > Otherwise I would be willing to open this discussion on the appropriate > lists. Is there any current policy on what libc is? It certainly isn't "libc" as required by C and hasn't been for almost ever but there needs to be some rational to its existence otherwise why not fold everything into libc and not bother with any other libraries! A growing libc makes static binaries grow and makes it more difficult to strip out unneeded functionality from a minimalist system install. I'd been inclined to try and move things the other way and strip stuff out of libc into separate libraries but that's obviously not in vogue at the moment. Why does crypt need to be in libc? Not even a significant fraction of applications need crypt? Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:30:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 9D6F837B423; Tue, 22 Aug 2000 09:30:45 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RGwf-0000iE-00; Tue, 22 Aug 2000 18:30:37 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id SAA09540; Tue, 22 Aug 2000 18:30:36 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 9441; Tue Aug 22 18:29:36 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13RGvg-0006xw-00; Tue, 22 Aug 2000 18:29:36 +0200 From: Sheldon Hearn To: Paul Richards Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , "FreeBSD Current Users' list" , green@freebsd.org Subject: Re: make buildworld br0ken in libutil In-reply-to: Your message of "Tue, 22 Aug 2000 17:25:50 +0100." <39A2A98E.EC1D33C4@originative.co.uk> Date: Tue, 22 Aug 2000 18:29:36 +0200 Message-ID: <26779.966961776@axl.fw.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 22 Aug 2000 17:25:50 +0100, Paul Richards wrote: > Is there any current policy on what libc is? For some reason, I seem to remember Bruce Evans once calling it "the kitchen sink". :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:32:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id EF3C337B43F; Tue, 22 Aug 2000 09:32:36 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id KAA12804; Tue, 22 Aug 2000 10:32:03 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id KAA23905; Tue, 22 Aug 2000 10:30:51 -0600 (MDT) (envelope-from nate) Date: Tue, 22 Aug 2000 10:30:51 -0600 (MDT) Message-Id: <200008221630.KAA23905@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Richards Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil In-Reply-To: <39A2A98E.EC1D33C4@originative.co.uk> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> <20000822175438.B76789@caerdonn.eurocontrol.fr> <20000822180037.B28016@lucifer.bart.nl> <39A2A98E.EC1D33C4@originative.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >> Alternatively the sentiment just rose why we couldn't just collapse the > > >> crypt/hash functions of libcrypt into libc. > > >> > > >> It would make sense. > > > > > >It would make even make more sense to convince the other BSD to do the same > > >(haven't checked recently what they do) and do the merge. > > > > I very much agree. > > > > Would it be sensible for the regular cypherpunks to discuss this with > > the NetBSD and OpenBSD brothers? > > > > Otherwise I would be willing to open this discussion on the appropriate > > lists. > > Is there any current policy on what libc is? It certainly isn't "libc" > as required by C and hasn't been for almost ever but there needs to be > some rational to its existence otherwise why not fold everything into > libc and not bother with any other libraries! > > A growing libc makes static binaries grow NOT! Static linking *only* brings in those symbols necessary for the file. It doesn't matter where those files are, they are only brought in if necessary. > and makes it more difficult to > strip out unneeded functionality from a minimalist system install. This is true. > I'd been inclined to try and move things the other way and strip stuff > out of libc into separate libraries but that's obviously not in vogue > at the moment. For what it's worth, I'm in agreement. The 'kitchen sink' approach, although easy tends to make stuff hard to maintain, since you end up with namespace collisions, and you may end up with something you are not aware of that conflicts with routines you are using inside your program. (Think of the recent weak symbol discussion where the library is not using the correct 'global' symbol for read as an example.) > Why does crypt need to be in libc? Not even a significant fraction of > applications need crypt? Agreed. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:39:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 9367137B43F; Tue, 22 Aug 2000 09:39:31 -0700 (PDT) Received: from grimreaper.grondar.za ([196.7.18.138] ident=root) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RH5E-0000nV-00; Tue, 22 Aug 2000 18:39:29 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7MGeIe01497; Tue, 22 Aug 2000 18:40:19 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008221640.e7MGeIe01497@grimreaper.grondar.za> To: Jeroen Ruigrok van der Werven Cc: Ollivier Robert , "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil References: <20000822175309.U86398@lucifer.bart.nl> In-Reply-To: <20000822175309.U86398@lucifer.bart.nl> ; from Jeroen Ruigrok van der Werven "Tue, 22 Aug 2000 17:53:09 +0200." Date: Tue, 22 Aug 2000 18:40:18 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: > >Brian, I'm afraid you broke libutil... Every program using libutil now must > >depend on libcrypt too. > > Alternatively the sentiment just rose why we couldn't just collapse the > crypt/hash functions of libcrypt into libc. Agreed! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 9:43:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 9606037B42C; Tue, 22 Aug 2000 09:43:31 -0700 (PDT) Received: from grimreaper.grondar.za ([196.7.18.138] ident=root) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RH96-0000qM-00; Tue, 22 Aug 2000 18:43:29 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7MGiJe01520; Tue, 22 Aug 2000 18:44:19 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008221644.e7MGiJe01520@grimreaper.grondar.za> To: Paul Richards Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil References: <39A2A98E.EC1D33C4@originative.co.uk> In-Reply-To: <39A2A98E.EC1D33C4@originative.co.uk> ; from Paul Richards "Tue, 22 Aug 2000 17:25:50 +0100." Date: Tue, 22 Aug 2000 18:44:19 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A growing libc makes static binaries grow and makes it more difficult to > strip out unneeded functionality from a minimalist system install. I'd > been inclined to try and move things the other way and strip stuff out > of libc into separate libraries but that's obviously not in vogue at the > moment. Static binaries don't pull in the whole of libc; they just pull in what they need, be it from libc or libcrypt, so size should not change. The _shared_ libc will get bigger, but we'll lose the shared libcrypto. > Why does crypt need to be in libc? Not even a significant fraction of > applications need crypt? Goes for very many libc components. Quite a lot of userland needs libcrypt (not much as a proportion, but a non-insignificant number). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 10: 6: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9395337B423; Tue, 22 Aug 2000 10:06:01 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA12505; Tue, 22 Aug 2000 13:05:54 -0400 (EDT) (envelope-from wollman) Date: Tue, 22 Aug 2000 13:05:54 -0400 (EDT) From: Garrett Wollman Message-Id: <200008221705.NAA12505@khavrinen.lcs.mit.edu> To: Jeroen Ruigrok van der Werven Cc: Ollivier Robert , "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil In-Reply-To: <20000822175309.U86398@lucifer.bart.nl> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> <20000822175309.U86398@lucifer.bart.nl> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: >> Brian, I'm afraid you broke libutil... Every program using libutil now must >> depend on libcrypt too. No. This is precisely why shared libraries have dependencies. For static linking, what Brian has done Just Works. For dynamic linking, libutil needs to depend on libcrypt to get its symbols resolved. (Alternatively you might be able to do it with weak symbols.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 12:11: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from h132-197-97-45.gte.com (h132-197-97-45.gte.com [132.197.97.45]) by hub.freebsd.org (Postfix) with ESMTP id C42AD37B423 for ; Tue, 22 Aug 2000 12:11:01 -0700 (PDT) Received: (from ak03@localhost) by h132-197-97-45.gte.com (8.11.0/8.11.0) id e7MJB1R66381 for freebsd-current@freebsd.org; Tue, 22 Aug 2000 15:11:01 -0400 (EDT) (envelope-from ak03) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 22 Aug 2000 15:11:01 -0400 (EDT) Organization: GTE Laboratories Inc. From: "Alexander N. Kabaev" To: freebsd-current@freebsd.org Subject: Strange messages on -CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am seeing these messages on the -CURRENT box as of FreeBSD kanpc.gte.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Aug 14 10:04:38 EDT 2000 ak03@kanpc.gte.com:/usr/src/sys/compile/KANPC i386 Aug 22 13:07:40 kanpc /kernel: unexpected vn driver lock: 0xc8010d40: type VREG, usecount 2, writecount 1, refcount 25, flags (VOBJBUF) Aug 22 13:07:40 kanpc /kernel: unexpected vn driver lock: 0xc8010d40: type VREG, usecount 2, writecount 1, refcount 25, flags (VOBJBUF) Aug 22 13:07:40 kanpc /kernel: tag VT_UFS, ino 349296, on dev #ad/0x30005 (116, 196613) lock type inode: EXCL (count 1) by pid 5 Aug 22 13:07:40 kanpc /kernel: tag VT_UFS, ino 349296, on dev #ad/0x30005 (116, 196613) lock type inode: EXCL (count 1) by pid 5 ---------------------------------- E-Mail: Alexander N. Kabaev Date: 22-Aug-00 Time: 13:09:40 ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 12:22:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0909F37B422; Tue, 22 Aug 2000 12:22:07 -0700 (PDT) Date: Tue, 22 Aug 2000 15:22:05 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Kenneth D. Merry" Cc: Mike Meyer , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <20000821104114.A67935@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would be _really_ nice if cd(4) supported that ioctl so I could just seek and read from a CD. I had knu trying out my read_cd program, and it doesn't work for SCSI CD-ROMs, seemingly because of this issue :( Would you be adverse to implementeing that ioctl? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 12:55: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 0BDAF37B42C for ; Tue, 22 Aug 2000 12:54:54 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.net ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FZP00BNWLK771@falla.videotron.net> for freebsd-current@FreeBSD.ORG; Tue, 22 Aug 2000 15:45:43 -0400 (EDT) Date: Tue, 22 Aug 2000 15:48:46 -0400 (EDT) From: Bosko Milekic Subject: Re: Kernel panic on fxp In-reply-to: <39A2A70D.E1198B31@whetstonelogic.com> X-Sender: bmilekic@jehovah.technokratis.com To: Patrick Gardella Cc: freebsd-current@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PLEASE read this: http://www.freebsd.org/FAQ/hackers.html#AEN4885 Basically, by just looking at the page fault message, this appears to be the dereferencing of a NULL pointer. That's all that I'm afraid pretty much anybody will be able to conclude from this unless you, at least, provide us with a backtrace as well as an assembly dump of whatever function the crash occured in. On Tue, 22 Aug 2000, Patrick Gardella wrote: > I've been working for a while to try to figure out a problem I'm having > here. > > I did a buildworld Sunday, and started to get kernel panics on boot when > it probed fxp. So I removed fxp from my kernel and loaded it as a > module (via loader.conf.local). It paniced. Then I unloaded the > if_fxp.ko on startup, and it booted. But if I load the fxp module now, > after a full boot, everything is great. Rebooting with fxp in the > kernel or loading the module on boot will cause a panic *every* time. > > Thinking it might be build problem, I redid the build/install/kernel > again on Monday, and am having the same problems. The panics only > started on the upgrade from a -current dated sometime in early July. > > As you will see from below, this is an SMP machine (dual P200) with 256 > Megs RAM. > I am also using NETGRAPH to run PPPoE. > > Any ideas? > > Patrick > > The panic is: > Fatal trap 12: page fault while in kernel mode > mp_lock=00000005; cpuid = 0; lapic.id=00000000 > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc034e304 > stack pointer = 0x10:0xc038bea8 > frame pointer = 0x10=0xc038bebc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPC 0, pres 1, def 32 1, gran 1 > processor eflag = interrupt enabled, resume, IOPC=0 > current process = 0 (swapper) > interrupt mask = net tty bio cam <- SMP:XXX > trap number = 12 > panic: page fault Cheers, Bosko. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 13: 8:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.solexine.fr (mail.solexine.fr [195.114.74.250]) by hub.freebsd.org (Postfix) with ESMTP id 4AA3737B43C for ; Tue, 22 Aug 2000 13:08:30 -0700 (PDT) Received: from mothra (IS~MOTHRA.solexine.fr [195.114.74.245]) by mail.solexine.fr (Post.Office MTA v3.5.3 release 223 ID# 150-63470U200L2S100V35) with ESMTP id fr for ; Tue, 22 Aug 2000 22:08:19 +0200 From: "David TOUITOU" Organization: Solexine To: freebsd-current@freebsd.org Date: Tue, 22 Aug 2000 22:09:22 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: compaq proliant Message-ID: <39A2FA12.26645.155C777B@localhost> References: Your message of "Mon, 21 Aug 2000 18:20:19 GMT" In-reply-to: <28805.966884666@verdi.nethelp.no> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Aug 2000, at 21:04, sthaug@nethelp.no wrote: > > has anyone gotten freebsd (current or other) running on one of these? > > Which Proliant model are you talking about? > > > i've tried 4.0, 4.1, and -current, and the kernel panics on me with > > the following: > > > > sym0: <895a> port 0x1000=0x10ff mem > > 0xb1100000-0xb1101fff,0xb1400000-0xb14003ff irq 11 at device 4.0 on pci1 > > sym0: failed to allocate RAM resources > > We're running 3.4-STABLE on a Proliant 3000 here, and it's working great. > Mind you, this has a Symbios 875 based controller, not 895a as in your > case. Proliant 3000 with 4.1-STABLE here, working great too. -- ...................................................................... David Touitou http://dites-le.com SysAdmin and co Solexine To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 13:29:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8479837B43C; Tue, 22 Aug 2000 13:29:10 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA79931; Tue, 22 Aug 2000 14:29:09 -0600 (MDT) (envelope-from ken) Date: Tue, 22 Aug 2000 14:29:09 -0600 From: "Kenneth D. Merry" To: Brian Fundakowski Feldman Cc: Mike Meyer , current@FreeBSD.org Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000822142909.B79351@panzer.kdm.org> References: <20000821104114.A67935@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from green@FreeBSD.org on Tue, Aug 22, 2000 at 03:22:05PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 22, 2000 at 15:22:05 -0400, Brian Fundakowski Feldman wrote: > One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would > be _really_ nice if cd(4) supported that ioctl so I could just seek > and read from a CD. I had knu trying out my read_cd program, and it > doesn't work for SCSI CD-ROMs, seemingly because of this issue :( > > Would you be adverse to implementeing that ioctl? That's fine. As it turns out, I've had additional discussions with Mike Meyer and Matt Jacob and Mike will probably be implementing MMC CD-R support. That ioctl will probably be a part of it. The functionality you're looking for is part of a larger issue of supporting CDDA reads in the cd(4) driver. That's needed to support AudioFS. (As well as to support doing a straight read off the CD when an audio CD is in there.) The main problem is that different drives use different commands to read audio data. MMC-compliant drives are one case, but there are a lot more drives out there that use varying methods to read audio data. It'll also take some tweaking to get the driver to support blocksizes that aren't multiples of 512 bytes. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 14: 4:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9F72D37B422; Tue, 22 Aug 2000 14:04:55 -0700 (PDT) Date: Tue, 22 Aug 2000 17:04:54 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Garrett Wollman Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , FreeBSD Current Users' list Subject: Re: make buildworld br0ken in libutil In-Reply-To: <200008221705.NAA12505@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 22 Aug 2000, Garrett Wollman wrote: > < said: > > > -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: > >> Brian, I'm afraid you broke libutil... Every program using libutil now must > >> depend on libcrypt too. > > No. This is precisely why shared libraries have dependencies. For > static linking, what Brian has done Just Works. For dynamic linking, > libutil needs to depend on libcrypt to get its symbols resolved. > (Alternatively you might be able to do it with weak symbols.) Further, I cannot see how the make world _could_ be broken! This is strange, since I've never had the problem at all and have tested this change in several places (5.0 and 4.1). {"/home/green"}$ objdump --all-headers /usr/lib/libutil.so | grep NEEDED /usr/libexec/elf/objdump: /usr/lib/libutil.so: no symbols NEEDED libcrypt.so.2 > -GAWollman -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 14:49:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f15.pav1.hotmail.com [64.4.31.15]) by hub.freebsd.org (Postfix) with ESMTP id D9ADE37B422 for ; Tue, 22 Aug 2000 14:49:11 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 22 Aug 2000 14:49:11 -0700 Received: from 209.213.222.214 by pv1fd.pav1.hotmail.msn.com with HTTP; Tue, 22 Aug 2000 GMT X-Originating-IP: [209.213.222.214] Reply-To: jake@3ware.com From: "Joel Jacobson" To: freebsd-current@freebsd.org Subject: Re: compaq proliant Date: Tue, 22 Aug 2000 21:49:11 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Aug 2000 21:49:11.0799 (UTC) FILETIME=[CE9C1070:01C00C82] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > sym0: <895a> port 0x1000=0x10ff mem > > >0xb1100000-0xb1101fff,0xb1400000-0xb14003ff irq 11 at > > device 4.0 on >pci1 sym0: failed to allocate RAM resources > > > We're running 3.4-STABLE on a Proliant 3000 here, and it's > working >great. > > Mind you, this has a Symbios 875 based controller, not 895a > as in your >case. > >Proliant 3000 with 4.1-STABLE here, working great too. it's a ML330. recompiling the kernel without sym support seems to make it boot (i wasnt using the scsi controller anyway). which is an interesting data point, actually: there were no scsi devices plugged into the controller. in any event, im up and running. this may now serve as a data point for whomever is maintaining the sym driver... - j ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 14:51:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5CA2837B422 for ; Tue, 22 Aug 2000 14:51:56 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id OAA24137; Tue, 22 Aug 2000 14:51:46 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id OAA21203; Tue, 22 Aug 2000 14:51:45 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 22 Aug 2000 14:51:45 -0700 (PDT) Message-Id: <200008222151.OAA21203@vashon.polstra.com> To: current@freebsd.org Reply-To: current@freebsd.org Cc: patrick@whetstonelogic.com Subject: Re: Kernel panic on fxp In-Reply-To: <39A2A70D.E1198B31@whetstonelogic.com> References: <39A2A70D.E1198B31@whetstonelogic.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <39A2A70D.E1198B31@whetstonelogic.com>, Patrick Gardella wrote: > I've been working for a while to try to figure out a problem I'm having > here. > > I did a buildworld Sunday, and started to get kernel panics on boot when > it probed fxp. So I removed fxp from my kernel and loaded it as a > module (via loader.conf.local). It paniced. Then I unloaded the > if_fxp.ko on startup, and it booted. But if I load the fxp module now, > after a full boot, everything is great. Rebooting with fxp in the > kernel or loading the module on boot will cause a panic *every* time. > > Thinking it might be build problem, I redid the build/install/kernel > again on Monday, and am having the same problems. The panics only > started on the upgrade from a -current dated sometime in early July. A problem with these precise symptoms was fixed in revision 1.54 of "src/sys/sys/mbuf.h". Make sure your sources really are up-to-date. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 15:26:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from acs-24-154-11-41.zoominternet.net (acs-24-154-11-41.zoominternet.net [24.154.11.41]) by hub.freebsd.org (Postfix) with ESMTP id 0776737B424 for ; Tue, 22 Aug 2000 15:26:05 -0700 (PDT) Received: from cvzoom.net (localhost [127.0.0.1]) by acs-24-154-11-41.zoominternet.net (8.11.0/8.11.0) with ESMTP id e7MMQ1n86344; Tue, 22 Aug 2000 18:26:02 -0400 (EDT) (envelope-from dmmiller@cvzoom.net) Message-ID: <39A2FDF8.7092132F@cvzoom.net> Date: Tue, 22 Aug 2000 18:26:00 -0400 From: Donn Miller X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Cc: Mark Murray Subject: Re: Review requested for /dev/random driver improvements! References: <200008221352.e7MDqbG00418@grimreaper.grondar.za> Content-Type: multipart/mixed; boundary="------------9A701D2338811FB98D791C32" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------9A701D2338811FB98D791C32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Murray wrote: > > Hi All > > Please could those of you with the time and computrons available > please review the patches for the entropy (/dev/random) driver at > http://people.freebsd.org/~markm/randomdev.patch. I'm getting some errors trying to build this. Attached is my make.log that shows the errors. -Donn --------------9A701D2338811FB98D791C32 Content-Type: text/plain; charset=us-ascii; name="make.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="make.log" linking kernel yarrow.o: In function `random_kthread': yarrow.o(.text+0x36): undefined reference to `yarrow_hash_init' yarrow.o(.text+0xe3): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x103): undefined reference to `yarrow_hash_iterate' yarrow.o: In function `reseed': yarrow.o(.text+0x317): undefined reference to `yarrow_hash_init' yarrow.o(.text+0x334): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x34b): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x37a): undefined reference to `yarrow_hash_init' yarrow.o(.text+0x392): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x3a3): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x3b6): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x3c6): undefined reference to `yarrow_hash_finish' yarrow.o(.text+0x3f5): undefined reference to `yarrow_hash_init' yarrow.o(.text+0x406): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x42c): undefined reference to `yarrow_hash_iterate' yarrow.o(.text+0x449): undefined reference to `yarrow_hash_finish' yarrow.o(.text+0x457): undefined reference to `yarrow_encrypt_init' yarrow.o(.text+0x481): undefined reference to `yarrow_encrypt' yarrow.o: In function `read_random': yarrow.o(.text+0x5d0): undefined reference to `yarrow_encrypt' yarrow.o(.text+0x645): undefined reference to `yarrow_encrypt' yarrow.o: In function `generator_gate': yarrow.o(.text+0x78b): undefined reference to `yarrow_encrypt' yarrow.o(.text+0x7a6): undefined reference to `yarrow_encrypt_init' *** Error code 1 Stop in /usr/src/sys/compile/CUSTOM. --------------9A701D2338811FB98D791C32-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 16:13: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from 21stcentury.net (24-148-36-243.na.21stcentury.net [24.148.36.243]) by hub.freebsd.org (Postfix) with ESMTP id 149D337B423 for ; Tue, 22 Aug 2000 16:13:00 -0700 (PDT) Received: from localhost (vacuum@localhost) by technotronic.21stcentury.net (8.11.0/8.9.3) with ESMTP id e7M4oxA09015 for ; Mon, 21 Aug 2000 23:51:03 -0500 (CDT) (envelope-from vacuum@technotronic.com) X-Authentication-Warning: technotronic.21stcentury.net: vacuum owned process doing -bs Date: Mon, 21 Aug 2000 23:50:59 -0500 (CDT) From: vacuum X-Sender: vacuum@technotronic.21stcentury.net To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 17:44:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id 0A89537B422 for ; Tue, 22 Aug 2000 17:44:53 -0700 (PDT) Received: from confusion.net (user-2ive75b.dialup.mindspring.com [165.247.28.171]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id UAA14269; Tue, 22 Aug 2000 20:44:36 -0400 (EDT) Message-ID: <39A31E23.CA9D2DC5@confusion.net> Date: Tue, 22 Aug 2000 20:43:15 -0400 From: Laurence Berland Organization: B.R.A.T.T. X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: Mike Meyer , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On a vaguely related topic, after much searching I can't seem to see one way or the other if we can do a complete bit-by-bit copy of a cd with either cdrecord or burncd, though it's possible I'm looking in the wrong place. Laurence "Kenneth D. Merry" wrote: > [snip] -- Laurence Berland <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Windows 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. http://stuy.debate.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 18: 3:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from vallesnet.org (vallesnet.org [194.224.210.5]) by hub.freebsd.org (Postfix) with ESMTP id 74F0F37B422 for ; Tue, 22 Aug 2000 18:03:50 -0700 (PDT) Received: from daemon (29-BARC-X34.libre.retevision.es [62.82.12.29]) by vallesnet.org (8.9.3/8.9.3) with SMTP id DAA31617 for ; Wed, 23 Aug 2000 03:05:03 +0200 Message-ID: <007201c00c9e$37529920$0164a8c0@daemon> From: "undergra" To: Subject: error with fetchmail + sendmail Date: Wed, 23 Aug 2000 03:05:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Helo, yesterday i actualiced from FreeBSD 4.1 to FreeBSD 5.0 current. and i am having some problems whith sendmail and fetchmail. the sendmail version is 8.11.0. the problem began whit this file aliases.db because as the sendmail logs said, it wasnt able to see this file at /etc/mail. so i made a new one whit "makehash". but now i have got another problem. when i run fetchmail to get my e-mail it freezes. it happens in the following way: (fetchmail -v) -latest version- fetchmail: 5.4.4 interrogando machine.com (protocolo auto) en Wed, 23 Aug 2000 01:38:54 +0200 (CEST) fetchmail: 5.4.4 interrogando machine.com (protocolo IMAP) en Wed, 23 Aug 2000 01:38:54 +0200 (CEST) fetchmail: 5.4.4 interrogando machine.com (protocolo POP3) en Wed, 23 Aug 2000 01:38:55 +0200 (CEST) fetchmail: POP3< +OK QPOP (version ?) at machine.com starting. <9004.966987776@machine.com> fetchmail: POP3> USER myuser fetchmail: POP3< +OK Password required for myuser. fetchmail: POP3> PASS * fetchmail: POP3< +OK myuser has 1 visible message (0 hidden) in 2267 octets. fetchmail: POP3> STAT fetchmail: POP3< +OK 1 2267 fetchmail: POP3> LAST fetchmail: POP3< +OK 0 is the last read message. 1 mensaje para koji en machine.com (2267 octetos). fetchmail: POP3> LIST fetchmail: POP3< +OK 1 visible messages (2267 octets) fetchmail: POP3< 1 2267 fetchmail: POP3< . fetchmail: POP3> TOP 1 99999999 fetchmail: POP3< +OK Message follows leyendo mensaje 1 de 1 (2267 octetos) fetchmail: SMTP< 220 daemon.org ESMTP Sendmail 8.11.0/8.11.0; Wed, 23 Aug 2000 01:39:00 +0200 (CEST) fetchmail: SMTP> EHLO localhost fetchmail: SMTP< 250-daemon.org Hello localhost [127.0.0.1], pleased to meet you fetchmail: SMTP< 250-ENHANCEDSTATUSCODES fetchmail: SMTP< 250-EXPN fetchmail: SMTP< 250-VERB fetchmail: SMTP< 250-8BITMIME fetchmail: SMTP< 250-SIZE fetchmail: SMTP< 250-DSN fetchmail: SMTP< 250-ONEX fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250-XUSR fetchmail: SMTP< 250 HELP fetchmail: SMTP> MAIL FROM: SIZE=2267 fetchmail: SMTP< 250 2.1.0 ... Sender ok fetchmail: SMTP> RCPT TO: and then freezes. the error that i get fron sendmail when the "fetchmail" is running is as it follows: Aug 23 01:35:28 daemon sendmail[3980]: e7MNPQG03980: lost input channel from localhost [127.0.0.1] to MTA after rcpt is there somebody who would help me whist this fail? thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 18:20:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1242037B443 for ; Tue, 22 Aug 2000 18:20:38 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id TAA82624; Tue, 22 Aug 2000 19:20:32 -0600 (MDT) (envelope-from ken) Date: Tue, 22 Aug 2000 19:20:32 -0600 From: "Kenneth D. Merry" To: Laurence Berland Cc: Mike Meyer , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? Message-ID: <20000822192032.A82571@panzer.kdm.org> References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <39A31E23.CA9D2DC5@confusion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39A31E23.CA9D2DC5@confusion.net>; from stuyman@confusion.net on Tue, Aug 22, 2000 at 08:43:15PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: > On a vaguely related topic, after much searching I can't seem to see one > way or the other if we can do a complete bit-by-bit copy of a cd with > either cdrecord or burncd, though it's possible I'm looking in the wrong > place. I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in ports/audio) can do it as well. As far as getting an image, you can use dd to dump off an image of a CD if it is a standard ISO9660 CD. (I've used that method to clone CDs before.) If it uses a blocksize other than 2048 bytes, though, you can't use dd with the SCSI cd driver. There may be CD rippers that can pull the data off into an image, though. I don't know for sure. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 18:57:49 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 8E0FA37B424 for ; Tue, 22 Aug 2000 18:57:40 -0700 (PDT) Received: by border.alcanet.com.au id <115278>; Wed, 23 Aug 2000 11:57:18 +1000 Content-return: prohibited Date: Wed, 23 Aug 2000 11:57:15 +1000 From: Peter Jeremy Subject: buildworld dies "undefined reference to crypt_des" To: freebsd-current@FreeBSD.ORG Mail-followup-to: freebsd-current@freebsd.org Message-Id: <00Aug23.115718est.115278@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The `building everything' stage of make buildworld is dying as below. The following patch fix lets my buildworld get beyond that point (but it's still running so I don't know if there are problems elsewhere). (I don't think the patch is the right fix, but it solved my immediate problem). Index: Makefile =================================================================== RCS file: /home/CVSROOT/src/bin/csh/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- Makefile 2000/07/07 08:27:59 1.20 +++ Makefile 2000/08/23 01:49:45 @@ -36,8 +36,8 @@ # utilities of the same name are handled with the associated manpage, # builtin.1 in share/man/man1/. -DPADD= ${LIBTERMCAP} ${LIBCRYPT} -LDADD= -ltermcap -lcrypt +DPADD= ${LIBTERMCAP} ${LIBCRYPT} ${LIBDESCRYPT} +LDADD= -ltermcap -lcrypt -ldescrypt LINKS= ${BINDIR}/csh ${BINDIR}/tcsh ============ cc -O -pipe -I/3.0/cvs/src/bin/csh/../../contrib/tcsh -I/3.0/cvs/src/bin/csh -I. -D_PATH_TCSHELL='"/usr/obj/3.0/cvs/src/i386/bin/csh"' -Wall -Wformat -I/usr/obj/3.0/cvs/src/i386/usr/include -c /3.0/cvs/src/bin/csh/../../contrib/tcsh/tc.who.c cc -O -pipe -I/3.0/cvs/src/bin/csh/../../contrib/tcsh -I/3.0/cvs/src/bin/csh -I. -D_PATH_TCSHELL='"/usr/obj/3.0/cvs/src/i386/bin/csh"' -Wall -Wformat -I/usr/obj/3.0/cvs/src/i386/usr/include -c /3.0/cvs/src/bin/csh/tc.defs.c cc -O -pipe -I/3.0/cvs/src/bin/csh/../../contrib/tcsh -I/3.0/cvs/src/bin/csh -I. -D_PATH_TCSHELL='"/usr/obj/3.0/cvs/src/i386/bin/csh"' -Wall -Wformat -I/usr/obj/3.0/cvs/src/i386/usr/include -static -o csh sh.o sh.dir.o sh.dol.o sh.err.o sh.exec.o sh.char.o sh.exp.o sh.file.o sh.func.o sh.glob.o sh.hist.o sh.init.o sh.lex.o sh.misc.o sh.parse.o sh.print.o sh.proc.o sh.sem.o sh.set.o sh.time.o glob.o mi.termios.o tw.help.o tw.init.o tw.parse.o tw.spell.o tw.comp.o tw.color.o ed.chared.o ed.defns.o ed.init.o ed.inputl.o ed.refresh.o ed.screen.o ed.xmap.o ed.term.o tc.alloc.o tc.bind.o tc.const.o tc.disc.o tc.func.o tc.os.o tc.printf.o tc.prompt.o tc.sched.o tc.sig.o tc.str.o tc.vers.o tc.who.o tc.defs.o -ltermcap -lcrypt /usr/obj/3.0/cvs/src/i386/usr/lib/libcrypt.a(crypt.o)(.rodata+0x4): undefined reference to `crypt_des' *** Error code 1 Stop in /3.0/cvs/src/bin/csh. *** Error code 1 Stop in /3.0/cvs/src/bin. *** Error code 1 Stop in /3.0/cvs/src. *** Error code 1 Stop in /3.0/cvs/src. *** Error code 1 Stop in /3.0/cvs/src. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 20: 1: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 120D437B423; Tue, 22 Aug 2000 20:00:57 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id NAA16811; Wed, 23 Aug 2000 13:00:23 +1000 Date: Wed, 23 Aug 2000 13:00:14 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Garrett Wollman Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil In-Reply-To: <200008221705.NAA12505@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 22 Aug 2000, Garrett Wollman wrote: > > -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: > >> Brian, I'm afraid you broke libutil... Every program using libutil now must > >> depend on libcrypt too. > > No. This is precisely why shared libraries have dependencies. For > static linking, what Brian has done Just Works. For dynamic linking, > libutil needs to depend on libcrypt to get its symbols resolved. > (Alternatively you might be able to do it with weak symbols.) Actually, the change breaks static linking for most programs that use one of the functions described in login_cap(3). This is because it adds login_setcrypt() to the existing spam in login_cap.c. This breaks limits, cron, crontab, inetd and sendmail in /usr/src alone. For dynamic linking, it only wastes time and space for the rarely actually used library. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 22:15:57 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-051.telepath.com [216.14.0.51]) by hub.freebsd.org (Postfix) with SMTP id EDFE337B43C for ; Tue, 22 Aug 2000 22:15:54 -0700 (PDT) Received: (qmail 84141 invoked by uid 100); 23 Aug 2000 05:15:54 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.24074.101991.63641@guru.mired.org> Date: Wed, 23 Aug 2000 00:15:54 -0500 (CDT) To: Mark Murray Cc: freebsd-current@FreeBSD.ORG Subject: Re: Q: encrypted swap In-Reply-To: <200008221427.e7MERFK00829@grimreaper.grondar.za> References: <20000822103856.A18347@teletubbie.het.net.je> <200008221427.e7MERFK00829@grimreaper.grondar.za> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray writes: > > So, I think having the option to use encrypted swap on FreeBSD > > would be nice. Is anybody already working on this? If not, how do > > I get somebody to work on it? ;-) > Ever since the Phoenecians invented money, there has been at least > one guaranteed answer to that :-) Actually, two. You can *always* work on something yourself! ; Tue, 22 Aug 2000 22:37:50 -0700 (PDT) Received: (qmail 84525 invoked by uid 100); 23 Aug 2000 05:37:25 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.25365.580303.530891@guru.mired.org> Date: Wed, 23 Aug 2000 00:37:25 -0500 (CDT) To: Brian Fundakowski Feldman Cc: "Kenneth D. Merry" , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: References: <20000821104114.A67935@panzer.kdm.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Fundakowski Feldman writes: > One thing that's missing is the ioctl CDRIOCSETBLOCKSIZE. It would > be _really_ nice if cd(4) supported that ioctl so I could just seek > and read from a CD. I had knu trying out my read_cd program, and it > doesn't work for SCSI CD-ROMs, seemingly because of this issue :( Yup - none of the CDR ioctls (and that's one) are supported by cd. > Would you be adverse to implementeing that ioctl? I'm planning on implementing all the CDR ioctls for SCSI cds. BTW, are those documented somewhere? I mean, I can work out what they should do, but they still ought to be on a man page. Soren? ; Tue, 22 Aug 2000 22:54:33 -0700 (PDT) Received: from grimreaper.grondar.za ([196.7.18.138] ident=root) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RTUb-00076w-00; Wed, 23 Aug 2000 07:54:30 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7N5tGe09068; Wed, 23 Aug 2000 07:55:16 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008230555.e7N5tGe09068@grimreaper.grondar.za> To: Donn Miller Cc: current@freebsd.org Subject: Re: Review requested for /dev/random driver improvements! References: <39A2FDF8.7092132F@cvzoom.net> In-Reply-To: <39A2FDF8.7092132F@cvzoom.net> ; from Donn Miller "Tue, 22 Aug 2000 18:26:00 -0400." Date: Wed, 23 Aug 2000 07:55:15 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm getting some errors trying to build this. Attached is my make.log > that shows the errors. The one that's there now should fix this (I forgot to include a 1-line patch to sys/conf/files). Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 23: 2: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-251.telepath.com [216.14.0.251]) by hub.freebsd.org (Postfix) with SMTP id D360137B43C for ; Tue, 22 Aug 2000 23:02:00 -0700 (PDT) Received: (qmail 85044 invoked by uid 100); 23 Aug 2000 06:01:59 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.26839.743103.399203@guru.mired.org> Date: Wed, 23 Aug 2000 01:01:59 -0500 (CDT) To: "Jacques A. Vidrine" Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: <20000822084309.D38787@hamlet.nectar.com> References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jacques A. Vidrine writes: > On Mon, Aug 21, 2000 at 11:59:26PM -0500, Mike Meyer wrote: > > I'm curious - are there any committers who regularly use a system with > > LOCALBASE set to something other than /usr/local? > > I have LOCALBASE=/opt for a couple of years now. > > OTOH, I also have a symlink from /usr/local -> /opt due to a small > but significant number of ports that are not PREFIX clean. Um - why? If you removed the setting of LOCALBASE in that case, you wouldn't change the disk layout at all. However, I was wondering if there was anyone who could fix things that weren't PREFIX clean who would also find them on a regular basis. That's not you. Thanx, ; Tue, 22 Aug 2000 23:46:33 -0700 (PDT) Received: from grimreaper.grondar.za ([196.7.18.138] ident=root) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RUIv-0007fI-00; Wed, 23 Aug 2000 08:46:29 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7N6lFe09716; Wed, 23 Aug 2000 08:47:15 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008230647.e7N6lFe09716@grimreaper.grondar.za> To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? References: <14755.26839.743103.399203@guru.mired.org> In-Reply-To: <14755.26839.743103.399203@guru.mired.org> ; from Mike Meyer "Wed, 23 Aug 2000 01:01:59 EST." Date: Wed, 23 Aug 2000 08:47:15 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > However, I was wondering if there was anyone who could fix things that > weren't PREFIX clean who would also find them on a regular > basis. That's not you. There is a non-trivial Perl5 LOCALBASE problem that I'm trying to get my head around. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Aug 22 23:51: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by hub.freebsd.org (Postfix) with ESMTP id 4DB3037B43F; Tue, 22 Aug 2000 23:51:01 -0700 (PDT) Received: by teletubbie.het.net.je (Postfix, from userid 500) id 52CD81B21C; Wed, 23 Aug 2000 08:51:00 +0200 (CEST) Date: Wed, 23 Aug 2000 08:51:00 +0200 To: Robert Watson Cc: freebsd-current@freebsd.org Subject: Re: Q: encrypted swap Message-ID: <20000823085100.A32468@teletubbie.het.net.je> References: <20000822103856.A18347@teletubbie.het.net.je> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from rwatson@freebsd.org on Tue, Aug 22, 2000 at 12:08:04PM -0400 From: walter@belgers.com (Walter Belgers) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > So, I think having the option to use encrypted swap on FreeBSD would be > > nice. Is anybody already working on this? If not, how do I get somebody > > to work on it? ;-) > > There has been discussion and substantial interest in an encrypted swap > interface on the freebsd-security mailing list in the last month or so. Ah. I guess I didn't use the right search criteria when checking the mailing lists then. Sorry. > So the short of it: infrastructure work is under way that should make > encrypted swap an easy addition in the near future. The layered approach sounds like a fine one to me. I can wait until Poul-Henning gets to it :) Cheers, Walter. -- Walter Belgers "Si hoc signum legere potes, operis boni in rebus walter@belgers.com Latinis alacribus et fructuosis potiri potes!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 0:17: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from scully.zoominternet.net (scully.zoominternet.net [63.67.120.3]) by hub.freebsd.org (Postfix) with SMTP id D62C937B422 for ; Wed, 23 Aug 2000 00:16:39 -0700 (PDT) Received: (qmail 24589 invoked from network); 23 Aug 2000 07:16:36 -0000 Received: from acs-24-154-11-41.zoominternet.net (HELO cvzoom.net) (24.154.11.41) by scully.zoominternet.net with SMTP; 23 Aug 2000 07:16:36 -0000 Message-ID: <39A37A54.6CF2E88E@cvzoom.net> Date: Wed, 23 Aug 2000 03:16:36 -0400 From: Donn Miller X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Cc: Mark Murray Subject: Re: Review requested for /dev/random driver improvements! References: <39A2FDF8.7092132F@cvzoom.net> <200008230555.e7N5tGe09068@grimreaper.grondar.za> Content-Type: multipart/mixed; boundary="------------C5A7BAC5ED586306F5139E1F" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------C5A7BAC5ED586306F5139E1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Murray wrote: > > > I'm getting some errors trying to build this. Attached is my make.log > > that shows the errors. > > The one that's there now should fix this (I forgot to include a 1-line > patch to sys/conf/files). I just tried the patch, which completed successfully. But now, I'm getting these errors (see attached make.log). -Donn --------------C5A7BAC5ED586306F5139E1F Content-Type: text/plain; charset=iso-8859-1; name="make.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="make.log" cc -c -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../in= clude -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D= 2 ../../i386/i386/genassym.c sh ../../kern/genassym.sh genassym.o > assym.s rm -f param.c cp ../../conf/param.c . perl5 ../../kern/vnode_if.pl -h ../../kern/vnode_if.src cc -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu= al -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../inclu= de -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D2 = -c ../../i386/linux/linux_genassym.c sh ../../kern/genassym.sh linux_genassym.o > linux_assym.h perl5 ../../kern/vnode_if.pl -c ../../kern/vnode_if.src perl5 ../../kern/makeobjops.pl -h ../../kern/device_if.m perl5 ../../kern/makeobjops.pl -h ../../kern/bus_if.m perl5 ../../kern/makeobjops.pl -h ../../kern/linker_if.m perl5 ../../kern/makeobjops.pl -h ../../dev/ppbus/ppbus_if.m perl5 ../../kern/makeobjops.pl -h ../../isa/isa_if.m perl5 ../../kern/makeobjops.pl -h ../../pci/pci_if.m rm -f .newdep mkdep -a -f .newdep -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wn= ested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -= Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../..= -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-st= ack-boundary=3D2 ../../dev/ed/if_ed_pci.c ../../dev/md/md.c ../../dev/nul= ldev/nulldev.c ../../dev/ppbus/if_plip.c ../../dev/ppbus/lpt.c ../../de= v/ppbus/ppb_1284.c ../../dev/ppbus/ppb_base.c ../../dev/ppbus/ppb_msq.c = =2E./../dev/ppbus/ppbconf.c ../../dev/ppbus/ppi.c ../../dev/randomdev/ha= rvest.c ../../dev/randomdev/randomdev.c ../../dev/randomdev/yarrow.c ../= =2E./dev/randomdev/hash.c ../../crypto/blowfish/bf_cbc.c ../../crypto/bl= owfish/bf_enc.c ../../crypto/blowfish/bf_skey.c ../../dev/sound/isa/ad18= 16.c ../../dev/sound/isa/es1888.c ../../dev/sound/isa/ess.c ../../dev/s= ound/isa/gusc.c ../../dev/sound/isa/mss.c ../../dev/sound/isa/sb.c ../..= /dev/sound/isa/sbc.c ../../dev/sound/pci/csa.c ../../dev/sound/pci/csapc= m.c ../../dev/sound/pci/ds1.c ../../dev/sound/pci/emu10k1.c ../../dev/s= ound/pci/es137x.c ../../dev/sound/pci/neomagic.c ../../dev/sound/pci/sol= o.c ../../dev/sound/pci/t4dwave.c ../../dev/sound/pci/via82c686.c ../../= dev/sound/pcm/ac97.c ../../dev/sound/pcm/channel.c ../../dev/sound/pcm/d= sp.c ../../dev/sound/pcm/fake.c ../../dev/sound/pcm/feeder.c ../../dev/= sound/pcm/mixer.c ../../dev/sound/pcm/sound.c ../../gnu/ext2fs/ext2_allo= c.c ../../gnu/ext2fs/ext2_balloc.c ../../gnu/ext2fs/ext2_inode.c ../../g= nu/ext2fs/ext2_inode_cnv.c ../../gnu/ext2fs/ext2_linux_balloc.c ../../g= nu/ext2fs/ext2_linux_ialloc.c ../../gnu/ext2fs/ext2_lookup.c ../../gnu/e= xt2fs/ext2_subr.c ../../gnu/ext2fs/ext2_vfsops.c ../../gnu/ext2fs/ext2_v= nops.c ../../isa/isa_common.c ../../isa/isahint.c ../../isa/pnp.c ../../= isa/pnpparse.c ../../isofs/cd9660/cd9660_bmap.c ../../isofs/cd9660/cd966= 0_lookup.c ../../isofs/cd9660/cd9660_node.c ../../isofs/cd9660/cd9660_rr= ip.c ../../isofs/cd9660/cd9660_util.c ../../isofs/cd9660/cd9660_vfsops.c= ../../isofs/cd9660/cd9660_vnops.c ../../kern/imgact_aout.c ../../kern/i= mgact_elf.c ../../kern/imgact_shell.c ../../kern/init_main.c ../../kern/= init_sysent.c ../../kern/kern_acct.c ../../kern/kern_acl.c ../../kern/ke= rn_cap.c ../../kern/kern_clock.c ../../kern/kern_conf.c ../../kern/kern_= descrip.c ../../kern/kern_environment.c ../../kern/kern_event.c ../../k= ern/kern_exec.c ../../kern/kern_exit.c ../../kern/kern_fork.c ../../kern= /kern_intr.c ../../kern/kern_jail.c ../../kern/kern_kthread.c ../../kern= /kern_ktrace.c ../../kern/kern_linker.c ../../kern/kern_lock.c ../../ker= n/kern_lockf.c ../../kern/kern_malloc.c ../../kern/kern_mib.c ../../kern= /kern_module.c ../../kern/kern_ntptime.c ../../kern/kern_physio.c ../../= kern/kern_proc.c ../../kern/kern_prot.c ../../kern/kern_resource.c ../..= /kern/kern_shutdown.c ../../kern/kern_sig.c ../../kern/kern_subr.c ../..= /kern/kern_switch.c ../../kern/kern_synch.c ../../kern/kern_syscalls.c = =2E./../kern/kern_sysctl.c ../../kern/kern_tc.c ../../kern/kern_threads.c= ../../kern/kern_time.c ../../kern/kern_timeout.c ../../kern/kern_xxx.c = ../../kern/link_aout.c ../../kern/link_elf.c ../../kern/md5c.c ../../ke= rn/subr_autoconf.c ../../kern/subr_blist.c ../../kern/subr_bus.c ../../k= ern/subr_devstat.c ../../kern/subr_disk.c ../../kern/subr_disklabel.c ..= /../kern/subr_diskslice.c ../../kern/subr_eventhandler.c ../../kern/subr= _kobj.c ../../kern/subr_log.c ../../kern/subr_module.c ../../kern/subr_p= rf.c ../../kern/subr_prof.c ../../kern/subr_rman.c ../../kern/subr_scanf= =2Ec ../../kern/subr_taskqueue.c ../../kern/subr_xxx.c ../../kern/sys_g= eneric.c ../../kern/sys_pipe.c ../../kern/sys_process.c ../../kern/sys_s= ocket.c ../../kern/sysv_ipc.c ../../kern/sysv_msg.c ../../kern/sysv_sem.= c ../../kern/sysv_shm.c ../../kern/tty.c ../../kern/tty_compat.c ../../k= ern/tty_conf.c ../../kern/tty_cons.c ../../kern/tty_pty.c ../../kern/tty= _subr.c ../../kern/tty_tty.c ../../kern/uipc_accf.c ../../kern/uipc_doma= in.c ../../kern/uipc_mbuf.c ../../kern/uipc_mbuf2.c ../../kern/uipc_prot= o.c ../../kern/uipc_socket.c ../../kern/uipc_socket2.c ../../kern/uipc_s= yscalls.c ../../kern/uipc_usrreq.c ../../kern/vfs_aio.c ../../kern/vfs_b= io.c ../../kern/vfs_cache.c ../../kern/vfs_cluster.c ../../kern/vfs_conf= =2Ec ../../kern/vfs_default.c ../../kern/vfs_init.c ../../kern/vfs_looku= p.c ../../kern/vfs_subr.c ../../kern/vfs_syscalls.c ../../kern/vfs_vnops= =2Ec ../../libkern/arc4random.c ../../libkern/bcd.c ../../libkern/index.= c ../../libkern/inet_ntoa.c ../../libkern/qsort.c ../../libkern/random.c= ../../libkern/rindex.c ../../libkern/scanc.c ../../libkern/skpc.c ../.= =2E/libkern/strcat.c ../../libkern/strcmp.c ../../libkern/strcpy.c ../..= /libkern/strlen.c ../../libkern/strncmp.c ../../libkern/strncpy.c ../../= libkern/strtol.c ../../libkern/strtoq.c ../../libkern/strtoul.c ../../li= bkern/strtouq.c ../../miscfs/deadfs/dead_vnops.c ../../miscfs/fifofs/fif= o_vnops.c ../../miscfs/procfs/procfs_ctl.c ../../miscfs/procfs/procfs_db= regs.c ../../miscfs/procfs/procfs_fpregs.c ../../miscfs/procfs/procfs_ma= p.c ../../miscfs/procfs/procfs_mem.c ../../miscfs/procfs/procfs_note.c = =2E./../miscfs/procfs/procfs_regs.c ../../miscfs/procfs/procfs_rlimit.c = =2E./../miscfs/procfs/procfs_status.c ../../miscfs/procfs/procfs_subr.c = =2E./../miscfs/procfs/procfs_type.c ../../miscfs/procfs/procfs_vfsops.c = =2E./../miscfs/procfs/procfs_vnops.c ../../miscfs/specfs/spec_vnops.c ..= /../msdosfs/msdosfs_conv.c ../../msdosfs/msdosfs_denode.c ../../msdosfs/= msdosfs_fat.c ../../msdosfs/msdosfs_lookup.c ../../msdosfs/msdosfs_vfsop= s.c ../../msdosfs/msdosfs_vnops.c ../../net/bpf.c ../../net/bpf_filter.c= ../../net/if.c ../../net/if_ethersubr.c ../../net/if_faith.c ../../net/= if_gif.c ../../net/if_loop.c ../../net/if_media.c ../../net/if_mib.c ..= /../net/if_ppp.c ../../net/if_sl.c ../../net/if_tun.c ../../net/intrq.c = =2E./../net/net_osdep.c ../../net/ppp_tty.c ../../net/radix.c ../../net/= raw_cb.c ../../net/raw_usrreq.c ../../net/route.c ../../net/rtsock.c ../= =2E./net/slcompress.c ../../netinet/if_ether.c ../../netinet/igmp.c ../.= =2E/netinet/in.c ../../netinet/in_gif.c ../../netinet/in_pcb.c ../../net= inet/in_proto.c ../../netinet/in_rmx.c ../../netinet/ip_ecn.c ../../neti= net/ip_encap.c ../../netinet/ip_flow.c ../../netinet/ip_icmp.c ../../net= inet/ip_input.c ../../netinet/ip_mroute.c ../../netinet/ip_output.c ../= =2E./netinet/raw_ip.c ../../netinet/tcp_input.c ../../netinet/tcp_output= =2Ec ../../netinet/tcp_subr.c ../../netinet/tcp_timer.c ../../netinet/tc= p_usrreq.c ../../netinet/udp_usrreq.c ../../netinet6/dest6.c ../../netin= et6/frag6.c ../../netinet6/icmp6.c ../../netinet6/in6.c ../../netinet6/i= n6_cksum.c ../../netinet6/in6_gif.c ../../netinet6/in6_ifattach.c ../..= /netinet6/in6_pcb.c ../../netinet6/in6_prefix.c ../../netinet6/in6_proto= =2Ec ../../netinet6/in6_rmx.c ../../netinet6/in6_src.c ../../netinet6/ip= 6_forward.c ../../netinet6/ip6_input.c ../../netinet6/ip6_mroute.c ../.= =2E/netinet6/ip6_output.c ../../netinet6/mld6.c ../../netinet6/nd6.c ../= =2E./netinet6/nd6_nbr.c ../../netinet6/nd6_rtr.c ../../netinet6/raw_ip6.= c ../../netinet6/route6.c ../../netinet6/scope6.c ../../netinet6/udp6_ou= tput.c ../../netinet6/udp6_usrreq.c ../../nfs/nfs_bio.c ../../nfs/nfs_no= de.c ../../nfs/nfs_nqlease.c ../../nfs/nfs_serv.c ../../nfs/nfs_socket.c= ../../nfs/nfs_srvcache.c ../../nfs/nfs_subs.c ../../nfs/nfs_syscalls.c = =2E./../nfs/nfs_vfsops.c ../../nfs/nfs_vnops.c ../../pci/pci.c ../../pci= /pcisupport.c ../../posix4/ksched.c ../../posix4/p1003_1b.c ../../posix4= /posix4_mib.c ../../ufs/ffs/ffs_alloc.c ../../ufs/ffs/ffs_balloc.c ../.= =2E/ufs/ffs/ffs_inode.c ../../ufs/ffs/ffs_snapshot.c ../../ufs/ffs/ffs_s= oftdep.c ../../ufs/ffs/ffs_softdep_stub.c ../../ufs/ffs/ffs_subr.c ../..= /ufs/ffs/ffs_tables.c ../../ufs/ffs/ffs_vfsops.c ../../ufs/ffs/ffs_vnops= =2Ec ../../ufs/mfs/mfs_vfsops.c ../../ufs/mfs/mfs_vnops.c ../../ufs/ufs= /ufs_bmap.c ../../ufs/ufs/ufs_extattr.c ../../ufs/ufs/ufs_ihash.c ../../= ufs/ufs/ufs_inode.c ../../ufs/ufs/ufs_lookup.c ../../ufs/ufs/ufs_quota.c= ../../ufs/ufs/ufs_vfsops.c ../../ufs/ufs/ufs_vnops.c ../../vm/default_= pager.c ../../vm/device_pager.c ../../vm/phys_pager.c ../../vm/swap_page= r.c ../../vm/vm_fault.c ../../vm/vm_glue.c ../../vm/vm_init.c ../../vm/v= m_kern.c ../../vm/vm_map.c ../../vm/vm_meter.c ../../vm/vm_mmap.c ../../= vm/vm_object.c ../../vm/vm_page.c ../../vm/vm_pageout.c ../../vm/vm_page= r.c ../../vm/vm_swap.c ../../vm/vm_unix.c ../../vm/vm_zone.c ../../vm/vn= ode_pager.c ../../compat/linux/linux_file.c ../../compat/linux/linux_ioc= tl.c ../../compat/linux/linux_ipc.c ../../compat/linux/linux_mib.c ../.= =2E/compat/linux/linux_misc.c ../../compat/linux/linux_signal.c ../../co= mpat/linux/linux_socket.c ../../compat/linux/linux_stats.c ../../compat/= linux/linux_util.c ../../dev/ata/ata-all.c ../../dev/ata/ata-disk.c ../.= =2E/dev/ata/ata-dma.c ../../dev/ata/atapi-all.c ../../dev/ata/atapi-cd.c= ../../dev/ed/if_ed.c ../../dev/ed/if_ed_isa.c ../../dev/eisa/eisaconf.c= ../../dev/fb/fb.c ../../dev/fb/splash.c ../../dev/fb/vga.c ../../dev/kb= d/atkbd.c ../../dev/kbd/atkbdc.c ../../dev/kbd/kbd.c ../../dev/syscons/s= chistory.c ../../dev/syscons/scmouse.c ../../dev/syscons/scterm.c ../..= /dev/syscons/scterm-dumb.c ../../dev/syscons/scterm-sc.c ../../dev/sysco= ns/scvgarndr.c ../../dev/syscons/scvidctl.c ../../dev/syscons/scvtb.c ..= /../dev/syscons/syscons.c ../../dev/syscons/sysmouse.c ../../i386/apm/ap= m.c ../../i386/i386/atomic.c ../../i386/i386/autoconf.c ../../i386/i386= /bios.c ../../i386/i386/busdma_machdep.c ../../i386/i386/elf_machdep.c .= =2E/../i386/i386/i686_mem.c ../../i386/i386/identcpu.c ../../i386/i386/i= n_cksum.c ../../i386/i386/initcpu.c ../../i386/i386/k6_mem.c ../../i386= /i386/machdep.c ../../i386/i386/math_emulate.c ../../i386/i386/mem.c ../= =2E./i386/i386/nexus.c ../../i386/i386/pmap.c ../../i386/i386/procfs_mac= hdep.c ../../i386/i386/sys_machdep.c ../../i386/i386/trap.c ../../i386/i= 386/userconfig.c ../../i386/i386/vm86.c ../../i386/i386/vm_machdep.c ..= /../i386/isa/clock.c ../../i386/isa/intr_machdep.c ../../i386/isa/ipl_fu= ncs.c ../../i386/isa/isa.c ../../i386/isa/isa_dma.c ../../i386/isa/mse.c= ../../i386/isa/npx.c ../../i386/isa/pcibus.c ../../i386/linux/imgact_li= nux.c ../../i386/linux/linux_dummy.c ../../i386/linux/linux_machdep.c ..= /../i386/linux/linux_sysent.c ../../i386/linux/linux_sysvec.c ../../isa/= atkbd_isa.c ../../isa/atkbdc_isa.c ../../isa/fd.c ../../isa/ppc.c ../../= isa/psm.c ../../isa/sio.c ../../isa/syscons_isa.c ../../isa/vga_isa.c .= =2E/../kern/subr_diskmbr.c ../../libkern/divdi3.c ../../libkern/moddi3.c = ../../libkern/qdivrem.c ../../libkern/udivdi3.c ../../libkern/umoddi3.c = param.c vnode_if.c hints.c config.c ../../i386/i386/genassym.c env MKDEP_CPP=3D"cc -E" mkdep -a -f .newdep -x assembler-with-cpp -DLOCO= RE -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Ws= trict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qu= al -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../inclu= de -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D2 = =2E./../i386/i386/bioscall.s ../../i386/i386/exception.s ../../i386/i386= /globals.s ../../i386/i386/support.s ../../i386/i386/swtch.s ../../i386/= linux/linux_locore.s ../../i386/i386/locore.s rm -f .depend mv -f .newdep .depend touch hack.c perl5 ../../kern/makeobjops.pl -c ../../kern/device_if.m; cc -c -march=3D= pentium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat= -extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNE= L -include opt_global.h -elf -mpreferred-stack-boundary=3D2 device_if.c= cc -elf -shared -nostdlib hack.c -o hack.So rm -f hack.c perl5 ../../kern/makeobjops.pl -c ../../kern/bus_if.m; cc -c -march=3Dpe= ntium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototyp= es -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-e= xtensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL = -include opt_global.h -elf -mpreferred-stack-boundary=3D2 bus_if.c perl5 ../../kern/makeobjops.pl -c ../../kern/linker_if.m; cc -c -march=3D= pentium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-protot= ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat= -extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNE= L -include opt_global.h -elf -mpreferred-stack-boundary=3D2 linker_if.c= cc -c -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../in= clude -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D= 2 ../../dev/md/md.c perl5 ../../kern/makeobjops.pl -c ../../dev/ppbus/ppbus_if.m; cc -c -mar= ch=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-p= rototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -ff= ormat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_= KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D2 ppbus_= if.c cc -c -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../in= clude -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D= 2 ../../dev/randomdev/harvest.c cc -c -march=3Dpentium -O -pipe -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast= -qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../in= clude -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=3D= 2 ../../dev/randomdev/yarrow.c In file included from ../../dev/randomdev/yarrow.c:49: In file included from ../../dev/randomdev/harvest.c:41: =2E./../dev/randomdev/hash.h:77: redefinition of `struct yarrowhash' =2E./../dev/randomdev/hash.h:83: redefinition of `struct yarrowkey' =2E./../dev/randomdev/hash.h:88: warning: redundant redeclaration of `yar= row_hash_init' in same scope =2E./../dev/randomdev/hash.h:42: warning: previous declaration of `yarrow= _hash_init' =2E./../dev/randomdev/hash.h:89: warning: redundant redeclaration of `yar= row_hash_iterate' in same scope =2E./../dev/randomdev/hash.h:43: warning: previous declaration of `yarrow= _hash_iterate' =2E./../dev/randomdev/hash.h:90: warning: redundant redeclaration of `yar= row_hash_finish' in same scope =2E./../dev/randomdev/hash.h:44: warning: previous declaration of `yarrow= _hash_finish' =2E./../dev/randomdev/hash.h:91: warning: redundant redeclaration of `yar= row_encrypt_init' in same scope =2E./../dev/randomdev/hash.h:45: warning: previous declaration of `yarrow= _encrypt_init' =2E./../dev/randomdev/hash.h:92: warning: redundant redeclaration of `yar= row_encrypt' in same scope =2E./../dev/randomdev/hash.h:46: warning: previous declaration of `yarrow= _encrypt' =2E./../dev/randomdev/hash.h:123: redefinition of `struct yarrowhash' =2E./../dev/randomdev/hash.h:129: redefinition of `struct yarrowkey' =2E./../dev/randomdev/hash.h:134: warning: redundant redeclaration of `ya= rrow_hash_init' in same scope =2E./../dev/randomdev/hash.h:88: warning: previous declaration of `yarrow= _hash_init' =2E./../dev/randomdev/hash.h:135: warning: redundant redeclaration of `ya= rrow_hash_iterate' in same scope =2E./../dev/randomdev/hash.h:89: warning: previous declaration of `yarrow= _hash_iterate' =2E./../dev/randomdev/hash.h:136: warning: redundant redeclaration of `ya= rrow_hash_finish' in same scope =2E./../dev/randomdev/hash.h:90: warning: previous declaration of `yarrow= _hash_finish' =2E./../dev/randomdev/hash.h:137: warning: redundant redeclaration of `ya= rrow_encrypt_init' in same scope =2E./../dev/randomdev/hash.h:91: warning: previous declaration of `yarrow= _encrypt_init' =2E./../dev/randomdev/hash.h:138: warning: redundant redeclaration of `ya= rrow_encrypt' in same scope =2E./../dev/randomdev/hash.h:92: warning: previous declaration of `yarrow= _encrypt' =2E./../dev/randomdev/hash.h:77: redefinition of `struct yarrowhash' =2E./../dev/randomdev/hash.h:83: redefinition of `struct yarrowkey' =2E./../dev/randomdev/hash.h:88: warning: redundant redeclaration of `yar= row_hash_init' in same scope =2E./../dev/randomdev/hash.h:42: warning: previous declaration of `yarrow= _hash_init' =2E./../dev/randomdev/hash.h:89: warning: redundant redeclaration of `yar= row_hash_iterate' in same scope =2E./../dev/randomdev/hash.h:43: warning: previous declaration of `yarrow= _hash_iterate' =2E./../dev/randomdev/hash.h:90: warning: redundant redeclaration of `yar= row_hash_finish' in same scope =2E./../dev/randomdev/hash.h:44: warning: previous declaration of `yarrow= _hash_finish' =2E./../dev/randomdev/hash.h:91: warning: redundant redeclaration of `yar= row_encrypt_init' in same scope =2E./../dev/randomdev/hash.h:45: warning: previous declaration of `yarrow= _encrypt_init' =2E./../dev/randomdev/hash.h:92: warning: redundant redeclaration of `yar= row_encrypt' in same scope =2E./../dev/randomdev/hash.h:46: warning: previous declaration of `yarrow= _encrypt' =2E./../dev/randomdev/hash.h:123: redefinition of `struct yarrowhash' =2E./../dev/randomdev/hash.h:129: redefinition of `struct yarrowkey' =2E./../dev/randomdev/hash.h:134: warning: redundant redeclaration of `ya= rrow_hash_init' in same scope =2E./../dev/randomdev/hash.h:88: warning: previous declaration of `yarrow= _hash_init' =2E./../dev/randomdev/hash.h:135: warning: redundant redeclaration of `ya= rrow_hash_iterate' in same scope =2E./../dev/randomdev/hash.h:89: warning: previous declaration of `yarrow= _hash_iterate' =2E./../dev/randomdev/hash.h:136: warning: redundant redeclaration of `ya= rrow_hash_finish' in same scope =2E./../dev/randomdev/hash.h:90: warning: previous declaration of `yarrow= _hash_finish' =2E./../dev/randomdev/hash.h:137: warning: redundant redeclaration of `ya= rrow_encrypt_init' in same scope =2E./../dev/randomdev/hash.h:91: warning: previous declaration of `yarrow= _encrypt_init' =2E./../dev/randomdev/hash.h:138: warning: redundant redeclaration of `ya= rrow_encrypt' in same scope =2E./../dev/randomdev/hash.h:92: warning: previous declaration of `yarrow= _encrypt' =2E./../dev/randomdev/harvest.c:84: warning: no previous prototype for `r= andom_set_wakeup' =2E./../dev/randomdev/harvest.c:91: warning: no previous prototype for `r= andom_set_wakeup_exit' *** Error code 1 *** Error code 1 2 errors --------------C5A7BAC5ED586306F5139E1F-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 0:20: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom0-104.telepath.com [216.14.0.104]) by hub.freebsd.org (Postfix) with SMTP id ABDD937B506 for ; Wed, 23 Aug 2000 00:19:52 -0700 (PDT) Received: (qmail 87176 invoked by uid 100); 23 Aug 2000 07:19:51 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.31511.258290.94085@guru.mired.org> Date: Wed, 23 Aug 2000 02:19:51 -0500 (CDT) To: Mark Murray Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: <200008230647.e7N6lFe09716@grimreaper.grondar.za> References: <14755.26839.743103.399203@guru.mired.org> <200008230647.e7N6lFe09716@grimreaper.grondar.za> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray writes: > > However, I was wondering if there was anyone who could fix things that > > weren't PREFIX clean who would also find them on a regular > > basis. That's not you. > There is a non-trivial Perl5 LOCALBASE problem that I'm trying to > get my head around. If this is the problem with perl modules installing in /usr/local no matter where LOCALBASE points, I reported it at one point. Non-trivial is an understatement. ; Wed, 23 Aug 2000 00:40:29 -0700 (PDT) Received: (qmail 87447 invoked by uid 100); 23 Aug 2000 07:40:28 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.32748.510248.196059@guru.mired.org> Date: Wed, 23 Aug 2000 02:40:28 -0500 (CDT) To: Mark Murray Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: <200008230647.e7N6lFe09716@grimreaper.grondar.za> References: <14755.26839.743103.399203@guru.mired.org> <200008230647.e7N6lFe09716@grimreaper.grondar.za> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray writes: > > However, I was wondering if there was anyone who could fix things that > > weren't PREFIX clean who would also find them on a regular > > basis. That's not you. > There is a non-trivial Perl5 LOCALBASE problem that I'm trying to > get my head around. I'm actually discussing one of the PR's related to this now, and had a thought. Is it possible to specify an installation directory in the perl module installation process? If so, then the bsd.port.mk mechanism needs to be tweaked to use that to set things to LOCALBASE (well, PREFIX), and the perl build should add $(LOCALBASE)/lib/5.6.0 to the search path for modules. Thanx, Message-Id: <200008230806.KAA64799@freebsd.dk> Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <14755.25365.580303.530891@guru.mired.org> from Mike Meyer at "Aug 23, 2000 00:37:25 am" To: mwm@mired.org (Mike Meyer) Date: Wed, 23 Aug 2000 10:06:47 +0200 (CEST) Cc: green@FreeBSD.ORG (Brian Fundakowski Feldman), ken@kdm.org (Kenneth D. Merry), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Mike Meyer wrote: > > I'm planning on implementing all the CDR ioctls for SCSI cds. > > BTW, are those documented somewhere? I mean, I can work out what they > should do, but they still ought to be on a man page. Soren? Uhm, no man page I'm afraid, but I'll answer any questions you might have... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 1:24:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 066C037B509 for ; Wed, 23 Aug 2000 01:24:31 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id IAA46758; Wed, 23 Aug 2000 08:49:47 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200008230649.IAA46758@freebsd.dk> Subject: Re: Why no CDR ioctls for SCSI cds? In-Reply-To: <39A31E23.CA9D2DC5@confusion.net> from Laurence Berland at "Aug 22, 2000 08:43:15 pm" To: stuyman@confusion.net (Laurence Berland) Date: Wed, 23 Aug 2000 08:49:47 +0200 (CEST) Cc: ken@kdm.org (Kenneth D. Merry), mwm@mired.org (Mike Meyer), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Laurence Berland wrote: > On a vaguely related topic, after much searching I can't seem to see one > way or the other if we can do a complete bit-by-bit copy of a cd with > either cdrecord or burncd, though it's possible I'm looking in the wrong > place. Uhm, I've had some success with changing the READ_CD flags in atapi-cd from 0x10 to 0xf8, that will make the driver read the entire block (2352bytes) no matter what format it is. Then burning it is bitch since DAO mode is not in the official sources yet, but with a bit of enginuity it can be done.. Or use cdrdao on a SCSI burner... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 2:37:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 6B55237B422 for ; Wed, 23 Aug 2000 02:37:24 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RWyB-0003Ar-00; Wed, 23 Aug 2000 11:37:15 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id LAA10550; Wed, 23 Aug 2000 11:37:14 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 10474; Wed Aug 23 11:36:48 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7N9bZr10249; Wed, 23 Aug 2000 11:37:35 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008230937.e7N9bZr10249@grimreaper.grondar.za> To: Donn Miller Cc: current@freebsd.org, Mark Murray Subject: Re: Review requested for /dev/random driver improvements! References: <39A37A54.6CF2E88E@cvzoom.net> In-Reply-To: <39A37A54.6CF2E88E@cvzoom.net> ; from Donn Miller "Wed, 23 Aug 2000 03:16:36 -0400." Date: Wed, 23 Aug 2000 11:37:35 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I just tried the patch, which completed successfully. But now, I'm > getting these errors (see attached make.log). Clean out your tree and reapply the patches; they got applied twice to some files :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 2:44: 0 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 6BAC137B424; Wed, 23 Aug 2000 02:43:55 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id LAA79922; Wed, 23 Aug 2000 11:43:52 +0200 (CEST) (envelope-from asmodai) Date: Wed, 23 Aug 2000 11:43:52 +0200 From: Jeroen Ruigrok van der Werven To: Ollivier Robert Cc: "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <20000823114352.G78405@lucifer.bart.nl> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000822172846.A76574@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Tue, Aug 22, 2000 at 05:28:46PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: >Brian, I'm afraid you broke libutil... Every program using libutil now must >depend on libcrypt too. > >-=-=- >===> libexec/fingerd >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -c /src/src/libexec/fingerd/fi >ngerd.c >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -o fingerd fingerd.o -lutil >/usr/obj/src/src/i386/usr/lib/libutil.so: undefined reference to `crypt_set_form >at' >*** Error code 1 > >Stop in /src/src/libexec/fingerd. >*** Error code 1 I get the same thing, even with Brian's latest commit. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Haste makes waste... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 2:45:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from scully.zoominternet.net (scully.zoominternet.net [63.67.120.3]) by hub.freebsd.org (Postfix) with SMTP id D19EF37B423 for ; Wed, 23 Aug 2000 02:45:19 -0700 (PDT) Received: (qmail 23876 invoked from network); 23 Aug 2000 09:45:19 -0000 Received: from acs-24-154-11-41.zoominternet.net (24.154.11.41) by scully.zoominternet.net with SMTP; 23 Aug 2000 09:45:19 -0000 Date: Wed, 23 Aug 2000 05:45:19 -0400 (EDT) From: Donn Miller X-Sender: dmmiller@acs-24-154-11-41.zoominternet.net To: Mark Murray Cc: current@freebsd.org Subject: Re: Review requested for /dev/random driver improvements! In-Reply-To: <200008230937.e7N9bZr10249@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Mark Murray wrote: > > I just tried the patch, which completed successfully. But now, I'm > > getting these errors (see attached make.log). > > Clean out your tree and reapply the patches; they got applied twice to some > files :-) OK, earlier I had done just that. After re-compiling and rebooting, my machine hangs at the beginning point of the boot stage, where it says "Pentium F00F bug detected". The boot just halts right there. There was no panic, just a dead hang. -Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 3:13:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 0A4AA37B424 for ; Wed, 23 Aug 2000 03:13:34 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RXXH-0003nM-00 for current@freebsd.org; Wed, 23 Aug 2000 12:13:31 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id MAA16809 for ; Wed, 23 Aug 2000 12:13:30 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 16650; Wed Aug 23 12:12:39 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13RXWR-00038r-00 for current@FreeBSD.org; Wed, 23 Aug 2000 12:12:39 +0200 To: current@freebsd.org Subject: HEADS UP: default mount(8) output format changed Date: Wed, 23 Aug 2000 12:12:39 +0200 Message-ID: <12080.967025559@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, Again, this is hardly worth a HEADS UP. The default output format for mount(8) has changed; sync and async read and writes statistics aren't printed unless the -v option is used. This does not apply to the output produced by the -p option, which has never printed these statistics. I've checked that this doesn't break any rc or periodic scripts, but if you use the output of mount(8) (without -p) to feed some specialized parser, make sure you add the -v option to its invocation. Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 3:15:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 7A9EE37B424 for ; Wed, 23 Aug 2000 03:15:24 -0700 (PDT) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id 1A0AF1D140; Wed, 23 Aug 2000 11:15:18 +0100 (BST) Message-ID: <39A3A435.11ABCD8C@originative.co.uk> Date: Wed, 23 Aug 2000 11:15:17 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: Laurence Berland , Mike Meyer , current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? References: <14753.20681.165961.352066@guru.mired.org> <20000821104114.A67935@panzer.kdm.org> <14753.42672.286077.409965@guru.mired.org> <20000821163458.A70871@panzer.kdm.org> <14753.47379.141329.994631@guru.mired.org> <20000821175657.A71753@panzer.kdm.org> <39A31E23.CA9D2DC5@confusion.net> <20000822192032.A82571@panzer.kdm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kenneth D. Merry" wrote: > > On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: > > On a vaguely related topic, after much searching I can't seem to see one > > way or the other if we can do a complete bit-by-bit copy of a cd with > > either cdrecord or burncd, though it's possible I'm looking in the wrong > > place. > > I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in > ports/audio) can do it as well. > > As far as getting an image, you can use dd to dump off an image of a CD if > it is a standard ISO9660 CD. (I've used that method to clone CDs before.) That didn't seem to work when I tried it a couple of days ago. Got a "device not configured" error. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 4: 8: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 5105F37B423 for ; Wed, 23 Aug 2000 04:07:58 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RYNl-0004k0-00; Wed, 23 Aug 2000 13:07:45 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id NAA26050; Wed, 23 Aug 2000 13:07:44 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 25928; Wed Aug 23 13:07:15 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7NB81r10453; Wed, 23 Aug 2000 13:08:01 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008231108.e7NB81r10453@grimreaper.grondar.za> To: Donn Miller Cc: current@freebsd.org Subject: Re: Review requested for /dev/random driver improvements! References: In-Reply-To: ; from Donn Miller "Wed, 23 Aug 2000 05:45:19 -0400." Date: Wed, 23 Aug 2000 13:08:01 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Clean out your tree and reapply the patches; they got applied twice to some > > files :-) > > OK, earlier I had done just that. After re-compiling and rebooting, my > machine hangs at the beginning point of the boot stage, where it says > "Pentium F00F bug detected". The boot just halts right there. There was > no panic, just a dead hang. Please drop into the debugger and see if you can find out what it is doing. (Or just where the hang is happening). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 4:52:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C247837B424 for ; Wed, 23 Aug 2000 04:52:45 -0700 (PDT) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 20EC11925D; Wed, 23 Aug 2000 06:52:44 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id GAA44588; Wed, 23 Aug 2000 06:52:44 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Wed, 23 Aug 2000 06:52:43 -0500 From: "Jacques A. Vidrine" To: Mike Meyer Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000823065243.A43477@hamlet.nectar.com> References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14755.26839.743103.399203@guru.mired.org>; from mwm@mired.org on Wed, Aug 23, 2000 at 01:01:59AM -0500 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 01:01:59AM -0500, Mike Meyer wrote: > Um - why? If you removed the setting of LOCALBASE in that case, you > wouldn't change the disk layout at all. I prefer installed executables, data files, and man pages to refer to /opt. Duh. > However, I was wondering if there was anyone who could fix things that > weren't PREFIX clean who would also find them on a regular basis. > That's not you. Sorry to disappoint you. Patches are welcome. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 5: 8:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id BF31137B423; Wed, 23 Aug 2000 05:08:07 -0700 (PDT) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.9.3/8.9.3) id OAA82334; Wed, 23 Aug 2000 14:08:06 +0200 (CEST) (envelope-from asmodai) Date: Wed, 23 Aug 2000 14:08:06 +0200 From: Jeroen Ruigrok van der Werven To: Ollivier Robert Cc: "FreeBSD Current Users' list" , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil Message-ID: <20000823140805.U78405@lucifer.bart.nl> References: <20000822172846.A76574@caerdonn.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000822172846.A76574@caerdonn.eurocontrol.fr>; from roberto@eurocontrol.fr on Tue, Aug 22, 2000 at 05:28:46PM +0200 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000822 17:30], Ollivier Robert (roberto@eurocontrol.fr) wrote: >-=-=- >===> libexec/fingerd >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -c /src/src/libexec/fingerd/fi >ngerd.c >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -o fingerd fingerd.o -lutil >/usr/obj/src/src/i386/usr/lib/libutil.so: undefined reference to `crypt_set_form >at' >*** Error code 1 This should be fixed after my commit. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Morpheus in my Heart, your sand in my veins... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 5:37:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by hub.freebsd.org (Postfix) with ESMTP id 8CEF037B43F for ; Wed, 23 Aug 2000 05:37:08 -0700 (PDT) Received: from theta.dante.org.uk ([193.63.211.7]) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 13RZm6-0007Kj-00; Wed, 23 Aug 2000 13:36:58 +0100 Received: from localhost ([127.0.0.1] helo=dante.org.uk) by theta.dante.org.uk with esmtp (Exim 3.12 #4) id 13RZm4-0003OQ-00; Wed, 23 Aug 2000 13:36:56 +0100 Message-ID: <39A3C568.32E686EC@dante.org.uk> Date: Wed, 23 Aug 2000 13:36:56 +0100 From: Konstantin Chuguev Organization: Delivery of Advanced Networking Service to Europe Ltd. X-Mailer: Mozilla 4.73 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Jacques A. Vidrine" Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Jacques A. Vidrine" wrote: > On Wed, Aug 23, 2000 at 01:01:59AM -0500, Mike Meyer wrote: > > Um - why? If you removed the setting of LOCALBASE in that case, you > > wouldn't change the disk layout at all. > > I prefer installed executables, data files, and man pages to refer to > /opt. Duh. > Just wondering: what is the reason of using /opt instead of /usr/local, apart from Solaris influence? Do you use /usr/local for anything? -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW: http://www.dante.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 5:46:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 2914B37B43C for ; Wed, 23 Aug 2000 05:46:09 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13RZut-0006R0-00; Wed, 23 Aug 2000 14:46:03 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id OAA13145; Wed, 23 Aug 2000 14:46:01 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 12899; Wed Aug 23 14:44:40 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13RZtU-0003g6-00; Wed, 23 Aug 2000 14:44:36 +0200 From: Sheldon Hearn To: Konstantin Chuguev Cc: "Jacques A. Vidrine" , current@freebsd.org Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-reply-to: Your message of "Wed, 23 Aug 2000 13:36:56 +0100." <39A3C568.32E686EC@dante.org.uk> Date: Wed, 23 Aug 2000 14:44:36 +0200 Message-ID: <14141.967034676@axl.fw.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000 13:36:56 +0100, Konstantin Chuguev wrote: > Just wondering: what is the reason of using /opt instead of /usr/local, > apart from Solaris influence? Do you use /usr/local for anything? NetBSD uses /usr/opt . It's a matter of taste. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 5:51: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id BC67437B424 for ; Wed, 23 Aug 2000 05:51:01 -0700 (PDT) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id F38FB1925D; Wed, 23 Aug 2000 07:51:00 -0500 (CDT) Received: (from nectar@localhost) by hamlet.nectar.com (8.9.3/8.9.3) id HAA04167; Wed, 23 Aug 2000 07:51:00 -0500 (CDT) (envelope-from nectar@spawn.nectar.com) Date: Wed, 23 Aug 2000 07:51:00 -0500 From: "Jacques A. Vidrine" To: Konstantin Chuguev Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000823075100.A1471@hamlet.nectar.com> References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> <39A3C568.32E686EC@dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <39A3C568.32E686EC@dante.org.uk>; from Konstantin.Chuguev@dante.org.uk on Wed, Aug 23, 2000 at 01:36:56PM +0100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 01:36:56PM +0100, Konstantin Chuguev wrote: > Just wondering: what is the reason of using /opt instead of /usr/local, > apart from Solaris influence? No Solaris influence, actually. Just strlen("/opt") < strlen("/usr/local"). It looks nicer to me. Secondarily to see if a ports behaves when ${LOCALBASE} != /usr/local. > Do you use /usr/local for anything? Nope. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 5:57:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id C706137B43F for ; Wed, 23 Aug 2000 05:57:13 -0700 (PDT) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.16 #20) id 13Ra5R-0005pn-00; Wed, 23 Aug 2000 14:56:57 +0200 Received: from a37cb.pppool.de ([213.6.55.203] helo=Magelan.Leidinger.net) by mx0.freenet.de with esmtp (Exim 3.16 #20) id 13Ra5L-00048A-00; Wed, 23 Aug 2000 14:56:55 +0200 Received: from Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.11.0/8.11.0) with ESMTP id e7NBLQk02859; Wed, 23 Aug 2000 13:21:27 +0200 (CEST) (envelope-from netchild@Leidinger.net) Message-Id: <200008231121.e7NBLQk02859@Magelan.Leidinger.net> Date: Wed, 23 Aug 2000 13:21:24 +0200 (CEST) From: Alexander Leidinger Subject: Re: Why no CDR ioctls for SCSI cds? To: paul@originative.co.uk Cc: ken@kdm.org, stuyman@confusion.net, mwm@mired.org, current@FreeBSD.ORG In-Reply-To: <39A3A435.11ABCD8C@originative.co.uk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23 Aug, Paul Richards wrote: >> > On a vaguely related topic, after much searching I can't seem to see one >> > way or the other if we can do a complete bit-by-bit copy of a cd with >> > either cdrecord or burncd, though it's possible I'm looking in the wrong >> > place. >> >> I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in >> ports/audio) can do it as well. >> >> As far as getting an image, you can use dd to dump off an image of a CD if >> it is a standard ISO9660 CD. (I've used that method to clone CDs before.) > > That didn't seem to work when I tried it a couple of days ago. Got a > "device not configured" error. You've done something wrong, it works here. BTW: If I need a copy of a data cd I use "cdrecord -v speed=4 dev=0,1,0 -eject -isosize /dev/cd1c" (cd1 is my CD-ROM, cd0 (dev=0,1,0) is my CD burner). Bye, Alexander. -- Speak softly and carry a cellular phone. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 6: 3:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from acs-24-154-11-41.zoominternet.net (acs-24-154-11-41.zoominternet.net [24.154.11.41]) by hub.freebsd.org (Postfix) with ESMTP id 8EB5237B422 for ; Wed, 23 Aug 2000 06:03:09 -0700 (PDT) Received: (from dmmiller@localhost) by acs-24-154-11-41.zoominternet.net (8.11.0/8.11.0) id e7ND38w00327; Wed, 23 Aug 2000 09:03:08 -0400 (EDT) (envelope-from dmmiller) Date: Wed, 23 Aug 2000 09:03:08 -0400 (EDT) From: Donn Miller Message-Id: <200008231303.e7ND38w00327@acs-24-154-11-41.zoominternet.net> To: dmmiller@cvzoom.net, mark@grondar.za Subject: Re: Review requested for /dev/random driver improvements! Cc: current@freebsd.org In-Reply-To: <200008231108.e7NB81r10453@grimreaper.grondar.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Basically, it is hanging immediately after this message: Preloaded elf kernel "kernel.old" at 0xc0392000. Intel Pentium detected, installing workaround for F00F bug nulldev: I couldn't even drop into the debugger, because my machine was locked solid. The next boot message WOULD'VE been: random: So, at least I know the hang is occuring at random: . -Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 6:59:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id 54E8937B422 for ; Wed, 23 Aug 2000 06:59:24 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13Rb3V-0007do-00; Wed, 23 Aug 2000 15:59:01 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id PAA25756; Wed, 23 Aug 2000 15:57:46 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 25564; Wed Aug 23 15:56:19 2000 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7NDusr11358; Wed, 23 Aug 2000 15:56:54 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008231356.e7NDusr11358@grimreaper.grondar.za> To: Donn Miller Cc: current@freebsd.org Subject: Re: Review requested for /dev/random driver improvements! References: <200008231303.e7ND38w00327@acs-24-154-11-41.zoominternet.net> In-Reply-To: <200008231303.e7ND38w00327@acs-24-154-11-41.zoominternet.net> ; from Donn Miller "Wed, 23 Aug 2000 09:03:08 -0400." Date: Wed, 23 Aug 2000 15:56:54 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So, at least I know the hang is occuring at random: . OK; please uncomment the #define DEBUG in yarrow.c and let me know what the output of that looks like? Thanks! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:23:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from acs-24-154-11-41.zoominternet.net (acs-24-154-11-41.zoominternet.net [24.154.11.41]) by hub.freebsd.org (Postfix) with ESMTP id 4E26F37B424 for ; Wed, 23 Aug 2000 07:23:33 -0700 (PDT) Received: from cvzoom.net (localhost [127.0.0.1]) by acs-24-154-11-41.zoominternet.net (8.11.0/8.11.0) with ESMTP id e7NENKh00312; Wed, 23 Aug 2000 10:23:20 -0400 (EDT) (envelope-from dmmiller@cvzoom.net) Message-ID: <39A3DE57.4BA55726@cvzoom.net> Date: Wed, 23 Aug 2000 10:23:19 -0400 From: Donn Miller X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: current@freebsd.org Subject: Re: Review requested for /dev/random driver improvements! References: <200008231303.e7ND38w00327@acs-24-154-11-41.zoominternet.net> <200008231356.e7NDusr11358@grimreaper.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > > So, at least I know the hang is occuring at random: . > > OK; please uncomment the #define DEBUG in yarrow.c and let me know what > the output of that looks like? I get random: Random init and then my machine just locks up tight, right there. -Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:28:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 932F237B422 for ; Wed, 23 Aug 2000 07:28:15 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id KAA20408 for ; Wed, 23 Aug 2000 10:28:00 -0400 (EDT) Date: Wed, 23 Aug 2000 10:28:00 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: freebsd-current@freebsd.org Subject: weirdness with devfs? (time) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this is cute: notice the dates, they predate the epoch. weird huh? anyone else see this or am I just off my rocker? -Trish total 0 crw-r--r-- 1 root operator 117, 0 Dec 31 1969 acd0a crw-r--r-- 1 root operator 117, 2 Dec 31 1969 acd0c crw-r----- 1 root operator 15, 0x00010002 Dec 31 1969 cd0 crw-r----- 1 root operator 15, 2 Dec 31 1969 cd0c crw------- 1 root wheel 0, 0 Dec 31 1969 console crw------- 1 root wheel 12, 255 Dec 31 1969 consolectl crw-rw---- 1 uucp dialer 28, 128 Dec 31 1969 cuaa0 crw-rw---- 1 uucp dialer 28, 129 Dec 31 1969 cuaa1 crw-rw---- 1 uucp dialer 28, 160 Dec 31 1969 cuaia0 crw-rw---- 1 uucp dialer 28, 161 Dec 31 1969 cuaia1 crw-rw---- 1 uucp dialer 28, 192 Dec 31 1969 cuala0 crw-rw---- 1 uucp dialer 28, 193 Dec 31 1969 cuala1 crw-r----- 1 root operator 13, 0x00010002 Dec 31 1969 da0 crw-r----- 1 root operator 13, 0x00020000 Dec 31 1969 da0s1a crw-r----- 1 root operator 13, 0x00020001 Dec 31 1969 da0s1b crw-r----- 1 root operator 13, 0x00020004 Dec 31 1969 da0s1e crw-r----- 1 root operator 13, 0x0001000a Dec 31 1969 da1 crw-r----- 1 root operator 13, 0x0002000c Dec 31 1969 da1s1e crw-r----- 1 root operator 13, 0x00010012 Dec 31 1969 da2 crw-r----- 1 root operator 13, 0x00020014 Dec 31 1969 da2s1e crw-r----- 1 root operator 13, 0x0001001a Dec 31 1969 da3 crw-r----- 1 root operator 13, 0x0002001c Dec 31 1969 da3s1e crw-r----- 1 root operator 9, 0 Dec 31 1969 fd0 crw------- 1 root wheel 2, 14 Dec 31 1969 io crw------- 1 root wheel 79, 3 Dec 31 1969 ipauth crw------- 1 root wheel 79, 0 Dec 31 1969 ipl crw------- 1 root wheel 79, 1 Dec 31 1969 ipnat crw------- 1 root wheel 79, 2 Dec 31 1969 ipstate crw------- 1 root wheel 7, 0 Dec 31 1969 klog crw-r----- 1 root kmem 2, 1 Dec 31 1969 kmem lrw-r---w- 1 root wheel 0 Dec 31 1969 log -> /var/run/log crw------- 1 root wheel 16, 0 Dec 31 1969 lpt0 crw------- 1 root wheel 16, 128 Dec 31 1969 lpt0.ctl crw-r----- 1 root kmem 2, 0 Dec 31 1969 mem crw-rw-rw- 1 root wheel 2, 2 Dec 31 1969 null crw------- 1 root operator 31, 0 Dec 31 1969 pass0 crw------- 1 root operator 31, 1 Dec 31 1969 pass1 crw------- 1 root operator 31, 2 Dec 31 1969 pass2 crw------- 1 root operator 31, 3 Dec 31 1969 pass3 crw------- 1 root operator 31, 4 Dec 31 1969 pass4 crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci crw------- 1 root wheel 82, 0 Dec 31 1969 ppi0 crw-rw-rw- 1 root wheel 6, 0 Dec 31 1969 ptyp0 crw-rw-rw- 1 root wheel 6, 1 Dec 31 1969 ptyp1 crw-rw-rw- 1 root wheel 6, 2 Dec 31 1969 ptyp2 crw-rw-rw- 1 root wheel 2, 3 Dec 31 1969 random crw-rw-rw- 1 root wheel 22, 2 Dec 31 1969 stderr crw-rw-rw- 1 root wheel 22, 0 Dec 31 1969 stdin crw-rw-rw- 1 root wheel 22, 1 Dec 31 1969 stdout crw------- 1 root wheel 12, 128 Dec 31 1969 sysmouse crw-rw-rw- 1 root wheel 1, 0 Dec 31 1969 tty crw------- 1 root wheel 28, 0 Dec 31 1969 ttyd0 crw------- 1 root wheel 28, 1 Dec 31 1969 ttyd1 crw------- 1 root wheel 28, 32 Dec 31 1969 ttyid0 crw------- 1 root wheel 28, 33 Dec 31 1969 ttyid1 crw------- 1 root wheel 28, 64 Dec 31 1969 ttyld0 crw------- 1 root wheel 28, 65 Dec 31 1969 ttyld1 crw--w---- 1 trish tty 5, 0 Dec 31 1969 ttyp0 crw--w---- 1 trish tty 5, 1 Dec 31 1969 ttyp1 crw--w---- 1 trish tty 5, 2 Dec 31 1969 ttyp2 crw------- 1 root wheel 12, 0 Dec 31 1969 ttyv0 crw------- 1 root wheel 12, 1 Dec 31 1969 ttyv1 crw------- 1 root wheel 12, 2 Dec 31 1969 ttyv2 crw------- 1 root wheel 12, 3 Dec 31 1969 ttyv3 crw------- 1 root wheel 12, 4 Dec 31 1969 ttyv4 crw------- 1 root wheel 12, 5 Dec 31 1969 ttyv5 crw------- 1 root wheel 12, 6 Dec 31 1969 ttyv6 crw------- 1 root wheel 12, 7 Dec 31 1969 ttyv7 crw------- 1 root wheel 12, 8 Dec 31 1969 ttyv8 crw------- 1 root wheel 12, 9 Dec 31 1969 ttyv9 crw------- 1 root wheel 12, 10 Dec 31 1969 ttyva crw------- 1 root wheel 12, 11 Dec 31 1969 ttyvb crw------- 1 root wheel 12, 12 Dec 31 1969 ttyvc crw------- 1 root wheel 12, 13 Dec 31 1969 ttyvd crw------- 1 root wheel 12, 14 Dec 31 1969 ttyve crw------- 1 root wheel 12, 15 Dec 31 1969 ttyvf crw-rw-rw- 1 root wheel 2, 4 Dec 31 1969 urandom crw-r--r-- 1 root operator 108, 255 Dec 31 1969 usb crw-r--r-- 1 root operator 108, 0 Dec 31 1969 usb0 lrw-r---w- 1 root wheel 0 Dec 31 1969 vga -> /dev/ttyv0 crw------- 1 root operator 104, 0 Dec 31 1969 xpt0 crw-rw-rw- 1 root wheel 2, 12 Dec 31 1969 zero __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net --- "how long till my soul gets it right can any human being ever reach that kind of light i call on the resting soul of galileo king of night vision, king of insight" -Indigo Girls, Galileo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:32: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from acs-24-154-11-41.zoominternet.net (acs-24-154-11-41.zoominternet.net [24.154.11.41]) by hub.freebsd.org (Postfix) with ESMTP id 013DD37B42C for ; Wed, 23 Aug 2000 07:32:00 -0700 (PDT) Received: from cvzoom.net (localhost [127.0.0.1]) by acs-24-154-11-41.zoominternet.net (8.11.0/8.11.0) with ESMTP id e7NEVjh00335; Wed, 23 Aug 2000 10:31:49 -0400 (EDT) (envelope-from dmmiller@cvzoom.net) Message-ID: <39A3E051.FFEA8988@cvzoom.net> Date: Wed, 23 Aug 2000 10:31:45 -0400 From: Donn Miller X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Siobhan Patricia Lynch Cc: freebsd-current@freebsd.org Subject: Re: weirdness with devfs? (time) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Siobhan Patricia Lynch wrote: > > this is cute: > notice the dates, they predate the epoch. > > weird huh? anyone else see this or am I just off my rocker? > > -Trish > > total 0 > crw-r--r-- 1 root operator 117, 0 Dec 31 1969 acd0a > crw-r--r-- 1 root operator 117, 2 Dec 31 1969 acd0c > crw-r----- 1 root operator 15, 0x00010002 Dec 31 1969 cd0 > crw-r----- 1 root operator 15, 2 Dec 31 1969 cd0c > crw------- 1 root wheel 0, 0 Dec 31 1969 console Maybe your machine was previously owned by a Woodstock-era hippie? LOL. I have no such problems with my -current: total 42 -r-xr-xr-x 1 root wheel 38814 Aug 19 23:40 MAKEDEV* -r-xr-xr-x 1 root wheel 2064 Jul 16 07:49 MAKEDEV.local* crw-r----- 2 root operator 117, 0 Jul 17 02:20 acd0a crw-rw-rw- 2 root operator 117, 2 Jul 17 02:20 acd0c crw-r----- 2 root operator 117, 8 Jul 17 02:20 acd1a crw-r----- 2 root operator 117, 10 Jul 17 02:20 acd1c crw-r----- 2 root operator 116, 0x00010002 Jul 17 02:20 ad0 crw-r----- 2 root operator 116, 0 Jul 17 02:20 ad0a crw-r----- 2 root operator 116, 1 Jul 17 02:20 ad0b [snip] -Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:34:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from argon.gryphonsoft.com (mcut-b-078.resnet.purdue.edu [128.211.209.78]) by hub.freebsd.org (Postfix) with ESMTP id EFBEF37B422 for ; Wed, 23 Aug 2000 07:34:10 -0700 (PDT) Received: by argon.gryphonsoft.com (Postfix, from userid 1000) id 59957197F; Wed, 23 Aug 2000 09:32:33 -0500 (EST) Date: Wed, 23 Aug 2000 09:32:33 -0500 From: Will Andrews To: Siobhan Patricia Lynch Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) Message-ID: <20000823093233.L8055@argon.gryphonsoft.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from trish@bsdunix.net on Wed, Aug 23, 2000 at 10:28:00AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 10:28:00AM -0400, Siobhan Patricia Lynch wrote: ^^^^^ > this is cute: > notice the dates, they predate the epoch. They don't predate the epoch. The epoch starts at 00:00 UTC on January 1, 1970. Hence, the dates are exactly the epoch (20:00 -0400 UTC on December 31, 1969). But you *DO* have a real bug there.. ;-> -- Will Andrews GCS/E/S @d- s+:+ a--- C++ UB++++$ P+ L- E--- W+ N-- !o ?K w--- O- M+ V- PS+ PE++ Y+ PGP+>+++ t++ 5 X+ R+ tv+ b++ DI+++ D+ G++ e>++++ h! r- y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:38:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id E1B8D37B424 for ; Wed, 23 Aug 2000 07:38:46 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13Rbfv-0000Y0-00; Wed, 23 Aug 2000 16:38:43 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id QAA02566; Wed, 23 Aug 2000 16:38:41 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 2235; Wed Aug 23 16:36:57 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13RbeD-0000Wq-00; Wed, 23 Aug 2000 16:36:57 +0200 From: Sheldon Hearn To: Donn Miller Cc: Siobhan Patricia Lynch , freebsd-current@freebsd.org Subject: Re: weirdness with devfs? (time) In-reply-to: Your message of "Wed, 23 Aug 2000 10:31:45 -0400." <39A3E051.FFEA8988@cvzoom.net> Date: Wed, 23 Aug 2000 16:36:57 +0200 Message-ID: <2035.967041417@axl.fw.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000 10:31:45 -0400, Donn Miller wrote: > Maybe your machine was previously owned by a Woodstock-era hippie? LOL. > > I have no such problems with my -current: > > total 42 > -r-xr-xr-x 1 root wheel 38814 Aug 19 23:40 MAKEDEV* > -r-xr-xr-x 1 root wheel 2064 Jul 16 07:49 MAKEDEV.local* And you're not using DEVFS, so it doesn't really matter whether you have the problem on your box. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:45:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 9E60A37B43C for ; Wed, 23 Aug 2000 07:45:31 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id KAA30504; Wed, 23 Aug 2000 10:45:20 -0400 (EDT) Date: Wed, 23 Aug 2000 10:45:19 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: Will Andrews Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) In-Reply-To: <20000823093233.L8055@argon.gryphonsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Will Andrews wrote: > On Wed, Aug 23, 2000 at 10:28:00AM -0400, Siobhan Patricia Lynch wrote: > ^^^^^ > > this is cute: > > notice the dates, they predate the epoch. > > They don't predate the epoch. The epoch starts at 00:00 UTC on January > 1, 1970. Hence, the dates are exactly the epoch (20:00 -0400 UTC on > December 31, 1969). > > But you *DO* have a real bug there.. ;-> > ok I concede, taking into account time zones, yes it is the epoch ;) however it *is* strange. __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net --- "Can't let them rape me again Your venom's not family here won't let them fill me with fatalistic remedies" -Dream Theater, Scarred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:46:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id ABBCC37B422 for ; Wed, 23 Aug 2000 07:46:51 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id HAA42373; Wed, 23 Aug 2000 07:46:37 -0700 (PDT) (envelope-from obrien) Date: Wed, 23 Aug 2000 07:46:37 -0700 From: "David O'Brien" To: Konstantin Chuguev Cc: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000823074637.A42348@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> <39A3C568.32E686EC@dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39A3C568.32E686EC@dante.org.uk>; from Konstantin.Chuguev@dante.org.uk on Wed, Aug 23, 2000 at 01:36:56PM +0100 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 01:36:56PM +0100, Konstantin Chuguev wrote: > Do you use /usr/local for anything? Yes, local stuff. IMHO, the Ports Collection using /usr/local was the biggest mistake of it. The ports collection should have used /usr/pkg/ as NetBSD does. I have to create /usr/truely-local on my FreeBSD machines. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:49:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta04.mail.mel.aone.net.au (mta04.mail.au.uu.net [203.2.192.84]) by hub.freebsd.org (Postfix) with ESMTP id 335FD37B424 for ; Wed, 23 Aug 2000 07:49:22 -0700 (PDT) Received: from camtech.net.au ([203.55.243.56]) by mta04.mail.mel.aone.net.au with ESMTP id <20000823144919.WUOA7848.mta04.mail.mel.aone.net.au@camtech.net.au>; Thu, 24 Aug 2000 00:49:19 +1000 Message-ID: <39A3E4C6.771DB1C3@camtech.net.au> Date: Thu, 24 Aug 2000 00:20:46 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Yemin.Win@au.uu.net Cc: support@uu.net, current@freebsd.org Subject: I thought I told you not to send a test message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why have you annoyed many hundreds of people with your test message which I told you was not necessary to send ? I clearly described the simple problem of your organisation using email relay servers which were not registered in the DNS causing many weeks of problems for me. Not only have you annoyed many people but you have sent email using my sending address instead of your own address for a test which was not necessary. I am extremely unimpressed with the performance of your organisation and the incompetant manner that this simple problem has been handled. It would be within my rights to take legal action against your organisation. Please have someone contact me as soon as possible to discuss the way your organisation should repay me for the more than 2 months of inconvienience and suffering I have endured. To the FreeBSD-current list subscribers, I hope you accept that I did not send that stupid test message and also be advised that the Australian operations of UU.net and Access One take about 2 months to even understand a simple DNS problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 7:53:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-160.telepath.com [216.14.2.160]) by hub.freebsd.org (Postfix) with SMTP id 7F7DB37B423 for ; Wed, 23 Aug 2000 07:53:37 -0700 (PDT) Received: (qmail 95318 invoked by uid 100); 23 Aug 2000 14:53:35 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14755.58735.734025.505698@guru.mired.org> Date: Wed, 23 Aug 2000 09:53:35 -0500 (CDT) To: Konstantin Chuguev Cc: "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: <39A3C568.32E686EC@dante.org.uk> References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> <39A3C568.32E686EC@dante.org.uk> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Konstantin Chuguev writes: > "Jacques A. Vidrine" wrote: > > On Wed, Aug 23, 2000 at 01:01:59AM -0500, Mike Meyer wrote: > > > Um - why? If you removed the setting of LOCALBASE in that case, you > > > wouldn't change the disk layout at all. > > I prefer installed executables, data files, and man pages to refer to > > /opt. Duh. Ok, that makes sense. I overlooked the man pages. > Just wondering: what is the reason of using /opt instead of /usr/local, > apart from Solaris influence? Do you use /usr/local for anything? I use /usr/opt instead of /opt. I use /usr/local for things that are local additions to the system, as opposed to things that are gotten through freebsd. They have different update & backup policies, which is why they were separated. Ports got moved instead of local because ports has a mechanism for moving them, whereas local things may or may not have that. ; Wed, 23 Aug 2000 08:24:54 -0700 (PDT) Received: (from abc@localhost) by diskfarm.firehouse.net (8.9.3/8.9.3) id PAA12775 for current@FreeBSD.ORG; Wed, 23 Aug 2000 15:24:57 GMT (envelope-from abc) Date: Wed, 23 Aug 2000 15:24:57 +0000 From: Alan Clegg To: current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000823152456.F398@diskfarm.firehouse.net> References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> <39A3C568.32E686EC@dante.org.uk> <20000823074637.A42348@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000823074637.A42348@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Wed, Aug 23, 2000 at 07:46:37AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Out of the ether, David O'Brien spewed forth the following bitstream: > On Wed, Aug 23, 2000 at 01:36:56PM +0100, Konstantin Chuguev wrote: > > Do you use /usr/local for anything? > Yes, local stuff. IMHO, the Ports Collection using /usr/local was the > biggest mistake of it. The ports collection should have used /usr/pkg/ > as NetBSD does. I have to create /usr/truely-local on my FreeBSD > machines. Amen. I would strongly recommend that the "/usr/local" use of ports be re-aimed at something else. "/usr/local" should be the pristine ownership of the LOCAL admin. AlanC {BSD/OS uses /usr/contrib, but that ain't the same thing} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 8:29:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta05.mail.mel.aone.net.au (mta05.mail.au.uu.net [203.2.192.85]) by hub.freebsd.org (Postfix) with ESMTP id E42AB37B422 for ; Wed, 23 Aug 2000 08:29:32 -0700 (PDT) Received: from camtech.net.au ([203.55.243.56]) by mta05.mail.mel.aone.net.au with ESMTP id <20000823152930.CWYS3895.mta05.mail.mel.aone.net.au@camtech.net.au>; Thu, 24 Aug 2000 01:29:30 +1000 Message-ID: <39A3EE2F.89415A5D@camtech.net.au> Date: Thu, 24 Aug 2000 01:00:55 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Soren Schmidt Cc: Andreas Klemm , j mckitrick , freebsd-current@FreeBSD.ORG Subject: Re: ATA66 support References: <200008031744.TAA73057@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Soren Schmidt wrote: > It seems Andreas Klemm wrote: > > ad4: 39082MB [79406/16/63] at ata2-master using UDMA33 > > AHA! try swap that with a known good drive (ie non Maxtor/WD) if you can.... Are there plans to try to support this broken hardware ? Maxtor seem to be violating ATAPI standards in that FreeBSD and Linux cannot use many Maxtor drives at rated speed, however..... Maxtor has some extremely fast drives that `work' in WinTel machines faster than all other competitors using ATA66 (as of a month or so ago) so it appears they are cutting corners on the standard (cheating) in order to produce a very fast product. Are there plans to accomodate their behavior ? Do you have any contacts in Maxtor to help in this task ? > > -Søren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Matthew Thyer (who doesn't send useless test mail to mailing lists) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 9:16:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 4BE5137B424 for ; Wed, 23 Aug 2000 09:16:15 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id SAA63996; Wed, 23 Aug 2000 18:14:46 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200008231614.SAA63996@freebsd.dk> Subject: Re: ATA66 support In-Reply-To: <39A3EE2F.89415A5D@camtech.net.au> from Matthew Thyer at "Aug 24, 2000 01:00:55 am" To: thyerm@camtech.net.au (Matthew Thyer) Date: Wed, 23 Aug 2000 18:14:46 +0200 (CEST) Cc: andreas@klemm.gtn.com (Andreas Klemm), jcm@FreeBSD-uk.eu.org (j mckitrick), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Matthew Thyer wrote: > Soren Schmidt wrote: > > It seems Andreas Klemm wrote: > > > ad4: 39082MB [79406/16/63] at ata2-master using UDMA33 > > > > AHA! try swap that with a known good drive (ie non Maxtor/WD) if you can.... > > Are there plans to try to support this broken hardware ? If possible... > Maxtor seem to be violating ATAPI standards in that FreeBSD and Linux > cannot use many Maxtor drives at rated speed, however..... You mean ATA standards, I'm not sure thats the problem... > Maxtor has some extremely fast drives that `work' in WinTel machines > faster than all other competitors using ATA66 (as of a month or so ago) > so it appears they are cutting corners on the standard (cheating) in > order to produce a very fast product. Well, "work" is exactly the word to use, they work on *some* chipsets with *some* drivers, but they have problems there as well. Remember that most wintel boxes doesn't even use DMA... Besides it seems as if its our much more agressive usage thats the real problem, looks like firmware problems too me.... > Are there plans to accomodate their behavior ? As I've stated before, if somebody get me one of the problematic drives on my desk I'll do what I can.... > Do you have any contacts in Maxtor to help in this task ? Sortof, but they dont think they have any problems at all :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 9:44:52 2000 Delivered-To: freebsd-current@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id C8C1137B43E for ; Wed, 23 Aug 2000 09:44:41 -0700 (PDT) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.16 #1) id 13RdIQ-000IJc-00; Wed, 23 Aug 2000 17:22:34 +0100 Received: (from ben@localhost) by strontium.scientia.demon.co.uk (8.9.3/8.9.3) id RAA76718; Wed, 23 Aug 2000 17:22:33 +0100 (BST) (envelope-from ben) Date: Wed, 23 Aug 2000 17:22:33 +0100 From: Ben Smithurst To: Doug Barton , current@FreeBSD.org Subject: patch for mergemaster when /dev is devfs Message-ID: <20000823172233.I20036@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just a minor point... Should we add a patch something like this to mergemaster so that it doesn't prompt the user about MAKEDEV if their /dev is a devfs where MAKEDEV can't be created anyway? Or would you prefer that this be made an option like IGNORE_DEV or IGNORE_MAKEDEV or something? If you'd prefer that I can probably create an appropriate patch, but this route seems more sensible to me, since no config change will be needed if I decide to stop using devfs. Index: mergemaster.sh =================================================================== RCS file: /usr/cvs/src/usr.sbin/mergemaster/mergemaster.sh,v retrieving revision 1.10 diff -u -r1.10 mergemaster.sh --- mergemaster.sh 2000/08/13 19:32:19 1.10 +++ mergemaster.sh 2000/08/23 16:17:48 @@ -10,7 +10,7 @@ # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.10 2000/08/13 19:32:19 gshapiro Exp $ -PATH=/bin:/usr/bin:/usr/sbin +PATH=/bin:/usr/bin:/usr/sbin:/sbin display_usage () { VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` @@ -421,6 +421,11 @@ *) rm ${TEMPROOT}/etc/motd ;; esac + + # Avoid trying to update MAKEDEV if /dev is on a devfs + if mount | grep -q "devfs on /dev "; then + rm ${TEMPROOT}/dev/MAKEDEV ${TEMPROOT}/dev/MAKEDEV.local + fi ;; # End of the "RERUN" test esac -- Ben Smithurst / ben@FreeBSD.org / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11: 7:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.254]) by hub.freebsd.org (Postfix) with ESMTP id 3213237B424 for ; Wed, 23 Aug 2000 11:07:29 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA04392; Wed, 23 Aug 2000 20:07:23 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Siobhan Patricia Lynch Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) In-Reply-To: Your message of "Wed, 23 Aug 2000 10:28:00 EDT." Date: Wed, 23 Aug 2000 20:07:23 +0200 Message-ID: <4390.967054043@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Siobhan Patricia Lynch writes: >this is cute: >notice the dates, they predate the epoch. Because of your timezone. >weird huh? anyone else see this or am I just off my rocker? >crw------- 1 root wheel 12, 0 Dec 31 1969 ttyv0 >crw------- 1 root wheel 12, 1 Dec 31 1969 ttyv1 >crw------- 1 root wheel 12, 2 Dec 31 1969 ttyv2 >crw------- 1 root wheel 12, 3 Dec 31 1969 ttyv3 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:27: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by hub.freebsd.org (Postfix) with ESMTP id 9812D37B422 for ; Wed, 23 Aug 2000 11:26:55 -0700 (PDT) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13RfEj-000Jcs-00; Wed, 23 Aug 2000 19:26:53 +0100 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.9.3/8.9.3) id TAA42920; Wed, 23 Aug 2000 19:26:51 +0100 (BST) (envelope-from jcm) Date: Wed, 23 Aug 2000 19:26:51 +0100 From: j mckitrick To: Soren Schmidt Cc: Matthew Thyer , Andreas Klemm , freebsd-current@FreeBSD.ORG Subject: Re: ATA66 support Message-ID: <20000823192651.B42818@dogma.freebsd-uk.eu.org> References: <39A3EE2F.89415A5D@camtech.net.au> <200008231614.SAA63996@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200008231614.SAA63996@freebsd.dk>; from sos@freebsd.dk on Wed, Aug 23, 2000 at 06:14:46PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 06:14:46PM +0200, Soren Schmidt wrote: | Well, "work" is exactly the word to use, they work on *some* chipsets | with *some* drivers, but they have problems there as well. Remember | that most wintel boxes doesn't even use DMA... really? why is that? and why include the feature if it is not used by the biggest segment of the market? | Besides it seems as if its our much more agressive usage thats the | real problem, looks like firmware problems too me.... how is bsd more aggressive (other than the obvious buildworld load)? maybe we should go easier on the hardware for real-world compatibility and reliability reasons? jcm -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:38:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 16A4F37B443 for ; Wed, 23 Aug 2000 11:38:41 -0700 (PDT) Received: from localhost (trish@localhost) by superconductor.rush.net (8.9.3/8.9.3) with ESMTP id OAA08762; Wed, 23 Aug 2000 14:35:59 -0400 (EDT) Date: Wed, 23 Aug 2000 14:35:58 -0400 (EDT) From: Siobhan Patricia Lynch X-Sender: trish@superconductor.rush.net To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) In-Reply-To: <4390.967054043@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Poul-Henning Kamp wrote: > In message , > Siobhan Patricia Lynch writes: > >this is cute: > >notice the dates, they predate the epoch. > > Because of your timezone. > nod, figured that out already, however, is the epoch date intentional? __ Trish Lynch FreeBSD - The Power to Serve trish@bsdunix.net Rush Networking trish@rush.net --- "the wood is tired and the wood is old we'll make it fine if the weather holds but if the weather holds we'll have missed the point that's where i need to go" -Indigo Girls, The Wood Song To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:48:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.telemere.net (mail.telemere.net [63.224.9.4]) by hub.freebsd.org (Postfix) with ESMTP id 43FCC37B43C; Wed, 23 Aug 2000 11:48:23 -0700 (PDT) Received: by mail.telemere.net (Postfix, from userid 1001) id 69A7520F01; Wed, 23 Aug 2000 13:51:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.telemere.net (Postfix) with ESMTP id 652CC1D101; Wed, 23 Aug 2000 13:51:21 -0500 (CDT) Date: Wed, 23 Aug 2000 13:51:16 -0500 (CDT) From: Visigoth To: current@freebsd.org, cvs-all@freebsd.org Subject: DPT revision....(broken drivers in -STABLE) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the cross post but.... Would it be possible to revert the DPT commits made by peter on Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have production machines that need worlds built for some other updates as well.. I would be happy to install a -CURRENT machine and help debug until it works, but for right now, there is NO DPT support in -STABLE for the DPT PM3334UW. I had a pr started, but haven't been able to get any response from the current maintainer. I am going to install a -CURRENT machine with a DPT in it and start the process of working on the issue, but it would be nice if we can keep -STABLE stable... ;) Visigoth Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOaQPGDnmC/+RTnGeEQIJmgCfceaKQbQtf6rIw8y7vnKX9yILwzgAoOio qyAuX72v+iICVu5y5n9GQvz/ =TXXY -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:51:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.254]) by hub.freebsd.org (Postfix) with ESMTP id 373A837B42C for ; Wed, 23 Aug 2000 11:51:34 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA04854; Wed, 23 Aug 2000 20:51:28 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Siobhan Patricia Lynch Cc: freebsd-current@FreeBSD.ORG Subject: Re: weirdness with devfs? (time) In-Reply-To: Your message of "Wed, 23 Aug 2000 14:35:58 EDT." Date: Wed, 23 Aug 2000 20:51:28 +0200 Message-ID: <4852.967056688@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Siobhan Patricia Lynch writes: >On Wed, 23 Aug 2000, Poul-Henning Kamp wrote: > >> In message , >> Siobhan Patricia Lynch writes: >> >this is cute: >> >notice the dates, they predate the epoch. >> >> Because of your timezone. >> > >nod, figured that out already, however, is the epoch date intentional? No. I'm working on that issue right now. If you look in sys/ufs/ufs/ufs_vnops.c:ufs_spec{read|write}() you will see that the filesystem "hosting" the device node has to figure out for itself when to update the ACCESS, UPDATE and CHANGE timestamps relative to the access to the dev_t through specfs. Obviously wrong since all device node hosting filesystems (ufs, ext2fs, devfs cd9660 (well, not really but in principle...)) will have to duplicate that code. I'm looking at a patch right now which adds three flag bits to the dev_t and clone this code into sys/miscfs/specfs() where it will maintain these three bits. The hosting filesystem can then examine just those bits to determine when timestamps should be updated. The advantage to this scheme is that the drivers themselves can set these bits when for instance ioctl functions have "updated" or "accessed" the device. The secondary advantage is that we don't have to have this code mutated in multiple filesystems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:54: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from dt051n1f.san.rr.com (24-25-220-168.san.rr.com [24.25.220.168]) by hub.freebsd.org (Postfix) with ESMTP id 0EB1737B422; Wed, 23 Aug 2000 11:54:00 -0700 (PDT) Received: from slave (doug@slave [10.0.0.1]) by dt051n1f.san.rr.com (8.9.3/8.9.3) with ESMTP id LAA07907; Wed, 23 Aug 2000 11:53:59 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 23 Aug 2000 11:53:59 -0700 (PDT) From: Doug Barton X-Sender: doug@dt051n1f.san.rr.com To: Ben Smithurst Cc: current@FreeBSD.org Subject: Re: patch for mergemaster when /dev is devfs In-Reply-To: <20000823172233.I20036@strontium.scientia.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Ben Smithurst wrote: > Or would you prefer that this be made an option like IGNORE_DEV or > IGNORE_MAKEDEV or something? If you'd prefer that I can probably create > an appropriate patch, but this route seems more sensible to me, since no > config change will be needed if I decide to stop using devfs. I like this approach better, since it doesn't seem that an option is really necessary. However my understanding of devfs is limited to the concept only, so if someone more knoweledgeable and/or preferably someone USING the new devfs stuff wants to comment, I'm open to suggestions. Otherwise, Ben go ahead and commit this after a few days have gone by without opinions to the contrary. Thanks, Doug > Index: mergemaster.sh > =================================================================== > RCS file: /usr/cvs/src/usr.sbin/mergemaster/mergemaster.sh,v > retrieving revision 1.10 > diff -u -r1.10 mergemaster.sh > --- mergemaster.sh 2000/08/13 19:32:19 1.10 > +++ mergemaster.sh 2000/08/23 16:17:48 > @@ -10,7 +10,7 @@ > > # $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.10 2000/08/13 19:32:19 gshapiro Exp $ > > -PATH=/bin:/usr/bin:/usr/sbin > +PATH=/bin:/usr/bin:/usr/sbin:/sbin > > display_usage () { > VERSION_NUMBER=`grep "[$]FreeBSD:" $0 | cut -d ' ' -f 4` > @@ -421,6 +421,11 @@ > *) rm ${TEMPROOT}/etc/motd > ;; > esac > + > + # Avoid trying to update MAKEDEV if /dev is on a devfs > + if mount | grep -q "devfs on /dev "; then > + rm ${TEMPROOT}/dev/MAKEDEV ${TEMPROOT}/dev/MAKEDEV.local > + fi > > ;; # End of the "RERUN" test > esac > > -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 11:58: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id E600F37B422 for ; Wed, 23 Aug 2000 11:58:02 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id UAA02869; Wed, 23 Aug 2000 20:56:36 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200008231856.UAA02869@freebsd.dk> Subject: Re: ATA66 support In-Reply-To: <20000823192651.B42818@dogma.freebsd-uk.eu.org> from j mckitrick at "Aug 23, 2000 07:26:51 pm" To: jcm@FreeBSD-uk.eu.org (j mckitrick) Date: Wed, 23 Aug 2000 20:56:36 +0200 (CEST) Cc: thyerm@camtech.net.au (Matthew Thyer), andreas@klemm.gtn.com (Andreas Klemm), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems j mckitrick wrote: > On Wed, Aug 23, 2000 at 06:14:46PM +0200, Soren Schmidt wrote: > | Well, "work" is exactly the word to use, they work on *some* chipsets > | with *some* drivers, but they have problems there as well. Remember > | that most wintel boxes doesn't even use DMA... > > really? why is that? and why include the feature if it is not used by the > biggest segment of the market? Marketing hype ? > | Besides it seems as if its our much more agressive usage thats the > | real problem, looks like firmware problems too me.... > > how is bsd more aggressive (other than the obvious buildworld load)? > maybe we should go easier on the hardware for real-world compatibility and > reliability reasons? Running multiple processes, multiple users gives you another use pattern as a wintel box used for gaming.... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 13:46:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 641BD37B424 for ; Wed, 23 Aug 2000 13:46:20 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id NAA00729 for ; Wed, 23 Aug 2000 13:46:19 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 23 Aug 2000 13:46:17 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: current@freebsd.org Subject: panic: reducing sbsize: lost count, uid = 1001 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got the above panic in a -current kernel from August 19 with INVARIANTS and INVARIANT_SUPPORT compiled in. I also saw it once before on a kernel from a few weeks ago. In both cases the panic occurred when receiving a 25 MB file with FTP over a gigabit Ethernet link (wx driver). Here is the relevant portion of the stack trace: #16 0xc016689d in panic ( fmt=0xc027fc80 "reducing sbsize: lost count, uid = %d") at /local0/src/sys/kern/kern_shutdown.c:553 #17 0xc0163b67 in chgsbsize (uid=1001, diff=-17520, max=9223372036854775807) at /local0/src/sys/kern/kern_proc.c:202 #18 0xc0186fe2 in sbrelease (sb=0xc7c22674, so=0xc7c22600) at /local0/src/sys/kern/uipc_socket2.c:453 #19 0xc0184333 in sofree (so=0xc7c22600) at /local0/src/sys/kern/uipc_socket.c:261 #20 0xc01b898e in in_pcbdetach (inp=0xc7c86880) at /local0/src/sys/netinet/in_pcb.c:542 #21 0xc01c2125 in tcp_close (tp=0xc7c86940) at /local0/src/sys/netinet/tcp_subr.c:711 #22 0xc01c00ea in tcp_input (m=0xc075ca00, off0=20, proto=6) at /local0/src/sys/netinet/tcp_input.c:2012 #23 0xc01bb09a in ip_input (m=0xc075ca00) at /local0/src/sys/netinet/ip_input.c:756 #24 0xc01bb0f7 in ipintr () at /local0/src/sys/netinet/ip_input.c:784 Unfortunately, I don't have time to dig into it further any time soon. I'll append my kernel config file to this mail. The system is a uniprocessor PII/400. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa # # BLAKE # machine "i386" cpu "I686_CPU" ident BLAKE maxusers 32 options SOFTUPDATES options DDB options INVARIANTS options INVARIANT_SUPPORT options "CLK_USE_I8254_CALIBRATION" options CLK_USE_TSC_CALIBRATION options INET #InterNETworking options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options KTRACE #kernel tracing options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "EXT2FS" #Linux ext2 filesystem options "CD9660_ROOT" #CD-ROM usable as root device options FFS_ROOT #FFS usable as root device [keep this!] options NFS_ROOT #NFS usable as root device options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options RANDOMDEV options SYSVSHM options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options P1003_1B #Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING # options _KPOSIX_VERSION=199309L device isa device pci device fdc # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. device ahc options AHC_ALLOW_MEMIO device scbus device da device sa device cd device pass # Keyboard, mouse, display. device atkbdc 1 device atkbd device psm device sc 1 device vga device splash device npx device sio device de device fxp device wx device bpf device ether device gzip device loop device pty device vn # On-board power management controller. device smbus device intpm device smb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 14:28:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 5F64037B423; Wed, 23 Aug 2000 14:28:51 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7NLRsQ18007; Wed, 23 Aug 2000 14:27:54 -0700 (PDT) Date: Wed, 23 Aug 2000 14:27:54 -0700 From: Alfred Perlstein To: John Polstra Cc: current@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823142754.H4854@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from jdp@polstra.com on Wed, Aug 23, 2000 at 01:46:17PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [000823 13:46] wrote: > I got the above panic in a -current kernel from August 19 with > INVARIANTS and INVARIANT_SUPPORT compiled in. I also saw it once > before on a kernel from a few weeks ago. In both cases the panic > occurred when receiving a 25 MB file with FTP over a gigabit Ethernet > link (wx driver). Here is the relevant portion of the stack trace: > > #16 0xc016689d in panic ( > fmt=0xc027fc80 "reducing sbsize: lost count, uid = %d") > at /local0/src/sys/kern/kern_shutdown.c:553 > #17 0xc0163b67 in chgsbsize (uid=1001, diff=-17520, max=9223372036854775807) > at /local0/src/sys/kern/kern_proc.c:202 > #18 0xc0186fe2 in sbrelease (sb=0xc7c22674, so=0xc7c22600) > at /local0/src/sys/kern/uipc_socket2.c:453 > #19 0xc0184333 in sofree (so=0xc7c22600) > at /local0/src/sys/kern/uipc_socket.c:261 > #20 0xc01b898e in in_pcbdetach (inp=0xc7c86880) > at /local0/src/sys/netinet/in_pcb.c:542 > #21 0xc01c2125 in tcp_close (tp=0xc7c86940) > at /local0/src/sys/netinet/tcp_subr.c:711 > #22 0xc01c00ea in tcp_input (m=0xc075ca00, off0=20, proto=6) > at /local0/src/sys/netinet/tcp_input.c:2012 > #23 0xc01bb09a in ip_input (m=0xc075ca00) > at /local0/src/sys/netinet/ip_input.c:756 > #24 0xc01bb0f7 in ipintr () at /local0/src/sys/netinet/ip_input.c:784 > > Unfortunately, I don't have time to dig into it further any time soon. > I'll append my kernel config file to this mail. The system is a > uniprocessor PII/400. I have a feeling that this is related to missing spl protection around the chgsbsize subsystem, this was probably an issue before I touched it but since I touched it last I'll have a look-see. Brian, does that makes sense? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 14:52:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id AA02F37B423; Wed, 23 Aug 2000 14:52:47 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7NLqjf19186; Wed, 23 Aug 2000 14:52:45 -0700 (PDT) Date: Wed, 23 Aug 2000 14:52:45 -0700 From: Alfred Perlstein To: John Polstra Cc: current@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823145244.J4854@fw.wintelcom.net> References: <20000823142754.H4854@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20000823142754.H4854@fw.wintelcom.net>; from bright@wintelcom.net on Wed, Aug 23, 2000 at 02:27:54PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [000823 14:29] wrote: > > I have a feeling that this is related to missing spl protection around > the chgsbsize subsystem, this was probably an issue before I touched it > but since I touched it last I'll have a look-see. > > Brian, does that makes sense? So far, here's functions that look like they call chgsbsize without splnet: socreate (called from socket() and socketpair(), on error calls sofree() which then calls sodealloc() without splnet) sonewconn3 (called from sonewconn which i'm unsure of the spl at this point) I'm sure there's more. Does it make sense to wrap chgsbsize with spl so callers don't have to worry about it? John can you try this patch and let us know if you still experiance crashes? Index: kern_proc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v retrieving revision 1.69 diff -u -u -r1.69 kern_proc.c --- kern_proc.c 2000/07/04 11:25:22 1.69 +++ kern_proc.c 2000/08/23 21:49:49 @@ -196,6 +196,7 @@ rlim_t max; { struct uidinfo *uip; + int s = splnet(); uip = uifind(uid); if (diff < 0) @@ -205,10 +206,12 @@ /* don't allow them to exceed max, but allow subtraction */ if (diff > 0 && uip->ui_sbsize + diff > max) { (void)uifree(uip); + splx(s); return (0); } uip->ui_sbsize += diff; (void)uifree(uip); + splx(s); return (1); } If this doesn't work then it may be nessesary to spl around examining the socketbuffer's size. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15: 3:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id BA6F837B42C for ; Wed, 23 Aug 2000 15:03:31 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id PAA01010; Wed, 23 Aug 2000 15:03:29 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id PAA23790; Wed, 23 Aug 2000 15:03:28 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 23 Aug 2000 15:03:28 -0700 (PDT) Message-Id: <200008232203.PAA23790@vashon.polstra.com> To: current@freebsd.org Cc: bright@wintelcom.net Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823145244.J4854@fw.wintelcom.net> References: <20000823142754.H4854@fw.wintelcom.net> <20000823145244.J4854@fw.wintelcom.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000823145244.J4854@fw.wintelcom.net>, Alfred Perlstein wrote: > John can you try this patch and let us know if you still experiance > crashes? Will do. I'll let you know what happens. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15:23:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id 6ED6637B424 for ; Wed, 23 Aug 2000 15:23:43 -0700 (PDT) Received: from silvia.hip.berkeley.edu (sji-ca1-02.ix.netcom.com [209.109.232.2]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA29687; Wed, 23 Aug 2000 18:23:34 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id PAA71689; Wed, 23 Aug 2000 15:23:31 -0700 (PDT) To: Mike Meyer Cc: "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: 23 Aug 2000 15:23:29 -0700 In-Reply-To: Mike Meyer's message of "Wed, 23 Aug 2000 01:01:59 -0500 (CDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Mike Meyer * However, I was wondering if there was anyone who could fix things that * weren't PREFIX clean who would also find them on a regular * basis. That's not you. I can help you when the new package building cluster (being put together by Paul Saab at the moment) comes up for service. I'll run some builds with LOCALBASE and X11BASE set to someplace other than the default and flag all ports that don't conform. I couldn't do that for a while since I didn't have enough computing power -- the machines were maxed out just squeezing out the weekly (and sometimes biweekly) set of packages. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15:24:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7EDD537B422 for ; Wed, 23 Aug 2000 15:24:26 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7NMOOD20065; Wed, 23 Aug 2000 15:24:24 -0700 (PDT) Date: Wed, 23 Aug 2000 15:24:24 -0700 From: Alfred Perlstein To: John Polstra Cc: current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823152424.K4854@fw.wintelcom.net> References: <20000823142754.H4854@fw.wintelcom.net> <20000823145244.J4854@fw.wintelcom.net> <200008232203.PAA23790@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200008232203.PAA23790@vashon.polstra.com>; from jdp@polstra.com on Wed, Aug 23, 2000 at 03:03:28PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [000823 15:03] wrote: > In article <20000823145244.J4854@fw.wintelcom.net>, > Alfred Perlstein wrote: > > > John can you try this patch and let us know if you still experiance > > crashes? > > Will do. I'll let you know what happens. Let's take a more paraniod approach (back out my spl in chgsbsize): Index: uipc_socket2.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.61 diff -u -u -r1.61 uipc_socket2.c --- uipc_socket2.c 2000/07/31 08:23:43 1.61 +++ uipc_socket2.c 2000/08/23 22:23:47 @@ -448,10 +448,17 @@ struct sockbuf *sb; struct socket *so; { + int s; sbflush(sb); + /* + * if we don't spl an interrupt can recurse into us and call chgsbsize + * before we zero sb->sb_hiwat + */ + s = splnet(); (void)chgsbsize(so->so_cred->cr_uid, -(rlim_t)sb->sb_hiwat, RLIM_INFINITY); sb->sb_hiwat = sb->sb_mbmax = 0; + splx(s); } /* -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15:39: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 01C6137B424 for ; Wed, 23 Aug 2000 15:38:54 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id PAA01124; Wed, 23 Aug 2000 15:38:52 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id PAA23896; Wed, 23 Aug 2000 15:38:52 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 23 Aug 2000 15:38:52 -0700 (PDT) Message-Id: <200008232238.PAA23896@vashon.polstra.com> To: current@freebsd.org Cc: bright@wintelcom.net Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823152424.K4854@fw.wintelcom.net> References: <20000823145244.J4854@fw.wintelcom.net> <200008232203.PAA23790@vashon.polstra.com> <20000823152424.K4854@fw.wintelcom.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000823152424.K4854@fw.wintelcom.net>, Alfred Perlstein wrote: > > Let's take a more paraniod approach (back out my spl in chgsbsize): > > > Index: uipc_socket2.c Nope, that doesn't fix it. I got the same panic on the very first try. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15:52:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0B3E537B424 for ; Wed, 23 Aug 2000 15:52:17 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7NMqFt20801; Wed, 23 Aug 2000 15:52:15 -0700 (PDT) Date: Wed, 23 Aug 2000 15:52:15 -0700 From: Alfred Perlstein To: John Polstra Cc: current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823155215.M4854@fw.wintelcom.net> References: <20000823145244.J4854@fw.wintelcom.net> <200008232203.PAA23790@vashon.polstra.com> <20000823152424.K4854@fw.wintelcom.net> <200008232238.PAA23896@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200008232238.PAA23896@vashon.polstra.com>; from jdp@polstra.com on Wed, Aug 23, 2000 at 03:38:52PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [000823 15:39] wrote: > In article <20000823152424.K4854@fw.wintelcom.net>, > Alfred Perlstein wrote: > > > > Let's take a more paraniod approach (back out my spl in chgsbsize): > > > > > > Index: uipc_socket2.c > > Nope, that doesn't fix it. I got the same panic on the very first > try. hmm, when does it happen? During the transfer or at the end of the transfer? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 15:55:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 84EC637B422 for ; Wed, 23 Aug 2000 15:55:12 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id PAA01210; Wed, 23 Aug 2000 15:55:10 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id PAA23949; Wed, 23 Aug 2000 15:55:10 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 23 Aug 2000 15:55:10 -0700 (PDT) Message-Id: <200008232255.PAA23949@vashon.polstra.com> To: current@freebsd.org Cc: bright@wintelcom.net Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823155215.M4854@fw.wintelcom.net> References: <20000823152424.K4854@fw.wintelcom.net> <200008232238.PAA23896@vashon.polstra.com> <20000823155215.M4854@fw.wintelcom.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000823155215.M4854@fw.wintelcom.net>, Alfred Perlstein wrote: > > Nope, that doesn't fix it. I got the same panic on the very first > > try. > > hmm, when does it happen? During the transfer or at the end of the > transfer? The first time I reported the problem it had happened during the transfer. This time (with your patch) the transfer actually completed from the peer's point of view before the panic occurred. That's not many data points, so it could be coincidence. I'll keep you posted if I can make it happen again. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 16: 7:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F1DED37B422 for ; Wed, 23 Aug 2000 16:07:35 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7NN7YZ21149; Wed, 23 Aug 2000 16:07:34 -0700 (PDT) Date: Wed, 23 Aug 2000 16:07:33 -0700 From: Alfred Perlstein To: John Polstra Cc: current@freebsd.org Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823160733.N4854@fw.wintelcom.net> References: <20000823152424.K4854@fw.wintelcom.net> <200008232238.PAA23896@vashon.polstra.com> <20000823155215.M4854@fw.wintelcom.net> <200008232255.PAA23949@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200008232255.PAA23949@vashon.polstra.com>; from jdp@polstra.com on Wed, Aug 23, 2000 at 03:55:10PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Polstra [000823 15:55] wrote: > In article <20000823155215.M4854@fw.wintelcom.net>, > Alfred Perlstein wrote: > > > Nope, that doesn't fix it. I got the same panic on the very first > > > try. > > > > hmm, when does it happen? During the transfer or at the end of the > > transfer? > > The first time I reported the problem it had happened during the > transfer. This time (with your patch) the transfer actually completed > from the peer's point of view before the panic occurred. That's not > many data points, so it could be coincidence. I'll keep you posted > if I can make it happen again. more paranioa: Index: uipc_socket.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.80 diff -u -u -r1.80 uipc_socket.c --- uipc_socket.c 2000/08/07 17:52:08 1.80 +++ uipc_socket.c 2000/08/23 23:06:13 @@ -187,8 +187,10 @@ sodealloc(so) struct socket *so; { + int s; so->so_gencnt = ++so_gencnt; + s = splnet(); /* protect against interrupts messing with sbsize */ if (so->so_rcv.sb_hiwat) (void)chgsbsize(so->so_cred->cr_uid, -(rlim_t)so->so_rcv.sb_hiwat, RLIM_INFINITY); @@ -204,6 +206,7 @@ FREE(so->so_accf->so_accept_filter_str, M_ACCF); FREE(so->so_accf, M_ACCF); } + splx(s); crfree(so->so_cred); zfreei(so->so_zone, so); } -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 16:20:19 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 7303237B446 for ; Wed, 23 Aug 2000 16:20:16 -0700 (PDT) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id 2AE381D140; Thu, 24 Aug 2000 00:20:11 +0100 (BST) Message-ID: <39A45C2B.89D8FFE3@originative.co.uk> Date: Thu, 24 Aug 2000 00:20:11 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Alexander Leidinger Cc: ken@kdm.org, stuyman@confusion.net, mwm@mired.org, current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? References: <200008231121.e7NBLQk02859@Magelan.Leidinger.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alexander Leidinger wrote: > > On 23 Aug, Paul Richards wrote: > > >> > On a vaguely related topic, after much searching I can't seem to see one > >> > way or the other if we can do a complete bit-by-bit copy of a cd with > >> > either cdrecord or burncd, though it's possible I'm looking in the wrong > >> > place. > >> > >> I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in > >> ports/audio) can do it as well. > >> > >> As far as getting an image, you can use dd to dump off an image of a CD if > >> it is a standard ISO9660 CD. (I've used that method to clone CDs before.) > > > > That didn't seem to work when I tried it a couple of days ago. Got a > > "device not configured" error. > > You've done something wrong, it works here. Yep, just tried it again and you're right I was doing something wrong. I was trying to dd from the blank in the CD-RW rather than the master in the CD (blush). > BTW: > If I need a copy of a data cd I use "cdrecord -v speed=4 dev=0,1,0 > -eject -isosize /dev/cd1c" (cd1 is my CD-ROM, cd0 (dev=0,1,0) is my CD > burner). That's what I used in the end. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 16:35: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (mass.osd.bsdi.com [204.216.28.234]) by hub.freebsd.org (Postfix) with ESMTP id 495CC37B50D; Wed, 23 Aug 2000 16:35:01 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id QAA00996; Wed, 23 Aug 2000 16:48:23 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200008232348.QAA00996@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Visigoth Cc: current@freebsd.org, cvs-all@freebsd.org Subject: Re: DPT revision....(broken drivers in -STABLE) In-reply-to: Your message of "Wed, 23 Aug 2000 13:51:16 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Aug 2000 16:48:23 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Would it be possible to revert the DPT commits made by peter on > Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the > dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have > production machines that need worlds built for some other updates as > well.. I would be happy to install a -CURRENT machine and help debug > until it works, but for right now, there is NO DPT support in -STABLE for > the DPT PM3334UW. I had a pr started, but haven't been able to get any > response from the current maintainer. I would recommend just preserving the relevant files and updating the rest of the system right now. I think that Matt Dodd is working on this right now. A quick look at the code doesn't suggest anything immediately wrong with the new interrupt assignment code; has anything else in this system been changed? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 16:38:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 59A4037B50D for ; Wed, 23 Aug 2000 16:38:09 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id QAA01383; Wed, 23 Aug 2000 16:38:07 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id QAA24071; Wed, 23 Aug 2000 16:38:06 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 23 Aug 2000 16:38:06 -0700 (PDT) Message-Id: <200008232338.QAA24071@vashon.polstra.com> To: current@freebsd.org Cc: bright@wintelcom.net Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823160733.N4854@fw.wintelcom.net> References: <20000823155215.M4854@fw.wintelcom.net> <200008232255.PAA23949@vashon.polstra.com> <20000823160733.N4854@fw.wintelcom.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000823160733.N4854@fw.wintelcom.net>, Alfred Perlstein wrote: > > more paranioa: > > > Index: uipc_socket.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v > retrieving revision 1.80 > diff -u -u -r1.80 uipc_socket.c > --- uipc_socket.c 2000/08/07 17:52:08 1.80 > +++ uipc_socket.c 2000/08/23 23:06:13 > @@ -187,8 +187,10 @@ > sodealloc(so) Nope, still no go. Here's the stack trace: #9 0xc0166894 in panic ( fmt=0xc027fca0 "reducing sbsize: lost count, uid = %d") at /local0/src/sys/kern/kern_shutdown.c:551 #10 0xc0163b67 in chgsbsize (uid=1001, diff=-17520, max=9223372036854775807) at /local0/src/sys/kern/kern_proc.c:202 #11 0xc0186ffa in sbrelease (sb=0xc7c227f4, so=0xc7c22780) at /local0/src/sys/kern/uipc_socket2.c:459 #12 0xc0184343 in sofree (so=0xc7c22780) at /local0/src/sys/kern/uipc_socket.c:264 #13 0xc01b89ae in in_pcbdetach (inp=0xc7c86440) at /local0/src/sys/netinet/in_pcb.c:542 #14 0xc01c2145 in tcp_close (tp=0xc7c86500) at /local0/src/sys/netinet/tcp_subr.c:711 #15 0xc01c010a in tcp_input (m=0xc075cb00, off0=20, proto=6) at /local0/src/sys/netinet/tcp_input.c:2012 #16 0xc01bb0ba in ip_input (m=0xc075cb00) at /local0/src/sys/netinet/ip_input.c:756 #17 0xc01bb117 in ipintr () at /local0/src/sys/netinet/ip_input.c:784 I see that tcp_close() is in the call stack, but that's surprising. It didn't seem like the transfer had gone on nearly long enough for it to be finishing already. Also, from the peer's point of view it was not finished. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 17:57:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by hub.freebsd.org (Postfix) with ESMTP id 8F6B937B422 for ; Wed, 23 Aug 2000 17:57:41 -0700 (PDT) Received: from waterblue.imgsrc.co.jp (localhost [127.0.0.1]) by waterblue.imgsrc.co.jp (8.11.0/8.11.0) with ESMTP id e7O0vgb13882 for ; Thu, 24 Aug 2000 09:57:43 +0900 (JST) Date: Thu, 24 Aug 2000 09:57:42 +0900 Message-ID: <7mlmxn8ohl.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Current Subject: buildworld failed with MAKE_IDEA=YES User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know this problem is happend only on my box, or not. But I'm using MAKE_IDEA=IES and USA_RESIDENT=NO for buildworld. ===> libcrypto cc -O -mpentiumpro -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DL_ENDIAN -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cpt_err.c -o cpt_err.o ... cc -O -mpentiumpro -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DL_ENDIAN -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c -o e_cbc_i.o /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:78: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c: In function `idea_cbc_init_key': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:97: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:100: syntax error before `tmp' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:102: `tmp' undeclared (first use in this function) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:102: (Each undeclared identifier is reported only once /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:102: for each function it appears in.) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:103: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:105: `IDEA_KEY_SCHEDULE' undeclared (first use in this function) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c: In function `idea_cbc_cipher': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:115: union has no member named `idea_ks' *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src/secure/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Jun Kuriyama // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 18: 9: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail4.post.kek.jp (mail4.post.kek.jp [130.87.41.21]) by hub.freebsd.org (Postfix) with ESMTP id 64E2E37B422 for ; Wed, 23 Aug 2000 18:09:03 -0700 (PDT) Received: from mail2.post.kek.jp (root@mail2.post.kek.jp [130.87.41.19]) by mail4.post.kek.jp (8.9.3+3.2W/3.7WpostKEK:04/29/00) with ESMTP id KAA11254 for ; Thu, 24 Aug 2000 10:09:02 +0900 (JST) (envelope-from yosimoto@post.kek.jp) Received: from darwin.kek.jp (darwin.kek.jp [130.87.85.49]) by mail2.post.kek.jp (8.9.3+3.2W/3.7WpostKEK:05/01/00) with ESMTP id KAA05019 for ; Thu, 24 Aug 2000 10:09:01 +0900 (JST) (envelope-from yosimoto@post.kek.jp) Mime-Version: 1.0 X-Sender: yosimoto@pop.post.kek.jp X-Mailer: Macintosh Eudora Pro Version 4.2.2-Jb6-9.100 Message-Id: Date: Thu, 24 Aug 2000 10:09:01 +0900 To: freebsd-current@FreeBSD.ORG From: Shin-ichi YOSHIMOTO Subject: make buildworld broken in libcrypto. Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got the following error while trying to make builworld with WITH_IDEA=YES and USA_RESIDENT=NO. ===> libcrypto [snip] cc -O -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DL_ENDIAN -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c -o e_cbc_i.o /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:7 8: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c: In function `idea_cbc_init_key': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:9 7: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 00: syntax error before `tmp' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 02: `tmp' undeclared (first use in this function) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 02: (Each undeclared identifier is reported only once /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 02: for each function it appears in.) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 03: union has no member named `idea_ks' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 05: `IDEA_KEY_SCHEDULE' undeclared (first use in this function) /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c: In function `idea_cbc_cipher': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/e_cbc_i.c:1 15: union has no member named `idea_ks' *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. ---------------------------------------------------------- Shin-ichi YOSHIMOTO KEK, High Energy Accelerator Research Organization Accelerator Laboratory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 18:29: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-121.telepath.com [216.14.2.121]) by hub.freebsd.org (Postfix) with SMTP id 57B2A37B423 for ; Wed, 23 Aug 2000 18:29:05 -0700 (PDT) Received: (qmail 4697 invoked by uid 100); 24 Aug 2000 01:28:26 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14756.31290.872353.347749@guru.mired.org> Date: Wed, 23 Aug 2000 20:28:26 -0500 (CDT) To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: References: <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi - Ports Wraith - Asami writes: > * From: Mike Meyer > * However, I was wondering if there was anyone who could fix things that > * weren't PREFIX clean who would also find them on a regular > * basis. That's not you. > I can help you when the new package building cluster (being put > together by Paul Saab at the moment) comes up for service. I'll run > some builds with LOCALBASE and X11BASE set to someplace other than the > default and flag all ports that don't conform. How does it decide whether or not a package conforms? I'm willing to help if you want to divide this task up. Just let me know what I can do to help. To: Mike Smith Cc: cvs-all@freebsd.org, current@freebsd.org Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: <200008232348.QAA00996@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I would recommend just preserving the relevant files and updating the > rest of the system right now. I think that Matt Dodd is working on this > right now. A quick look at the code doesn't suggest anything immediately > wrong with the new interrupt assignment code; has anything else in this > system been changed? No, this system is a regular workstation, and the issue has been tested on a fresh install. Nothin special... Yea, I already did that on at least one machine... (preserving relevent files) Thanks, again, anyway I can help test would be happy to... Visigoth Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOaRviDnmC/+RTnGeEQI6hwCglJixNl6ygc5lB1htPYHhHnq/gfgAoPyg PFi6lsLGRVUo9zDr+sC4oPx8 =jmqK -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 19:18:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id ED80737B422; Wed, 23 Aug 2000 19:18:24 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id WAA46626; Wed, 23 Aug 2000 22:18:23 -0400 (EDT) Date: Wed, 23 Aug 2000 22:18:23 -0400 (EDT) From: "Matthew N. Dodd" To: Mike Smith Cc: Visigoth , current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: <200008232348.QAA00996@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Mike Smith wrote: > I would recommend just preserving the relevant files and updating the > rest of the system right now. I think that Matt Dodd is working on > this right now. A quick look at the code doesn't suggest anything > immediately wrong with the new interrupt assignment code; has anything > else in this system been changed? I don't remember seeing a verbose boot log posted so I can't really say whats wrong. There is no difference b/t the -CURRENT and 4-STABLE versions of dpt_pci.c so I'm not sure what could be causing the problem. Of course it may be that the cards don't work in -CURRENT either. Not having a test system with PCI DPT boards somewhat limits my ability to wring these things out. I won't refuse a rackmounted compaq with PCI and EISA slots and a brace of DPT and Smart2 RAID cards if someone sends me one. Who knows? I might even be able to beat a bit on the management tools then. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 19:26:39 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 07EA837B424; Wed, 23 Aug 2000 19:26:38 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id TAA93044; Wed, 23 Aug 2000 19:26:38 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Wed, 23 Aug 2000 19:26:37 -0700 (PDT) From: Kris Kennaway To: Mike Meyer Cc: Satoshi - Ports Wraith - Asami , "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: <14756.31290.872353.347749@guru.mired.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Mike Meyer wrote: > How does it decide whether or not a package conforms? Probably by looking for files which get installed in /usr/local or /usr/X11R6 instead of ${LOCALBASE} or ${X11BASE} :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 22: 5:17 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B431A37B422; Wed, 23 Aug 2000 22:05:14 -0700 (PDT) Date: Thu, 24 Aug 2000 01:05:13 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Alfred Perlstein Cc: John Polstra , current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823145244.J4854@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Aug 2000, Alfred Perlstein wrote: > * Alfred Perlstein [000823 14:29] wrote: > > > > I have a feeling that this is related to missing spl protection around > > the chgsbsize subsystem, this was probably an issue before I touched it > > but since I touched it last I'll have a look-see. > > > > Brian, does that makes sense? > [...] > > Does it make sense to wrap chgsbsize with spl so callers don't have > to worry about it? > Yeah, I say to go for it. I was /certain/ that these functions had the right spl()s before; if the patch fixes jdp's problem, I can't see a good reason not to change it, other than it would hide what may be quite problematic for other reasons even if not for that one... -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 22:49: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 534FA37B422; Wed, 23 Aug 2000 22:49:05 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7O5n5p00891; Wed, 23 Aug 2000 22:49:05 -0700 (PDT) Date: Wed, 23 Aug 2000 22:49:05 -0700 From: Alfred Perlstein To: Brian Fundakowski Feldman Cc: John Polstra , current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000823224905.W4854@fw.wintelcom.net> References: <20000823145244.J4854@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from green@FreeBSD.ORG on Thu, Aug 24, 2000 at 01:05:13AM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Brian Fundakowski Feldman [000823 22:05] wrote: > On Wed, 23 Aug 2000, Alfred Perlstein wrote: > > > * Alfred Perlstein [000823 14:29] wrote: > > > > > > I have a feeling that this is related to missing spl protection around > > > the chgsbsize subsystem, this was probably an issue before I touched it > > > but since I touched it last I'll have a look-see. > > > > > > Brian, does that makes sense? > > [...] > > > > Does it make sense to wrap chgsbsize with spl so callers don't have > > to worry about it? > > > > Yeah, I say to go for it. I was /certain/ that these functions had > the right spl()s before; if the patch fixes jdp's problem, I can't see > a good reason not to change it, other than it would hide what may be > quite problematic for other reasons even if not for that one... Actually with my patches he still has problems, but I just realized that I'm using splnet in my patches, should I be using splimp? patch is here: http://people.freebsd.org/~alfred/sbsize_spl.diff Note that I'm quite sure it's not just sbsize which needs spl, it's the code that modifies the socketbuffer's size fields as well as the chgsbsize() calls otherwise user context may be preempted by a packet closing the connection after sbsize has been adjusted but not before the buffer sizes have been fixed in the socket struture causing the interrupt context to try to chgsbsize again. Or at least that's what I think may be going on. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Aug 23 22:54:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 4DC8D37B423; Wed, 23 Aug 2000 22:54:56 -0700 (PDT) Received: from silvia.hip.berkeley.edu (sji-ca1-02.ix.netcom.com [209.109.232.2]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id BAA06968; Thu, 24 Aug 2000 01:54:48 -0400 (EDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id WAA73663; Wed, 23 Aug 2000 22:54:45 -0700 (PDT) To: Kris Kennaway Cc: Mike Meyer , "Jacques A. Vidrine" , current@FreeBSD.org Subject: Re: People running with LOCALBASE set to something other than /usr/local? References: From: asami@FreeBSD.org (Satoshi - Ports Wraith - Asami) Date: 23 Aug 2000 22:54:44 -0700 In-Reply-To: Kris Kennaway's message of "Wed, 23 Aug 2000 19:26:37 -0700 (PDT)" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Kris Kennaway * On Wed, 23 Aug 2000, Mike Meyer wrote: * * > How does it decide whether or not a package conforms? * * Probably by looking for files which get installed in /usr/local or * /usr/X11R6 instead of ${LOCALBASE} or ${X11BASE} :-) Actually, it's easier than that -- just do a "make package". If files go to anyplace else than ${PREFIX}, pkg_create will fail. :) However, note that you need to move LOCALBASE and X11BASE for *all* ports, not one. (For instance, you can't expect an emacs-lisp package to install correctly if you just try to move it while emacs is still in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and rebuild everything, including X. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 1:21:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id 6F9BE37B422; Thu, 24 Aug 2000 01:21:30 -0700 (PDT) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.0/8.9.3) id e7O8LSd37977; Thu, 24 Aug 2000 15:21:28 +0700 (NOVST) (envelope-from nnd) Date: Thu, 24 Aug 2000 15:21:28 +0700 (NOVST) Message-Id: <200008240821.e7O8LSd37977@wint.itfs.nsk.su> From: Nickolay Dudorov Cc: current@FreeBSD.ORG To: Brian Feldman Subject: Re: cvs commit: src/secure/lib/libcrypto Makefile Makefile.inc In-Reply-To: <200008231141.EAA87303@freefall.freebsd.org> X-Newsgroups: itfs.freebsd.cvs.all User-Agent: tin/1.5.6-20000803 ("Dust") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200008231141.EAA87303@freefall.freebsd.org> you wrote: > green 2000/08/23 04:41:01 PDT > > Modified files: > secure/lib/libcrypto Makefile Makefile.inc > Log: > Generate a new evp.h at build-time instead of install-time to properly > support NFS(ro) installworlds. > > Revision Changes Path > 1.22 +3 -5 src/secure/lib/libcrypto/Makefile > 1.16 +6 -3 src/secure/lib/libcrypto/Makefile.inc I usually run 'make -j32 buildworld' on my current system. After this commit I can not do this. The next patch permits to use '-j32' again. N.Dudorov Index: src/secure/lib/libcrypto/Makefile =================================================================== RCS file: /store/CVS/src/secure/lib/libcrypto/Makefile,v retrieving revision 1.22 diff -b -u -r1.22 Makefile --- src/secure/lib/libcrypto/Makefile 2000/08/23 11:41:00 1.22 +++ src/secure/lib/libcrypto/Makefile 2000/08/24 07:59:34 @@ -268,6 +268,7 @@ des_crypt.3 des_enc_read.3 des_crypt.3 des_enc_write.3 \ des_crypt.3 des_set_odd_parity.3 des_crypt.3 des_is_weak_key.3 +.ORDER: openssl/opensslconf.h openssl/evp.h beforeinstall: openssl/opensslconf.h openssl/evp.h ${INSTALL} ${COPY} -o ${BINOWN} -g ${BINGRP} -m 444 \ ${CRYPTO_HDRS} openssl/opensslconf.h \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 3: 8:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 118A637B43C; Thu, 24 Aug 2000 03:08:19 -0700 (PDT) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id CBC201D140; Thu, 24 Aug 2000 11:08:17 +0100 (BST) Message-ID: <39A4F411.83DB4ED4@originative.co.uk> Date: Thu, 24 Aug 2000 11:08:17 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Jeroen Ruigrok van der Werven , Ollivier Robert , FreeBSD Current Users' list , green@FreeBSD.ORG Subject: Re: make buildworld br0ken in libutil References: <39A2A98E.EC1D33C4@originative.co.uk> <200008221644.e7MGiJe01520@grimreaper.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > > Why does crypt need to be in libc? Not even a significant fraction of > > applications need crypt? > > Goes for very many libc components. Quite a lot of userland needs libcrypt > (not much as a proportion, but a non-insignificant number). This runs counter to my gut instinct of development which is to modularise code. Modularisation is accepted as a goal in all other areas of the tree it doesn't make sense to me why that thinking is being put to one side when it comes to the libraries. Maybe this should move to arch because I guess I'd like to see a actual design discussion as to why the current thinking is to collapse libraries into libc rather than to actually go the other way and modularise the code. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 3:52:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 1246837B424 for ; Thu, 24 Aug 2000 03:52:12 -0700 (PDT) Received: from areilly.bpc-users.org (CPE-144-132-245-92.nsw.bigpond.net.au [144.132.245.92]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id UAA15251 for ; Thu, 24 Aug 2000 20:52:07 +1000 (EST) Received: (qmail 33384 invoked by uid 1000); 24 Aug 2000 10:52:06 -0000 From: "Andrew Reilly" Date: Thu, 24 Aug 2000 20:52:06 +1000 To: Satoshi - Ports Wraith - Asami Cc: Kris Kennaway , Mike Meyer , "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000824205206.A32882@gurney.reilly.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from asami@FreeBSD.ORG on Wed, Aug 23, 2000 at 10:54:44PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 10:54:44PM -0700, Satoshi - Ports Wraith - Asami wrote: > However, note that you need to move LOCALBASE and X11BASE for *all* > ports, not one. (For instance, you can't expect an emacs-lisp package > to install correctly if you just try to move it while emacs is still > in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and > rebuild everything, including X. On the subject of rebuilding everything, is there a tool that will build a dependency-ordered list of all of the ports that are currently installed (or at least the current version of them)? I've been thinking that it would be a nice housekeeping proceedure every so often to move /usr/local aside, and rebuild all of the ports that I use, after a successful build of world and kernel. At least that would help to keep track of things that I've gratuitously added to /usr/local, outside of the ports mechanism. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 4: 6:50 2000 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 0496737B423 for ; Thu, 24 Aug 2000 04:06:48 -0700 (PDT) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id NAA73245; Thu, 24 Aug 2000 13:06:46 +0200 (CEST) (envelope-from olli) Date: Thu, 24 Aug 2000 13:06:46 +0200 (CEST) Message-Id: <200008241106.NAA73245@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG Reply-To: freebsd-current@FreeBSD.ORG Subject: Re: Why no CDR ioctls for SCSI cds? X-Newsgroups: list.freebsd-current In-Reply-To: <8nv8tg$28v2$1@atlantis.rz.tu-clausthal.de> Organization: Administration TU Clausthal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In list.freebsd-current Kenneth D. Merry wrote: > On Tue, Aug 22, 2000 at 20:43:15 -0400, Laurence Berland wrote: > > On a vaguely related topic, after much searching I can't seem to see one > > way or the other if we can do a complete bit-by-bit copy of a cd with > > either cdrecord or burncd, though it's possible I'm looking in the wrong > > place. > > I think cdrecord can burn CDs in disk-at-once mode, and I think cdrdao (in > ports/audio) can do it as well. > > As far as getting an image, you can use dd to dump off an image of a CD if > it is a standard ISO9660 CD. (I've used that method to clone CDs before.) > > If it uses a blocksize other than 2048 bytes, though, you can't use dd with > the SCSI cd driver. > > There may be CD rippers that can pull the data off into an image, though. > I don't know for sure. Tosha can read tracks from CDs with 2352 byte blocks, for example VideoCDs. I'm using it sometimes to directly pipe the data into MpegTV to view VCDs under FreeBSD. (BTW, tosha can also read standard data tracks with 2048 byte blocks. While dd provides the same functionality, tosha has a few nice features such as a progress and ETA display, which might make it preferable over dd.) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) Addresses will change soon!! If in doubt: www.fromme.com "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 4:18:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 5DFD437B423; Thu, 24 Aug 2000 04:18:51 -0700 (PDT) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13Rv1f-00061t-00; Thu, 24 Aug 2000 13:18:27 +0200 Date: Thu, 24 Aug 2000 13:18:27 +0200 From: Neil Blakey-Milner To: Andrew Reilly Cc: Satoshi - Ports Wraith - Asami , Kris Kennaway , Mike Meyer , "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Message-ID: <20000824131827.A23159@mithrandr.moria.org> References: <20000824205206.A32882@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000824205206.A32882@gurney.reilly.home>; from areilly@bigpond.net.au on Thu, Aug 24, 2000 at 08:52:06PM +1000 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu 2000-08-24 (20:52), Andrew Reilly wrote: > On Wed, Aug 23, 2000 at 10:54:44PM -0700, Satoshi - Ports Wraith - Asami wrote: > > However, note that you need to move LOCALBASE and X11BASE for *all* > > ports, not one. (For instance, you can't expect an emacs-lisp package > > to install correctly if you just try to move it while emacs is still > > in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and > > rebuild everything, including X. > > At least that would help to keep track of things that I've > gratuitously added to /usr/local, outside of the ports > mechanism. Try /usr/ports/Tools/scripts/consistency-check Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 6:10:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A752D37B424; Thu, 24 Aug 2000 06:10:10 -0700 (PDT) Date: Thu, 24 Aug 2000 09:10:09 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Alfred Perlstein Cc: John Polstra , current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <20000823145244.J4854@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Try making them small critical sections. If it makes it easier, which it probably will, try this: pass the pointer to sb_hiwat as an argument to chgsbsize and make that the only way to modify it (sockbuf creation would have to be a place where it's initialized manually to 0 ;) I'd say stick the hiwat increment of delta at the end, after malloc, since that would place it in the same context as the setting. Luckily, doing this right would be making the code clearer in several of the (few) places sb_hiwat is used. We just have to assure that sb_hiwat is always consistent with the ui_sbsize which can be done with a critical section that "knows" the delta to apply and where to apply it. Using splimp() should not be necessary as that is used for mbuf protection, which is why network card drivers' interrupts must be called at splimp() (an aggregate mask which includes splnet()): they need to not corrupt the mbuf subsystem. Plus, it makes a convenient critical section for the network drivers in this way :) At least, this is how I learned it to be. I'm not sure if it's absolutely correct, but it should be. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 6:41:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom2-101.telepath.com [216.14.2.101]) by hub.freebsd.org (Postfix) with SMTP id 80F4D37B43C for ; Thu, 24 Aug 2000 06:41:52 -0700 (PDT) Received: (qmail 14365 invoked by uid 100); 24 Aug 2000 13:41:50 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14757.9758.636019.42099@guru.mired.org> Date: Thu, 24 Aug 2000 08:41:50 -0500 (CDT) To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: Kris Kennaway , "Jacques A. Vidrine" , current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi - Ports Wraith - Asami writes: > * From: Kris Kennaway > * On Wed, 23 Aug 2000, Mike Meyer wrote: > * > How does it decide whether or not a package conforms? > * Probably by looking for files which get installed in /usr/local or > * /usr/X11R6 instead of ${LOCALBASE} or ${X11BASE} :-) > Actually, it's easier than that -- just do a "make package". If files > go to anyplace else than ${PREFIX}, pkg_create will fail. :) > However, note that you need to move LOCALBASE and X11BASE for *all* > ports, not one. (For instance, you can't expect an emacs-lisp package > to install correctly if you just try to move it while emacs is still > in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and > rebuild everything, including X. There's a test that's almost that simple that works even if you haven't moved PREFIX for all ports. Since the pkg +CONTENTS list is derived from PREFIX and the PLIST, "make install" followed by "make deinstall" will complain about not being able to delete files that weren't installed in the proper place. ; Thu, 24 Aug 2000 08:21:30 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13Ryol-0002SP-00; Thu, 24 Aug 2000 17:21:23 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id RAA06166; Thu, 24 Aug 2000 17:21:20 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 5916; Thu Aug 24 17:19:35 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13Ryn0-000MLN-00; Thu, 24 Aug 2000 17:19:34 +0200 From: Sheldon Hearn To: Tony Fleisher Cc: freebsd-current@freebsd.org Subject: Re: problems with /usr/bin/awk In-reply-to: Your message of "Tue, 22 Aug 2000 12:27:01 +0200." <17031.966940021@axl.fw.uunet.co.za> Date: Thu, 24 Aug 2000 17:19:34 +0200 Message-ID: <85892.967130374@axl.fw.uunet.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 22 Aug 2000 12:27:01 +0200, Sheldon Hearn wrote: > > awk: ./guile-snarf.awk:17: (FILENAME=- FNR=9680) fatal error: internal > > error > > Abort trap - core dumped > > *** Error code 1 > > I get the same thing here. Inspecting the core dump, one finds that the > abort() happens in eval.c:1668, just below a huge FIXME comment. I'll > contact the gawk maintainers. This is a bitch. If I run the problematic awk script from the command-line, feeding it exactly the same input as it is given from the Makefile, awk does not dump core, but rather completes successfully. When run from gmake, it dumps core. So I'm a bit stumped as far as formulating an easy How-To-Repeat is concerned. :-( Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 10:30: 7 2000 Delivered-To: freebsd-current@freebsd.org Received: from doorstop.webtv.net (doorstop.webtv.net [207.46.121.10]) by hub.freebsd.org (Postfix) with ESMTP id 779B237B422 for ; Thu, 24 Aug 2000 10:30:05 -0700 (PDT) Received: by doorstop.webtv.net; id KAA21705; Thu, 24 Aug 2000 10:27:44 -0700 (PDT) Received: from unknown(157.57.212.23) by svc-egress.artemis.com via smap (V5.0) id xma021367; Thu, 24 Aug 00 10:26:44 -0700 Received: (qmail 2500 invoked by uid 3215); 24 Aug 2000 17:29:03 -0000 Date: Thu, 24 Aug 2000 10:29:03 -0700 From: Jos Backus To: current@freebsd.org Subject: devfs, moused and rc.devfs position in rc Message-ID: <20000824102903.A2492@traitor.artemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In /etc/rc, rc.i386 is invoked before rc.devfs. This causes moused to fail to start for those people who use a link from /dev/ to /dev/mouse. The fix seems to be to switch the order of invocation: # Run rc.devfs if readable to customize devfs # if [ -r /etc/rc.devfs ]; then sh /etc/rc.devfs fi # Configure implementation specific stuff # arch=`uname -m` if [ -r /etc/rc.${arch} ]; then . /etc/rc.${arch} fi Hth, -- Jos Backus WebTV Networks, Inc., Mountain View, CA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 10:31:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.telemere.net (mail.telemere.net [63.224.9.4]) by hub.freebsd.org (Postfix) with ESMTP id 2EDAC37B422; Thu, 24 Aug 2000 10:31:43 -0700 (PDT) Received: by mail.telemere.net (Postfix, from userid 1001) id 8F37520F01; Thu, 24 Aug 2000 12:34:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by mail.telemere.net (Postfix) with ESMTP id 8CD861D101; Thu, 24 Aug 2000 12:34:48 -0500 (CDT) Date: Thu, 24 Aug 2000 12:34:43 -0500 (CDT) From: Visigoth To: "Matthew N. Dodd" Cc: Mike Smith , current@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 23 Aug 2000, Matthew N. Dodd wrote: > I don't remember seeing a verbose boot log posted so I can't really say > whats wrong. There is no difference b/t the -CURRENT and 4-STABLE > versions of dpt_pci.c so I'm not sure what could be causing the > problem. Of course it may be that the cards don't work in -CURRENT > either. Correct, the cards don't work in current either. The driver is failing in its call to bus_alloc_resource() for the irq in dpt_pci.c, and then panic(9) ensues as it tries to resource_list_release but cant find resource. During the boot it comes up with: dpt0: port 0xdc60-0xdc7f irq 16 at device 8.0 on pci 2 even though bios asigned it irq 9... hmmm.... I have tried it on a few machines now, with both -current and -stable > Not having a test system with PCI DPT boards somewhat limits my ability to > wring these things out. I won't refuse a rackmounted compaq with PCI and > EISA slots and a brace of DPT and Smart2 RAID cards if someone sends me > one. Who knows? I might even be able to beat a bit on the management > tools then. I may be able to help some here... Would root on a testbed,breakable,remote dual xeon machine with a dpt card in it help? I could install a snapshot from before the commits and let you have at it. I would even reboot it into the working kernel from here if you need ;)... Boy those DPT utils would be nice.... heh Visigoth Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOaVOpjnmC/+RTnGeEQLrcwCfTud8DcoJyr3KOLp1FPnT9TLOiRAAoJQ5 s5us3H/2tb7mcnwDAjfjcBnL =5aP+ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 10:41:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 961F037B43C for ; Thu, 24 Aug 2000 10:40:59 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id TAA26284 for current@freebsd.org; Thu, 24 Aug 2000 19:40:58 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200008241740.TAA26284@freebsd.dk> Subject: Anybody with a Maxtor disk that doesn't work with DMA ?? To: current@freebsd.org Date: Thu, 24 Aug 2000 19:40:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a patch I want you to try, please get in contact with me! Thanks! -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 12: 9:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 58AD337B422 for ; Thu, 24 Aug 2000 12:09:12 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA71749; Thu, 24 Aug 2000 13:09:10 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA11539; Thu, 24 Aug 2000 13:09:07 -0600 (MDT) Message-Id: <200008241909.NAA11539@harmony.village.org> To: Sheldon Hearn Subject: Re: People running with LOCALBASE set to something other than /usr/local? Cc: Konstantin Chuguev , "Jacques A. Vidrine" , current@FreeBSD.ORG In-reply-to: Your message of "Wed, 23 Aug 2000 14:44:36 +0200." <14141.967034676@axl.fw.uunet.co.za> References: <14141.967034676@axl.fw.uunet.co.za> Date: Thu, 24 Aug 2000 13:09:07 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14141.967034676@axl.fw.uunet.co.za> Sheldon Hearn writes: : On Wed, 23 Aug 2000 13:36:56 +0100, Konstantin Chuguev wrote: : : > Just wondering: what is the reason of using /opt instead of /usr/local, : > apart from Solaris influence? Do you use /usr/local for anything? : : NetBSD uses /usr/opt . It's a matter of taste. :-) NetBSD uses /usr/pkg. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 12:11:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1915C37B422; Thu, 24 Aug 2000 12:11:39 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA71763; Thu, 24 Aug 2000 13:11:37 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA11562; Thu, 24 Aug 2000 13:11:36 -0600 (MDT) Message-Id: <200008241911.NAA11562@harmony.village.org> To: obrien@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? Cc: Konstantin Chuguev , current@FreeBSD.ORG In-reply-to: Your message of "Wed, 23 Aug 2000 07:46:37 PDT." <20000823074637.A42348@dragon.nuxi.com> References: <20000823074637.A42348@dragon.nuxi.com> <14754.2222.927759.462718@guru.mired.org> <20000822084309.D38787@hamlet.nectar.com> <14755.26839.743103.399203@guru.mired.org> <20000823065243.A43477@hamlet.nectar.com> <39A3C568.32E686EC@dante.org.uk> Date: Thu, 24 Aug 2000 13:11:35 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000823074637.A42348@dragon.nuxi.com> "David O'Brien" writes: : Yes, local stuff. IMHO, the Ports Collection using /usr/local was the : biggest mistake of it. The ports collection should have used /usr/pkg/ : as NetBSD does. I have to create /usr/truely-local on my FreeBSD : machines. But the ports collection predated NetBSD's use of /usr/pkg... I have a /local for things that must be local to the machine and /usr/local NFS mounted in one lab. In the other, I don't worry about it and have /usr/local and /packages. In a third I have /usr/local and no central package area. The only thing that seems different is the order of my path variable :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 12:27:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from ego.mind.net (ego.mind.net [206.99.66.9]) by hub.freebsd.org (Postfix) with ESMTP id 745FA37B424 for ; Thu, 24 Aug 2000 12:27:23 -0700 (PDT) Received: from takhus-home.ashlandfn.org (AFN-Dynamic-21924.ashlandfiber.net [208.46.219.24]) by ego.mind.net (8.9.3/8.9.3) with ESMTP id MAA15592; Thu, 24 Aug 2000 12:27:21 -0700 Received: from localhost (fleisher@localhost) by takhus-home.ashlandfn.org (8.11.0/8.9.3) with ESMTP id e7OJREu58499; Thu, 24 Aug 2000 12:27:14 -0700 (PDT) (envelope-from takhus@takhus.mind.net) Date: Thu, 24 Aug 2000 12:27:14 -0700 (PDT) From: Tony Fleisher X-Sender: fleisher@takhus-home.ashlandfn.org To: Sheldon Hearn Cc: freebsd-current@FreeBSD.ORG Subject: Re: problems with /usr/bin/awk In-Reply-To: <85892.967130374@axl.fw.uunet.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I also was able to get it to run properly when not redirecting to a file. I wonder if there might be some dependancy in the system that causes different behavior with this when output is to a tty vs. a filehandle. I tried this with a copy of /bin/sh from 4.0-RELEASE, and had the same result, so I think we can probably rule out /bin/sh as the culprit. This might provide some further help: # pwd /usr/ports/lang/guile/work/guile-1.4/libguile # PATH=.:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin ./guile-doc-snarf eval.c -DHAVE_CONFIG_H -I.. -I./.. -I../libltdl -O -pipe -Wall -Wmissing-prototypes eval.c > eval.x awk: ./guile-snarf.awk:17: (FILENAME=- FNR=9680) fatal error: internal error Abort trap - core dumped # cat eval.x scm_unbound_variable_key = scm_permanent_object (( ((scm_bits_t) ( ((scm_bits_t *) ((SCM_CELLPTR) (( scm_intern0 ( "unbound-variable" ) ) )) ) [ 0 ] )) ) ) ; On Thu, 24 Aug 2000, Sheldon Hearn wrote: > > > On Tue, 22 Aug 2000 12:27:01 +0200, Sheldon Hearn wrote: > > > > awk: ./guile-snarf.awk:17: (FILENAME=- FNR=9680) fatal error: internal > > > error > > > Abort trap - core dumped > > > *** Error code 1 > > > > I get the same thing here. Inspecting the core dump, one finds that the > > abort() happens in eval.c:1668, just below a huge FIXME comment. I'll > > contact the gawk maintainers. > > This is a bitch. If I run the problematic awk script from the > command-line, feeding it exactly the same input as it is given from the > Makefile, awk does not dump core, but rather completes successfully. > When run from gmake, it dumps core. > > So I'm a bit stumped as far as formulating an easy How-To-Repeat is > concerned. :-( > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 12:49:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id EFB9A37B423 for ; Thu, 24 Aug 2000 12:49:32 -0700 (PDT) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.9.3/8.9.3) id VAA28213; Thu, 24 Aug 2000 21:49:31 +0200 (CEST) (envelope-from olli) Date: Thu, 24 Aug 2000 21:49:31 +0200 (CEST) Message-Id: <200008241949.VAA28213@dorifer.heim3.tu-clausthal.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG Reply-To: freebsd-current@FreeBSD.ORG Subject: Re: People running with LOCALBASE set to something other than /usr/local? X-Newsgroups: list.freebsd-current In-Reply-To: <8o3rt2$26j7$1@atlantis.rz.tu-clausthal.de> Organization: Administration TU Clausthal MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: tin/1.4.1-19991201 ("Polish") (UNIX) (FreeBSD/3.4-19991219-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In list.freebsd-current Warner Losh wrote: > In message <14141.967034676@axl.fw.uunet.co.za> Sheldon Hearn writes: > : On Wed, 23 Aug 2000 13:36:56 +0100, Konstantin Chuguev wrote: > : > : > Just wondering: what is the reason of using /opt instead of /usr/local, > : > apart from Solaris influence? Do you use /usr/local for anything? > : > : NetBSD uses /usr/opt . It's a matter of taste. :-) > > NetBSD uses /usr/pkg. Just as a side note (I'm not a comitter)... At the university we use /rzdist/FreeBSD for historical reasons. That directory is distributed via rdist to several servers, and then exported via NFS to clients. Of course, there's also /rzdist/linux and others. /usr/local is only used for "real" locally installed software. It is true that there are quite a lot of ports that don't support PREFIXes different from /usr/local correctly. I know, I should have send-pr'ed all of them, but that would have taken me several days... I promise to do it next time I stumble across some, I promise. :-) Even more off-topic: On our Solaris boxes, we use /opt for external packages (such as those that come from Sun itself, like the compiler suite SUNWspro), and we use /usr/local for software that we install ourself manually, i.e. not from a ready-made package. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) Addresses will change soon!! If in doubt: www.fromme.com "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 14:24:23 2000 Delivered-To: freebsd-current@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 45E4E37B423; Thu, 24 Aug 2000 14:24:21 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7OLOKG01037; Thu, 24 Aug 2000 14:24:20 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma001034; Thu, 24 Aug 2000 14:24:17 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id OAA01969; Thu, 24 Aug 2000 14:24:16 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008242124.OAA01969@bubba.whistle.com> Subject: Re: People running with LOCALBASE set to something other than /usr/local? In-Reply-To: "from Satoshi - Ports Wraith - Asami at Aug 23, 2000 03:23:29 pm" To: Satoshi - Ports Wraith - Asami Date: Thu, 24 Aug 2000 14:24:16 -0700 (PDT) Cc: Mike Meyer , "Jacques A. Vidrine" , current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi - Ports Wraith - Asami writes: > * However, I was wondering if there was anyone who could fix things that > * weren't PREFIX clean who would also find them on a regular > * basis. That's not you. > > I can help you when the new package building cluster (being put > together by Paul Saab at the moment) comes up for service. I'll run > some builds with LOCALBASE and X11BASE set to someplace other than the > default and flag all ports that don't conform. > > I couldn't do that for a while since I didn't have enough computing > power -- the machines were maxed out just squeezing out the weekly > (and sometimes biweekly) set of packages. Random though.. this stuff sounds like a good use for snapshots! I.e., snapshot before "make install" and then figure out what got installed by decoding the snapshot file, or something like that. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 14:52:33 2000 Delivered-To: freebsd-current@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 1FC1237B43C; Thu, 24 Aug 2000 14:52:30 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7OLqKW01284; Thu, 24 Aug 2000 14:52:20 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma001281; Thu, 24 Aug 2000 14:52:15 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id OAA02179; Thu, 24 Aug 2000 14:52:15 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008242152.OAA02179@bubba.whistle.com> Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: "from Brian Fundakowski Feldman at Aug 24, 2000 09:10:09 am" To: Brian Fundakowski Feldman Date: Thu, 24 Aug 2000 14:52:15 -0700 (PDT) Cc: Alfred Perlstein , John Polstra , current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know if this is related to the problems you guys are looking at, but I have a box that every so often (every couple of months) panics with a "panic: recieve 1" panic. This panic happens when the socket character count is bogus during a recv(2), etc. system call. So several months ago I came up with a patch to try and track this down, and with the patch it panics immediately.. but I couldn't figure out why at the time and haven't pursued it since then. Anyway, for what it's worth, the patch I was using is here: ftp://ftp.whistle.com/pub/archie/misc/sbcheck.patch Some variant of it may be useful for tracking down this problem too. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 15:22:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 300D737B423 for ; Thu, 24 Aug 2000 15:22:34 -0700 (PDT) Received: from areilly.bpc-users.org (CPE-144-132-245-92.nsw.bigpond.net.au [144.132.245.92]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id IAA29358 for ; Fri, 25 Aug 2000 08:22:30 +1000 (EST) Received: (qmail 52734 invoked by uid 1000); 24 Aug 2000 22:22:28 -0000 From: "Andrew Reilly" Date: Fri, 25 Aug 2000 08:22:28 +1000 To: Sheldon Hearn Cc: Tony Fleisher , freebsd-current@FreeBSD.ORG Subject: Re: problems with /usr/bin/awk Message-ID: <20000825082228.A51930@gurney.reilly.home> References: <17031.966940021@axl.fw.uunet.co.za> <85892.967130374@axl.fw.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <85892.967130374@axl.fw.uunet.co.za>; from sheldonh@uunet.co.za on Thu, Aug 24, 2000 at 05:19:34PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Aug 24, 2000 at 05:19:34PM +0200, Sheldon Hearn wrote: > So I'm a bit stumped as far as formulating an easy How-To-Repeat is > concerned. :-( How about wedging a printenv into the makefile, before the call to awk, so that you can re-create the environment when testing it? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 16:12:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 25FA537B423; Thu, 24 Aug 2000 16:12:17 -0700 (PDT) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e7ONCGL25930; Thu, 24 Aug 2000 16:12:16 -0700 (PDT) Date: Thu, 24 Aug 2000 16:12:16 -0700 From: Alfred Perlstein To: Archie Cobbs Cc: Brian Fundakowski Feldman , John Polstra , current@FreeBSD.ORG Subject: Re: panic: reducing sbsize: lost count, uid = 1001 Message-ID: <20000824161216.C1209@fw.wintelcom.net> References: <200008242152.OAA02179@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200008242152.OAA02179@bubba.whistle.com>; from archie@whistle.com on Thu, Aug 24, 2000 at 02:52:15PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Archie Cobbs [000824 14:52] wrote: > I don't know if this is related to the problems you guys are looking at, > but I have a box that every so often (every couple of months) panics > with a "panic: recieve 1" panic. This panic happens when the socket > character count is bogus during a recv(2), etc. system call. > > So several months ago I came up with a patch to try and track this > down, and with the patch it panics immediately.. but I couldn't > figure out why at the time and haven't pursued it since then. > > Anyway, for what it's worth, the patch I was using is here: > > ftp://ftp.whistle.com/pub/archie/misc/sbcheck.patch > > Some variant of it may be useful for tracking down this problem too. It seems that the socket counters aren't being protected by spl enough, brian has suggested moving it into the chgsbsize function which would encapsulate spl+uidinfo+sbsize issues. I'm hoping he'll look into it, and I will be as well as soon as I find the time. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 16:23:22 2000 Delivered-To: freebsd-current@freebsd.org Received: from daemon.kek.jp (daemon.kek.jp [130.87.85.2]) by hub.freebsd.org (Postfix) with ESMTP id B6C4937B42C for ; Thu, 24 Aug 2000 16:23:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daemon.kek.jp (8.11.0/8.11.0) with ESMTP id e7ONNHn62504 for ; Fri, 25 Aug 2000 08:23:18 +0900 (JST) (envelope-from yosimoto@daemon.kek.jp) To: freebsd-current@freebsd.org Subject: make buildworld broken in usr.bin/systat X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Channel Islands) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000825082317V.yosimoto@daemon.kek.jp> Date: Fri, 25 Aug 2000 08:23:17 +0900 From: Shin-ichi YOSHIMOTO X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG make buildworld failed this morning. Error messages are as follows: ===> usr.bin/systat [snip] cc -O -pipe -I/usr/src/usr.bin/systat/../../sys -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/systat/swap.c In file included from /usr/src/usr.bin/systat/swap.c:47: /usr/src/usr.bin/systat/../../sys/sys/conf.h:59: field `si_atime' has incomplete type /usr/src/usr.bin/systat/../../sys/sys/conf.h:60: field `si_ctime' has incomplete type /usr/src/usr.bin/systat/../../sys/sys/conf.h:61: field `si_mtime' has incomplete type *** Error code 1 Stop in /usr/src/usr.bin/systat. ---------------------------------------------------------- KEK, High Energy Accelerator Research Organization Shin-ichi YOSHIMOTO To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 17:27:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp.bsdhome.com (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 4F34F37B423 for ; Thu, 24 Aug 2000 17:27:56 -0700 (PDT) Received: from vger.bsdhome.com (vger [192.168.220.2]) by smtp.bsdhome.com (8.9.3/8.9.3) with ESMTP id UAA18164 for ; Thu, 24 Aug 2000 20:27:55 -0400 (EDT) (envelope-from bsd@bsdhome.com) Received: from localhost (bsd@localhost) by vger.bsdhome.com (8.9.3/8.9.3) with ESMTP id UAA20728 for ; Thu, 24 Aug 2000 20:27:55 -0400 (EDT) (envelope-from bsd@vger.bsdhome.com) Date: Thu, 24 Aug 2000 20:27:54 -0400 (EDT) From: Brian Dean To: freebsd-current@freebsd.org Subject: Review requested for i386 debug register helper functions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, If you have the time, I would very much appreciate any reviews on a couple of helper functions that I've put together for manipulating the i386 debug registers: http://people.freebsd.org/~bsd/i386watch/ I've had these in my toolkit for a long time and present them here, slightly modified. They are intended to keep folks from re-inventing the wheel. I've had at least two people ask for these to be committed. My main concern is their location in the tree. I've got them under src/lib/libc/i386/sys, and manual section 2. They are not quite system calls, but this seemed to be the best fit location for these. I'm open to other suggestions as well. Thanks, Brian -- Brian Dean bsd@FreeBSD.org bsd@bsdhome.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 17:55:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from web109.yahoomail.com (web109.yahoomail.com [205.180.60.76]) by hub.freebsd.org (Postfix) with SMTP id 1B9D337B423 for ; Thu, 24 Aug 2000 17:55:43 -0700 (PDT) Received: (qmail 18339 invoked by uid 60001); 25 Aug 2000 00:55:33 -0000 Message-ID: <20000825005533.18338.qmail@web109.yahoomail.com> Received: from [168.191.63.184] by web109.yahoomail.com; Thu, 24 Aug 2000 17:55:33 PDT Date: Thu, 24 Aug 2000 17:55:33 -0700 (PDT) From: Maksim Yevmenkin Subject: patch: new DEVFS support for TAP driver To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1957747793-967164933=:17404" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0-1957747793-967164933=:17404 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline All, please review, test and commit (if no objection :-) attached patch for tap driver. this is to support new devfs. thanks, emax __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ --0-1957747793-967164933=:17404 Content-Type: application/x-unknown; name="if_tap.c.diff" Content-Transfer-Encoding: base64 Content-Description: if_tap.c.diff Content-Disposition: attachment; filename="if_tap.c.diff" KioqIC9zeXMvbmV0L2lmX3RhcC5jCVdlZCBKdWwgMjYgMjA6Mzg6NDYgMjAw MAotLS0gaWZfdGFwLmMJVGh1IEF1ZyAyNCAyMDozOTo1OSAyMDAwCioqKioq KioqKioqKioqKgoqKiogMzIsNDEgKioqKgogIAogIC8qCiAgICogJEZyZWVC U0Q6IHNyYy9zeXMvbmV0L2lmX3RhcC5jLHYgMS4zIDIwMDAvMDcvMjUgMjM6 NTA6MzAgbnNheWVyIEV4cCAkCiEgICogJElkOiBpZl90YXAuYyx2IDAuMjEg MjAwMC8wNy8yMyAyMTo0NjowMiBtYXggRXhwICQKICAgKi8KICAKICAjaW5j bHVkZSAib3B0X2luZXQuaCIKICAKICAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+ CiAgI2luY2x1ZGUgPHN5cy9jb25mLmg+Ci0tLSAzMiw0MiAtLS0tCiAgCiAg LyoKICAgKiAkRnJlZUJTRDogc3JjL3N5cy9uZXQvaWZfdGFwLmMsdiAxLjMg MjAwMC8wNy8yNSAyMzo1MDozMCBuc2F5ZXIgRXhwICQKISAgKiAkSWQ6IGlm X3RhcC5jLHYgMC4yNCAyMDAwLzA4LzI1IDAxOjM5OjU5IG1heCBFeHAgJAog ICAqLwogIAogICNpbmNsdWRlICJvcHRfaW5ldC5oIgorICNpbmNsdWRlICJv cHRfZGV2ZnMuaCIKICAKICAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAgI2lu Y2x1ZGUgPHN5cy9jb25mLmg+CioqKioqKioqKioqKioqKgoqKiogNjYsNzEg KioqKgotLS0gNjcsNzcgLS0tLQogICNpbmNsdWRlIDxuZXQvaWZfdGFwdmFy Lmg+CiAgI2luY2x1ZGUgPG5ldC9pZl90YXAuaD4KICAKKyAjaWZkZWYgREVW RlMKKyAjaW5jbHVkZSA8c3lzL2V2ZW50aGFuZGxlci5oPgorICNpbmNsdWRl IDxmcy9kZXZmcy9kZXZmcy5oPgorICNlbmRpZgorIAogIAogICNkZWZpbmUg Q0RFVl9OQU1FCSJ0YXAiCiAgI2RlZmluZSBDREVWX01BSk9SCTE0OQoqKioq KioqKioqKioqKioKKioqIDc3LDgyICoqKioKLS0tIDgzLDkxIC0tLS0KICAK ICAvKiBtb2R1bGUgKi8KICBzdGF0aWMgaW50IAkJdGFwbW9kZXZlbnQJX19Q KChtb2R1bGVfdCwgaW50LCB2b2lkICopKTsKKyAjaWZkZWYgREVWRlMKKyBz dGF0aWMgdm9pZAkJdGFwY2xvbmUJX19QKCh2b2lkICosIGNoYXIgKiwgaW50 LCBkZXZfdCAqKSk7CisgI2VuZGlmCiAgCiAgLyogZGV2aWNlICovCiAgc3Rh dGljIHZvaWQJCXRhcGNyZWF0ZQlfX1AoKGRldl90KSk7CioqKioqKioqKioq KioqKgoqKiogMTMyLDE1NyAqKioqCiAgCXZvaWQJCSpkYXRhOwogIHsKICAJ c3RhdGljIGludAkJIGF0dGFjaGVkID0gMDsKISAJc3RydWN0IGlmbmV0CQkq aWZwID0gTlVMTDsKISAJaW50CQkJIHVuaXQsIHM7CiAgCiAgCXN3aXRjaCAo dHlwZSkgewogIAljYXNlIE1PRF9MT0FEOgogIAkJaWYgKGF0dGFjaGVkKQog IAkJCXJldHVybiAoRUVYSVNUKTsKISAKICAJCWNkZXZzd19hZGQoJnRhcF9j ZGV2c3cpOwogIAkJYXR0YWNoZWQgPSAxOwogIAlicmVhazsKICAKISAJY2Fz ZSBNT0RfVU5MT0FEOgogIAkJaWYgKHRhcHJlZmNudCA+IDApCiAgCQkJcmV0 dXJuIChFQlVTWSk7CiAgCiAgCQljZGV2c3dfcmVtb3ZlKCZ0YXBfY2RldnN3 KTsKICAKLSAJCXVuaXQgPSAwOwotIAkJd2hpbGUgKHVuaXQgPD0gdGFwbGFz dHVuaXQpIHsKICAJCQlzID0gc3BsaW1wKCk7CiAgCQkJVEFJTFFfRk9SRUFD SChpZnAsICZpZm5ldCwgaWZfbGluaykKICAJCQkJaWYgKChzdHJjbXAoaWZw LT5pZl9uYW1lLCBUQVApID09IDApIHx8Ci0tLSAxNDEsMTc4IC0tLS0KICAJ dm9pZAkJKmRhdGE7CiAgewogIAlzdGF0aWMgaW50CQkgYXR0YWNoZWQgPSAw OwohICNpZmRlZiBERVZGUwohIAlzdGF0aWMgZXZlbnRoYW5kbGVyX3RhZwkg ZWhfdGFnOwohICNlbmRpZgogIAogIAlzd2l0Y2ggKHR5cGUpIHsKICAJY2Fz ZSBNT0RfTE9BRDoKICAJCWlmIChhdHRhY2hlZCkKICAJCQlyZXR1cm4gKEVF WElTVCk7CiEgI2lmZGVmIERFVkZTCiEgCQllaF90YWcgPSBFVkVOVEhBTkRM RVJfUkVHSVNURVIoZGV2ZnNfY2xvbmUsIHRhcGNsb25lLCAwLCAxMDAwKTsK ISAjZWxzZQogIAkJY2RldnN3X2FkZCgmdGFwX2NkZXZzdyk7CisgI2VuZGlm CiAgCQlhdHRhY2hlZCA9IDE7CiAgCWJyZWFrOwogIAohIAljYXNlIE1PRF9V TkxPQUQ6IHsKISAJCWludAl1bml0OwohIAogIAkJaWYgKHRhcHJlZmNudCA+ IDApCiAgCQkJcmV0dXJuIChFQlVTWSk7CiAgCisgI2lmZGVmIERFVkZTCisg CQlFVkVOVEhBTkRMRVJfREVSRUdJU1RFUihkZXZmc19jbG9zZSwgZWhfdGFn KTsKKyAjZWxzZQogIAkJY2RldnN3X3JlbW92ZSgmdGFwX2NkZXZzdyk7Cisg I2VuZGlmCisgCisgCQlmb3IgKHVuaXQgPSAwOyB1bml0IDw9IHRhcGxhc3R1 bml0OyApIHsKKyAJCQlpbnQJCSBzOworIAkJCXN0cnVjdCBpZm5ldAkqaWZw ID0gTlVMTDsKICAKICAJCQlzID0gc3BsaW1wKCk7CiAgCQkJVEFJTFFfRk9S RUFDSChpZnAsICZpZm5ldCwgaWZfbGluaykKICAJCQkJaWYgKChzdHJjbXAo aWZwLT5pZl9uYW1lLCBUQVApID09IDApIHx8CioqKioqKioqKioqKioqKgoq KiogMTc5LDE4NSAqKioqCiAgCQl9CiAgCiAgCQlhdHRhY2hlZCA9IDA7CiEg CWJyZWFrOwogIAogIAlkZWZhdWx0OgogIAkJcmV0dXJuIChFT1BOT1RTVVBQ KTsKLS0tIDIwMCwyMDcgLS0tLQogIAkJfQogIAogIAkJYXR0YWNoZWQgPSAw OwohIAkJdGFwbGFzdHVuaXQgPSAtMTsKISAJfSBicmVhazsKICAKICAJZGVm YXVsdDoKICAJCXJldHVybiAoRU9QTk9UU1VQUCk7CioqKioqKioqKioqKioq KgoqKiogMTg3LDE5MiAqKioqCi0tLSAyMDksMjQ5IC0tLS0KICAKICAJcmV0 dXJuICgwKTsKICB9IC8qIHRhcG1vZGV2ZW50ICovCisgCisgCisgI2lmZGVm IERFVkZTCisgLyoKKyAgKiB0YXBjbG9uZSAtIERFVkZTIGhhbmRsZXIKKyAg KgorICAqIHdlIG5lZWQgdG8gc3VwcG9ydCB0d28ga2luZCBvZiBkZXZpY2Vz IHRhcCBhbmQgdm1uZXQKKyAgKi8KKyBzdGF0aWMgdm9pZAorIHRhcGNsb25l KGFyZywgbmFtZSwgbmFtZWxlbiwgZGV2KQorIAl2b2lkCSphcmc7CisgCWNo YXIJKm5hbWU7CisgCWludAkgbmFtZWxlbjsKKyAJZGV2X3QJKmRldjsKKyB7 CisgCWludAkgdW5pdCwgbWlub3I7CisgCWNoYXIJKmRldmljZV9uYW1lOwor IAorIAlpZiAoKmRldiAhPSBOT0RFVikKKyAJCXJldHVybjsKKyAKKyAJZGV2 aWNlX25hbWUgPSBUQVA7CisgCWlmIChkZXZmc19zdGRjbG9uZShuYW1lLCBO VUxMLCBkZXZpY2VfbmFtZSwgJnVuaXQpICE9IDEpIHsKKyAJCWRldmljZV9u YW1lID0gVk1ORVQ7CisgCQlpZiAoZGV2ZnNfc3RkY2xvbmUobmFtZSwgTlVM TCwgZGV2aWNlX25hbWUsICZ1bml0KSAhPSAxKQorIAkJCXJldHVybjsKKyAJ CW1pbm9yID0gKHVuaXQgfCBWTU5FVF9ERVZfTUFTSyk7CisgCX0KKyAJZWxz ZQorIAkJbWlub3IgPSB1bml0OworIAorIAkqZGV2ID0gbWFrZV9kZXYoJnRh cF9jZGV2c3csIG1pbm9yLAorIAkJCVVJRF9ST09ULCBHSURfV0hFRUwsIDA2 MDAsICIlcyVkIiwgZGV2aWNlX25hbWUsIHVuaXQpOworIH0gLyogdGFwY2xv bmUgKi8KKyAjZW5kaWYKICAKICAKICAvKgo= --0-1957747793-967164933=:17404-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 18: 5:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by hub.freebsd.org (Postfix) with ESMTP id A389837B424 for ; Thu, 24 Aug 2000 18:05:28 -0700 (PDT) Received: from waterblue.imgsrc.co.jp (localhost [127.0.0.1]) by waterblue.imgsrc.co.jp (8.11.0/8.11.0) with ESMTP id e7P15Tb38556 for ; Fri, 25 Aug 2000 10:05:30 +0900 (JST) Date: Fri, 25 Aug 2000 10:05:29 +0900 Message-ID: <7mk8d68812.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: freebsd-current@FreeBSD.ORG Subject: Re: make buildworld broken in usr.bin/systat In-Reply-To: In your message of "24 Aug 2000 23:23:30 GMT" <20000825082317V.yosimoto@daemon.kek.jp> References: <20000825082317V.yosimoto@daemon.kek.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 10) (Capitol Reef) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have same problem with today's -current. At 24 Aug 2000 23:23:30 GMT, Shin-ichi YOSHIMOTO wrote: > make buildworld failed this morning. > Error messages are as follows: > > ===> usr.bin/systat > > [snip] > > cc -O -pipe -I/usr/src/usr.bin/systat/../../sys -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/systat/swap.c > In file included from /usr/src/usr.bin/systat/swap.c:47: > /usr/src/usr.bin/systat/../../sys/sys/conf.h:59: field `si_atime' has incomplete type > /usr/src/usr.bin/systat/../../sys/sys/conf.h:60: field `si_ctime' has incomplete type > /usr/src/usr.bin/systat/../../sys/sys/conf.h:61: field `si_mtime' has incomplete type > *** Error code 1 > > Stop in /usr/src/usr.bin/systat. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 18:32:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail4.post.kek.jp (mail4.post.kek.jp [130.87.41.21]) by hub.freebsd.org (Postfix) with ESMTP id 69C0E37B424 for ; Thu, 24 Aug 2000 18:32:40 -0700 (PDT) Received: from mail1.post.kek.jp (root@mail1.post.kek.jp [130.87.41.18]) by mail4.post.kek.jp (8.9.3+3.2W/3.7WpostKEK:04/29/00) with ESMTP id KAA27725 for ; Fri, 25 Aug 2000 10:32:27 +0900 (JST) (envelope-from yosimoto@post.kek.jp) Received: from darwin.kek.jp (darwin.kek.jp [130.87.85.49]) by mail1.post.kek.jp (8.9.3+3.2W/3.7WpostKEK:05/01/00) with ESMTP id KAA27009 for ; Fri, 25 Aug 2000 10:32:26 +0900 (JST) (envelope-from yosimoto@post.kek.jp) Mime-Version: 1.0 X-Sender: yosimoto@pop.post.kek.jp X-Mailer: Macintosh Eudora Pro Version 4.2.2-Jb6-9.100 Message-Id: In-Reply-To: <7mk8d68812.wl@waterblue.imgsrc.co.jp> References: <20000825082317V.yosimoto@daemon.kek.jp> <7mk8d68812.wl@waterblue.imgsrc.co.jp> Date: Fri, 25 Aug 2000 10:32:25 +0900 To: freebsd-current@FreeBSD.ORG From: Shin-ichi YOSHIMOTO Subject: Re: make buildworld broken in usr.bin/systat Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:05 +0900 08/25/2000, Jun Kuriyama wrote: > I have same problem with today's -current. This problem was fixed by At 13:22 -0700 08/24/2000, Peter Wemm wrote: > peter 2000/08/24 13:22:44 PDT > > Modified files: > usr.bin/systat swap.c > Log: > Quick Fix: swap.c doesn't appear to actually need , so remove > it to try and get world building again. (sys/conf.h now depends on > sys/types.h) > > Revision Changes Path > 1.14 +1 -2 src/usr.bin/systat/swap.c Thanks peter. ---------------------------------------------------------- Shin-ichi YOSHIMOTO KEK, High Energy Accelerator Research Organization Accelerator Laboratory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 21:42:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from merc95.us.sas.com (merc95.us.sas.com [149.173.6.5]) by hub.freebsd.org (Postfix) with ESMTP id 2156937B42C for ; Thu, 24 Aug 2000 21:42:34 -0700 (PDT) Received: from merc95.us.sas.com ([127.0.0.1]) by merc95.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id RL3RBXVL; Fri, 25 Aug 2000 00:42:33 -0400 Received: from 10.28.149.26 by merc95.us.sas.com (InterScan E-Mail VirusWall NT); Fri, 25 Aug 2000 00:42:33 -0400 (Eastern Daylight Time) Received: from bb01f39.unx.sas.com (bb01f39.unx.sas.com [10.16.2.246]) by mozart.unx.sas.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id AAA06434 for ; Fri, 25 Aug 2000 00:42:32 -0400 (EDT) Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.3/8.9.1) id AAA89339 for freebsd-current@freebsd.org; Fri, 25 Aug 2000 00:42:31 -0400 (EDT) (envelope-from jwd) Date: Fri, 25 Aug 2000 00:42:31 -0400 From: John DeBoskey To: freebsd-current@freebsd.org Subject: gdb bug w/ dlopen()ed images Message-ID: <20000825004231.A89090@unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, There appears to be a problem with gdb when debugging dynamically loaded images. On 5.0-current with sources current and built as of this evenning and a 4.1-STABLE system, the following incorrect result is seen: %gdb ./testmain GNU gdb 4.18 (gdb) b main Breakpoint 1 at 0x804853f: file testmain.c, line 11. (gdb) run Starting program: /usr/home/jwd/src/ldt/./testmain Breakpoint 1, main () at testmain.c:11 11 addr = dlopen("./first", RTLD_LAZY); (gdb) n 13 if (!addr) { (gdb) n 18 fp = dlsym(addr, "first"); (gdb) n 20 (*fp)(); (gdb) s 0x280f85b7 in first () at first.c:24 24 } built with gcc version 2.95.2 19991024 (release) The same test program run under gcb on 4.0-20000313-SNAP and 4.0-STABLE systems yield the correct result: %gdb ./testmain GNU gdb 4.18 (gdb) b main Breakpoint 1 at 0x80484ff: file testmain.c, line 11. (gdb) run Starting program: /usr00/home/jwd/ldt/./testmain Breakpoint 1, main () at testmain.c:11 11 addr = dlopen("./first", RTLD_LAZY); (gdb) n 13 if (!addr) { (gdb) n 18 fp = dlsym(addr, "first"); (gdb) n 20 (*fp)(); (gdb) s first () at first.c:10 10 addr = dlopen("./second", RTLD_LAZY); built with gcc version 2.95.2 19991024 (release). In looking at the stabs information, for the working version, we find: STABS> name=first:F(0,1), type=24, desc=6, value=896 STABS> name=, type=44, desc=6, value=0 STABS> name=, type=44, desc=7, value=7 STABS> name=, type=44, desc=10, value=7 STABS> name=, type=44, desc=12, value=30 STABS> name=, type=44, desc=13, value=36 STABS> name=, type=44, desc=14, value=60 STABS> name=, type=44, desc=17, value=76 STABS> name=, type=44, desc=19, value=99 STABS> name=, type=44, desc=21, value=104 STABS> name=, type=44, desc=23, value=119 STABS> name=, type=44, desc=24, value=123 STABS> name=, type=44, desc=24, value=123 STABS> name=first:F(0,1), type=24, desc=6, value=896 and the non-working stabs: STABS> name=first:F(0,1), type=24, desc=6, value=0 STABS> name=, type=44, desc=6, value=0 STABS> name=, type=44, desc=7, value=7 STABS> name=, type=44, desc=10, value=7 STABS> name=, type=44, desc=12, value=30 STABS> name=, type=44, desc=13, value=36 STABS> name=, type=44, desc=14, value=60 STABS> name=, type=44, desc=17, value=76 STABS> name=, type=44, desc=19, value=99 STABS> name=, type=44, desc=21, value=104 STABS> name=, type=44, desc=23, value=119 STABS> name=, type=44, desc=24, value=123 STABS> name=, type=44, desc=24, value=123 STABS> name=first:F(0,1), type=24, desc=6, value=0 Note that in the non-working version, the only difference is the value of 896 vs 0. 896 should be the start address of the function. There is a possibly relative commment in section G.2 of 'The "stabs" debug format' put out by Cygnus Support: http://sources.redhat.com/cygwin/stabs.html#SEC89 It seems to imply that a value=0 field should be a linker relocated stab. The test program(s) are simple and can be found at: http://people.freebsd.org/~jwd/ldt/ I've searched through the PR database but I can't find any entries that seem related (but then I'm not a GNATS expert either). If anyone knows anything or has any ideas on this, please let me know. Thanks! John -- FreeBSD... The choice of those who know how to choose... (anon) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 23: 5:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id CA5E937B423; Thu, 24 Aug 2000 23:05:32 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id CAA67644; Fri, 25 Aug 2000 02:05:31 -0400 (EDT) Date: Fri, 25 Aug 2000 02:05:30 -0400 (EDT) From: "Matthew N. Dodd" To: Visigoth Cc: Mike Smith , current@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 24 Aug 2000, Visigoth wrote: > dpt0: port 0xdc60-0xdc7f irq 16 at > device 8.0 on pci 2 > > even though bios asigned it irq 9... hmmm.... Is this an SMP box or a UP box in APIC mode or something strange? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Aug 24 23:41: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 26B9237B42C for ; Thu, 24 Aug 2000 23:40:47 -0700 (PDT) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id NAA89490; Fri, 25 Aug 2000 13:37:03 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Fri, 25 Aug 2000 13:37:02 +0700 (NSS) From: Max Khon To: John DeBoskey Cc: freebsd-current@FreeBSD.ORG Subject: Re: gdb bug w/ dlopen()ed images In-Reply-To: <20000825004231.A89090@unx.sas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Fri, 25 Aug 2000, John DeBoskey wrote: > There appears to be a problem with gdb when debugging > dynamically loaded images. On 5.0-current with > sources current and built as of this evenning and a > 4.1-STABLE system, the following incorrect result is seen: PR/20373 Solution: apply patch 1.8->1.9 for bfd/elf32-i386.c from binutils source tree (their cvsweb is somewhere at http://sources.redhat.com/binutils/) to src/contrib/binutils/bfd/elf32-i386.c and rebuild src/gnu/usr.bin/binutils/libbfd and src/gnu/usr.bin/binutils/ld Unfortunately for some reason I cannot post follow-up for this PR. David O'Brien has all the information. /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 1:52:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id D2B4537B422 for ; Fri, 25 Aug 2000 01:52:31 -0700 (PDT) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 13SFDw-0004W5-00; Fri, 25 Aug 2000 10:52:28 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id KAA27111; Fri, 25 Aug 2000 10:52:25 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 27084; Fri Aug 25 10:52:01 2000 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.16 #1) id 13SFDV-0001so-00; Fri, 25 Aug 2000 10:52:01 +0200 To: Jos Backus Cc: current@freebsd.org Subject: Re: devfs, moused and rc.devfs position in rc In-reply-to: Your message of "Thu, 24 Aug 2000 10:29:03 MST." <20000824102903.A2492@traitor.artemis.com> Date: Fri, 25 Aug 2000 10:52:01 +0200 Message-ID: <7241.967193521@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 24 Aug 2000 10:29:03 MST, Jos Backus wrote: > In /etc/rc, rc.i386 is invoked before rc.devfs. This causes moused to fail to > start for those people who use a link from /dev/ to /dev/mouse. The > fix seems to be to switch the order of invocation: Your problem raises another interesting problem. Takea look at the bottom of rc.diskless2, where /dev is mounted in mfs. That operation needs to be conditionalized on the presence of DEFVS. What we really need is for someone who runs a diskless environment to try placing the call to rc.devfs immediately before the call to rc.diskless1 and to apply something like the following patch to rc.diskless2: Index: rc.diskless2 =================================================================== RCS file: /home/ncvs/src/etc/rc.diskless2,v retrieving revision 1.6 diff -u -d -r1.6 rc.diskless2 --- rc.diskless2 2000/04/27 08:43:48 1.6 +++ rc.diskless2 2000/08/25 08:51:20 @@ -34,6 +34,8 @@ fi # extract a list of device entries, then copy them to a writable partition -(cd /; find -x dev | cpio -o -H newc) > /tmp/dev.tmp -mount_mfs -s 4096 -i 512 -T qp120at dummy /dev -(cd /; cpio -i -H newc -d < /tmp/dev.tmp) +if ! mount | grep -q 'devfs on /dev'; then + (cd /; find -x dev | cpio -o -H newc) > /tmp/dev.tmp + mount_mfs -s 4096 -i 512 -T qp120at dummy /dev + (cd /; cpio -i -H newc -d < /tmp/dev.tmp) +fi Feedback from such a person would be most useful, I think. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 2:45:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from ockle.dev.nanoteq.co.za (ockle.dev.nanoteq.co.za [196.7.114.28]) by hub.freebsd.org (Postfix) with ESMTP id BD7AB37B423; Fri, 25 Aug 2000 02:45:03 -0700 (PDT) Received: (from johan@localhost) by ockle.dev.nanoteq.co.za (8.9.3/8.9.3) id LAA97652; Fri, 25 Aug 2000 11:56:12 +0200 (SAST) (envelope-from johan) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 25 Aug 2000 11:56:12 +0200 (SAST) Organization: Nanoteq From: Johan Kruger To: FreeBSD Current , freebsd-hackers@FreeBSD.ORG Subject: perlcc in current - xs_init and boot_DynaLoader Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If i do a perlcc test.pl i get the folllowing , in CURRENT ? Must i define something beforehand, or is it broken ? -Wl,-E -lperl -lm -L/usr/libdata/perl/5.6.0/mach/CORE -lperl -lm -lc -lcrypt /usr/libdata/perl/5.6.0/mach/auto/IO/IO.so /usr/libdata/perl/5.6.0/mach/auto/Fcntl/Fcntl.so /tmp/ccJ97508.o: In function `xs_init': /tmp/ccJ97508.o(.text+0x33a4): undefined reference to `boot_DynaLoader' ERROR: In compiling code for test.pl.c ! ---------------------------------- Unix Software Developer/Engineer E-Mail: Johan Kruger Date: 25-Aug-00 Time: 11:53:40 All good things come to those who ... runs FreeBSD ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 3: 9:24 2000 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228]) by hub.freebsd.org (Postfix) with ESMTP id 8C58437B449; Fri, 25 Aug 2000 03:09:19 -0700 (PDT) Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241]) by mailgate.originative.co.uk (Postfix) with ESMTP id EB0CD1D140; Fri, 25 Aug 2000 11:09:13 +0100 (BST) Message-ID: <39A645C9.3A68B0CD@originative.co.uk> Date: Fri, 25 Aug 2000 11:09:13 +0100 From: Paul Richards Organization: Originative Solutions Ltd X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Ovens Cc: current@FreeBSD.ORG Subject: Re: Request for review/comments - new option for uname(1) References: <20000809005929.K250@parish> <20000809143344.L29987@argon.gryphonsoft.com> <20000810003858.D251@parish> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Ovens wrote: > > On Wed, Aug 09, 2000 at 02:33:44PM -0400, Will Andrews wrote: > > On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote: > > > Is there any reason why this is unacceptable and could not be committed? > > > > Because it can be done with an awk/sed script? > > > > I'll forget about it then. I only did it because I was fed up with > manually editing the output so it was tidier in e-mails and PRs. Like > I said, it's not important. I think this might be one of those rare cases where adding another option is more efficient than using tools. Running awk/sed to correct the formatting is overkill when a few printfs in the code would do it much more efficiently. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 3:22:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (blizzard.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id C4A9D37B43F; Fri, 25 Aug 2000 03:22:09 -0700 (PDT) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.106]) by blizzard.sabbo.net (8.9.1/8.9.3) with ESMTP id NAA15802; Fri, 25 Aug 2000 13:21:59 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.9.3/8.9.3) with ESMTP id NAA25160; Fri, 25 Aug 2000 13:22:00 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <39A648C6.CDFD7E0@FreeBSD.org> Date: Fri, 25 Aug 2000 13:21:59 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Paul Richards Cc: Mark Ovens , current@FreeBSD.org Subject: Re: Request for review/comments - new option for uname(1) References: <20000809005929.K250@parish> <20000809143344.L29987@argon.gryphonsoft.com> <20000810003858.D251@parish> <39A645C9.3A68B0CD@originative.co.uk> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Paul Richards wrote: > Mark Ovens wrote: > > > > On Wed, Aug 09, 2000 at 02:33:44PM -0400, Will Andrews wrote: > > > On Wed, Aug 09, 2000 at 12:59:29AM +0100, Mark Ovens wrote: > > > > Is there any reason why this is unacceptable and could not be committed? > > > > > > Because it can be done with an awk/sed script? > > > > > > > I'll forget about it then. I only did it because I was fed up with > > manually editing the output so it was tidier in e-mails and PRs. Like > > I said, it's not important. > > I think this might be one of those rare cases where adding another > option is more efficient than using tools. Running awk/sed to correct > the formatting is overkill when a few printfs in the code would do it > much more efficiently. Introduction of incompatible among others BSD/*nix variants changes in commonly used tools is evil from any point of view (IMO). -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 6:32:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from mint.freemail.ne.jp (mint.freemail.ne.jp [210.235.164.35]) by hub.freebsd.org (Postfix) with SMTP id CFDDB37B42C for ; Fri, 25 Aug 2000 06:32:05 -0700 (PDT) Received: (qmail 7745 invoked by alias); 25 Aug 2000 20:44:20 +0900 Received: (qmail 6741 invoked from network); 25 Aug 2000 20:44:13 +0900 Received: from unknown (HELO c10) (211.11.215.60) by mint.freemail.ne.jp with SMTP; 25 Aug 2000 20:44:13 +0900 Message-ID: <008901c00e89$f638cd40$0c00a8c0@c10> From: "Cosmo21" To: Subject: =?iso-2022-jp?B?GyRCRikyYTUhRz1JVSVHJTglKyVhMSMkNzsjJGolLSVDJUhITkdkGyhC?= Date: Fri, 25 Aug 2000 20:13:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG $B%Y%k%H$N%P%C%/%k$K;E9~$s$@%l%s%:$+$iK\BN!J3s$J$I!K$K(B $BEEGH$rHt$P$9J}<0$G$9!#=D(B1440$B!_2#(B960$B%T%/%;%k!##A#4MQ;f(B $B=D$G>/$7:81&$KM>Gr$reH>?H!&2?H$NA*Br$r85$K$"$i$+$8$a%l%s(B $B%:3QEY!"%:!<%`N($rD4@a8GDj!#$"$H$O%P%C%/%k$r?($k$h$&$K(B $B%7%c%C%?!]J*$r#2!?#3$NHO0O(B $B$K<}$a$k$3$H$,$G$-$^$9!#5^B.%*!<%H%U%)!<%+%9$G$9$N$G!"(B $BN)$A;_$^$C$?Aj5CN$/$@$5$$!#(B $B5-O?$O%9%^!<%H%a%G%#%"!J#8(BMB$BE:IU!"#2#0Kg5-O?2D!K$G!"K\BN$N(B $B#2%$%s%A1U>=!"%F%l%S@\B3$G8+$i$l$k$[$+!"#1K|1_DxEY$N%U%i%C(B $B%7%e%Q%9$+%9%^!<%H%a%G%#%"%j!<%@$rGc$($P%Q%=%3%s$K$b3Q%m!<%^;z!J=g=x$OF|K\8l<0$G2D!K$G$*CN$i$;(B $B4j$$$^$9!#3NG'8eLs=54V$GH/Aw$7$^$9!#H/AwF|;XDj!":-Jq$=$NB>4uK>(B $B$O8=6b=qN1$KJ;5-$7$F$/$@$5$$!#(B $B")(B112$B!!El5~!!>.@P@nM9JX6I;_$a!!%3%9%b#2#1(B $BDy$a@Z$jD62a8e$N$*?=$79~$_!"$*Ld$$9g$o$;$=$NB>$O0l@Z1~$8$+$M$^$9!#(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 6:48: 1 2000 Delivered-To: freebsd-current@freebsd.org Received: from daemon.org (116-BARC-X124.libre.retevision.es [62.83.95.116]) by hub.freebsd.org (Postfix) with ESMTP id 03B0937B422 for ; Fri, 25 Aug 2000 06:47:53 -0700 (PDT) Received: (from koji@localhost) by daemon.org (8.11.0/8.11.0) id e7PDnQN00305 for current@freebsd.org; Fri, 25 Aug 2000 15:49:26 +0200 (CEST) (envelope-from koji) Date: Fri, 25 Aug 2000 15:49:25 +0200 From: undergra To: current@freebsd.org Subject: BitchX-1.0c16 broken Message-ID: <20000825154925.A294@daemon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi.. i try to compile BitchX-1.0c16 on my FreeBSD-current 5.0. The same version works on my old FreeBSD 4.1, but when i try to compile on 5.0... ../include/struct.h:743: `INPUT_BUFFER_SIZE' undeclared here (not in a function) ../include/struct.h:743: size of array `input_buffer' has non-integer type ../include/struct.h:759: `INPUT_BUFFER_SIZE' undeclared here (not in a function) ../include/struct.h:759: size of array `saved_input_buffer' has non-integer type ../include/struct.h:1025: `REFNUM_MAX' undeclared here (not in a function) ../include/struct.h:1025: size of array `ref' has non-integer type gmake[1]: *** [alias.o] Error 1 gmake[1]: Saliendo directorio `/usr/ports/irc/bitchx/work/BitchX/source' gmake: *** [BitchX] Error 2 *** Error code 2 Stop in /usr/ports/irc/bitchx. *** Error code 1 Stop in /usr/ports/irc/bitchx. *** Error code 1 Stop in /usr/ports/irc/bitchx. *** Error code 1 Stop in /usr/ports/irc/bitchx. anyone help me please? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 6:48:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from indigo.dreamfire.net (indigo.dreamfire.net [207.113.154.29]) by hub.freebsd.org (Postfix) with ESMTP id F3DE737B422 for ; Fri, 25 Aug 2000 06:48:34 -0700 (PDT) Received: from valiant.dreamfire.net (valiant.dreamfire.net [24.11.227.21]) by indigo.dreamfire.net (Postfix) with ESMTP id A19359452 for ; Fri, 25 Aug 2000 06:48:34 -0700 (PDT) Received: by valiant.dreamfire.net (Postfix, from userid 1000) id 611F2E8E1A; Fri, 25 Aug 2000 06:48:34 -0700 (PDT) Date: Fri, 25 Aug 2000 06:48:34 -0700 From: Sean-Paul Rees To: current@freebsd.org Subject: Linux Netscape Message-ID: <20000825064834.A44798@seanrees.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Under my 5.0-C setup here, the Linux netscape takes AGES to load (>5min) and is so unresponsive, I have to kill it. I experienced a similar problem with StarOffice 5.2, where performance was just dog slow. Is the Linuxulator broken? -- Cheers, Sean Sean-Paul Rees (sean@seanrees.com) Web: http://www.seanrees.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 7:44:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from shell.telemere.net (shell.telemere.net [63.224.9.3]) by hub.freebsd.org (Postfix) with ESMTP id 19FC437B424; Fri, 25 Aug 2000 07:44:11 -0700 (PDT) Received: from localhost (visigoth@localhost) by shell.telemere.net (8.9.3/8.9.3) with ESMTP id JAA12893; Fri, 25 Aug 2000 09:46:36 -0500 (CDT) (envelope-from visigoth@telemere.net) X-Authentication-Warning: shell.telemere.net: visigoth owned process doing -bs Date: Fri, 25 Aug 2000 09:46:32 -0500 (CDT) From: Damieon Stark To: "Matthew N. Dodd" Cc: Mike Smith , current@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 25 Aug 2000, Matthew N. Dodd wrote: > Is this an SMP box or a UP box in APIC mode or something strange? As of right now all of the machines that I have tried it on are SMP machines which prebviously worked just fine with them in. It would be super easy for me to test it on a normal UP box if you would like. Even boot disks don't work, so testing is easy.... ;) But I was serious about being able to make a box remotly available if that would help. Thanks. Visigoth Damieon Stark Sr. Unix Systems Administrator visigoth@telemere.net PGP Public Key: www.telemere.net/~visigoth/visigoth.asc ____________________________________________________________________________ | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQA/AwUBOaZ4vDnmC/+RTnGeEQLDugCgk8yj3kGi2xzwZmGlB3E/05gLRXkAniJ6 W3gVOvu+cibAtbe5bGMkIXUp =iMXk -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 13:24:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 8499337B423; Fri, 25 Aug 2000 13:24:02 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13SQ17-0007ZL-00; Fri, 25 Aug 2000 22:23:57 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7PKOep20703; Fri, 25 Aug 2000 22:24:40 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008252024.e7PKOep20703@grimreaper.grondar.za> To: Johan Kruger Cc: FreeBSD Current , freebsd-hackers@FreeBSD.ORG Subject: Re: perlcc in current - xs_init and boot_DynaLoader References: In-Reply-To: ; from Johan Kruger "Fri, 25 Aug 2000 11:56:12 +0200." Date: Fri, 25 Aug 2000 22:24:40 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If i do a perlcc test.pl i get the folllowing , in CURRENT ? > Must i define something beforehand, or is it broken ? I'll take a look... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 15:39:58 2000 Delivered-To: freebsd-current@freebsd.org Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (Postfix) with ESMTP id 2A10537B424 for ; Fri, 25 Aug 2000 15:39:57 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.10.0/8.10.0) id e7PMduW13232 for ; Fri, 25 Aug 2000 15:39:56 -0700 (PDT) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma013227; Fri, 25 Aug 2000 15:39:50 -0700 Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id PAA56994 for freebsd-current@freebsd.org; Fri, 25 Aug 2000 15:39:50 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008252239.PAA56994@bubba.whistle.com> Subject: kernel hash table implementation? To: freebsd-current@freebsd.org Date: Fri, 25 Aug 2000 15:39:50 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there a generic hash table implementation in the kernel somewhere? If not, is there any interest in creating one? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 17:25:25 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp.bsdhome.com (unknown [24.25.2.13]) by hub.freebsd.org (Postfix) with ESMTP id 5E25D37B43E for ; Fri, 25 Aug 2000 17:25:21 -0700 (PDT) Received: from vger.bsdhome.com (vger [192.168.220.2]) by smtp.bsdhome.com (8.9.3/8.9.3) with ESMTP id UAA20958 for ; Fri, 25 Aug 2000 20:25:20 -0400 (EDT) (envelope-from bsd@bsdhome.com) Received: from localhost (bsd@localhost) by vger.bsdhome.com (8.9.3/8.9.3) with ESMTP id UAA25601 for ; Fri, 25 Aug 2000 20:25:19 -0400 (EDT) (envelope-from bsd@vger.bsdhome.com) Date: Fri, 25 Aug 2000 20:23:59 -0400 (EDT) From: Brian Dean To: freebsd-current@FreeBSD.ORG Subject: Re: Review requested for i386 debug register helper functions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 24 Aug 2000, Brian Dean wrote: > If you have the time, I would very much appreciate any reviews on a > couple of helper functions that I've put together for manipulating the > i386 debug registers: > > http://people.freebsd.org/~bsd/i386watch/ Just a note to reviewers, I've simplified the i386_set_watch() function a bit as of Aug 25 @ 5:15 PDT. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 17:43:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from r00t.besiex.org (r00t.besiex.org [208.222.215.145]) by hub.freebsd.org (Postfix) with ESMTP id D6F9437B42C; Fri, 25 Aug 2000 17:43:09 -0700 (PDT) Received: (from adam@localhost) by r00t.besiex.org (8.8.7/8.8.7) id UAA21527; Fri, 25 Aug 2000 20:43:04 -0400 Date: Fri, 25 Aug 2000 20:43:04 -0400 Message-Id: <200008260043.UAA21527@r00t.besiex.org> From: Adam Back To: current@freebsd.org Cc: kris@freebsd.org Cc: jeroen@vangelderen.org Cc: mark@grondar.za Subject: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [try again this foobared the first time -- apologies for duplicates] [If this bounces because I am not a list member, could I trouble one of you to forward it to the list? -- Thanks] Hi all We've been implementing yarrow at zeroknowledge also. I just read through the freebsed-current archives searching for "yarrow", and I share some of the concerns raised by Kris Kennaway: Kris Kennaway > [...] > > I'm not bothered about this. My point is that, by design, Yarrow is not > suitable as a replacement for /dev/random (/dev/urandom, yes). and Jeroen van Gelderen : > [...] At a more fundamental level we will need to answer the > question: "Do we need to preserve the current /dev/random semantics > or can we decide to change 'em? [1]". And how will this affect our > applications *in practice*. > > So let's concentrate this discussion on the practical issues > and explain why you think backing /dev/random with Yarrow and > changing the semantics is justifyable or even a good thing. and several others I saw. I've been talking with John Kelsey (one of the Yarrow authors) about changing yarrow to support /dev/random for the very same reason (I had not read this discussion -- but the same objection independently occured to me in connection with linux which has the same Ted T'so /dev/random code). John Kelsey has also been working on a Yarrow-160-A which simplifies some of the design. I'm hoping to persuade the yarrow designers of the importance of supporting /dev/random semantics for the unix community acceptance. John Kelsey and I had some discussions along the lines of feeding /dev/random output into yarrow, which I notice someone on here considered. (Sorry I forgot who said that). Perhaps I could encourage some of you to subscribe to the yarrow list we have setup at yarrow@zeroknowledge.com (send mail to yarrow-request@zeroknowldege.com). Peter Gutmann is subscribed (I see some references to his paper), and I expect some of the yarrow authors will when they get back from Crypto. It might help the cause of preserving /dev/random semantics, if those of you participating in this discussion back in July chipped in to support my similar predictions about community acceptance on this basis -- OS implementors are after all the target audience for yarrow. There are several implementors on board -- RST have an implementation tracking the changes in yarrow-160-A they plan to release soon, we have the 160 implementation I wrote (current tar ball at: http://opensource.zeroknowledge.com). I must say I think it is important with cryptographic primitives to have test vectors, so that you know your implementation is correct and conforms to the specification. It's very difficult to notice errors in a PRNG -- the output still looks random. So the aim of the yarrow list is to collectively work on deriving test vectors. I had a quick look at Mark's yarrow implementation and there are a things which I'd caution about: - the hash function constructed from using Blowfish in CBC mode you -- have to be careful how you use block ciphers to construct hash functions -- they have quite different properties. For example collision resistance is not generally important for a block cipher, but is all-important for a hash function - yarrow design specifically calls for a hash function and a block cipher -- you may easily be violating some of it's security assumptions by plugging in the above. - blowfish has an expensive key-schedule, so depending on your Pg value it might be faster to use 3DES as specified by yarrow-160. - a minor coding question: it doens't look to me like the IV is initialised -- is there something assuring that the ivec local variable will hold zeros -- otherwise your RNG may have non repeatable output - making testing difficult. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 18:47:42 2000 Delivered-To: freebsd-current@freebsd.org Received: from r00t.besiex.org (r00t.besiex.org [208.222.215.145]) by hub.freebsd.org (Postfix) with ESMTP id 015A137B423 for ; Fri, 25 Aug 2000 18:47:39 -0700 (PDT) Received: (from adam@localhost) by r00t.besiex.org (8.8.7/8.8.7) id VAA22230; Fri, 25 Aug 2000 21:47:35 -0400 Date: Fri, 25 Aug 2000 21:47:35 -0400 Message-Id: <200008260147.VAA22230@r00t.besiex.org> From: adam@cypherspace.org To: current@freebsd.org Subject: MACs vs Hash fns. and collision resistance Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I see my post made it] To expand briefly on my comment about collision resistance > - the hash function constructed from using Blowfish in CBC mode you -- > have to be careful how you use block ciphers to construct hash > functions -- they have quite different properties. For example > collision resistance is not generally important for a block cipher, > but is all-important for a hash function -- I haven't looked in detail at what the code does, but I think I can guess from the description: CBC mode means you start with y_0 = IV, and compute ciphertext y_i = E_k( x_i ^ y_{i-1} ). In this case I see y_0 is set to zero (or perhaps left undefined). (^ = xor) A CBC-MAC is where you use IV = 0, a MAC key k and you output the last block of the MAC. However you can't use a raw CBC-MAC as a variable length MAC, without using one of the padding options. The collision resistance property of a hash function (which SHA1 and MD5 exhibit) is that it should be computationally expensive for an attacker to find h( x ) == h( y ) st x != y. The birthday attack is when you try to find any x and y hashing to the same value, and a targetted collsiion is when you have a given x and you want to find a y with the same hash value. Your hash function is optimally collision resistant if you can't find targetted collisions any more cheaply than 2^|output_size-1| average tries, and can't find birthday collision in less than average 2^|output_size/2-1| tries. So if we take the 256 bit CBC hash with an unknown key k, lets say with input string x_1 || x_2 then the following computes a collision: h1 = h( x1 ) h2 = h( x1 || x2 ) = h( x1 || x2 || h2 ^ h1 ^ x2 ) and you don't even need to know the key K to find this collision. So ok that's using different length messages, but if you have the key you can construct more arbitrary collisions. Yarrow calls for a (keyless) hash function rather than a MAC, so using a MAC with a key related to inputs or related to K from yarrow may invalidate some assumptions they are making. This is not to say what you have isn't safe -- I haven't really looked at it closely to see if this is a problem in practice -- but I just wanted to point out it's not a good idea to just swap out constructs without being sure the designers weren't relying on a property you have removed. And also, even if it turns out to be secure, once it's finished you can't in fairness to the authors call it yarrow, so you lose the ability to say "freeBSD uses yarrow", the closest you could come would be to say it uses a "variant of yarrow with a blowfish-CBC-MAC instead of a hash function" and then justify all of the assumptions and reasons why you think it's still secure and does't violate any assumptions the yarrow authors were making that matter to it's security. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 19:11:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id 1599F37B423 for ; Fri, 25 Aug 2000 19:11:41 -0700 (PDT) Received: from barracuda (barracuda [208.11.247.5]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05376; Fri, 25 Aug 2000 22:11:40 -0400 (EDT) Date: Fri, 25 Aug 2000 22:11:40 -0400 (EDT) From: Thomas Stromberg X-Sender: tstromberg@barracuda.aquarium.rtci.com To: freebsd-current@freebsd.org Cc: sos@freebsd.dk Subject: IDE RAID (HPT-370/Abit KT7-RAID) install questions.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (excuse complete ignorance as far as IDE RAID below) For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. So after a long day of hacking at getting Cyclone Interchange to run under FreeBSD, I decided to go for the install today w/ 20000820-CURRENT. I set up the RAID BIOS to stripe together both of the drives, each as a master on their own channel. The controller shows up in the FreeBSD bootup, as well as the drives with UDMA100, but.. While "lsdev" from the boot floppy shows one drive, in FreeBSD & fdisk they show up as two 15G drives (ad4s1 & ad6s1) rather then a 30G concatanated one. Am I missing something here? I've never done IDE RAID, let alone on-board RAID. Are they striped, but show up as seperate due to the lack of emulation? I went ahead and installed FreeBSD as a 6G partition.. and everything looked good (and fast!), but when I rebooted, BootEasy saw the FreeBSD bootblock, but it compained that it couldn't find any ufs partition. However, "lsdev" from the floppies saw a ufs and swap partition when checked. Do I have to install / on a non-RAIDed drive so that the boot loader has a chance? In any case, much thanks goes to Soren for adding support for the HPT-370 (and for the ATA drivers in general). I don't owe him just a beer, but probably a keg or two for all the IDE boxes that I've installed FreeBSD on :) ------------------------------------------------------------------------ thomas r. stromberg tstromberg@rtci.com senior systems administrator http://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 20:43:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id A694F37B43C for ; Fri, 25 Aug 2000 20:43:08 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 7949228AB5; Sat, 26 Aug 2000 10:43:01 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 710A928AB4; Sat, 26 Aug 2000 10:43:01 +0700 (ALMST) Date: Sat, 26 Aug 2000 10:43:01 +0700 (ALMST) From: Boris Popov To: Archie Cobbs Cc: freebsd-current@freebsd.org Subject: Re: kernel hash table implementation? In-Reply-To: <200008252239.PAA56994@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 25 Aug 2000, Archie Cobbs wrote: > Is there a generic hash table implementation in the kernel somewhere? Yes, see kern/kern_subr.c for hashinit() function. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Aug 25 23:32:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 1D98237B422; Fri, 25 Aug 2000 23:32:00 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13SZVM-000FDv-00; Sat, 26 Aug 2000 08:31:49 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7Q6Wep24461; Sat, 26 Aug 2000 08:32:40 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008260632.e7Q6Wep24461@grimreaper.grondar.za> To: Adam Back Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org, mark@grondar.za Subject: Re: yarrow & /dev/random References: <200008260037.UAA27804@caesar.zks.net> In-Reply-To: <200008260037.UAA27804@caesar.zks.net> ; from Adam Back "Fri, 25 Aug 2000 20:37:06 -0400." Date: Sat, 26 Aug 2000 08:32:40 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We've been implementing yarrow at zeroknowledge also. I just read > through the freebsed-current archives searching for "yarrow", and I > share some of the concerns raised by Kris Kennaway: OK... > I've been talking with John Kelsey (one of the Yarrow authors) about > changing yarrow to support /dev/random for the very same reason (I had > not read this discussion -- but the same objection independently > occured to me in connection with linux which has the same Ted T'so > /dev/random code). Great! > John Kelsey has also been working on a Yarrow-160-A which simplifies > some of the design. I'm hoping to persuade the yarrow designers of > the importance of supporting /dev/random semantics for the unix > community acceptance. John Kelsey and I had some discussions along > the lines of feeding /dev/random output into yarrow, which I notice > someone on here considered. (Sorry I forgot who said that). By "/dev/random semantics", are you referring to a blocking model that "counts" entropy and blocks when it beieves it is "empty"? > Perhaps I could encourage some of you to subscribe to the yarrow list > we have setup at yarrow@zeroknowledge.com (send mail to > yarrow-request@zeroknowldege.com). Thanks! Doing it now! > some references to his paper), and I expect some of the yarrow authors > will when they get back from Crypto. It might help the cause of > preserving /dev/random semantics, if those of you participating in > this discussion back in July chipped in to support my similar > predictions about community acceptance on this basis -- OS > implementors are after all the target audience for yarrow. I am against the blocking model, as I believe that it goes against what Yarrow is trying to do. If the Yarrow authors argued otherwise, I'd listen. > There are several implementors on board -- RST have an implementation > tracking the changes in yarrow-160-A they plan to release soon, we > have the 160 implementation I wrote (current tar ball at: > http://opensource.zeroknowledge.com). Great! > I must say I think it is important with cryptographic primitives to > have test vectors, so that you know your implementation is correct and > conforms to the specification. It's very difficult to notice errors > in a PRNG -- the output still looks random. So the aim of the yarrow > list is to collectively work on deriving test vectors. I'd be _most_ interested in this. > I had a quick look at Mark's yarrow implementation and there are a > things which I'd caution about: > > - the hash function constructed from using Blowfish in CBC mode you -- > have to be careful how you use block ciphers to construct hash > functions -- they have quite different properties. For example > collision resistance is not generally important for a block cipher, > but is all-important for a hash function Gotcha. I aim to improve my hash function. I've broken it out into a separate function already. > - yarrow design specifically calls for a hash functoin and a block > cipher -- you may easily be violating some of it's security > assumptions by plugging in the above. If I construct a specific hash function, is this still a problem? > - blowfish has an expensive key-schedule, so depending on your Pg > value it might be faster to use 3DES as specified by yarrow-160. Hmm. I may just do this once I get onto the performance-tweaking part of the project. > - a minor coding question: it doens't look to me like the IV is > initialised -- is there something assuring that the ivec local > variable will hold zeros -- otherwise your RNG may have non > repeatable output -- which is OK in use but not for testing. I'll fix that. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 0:10:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id E774637B424 for ; Sat, 26 Aug 2000 00:10:26 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id AAA00625; Sat, 26 Aug 2000 00:24:04 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200008260724.AAA00625@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Thomas Stromberg Cc: freebsd-current@freebsd.org, sos@freebsd.dk Subject: Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions.. In-reply-to: Your message of "Fri, 25 Aug 2000 22:11:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Aug 2000 00:24:04 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is not an "IDE RAID" controller. It's an IDE controller with some lame "RAID" software in the BIOS. We don't support this. > (excuse complete ignorance as far as IDE RAID below) > > For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID > suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard > Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. > > So after a long day of hacking at getting Cyclone Interchange to run under > FreeBSD, I decided to go for the install today w/ > 20000820-CURRENT. I set up the RAID BIOS to stripe together both of > the drives, each as a master on their own channel. The controller shows up > in the FreeBSD bootup, as well as the drives with UDMA100, but.. > > While "lsdev" from the boot floppy shows one drive, in FreeBSD & fdisk > they show up as two 15G drives (ad4s1 & ad6s1) rather then a 30G > concatanated one. > > Am I missing something here? I've never done IDE RAID, let alone on-board > RAID. Are they striped, but show up as seperate due to the lack of > emulation? > > I went ahead and installed FreeBSD as a 6G partition.. and everything > looked good (and fast!), but when I rebooted, BootEasy saw the FreeBSD > bootblock, but it compained that it couldn't find any ufs > partition. However, "lsdev" from the floppies saw a ufs and swap > partition when checked. > > Do I have to install / on a non-RAIDed drive so that the boot loader has a > chance? > > In any case, much thanks goes to Soren for adding support for the > HPT-370 (and for the ATA drivers in general). I don't owe him just a > beer, but probably a keg or two for all the IDE boxes that I've installed > FreeBSD on :) > > ------------------------------------------------------------------------ > thomas r. stromberg tstromberg@rtci.com > senior systems administrator http://www.afterthought.org/ > research triangle commerce, inc. 1.919.657.1317 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 1:56: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from viper.dmpriest.com (viper.dmpriest.com [195.188.177.3]) by hub.freebsd.org (Postfix) with ESMTP id 1A47837B43F for ; Sat, 26 Aug 2000 01:56:02 -0700 (PDT) Received: from tdx.co.uk (lorca.tdx.co.uk [195.188.177.195]) by viper.dmpriest.com (8.9.3/8.9.3/Kp) with ESMTP id JAA87259; Sat, 26 Aug 2000 09:55:45 +0100 (BST) Message-ID: <39A78611.7622D9E4@tdx.co.uk> Date: Sat, 26 Aug 2000 09:55:45 +0100 From: Karl Pielorz Organization: The Digital eXchange X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew N. Dodd" Cc: current@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Matthew N. Dodd" wrote: > Not having a test system with PCI DPT boards somewhat limits my ability to > wring these things out. I won't refuse a rackmounted compaq with PCI and > EISA slots and a brace of DPT and Smart2 RAID cards if someone sends me > one. Who knows? I might even be able to beat a bit on the management > tools then. Hi Matthew, If you remember - we spoke a while ago about some problems the DPT's had with the CAMified driver? - I did offer you a PCI DPT to try, but you thought you'd be OK at the time... I can hopefully still sort that out for you, if your interested - mail me off list... -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 2:14:31 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id EB1F037B422; Sat, 26 Aug 2000 02:14:24 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13Sc2f-000GZe-00; Sat, 26 Aug 2000 11:14:21 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7Q9F9p25033; Sat, 26 Aug 2000 11:15:09 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008260915.e7Q9F9p25033@grimreaper.grondar.za> To: Mark Murray Cc: Johan Kruger , FreeBSD Current , freebsd-hackers@FreeBSD.ORG Subject: Re: perlcc in current - xs_init and boot_DynaLoader References: <200008252024.e7PKOep20703@grimreaper.grondar.za> In-Reply-To: <200008252024.e7PKOep20703@grimreaper.grondar.za> ; from Mark Murray "Fri, 25 Aug 2000 22:24:40 +0200." Date: Sat, 26 Aug 2000 11:15:09 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If i do a perlcc test.pl i get the folllowing , in CURRENT ? > > Must i define something beforehand, or is it broken ? > > I'll take a look... Looks like perl brokenness. The missing boot_DynaLoader is in DynaLoader.a, but there is no way of linking it in. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 4:21:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from columbus.cris.net (columbus.cris.net [212.110.128.65]) by hub.freebsd.org (Postfix) with ESMTP id A223C37B424; Sat, 26 Aug 2000 04:21:19 -0700 (PDT) Received: from ark.cris.net (ark.cris.net [212.110.128.68]) by columbus.cris.net (8.9.3/8.9.3) with ESMTP id OAA25423; Sat, 26 Aug 2000 14:20:47 +0300 (EEST) Received: (from phantom@localhost) by ark.cris.net (8.9.3/8.9.3) id OAA68064; Sat, 26 Aug 2000 14:20:42 +0300 (EEST) (envelope-from phantom) Date: Sat, 26 Aug 2000 14:20:42 +0300 From: Alexey Zelkin To: current@FreeBSD.org Cc: kris@FreeBSD.org Subject: make buildworld (4->5) failed Message-ID: <20000826142042.A67678@ark.cris.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Operating-System: FreeBSD 3.5-STABLE i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, Just experienced on 4.0-RELEASE and 4.1-STABLE (two days ago) following error when tried to build current world. ===> secure/usr.bin/scp cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/usr.bin/scp/../../../crypto/openssh/scp.c cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -o scp scp.o -lcrypto -lutil -lz -L/usr/obj/usr/src/secure/usr.bin/scp/../../lib/libssh -lssh gzip -cn /usr/src/secure/usr.bin/scp/../../../crypto/openssh/scp.1 > scp.1.gz ===> secure/usr.bin/ssh cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -DXAUTH_PATH=/usr/X11R6/bin/xauth -c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c: In function `x11_get_proto': /usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c:685: syntax error before `/' *** Error code 1 Following patch fixed this for me: Index: Makefile =================================================================== RCS file: /home/ncvs/src/secure/usr.bin/ssh/Makefile,v retrieving revision 1.8 diff -u -r1.8 Makefile --- Makefile 2000/08/23 09:39:20 1.8 +++ Makefile 2000/08/26 10:17:10 @@ -37,7 +37,7 @@ .include .if defined(X11BASE) -CFLAGS+= -DXAUTH_PATH=${X11BASE}/bin/xauth +CFLAGS+= -DXAUTH_PATH=\"${X11BASE}/bin/xauth\" .endif LDADD+= -L${.OBJDIR}/../../lib/libssh -lssh -lcrypto -lutil -lz -- /* Alexey Zelkin && phantom@cris.net */ /* Tavric National University && phantom@FreeBSD.org */ /* Sysadmin/Developer && phantom@sms.umc.com.ua */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 5:47:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from barracuda.aquarium.rtci.com (barracuda.aquarium.rtci.com [208.11.247.5]) by hub.freebsd.org (Postfix) with ESMTP id 48CB737B424; Sat, 26 Aug 2000 05:47:54 -0700 (PDT) Received: from barracuda (barracuda [208.11.247.5]) by barracuda.aquarium.rtci.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19649; Sat, 26 Aug 2000 08:47:53 -0400 (EDT) Date: Sat, 26 Aug 2000 08:47:51 -0400 (EDT) From: Thomas Stromberg X-Sender: tstromberg@barracuda.aquarium.rtci.com To: Mike Smith Cc: freebsd-current@freebsd.org, sos@freebsd.dk Subject: Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions.. In-Reply-To: <200008260724.AAA00625@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 26 Aug 2000, Mike Smith wrote: > This is not an "IDE RAID" controller. It's an IDE controller with some > lame "RAID" software in the BIOS. We don't support this. Hopefully this thread will save the next poor soul who tries this. Just to put the final nail in the coffin.. I went ahead and installed on an old WDMA2 drive of mine, and put /var and /usr on what hopefully was a striped RAID. Well, I pulled the second drive offline, and.. it still booted up beautifully. So the striping in bios on the HPT-370 is indeed meaningless. C'est la vie. Now the question is, what ATA-100 RAID solutions are there that are fully supported? I'd guess the Promise board, but the last time I guessed (err.. last week), I got a supported chipset with an unsupported feature :) Just so I don't go do anything stupid, anyone secretly working on drivers for this behind our backs, or is it as good as junk? BTW, these IBM 75GXP drives off of the HPT-370 are amazingly fast for IDE. It was fast enough to fool me into thinking the striping might have been working. Ahh, the delusions hope brings. / Thomas > > For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID > > suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard > > Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 6:22:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 9842137B424; Sat, 26 Aug 2000 06:22:10 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id EECAB28C43; Sat, 26 Aug 2000 20:22:02 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id CD18D28703; Sat, 26 Aug 2000 20:22:02 +0700 (ALMST) Date: Sat, 26 Aug 2000 20:22:02 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: freebsd-current@freebsd.org Subject: devfs patch for review Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-814033623-967296122=:97704" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-814033623-967296122=:97704 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I've made some fixes in the fs layer of new devfs. First version of this patch was passed via Poul and new version includes parts of his suggestions. Here is a brief decription of the patch: Rename de_dir to de_parent with appropritate code changes. Implement proper logic and locking in the devfs_lookup(). Fix behaviour for '.' and '..' directories with corresponding changes in the devfs_readdir(). Implement devfs_read() operation for directories. Return proper mount owner in the devfs_statfs(). Fix panic related to the incorrect handling of root vnode. Few cosmetic changes as well. Code is still not SMP safe. -- Boris Popov http://www.butya.kz/~bp/ --0-814033623-967296122=:97704 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="devfs5.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="devfs5.diff" SW5kZXg6IGRldmZzLmgNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm aWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvZnMvZGV2ZnMvZGV2ZnMuaCx2DQpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMg0KZGlmZiAtdSAtcjEuMiBkZXZmcy5o DQotLS0gZGV2ZnMuaAkyMDAwLzA4LzI0IDE1OjM2OjQ3CTEuMg0KKysrIGRl dmZzLmgJMjAwMC8wOC8yNiAxMjoyODo1Mg0KQEAgLTQ4LDEwICs0OCwxMiBA QA0KICNkZWZpbmUJREVfT1JQSEFOCTB4MQ0KICNkZWZpbmUJREVfRE9UCQkw eDINCiAjZGVmaW5lCURFX0RPVERPVAkweDQNCi0Jc3RydWN0IGRpcmVudCAq ZGVfZGlyZW50Ow0KKwlpbnQJZGVfdHlwZTsNCisJY2hhciAqCWRlX25hbWU7 DQorCWludAlkZV9uYW1lbGVuOw0KIAlUQUlMUV9FTlRSWShkZXZmc19kaXJl bnQpIGRlX2xpc3Q7DQogCVRBSUxRX0hFQUQoLCBkZXZmc19kaXJlbnQpIGRl X2RsaXN0Ow0KLQlzdHJ1Y3QgZGV2ZnNfZGlyZW50ICpkZV9kaXI7DQorCXN0 cnVjdCBkZXZmc19kaXJlbnQgKmRlX3BhcmVudDsNCiAJaW50CWRlX2xpbmtz Ow0KIAltb2RlX3QJZGVfbW9kZTsNCiAJdWlkX3QJZGVfdWlkOw0KQEAgLTY4 LDcgKzcwLDYgQEANCiB9Ow0KIA0KIHN0cnVjdCBkZXZmc19tb3VudCB7DQot CXN0cnVjdCB2bm9kZQkqZG1fcm9vdDsJLyogUm9vdCBub2RlICovDQogCXN0 cnVjdCBkZXZmc19kaXJlbnQgKmRtX3Jvb3RkaXI7DQogCXN0cnVjdCBkZXZm c19kaXJlbnQgKmRtX2Jhc2VkaXI7DQogCXVuc2lnbmVkCWRtX2dlbmVyYXRp b247DQpAQCAtODQsNiArODUsNyBAQA0KIA0KIA0KICNkZWZpbmUgVkZTVE9E RVZGUyhtcCkJKChzdHJ1Y3QgZGV2ZnNfbW91bnQgKikoKG1wKS0+bW50X2Rh dGEpKQ0KKyNkZWZpbmUgVk5UT0RFVkZTKHZwKQkoKHN0cnVjdCBkZXZmc19k aXJlbnQgKikodnApLT52X2RhdGEpDQogDQogZXh0ZXJuIHZvcF90ICoqZGV2 ZnNfdm5vZGVvcF9wOw0KIGV4dGVybiB2b3BfdCAqKmRldmZzX3NwZWNvcF9w Ow0KQEAgLTkzLDYgKzk1LDkgQEANCiB2b2lkIGRldmZzX3B1cmdlIF9fUCgo c3RydWN0IGRldmZzX2RpcmVudCAqZGQpKTsNCiBzdHJ1Y3QgZGV2ZnNfZGly ZW50ICogZGV2ZnNfdm1rZGlyIF9fUCgoY2hhciAqbmFtZSwgaW50IG5hbWVs ZW4sDQogICAgIHN0cnVjdCBkZXZmc19kaXJlbnQgKmRvdGRvdCkpOw0KK2lu dCBkZXZmc19hbGxvY3Yoc3RydWN0IGRldmZzX2RpcmVudCAqZGUsIHN0cnVj dCBtb3VudCAqbXAsIHN0cnVjdCB2bm9kZSAqKnZwcCwNCisJc3RydWN0IHBy b2MgKnByb2MpOw0KKw0KICNlbmRpZiAvKiBERVZGU19JTlRFUk4gKi8NCiAN CiB0eXBlZGVmIHZvaWQgKCpkZXZmc19jbG9uZV9mbikgX19QKCh2b2lkICph cmcsIGNoYXIgKm5hbWUsIGludCBuYW1lbGVuLCBkZXZfdCAqcmVzdWx0KSk7 DQpJbmRleDogZGV2ZnNfZGV2cy5jDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2ZzL2RldmZzL2RldmZz X2RldnMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMw0KZGlmZiAtdSAt cjEuMyBkZXZmc19kZXZzLmMNCi0tLSBkZXZmc19kZXZzLmMJMjAwMC8wOC8y NCAxNTozNjo0NwkxLjMNCisrKyBkZXZmc19kZXZzLmMJMjAwMC8wOC8yNiAx MTo0OTo0OQ0KQEAgLTQ2LDE2ICs0NiwxMyBAQA0KIHsNCiAJaW50IGk7DQog CXN0cnVjdCBkZXZmc19kaXJlbnQgKmRlOw0KLQlzdHJ1Y3QgZGlyZW50IGQ7 DQogDQotCWQuZF9uYW1sZW4gPSBuYW1lbGVuOw0KLQlpID0gc2l6ZW9mICgq ZGUpICsgR0VORVJJQ19ESVJTSVooJmQpOw0KKwlpID0gc2l6ZW9mICgqZGUp ICsgbmFtZWxlbiArIDE7DQogCU1BTExPQyhkZSwgc3RydWN0IGRldmZzX2Rp cmVudCAqLCBpLCBNX0RFVkZTLCBNX1dBSVRPSyk7DQogCWJ6ZXJvKGRlLCBp KTsNCi0JZGUtPmRlX2RpcmVudCA9IChzdHJ1Y3QgZGlyZW50ICopKGRlICsg MSk7DQotCWRlLT5kZV9kaXJlbnQtPmRfbmFtbGVuID0gbmFtZWxlbjsNCi0J ZGUtPmRlX2RpcmVudC0+ZF9yZWNsZW4gPSBHRU5FUklDX0RJUlNJWigmZCk7 DQotCWJjb3B5KG5hbWUsIGRlLT5kZV9kaXJlbnQtPmRfbmFtZSwgbmFtZWxl biArIDEpOw0KKwlkZS0+ZGVfbmFtZSA9IChjaGFyICopKGRlICsgMSk7DQor CWRlLT5kZV9uYW1lbGVuID0gbmFtZWxlbjsNCisJYmNvcHkobmFtZSwgZGUt PmRlX25hbWUsIG5hbWVsZW4pOw0KIAluYW5vdGltZSgmZGUtPmRlX2N0aW1l KTsNCiAJZGUtPmRlX210aW1lID0gZGUtPmRlX2F0aW1lID0gZGUtPmRlX2N0 aW1lOw0KIAlkZS0+ZGVfbGlua3MgPSAxOw0KQEAgLTYzLDM2ICs2MCwyMyBA QA0KIH0NCiANCiBzdHJ1Y3QgZGV2ZnNfZGlyZW50ICoNCi1kZXZmc192bWtk aXIoY2hhciAqbmFtZSwgaW50IG5hbWVsZW4sIHN0cnVjdCBkZXZmc19kaXJl bnQgKmRvdGRvdCkNCitkZXZmc192bWtkaXIoY2hhciAqbmFtZSwgaW50IG5h bWVsZW4sIHN0cnVjdCBkZXZmc19kaXJlbnQgKnBhcmVudCkNCiB7DQotCXN0 cnVjdCBkZXZmc19kaXJlbnQgKmRkOw0KIAlzdHJ1Y3QgZGV2ZnNfZGlyZW50 ICpkZTsNCiANCi0JZGQgPSBkZXZmc19uZXdkaXJlbnQobmFtZSwgbmFtZWxl bik7DQorCWRlID0gZGV2ZnNfbmV3ZGlyZW50KG5hbWUsIG5hbWVsZW4pOw0K IA0KLQlUQUlMUV9JTklUKCZkZC0+ZGVfZGxpc3QpOw0KKwlUQUlMUV9JTklU KCZkZS0+ZGVfZGxpc3QpOw0KIA0KLQlkZC0+ZGVfZGlyZW50LT5kX3R5cGUg PSBEVF9ESVI7DQotCWRkLT5kZV9tb2RlID0gMDc1NTsNCi0JZGQtPmRlX2xp bmtzID0gMjsNCi0JZGQtPmRlX2RpciA9IGRkOw0KLQ0KLQlkZSA9IGRldmZz X25ld2RpcmVudCgiLiIsIDEpOw0KLQlkZS0+ZGVfZGlyZW50LT5kX3R5cGUg PSBEVF9ESVI7DQotCWRlLT5kZV9kaXIgPSBkZDsNCi0JZGUtPmRlX2ZsYWdz IHw9IERFX0RPVDsNCi0JVEFJTFFfSU5TRVJUX1RBSUwoJmRkLT5kZV9kbGlz dCwgZGUsIGRlX2xpc3QpOw0KLQ0KLQlkZSA9IGRldmZzX25ld2RpcmVudCgi Li4iLCAyKTsNCi0JZGUtPmRlX2RpcmVudC0+ZF90eXBlID0gRFRfRElSOw0K LQlpZiAoZG90ZG90ID09IE5VTEwpDQotCQlkZS0+ZGVfZGlyID0gZGQ7DQot CWVsc2UNCi0JCWRlLT5kZV9kaXIgPSBkb3Rkb3Q7DQotCWRlLT5kZV9mbGFn cyB8PSBERV9ET1RET1Q7DQotCVRBSUxRX0lOU0VSVF9UQUlMKCZkZC0+ZGVf ZGxpc3QsIGRlLCBkZV9saXN0KTsNCisJZGUtPmRlX3R5cGUgPSBEVF9ESVI7 DQorCWRlLT5kZV9tb2RlID0gMDc1NTsNCisJZGUtPmRlX2xpbmtzID0gMjsN CiANCi0JcmV0dXJuIChkZCk7DQorCWlmIChwYXJlbnQpIHsNCisJCWRlLT5k ZV9wYXJlbnQgPSBwYXJlbnQ7DQorCQlUQUlMUV9JTlNFUlRfVEFJTCgmcGFy ZW50LT5kZV9kbGlzdCwgZGUsIGRlX2xpc3QpOw0KKwl9DQorCXJldHVybiAo ZGUpOw0KIH0NCiANCiBzdGF0aWMgdm9pZA0KQEAgLTEyNSw3ICsxMDksNiBA QA0KIAlGUkVFKGRkLCBNX0RFVkZTKTsNCiB9DQogDQotDQogaW50DQogZGV2 ZnNfcG9wdWxhdGUoc3RydWN0IGRldmZzX21vdW50ICpkbSkNCiB7DQpAQCAt MTQ1LDcgKzEyOCw3IEBADQogCQkJCWNvbnRpbnVlOw0KIAkJCX0NCiAJCQlp ZiAoZGV2ID09IE5VTEwgJiYgZGUgIT0gTlVMTCkgew0KLQkJCQlkZCA9IGRl LT5kZV9kaXI7DQorCQkJCWRkID0gZGUtPmRlX3BhcmVudDsNCiAJCQkJZG0t PmRtX2RpcmVudFtpXSA9IE5VTEw7DQogCQkJCVRBSUxRX1JFTU9WRSgmZGQt PmRlX2RsaXN0LCBkZSwgZGVfbGlzdCk7DQogCQkJCWlmIChkZS0+ZGVfdm5v ZGUpIHsNCkBAIC0xNjYsOSArMTQ5LDkgQEANCiAJCQkJY29udGludWU7DQog CQkJaWYgKCpxID09ICcvJykgew0KIAkJCQlUQUlMUV9GT1JFQUNIKGRlLCAm ZGQtPmRlX2RsaXN0LCBkZV9saXN0KSB7DQotCQkJCQlpZiAoZGUtPmRlX2Rp cmVudC0+ZF9uYW1sZW4gIT0gcSAtIHMpDQorCQkJCQlpZiAoZGUtPmRlX25h bWVsZW4gIT0gcSAtIHMpDQogCQkJCQkJY29udGludWU7DQotCQkJCQlpZiAo YmNtcChkZS0+ZGVfZGlyZW50LT5kX25hbWUsIHMsIHEgLSBzKSkNCisJCQkJ CWlmIChiY21wKGRlLT5kZV9uYW1lLCBzLCBxIC0gcykpDQogCQkJCQkJY29u dGludWU7DQogCQkJCQlnb3RvIGZkaXI7DQogCQkJCX0NCkBAIC0xODcsNyAr MTcwLDcgQEANCiAJCQkJZGUtPmRlX3VpZCA9IDA7DQogCQkJCWRlLT5kZV9n aWQgPSAwOw0KIAkJCQlkZS0+ZGVfbW9kZSA9IDA2NjY7DQotCQkJCWRlLT5k ZV9kaXJlbnQtPmRfdHlwZSA9IERUX0xOSzsNCisJCQkJZGUtPmRlX3R5cGUg PSBEVF9MTks7DQogCQkJCXBkZXYgPSBkZXYtPnNpX2RydjE7DQogCQkJCWog PSBzdHJsZW4ocGRldi0+c2lfbmFtZSkgKyAxOw0KIAkJCQlNQUxMT0MoZGUt PmRlX3N5bWxpbmssIGNoYXIgKiwgaiwgTV9ERVZGUywgTV9XQUlUT0spOw0K QEAgLTE5Nyw3ICsxODAsNyBAQA0KIAkJCQlkZS0+ZGVfdWlkID0gZGV2LT5z aV91aWQ7DQogCQkJCWRlLT5kZV9naWQgPSBkZXYtPnNpX2dpZDsNCiAJCQkJ ZGUtPmRlX21vZGUgPSBkZXYtPnNpX21vZGU7DQotCQkJCWRlLT5kZV9kaXJl bnQtPmRfdHlwZSA9IERUX0NIUjsNCisJCQkJZGUtPmRlX3R5cGUgPSBEVF9D SFI7DQogCQkJfQ0KIAkJCWRtLT5kbV9kaXJlbnRbaV0gPSBkZTsNCiAJCQlU QUlMUV9JTlNFUlRfVEFJTCgmZGQtPmRlX2RsaXN0LCBkZSwgZGVfbGlzdCk7 DQpJbmRleDogZGV2ZnNfdmZzb3BzLmMNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvZnMvZGV2ZnMvZGV2 ZnNfdmZzb3BzLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMNCmRpZmYg LXUgLXIxLjMgZGV2ZnNfdmZzb3BzLmMNCi0tLSBkZXZmc192ZnNvcHMuYwky MDAwLzA4LzI0IDE1OjM2OjQ3CTEuMw0KKysrIGRldmZzX3Zmc29wcy5jCTIw MDAvMDgvMjYgMTE6NDk6NDkNCkBAIC03OSwzMCArNzksMjMgQEANCiAJCXJl dHVybiAoRU9QTk9UU1VQUCk7DQogDQogCU1BTExPQyhmbXAsIHN0cnVjdCBk ZXZmc19tb3VudCAqLCBzaXplb2Yoc3RydWN0IGRldmZzX21vdW50KSwgTV9E RVZGUywgTV9XQUlUT0spOw0KLQ0KIAliemVybyhmbXAsIHNpemVvZigqZm1w KSk7DQogDQotCWVycm9yID0gZ2V0bmV3dm5vZGUoVlRfREVWRlMsIG1wLCBk ZXZmc192bm9kZW9wX3AsICZydnApOw0KLQlpZiAoZXJyb3IpIHsNCi0JCUZS RUUoZm1wLCBNX0RFVkZTKTsNCi0JCXJldHVybiAoZXJyb3IpOw0KLQl9DQot DQotCXZob2xkKHJ2cCk7DQotCXJ2cC0+dl90eXBlID0gVkRJUjsNCi0JcnZw LT52X2ZsYWcgfD0gVlJPT1Q7DQogCW1wLT5tbnRfZmxhZyB8PSBNTlRfTE9D QUw7DQogCW1wLT5tbnRfZGF0YSA9IChxYWRkcl90KSBmbXA7DQogCXZmc19n ZXRuZXdmc2lkKG1wKTsNCiANCiAJZm1wLT5kbV9pbm9kZSA9IE5ERVZJTk87 DQotCWZtcC0+ZG1fcm9vdCA9IHJ2cDsNCiANCiAJZm1wLT5kbV9yb290ZGly ID0gZGV2ZnNfdm1rZGlyKCIocm9vdCkiLCA2LCBOVUxMKTsNCiAJZm1wLT5k bV9yb290ZGlyLT5kZV9pbm9kZSA9IDI7DQotCXJ2cC0+dl9kYXRhID0gZm1w LT5kbV9yb290ZGlyOw0KLQ0KIAlmbXAtPmRtX2Jhc2VkaXIgPSBmbXAtPmRt X3Jvb3RkaXI7DQorCWVycm9yID0gZGV2ZnNfcm9vdChtcCwgJnJ2cCk7DQor CWlmIChlcnJvcikgew0KKwkJRlJFRShmbXAsIE1fREVWRlMpOw0KKwkJcmV0 dXJuIGVycm9yOw0KKwl9DQorCVZPUF9VTkxPQ0socnZwLCAwLCBwKTsNCiAN CiAJaWYgKHBhdGggIT0gTlVMTCkgew0KIAkJKHZvaWQpIGNvcHlpbnN0cihw YXRoLCBtcC0+bW50X3N0YXQuZl9tbnRvbm5hbWUsIE1OQU1FTEVOIC0gMSwg JnNpemUpOw0KQEAgLTEyNywxMyArMTIwLDE1IEBADQogew0KIAlpbnQgZXJy b3I7DQogCWludCBmbGFncyA9IDA7DQotCXN0cnVjdCB2bm9kZSAqcm9vdHZw ID0gVkZTVE9ERVZGUyhtcCktPmRtX3Jvb3Q7DQotCXN0cnVjdCBkZXZmc19t b3VudCAqZm1wOw0KKwlzdHJ1Y3QgZGV2ZnNfbW91bnQgKmZtcCA9IFZGU1RP REVWRlMobXApOw0KKwlzdHJ1Y3Qgdm5vZGUgKnJvb3R2cDsNCiANCi0JZm1w ID0gKHN0cnVjdCBkZXZmc19tb3VudCopIG1wLT5tbnRfZGF0YTsNCiAJaWYg KG1udGZsYWdzICYgTU5UX0ZPUkNFKQ0KIAkJZmxhZ3MgfD0gRk9SQ0VDTE9T RTsNCiANCisJZXJyb3IgPSBWRlNfUk9PVChtcCwgJnJvb3R2cCk7DQorCWlm IChlcnJvcikNCisJCXJldHVybiAoZXJyb3IpOw0KIAkvKg0KIAkgKiBDbGVh ciBvdXQgYnVmZmVyIGNhY2hlLiAgSSBkb24ndCB0aGluayB3ZQ0KIAkgKiBl dmVyIGdldCBhbnl0aGluZyBjYWNoZWQgYXQgdGhpcyBsZXZlbCBhdCB0aGUN CkBAIC0xNDYsNiArMTQxLDcgQEANCiAJaWYgKGVycm9yKQ0KIAkJcmV0dXJu IChlcnJvcik7DQogDQorCXZwdXQocm9vdHZwKTsNCiAJLyoNCiAJICogUmVs ZWFzZSByZWZlcmVuY2Ugb24gdW5kZXJseWluZyByb290IHZub2RlDQogCSAq Lw0KQEAgLTE1Nyw4ICsxNTMsOCBAQA0KIAkvKg0KIAkgKiBGaW5hbGx5LCB0 aHJvdyBhd2F5IHRoZSBkZXZmc19tb3VudCBzdHJ1Y3R1cmUNCiAJICovDQot CWZyZWUobXAtPm1udF9kYXRhLCBNX0RFVkZTKTsNCi0JbXAtPm1udF9kYXRh ID0gMDsNCisJbXAtPm1udF9kYXRhID0gKHFhZGRyX3QpMDsNCisJZnJlZShm bXAsIE1fREVWRlMpOw0KIAlyZXR1cm4gMDsNCiB9DQogDQpAQCAtMTY3LDE1 ICsxNjMsMTggQEANCiAJc3RydWN0IG1vdW50ICptcDsNCiAJc3RydWN0IHZu b2RlICoqdnBwOw0KIHsNCisJc3RydWN0IGRldmZzX21vdW50ICpkbXAgPSBW RlNUT0RFVkZTKG1wKTsNCiAJc3RydWN0IHByb2MgKnAgPSBjdXJwcm9jOwkv KiBYWFggKi8NCiAJc3RydWN0IHZub2RlICp2cDsNCisJaW50IGVycm9yOw0K IA0KIAkvKg0KIAkgKiBSZXR1cm4gbG9ja2VkIHJlZmVyZW5jZSB0byByb290 Lg0KIAkgKi8NCi0JdnAgPSBWRlNUT0RFVkZTKG1wKS0+ZG1fcm9vdDsNCi0J VlJFRih2cCk7DQotCXZuX2xvY2sodnAsIExLX0VYQ0xVU0lWRSB8IExLX1JF VFJZLCBwKTsNCisJZXJyb3IgPSBkZXZmc19hbGxvY3YoZG1wLT5kbV9yb290 ZGlyLCBtcCwgJnZwLCBwKTsNCisJaWYgKGVycm9yKQ0KKwkJcmV0dXJuIGVy cm9yOw0KKwl2cC0+dl9mbGFnIHw9IFZST09UOw0KIAkqdnBwID0gdnA7DQog CXJldHVybiAoMCk7DQogfQ0KQEAgLTE5Nyw2ICsxOTYsNyBAQA0KIAlzYnAt PmZfZmZyZWUgPSAwOw0KIAlpZiAoc2JwICE9ICZtcC0+bW50X3N0YXQpIHsN CiAJCXNicC0+Zl90eXBlID0gbXAtPm1udF92ZmMtPnZmY190eXBlbnVtOw0K KwkJc2JwLT5mX293bmVyID0gbXAtPm1udF9zdGF0LmZfb3duZXI7CS8qIHVz ZXIgdGhhdCBtb3VudGVkIHRoZSBmaWxlc3lzdGVtICovDQogCQliY29weSgm bXAtPm1udF9zdGF0LmZfZnNpZCwgJnNicC0+Zl9mc2lkLCBzaXplb2Yoc2Jw LT5mX2ZzaWQpKTsNCiAJCWJjb3B5KG1wLT5tbnRfc3RhdC5mX21udG9ubmFt ZSwgc2JwLT5mX21udG9ubmFtZSwgTU5BTUVMRU4pOw0KIAkJYmNvcHkobXAt Pm1udF9zdGF0LmZfbW50ZnJvbW5hbWUsIHNicC0+Zl9tbnRmcm9tbmFtZSwg TU5BTUVMRU4pOw0KSW5kZXg6IGRldmZzX3Zub3BzLmMNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvZnMv ZGV2ZnMvZGV2ZnNfdm5vcHMuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEu Mw0KZGlmZiAtdSAtcjEuMyBkZXZmc192bm9wcy5jDQotLS0gZGV2ZnNfdm5v cHMuYwkyMDAwLzA4LzI0IDE1OjM2OjQ3CTEuMw0KKysrIGRldmZzX3Zub3Bz LmMJMjAwMC8wOC8yNiAxMjoyOToyMg0KQEAgLTUzLDcgKzUzLDcgQEANCiAj aW5jbHVkZSA8ZnMvZGV2ZnMvZGV2ZnMuaD4NCiANCiAjZGVmaW5lIEtTVFJJ TkcJMjU2CQkvKiBMYXJnZXN0IEkvTyBhdmFpbGFibGUgdmlhIHRoaXMgZmls ZXN5c3RlbSAqLw0KLSNkZWZpbmUJVUlPX01YIDMyDQorI2RlZmluZQlERV9T SVpFCShzaXplb2Yoc3RydWN0IGRpcmVudCkpDQogDQogc3RhdGljIGludAlk ZXZmc19hY2Nlc3MgX19QKChzdHJ1Y3Qgdm9wX2FjY2Vzc19hcmdzICphcCkp Ow0KIHN0YXRpYyBpbnQJZGV2ZnNfYmFkb3AgX19QKCh2b2lkKSk7DQpAQCAt NjksMTYgKzY5LDE4IEBADQogc3RhdGljIGludAlkZXZmc19zeW1saW5rIF9f UCgoc3RydWN0IHZvcF9zeW1saW5rX2FyZ3MgKmFwKSk7DQogDQogDQotc3Rh dGljIGludA0KLWRldmZzX2FsbG9jdihzdHJ1Y3QgZGV2ZnNfZGlyZW50ICpk ZSwgc3RydWN0IG1vdW50ICptcCwgc3RydWN0IHZub2RlICoqdnBwLCBzdHJ1 Y3QgcHJvYyAqcCkNCitpbnQNCitkZXZmc19hbGxvY3Yoc3RydWN0IGRldmZz X2RpcmVudCAqZGUsIHN0cnVjdCBtb3VudCAqbXAsIHN0cnVjdCB2bm9kZSAq KnZwcCwNCisJc3RydWN0IHByb2MgKnByb2MpDQogew0KLQlpbnQgZXJyb3I7 DQorCXN0cnVjdCBwcm9jICpwID0gcHJvYyA/IHByb2MgOiBjdXJwcm9jOwkv KiBYWFggKi8NCiAJc3RydWN0IHZub2RlICp2cDsNCisJaW50IGVycm9yOw0K IA0KIGxvb3A6DQogCXZwID0gZGUtPmRlX3Zub2RlOw0KIAlpZiAodnAgIT0g TlVMTCkgew0KLQkJaWYgKHZnZXQodnAsIDAsIHAgPyBwIDogY3VycHJvYykp DQorCQlpZiAodmdldCh2cCwgTEtfRVhDTFVTSVZFLCBwKSkNCiAJCQlnb3Rv IGxvb3A7DQogCQkqdnBwID0gdnA7DQogCQlyZXR1cm4gKDApOw0KQEAgLTg5 LDEzICs5MSwxMyBAQA0KIAkJcmV0dXJuIChlcnJvcik7DQogCX0NCiANCi0J aWYgKGRlLT5kZV9kaXJlbnQtPmRfdHlwZSA9PSBEVF9DSFIpIHsNCisJaWYg KGRlLT5kZV90eXBlID09IERUX0NIUikgew0KIAkJdnAtPnZfdHlwZSA9IFZD SFI7DQogCQl2cCA9IGFkZGFsaWFzdSh2cCwgZGV2ZnNfaW5vdFtkZS0+ZGVf aW5vZGVdLT5zaV91ZGV2KTsNCiAJCXZwLT52X29wID0gZGV2ZnNfc3BlY29w X3A7DQotCX0gZWxzZSBpZiAoZGUtPmRlX2RpcmVudC0+ZF90eXBlID09IERU X0RJUikgew0KKwl9IGVsc2UgaWYgKGRlLT5kZV90eXBlID09IERUX0RJUikg ew0KIAkJdnAtPnZfdHlwZSA9IFZESVI7DQotCX0gZWxzZSBpZiAoZGUtPmRl X2RpcmVudC0+ZF90eXBlID09IERUX0xOSykgew0KKwl9IGVsc2UgaWYgKGRl LT5kZV90eXBlID09IERUX0xOSykgew0KIAkJdnAtPnZfdHlwZSA9IFZMTks7 DQogCX0gZWxzZSB7DQogCQl2cC0+dl90eXBlID0gVkJBRDsNCkBAIC0xMDMs OSArMTA1LDI5IEBADQogCXZwLT52X2RhdGEgPSBkZTsNCiAJZGUtPmRlX3Zu b2RlID0gdnA7DQogCXZob2xkKHZwKTsNCisJdm5fbG9jayh2cCwgTEtfRVhD TFVTSVZFIHwgTEtfUkVUUlksIHApOw0KIAkqdnBwID0gdnA7DQogCXJldHVy biAoMCk7DQogfQ0KKw0KK3N0YXRpYyBpbnQNCitkZXZmc19kZV9sb29rdXAo c3RydWN0IHZub2RlICpkdnAsIGNvbnN0IGNoYXIgKm5hbWUsIGludCBuYW1l bGVuLA0KKwlzdHJ1Y3QgZGV2ZnNfZGlyZW50ICoqZGVwcCkNCit7DQorCXN0 cnVjdCBkZXZmc19kaXJlbnQgKmRkLCAqZGU7DQorDQorCWRldmZzX3BvcHVs YXRlKFZGU1RPREVWRlMoZHZwLT52X21vdW50KSk7DQorCWRkID0gVk5UT0RF VkZTKGR2cCk7DQorCVRBSUxRX0ZPUkVBQ0goZGUsICZkZC0+ZGVfZGxpc3Qs IGRlX2xpc3QpIHsNCisJCWlmIChuYW1lbGVuICE9IGRlLT5kZV9uYW1lbGVu IHx8DQorCQkgICAgYmNtcChuYW1lLCBkZS0+ZGVfbmFtZSwgbmFtZWxlbikg IT0gMCkNCisJCQljb250aW51ZTsNCisJCSpkZXBwID0gZGU7DQorCQlyZXR1 cm4gMDsNCisJfQ0KKwlyZXR1cm4gRU5PRU5UOw0KK30NCisNCiAvKg0KICAq IHZwIGlzIHRoZSBjdXJyZW50IG5hbWVpIGRpcmVjdG9yeQ0KICAqIG5kcCBp cyB0aGUgbmFtZSB0byBsb2NhdGUgaW4gdGhhdCBkaXJlY3RvcnkuLi4NCkBA IC0xMjEsNDcgKzE0Myw2NyBAQA0KIAlzdHJ1Y3QgY29tcG9uZW50bmFtZSAq Y25wID0gYXAtPmFfY25wOw0KIAlzdHJ1Y3Qgdm5vZGUgKip2cHAgPSBhcC0+ YV92cHA7DQogCXN0cnVjdCB2bm9kZSAqZHZwID0gYXAtPmFfZHZwOw0KLQlj aGFyICpwbmFtZSA9IGNucC0+Y25fbmFtZXB0cjsNCisJY2hhciAqbmFtZSA9 IGNucC0+Y25fbmFtZXB0cjsNCiAJc3RydWN0IHByb2MgKnAgPSBjbnAtPmNu X3Byb2M7DQogCXN0cnVjdCBkZXZmc19kaXJlbnQgKmRkOw0KIAlzdHJ1Y3Qg ZGV2ZnNfZGlyZW50ICpkZTsNCiAJc3RydWN0IGRldmZzX21vdW50ICpkbXA7 DQogCWRldl90IGNkZXY7DQotCWludCBlcnJvciwgY2xvbmVkLCBpOw0KIAlj aGFyIHNwZWNuYW1lW1NQRUNOQU1FTEVOICsgMV07DQorCWludCBmbGFncyA9 IGNucC0+Y25fZmxhZ3M7DQorCWludCBpc2RvdGRvdCA9IGZsYWdzICYgSVNE T1RET1Q7DQorCWludCBuYW1lbGVuID0gY25wLT5jbl9uYW1lbGVuOw0KKwlp bnQgbmFtZWlvcCA9IGNucC0+Y25fbmFtZWlvcDsNCisJaW50IGxvY2twYXJl bnQsIHdhbnRwYXJlbnQsIGVycm9yLCBpc2xhc3RjbiwgaTsNCiANCiAJKnZw cCA9IE5VTExWUDsNCiANCi0jaWYgMA0KLQllcnJvciA9IFZPUF9BQ0NFU1Mo ZHZwLCBWRVhFQywgY3JlZCwgY25wLT5jbl9wcm9jKTsNCisJaWYgKGR2cC0+ dl90eXBlICE9IFZESVIpDQorCQlyZXR1cm4gRU5PVERJUjsNCisNCisJaWYg KGlzZG90ZG90ICYmIChkdnAtPnZfZmxhZyAmIFZST09UKSkNCisJCXJldHVy biBFSU87DQorDQorCWVycm9yID0gVk9QX0FDQ0VTUyhkdnAsIFZFWEVDLCBj bnAtPmNuX2NyZWQsIGNucC0+Y25fcHJvYyk7DQogCWlmIChlcnJvcikNCiAJ CXJldHVybiAoZXJyb3IpOw0KLSNlbmRpZg0KKw0KKwlpZiAobmFtZWlvcCA9 PSBSRU5BTUUpDQorCQlyZXR1cm4gRU9QTk9UU1VQUDsNCiANCi0JVk9QX1VO TE9DSyhkdnAsIDAsIHApOw0KLQlpZiAoY25wLT5jbl9uYW1lbGVuID09IDEg JiYgKnBuYW1lID09ICcuJykgew0KKwlpZiAobmFtZWxlbiA9PSAxICYmIG5h bWVbMF0gPT0gJy4nKSB7DQorCQlpZiAobmFtZWlvcCAhPSBMT09LVVApDQor CQkJcmV0dXJuIEVJTlZBTDsNCiAJCSp2cHAgPSBkdnA7DQogCQlWUkVGKGR2 cCk7DQotCQl2bl9sb2NrKGR2cCwgTEtfU0hBUkVEIHwgTEtfUkVUUlksIHAp Ow0KIAkJcmV0dXJuICgwKTsNCiAJfQ0KLQ0KLQljbG9uZWQgPSAwOw0KLQ0K LQlkbXAgPSBWRlNUT0RFVkZTKGR2cC0+dl9tb3VudCk7DQotYWdhaW46DQot DQotCWRldmZzX3BvcHVsYXRlKGRtcCk7DQotCWRkID0gZHZwLT52X2RhdGE7 DQotCVRBSUxRX0ZPUkVBQ0goZGUsICZkZC0+ZGVfZGxpc3QsIGRlX2xpc3Qp IHsNCi0JCWlmIChjbnAtPmNuX25hbWVsZW4gIT0gZGUtPmRlX2RpcmVudC0+ ZF9uYW1sZW4pDQotCQkJY29udGludWU7DQotCQlpZiAoYmNtcChjbnAtPmNu X25hbWVwdHIsIGRlLT5kZV9kaXJlbnQtPmRfbmFtZSwgZGUtPmRlX2RpcmVu dC0+ZF9uYW1sZW4pICE9IDApDQotCQkJY29udGludWU7DQotCQlnb3RvIGZv dW5kOw0KKwlkZCA9IFZOVE9ERVZGUyhkdnApOw0KKwlpc2xhc3RjbiA9IGZs YWdzICYgSVNMQVNUQ047DQorCWxvY2twYXJlbnQgPSBmbGFncyAmIExPQ0tQ QVJFTlQ7DQorCXdhbnRwYXJlbnQgPSBmbGFncyAmIChMT0NLUEFSRU5UIHwg V0FOVFBBUkVOVCk7DQorDQorCWlmIChpc2RvdGRvdCkgew0KKwkJaWYgKG5h bWVpb3AgIT0gTE9PS1VQKQ0KKwkJCXJldHVybiBFSU5WQUw7DQorCQlWT1Bf VU5MT0NLKGR2cCwgMCwgcCk7DQorCQlkZSA9IGRkLT5kZV9wYXJlbnQ7DQor CQllcnJvciA9IGRldmZzX2FsbG9jdihkZSwgZHZwLT52X21vdW50LCB2cHAs IHApOw0KKwkJaWYgKGVycm9yKSB7DQorCQkJdm5fbG9jayhkdnAsIExLX0VY Q0xVU0lWRSB8IExLX1JFVFJZLCBwKTsNCisJCQlyZXR1cm4gZXJyb3I7DQor CQl9DQorCQlpZiAobG9ja3BhcmVudCAmJiBpc2xhc3RjbiAmJg0KKwkJICAg IChlcnJvciA9IHZuX2xvY2soZHZwLCBMS19FWENMVVNJVkUsIHApKSkgew0K KwkJICAgIAl2cHV0KCp2cHApOw0KKwkJCXJldHVybiBlcnJvcjsNCisJCX0N CisJCXJldHVybiAwOw0KIAl9DQogDQotCWlmICghY2xvbmVkKSB7DQorCWRt cCA9IFZGU1RPREVWRlMoZHZwLT52X21vdW50KTsNCisJZXJyb3IgPSBkZXZm c19kZV9sb29rdXAoZHZwLCBuYW1lLCBuYW1lbGVuLCAmZGUpOw0KKwlpZiAo ZXJyb3IpIHsNCiAJCS8qDQogCQkgKiBPSywgd2UgZGlkbid0IGhhdmUgYW4g ZW50cnkgZm9yIHRoZSBuYW1lIHdlIHdlcmUgYXNrZWQgZm9yDQogCQkgKiBz byB3ZSB0cnkgdG8gc2VlIGlmIGFueWJvZHkgY2FuIGNyZWF0ZSBpdCBvbiBk ZW1hbmQuDQpAQCAtMTcxLDI0ICsyMTMsMjEgQEANCiAJCSAqLw0KIAkJaSA9 IFNQRUNOQU1FTEVOOw0KIAkJc3BlY25hbWVbaV0gPSAnXDAnOw0KLQkJaSAt PSBjbnAtPmNuX25hbWVsZW47DQorCQlpIC09IG5hbWVsZW47DQogCQlpZiAo aSA8IDApDQogCQkJIGdvdG8gbm9jbG9uZTsNCi0JCWJjb3B5KGNucC0+Y25f bmFtZXB0ciwgc3BlY25hbWUgKyBpLCBjbnAtPmNuX25hbWVsZW4pOw0KKwkJ YmNvcHkobmFtZSwgc3BlY25hbWUgKyBpLCBuYW1lbGVuKTsNCiAJCWRlID0g ZGQ7DQotCQl3aGlsZSAoZGUgIT0gZG1wLT5kbV9iYXNlZGlyKSB7DQorCQl3 aGlsZSAoZGUtPmRlX3BhcmVudCkgew0KIAkJCWktLTsNCiAJCQlpZiAoaSA8 IDApDQogCQkJCSBnb3RvIG5vY2xvbmU7DQogCQkJc3BlY25hbWVbaV0gPSAn Lyc7DQotCQkJaSAtPSBkZS0+ZGVfZGlyZW50LT5kX25hbWxlbjsNCisJCQlp IC09IGRlLT5kZV9uYW1lbGVuOw0KIAkJCWlmIChpIDwgMCkNCiAJCQkJIGdv dG8gbm9jbG9uZTsNCi0JCQliY29weShkZS0+ZGVfZGlyZW50LT5kX25hbWUs IHNwZWNuYW1lICsgaSwNCi0JCQkgICAgZGUtPmRlX2RpcmVudC0+ZF9uYW1s ZW4pOw0KLQkJCWRlID0gVEFJTFFfRklSU1QoJmRlLT5kZV9kbGlzdCk7CS8q ICIuIiAqLw0KLQkJCWRlID0gVEFJTFFfTkVYVChkZSwgZGVfbGlzdCk7CQkv KiAiLi4iICovDQotCQkJZGUgPSBkZS0+ZGVfZGlyOw0KKwkJCWJjb3B5KGRl LT5kZV9uYW1lLCBzcGVjbmFtZSArIGksIGRlLT5kZV9uYW1lbGVuKTsNCisJ CQlkZSA9IGRlLT5kZV9wYXJlbnQ7DQogCQl9DQogDQogI2lmIDANCkBAIC0y MDEsNDcgKzI0MCw0NCBAQA0KIAkJcHJpbnRmKCJjbG9uZWQgJXMgLT4gJXAg JXNcbiIsIHNwZWNuYW1lICsgaSwgY2RldiwNCiAJCSAgICBjZGV2ID09IE5P REVWID8gIk5PREVWIiA6IGNkZXYtPnNpX25hbWUpOw0KICNlbmRpZg0KLQkJ aWYgKGNkZXYgIT0gTk9ERVYpIHsNCi0JCQljbG9uZWQgPSAxOw0KLQkJCWdv dG8gYWdhaW47DQotCQl9DQorCQlpZiAoY2RldiAhPSBOT0RFVikNCisJCQll cnJvciA9IGRldmZzX2RlX2xvb2t1cChkdnAsIG5hbWUsIG5hbWVsZW4sICZk ZSk7DQogCX0NCi0NCiBub2Nsb25lOg0KLQkvKiBObyBsdWNrLCB0b28gYmFk LiAqLw0KLQ0KLQlpZiAoKGNucC0+Y25fbmFtZWlvcCA9PSBDUkVBVEUgfHwg Y25wLT5jbl9uYW1laW9wID09IFJFTkFNRSkgJiYNCi0JICAgIChjbnAtPmNu X2ZsYWdzICYgSVNMQVNUQ04pKSB7DQotCQljbnAtPmNuX2ZsYWdzIHw9IFNB VkVOQU1FOw0KLQkJaWYgKCEoY25wLT5jbl9mbGFncyAmIExPQ0tQQVJFTlQp KQ0KLQkJCVZPUF9VTkxPQ0soZHZwLCAwLCBwKTsNCi0JCXJldHVybiAoRUpV U1RSRVRVUk4pOw0KLQl9IGVsc2Ugew0KLQkJdm5fbG9jayhkdnAsIExLX1NI QVJFRCB8IExLX1JFVFJZLCBwKTsNCisJaWYgKGVycm9yKSB7DQorCQkvKg0K KwkJICogTm8gdmFsaWQgZW50cnkgd2FzIGZvdW5kDQorCQkgKi8NCisJCWlm ICgobmFtZWlvcCA9PSBDUkVBVEUgfHwgbmFtZWlvcCA9PSBSRU5BTUUpICYm DQorCQkgICAgd2FudHBhcmVudCAmJiBpc2xhc3Rjbikgew0KKwkJCWNucC0+ Y25fZmxhZ3MgfD0gU0FWRU5BTUU7DQorCQkJaWYgKCFsb2NrcGFyZW50KQ0K KwkJCQlWT1BfVU5MT0NLKGR2cCwgMCwgcCk7DQorCQkJcmV0dXJuIChFSlVT VFJFVFVSTik7DQorCQl9DQogCQlyZXR1cm4gKEVOT0VOVCk7DQogCX0NCi0N CiANCi1mb3VuZDoNCi0NCi0JZXJyb3IgPSBkZXZmc19hbGxvY3YoZGUsIGR2 cC0+dl9tb3VudCwgdnBwLCBwKTsNCi0JaWYgKGVycm9yICE9IDApIHsNCi0J CXZuX2xvY2soZHZwLCBMS19TSEFSRUQgfCBMS19SRVRSWSwgcCk7DQotCQly ZXR1cm4gKGVycm9yKTsNCi0JfQ0KLQlpZiAoKGNucC0+Y25fbmFtZWlvcCA9 PSBERUxFVEUpICYmIChjbnAtPmNuX2ZsYWdzICYgSVNMQVNUQ04pKSB7DQor CWlmIChuYW1laW9wID09IERFTEVURSAmJiBpc2xhc3Rjbikgew0KKwkJZXJy b3IgPSBWT1BfQUNDRVNTKGR2cCwgVldSSVRFLCBjbnAtPmNuX2NyZWQsIHAp Ow0KKwkJaWYgKGVycm9yKQ0KKwkJCXJldHVybiAoZXJyb3IpOw0KIAkJaWYg KCp2cHAgPT0gZHZwKSB7DQogCQkJVlJFRihkdnApOw0KIAkJCSp2cHAgPSBk dnA7DQogCQkJcmV0dXJuICgwKTsNCiAJCX0NCi0JCVZSRUYoKnZwcCk7DQot CQlpZiAoIShjbnAtPmNuX2ZsYWdzICYgTE9DS1BBUkVOVCkpDQorCQllcnJv ciA9IGRldmZzX2FsbG9jdihkZSwgZHZwLT52X21vdW50LCB2cHAsIHApOw0K KwkJaWYgKGVycm9yKQ0KKwkJCXJldHVybiAoZXJyb3IpOw0KKwkJaWYgKCFs b2NrcGFyZW50KQ0KIAkJCVZPUF9VTkxPQ0soZHZwLCAwLCBwKTsNCiAJCXJl dHVybiAoMCk7DQogCX0NCi0Jdm5fbG9jaygqdnBwLCBMS19TSEFSRUQgfCBM S19SRVRSWSwgcCk7DQotCWlmICghKGNucC0+Y25fZmxhZ3MgJiBMT0NLUEFS RU5UKSkNCisJZXJyb3IgPSBkZXZmc19hbGxvY3YoZGUsIGR2cC0+dl9tb3Vu dCwgdnBwLCBwKTsNCisJaWYgKGVycm9yKQ0KKwkJcmV0dXJuIGVycm9yOw0K KwlpZiAoIWxvY2twYXJlbnQgfHwgIWlzbGFzdGNuKQ0KIAkJVk9QX1VOTE9D SyhkdnAsIDAsIHApOw0KIAlyZXR1cm4gKDApOw0KIH0NCkBAIC0yNTYsMTEg KzI5Miw3IEBADQogCX0gKi8gKmFwOw0KIHsNCiAJc3RydWN0IHZub2RlICp2 cCA9IGFwLT5hX3ZwOw0KLQlzdHJ1Y3QgZGV2ZnNfZGlyZW50ICpkZTsNCi0N Ci0JZGUgPSB2cC0+dl9kYXRhOw0KLQlpZiAodnAtPnZfdHlwZSA9PSBWRElS KQ0KLQkJZGUgPSBkZS0+ZGVfZGlyOw0KKwlzdHJ1Y3QgZGV2ZnNfZGlyZW50 ICpkZSA9IFZOVE9ERVZGUyh2cCk7DQogDQogCXJldHVybiAodmFjY2Vzcyh2 cC0+dl90eXBlLCBkZS0+ZGVfbW9kZSwgZGUtPmRlX3VpZCwgZGUtPmRlX2dp ZCwNCiAJICAgIGFwLT5hX21vZGUsIGFwLT5hX2NyZWQpKTsNCkBAIC0yNzcs MTMgKzMwOSwxMCBAQA0KIHsNCiAJc3RydWN0IHZub2RlICp2cCA9IGFwLT5h X3ZwOw0KIAlzdHJ1Y3QgdmF0dHIgKnZhcCA9IGFwLT5hX3ZhcDsNCisJc3Ry dWN0IGRldmZzX2RpcmVudCAqZGUgPSBWTlRPREVWRlModnApOw0KIAlpbnQg ZXJyb3IgPSAwOw0KLQlzdHJ1Y3QgZGV2ZnNfZGlyZW50ICpkZTsNCiAJZGV2 X3QgZGV2Ow0KIA0KLQlkZSA9IHZwLT52X2RhdGE7DQotCWlmICh2cC0+dl90 eXBlID09IFZESVIpIA0KLQkJZGUgPSBkZS0+ZGVfZGlyOw0KIAliemVybygo Y2FkZHJfdCkgdmFwLCBzaXplb2YoKnZhcCkpOw0KIAl2YXR0cl9udWxsKHZh cCk7DQogCXZhcC0+dmFfdWlkID0gZGUtPmRlX3VpZDsNCkBAIC0zMDgsMTEg KzMzNywxMiBAQA0KIAl2YXAtPnZhX25saW5rID0gZGUtPmRlX2xpbmtzOw0K IAl2YXAtPnZhX2ZpbGVpZCA9IGRlLT5kZV9pbm9kZTsNCiANCi0JaWYgKGRl LT5kZV9kaXJlbnQtPmRfdHlwZSA9PSBEVF9ESVIpIHsNCisJaWYgKGRlLT5k ZV90eXBlID09IERUX0RJUikgew0KIAkJdmFwLT52YV90eXBlID0gVkRJUjsN Ci0JfSBlbHNlIGlmIChkZS0+ZGVfZGlyZW50LT5kX3R5cGUgPT0gRFRfTE5L KSB7DQorCQl2YXAtPnZhX3NpemUgPSA1MTI7CQkvKiBhbnkgbm9uLXplcm8g dmFsdWUgKi8NCisJfSBlbHNlIGlmIChkZS0+ZGVfdHlwZSA9PSBEVF9MTksp IHsNCiAJCXZhcC0+dmFfdHlwZSA9IFZMTks7DQotCX0gZWxzZSBpZiAoZGUt PmRlX2RpcmVudC0+ZF90eXBlID09IERUX0NIUikgew0KKwl9IGVsc2UgaWYg KGRlLT5kZV90eXBlID09IERUX0NIUikgew0KIAkJdmFwLT52YV90eXBlID0g VkNIUjsNCiAJCXZhcC0+dmFfcmRldiA9IGRldmZzX2lub3RbZGUtPmRlX2lu b2RlXS0+c2lfdWRldjsNCiAJfQ0KQEAgLTMzNCwzMSArMzY0LDMwIEBADQog CX0gKi8gKmFwOw0KIHsNCiAJc3RydWN0IGRldmZzX2RpcmVudCAqZGU7DQor CXN0cnVjdCB2YXR0ciAqdmFwID0gYXAtPmFfdmFwOw0KIAlpbnQgYzsNCiAN Ci0JZGUgPSBhcC0+YV92cC0+dl9kYXRhOw0KLQlpZiAoYXAtPmFfdnAtPnZf dHlwZSA9PSBWRElSKSANCi0JCWRlID0gZGUtPmRlX2RpcjsNCisJZGUgPSBW TlRPREVWRlMoYXAtPmFfdnApOw0KIA0KIAljID0gMDsNCi0JaWYgKGFwLT5h X3ZhcC0+dmFfZmxhZ3MgIT0gVk5PVkFMKQ0KKwlpZiAodmFwLT52YV9mbGFn cyAhPSBWTk9WQUwpDQogCQlyZXR1cm4gKEVPUE5PVFNVUFApOw0KLQlpZiAo YXAtPmFfdmFwLT52YV91aWQgIT0gKHVpZF90KVZOT1ZBTCkgew0KLQkJZGUt PmRlX3VpZCA9IGFwLT5hX3ZhcC0+dmFfdWlkOw0KKwlpZiAodmFwLT52YV91 aWQgIT0gKHVpZF90KVZOT1ZBTCkgew0KKwkJZGUtPmRlX3VpZCA9IHZhcC0+ dmFfdWlkOw0KIAkJYyA9IDE7DQogCX0NCi0JaWYgKGFwLT5hX3ZhcC0+dmFf Z2lkICE9IChnaWRfdClWTk9WQUwpIHsNCi0JCWRlLT5kZV9naWQgPSBhcC0+ YV92YXAtPnZhX2dpZDsNCisJaWYgKHZhcC0+dmFfZ2lkICE9IChnaWRfdClW Tk9WQUwpIHsNCisJCWRlLT5kZV9naWQgPSB2YXAtPnZhX2dpZDsNCiAJCWMg PSAxOw0KIAl9DQotCWlmIChhcC0+YV92YXAtPnZhX21vZGUgIT0gKG1vZGVf dClWTk9WQUwpIHsNCi0JCWRlLT5kZV9tb2RlID0gYXAtPmFfdmFwLT52YV9t b2RlOw0KKwlpZiAodmFwLT52YV9tb2RlICE9IChtb2RlX3QpVk5PVkFMKSB7 DQorCQlkZS0+ZGVfbW9kZSA9IHZhcC0+dmFfbW9kZTsNCiAJCWMgPSAxOw0K IAl9DQotCWlmIChhcC0+YV92YXAtPnZhX2F0aW1lLnR2X3NlYyAhPSBWTk9W QUwpDQotCQlkZS0+ZGVfYXRpbWUgPSBhcC0+YV92YXAtPnZhX2F0aW1lOw0K LQlpZiAoYXAtPmFfdmFwLT52YV9tdGltZS50dl9zZWMgIT0gVk5PVkFMKQ0K LQkJZGUtPmRlX210aW1lID0gYXAtPmFfdmFwLT52YV9tdGltZTsNCisJaWYg KHZhcC0+dmFfYXRpbWUudHZfc2VjICE9IFZOT1ZBTCkNCisJCWRlLT5kZV9h dGltZSA9IHZhcC0+dmFfYXRpbWU7DQorCWlmICh2YXAtPnZhX210aW1lLnR2 X3NlYyAhPSBWTk9WQUwpDQorCQlkZS0+ZGVfbXRpbWUgPSB2YXAtPnZhX210 aW1lOw0KIA0KIAlpZiAoYykNCiAJCWdldG5hbm90aW1lKCZkZS0+ZGVfY3Rp bWUpOw0KQEAgLTM2Niw2ICszOTUsMjIgQEANCiB9DQogDQogc3RhdGljIGlu dA0KK2RldmZzX3JlYWQoc3RydWN0IHZvcF9yZWFkX2FyZ3MgKmFwKQ0KKyAg ICAgICAgLypzdHJ1Y3Qgdm9wX3JlYWRfYXJncyB7DQorICAgICAgICAgICAg ICAgIHN0cnVjdCB2bm9kZSAqYV92cDsNCisgICAgICAgICAgICAgICAgc3Ry dWN0IHVpbyAqYV91aW87DQorICAgICAgICAgICAgICAgIGludCAgYV9pb2Zs YWc7DQorICAgICAgICAgICAgICAgIHN0cnVjdCB1Y3JlZCAqYV9jcmVkOw0K KyAgICAgICAgfSAqLw0KK3sNCisJc3RydWN0IHZub2RlICp2cCA9IGFwLT5h X3ZwOw0KKw0KKwlpZiAodnAtPnZfdHlwZSAhPSBWRElSKQ0KKwkJcmV0dXJu IChFSU5WQUwpOw0KKwlyZXR1cm4gKFZPUF9SRUFERElSKHZwLCBhcC0+YV91 aW8sIGFwLT5hX2NyZWQsIE5VTEwsIE5VTEwsIE5VTEwpKTsNCit9DQorDQor c3RhdGljIGludA0KIGRldmZzX3JlYWRkaXIoYXApDQogCXN0cnVjdCB2b3Bf cmVhZGRpcl9hcmdzIC8qIHsNCiAJCXN0cnVjdCB2bm9kZSAqYV92cDsNCkBA IC0zNzYsNDAgKzQyMSw2NCBAQA0KIAkJdV9sb25nICoqYV9jb29raWVzOw0K IAl9ICovICphcDsNCiB7DQotCWludCBlcnJvciwgaTsNCisJc3RydWN0IHZu b2RlICp2cCA9IGFwLT5hX3ZwOw0KIAlzdHJ1Y3QgdWlvICp1aW8gPSBhcC0+ YV91aW87DQotCXN0cnVjdCBkaXJlbnQgKmRwOw0KLQlzdHJ1Y3QgZGV2ZnNf ZGlyZW50ICpkZDsNCi0Jc3RydWN0IGRldmZzX2RpcmVudCAqZGU7DQorCXN0 cnVjdCBkaXJlbnQgKmRwLCBkaXJlbnQ7DQorCXN0cnVjdCBkZXZmc19kaXJl bnQgKmRkLCAqZGU7DQogCXN0cnVjdCBkZXZmc19tb3VudCAqZG1wOw0KIAlv ZmZfdCBvZmY7DQorCWludCBlcnJvciwgZW50cnlpZCwgaTsNCiANCiAJaWYg KGFwLT5hX3ZwLT52X3R5cGUgIT0gVkRJUikNCiAJCXJldHVybiAoRU5PVERJ Uik7DQorDQorCWlmIChhcC0+YV9uY29va2llcykgew0KKwkJcHJpbnRmKCJk ZXZmc19yZWFkZGlyOiBjb29raWVzIG5vdCBzdXBwb3J0ZWRcbiIpOw0KKwkJ cmV0dXJuIEVPUE5PVFNVUFA7DQorCX0NCiANCi0JZG1wID0gVkZTVE9ERVZG UyhhcC0+YV92cC0+dl9tb3VudCk7DQorCWlmICh1aW8tPnVpb19yZXNpZCA8 IERFX1NJWkUgfHwgdWlvLT51aW9fb2Zmc2V0IDwgMCkNCisJCXJldHVybiBF SU5WQUw7DQorDQorCWRtcCA9IFZGU1RPREVWRlModnAtPnZfbW91bnQpOw0K IAlkZXZmc19wb3B1bGF0ZShkbXApOw0KLQlpID0gKHVfaW50KW9mZiAvIFVJ T19NWDsNCisNCisJb2ZmID0gdWlvLT51aW9fb2Zmc2V0Ow0KKwllbnRyeWlk ID0gb2ZmIC8gREVfU0laRTsNCiAJZXJyb3IgPSAwOw0KLQlkZSA9IGFwLT5h X3ZwLT52X2RhdGE7DQotCWRkID0gVEFJTFFfRklSU1QoJmRlLT5kZV9kbGlz dCk7DQotCW9mZiA9IDA7DQotCXdoaWxlICh1aW8tPnVpb19yZXNpZCA+PSBV SU9fTVggJiYgZGQgIT0gTlVMTCkgew0KLQkJaWYgKGRkLT5kZV9kaXJlbnQt PmRfdHlwZSA9PSBEVF9ESVIpIA0KLQkJCWRlID0gZGQtPmRlX2RpcjsNCi0J CWVsc2UNCi0JCQlkZSA9IGRkOw0KLQkJZHAgPSBkZC0+ZGVfZGlyZW50Ow0K LQkJZHAtPmRfZmlsZW5vID0gZGUtPmRlX2lub2RlOw0KLQkJaWYgKG9mZiA+ PSB1aW8tPnVpb19vZmZzZXQpDQotCQkJaWYgKChlcnJvciA9IHVpb21vdmUo KGNhZGRyX3QpZHAsIGRwLT5kX3JlY2xlbiwgdWlvKSkgIT0gMCkNCi0JCQkJ YnJlYWs7DQorCWRkID0gVk5UT0RFVkZTKHZwKTsNCisNCisJZGUgPSBUQUlM UV9GSVJTVCgmZGQtPmRlX2RsaXN0KTsNCisJZm9yIChpID0gZW50cnlpZCAt IDI7IGRlICYmIGkgPiAwOyBpLS0pDQorCQlkZSA9IFRBSUxRX05FWFQoZGUs IGRlX2xpc3QpOw0KKw0KKwlkcCA9ICZkaXJlbnQ7DQorCXdoaWxlICh1aW8t PnVpb19yZXNpZCA+PSBERV9TSVpFICYmIGRlICE9IE5VTEwpIHsNCisJCWJ6 ZXJvKGRwLCBERV9TSVpFKTsNCisJCWRwLT5kX3JlY2xlbiA9IERFX1NJWkU7 DQorCQlzd2l0Y2ggKGVudHJ5aWQpIHsNCisJCSAgICBjYXNlIDA6DQorCQkg ICAgY2FzZSAxOg0KKwkJCWRwLT5kX25hbWVbMF0gPSBkcC0+ZF9uYW1lWzFd ID0gJy4nOw0KKwkJCWRwLT5kX2ZpbGVubyA9IChlbnRyeWlkID09IDApID8g ZGQtPmRlX2lub2RlIDoNCisJCQkgICAgKGRkLT5kZV9wYXJlbnQgPyBkZC0+ ZGVfcGFyZW50LT5kZV9pbm9kZSA6IDEpOw0KKwkJCWRwLT5kX25hbWxlbiA9 IGVudHJ5aWQgKyAxOw0KKwkJCWRwLT5kX25hbWVbZW50cnlpZCArIDFdID0g J1wwJzsNCisJCQlkcC0+ZF90eXBlID0gRFRfRElSOw0KKwkJCWJyZWFrOw0K KwkJICAgIGRlZmF1bHQ6DQorCQkJZHAtPmRfZmlsZW5vID0gZGUtPmRlX2lu b2RlOw0KKwkJCWRwLT5kX25hbWxlbiA9IGRlLT5kZV9uYW1lbGVuOw0KKwkJ CWRwLT5kX3R5cGUgPSBkZS0+ZGVfdHlwZTsNCisJCQliY29weShkZS0+ZGVf bmFtZSwgZHAtPmRfbmFtZSwgZGUtPmRlX25hbWVsZW4gKyAxKTsNCisJCQlk ZSA9IFRBSUxRX05FWFQoZGUsIGRlX2xpc3QpOw0KKwkJfQ0KKwkJaWYgKChl cnJvciA9IHVpb21vdmUoKGNhZGRyX3QpZHAsIGRwLT5kX3JlY2xlbiwgdWlv KSkgIT0gMCkNCisJCQlicmVhazsNCiAJCW9mZiArPSBkcC0+ZF9yZWNsZW47 DQotCQlkZCA9IFRBSUxRX05FWFQoZGQsIGRlX2xpc3QpOw0KKwkJZW50cnlp ZCsrOw0KIAl9DQotDQogCXVpby0+dWlvX29mZnNldCA9IG9mZjsNCi0NCiAJ cmV0dXJuIChlcnJvcik7DQogfQ0KIA0KQEAgLTQyNCw3ICs0OTMsNyBAQA0K IAlpbnQgZXJyb3I7DQogCXN0cnVjdCBkZXZmc19kaXJlbnQgKmRlOw0KIA0K LQlkZSA9IGFwLT5hX3ZwLT52X2RhdGE7DQorCWRlID0gVk5UT0RFVkZTKGFw LT5hX3ZwKTsNCiAJZXJyb3IgPSB1aW9tb3ZlKGRlLT5kZV9zeW1saW5rLCBz dHJsZW4oZGUtPmRlX3N5bWxpbmspICsgMSwgYXAtPmFfdWlvKTsNCiAJcmV0 dXJuIChlcnJvcik7DQogfQ0KQEAgLTUwNCwyNiArNTczLDI0IEBADQogCQlj aGFyICphX3RhcmdldDsNCiAJfSAqLyAqYXA7DQogew0KLQlpbnQgaTsNCi0J c3RydWN0IGRldmZzX2RpcmVudCAqZGQ7DQorCXN0cnVjdCB2bm9kZSAqZHZw ID0gYXAtPmFfZHZwOw0KKwlzdHJ1Y3QgZGV2ZnNfbW91bnQgKmRtcCA9IFZG U1RPREVWRlMoZHZwLT52X21vdW50KTsNCisJc3RydWN0IGRldmZzX2RpcmVu dCAqZGQgPSBWTlRPREVWRlMoZHZwKTsNCiAJc3RydWN0IGRldmZzX2RpcmVu dCAqZGU7DQotCXN0cnVjdCBkZXZmc19tb3VudCAqZG1wOw0KKwljaGFyICp0 YXJnZXQgPSBhcC0+YV90YXJnZXQ7DQorCWludCBpOw0KIA0KLQlkbXAgPSAo c3RydWN0IGRldmZzX21vdW50ICopYXAtPmFfZHZwLT52X21vdW50LT5tbnRf ZGF0YTsNCi0JZGQgPSBhcC0+YV9kdnAtPnZfZGF0YTsNCiAJZGUgPSBkZXZm c19uZXdkaXJlbnQoYXAtPmFfY25wLT5jbl9uYW1lcHRyLCBhcC0+YV9jbnAt PmNuX25hbWVsZW4pOw0KIAlkZS0+ZGVfdWlkID0gMDsNCiAJZGUtPmRlX2dp ZCA9IDA7DQogCWRlLT5kZV9tb2RlID0gMDY0MjsNCiAJZGUtPmRlX2lub2Rl ID0gZG1wLT5kbV9pbm9kZSsrOw0KLQlkZS0+ZGVfZGlyZW50LT5kX3R5cGUg PSBEVF9MTks7DQotCWkgPSBzdHJsZW4oYXAtPmFfdGFyZ2V0KSArIDE7DQor CWRlLT5kZV90eXBlID0gRFRfTE5LOw0KKwlpID0gc3RybGVuKHRhcmdldCkg KyAxOw0KIAlNQUxMT0MoZGUtPmRlX3N5bWxpbmssIGNoYXIgKiwgaSwgTV9E RVZGUywgTV9XQUlUT0spOw0KLQliY29weShhcC0+YV90YXJnZXQsIGRlLT5k ZV9zeW1saW5rLCBpKTsNCisJYmNvcHkodGFyZ2V0LCBkZS0+ZGVfc3ltbGlu aywgaSk7DQogCVRBSUxRX0lOU0VSVF9UQUlMKCZkZC0+ZGVfZGxpc3QsIGRl LCBkZV9saXN0KTsNCi0JZGV2ZnNfYWxsb2N2KGRlLCBhcC0+YV9kdnAtPnZf bW91bnQsIGFwLT5hX3ZwcCwgMCk7DQotCVZSRUYoKihhcC0+YV92cHApKTsN Ci0JcmV0dXJuICgwKTsNCisJcmV0dXJuIGRldmZzX2FsbG9jdihkZSwgZHZw LT52X21vdW50LCBhcC0+YV92cHAsIDApOw0KIH0NCiANCiAvKg0KQEAgLTU0 Miw3ICs2MDksNyBAQA0KIH0NCiANCiAvKg0KLSAqIEtlcm5mcyAic2hvdWxk IG5ldmVyIGdldCBoZXJlIiBvcGVyYXRpb24NCisgKiBkZXZmcyAic2hvdWxk IG5ldmVyIGdldCBoZXJlIiBvcGVyYXRpb24NCiAgKi8NCiBzdGF0aWMgaW50 DQogZGV2ZnNfYmFkb3AoKQ0KQEAgLTU1OSw2ICs2MjYsNyBAQA0KIAl7ICZ2 b3BfbG9va3VwX2Rlc2MsCQkodm9wX3QgKikgZGV2ZnNfbG9va3VwIH0sDQog CXsgJnZvcF9wYXRoY29uZl9kZXNjLAkJKHZvcF90ICopIHZvcF9zdGRwYXRo Y29uZiB9LA0KIAl7ICZ2b3BfcHJpbnRfZGVzYywJCSh2b3BfdCAqKSBkZXZm c19wcmludCB9LA0KKwl7ICZ2b3BfcmVhZF9kZXNjLAkJKHZvcF90ICopIGRl dmZzX3JlYWQgfSwNCiAJeyAmdm9wX3JlYWRkaXJfZGVzYywJCSh2b3BfdCAq KSBkZXZmc19yZWFkZGlyIH0sDQogCXsgJnZvcF9yZWFkbGlua19kZXNjLAkJ KHZvcF90ICopIGRldmZzX3JlYWRsaW5rIH0sDQogCXsgJnZvcF9yZWNsYWlt X2Rlc2MsCQkodm9wX3QgKikgZGV2ZnNfcmVjbGFpbSB9LA0K --0-814033623-967296122=:97704-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 6:57:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherspace.org (modemcable204.96-200-24.mtl.mc.videotron.net [24.200.96.204]) by hub.freebsd.org (Postfix) with ESMTP id 9FE1737B422; Sat, 26 Aug 2000 06:57:50 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id JAA05375; Sat, 26 Aug 2000 09:59:48 -0500 Date: Sat, 26 Aug 2000 09:59:48 -0500 Message-Id: <200008261459.JAA05375@cypherspace.org> From: Adam Back To: mark@grondar.za Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org Subject: Re: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark writes: > > I'm hoping to persuade the yarrow designers of the importance of > > supporting /dev/random semantics for the unix community acceptance. > > John Kelsey and I had some discussions along the lines of feeding > > /dev/random output into yarrow, which I notice someone on here > > considered. > > By "/dev/random semantics", are you referring to a blocking model > that "counts" entropy and blocks when it beieves it is "empty"? Yes. See the mbox archive I just put up at: http://www.cypherspace.org/~adam/yarrow.txt and [1] below for my arguments of why I agree with Kris and Jeroen's earlier comments. You really can't use yarrow to implement /dev/random as it is. Even waiting for reseeds doesn't cut it. The issue is that everything goes through the yarrow output function, which restricts yarrow to offering computational security with at worst 2^n work factor to break because it offers known plaintext the 0 block as the first output is E_k( 0 ). > I am against the blocking model, as I believe that it goes against > what Yarrow is trying to do. If the Yarrow authors argued otherwise, > I'd listen. Niels and John Kelsey were against it to initially, on the grounds that computational security (160 bits -- or whatever the parameter is with the ciphers you have plugged in) is in fact "good enough" in practice even for 1024 bit RSA key generation. (The argument has some validity; in practice a brute force attack against RSA 1024 takes significantly less than 2^160 operations, though the memory requirements are higher). However it is not fair to impose that view on someone. People can have legitmate reasons to need more entropy. Another very concrete example is: say someone is using a yarrow-160 (3DES and SHA1) implementation and they want to use an AES cipher with a 256 bit key -- without the /dev/random API, you can't get 256 bit security, with it you can. OTPs and some algorithms offer information theoretic security, or you may be using a larger key space symmetric construct than the yarrow output size (using 256 doesn't solve that -- then they want a 512 bit key). Worse people may already be using /dev/random for these assumptions, so you risk breaking existing code's security by replacing /dev/random with yarrow. > > - yarrow design specifically calls for a hash functoin and a block > > cipher -- you may easily be violating some of it's security > > assumptions by plugging in the above. > > If I construct a specific hash function, is this still a problem? No. Note my other comments on list about CBC-MAC are confused -- I misread your code. It appears to be a keyless hash function, and as Joeren noted it has some similarities to Davies-Meyer, but it's not quite the same for the reasons he noted. The main argument is against not using constructs which haven't received lots of peer-review -- most crypto constructs are very fragile to small design changes. Adam [1] ====================================================================== Here's a cut and paste from discussions on yarrow list summarising my view: | we still have a community acceptance problem: there remains the | possibility that /dev/random could produce unconditionally secure | ouput [IFF entropy estimates are conservative]; if we replace this | with something which _can not_ be unconditionally secure, we face | complaints. and: | So given that, it doesn't seem quite fair to pull the rug from under | /dev/random users and replace it with a PRNG with quite different | security assumptions. Users would have similar reasons to be upset if | someone removed their /dev/random and symlinked it to /dev/urandom. and after more arguments, more formally argued: | Let's imagine we have a radioactive decay card, and we run it's | outputs through a software de-skewing function to hide biases due to | detector dead time and the expected distribution being different to | that which we desire. Say we're convinced that the de-skewing | function makes each bit of output uniformly distributed, to the extent | that we're confident in using it's outputs as a OTP. | | Now what Yarrow-160 does is it takes k bits of OTP output, resets a 64 | bit counter (C) to 0 and uses counter mode from there. You can't get | at the OTP outputs. | | | Now my issue is if I had access to the OTP I could have had as many | uniformly distributed bits as I wanted subject to their rate of | production. But going through the Yarrow-160 output function I can | never get information theoretic security. If I use it niavely I'll | get at best 2^160 bits of security if no reseeds occur, and I may | share these bits across multiple applications and with other users. | | Even if I have a mechanism to wait for a reseed after each output and | reserve that output for me, I get at best R*2^160 bits for R reseeds, | rather than the 2^{R*160} bits I wanted. | | Note the yarrow-160 API and design doesn't allow me to wait for and | reserve the output of a reseed in a multi-tasking OS -- /dev/random | does. ====================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 7:46: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id DCA2A37B43C for ; Sat, 26 Aug 2000 07:45:56 -0700 (PDT) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id KAA27640; Sat, 26 Aug 2000 10:45:55 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Sat, 26 Aug 2000 10:45:55 -0400 (EDT) From: "Brandon D. Valentine" To: Thomas Stromberg Cc: FreeBSD-CURRENT Subject: Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 26 Aug 2000, Thomas Stromberg wrote: >Hopefully this thread will save the next poor soul who tries this. Indeed. >Now the question is, what ATA-100 RAID solutions are there that are fully >supported? I'd guess the Promise board, but the last time I guessed >(err.. last week), I got a supported chipset with an unsupported feature >:) Currently the only IDE RAID cards supported are the 3Ware ones. For a list of supported RAID hardware one should always check: http://people.freebsd.org/~msmith/RAID/index.html >Just so I don't go do anything stupid, anyone secretly working on >drivers for this behind our backs, or is it as good as junk? You could turn off the fake RAID in the BIOS, use it strictly as an ATA100 controller and use the vinum software RAID driver to do some real RAID. Info on that is available from: http://www.vinumvm.org/ Another alternative, and the one that I have been using, is to order one of the Arena series external IDE RAID boxes from raidweb.com. They're pretty cool little pieces of hardware. I'm also using IBM 75GXPs with mine. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 8:33: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 8C1BF37B423; Sat, 26 Aug 2000 08:32:53 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13Shwn-000JAn-00; Sat, 26 Aug 2000 17:32:42 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7QFXUp25804; Sat, 26 Aug 2000 17:33:30 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008261533.e7QFXUp25804@grimreaper.grondar.za> To: Adam Back Cc: mark@grondar.za, current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org Subject: Re: yarrow & /dev/random References: <200008261459.JAA05375@cypherspace.org> In-Reply-To: <200008261459.JAA05375@cypherspace.org> ; from Adam Back "Sat, 26 Aug 2000 09:59:48 EST." Date: Sat, 26 Aug 2000 17:33:29 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You really can't use yarrow to implement /dev/random as it is. Even > waiting for reseeds doesn't cut it. The issue is that everything goes > through the yarrow output function, which restricts yarrow to offering > computational security with at worst 2^n work factor to break because > it offers known plaintext the 0 block as the first output is E_k( 0 ). OK; what then? The existing MD5 based system is very attackable, and protects itself very poorly. My approach to this (and this is the first time I am stating this in such a wide forum) is to provide another device (say /dev/srandom) for folk who want to do their own randomness processing. This would provide a structure of data including the entropy, the system nanotime and the source, so the user can do his own hard work when he needs to, and the folk simply needing a stream of "good" random numbers can do do from /dev/random. > > I am against the blocking model, as I believe that it goes against > > what Yarrow is trying to do. If the Yarrow authors argued otherwise, > > I'd listen. > > Niels and John Kelsey were against it to initially, on the grounds > that computational security (160 bits -- or whatever the parameter is > with the ciphers you have plugged in) is in fact "good enough" in > practice even for 1024 bit RSA key generation. > > (The argument has some validity; in practice a brute force attack > against RSA 1024 takes significantly less than 2^160 operations, > though the memory requirements are higher). I've heard that that is down to like 2^90 or a lot less... > However it is not fair to impose that view on someone. People can > have legitmate reasons to need more entropy. Another very concrete > example is: say someone is using a yarrow-160 (3DES and SHA1) > implementation and they want to use an AES cipher with a 256 bit key > -- without the /dev/random API, you can't get 256 bit security, with > it you can. Sooner or later someone is going to come up with a requirement for M-bit randoness on Yarrow-N, where M > N. What then? > OTPs and some algorithms offer information theoretic security, or you > may be using a larger key space symmetric construct than the yarrow > output size (using 256 doesn't solve that -- then they want a 512 bit > key). Worse people may already be using /dev/random for these > assumptions, so you risk breaking existing code's security by > replacing /dev/random with yarrow. I can't help broken applications, but if we provide a better API, and get folk to use it, that everyone wins. > > If I construct a specific hash function, is this still a problem? > > No. Note my other comments on list about CBC-MAC are confused -- I > misread your code. It appears to be a keyless hash function, and as > Joeren noted it has some similarities to Davies-Meyer, but it's not > quite the same for the reasons he noted. I fixed that and made it Davies-Meyer. http://people.freebsd.org/~markm/randomdev.patch > The main argument is against not using constructs which haven't > received lots of peer-review -- most crypto constructs are very > fragile to small design changes. Agreed. > | So given that, it doesn't seem quite fair to pull the rug from under > | /dev/random users and replace it with a PRNG with quite different > | security assumptions. Users would have similar reasons to be upset if > | someone removed their /dev/random and symlinked it to /dev/urandom. ...unless we can somehow get /dev/random to be "secure enough". > and after more arguments, more formally argued: : : > | Even if I have a mechanism to wait for a reseed after each output and > | reserve that output for me, I get at best R*2^160 bits for R reseeds, > | rather than the 2^{R*160} bits I wanted. > | > | Note the yarrow-160 API and design doesn't allow me to wait for and > | reserve the output of a reseed in a multi-tasking OS -- /dev/random > | does. Hmm. Most convincing argument I have heard so far. How much of a practical difference does that make, though. With ultra-conservative entropy estimation (eg, I am stirring in nanotime(9), but not making any randomness estimates from it, so the device is getting some "free" entropy.)? PC's are pretty low-entropy devices; users who need lots of random bits (as opposed to a steady supply of random numbers) are arguably going to need to go to extraordinary lengths to get them; their own statistical analysis is almost certainly going to be required. Software that I am (partially) aware of that uses /dev/random usually doesn't trust it too much anyway (qv PGP) (OpenSSH is an exception), and programmers often come up with elabrate schemes to compel the os to provide their requisite bits. Folk who are generating OTP's for anything other than personal use would be insane to use anything other than custom hardware such as the ubiquitous geiger-counter or zener noise generator. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 9:41: 8 2000 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 7B0D137B42C; Sat, 26 Aug 2000 09:41:05 -0700 (PDT) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id SAA91784; Sat, 26 Aug 2000 18:41:02 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <200008261641.SAA91784@freebsd.dk> Subject: Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions.. In-Reply-To: from Thomas Stromberg at "Aug 26, 2000 08:47:51 am" To: tstromberg@rtci.com (Thomas Stromberg) Date: Sat, 26 Aug 2000 18:41:01 +0200 (CEST) Cc: msmith@freebsd.org (Mike Smith), freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Thomas Stromberg wrote: > On Sat, 26 Aug 2000, Mike Smith wrote: > > > This is not an "IDE RAID" controller. It's an IDE controller with some > > lame "RAID" software in the BIOS. We don't support this. > > Hopefully this thread will save the next poor soul who tries this. > > Just to put the final nail in the coffin.. I went ahead and > installed on an old WDMA2 drive of mine, and put /var and /usr on what > hopefully was a striped RAID. Well, I pulled the second drive > offline, and.. it still booted up beautifully. So the striping in bios > on the HPT-370 is indeed meaningless. C'est la vie. > > Now the question is, what ATA-100 RAID solutions are there that are fully > supported? I'd guess the Promise board, but the last time I guessed > (err.. last week), I got a supported chipset with an unsupported feature > :) Well, both the HPT270 and the Promise Fasttrak "RAID" gimmicks are SW in the BIOS, so there is no HW to support. You could use vinum to get the exact same behavior... > Just so I don't go do anything stupid, anyone secretly working on > drivers for this behind our backs, or is it as good as junk? He, I've got a patch submitted that should work with the promise ie it does the RAID stuff in the driver and reads the RAID setup from the BIOS/disks. I've yet to find out how/where HPT stores their info, but in case I find out, I will probably add support for these "BIOS RAID" setups... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 12: 5:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp.email.msn.com (cpimssmtpu02.email.msn.com [207.46.181.18]) by hub.freebsd.org (Postfix) with ESMTP id 5A80837B43C for ; Sat, 26 Aug 2000 12:05:32 -0700 (PDT) Received: from lando - 63.15.0.188 by email.msn.com with Microsoft SMTPSVC; Sat, 26 Aug 2000 12:04:52 -0700 From: "James Johnson" To: Subject: break in usr.bin/kdump Date: Sat, 26 Aug 2000 12:04:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I've been tracking -CURRENT for a while.. Whenever I attempt to build the world I get the following break: # make buildworld ===> usr.bin/kdump cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../. . -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include > ioctl.c In file included from :67: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../. . -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:97: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition In file included from ioctl.c:37: /usr/obj/usr/src/i386/usr/include/dev/usb/rio500_usb.h:35: redefinition of `struct RioCommand' *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 # I do own one of the rio500 devices and have installed the rio500 audio package in the past (have since cleaned it..) I usually just comment out struct RioCommand from include/dev/usb/rio500_usb.h this goes away, feeling this was a common break but since it has been reoccuring I feel that I should mention it. Anyone have ideas to figure out why this is occuring on only this box? Thanks -- James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 12:10: 3 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (beachchick.freebsd.dk [212.242.34.253]) by hub.freebsd.org (Postfix) with ESMTP id 79AEA37B42C for ; Sat, 26 Aug 2000 12:09:58 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.0/8.9.3) with ESMTP id e7QJ9vN00487 for ; Sat, 26 Aug 2000 21:09:57 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-current@FreeBSD.ORG Subject: official devfs patch for review In-Reply-To: Your message of "Sat, 26 Aug 2000 20:22:02 +0700." Date: Sat, 26 Aug 2000 21:09:57 +0200 Message-ID: <485.967316997@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There is an official DEVFS patch at http://phk.freebsd.dk/patch/devfs.patch This incorporates the functional bits from the patch Boris posted here earlier as I've been able to extract them from his patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 12:31: 2 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherspace.org (modemcable228.178-201-24.mtl.mc.videotron.net [24.201.178.228]) by hub.freebsd.org (Postfix) with ESMTP id 3CB9437B422; Sat, 26 Aug 2000 12:30:49 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id PAA05849; Sat, 26 Aug 2000 15:32:38 -0500 Date: Sat, 26 Aug 2000 15:32:38 -0500 Message-Id: <200008262032.PAA05849@cypherspace.org> From: Adam Back To: mark@grondar.za Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org In-reply-to: <200008261533.e7QFXUp25804@grimreaper.grondar.za> (message from Mark Murray on Sat, 26 Aug 2000 17:33:29 +0200) Subject: Re: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark writes: > > You really can't use yarrow to implement /dev/random as it is. > > [...] > > OK; what then? The existing MD5 based system is very attackable, and > protects itself very poorly. My argument for linux is leave it as it is, and see if we can persuade the yarrow authors to change yarrow so it does export a /dev/random compatible API. Isn't freeBSD using the same Ted T'so code? It's "good enough" IMO that there is no rush to change it until we can preserve it's API semantics. The linux version has been switched to SHA1, though IMO Dobbertin's pseudo collision attack on MD5 isn't broken in any practical way for this purpose. People are just moving away from MD5 in case someone manages to extend this attacks as conservative design. > My approach to this (and this is the first time I am stating this in > such a wide forum) is to provide another device (say /dev/srandom) for > folk who want to do their own randomness processing. This would provide > a structure of data including the entropy, the system nanotime and the > source, so the user can do his own hard work when he needs to, and the > folk simply needing a stream of "good" random numbers can do do from > /dev/random. You don't want people to have work hard -- they just want to retain the /dev/random API which works and has understood semantics. > > However it is not fair to impose that view on someone. People can > > have legitmate reasons to need more entropy. Another very concrete > > example is: say someone is using a yarrow-160 (3DES and SHA1) > > implementation and they want to use an AES cipher with a 256 bit key > > -- without the /dev/random API, you can't get 256 bit security, with > > it you can. > > Sooner or later someone is going to come up with a requirement for > M-bit randoness on Yarrow-N, where M > N. What then? You could use the /dev/random API if your entropy requirements are greater than the output size of /dev/urandom (implemented with yarrow or otherwise). With the API we could add a call to ask the device what it's output block size is. And/or we could define a value exported from random.h for the bit strength of /dev/urandom, though that risks missing changes over time. > > OTPs and some algorithms offer information theoretic security, or you > > may be using a larger key space symmetric construct than the yarrow > > output size (using 256 doesn't solve that -- then they want a 512 bit > > key). Worse people may already be using /dev/random for these > > assumptions, so you risk breaking existing code's security by > > replacing /dev/random with yarrow. > > I can't help broken applications, but if we provide a better API, and > get folk to use it, that everyone wins. The applications aren't broken. They are using the advertised /dev/random API, and some people are proposing to pull the rug out of under them and effectively symlink /dev/random to /dev/urandom. As they may have relied on better than /dev/urandom for security, you may break the security of their application. > > > If I construct a specific hash function, is this still a problem? > > > > No. Note my other comments on list about CBC-MAC are confused -- I > > misread your code. It appears to be a keyless hash function, and as > > Joeren noted it has some similarities to Davies-Meyer, but it's not > > quite the same for the reasons he noted. > > I fixed that and made it Davies-Meyer. > http://people.freebsd.org/~markm/randomdev.patch Looks good. API comment: you might want a hash_final implemented as a memcpy because some hashes you swap in have this phase (MD5, SHA1 mix in the length as a last step). Also other hash APIs often don't have an hash_init which takes the magic constants as an argument. As you're not using any constants (and relying on 0 as the magic constant / Davies-Meyer IV) you could remove that. Then you'd have the classic MD5 API which would make plugging other hashes in easy. Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit plaintext with a 256 bit key as a virtual 256 bit block cipher operation. I suspect the result will be weaker than 256 bits because of the internal structure of BF-CBC. If you want 256 bit hash (and it is desirable for AES) you could use what Joeren suggested: abrest Davies-Meyer, and a 128 bit block cipher. Or we could wait for the AES hash mode. Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 pseudo 256 bit block cipher Davies-Meyer performance wise, because of the key agility. > > | So given that, it doesn't seem quite fair to pull the rug from under > > | /dev/random users and replace it with a PRNG with quite different > > | security assumptions. Users would have similar reasons to be upset if > > | someone removed their /dev/random and symlinked it to /dev/urandom. > > ...unless we can somehow get /dev/random to be "secure enough". I think we have an obligation to attempt to make it no less secure than the current /dev/random; and of course we should try to make it as secure as we can in general. See below for my ideas of how you might do that. > > and after more arguments, more formally argued: > : > : > > | Even if I have a mechanism to wait for a reseed after each output and > > | reserve that output for me, I get at best R*2^160 bits for R reseeds, > > | rather than the 2^{R*160} bits I wanted. > > | > > | Note the yarrow-160 API and design doesn't allow me to wait for and > > | reserve the output of a reseed in a multi-tasking OS -- /dev/random > > | does. > > Hmm. Most convincing argument I have heard so far. How much of a > practical difference does that make, though. With ultra-conservative > entropy estimation (eg, I am stirring in nanotime(9), but not making > any randomness estimates from it, so the device is getting some "free" > entropy.)? The quality of the de-skewing function, conservative assumptions about distribution of entropy across samples and conservativeness of the entropy estimates don't help. It's the yarrow output function which blows it. The solution as I see it is to modify yarrow to bypass the yarrow output function and grab raw de-skewing function output for /dev/random output. You'd also want to do what John Kelsey was suggesting and XOR the bypassed de-skewing function output with /dev/urandom output as an additional safety measure. But let's get this put in yarrow-160-a, rather than making our own variant -- then we can say we are using stock yarrow, and other yarrow users benefit. > Folk who are generating OTP's for anything other than personal use > would be insane to use anything other than custom hardware such as > the ubiquitous geiger-counter or zener noise generator. Even those hardware devices have biases and rely on software de-skewing functions. Provided we can do a good job of de-skewing, entropy estimation and make good assumptions about entropy distribution I see no inherent reason why we can't generate OTP quality randomness from generic PC hardware. There is real entropy in that mouse swirl and keyboard input. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 13:20:20 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 640B237B43F; Sat, 26 Aug 2000 13:20:19 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA53026; Sat, 26 Aug 2000 13:20:19 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 26 Aug 2000 13:20:19 -0700 (PDT) From: Kris Kennaway To: Alexey Zelkin Cc: current@FreeBSD.org Subject: Re: make buildworld (4->5) failed In-Reply-To: <20000826142042.A67678@ark.cris.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 26 Aug 2000, Alexey Zelkin wrote: > hi, > > Just experienced on 4.0-RELEASE and 4.1-STABLE (two days ago) following > error when tried to build current world. This was already fixed a few days ago. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 13:35:36 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 3365E37B422; Sat, 26 Aug 2000 13:35:23 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13SmfW-000MeD-00; Sat, 26 Aug 2000 22:35:10 +0200 Received: from grimreaper.grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.0/8.11.0) with ESMTP id e7QKZsp26706; Sat, 26 Aug 2000 22:35:54 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200008262035.e7QKZsp26706@grimreaper.grondar.za> To: Adam Back Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org Subject: Re: yarrow & /dev/random References: <200008262032.PAA05849@cypherspace.org> In-Reply-To: <200008262032.PAA05849@cypherspace.org> ; from Adam Back "Sat, 26 Aug 2000 15:32:38 EST." Date: Sat, 26 Aug 2000 22:35:54 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > OK; what then? The existing MD5 based system is very attackable, and > > protects itself very poorly. > > My argument for linux is leave it as it is, and see if we can persuade > the yarrow authors to change yarrow so it does export a /dev/random > compatible API. If that happened, I'd follow suit. > Isn't freeBSD using the same Ted T'so code? It's "good enough" IMO > that there is no rush to change it until we can preserve it's API > semantics. The linux version has been switched to SHA1, though IMO > Dobbertin's pseudo collision attack on MD5 isn't broken in any > practical way for this purpose. People are just moving away from MD5 > in case someone manages to extend this attacks as conservative design. FreeBSD is using an earlier version of T'so's code; I beiieve he improved it later, but it has no (or little) backtracking protection, and can be too easily attacked "from both sides". > > My approach to this (and this is the first time I am stating this in > > such a wide forum) is to provide another device (say /dev/srandom) for > > folk who want to do their own randomness processing. This would provide > > a structure of data including the entropy, the system nanotime and the > > source, so the user can do his own hard work when he needs to, and the > > folk simply needing a stream of "good" random numbers can do do from > > /dev/random. > > You don't want people to have work hard -- they just want to retain > the /dev/random API which works and has understood semantics. Reading random events from the kernel to stir into a pot is not too far off what I am asking folk to do; it would be better to ask them to read N bits out of /dev/random, but N bits aren't always available; we have to compromise. Raw data is a pretty "pure" compromaise. > > Sooner or later someone is going to come up with a requirement for > > M-bit randoness on Yarrow-N, where M > N. What then? > > You could use the /dev/random API if your entropy requirements are > greater than the output size of /dev/urandom (implemented with yarrow > or otherwise). With the API we could add a call to ask the device > what it's output block size is. And/or we could define a value > exported from random.h for the bit strength of /dev/urandom, though > that risks missing changes over time. Hmm. sounds like we need a way of forcing some entropy back into /dev/random, or doing things with reseeds. Lets say we have a zener noise generator and a geiger counter, but these are connected to a device that the kernel (and thus /dev/random) cannot "harvest" (like say an async line or at the end of an SSH connection), I have make the current FreeBSD accept that input (in 8-byte chunks) followed by an explicit reseed. This is not a perfect solution to anything, but a user with high entropy needs has a simple method of "pumping" the driver, and as long as he reads at the same spead as he writes, he gets his deskewing. > > I can't help broken applications, but if we provide a better API, and > > get folk to use it, that everyone wins. > > The applications aren't broken. They are using the advertised > /dev/random API, and some people are proposing to pull the rug out of > under them and effectively symlink /dev/random to /dev/urandom. I'm trying to improve, not pull the rug :-). > As they may have relied on better than /dev/urandom for security, you > may break the security of their application. This is what I'm counting on a) yarrow and b) better harvesting for. > > I fixed that and made it Davies-Meyer. > > http://people.freebsd.org/~markm/randomdev.patch > > Looks good. API comment: you might want a hash_final implemented as a > memcpy because some hashes you swap in have this phase (MD5, SHA1 mix > in the length as a last step). Also other hash APIs often don't have > an hash_init which takes the magic constants as an argument. As > you're not using any constants (and relying on 0 as the magic constant > / Davies-Meyer IV) you could remove that. Then you'd have the classic > MD5 API which would make plugging other hashes in easy. Sounds sensible. Will do. > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > plaintext with a 256 bit key as a virtual 256 bit block cipher > operation. I suspect the result will be weaker than 256 bits because > of the internal structure of BF-CBC. I'm not sure I understand this? > If you want 256 bit hash (and it is desirable for AES) you could use > what Joeren suggested: abrest Davies-Meyer, and a 128 bit block > cipher. Or we could wait for the AES hash mode. That is doable; at the moment I only have SHA1, MD5, DES and Blowfish available in FreeBSD's kernel crypto API; I'd need a lot more evidence before I feen I can pull in any more :-) > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > the key agility. Understood :-). See above. > > ...unless we can somehow get /dev/random to be "secure enough". > > I think we have an obligation to attempt to make it no less secure > than the current /dev/random; and of course we should try to make it > as secure as we can in general. See below for my ideas of how you > might do that. :-) I am of the opinion that a well-implemented Yarrow with lots of entropy-harvesting to back it up can be as good as a simple hash-based single-pool bit distiller. My argument is weakening, though. > The quality of the de-skewing function, conservative assumptions about > distribution of entropy across samples and conservativeness of the > entropy estimates don't help. It's the yarrow output function which > blows it. Yeah; that monotonically-increasing counter bothers me slightly. > The solution as I see it is to modify yarrow to bypass the yarrow > output function and grab raw de-skewing function output for > /dev/random output. You'd also want to do what John Kelsey was > suggesting and XOR the bypassed de-skewing function output with > /dev/urandom output as an additional safety measure. I'll look that up; It sounds like quite a departure from yarrow to me though; that makes me nervous. > But let's get this put in yarrow-160-a, rather than making our own > variant -- then we can say we are using stock yarrow, and other yarrow > users benefit. Ok - as long as "classic" yarrow has it. > > Folk who are generating OTP's for anything other than personal use > > would be insane to use anything other than custom hardware such as > > the ubiquitous geiger-counter or zener noise generator. > > Even those hardware devices have biases and rely on software > de-skewing functions. Provided we can do a good job of de-skewing, That stuff can be harvested into yarrow, sure, but... > entropy estimation and make good assumptions about entropy > distribution I see no inherent reason why we can't generate OTP > quality randomness from generic PC hardware. There is real entropy in > that mouse swirl and keyboard input. ...there may not be a suitable monkey at the keyboard. What about a server in an unattended colo? MHO - hardware RNG. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 15: 3:44 2000 Delivered-To: freebsd-current@freebsd.org Received: from spock.org (cm-24-92-52-10.nycap.rr.com [24.92.52.10]) by hub.freebsd.org (Postfix) with ESMTP id 4DAF137B43C; Sat, 26 Aug 2000 15:03:33 -0700 (PDT) Received: (from jon@localhost) by spock.org serial EF600Q3T-B7F; Sat, 26 Aug 2000 18:03:21 -0400 (EDT) (envelope-from jon) Date: Sat, 26 Aug 2000 18:03:21 -0400 From: Jonathan Chen To: Visigoth Cc: current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) Message-ID: <20000826180321.A1703@spock.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from visigoth@telemere.net on Wed, Aug 23, 2000 at 01:51:16PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote: > Sorry for the cross post but.... > > Would it be possible to revert the DPT commits made by peter on > Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the > dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have > production machines that need worlds built for some other updates as > well.. I would be happy to install a -CURRENT machine and help debug > until it works, but for right now, there is NO DPT support in -STABLE for > the DPT PM3334UW. I had a pr started, but haven't been able to get any > response from the current maintainer. > > I am going to install a -CURRENT machine with a DPT in it and > start the process of working on the issue, but it would be nice if we can > keep -STABLE stable... ;) I just updated on my -STABLE machine and ran into the same exact problem. I also have on the machine SMP with APIC. The fix for this problem is simple: Index: dpt_pci.c =================================================================== RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v retrieving revision 1.17.2.1 diff -u -r1.17.2.1 dpt_pci.c --- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1 +++ dpt_pci.c 2000/08/26 21:40:26 @@ -106,7 +106,7 @@ } rid = 0; - irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE); + irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); if (!irq) { device_printf(dev, "No irq?!\n"); error = ENOMEM; (Everybody in unison, say "Doh!") Since this didn't change in the past two months, I'm guessing this was caused by somebody else futzing with APIC. In any case, I don't see why the DPT card shouldn't be allowed to share IRQs, and I'm now running the latest -STABLE on my DPT card. PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;) -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\ Jonathan Chen jon@spock.org /_/// <____) No electrons were harmed during production of this message (____> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 15:22:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186]) by hub.freebsd.org (Postfix) with ESMTP id B8A0237B42C; Sat, 26 Aug 2000 15:22:21 -0700 (PDT) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.11.0/8.9.3) with ESMTP id e7QMMEG25902; Sat, 26 Aug 2000 15:22:14 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200008262222.e7QMMEG25902@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jonathan Chen Cc: Visigoth , current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-Reply-To: <20000826180321.A1703@spock.org> Date: Sat, 26 Aug 2000 15:22:14 -0700 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jonathan Chen wrote: > On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote: > > > Sorry for the cross post but.... > > > > Would it be possible to revert the DPT commits made by peter on > > Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the > > dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have > > production machines that need worlds built for some other updates as > > well.. I would be happy to install a -CURRENT machine and help debug > > until it works, but for right now, there is NO DPT support in -STABLE for > > the DPT PM3334UW. I had a pr started, but haven't been able to get any > > response from the current maintainer. > > > > I am going to install a -CURRENT machine with a DPT in it and > > start the process of working on the issue, but it would be nice if we can > > keep -STABLE stable... ;) > > I just updated on my -STABLE machine and ran into the same exact problem. > I also have on the machine SMP with APIC. The fix for this problem is > simple: Argh! I have committed this now, both in -current and RELENG_4. Thanks! > Index: dpt_pci.c > =================================================================== > RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v > retrieving revision 1.17.2.1 > diff -u -r1.17.2.1 dpt_pci.c > --- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1 > +++ dpt_pci.c 2000/08/26 21:40:26 > @@ -106,7 +106,7 @@ > } > > rid = 0; > - irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE); > + irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE | RF_SHAREABLE); > if (!irq) { > device_printf(dev, "No irq?!\n"); > error = ENOMEM; > > (Everybody in unison, say "Doh!") > Since this didn't change in the past two months, I'm guessing this was > caused by somebody else futzing with APIC. In any case, I don't see why > the DPT card shouldn't be allowed to share IRQs, and I'm now running the > latest -STABLE on my DPT card. > > PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;) > > -- > (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) > \\\_\ Jonathan Chen jon@spock.org /_/// > <____) No electrons were harmed during production of this message (____> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 15:48: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherspace.org (modemcable228.178-201-24.mtl.mc.videotron.net [24.201.178.228]) by hub.freebsd.org (Postfix) with ESMTP id 95CBC37B423; Sat, 26 Aug 2000 15:47:58 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id SAA06044; Sat, 26 Aug 2000 18:49:56 -0500 Date: Sat, 26 Aug 2000 18:49:56 -0500 Message-Id: <200008262349.SAA06044@cypherspace.org> From: Adam Back To: mark@grondar.za Cc: current@freebsd.org, kris@freebsd.org, jeroen@vangelderen.org In-reply-to: <200008262035.e7QKZsp26706@grimreaper.grondar.za> (message from Mark Murray on Sat, 26 Aug 2000 22:35:54 +0200) Subject: Re: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark writes: > [...] > FreeBSD is using an earlier version of T'so's code; I beiieve he > improved it later, but it has no (or little) backtracking protection, > and can be too easily attacked "from both sides". OK, I agree that that's an area where yarrow offers better protection. But it's not like Ted's code is broken or anything. We would break things using /dev/random by switching as is to yarrow, so this is why I don't like it: we're trying to improve things (Yarrows protection aginst the attacks you describe), but in order to do this we're doing some other damage. We should at least do no damage: we're improving one thing and breaking something else. > > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > > plaintext with a 256 bit key as a virtual 256 bit block cipher > > operation. I suspect the result will be weaker than 256 bits because > > of the internal structure of BF-CBC. > > I'm not sure I understand this? Well consider the behavior of the BF-CBC-256 construct as a block cipher. If we encrypt: X1 = (x1 || x2 || x3 || x4) where |x| is blowfish block size (64 bits) and |X1| is BF-CBC-256 pseudo-blocksize (256 bits). The encryption of X1 and X1' = (x1 || x2 || x3 || x4') are going to be the same in all blocks except the last: Y1 = (y1||y2||y3||y4) = E( X1 ) Y1' = (y1||y2||y3||y4') = E( X1' ) a block cipher would be considered broken if it exhibited that behavior. I don't immediately see how to transfer that to weakening the Davies-Meyer hash built using it -- but it certainly violates the stated requirements for the strength of the underlying block cipher. Probably you can do some kind of 2^64 work factor precomputation attack something. Bear in mind anything significantly short of 2^256 operations allowing you to compute hash collisions is going to be considered a break, and that gives quite a lot of scope for precomputation against CBC on a smaller block cipher given the hash output size. > > > ...unless we can somehow get /dev/random to be "secure enough". > > > > I think we have an obligation to attempt to make it no less secure > > than the current /dev/random; and of course we should try to make it > > as secure as we can in general. See below for my ideas of how you > > might do that. > > :-) I am of the opinion that a well-implemented Yarrow with lots of > entropy-harvesting to back it up can be as good as a simple hash-based > single-pool bit distiller. My argument is weakening, though. The distiller needs looking at -- it seems to be a bit hazy due to the unknown spread of correlations between input samples, but even if you presume god's distiller, getting outputs via the yarrow output function is going to destroy any hopes of getting information theoretic security. > > The solution as I see it is to modify yarrow to bypass the yarrow > > output function and grab raw de-skewing function output for > > /dev/random output. You'd also want to do what John Kelsey was > > suggesting and XOR the bypassed de-skewing function output with > > /dev/urandom output as an additional safety measure. > > I'll look that up; It sounds like quite a departure from yarrow to > me though; that makes me nervous. Well you leave most of yarrow alone, you just add the ability to reserve de-skewing function outputs for /dev/random. /dev/urandom still goes through the normal yarrow output function. > > But let's get this put in yarrow-160-a, rather than making our own > > variant -- then we can say we are using stock yarrow, and other yarrow > > users benefit. > > Ok - as long as "classic" yarrow has it. I agree, we need the peer review. > > entropy estimation and make good assumptions about entropy > > distribution I see no inherent reason why we can't generate OTP > > quality randomness from generic PC hardware. There is real entropy in > > that mouse swirl and keyboard input. > > ...there may not be a suitable monkey at the keyboard. What about > a server in an unattended colo? MHO - hardware RNG. Unattended servers are a problem alright. One thing you can do is if your server has any private keys -- and it generally will have if it's doing crypto -- is mix the private key into the random pool along with the curren time. As the attacker doesn't know your private key (if he does it's game over anyway), you get a /dev/urandom which is secure. (If you don't like the `feel' of putting your private key into /dev/urandom as a sample, run it through a one-way hash function first). The other thing you can do is mix in encrypted IVs people connecting to your server send you -- for example SSL, SSH, and PGP and so on tend to do this. It can't hurt because you're only mixing, and you can't destroy entropy with a good mixing function; and if you presume the collection of people who connect to you aren't colluding it helps. (If there is only one person communicating with you, it doesn't matter anyway, because they have their own plaintext.) We should encourage people to do these two things. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 16:50:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6FA2437B422; Sat, 26 Aug 2000 16:50:51 -0700 (PDT) Date: Sat, 26 Aug 2000 19:50:50 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Nickolay Dudorov Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/secure/lib/libcrypto Makefile Makefile.inc In-Reply-To: <200008240821.e7O8LSd37977@wint.itfs.nsk.su> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 24 Aug 2000, Nickolay Dudorov wrote: > I usually run 'make -j32 buildworld' on my current > system. After this commit I can not do this. The next patch > permits to use '-j32' again. Since it can't really break things to do so, I added it :) Thanks. > N.Dudorov -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 17:12:35 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 11FF537B424; Sat, 26 Aug 2000 17:12:28 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 89BAC28C4A; Sun, 27 Aug 2000 07:12:25 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 7F29C28703; Sun, 27 Aug 2000 07:12:25 +0700 (ALMST) Date: Sun, 27 Aug 2000 07:12:25 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: PATCH: devfs mkIII test & review please. In-Reply-To: <84513.966631292@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 18 Aug 2000, Poul-Henning Kamp wrote: > Missing: > Rename > Subdirs. > Close some race conditions using guaranteed atomic operations. > Mountoption (ro ?) to prevent new devices from appearing in an instance. > All uses of cdevsw_add() needs to be use devfs_clone() instead. How should 3rd party KLDs implement cloning function ? For now it seems to be impossible to use a single binary for DEVFS and non-DEVFS case. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 17:23:41 2000 Delivered-To: freebsd-current@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 313D737B422; Sat, 26 Aug 2000 17:23:29 -0700 (PDT) Date: Sat, 26 Aug 2000 20:23:28 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: John Polstra Cc: current@freebsd.org, bright@wintelcom.net Subject: Re: panic: reducing sbsize: lost count, uid = 1001 In-Reply-To: <200008232338.QAA24071@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If this is a problem with sbsize, this should take care of any possibility ever of there being a problem... Index: kern/kern_proc.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/kern_proc.c,v retrieving revision 1.69 diff -u -r1.69 kern_proc.c --- kern/kern_proc.c 2000/07/04 11:25:22 1.69 +++ kern/kern_proc.c 2000/08/26 23:50:40 @@ -190,25 +190,33 @@ * Change the total socket buffer size a user has used. */ int -chgsbsize(uid, diff, max) +chgsbsize(uid, hiwat, to, max) uid_t uid; - rlim_t diff; + u_long *hiwat; + u_long to; rlim_t max; { struct uidinfo *uip; + rlim_t diff; + int s; uip = uifind(uid); - if (diff < 0) - KASSERT(uip != NULL, ("reducing sbsize: lost count, uid = %d", uid)); + KASSERT(to < *hiwat && uip != NULL, + ("reducing sbsize: lost count, uid = %d", uid)); if (uip == NULL) uip = uicreate(uid); + s = splnet(); + diff = to - *hiwat; /* don't allow them to exceed max, but allow subtraction */ if (diff > 0 && uip->ui_sbsize + diff > max) { (void)uifree(uip); + splx(s); return (0); } uip->ui_sbsize += diff; + *hiwat = to; (void)uifree(uip); + splx(s); return (1); } Index: kern/uipc_socket2.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.61 diff -u -r1.61 uipc_socket2.c --- kern/uipc_socket2.c 2000/07/31 08:23:43 1.61 +++ kern/uipc_socket2.c 2000/08/26 23:36:25 @@ -420,7 +420,6 @@ struct socket *so; struct proc *p; { - rlim_t delta; /* * p will only be NULL when we're in an interrupt @@ -428,8 +427,7 @@ */ if ((u_quad_t)cc > (u_quad_t)sb_max * MCLBYTES / (MSIZE + MCLBYTES)) return (0); - delta = (rlim_t)cc - sb->sb_hiwat; - if (p && !chgsbsize(so->so_cred->cr_uid, delta, + if (p && !chgsbsize(so->so_cred->cr_uid, &sb->sb_hiwat, cc, p->p_rlimit[RLIMIT_SBSIZE].rlim_cur)) { return (0); } @@ -450,8 +448,8 @@ { sbflush(sb); - (void)chgsbsize(so->so_cred->cr_uid, -(rlim_t)sb->sb_hiwat, RLIM_INFINITY); - sb->sb_hiwat = sb->sb_mbmax = 0; + (void)chgsbsize(so->so_cred->cr_uid, &sb->sb_hiwat, 0, RLIM_INFINITY); + sb->sb_mbmax = 0; } /* Index: kern/uipc_socket.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.80 diff -u -r1.80 uipc_socket.c --- kern/uipc_socket.c 2000/08/07 17:52:08 1.80 +++ kern/uipc_socket.c 2000/08/26 23:37:00 @@ -191,10 +191,10 @@ so->so_gencnt = ++so_gencnt; if (so->so_rcv.sb_hiwat) (void)chgsbsize(so->so_cred->cr_uid, - -(rlim_t)so->so_rcv.sb_hiwat, RLIM_INFINITY); + &so->so_rcv.sb_hiwat, 0, RLIM_INFINITY); if (so->so_snd.sb_hiwat) (void)chgsbsize(so->so_cred->cr_uid, - -(rlim_t)so->so_snd.sb_hiwat, RLIM_INFINITY); + &so->so_snd.sb_hiwat, 0, RLIM_INFINITY); if (so->so_accf != NULL) { if (so->so_accf->so_accept_filter != NULL && so->so_accf->so_accept_filter->accf_destroy != NULL) { Index: kern/uipc_usrreq.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/uipc_usrreq.c,v retrieving revision 1.58 diff -u -r1.58 uipc_usrreq.c --- kern/uipc_usrreq.c 2000/07/11 22:07:43 1.58 +++ kern/uipc_usrreq.c 2000/08/26 23:52:24 @@ -217,6 +217,7 @@ { struct unpcb *unp = sotounpcb(so); struct socket *so2; + u_long newhiwat; if (unp == 0) return EINVAL; @@ -235,9 +236,10 @@ */ so2->so_snd.sb_mbmax += unp->unp_mbcnt - so->so_rcv.sb_mbcnt; unp->unp_mbcnt = so->so_rcv.sb_mbcnt; - so2->so_snd.sb_hiwat += unp->unp_cc - so->so_rcv.sb_cc; - (void)chgsbsize(so2->so_cred->cr_uid, - (rlim_t)unp->unp_cc - so->so_rcv.sb_cc, RLIM_INFINITY); + newhiwat = so2->so_snd.sb_hiwat + unp->unp_cc - + so->so_rcv.sb_cc; + (void)chgsbsize(so2->so_cred->cr_uid, &so2->so_snd.sb_hiwat, + newhiwat, RLIM_INFINITY); unp->unp_cc = so->so_rcv.sb_cc; sowwakeup(so2); break; @@ -257,6 +259,7 @@ int error = 0; struct unpcb *unp = sotounpcb(so); struct socket *so2; + u_long newhiwat; if (unp == 0) { error = EINVAL; @@ -342,10 +345,10 @@ so->so_snd.sb_mbmax -= so2->so_rcv.sb_mbcnt - unp->unp_conn->unp_mbcnt; unp->unp_conn->unp_mbcnt = so2->so_rcv.sb_mbcnt; - so->so_snd.sb_hiwat -= - so2->so_rcv.sb_cc - unp->unp_conn->unp_cc; - (void)chgsbsize(so->so_cred->cr_uid, - (rlim_t)unp->unp_conn->unp_cc - so2->so_rcv.sb_cc, RLIM_INFINITY); + newhiwat = so->so_snd.sb_hiwat - + (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc); + (void)chgsbsize(so->so_cred->cr_uid, &so->so_snd.sb_hiwat, + newhiwat, RLIM_INFINITY); unp->unp_conn->unp_cc = so2->so_rcv.sb_cc; sorwakeup(so2); m = 0; Index: sys/proc.h =================================================================== RCS file: /usr2/ncvs/src/sys/sys/proc.h,v retrieving revision 1.107 diff -u -r1.107 proc.h --- sys/proc.h 2000/07/11 22:07:53 1.107 +++ sys/proc.h 2000/08/26 23:31:17 @@ -422,7 +423,7 @@ extern struct vm_zone *proc_zone; int chgproccnt __P((uid_t uid, int diff, int max)); -int chgsbsize __P((uid_t uid, rlim_t diff, rlim_t max)); +int chgsbsize __P((uid_t uid, u_long *hiwat, u_long to, rlim_t max)); int enterpgrp __P((struct proc *p, pid_t pgid, int mksess)); void fixjobc __P((struct proc *p, struct pgrp *pgrp, int entering)); int inferior __P((struct proc *p)); -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 17:30:27 2000 Delivered-To: freebsd-current@freebsd.org Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39]) by hub.freebsd.org (Postfix) with ESMTP id 4B7FA37B43E; Sat, 26 Aug 2000 17:30:10 -0700 (PDT) Received: from [10.0.1.2] (dialup536.brussels.skynet.be [195.238.21.24]) by morpheus.skynet.be (Postfix) with ESMTP id 43CF7DADF; Sun, 27 Aug 2000 02:30:04 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@pop.skynet.be Message-Id: In-Reply-To: References: Date: Sun, 27 Aug 2000 02:12:44 +0200 To: "Matthew N. Dodd" , Mike Smith From: Brad Knowles Subject: Re: DPT revision....(broken drivers in -STABLE) Cc: Visigoth , current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:18 PM -0400 2000/8/23, Matthew N. Dodd wrote: > I don't remember seeing a verbose boot log posted so I can't really say > whats wrong. There is no difference b/t the -CURRENT and 4-STABLE > versions of dpt_pci.c so I'm not sure what could be causing the > problem. Of course it may be that the cards don't work in -CURRENT > either. I'm curious -- what kinds of cards are supported by this routine? Does this include the DPT SmartRAID V, as well as the older SmartRAID IV? I've got an anonymous ftp server I need to rebuild -- it had previously been running Slackware Linux, but as the kernel got updated, the source for the driver didn't, so I scrapped it and am rebuilding with FreeBSD. Anyway, my thought was actually to scrap the DPT card (because it was my understanding that the FreeBSD drivers for the SmartRAID V were only "beta" quality), and simply use vinum instead. However, if this card is better supported than I first thought, then I'll be glad to keep it. ;-) -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 17:44:26 2000 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 86B3237B42C for ; Sat, 26 Aug 2000 17:44:22 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id F220228C43; Sun, 27 Aug 2000 07:44:18 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id DD66528703; Sun, 27 Aug 2000 07:44:18 +0700 (ALMST) Date: Sun, 27 Aug 2000 07:44:18 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: freebsd-current@FreeBSD.ORG Subject: Re: official devfs patch for review In-Reply-To: <485.967316997@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 26 Aug 2000, Poul-Henning Kamp wrote: > This incorporates the functional bits from the patch Boris posted > here earlier as I've been able to extract them from his patch. No, not all bits are incorporated. At least you've missed two important things. First: # cd /dev/fd # ls 0 1 2 # cd .. # ls 0 1 2 And second - directory names supplied by readdir() function contains junk characters at the end. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 18:24:12 2000 Delivered-To: freebsd-current@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id B36E937B424 for ; Sat, 26 Aug 2000 18:24:10 -0700 (PDT) Received: from holly.dyndns.org ([208.191.149.190]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FZX006SEF9AHC@mta4.rcsntx.swbell.net> for freebsd-current@FreeBSD.ORG; Sat, 26 Aug 2000 20:10:22 -0500 (CDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id UAA78652; Sat, 26 Aug 2000 20:08:45 -0500 (CDT envelope-from chris) Date: Sat, 26 Aug 2000 20:08:44 -0500 From: Chris Costello Subject: Re: official devfs patch for review In-reply-to: To: Boris Popov Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000826200844.N60058@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <485.967316997@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, August 27, 2000, Boris Popov wrote: > No, not all bits are incorporated. At least you've missed two > important things. First: > > # cd /dev/fd > # ls > 0 1 2 > # cd .. > # ls > 0 1 2 > > And second - directory names supplied by readdir() function > contains junk characters at the end. I'm going to commit some fdescfs-related patches sometime soon next week. If you're not using the fdescfs code already, I can probably integrate my work into devfs, since that was the point of my work on fdescfs. -- |Chris Costello |All new: The software is not compatible with previous versions. `--------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 19:57:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 1CD2537B423; Sat, 26 Aug 2000 19:57:28 -0700 (PDT) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 0668E4D; Sat, 26 Aug 2000 22:57:26 -0400 (AST) Message-ID: <39A88396.A0D06237@vangelderen.org> Date: Sat, 26 Aug 2000 22:57:26 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Adam Back , current@freebsd.org, kris@freebsd.org Subject: Re: yarrow & /dev/random References: <200008262032.PAA05849@cypherspace.org> <200008262035.e7QKZsp26706@grimreaper.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: [...] > > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > > plaintext with a 256 bit key as a virtual 256 bit block cipher > > operation. I suspect the result will be weaker than 256 bits because > > of the internal structure of BF-CBC. > > I'm not sure I understand this? 256-bit Davies-Meyer is considered secure if a blockcipher with a 256-bit block is being used. Encrypting 256 bits in CBC mode is not the same as a blockcipher with a 256-bit block. For one, it will not obfuscate certain plaintext patterns. Consider what happens if the first 64 bits of two plaintext blocks are equal... Using the current construct allows for a variety of attacks on the compression function of the constructed hash. > > If you want 256 bit hash (and it is desirable for AES) you could use > > what Jeroen suggested: abrest Davies-Meyer, and a 128 bit block > > cipher. Or we could wait for the AES hash mode. > > That is doable; But we don't have any 128-bit block blockciphers in the kernel? > at the moment I only have SHA1, MD5, DES and Blowfish > available in FreeBSD's kernel crypto API; I'd need a lot more evidence > before I feen I can pull in any more :-) You could argue that AES belongs in the kernel as soon as it is selected. You could then go ahead and import Serpent now (as the most conservative possible choice of AES) with the comment that it will be replaced with the real AES later. Waiting for the AES hash mode requires a lot of patience. I suspect a 256-bit hash will accompany the next-generation DSA but that will take at least a year or so... In any case, the currently available building blocks are not sufficient and I doubt you will encounter much objections against importing another cipher. Have you actually asked or is it more of a perceived objection? > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > > the key agility. But Twofish is not neccessarily the best choice. Yes, it's being pushed by Bruce Schneier but that's for marketing purposes, not for technical merits. Iff you are going with a 128-bit-block blockcipher you ought to select the most conservative one and that currently isn't Twofish IMO. [...] > > The quality of the de-skewing function, conservative assumptions about > > distribution of entropy across samples and conservativeness of the > > entropy estimates don't help. It's the yarrow output function which > > blows it. > > Yeah; that monotonically-increasing counter bothers me slightly. Why? How would it affect security if one assumes the blockcipher is secure? Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 21:40:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherspace.org (modemcable228.178-201-24.mtl.mc.videotron.net [24.201.178.228]) by hub.freebsd.org (Postfix) with ESMTP id A70EB37B424 for ; Sat, 26 Aug 2000 21:40:52 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id AAA06989; Sun, 27 Aug 2000 00:42:59 -0500 Date: Sun, 27 Aug 2000 00:42:59 -0500 Message-Id: <200008270542.AAA06989@cypherspace.org> From: Adam Back To: jeroen@vangelderen.org Cc: mark@grondar.za, current@freebsd.org In-reply-to: <39A88396.A0D06237@vangelderen.org> (jeroen@vangelderen.org) Subject: Re: yarrow & /dev/random Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen writes: > > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > > > the key agility. > > But Twofish is not neccessarily the best choice. Yes, it's being > pushed by Bruce Schneier but that's for marketing purposes, not > for technical merits. I think that's a little negative -- all of the authors got to make their speil for how their cipher was the best. All the candidates are pushing their respective ciphers. > Iff you are going with a 128-bit-block blockcipher you ought to > select the most conservative one and that currently isn't Twofish > IMO. Anderson argues that Serpent is a conservative design, and makes a reasonable case for this, however as a result Serpent is a tad slow compared to others, and perhaps might lose as a result. I don't see that it makes much difference either way. You probably don't want to chose RC6 or MARS because their authors will probably patent them if they lose, and then you'll have to back off using them fast. Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 21:44: 6 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1350B37B423 for ; Sat, 26 Aug 2000 21:43:57 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id AAA13998; Sun, 27 Aug 2000 00:43:56 -0400 (EDT) (envelope-from wollman) Date: Sun, 27 Aug 2000 00:43:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200008270443.AAA13998@khavrinen.lcs.mit.edu> To: Adam Back Cc: jeroen@vangelderen.org, mark@grondar.za, current@FreeBSD.ORG Subject: Re: yarrow & /dev/random In-Reply-To: <200008270542.AAA06989@cypherspace.org> References: <39A88396.A0D06237@vangelderen.org> <200008270542.AAA06989@cypherspace.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > You probably don't want to chose RC6 or MARS because their authors > will probably patent them if they lose, and then you'll have to back > off using them fast. If they were going to be patented, the application has already been filed, so you might as well assume that they are patented. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Aug 26 22:54:13 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-115.dsl.snfc21.pacbell.net [63.202.177.115]) by hub.freebsd.org (Postfix) with ESMTP id 58CCD37B422 for ; Sat, 26 Aug 2000 22:54:10 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id XAA09023; Sat, 26 Aug 2000 23:07:06 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200008270607.XAA09023@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brad Knowles Cc: current@FreeBSD.ORG Subject: Re: DPT revision....(broken drivers in -STABLE) In-reply-to: Your message of "Sun, 27 Aug 2000 02:12:44 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Aug 2000 23:07:06 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm curious -- what kinds of cards are supported by this routine? > Does this include the DPT SmartRAID V, as well as the older SmartRAID > IV? I've got an anonymous ftp server I need to rebuild -- it had > previously been running Slackware Linux, but as the kernel got > updated, the source for the driver didn't, so I scrapped it and am > rebuilding with FreeBSD. The Linux driver for the V and VI cards is (according to a reliable source) pretty awful. > Anyway, my thought was actually to scrap the DPT card (because it > was my understanding that the FreeBSD drivers for the SmartRAID V > were only "beta" quality), and simply use vinum instead. However, if > this card is better supported than I first thought, then I'll be glad > to keep it. ;-) I have theoretically production-quality drivers from Adaptec which I will be committing as soon as I have time to test them (a few days, I hope). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message