From owner-freebsd-hackers Sun Feb 14 00:45:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA04028 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 00:45:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA04023 for ; Sun, 14 Feb 1999 00:45:20 -0800 (PST) (envelope-from root@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10BxB1-000I2vC; Sun, 14 Feb 1999 03:45:19 -0500 (EST) Message-Id: From: root@tomqnx.com (Tom Torrance at home Root) Subject: cvsup query To: hackers@FreeBSD.ORG Date: Sun, 14 Feb 1999 03:45:19 -0500 (EST) 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am running version 16.0 on RELENG_3 obtained from the cvsup-bin port. I just ran a cvsup to cvsup3 and it added deltas to amd.map and config.c (the server was running 16.0 cvsup server). I then ran the same update to cvsup.freebsd.org which was running U_1999_01_15_18_18_08. It said 'Falling back to protocol version 15.5'. This run checked out new versions of amd.map and config.c over the modified versions. Obviously this would be what would happen if cvsup3 were more up-to-date than cvsup, but I had thought that cvsup was the master (perhaps incorrectly...). Was this normal operation? Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 05:39:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA28421 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 05:39:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from niobe.ewox.org (ppp063.uio.no [129.240.240.68]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA28414 for ; Sun, 14 Feb 1999 05:39:39 -0800 (PST) (envelope-from des@niobe.ewox.org) Received: (from des@localhost) by niobe.ewox.org (8.9.3/8.9.1) id BAA16733 for freebsd-hackers@freebsd.org; Sun, 14 Feb 1999 01:48:21 +0100 (CET) (envelope-from des) To: freebsd-hackers@FreeBSD.ORG Subject: install -C From: Dag-Erling Smorgrav Date: 14 Feb 1999 01:05:41 +0100 Message-ID: <86u2wpc0iy.fsf@niobe.ewox.org> X-Mailer: Gnus v5.3/Emacs 19.34 Lines: 28 Xref: niobe.ewox.org sent.1999-02:14 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There's something funny about make installworld. Specifically, it installs a lot of files with "install -C" regardless of whether or not the INSTALL variable in /etc/make.conf actually is set to "install -C". This is the case for: * header files * C++ template files * /boot/loader.help * /usr/libexec/ld.so * /usr/libexec/ld-elf.so.1 I can understand the reason for the first two (avoid needlessly breaking dependencies), but not for the last three. In any case, I think it would be better if we always used whatever the admin has set INSTALL to in /etc/make.conf, and make "install -C" the default. My main argument against always installing certain files with "install -C" is that makes it very difficult to clean up after a major upgrade, since you can't rely on "live" files to have a recent timestamp. I've talked to people on IRC who deleted their Elf interpreter because its mtime predated their last make world. Shooting yourself in the foot like that is too high a price for the few seconds saved during make installworld. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 05:48:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA29099 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 05:48:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA29094 for ; Sun, 14 Feb 1999 05:48:25 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id OAA24092 for FreeBSD-hackers@freebsd.org; Sun, 14 Feb 1999 14:42:47 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id OAA01775 for FreeBSD-hackers@freebsd.org; Sun, 14 Feb 1999 14:45:46 +0100 (CET) From: Wilko Bulte Message-Id: <199902141345.OAA01775@yedi.iaf.nl> Subject: shopping for SCSI CDR / recommendations sought To: FreeBSD-hackers@FreeBSD.ORG (FreeBSD hackers list) Date: Sun, 14 Feb 1999 14:45:46 +0100 (CET) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I'm considering the purchase of a SCSI CDR, 4x speed. I invite recommendations for this (private mail please). Intended (obviously..) for use on FreeBSD. Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 06:02:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA00468 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 06:02:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00462 for ; Sun, 14 Feb 1999 06:02:39 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA07043; Sun, 14 Feb 1999 15:02:36 +0100 (CET) (envelope-from des) To: root@tomqnx.com (Tom Torrance at home Root) Cc: hackers@FreeBSD.ORG Subject: Re: cvsup query References: From: Dag-Erling Smorgrav Date: 14 Feb 1999 15:02:36 +0100 In-Reply-To: root@tomqnx.com's message of "Sun, 14 Feb 1999 03:45:19 -0500 (EST)" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG root@tomqnx.com (Tom Torrance at home Root) writes: > This run checked out new versions of amd.map and config.c over the > modified versions. Obviously this would be what would happen if > cvsup3 were more up-to-date than cvsup, but I had thought that cvsup > was the master (perhaps incorrectly...). > > Was this normal operation? Yes. The master cvsup site is freefall.freebsd.org, but acces to it is restricted. cvsup[0-9]?(.[a-z][a-z].)?.freebsd.org are all mirrors, and they are not necessarily always in sync with eachother. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 10:57:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25996 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 10:57:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25990; Sun, 14 Feb 1999 10:56:57 -0800 (PST) (envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp) From: takawata@shidahara1.planet.sci.kobe-u.ac.jp Received: from libr.scitec.kobe-u.ac.jp (cs22145.ppp.infoweb.ne.jp [202.219.4.61]) by shidahara1.planet.sci.kobe-u.ac.jp (8.8.8+2.7Wbeta7/8.8.8) with ESMTP id DAA20198; Mon, 15 Feb 1999 03:47:47 +0900 (JST) Received: from shidahara1.planet.kobe-u.ac.jp (localhost [127.0.0.1]) by libr.scitec.kobe-u.ac.jp (8.9.1/3.5Wpl7) with ESMTP id DAA03817; Mon, 15 Feb 1999 03:55:08 +0900 (JST) Message-Id: <199902141855.DAA03817@libr.scitec.kobe-u.ac.jp> To: Brian Feldman , nsouch@FreeBSD.ORG Cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Aladdin chipset SMBus support available! In-reply-to: Your message of "Sun, 14 Feb 1999 12:11:09 EST." Date: Mon, 15 Feb 1999 03:55:07 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Brian Feldman wrote: >> >> I attach you the detect.c program. It's very simple and may help us >> >> in knowing what I2C hardware you have on your mobo. >> > >> >Where's my detect.c? I think you forgot to attach it :) >> >> :) here it is! > >alpm0: rev 0x00 on pci0.3.0 >alsmb0: >smbus0: on alsmb0 >smb0: on smbus0 > >{"/home/green/examples"}$ ./detect >a2 found. This is DIMM(with SPD). #./spd 1 will show your DIMM infomation. >d2 found. I want to know about this address. SMBus in my motherboard will hang up when I issue RECV_BYTE method for this port. >> BTW, as outlined by -pkh all this is just a first step in a huge monitoring >> adventure where all still need to be _defined_ (architecture and interfaces) >> and implemented. Any proposition for doing the job is wellcome, >> since I just have enough time to do the hardware SMBus support. > >Sounds like fun.... I think so too. /dev/smb? should not be used in casual use,because it is dangerous,as banging I/O port.I want to discuss about the interface. Where did he wrote it? Takanori Watanabe Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 11:43:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00627 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 11:43:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00617; Sun, 14 Feb 1999 11:43:53 -0800 (PST) (envelope-from son@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.1a/8.9.1a) with ESMTP id UAA25879; Sun, 14 Feb 1999 20:43:40 +0100 (MET) Received: (from son@localhost) by teaser.fr (8.9.2/8.9.1) id UAA00563; Sun, 14 Feb 1999 20:40:54 +0100 (CET) (envelope-from son) Message-ID: <19990214204054.42098@breizh.prism.uvsq.fr> Date: Sun, 14 Feb 1999 20:40:54 +0100 From: Nicolas Souchu To: takawata@shidahara1.planet.sci.kobe-u.ac.jp Cc: Brian Feldman , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Aladdin chipset SMBus support available! References: <199902141855.DAA03817@libr.scitec.kobe-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199902141855.DAA03817@libr.scitec.kobe-u.ac.jp>; from takawata@shidahara1.planet.sci.kobe-u.ac.jp on Mon, Feb 15, 1999 at 03:55:07AM +0900 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 15, 1999 at 03:55:07AM +0900, takawata@shidahara1.planet.sci.kobe-u.ac.jp wrote: > >>d2 found. > >I want to know about this address. SMBus in my motherboard will hang >up when I issue RECV_BYTE method for this port. It does not for me. It's supposed to be the address of a clock chip, isn't it? > >>> BTW, as outlined by -pkh all this is just a first step in a huge monitoring >>> adventure where all still need to be _defined_ (architecture and interfaces) >>> and implemented. Any proposition for doing the job is wellcome, >>> since I just have enough time to do the hardware SMBus support. >> >>Sounds like fun.... > >I think so too. >/dev/smb? should not be used in casual use,because it is dangerous,as >banging I/O port.I want to discuss about the interface. Where did he >wrote it? He wrote nothing, just: >>> Not to stop you in your tracks, but I would really love to see somebody (more capable than the PAO people) work out a power management architecture for us before we have too many more hacks in this area... Poul-Henning In message <199902131808.KAA79388@freefall.freebsd.org>, Nicolas Souchu writes: >nsouch 1999/02/13 10:08:35 PST > > Modified files: > share/man/man4 intpm.4 > Log: > Fix the date and add an smbus declaration > > Revision Changes Path > 1.2 +3 -2 src/share/man/man4/intpm.4 > <<< -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 12:53:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07113 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 12:53:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07108; Sun, 14 Feb 1999 12:53:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA07985; Sun, 14 Feb 1999 12:53:44 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 12:53:44 -0800 (PST) From: Matthew Dillon Message-Id: <199902142053.MAA07985@apollo.backplane.com> To: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Again: sorflush() bug fix in uipc_usrreq.c -- need someone to review this Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nobody but Doug has gotten back to me on this patch, which is in -current but not currently in stable. Doug indicated that he wasn't very familiar with the area in question. I think it's pretty important that this patch make it into the 3.1 release but I would like someone familiar with the code to double-check it. If nobody gets back to me today on it I am going to commit it to -stable w/ Jordan's permission. -Matt Matthew Dillon : This fix is currently comitted to -4.x. I don't want to backport it to : -3.x until I get an independant review. : : This code is ( I believe ) part of the message queue flushing for : typically unix domain sockets, relating to file descriptor passing. : This code is attempting to flush the in-transit file descriptors when : both sides of the connection go poof. : : The problem ( I believe ) is that it is calling sorflush() potentially : on non-sockets. While most uses of file descriptor passing pass only : sockets, if this bug is hit for those uses that do not, it could corrupt : kernel memory or cause a crash. : : I need someone to check the code and tell me I'm not blowing smoke before : I backport this :-) : : -Matt : Matthew Dillon : : :*** uipc_usrreq.c 1998/10/25 17:44:51 1.37 :--- uipc_usrreq.c 1999/01/21 08:03:49 :*************** :*** 1114,1121 **** : /* : * for each FD on our hit list, do the following two things : */ :! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) :! sorflush((struct socket *)(*fpp)->f_data); : for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) : closef(*fpp, (struct proc *) NULL); : free((caddr_t)extra_ref, M_FILE); :--- 1114,1124 ---- : /* : * for each FD on our hit list, do the following two things : */ :! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) { :! struct file *tfp = *fpp; :! if (tfp->f_type == DTYPE_SOCKET && tfp->f_data != NULL) :! sorflush((struct socket *)(tfp->f_data)); :! } : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:00:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08084 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:00:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08079 for ; Sun, 14 Feb 1999 13:00:33 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id MAA96683 for ; Sun, 14 Feb 1999 12:59:52 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902142059.MAA96683@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: Oskit and 3.0? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 12:59:52 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://www.cs.utah.edu/projects/flexmach/oskit/html/index.html Does anyone have patches to create oskit kernels which can be booted by 3.0 or 4.0 system? I can netboot oskits from a floppy or use GRUB in a floppy to boot kernels however it would be nice if I boot Oskit from FreeBSD partition. BTW: netboot is really cool: http://www.cs.utah.edu/projects/flexmach/oskit/html/boot-floppy/ Tnks, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:24:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11098 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:24:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11089 for ; Sun, 14 Feb 1999 13:24:45 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id OAA22374; Sun, 14 Feb 1999 14:24:44 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA22436; Sun, 14 Feb 1999 14:24:42 -0700 Date: Sun, 14 Feb 1999 14:24:42 -0700 Message-Id: <199902142124.OAA22436@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dag-Erling Smorgrav Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: install -C In-Reply-To: <86u2wpc0iy.fsf@niobe.ewox.org> References: <86u2wpc0iy.fsf@niobe.ewox.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > There's something funny about make installworld. > > Specifically, it installs a lot of files with "install -C" regardless > of whether or not the INSTALL variable in /etc/make.conf actually is > set to "install -C". This is the case for: > > * header files > * C++ template files .... > My main argument against always installing certain files with "install > -C" is that makes it very difficult to clean up after a major upgrade, > since you can't rely on "live" files to have a recent timestamp. You shouldn't rely on timestamps for determining if a file is valid or not. > I've talked to people on IRC who deleted their Elf interpreter because > its mtime predated their last make world. Shooting yourself in the > foot like that is too high a price for the few seconds saved during > make installworld. Dr., Dr., it hurts when I do this. Then *DON'T* do it. If you don't know what you are doing, then don't do stupid things. I think the defaults should stay the way they are, because there are very valid reasons for using 'install -C' on the special files described. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:32:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11592 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:26:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from k6n1.znh.org ([207.109.235.49]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11587 for ; Sun, 14 Feb 1999 13:26:56 -0800 (PST) (envelope-from zach@uffdaonline.net) Received: (from zach@localhost) by k6n1.znh.org (8.9.3/8.9.1) id VAA01037; Sun, 14 Feb 1999 21:28:53 GMT (envelope-from zach) Message-ID: <19990214152853.A719@znh.org> Date: Sun, 14 Feb 1999 15:28:53 -0600 From: Zach Heilig To: Dag-Erling Smorgrav , freebsd-hackers@freebsd.org Subject: Re: install -C References: <86u2wpc0iy.fsf@niobe.ewox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <86u2wpc0iy.fsf@niobe.ewox.org>; from Dag-Erling Smorgrav on Sun, Feb 14, 1999 at 01:05:41AM +0100 Sender: owner-freebsd-hackers@freebsd.org Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 14, 1999 at 01:05:41AM +0100, Dag-Erling Smorgrav wrote: > My main argument against always installing certain files with "install > -C" is that makes it very difficult to clean up after a major upgrade, > since you can't rely on "live" files to have a recent timestamp. I've > talked to people on IRC who deleted their Elf interpreter because its > mtime predated their last make world. Shooting yourself in the foot > like that is too high a price for the few seconds saved during make > installworld. Use 'ctime' instead of 'mtime'. This works for everything but perl... -- Zach Heilig / Zach Heilig "Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend" -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:32:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12369 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:32:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles146.castles.com [208.214.165.146]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12363 for ; Sun, 14 Feb 1999 13:32:37 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA05513; Sun, 14 Feb 1999 13:27:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902142127.NAA05513@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Dag-Erling Smorgrav , freebsd-hackers@FreeBSD.ORG Subject: Re: install -C In-reply-to: Your message of "Sun, 14 Feb 1999 14:24:42 MST." <199902142124.OAA22436@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 13:27:26 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've talked to people on IRC who deleted their Elf interpreter because > > its mtime predated their last make world. Shooting yourself in the > > foot like that is too high a price for the few seconds saved during > > make installworld. > > Dr., Dr., it hurts when I do this. > > Then *DON'T* do it. > > If you don't know what you are doing, then don't do stupid things. I > think the defaults should stay the way they are, because there are very > valid reasons for using 'install -C' on the special files described. I was present during at least some of these conversations. If these people hadn't deleted their ELF interpreters, they'd just have found some other way to screw themselves. We're seeing the manifestation of some millenial lemmings with the impending a.out->ELF finality; just carry an umbrella strong enough to resist small furry bodies at terminal velocity and all will be well. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:39:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12953 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:39:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12946 for ; Sun, 14 Feb 1999 13:39:33 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id WAA28840 for freebsd-hackers@FreeBSD.ORG; Sun, 14 Feb 1999 22:39:29 +0100 (CET) (envelope-from olli) Date: Sun, 14 Feb 1999 22:39:29 +0100 (CET) From: Oliver Fromme Message-Id: <199902142139.WAA28840@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Amancio Hasty wrote in list.freebsd-hackers: > [...] > BTW: netboot is really cool: > http://www.cs.utah.edu/projects/flexmach/oskit/html/boot-floppy/ Yes, indeed, cool... I still have to use the old bootloader and aout kernels, because there's no netboot support in the new bootloader. I think it's a shame that 3.1-Release won't be able to support netbooting (at least not without major efforts), like 2.x did. Netbooting is quite an important feature, IMO. Regards Oliver PS: Sorry for whining... :-) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:51:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14359 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:51:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA14337; Sun, 14 Feb 1999 13:51:40 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id QAA00307; Sun, 14 Feb 1999 16:58:36 -0500 From: Bill Paul Message-Id: <199902142158.QAA00307@skynet.ctr.columbia.edu> Subject: How the hell does one create a new bus?! To: hackers@FreeBSD.ORG Date: Sun, 14 Feb 1999 16:58:35 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Grrrr. Alright, I give up: how does one create a new 'bus' layer? By that I mean like /sys/dev/iicbus and /sys/dev/smbus. Yes, I've read the code in these two directories, but I'm confused as to which parts relate to the bus architecture in general and which parts are speficic to the I2C and system management implementation. >From what I can tell, you need the following: - foobus_if.m, a file which describes the functions that drivers for devices attached to this kind bus can perform. - foobus.c and foobus.h WHAT EXACTLY GOES IN HERE!? - fooconf.c and fooconf.h WHAT EXACTLY GOES IN HERE!? - Some type of top level driver for the device which implements the bus. - Various drivers for devices attached to the bus. In my particular case, I'm trying to create a bus layer for MII-compliant PHYs attached to ethernet controller chips. The ethernet controller is the bus controller device: each MII management bus can have up to 32 PHY devices attached to it (though in general you rarely have more than two). Each ethernet driver exports three functions to the MII code: mii_read(), mii_write() and mii_statchg(). The first two allow reading and writing of the registers of a PHY at a particular address (i.e. mii_read(dev, phyadd, regaddr), mii_write(dev, phyaddr, regaddr, val)). The mii_statchg() routine is a callback routine: when one of the lower-level PHY drivers does a media change, it calls back to the ethernet driver to let it know. (This is necessary because some media changes also require updating registers on the ethernet controller itself. For instance, on the ThunderLAN chip, if the PHY is set for full duplex, the ThunderLAN chip itself also has to be programmed for full duplex at the same time). The PHY drivers themselves (as they are now) export three functions to the MII glue code: foophy_probe(), foophy_attach() and foophy_service(). The middle MII layer exports mii_phy_probe(), mii_pollstat(), mii_statchg() and mii_tick() back to the ethernet driver. I've faked things up for now using linker sets, but I'd prefer to make everything fit into the bus framework if possible. Unfortunately, there doesn't appear to be a nice generic example that shows how to create a new bus layer, and the existing code confuses the hell out of me. For example, both the iicbus and smbus code use interrupt routines, but the MII code doesn't need interrupts (PHY devices don't normally generate interrupts). Also, how do I know exactly what goes into the foobus.c and fooconf.c modules? The smbconf.c and iiconf.c modules appear to have 'request_bus' routines that do things with tsleep(); what is this for? Does every bus need this or is it specific to the I2C and SMB stuff? The ppbus code is no help as it doesn't actually use this framework, and the usb bus stuff is a mutant pile of macros and #ifdefs. What this stuff needs is a developer's guide; a clearcut explanation of how to create new busses, how to create top level bus drivers and how to create drivers for devices attached to busses. If anyone can point me at such a guide or can just explain to me how this nonsense is supposed to work, I'd be grateful. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 13:53:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14680 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 13:53:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles146.castles.com [208.214.165.146]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA14675 for ; Sun, 14 Feb 1999 13:53:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id NAA05644 for ; Sun, 14 Feb 1999 13:49:05 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902142149.NAA05644@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? In-reply-to: Your message of "Sun, 14 Feb 1999 22:39:29 +0100." <199902142139.WAA28840@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Sun, 14 Feb 1999 13:49:04 -0800 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id NAA14676 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Amancio Hasty wrote in list.freebsd-hackers: > > [...] > > BTW: netboot is really cool: > > http://www.cs.utah.edu/projects/flexmach/oskit/html/boot-floppy/ > > Yes, indeed, cool... I still have to use the old bootloader > and aout kernels, because there's no netboot support in the new > bootloader. > I think it's a shame that 3.1-Release won't be able to support > netbooting (at least not without major efforts), like 2.x did. > Netbooting is quite an important feature, IMO. > > Regards > Oliver > > PS: Sorry for whining... :-) There's work underway at the moment to address this; it should be an easy after-release bolt-on. Testers will, of course, be required. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 14:00:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15231 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 14:00:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nina.pagesz.net (nina.pagesz.net [208.194.157.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15196 for ; Sun, 14 Feb 1999 13:59:58 -0800 (PST) (envelope-from rhh@pagesz.net) Received: from stealth.dummynet. (juana-32.pagesz.net [208.213.126.32]) by nina.pagesz.net (8.8.7/8.8.7) with ESMTP id RAA24172 for ; Sun, 14 Feb 1999 17:00:17 -0500 Received: (from rhh@localhost) by stealth.dummynet. (8.9.1/8.8.8) id RAA01514 for hackers@freebsd.org; Sun, 14 Feb 1999 17:00:45 -0500 (EST) (envelope-from rhh) Date: Sun, 14 Feb 1999 17:00:45 -0500 From: Randall Hopper To: hackers@FreeBSD.ORG Subject: "XESS" Spreadsheet for FreeBSD Message-ID: <19990214170045.B1363@pagesz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The XESS Spreadsheet folks (AIS) are considering a FreeBSD version. If anyone would also be interested in this, please forward your interest/input onto them (info@ais.com). Here's the URL for the spreadsheet: http://www.ais.com/Xess/xess4_product_sheet.html Randall ----- Forwarded message from shannon@ais.com ----- Date: Tue, 9 Feb 99 11:49:38 EST From: shannon@ais.com Subject: XESS on FreeBSD Hello Randall, You sent: > I would consider your product were there a version that runs on FreeBSD > (www.freebsd.org) as there apparently once was. However, it appears > you currently only have a Linux version, and it depends on Linux-specific > /proc entries such as /proc/cpuinfo /proc/version, so I can't run it > on FreeBSD, even under Linux emulation. > Just a datapoint XESS and XessLite have never been built specifically for FreeBSD. However, we have recently gotten enough interest that we are giving the idea of porting XESS and/or XessLite to FreeBSD. We would appreciate any input you might have and will let you know once we make a decision. Thank you for your interest in XESS! Sincerely, Shannon Tostanoski AIS Sales Admin shannon@ais.com ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 14:42:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20037 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 14:42:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20032 for ; Sun, 14 Feb 1999 14:42:39 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA16244; Sun, 14 Feb 1999 14:35:42 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdi16239; Sun Feb 14 22:35:32 1999 Date: Sun, 14 Feb 1999 14:35:27 -0800 (PST) From: Julian Elischer To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? In-Reply-To: <199902142149.NAA05644@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG we netboot elf kernels and aout kernels here.. check with doug ambrisko (ambrisko@whistle.com) for his netbooting stuff. julian On Sun, 14 Feb 1999, Mike Smith wrote: > > Amancio Hasty wrote in list.freebsd-hackers: > > > [...] > > > BTW: netboot is really cool: > > > http://www.cs.utah.edu/projects/flexmach/oskit/html/boot-floppy/ > > > > Yes, indeed, cool... I still have to use the old bootloader > > and aout kernels, because there's no netboot support in the new > > bootloader. > > I think it's a shame that 3.1-Release won't be able to support > > netbooting (at least not without major efforts), like 2.x did. > > Netbooting is quite an important feature, IMO. > > > > Regards > > Oliver > > > > PS: Sorry for whining... :-) > > There's work underway at the moment to address this; it should be an > easy after-release bolt-on. Testers will, of course, be required. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 14:42:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20074 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 14:42:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20049; Sun, 14 Feb 1999 14:42:43 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA16213; Sun, 14 Feb 1999 14:33:21 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdD16211; Sun Feb 14 22:33:14 1999 Date: Sun, 14 Feb 1999 14:33:10 -0800 (PST) From: Julian Elischer To: Matthew Dillon cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Again: sorflush() bug fix in uipc_usrreq.c -- need someone to review this In-Reply-To: <199902142053.MAA07985@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not convinced that it may not be impossible to get anything but socket fds in the 'hitlist' Since to get on it the fd must be involved in a cyclical reference (see the big comment in prior code). still the check can't hurt.. julian On Sun, 14 Feb 1999, Matthew Dillon wrote: > Nobody but Doug has gotten back to me on this patch, which is in -current > but not currently in stable. Doug indicated that he wasn't very familiar > with the area in question. > > I think it's pretty important that this patch make it into the 3.1 > release but I would like someone familiar with the code to double-check > it. If nobody gets back to me today on it I am going to commit it to > -stable w/ Jordan's permission. > > -Matt > Matthew Dillon > > > > : This fix is currently comitted to -4.x. I don't want to backport it to > : -3.x until I get an independant review. > : > : This code is ( I believe ) part of the message queue flushing for > : typically unix domain sockets, relating to file descriptor passing. > : This code is attempting to flush the in-transit file descriptors when > : both sides of the connection go poof. > : > : The problem ( I believe ) is that it is calling sorflush() potentially > : on non-sockets. While most uses of file descriptor passing pass only > : sockets, if this bug is hit for those uses that do not, it could corrupt > : kernel memory or cause a crash. > : > : I need someone to check the code and tell me I'm not blowing smoke before > : I backport this :-) > : > : -Matt > : Matthew Dillon > : > : > :*** uipc_usrreq.c 1998/10/25 17:44:51 1.37 > :--- uipc_usrreq.c 1999/01/21 08:03:49 > :*************** > :*** 1114,1121 **** > : /* > : * for each FD on our hit list, do the following two things > : */ > :! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) > :! sorflush((struct socket *)(*fpp)->f_data); > : for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) > : closef(*fpp, (struct proc *) NULL); > : free((caddr_t)extra_ref, M_FILE); > :--- 1114,1124 ---- > : /* > : * for each FD on our hit list, do the following two things > : */ > :! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) { > :! struct file *tfp = *fpp; > :! if (tfp->f_type == DTYPE_SOCKET && tfp->f_data != NULL) > :! sorflush((struct socket *)(tfp->f_data)); > :! } > : > : > :To Unsubscribe: send mail to majordomo@FreeBSD.org > :with "unsubscribe freebsd-hackers" in the body of the message > : > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 14:48:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20776 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 14:48:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20769 for ; Sun, 14 Feb 1999 14:48:38 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id XAA29251 for freebsd-hackers@FreeBSD.ORG; Sun, 14 Feb 1999 23:23:59 +0100 (CET) (envelope-from olli) Date: Sun, 14 Feb 1999 23:23:59 +0100 (CET) From: Oliver Fromme Message-Id: <199902142223.XAA29251@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? Newsgroups: list.freebsd-hackers Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote in list.freebsd-hackers: > > Amancio Hasty wrote in list.freebsd-hackers: > > > [...] > > > BTW: netboot is really cool: > > > http://www.cs.utah.edu/projects/flexmach/oskit/html/boot-floppy/ > > > > Yes, indeed, cool... I still have to use the old bootloader > > and aout kernels, because there's no netboot support in the new > > bootloader. > > I think it's a shame that 3.1-Release won't be able to support > > netbooting (at least not without major efforts), like 2.x did. > > Netbooting is quite an important feature, IMO. > > There's work underway at the moment to address this; it should be an > easy after-release bolt-on. I'm really happy to hear that. :) At the moment I have to use that self-hacked version of rawboot, which works with aout kernels only, and doesn't support /kernel.config... Setting up PnP cards is a PITA that way. > > Testers will, of course, be required. Here's one tester for you. As soon as /boot/loader is able to pull a kernel and its config through an EtherExpress/100 I'll buy you a beer. :-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 14:52:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21288 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 14:52:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21280 for ; Sun, 14 Feb 1999 14:52:26 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA16542; Sun, 14 Feb 1999 14:46:06 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdD16538; Sun Feb 14 22:46:04 1999 Date: Sun, 14 Feb 1999 14:46:01 -0800 (PST) From: Julian Elischer To: Randall Hopper cc: hackers@FreeBSD.ORG Subject: Re: "XESS" Spreadsheet for FreeBSD In-Reply-To: <19990214170045.B1363@pagesz.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The thing to do is to tell them that we'd like them to test the linux version with freebsd and just add a note to say that it is tested under linux emulation under FreeBSD.. this would give us the tool and let them know about FreeBSD. We probably don't have ht enumbers to make them make a true FreeBSD port, but I f they do a FreeBSD port and no-one buys it we are in a worse situation than if we didn't. On Sun, 14 Feb 1999, Randall Hopper wrote: > The XESS Spreadsheet folks (AIS) are considering a FreeBSD version. > If anyone would also be interested in this, please forward your > interest/input onto them (info@ais.com). > > Here's the URL for the spreadsheet: > > http://www.ais.com/Xess/xess4_product_sheet.html > > Randall > > ----- Forwarded message from shannon@ais.com ----- > > Date: Tue, 9 Feb 99 11:49:38 EST > From: shannon@ais.com > Subject: XESS on FreeBSD > > Hello Randall, > > You sent: > > > I would consider your product were there a version that runs on FreeBSD > > (www.freebsd.org) as there apparently once was. However, it appears > > you currently only have a Linux version, and it depends on Linux-specific > > /proc entries such as /proc/cpuinfo /proc/version, so I can't run it > > on FreeBSD, even under Linux emulation. > > Just a datapoint > > XESS and XessLite have never been built specifically for FreeBSD. However, > we have recently gotten enough interest that we are giving the idea of > porting XESS and/or XessLite to FreeBSD. We would appreciate any input you > might have and will let you know once we make a decision. > > Thank you for your interest in XESS! > > Sincerely, > > Shannon Tostanoski > AIS Sales Admin > shannon@ais.com > > ----- End forwarded message ----- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 15:25:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25102 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 15:25:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bytor.rush.net (bytor.rush.net [209.45.245.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25084; Sun, 14 Feb 1999 15:25:48 -0800 (PST) (envelope-from lynch@rush.net) Received: from localhost (lynch@localhost) by bytor.rush.net (8.9.1/8.8.8) with ESMTP id SAA19192; Sun, 14 Feb 1999 18:16:59 -0500 (EST) (envelope-from lynch@rush.net) Date: Sun, 14 Feb 1999 18:16:59 -0500 (EST) From: Pat Lynch To: hackers@FreeBSD.ORG, chat@FreeBSD.ORG Subject: New York Users Group (FUNY?) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG don;t know if this ever got posted to -announce, so I'll try again. -Pat ___________________________________________________________________________ ---------- Forwarded message ---------- Date: Sat, 13 Feb 1999 14:28:18 -0500 (EST) From: Pat Lynch To: freebsd-announce@freebsd.org Subject: New York Users Group (FUNY?) There will be a steering/planning committee of the New York City FreeBSD Users Group or FreeBSD USers of New York or whatever ;) at the Bombay Palace restaurant between 5th and 6th on 52nd street in New York City on February 26, 1999 (thats next Friday). Anyone with an interest in a users group and the direction we should be taking in the NY metro area is invited to attend. Any requests for info should be directed towards me (lynch@rush.net). This includes directions, transportation questions, etc. -Pat Lynch ___________________________________________________________________________ Pat Lynch lynch@rush.net Systems Administrator Rush Networking Remark made by Bertrand Meyer (inventor of the Eiffel language) at a panel discussion at OOPSLA '89: "COBOL programmers are destined to code COBOL for the rest of their lives, and thereafter." ___________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 16:20:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03520 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 16:20:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03515; Sun, 14 Feb 1999 16:20:30 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA10642; Sun, 14 Feb 1999 16:20:23 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 16:20:23 -0800 (PST) From: Matthew Dillon Message-Id: <199902150020.QAA10642@apollo.backplane.com> To: Julian Elischer Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Again: sorflush() bug fix in uipc_usrreq.c -- need someone to review this References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'm not convinced that it may not be impossible to get anything but :socket fds in the 'hitlist' Since to get on it the fd must be involved in :a cyclical reference (see the big comment in prior code). :still the check can't hurt.. : :julian good 'nuf for me. I traced through the code and I believe it can happen. What has to happen is that you have to have two processes passing file descriptors to each other over a unix domain socket, and have both processes die while descriptors are 'in transit'. You get into trouble if you happen to be passing a non-socket descriptor over the socket when that condition occurs. The cyclical reference problem is a different problem - the hitlist is constructed whether there is cycle or not. The problem with the cyclical bug was that the same descriptor would wind up being double-closed or double-flushed due to the recursion. This particular bug was fixed a long time ago. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 16:20:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03741 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 16:20:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03529; Sun, 14 Feb 1999 16:20:32 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id AAA49511; Mon, 15 Feb 1999 00:19:15 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 15 Feb 1999 00:19:15 +0000 (GMT) From: Doug Rabson To: Bill Paul cc: hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: How the hell does one create a new bus?! In-Reply-To: <199902142158.QAA00307@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 14 Feb 1999, Bill Paul wrote: > Grrrr. Alright, I give up: how does one create a new 'bus' layer? > By that I mean like /sys/dev/iicbus and /sys/dev/smbus. Yes, I've read > the code in these two directories, but I'm confused as to which parts > relate to the bus architecture in general and which parts are speficic > to the I2C and system management implementation. > > >From what I can tell, you need the following: > > - foobus_if.m, a file which describes the functions that drivers for > devices attached to this kind bus can perform. Each xxx_if.m file defines a set of functions which are implemented by (some) drivers as you can see. This can be used in a couple of ways: 1. If a number of different types of the 'bus' hardware can have the same set of child devices, one can define an interface which each of the different bus device implements that can be called by the attached child devices to hide the differences between the hardware. Code in the drivers for child devices might look like this: /* * A ficitious 'probe' method for a device attached to a pci bus. */ int foo_probe(device_t dev) { /* Call a function in the PCI interface on our parent */ if (PCI_READ_CONFIG(device_get_parent(dev), dev, 123, 4) == 456) return ENXIO; } 2. If all the devices attached to a bus can perform similar functions (but implement them in different ways), an interface can be defined to describe these functions. This interface can be called by any client which needs to use the device. In this case, each driver would implement the method, looking something like this: /* * Implementation of BOGUS_SET_LEVEL for the foo driver. */ static void foo_set_level(device_t dev, unsigned int level) { ...; } ... static device_method_t foo_methods[] = { /* Device interface */ ...; /* Bogus interface */ DEVMETHOD(bogus_set_level, foo_set_level), { 0, 0 } }; for an interface declaration (bogus_if.m) which looked like this: INTERFACE bogus; METHOD void set_level { device_t dev; unsigned int level; }; > > - foobus.c and foobus.h > WHAT EXACTLY GOES IN HERE!? > > - fooconf.c and fooconf.h > WHAT EXACTLY GOES IN HERE!? There really isn't any naming convention for files which make up the implementation of a driver (a bus is just a driver which implements the BUS interface and which contains some kind of support for adding child devices either by a PnP scan or by config(8) supplied tables). For SMB, the implementation of the smbus driver seems to be in smbus.[ch], with some kind of utility functions in smbconf.[ch]. To write a file with a 'minimum' driver (in this case a driver named 'foo' attached to a bus named 'bogus'), you might have something like this: struct foo_softc { ...; }; static devclass_t foo_devclass; #define FOO_SOFTC(unit) (struct foo_softc*) \ devclass_get_softc(foo_devclass, unit) static int foo_probe(device_t dev) { if (device exists) return 0; else return ENXIO; } static int foo_attach(device_t dev) { device_printf(dev, "I'm alive\n"); return 0; } static device_method_t foo_methods[] = { /* Device interface */ DEVMETHOD(device_probe, foo_probe), DEVMETHOD(device_attach, foo_attach), { 0, 0 } }; static driver_t foo_driver = { "foo", /* driver name */ foo_methods, /* implementation */ DRIVER_TYPE_NET, /* interrupt class */ sizeof(struct foo_softc), /* size of driver scratch */ }; DRIVER_MODULE(foo, bogus, foo_driver, foo_devclass, 0, 0); > > - Some type of top level driver for the device which implements the > bus. > The implementation of a 'bus' device requires implementing a few extra methods. Typically bus_print_child and bus_read_ivar are implemented by most busses. Generic implementations for many of the bus functions are provided (e.g. bus_generic_print_child) but these must be explicitly specified in the method table (there is no automatic fallback mechanism). Most bus drivers will add child devices to themselves during either probe or attach and will call bus_generic_attach() from their attach method (or just use bus_generic_attach directly instead of having their own implementation of attach) to probe and attach the child devices. > - Various drivers for devices attached to the bus. See above > > In my particular case, I'm trying to create a bus layer for MII-compliant > PHYs attached to ethernet controller chips. The ethernet controller is > the bus controller device: each MII management bus can have up to 32 > PHY devices attached to it (though in general you rarely have more than > two). Each ethernet driver exports three functions to the MII code: > mii_read(), mii_write() and mii_statchg(). The first two allow reading > and writing of the registers of a PHY at a particular address (i.e. > mii_read(dev, phyadd, regaddr), mii_write(dev, phyaddr, regaddr, val)). The > mii_statchg() routine is a callback routine: when one of the lower-level > PHY drivers does a media change, it calls back to the ethernet driver > to let it know. (This is necessary because some media changes also > require updating registers on the ethernet controller itself. For > instance, on the ThunderLAN chip, if the PHY is set for full duplex, the > ThunderLAN chip itself also has to be programmed for full duplex at the > same time). Here you would define an MII interface (mii_if.m) which describes mii_read() etc. Each ethernet driver would contain an implementation of a driver which implements this interface. The driver should be called 'mii' for all ethernet devices since the PHY driver won't know what kind of hardware they will be attached to. There is no problem with multiple drivers having the same name as long as there is no ambiguity. For instance if each driver was attached to a different kind of parent device (ethernet device) there is no ambiguity. If the device probe is performed using accurate PnP data (e.g. pci), then there is also no ambiguity. A fraction of the device tree might look like this: ... --------pcib0 The host-pci bridge | |-------pci0 Top pci bus | |-------xl0 An ethernet device | | | |-------mii0 and its mii component | |-------fxp0 | | | |-------mii1 | |-------pcib1 A pci-pci bridge | |-------pci1 With a second pci bus | |-------de0 | | | |-------mii2 | |-------de1 | |-------mii3 Since the code in -current doesn't use the bus interface for pci though, you will need to fake it out a little by providing a stub driver for each ethernet driver which attaches an mii device (I'm gradually working on moving the pci code to the new system but I don't have much FreeBSD time at the moment): root0 | |-------xl0 /* stub driver */ | | | |-------mii0 | |-------fxp0 | |-------mii1 The stub probe method for xl0 would create a device for its mii driver to use: xl_stub_probe(device_t dev) { /* * Add a device with the name 'mii' and allocate a unit * number for it automatically. */ device_add_child(dev, "mii", -1, NULL); return 0; } The stub driver would use bus_generic_attach() as its implementation of device_attach and would probably use bus_generic_print_child too to help in printing the probe message. The real attach method for the xl driver would attach an instance of the stub device to the root bus to allow the mii to be probed later when the root bus is probed: xl_attach(...) { ...; device_add_child(root_bus, "xl", -1, NULL); } > > The PHY drivers themselves (as they are now) export three functions to > the MII glue code: foophy_probe(), foophy_attach() and foophy_service(). > The middle MII layer exports mii_phy_probe(), mii_pollstat(), mii_statchg() > and mii_tick() back to the ethernet driver. For the PHY drivers, you would probably define a second interface to describe the service method and write the drivers as above, possibly calling MII_XXX methods on the parent device and registering the drivers under the mii bus: DRIVER_MODULE(foophy, mii, foophy_driver, foophy_devclass, 0, 0); This makes sure that the foophy driver is available to any device connected to any kind of mii. > > I've faked things up for now using linker sets, but I'd prefer to make > everything fit into the bus framework if possible. Unfortunately, there > doesn't appear to be a nice generic example that shows how to create a > new bus layer, and the existing code confuses the hell out of me. For > example, both the iicbus and smbus code use interrupt routines, but the > MII code doesn't need interrupts (PHY devices don't normally generate > interrupts). Also, how do I know exactly what goes into the foobus.c > and fooconf.c modules? The smbconf.c and iiconf.c modules appear to > have 'request_bus' routines that do things with tsleep(); what is this > for? Does every bus need this or is it specific to the I2C and SMB stuff? > The ppbus code is no help as it doesn't actually use this framework, and > the usb bus stuff is a mutant pile of macros and #ifdefs. I think that the request_bus and tsleep stuff is just part of the implementation of smbus and can be ignored (for your purposes). > > What this stuff needs is a developer's guide; a clearcut explanation of > how to create new busses, how to create top level bus drivers and how to > create drivers for devices attached to busses. If anyone can point me at > such a guide or can just explain to me how this nonsense is supposed to > work, I'd be grateful. I hope I've explained some things. There isn't a developer's guide as yet, I'm afraid and I don't really have time to write one :-(. Perhaps one of the people who has used the code might like to tackle it (or you might if you manage to struggle through implementing this thing...) If anyone wants to write such a guide, please go ahead and feel free to ask me any questions about how the thing is supposed to work. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 16:52:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07128 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 16:52:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07110; Sun, 14 Feb 1999 16:52:27 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA18367; Sun, 14 Feb 1999 16:44:47 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdq18365; Mon Feb 15 00:44:40 1999 Date: Sun, 14 Feb 1999 16:44:37 -0800 (PST) From: Julian Elischer To: Doug Rabson cc: Bill Paul , hackers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: How the hell does one create a new bus?! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The trouble is Doug, that until there IS a developer's guide, the only person capable if moving PCI and ISA to your scheme, is you. and as you pointed out.. you're short of time right now.. This stuff is very cryptic. On Mon, 15 Feb 1999, Doug Rabson wrote: > I hope I've explained some things. There isn't a developer's guide as > yet, I'm afraid and I don't really have time to write one :-(. Perhaps > one of the people who has used the code might like to tackle it (or you > might if you manage to struggle through implementing this thing...) > > If anyone wants to write such a guide, please go ahead and feel free to > ask me any questions about how the thing is supposed to work. > This email in itself has cleared up a few things.. but there is still a nead for a more general overview which should be read before getting to this level of detail.. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 17:09:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08270 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 17:09:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08262 for ; Sun, 14 Feb 1999 17:09:13 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id RAA23841; Sun, 14 Feb 1999 17:09:03 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA02116; Sun, 14 Feb 1999 17:09:02 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA09078; Sun, 14 Feb 1999 17:09:00 -0800 (PST) From: Don Lewis Message-Id: <199902150109.RAA09078@salsa.gv.tsc.tdk.com> Date: Sun, 14 Feb 1999 17:09:00 -0800 In-Reply-To: Terry Lambert "Re: portability of shm, mmap, pipes and socket IPC" (Feb 9, 10:46pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 9, 10:46pm, Terry Lambert wrote: } Subject: Re: portability of shm, mmap, pipes and socket IPC } FreeBSD does not select writeable on sockets. This does not appear to be correct. What about the call path: select() selscan() (*fp->f_ops->fo_poll)() [ soo_poll() for sockets ] so->so_proto->pr_usrreqs->pru_sopoll() [ sopoll() for TCP ] sowriteable() } Sockets can be } written if there are mbuf's available, and mbuf's can } become unavailable asynchronously between the select } coming true and the subsequent write. While it is certainly possible to get an occasional false positive if an mbuf isn't available, selecting for write is still useful to keep from spinning on a socket that isn't writeable because its TCP send window is full. This condition can persist indefinitely and the socket won't become writeable again until the peer consumes some data. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 17:36:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10602 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 17:36:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bytor.rush.net (bytor.rush.net [209.45.245.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10597; Sun, 14 Feb 1999 17:36:50 -0800 (PST) (envelope-from lynch@rush.net) Received: from localhost (lynch@localhost) by bytor.rush.net (8.9.1/8.8.8) with ESMTP id UAA19819; Sun, 14 Feb 1999 20:36:49 -0500 (EST) (envelope-from lynch@rush.net) Date: Sun, 14 Feb 1999 20:36:49 -0500 (EST) From: Pat Lynch To: chat@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: FUNY (oops forgot the time) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks DES for pointing out I forgot the time : Meeting will start between 7:30 and 8:00 PM< with formalities to start around 8:30 I think (gives us time to socialize and wait for stragglers =) -Pat ___________________________________________________________________________ Pat Lynch lynch@rush.net Systems Administrator Rush Networking Remark made by Bertrand Meyer (inventor of the Eiffel language) at a panel discussion at OOPSLA '89: "COBOL programmers are destined to code COBOL for the rest of their lives, and thereafter." ___________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:00:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12424 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:00:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12419 for ; Sun, 14 Feb 1999 18:00:57 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id SAA98447; Sun, 14 Feb 1999 18:00:12 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902150200.SAA98447@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Randall Hopper cc: hackers@FreeBSD.ORG Subject: Re: "XESS" Spreadsheet for FreeBSD In-reply-to: Your message of "Sun, 14 Feb 1999 17:00:45 EST." <19990214170045.B1363@pagesz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 18:00:12 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I mailed a request for a FreeBSD version of Xess ! Tnks for the pointer! Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:05:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13174 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:05:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13169 for ; Sun, 14 Feb 1999 18:05:40 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id SAA98492; Sun, 14 Feb 1999 18:04:21 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902150204.SAA98492@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? In-reply-to: Your message of "Sun, 14 Feb 1999 13:49:04 PST." <199902142149.NAA05644@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 18:04:21 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Count me in as a tester . I have a "trash box " -- P200MMx system which I use for testing or developing stuff just like netbooting 8) Tnks! Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:08:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13697 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:08:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13679 for ; Sun, 14 Feb 1999 18:08:49 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4034.ime.net [209.90.195.44]) by Loki.orland.u91.k12.me.us (8.9.3/8.8.8-Loki) with SMTP id VAA01731; Sun, 14 Feb 1999 21:08:28 -0500 (EST) (envelope-from netmonger@genesis.ispace.com) X-Server-ID: Loki.orland.u91.k12.me.us, OCSNet - Orland Maine USA X-Coord-Name: Drew "Droobie" Baxter, OneNetwork Exchange X-Coord-Addr: Droobie@Openlink.orland.me.us X-Coord-Pager: USA: 207-471-2719, http://pagedroo.orland.me.us Message-Id: <4.1.19990214210636.03aaa2d0@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 14 Feb 1999 21:07:43 -0500 To: Amancio Hasty , Mike Smith From: Drew Baxter Subject: Re: Oskit and 3.0? Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902150204.SAA98492@rah.star-gate.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:04 PM 2/14/99 , Amancio Hasty wrote: >Count me in as a tester . I have a "trash box " -- P200MMx system which I use >for testing or developing stuff just like netbooting 8) I could put something together for humor.. I'll play the testing game. After I get my damn cd0c to do detection. for some reason I'm getting a panic on startup right now.. I knew I should have left well enough alone and not installed FreeBSD on my home machine. Kudos on System Commander, which makes multibooting painless... I'll just have to fix the little problem though.. --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP DSS/1024 Public Key ID: 0x409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:13:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14304 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:13:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles146.castles.com [208.214.165.146]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14296 for ; Sun, 14 Feb 1999 18:13:48 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA07060; Sun, 14 Feb 1999 18:09:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902150209.SAA07060@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Amancio Hasty cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Testing (was Re: Oskit and 3.0? ) In-reply-to: Your message of "Sun, 14 Feb 1999 18:04:21 PST." <199902150204.SAA98492@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 18:09:10 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Count me in as a tester . I have a "trash box " -- P200MMx system which I use > for testing or developing stuff just like netbooting 8) If you care a damn about testing, test the most recent 3.0 snapshot off current.freebsd.org (and shame on you for not starting that a week ago). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:19:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14822 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:19:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14817 for ; Sun, 14 Feb 1999 18:19:10 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id SAA98610; Sun, 14 Feb 1999 18:18:20 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902150218.SAA98610@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Drew Baxter cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: Oskit and 3.0? In-reply-to: Your message of "Sun, 14 Feb 1999 21:07:43 EST." <4.1.19990214210636.03aaa2d0@genesis.ispace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 18:18:19 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, what I am really interested on is netbooting or booting OSKIT kernels from my FreeBSD boxes whithout having to use Linux or a boot floopy. Currently, I can drop Oskit kernels into a linux partition boot GRUB from a floppy then boot the oskit kernel or boot "netboot" from a floopy. I guess the oskit team has to catch up to FreeBSD 3.0 or FreeBSD 4.0 . I will post next on the OSKIT mailing list because I am pretty sure that the OSKIT team uses FreeBSD a lot. Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:26:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA15695 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:26:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA15685 for ; Sun, 14 Feb 1999 18:26:01 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id SAA98697; Sun, 14 Feb 1999 18:24:57 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902150224.SAA98697@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Kernel threads --- Re: Testing (was Re: Oskit and 3.0? ) In-reply-to: Your message of "Sun, 14 Feb 1999 18:09:10 PST." <199902150209.SAA07060@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Feb 1999 18:24:57 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Aye Aye, Captain! --------------------------- That a side what I am really after is high performance kernel threads not necessarily posix to be use in Kaffe or Sun's JDK. OSKIT has a cool implementation of kernel threads and it so happens that the OSKIT team ported Kaffe to OSKIT as a kernel module -- the oskit kaffe port uses kernel threads 8) Amancio > > Count me in as a tester . I have a "trash box " -- P200MMx system which I use > > for testing or developing stuff just like netbooting 8) > > If you care a damn about testing, test the most recent 3.0 snapshot off > current.freebsd.org (and shame on you for not starting that a week ago). > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:33:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA16375 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:33:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA16366; Sun, 14 Feb 1999 18:33:05 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id VAA07896; Sun, 14 Feb 1999 21:32:54 -0500 (EST) (envelope-from wollman) Date: Sun, 14 Feb 1999 21:32:54 -0500 (EST) From: Garrett Wollman Message-Id: <199902150232.VAA07896@khavrinen.lcs.mit.edu> To: Julian Elischer Cc: Doug Rabson , Bill Paul , hackers@FreeBSD.ORG, current@FreeBSD.ORG Reply-To: new-bus-arch@bostonradio.org Subject: Re: How the hell does one create a new bus?! In-Reply-To: References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > The trouble is Doug, that until there IS a developer's guide, the only > person capable if moving PCI and ISA to your scheme, is you. > and as you pointed out.. you're short of time right now.. No, there are more people than just Doug. Certainly me (if I had time), Nicolas (if he had time), probably Andrew Gallatin since he's done a lot of work on the Alpha side of things (but he probably has no more time than the rest of us). There is a proper mailing list for this discussion, and we'd be happy to talk over any doco that someone should choose to write. Please take any followups to . -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 18:41:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA17489 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 18:41:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17484 for ; Sun, 14 Feb 1999 18:41:43 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: from localhost (mrcpu@localhost) by schizo.cdsnet.net (8.8.8/8.7.3) with SMTP id SAA10192 for ; Sun, 14 Feb 1999 18:36:21 -0800 (PST) Date: Sun, 14 Feb 1999 18:36:20 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@FreeBSD.ORG Subject: Processor affinity? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Noticed somethign a little odd with a 3.1-stable supped a few days ago. There were only 3 processes of any significance running on a dual processor P6. mysql, top, and a perl script pumping kazillions of small records into the mysql database. The perl script was basically burning 99.9% of the CPU. Mysql was chewing up 40-60% of the CPU. For some reason that on the suface does not make sense to me, the perl script moved back and forth among the CPU's, just about like clockwork, every update or so of top. This seems odd to me, in that given the size of the program (small), and the amount of CPU burning, it would be better if the perl process stayed stuck to 1 CPU to maximise the use of the cache (512k) of that CPU, instead of having to wander around. Is there some way to set processor affinity on a process? Or some tweak to some sysctl variable somewhere that I can take advantage of? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 19:11:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20615 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 19:11:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20610 for ; Sun, 14 Feb 1999 19:11:32 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id EAA26605 for freebsd-hackers@FreeBSD.ORG; Mon, 15 Feb 1999 04:11:29 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 8354A1512; Mon, 15 Feb 1999 01:00:39 +0100 (CET) Date: Mon, 15 Feb 1999 01:00:39 +0100 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: install -C Message-ID: <19990215010039.A7717@keltia.freenix.fr> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <86u2wpc0iy.fsf@niobe.ewox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <86u2wpc0iy.fsf@niobe.ewox.org>; from Dag-Erling Smorgrav on Sun, Feb 14, 1999 at 01:05:41AM +0100 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#5026 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Dag-Erling Smorgrav: > I can understand the reason for the first two (avoid needlessly > breaking dependencies), but not for the last three. In any case, I > think it would be better if we always used whatever the admin has set > INSTALL to in /etc/make.conf, and make "install -C" the default. I think it avoid some race conditions that could be deadly. Bruce sent a message about this a while ago. Without '-C', install will truncate the target file before writing; now imagine the copy fails for some reason, you're hosed big time. With '-C', it is copied under another name, the target is unlinked then the file is renamed. You're safe. > My main argument against always installing certain files with "install > -C" is that makes it very difficult to clean up after a major upgrade, > since you can't rely on "live" files to have a recent timestamp. I've > talked to people on IRC who deleted their Elf interpreter because its > mtime predated their last make world. Shooting yourself in the foot The a.out loader used to be protected, why not doing it for ld-elf.so too ? -r-xr-xr-x 1 root wheel - 62872 Jan 18 00:01 /usr/libexec/ld-elf.so.1* -r-xr-xr-x 1 root wheel schg 77824 Dec 29 20:14 /usr/libexec/ld.so* ^^^^ -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 20:10:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26661 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 20:10:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26656 for ; Sun, 14 Feb 1999 20:10:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA12131; Sun, 14 Feb 1999 20:10:27 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 20:10:27 -0800 (PST) From: Matthew Dillon Message-Id: <199902150410.UAA12131@apollo.backplane.com> To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Processor affinity? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Noticed somethign a little odd with a 3.1-stable supped a few days ago. : :There were only 3 processes of any significance running on a dual :processor P6. : :mysql, top, and a perl script pumping kazillions of small records into the :mysql database. : :The perl script was basically burning 99.9% of the CPU. Mysql was chewing :up 40-60% of the CPU. : :For some reason that on the suface does not make sense to me, the perl :script moved back and forth among the CPU's, just about like clockwork, :every update or so of top. : :This seems odd to me, in that given the size of the program (small), and :the amount of CPU burning, it would be better if the perl process stayed :stuck to 1 CPU to maximise the use of the cache (512k) of that CPU, :instead of having to wander around. : :Is there some way to set processor affinity on a process? Or some tweak :to some sysctl variable somewhere that I can take advantage of? Doing processor affinity properly is very difficult. It isn't as simple as trying to keep a process on a specific cpu. Whatever algorithm is chosen must deal with the situation under a greater process load. Often, as on IRIX 6.1 boxes, affinity could make things worse rather then better by unbalancing the cpu's. Processor affinity makes sense when you have a lot of processors ( you can schedule a process to a group of cpu's to maintain reasonable balancing across the system), but doesn't make much sense if you only have 2-4. Note that processor affinity scheduling is different from hard-assigning a process to a processor. Even so, there are very few circumstances where even hard-assigning will do a better job then letting the scheduler do it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 20:48:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00204 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 20:48:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00198 for ; Sun, 14 Feb 1999 20:48:10 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id UAA29174; Sun, 14 Feb 1999 20:47:50 -0800 Date: Sun, 14 Feb 1999 20:47:50 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Processor affinity? In-Reply-To: <199902150410.UAA12131@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > as trying to keep a process on a specific cpu. Whatever algorithm is > chosen must deal with the situation under a greater process load. Often, > as on IRIX 6.1 boxes, affinity could make things worse rather then better > by unbalancing the cpu's. Processor affinity makes sense when you have > a lot of processors ( you can schedule a process to a group of cpu's to > maintain reasonable balancing across the system), but doesn't make much > sense if you only have 2-4. > > Note that processor affinity scheduling is different from hard-assigning > a process to a processor. Even so, there are very few circumstances where > even hard-assigning will do a better job then letting the scheduler do it. > Doesn't it also really depend upon the cache architecture? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 21:04:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01737 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 21:04:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01731 for ; Sun, 14 Feb 1999 21:04:27 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA25573; Sun, 14 Feb 1999 22:04:26 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA24224; Sun, 14 Feb 1999 22:04:24 -0700 Date: Sun, 14 Feb 1999 22:04:24 -0700 Message-Id: <199902150504.WAA24224@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ollivier Robert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: install -C In-Reply-To: <19990215010039.A7717@keltia.freenix.fr> References: <86u2wpc0iy.fsf@niobe.ewox.org> <19990215010039.A7717@keltia.freenix.fr> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > My main argument against always installing certain files with "install > > -C" is that makes it very difficult to clean up after a major upgrade, > > since you can't rely on "live" files to have a recent timestamp. I've > > talked to people on IRC who deleted their Elf interpreter because its > > mtime predated their last make world. Shooting yourself in the foot > > The a.out loader used to be protected, why not doing it for ld-elf.so too ? You're not the first person to suggest it, but hopefully (now) the last. I just modified the makefile for the elf loader to set the system immutable flag. Unfortunately, it didn't happen until after the 3.1 TAG went down, so I'll merge it in later after Jordan has opened up the tree again. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 21:21:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03618 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 21:21:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03605 for ; Sun, 14 Feb 1999 21:21:48 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA12394; Sun, 14 Feb 1999 21:21:46 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 21:21:46 -0800 (PST) From: Matthew Dillon Message-Id: <199902150521.VAA12394@apollo.backplane.com> To: Matthew Jacob Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Processor affinity? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> maintain reasonable balancing across the system), but doesn't make much :> sense if you only have 2-4. :> :> Note that processor affinity scheduling is different from hard-assigning :> a process to a processor. Even so, there are very few circumstances where :> even hard-assigning will do a better job then letting the scheduler do it. :> : :Doesn't it also really depend upon the cache architecture? Not particularly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 22:39:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11874 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 22:39:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11869 for ; Sun, 14 Feb 1999 22:39:04 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id WAA29515; Sun, 14 Feb 1999 22:38:43 -0800 Date: Sun, 14 Feb 1999 22:38:43 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Processor affinity? In-Reply-To: <199902150521.VAA12394@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Really? Hmm.. I would have thought for a machine that with local cache but expensive global access (e.g., sun4d architecture) that affinity is a win. Oh well, not my area of expertise. On Sun, 14 Feb 1999, Matthew Dillon wrote: > :> maintain reasonable balancing across the system), but doesn't make much > :> sense if you only have 2-4. > :> > :> Note that processor affinity scheduling is different from hard-assigning > :> a process to a processor. Even so, there are very few circumstances where > :> even hard-assigning will do a better job then letting the scheduler do it. > :> > : > :Doesn't it also really depend upon the cache architecture? > > Not particularly. > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 22:49:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12962 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 22:49:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12947; Sun, 14 Feb 1999 22:49:07 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.9.2/8.7.3) id HAA27994; Mon, 15 Feb 1999 07:48:43 +0100 (MET) Message-ID: <19990215074843.A27954@cons.org> Date: Mon, 15 Feb 1999 07:48:43 +0100 From: Martin Cracauer To: Dag-Erling Smorgrav , wpaul@FreeBSD.ORG Cc: nsouch@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Regarding tcpdump and plip References: <86n22pg5z6.fsf@niobe.ewox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <86n22pg5z6.fsf@niobe.ewox.org>; from Dag-Erling Smorgrav on Mon, Feb 08, 1999 at 12:16:13AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <86n22pg5z6.fsf@niobe.ewox.org>, Dag-Erling Smorgrav wrote: > [moving over to -hackers...] > > As I mentioned in earlier correspondance on -current, tcpdump is > broken wrt plip connections. There is a PR with a fix by Bill Fenner, which he didn't commit since he cannot test it. Please try it out if you can and see if it's the same as yours. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 22:50:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13369 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 22:50:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13363 for ; Sun, 14 Feb 1999 22:50:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA12919; Sun, 14 Feb 1999 22:50:02 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 22:50:02 -0800 (PST) From: Matthew Dillon Message-Id: <199902150650.WAA12919@apollo.backplane.com> To: Matthew Jacob Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Processor affinity? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :Really? Hmm.. I would have thought for a machine that with local cache :but expensive global access (e.g., sun4d architecture) that affinity is a :win. Oh well, not my area of expertise. All modern SMP designs have per-cpu caches and nearly all have local L1 and L2 caches ( because the L2 caches are what tie into the SMP mechanisms of the backplane ). The expense of a main memory access verses a cache access is always pretty big. There are various kinds of SMP caching schemes, but most of the amount to the same generalities and only differ in their basic performance characteristic. For example, a number of modern SMP designs use an L2-read-shared and L2-write-allocate scheme and one L2 cache that misses is actually able to get the data from another L2 cache belonging to another cpu rather then have to go to main memory. The only issue with processor affinity, really, is the actual load on the main memory. Processor affinity only makes sense when the load on main memory is relatively high. Typically, SMP systems have a relatively low main memory load ( and high L1 and L2 cache memory load ), so until you have enough cpu's banging on the same main memory to saturate it, processor affinity is usually wash. It makes sense on a big 32+ cpu Solaris or SGI system, but not much sense on a 2 or 4 cpu system. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 23:03:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA15004 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 23:03:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA14997 for ; Sun, 14 Feb 1999 23:03:08 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id XAA29602; Sun, 14 Feb 1999 23:02:56 -0800 Date: Sun, 14 Feb 1999 23:02:56 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon cc: hackers@FreeBSD.ORG Subject: Re: Processor affinity? In-Reply-To: <199902150650.WAA12919@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The only issue with processor affinity, really, is the actual load on > the main memory. Processor affinity only makes sense when the load on > main memory is relatively high. Typically, SMP systems have a relatively > low main memory load ( and high L1 and L2 cache memory load ), so until > you have enough cpu's banging on the same main memory to saturate it, > processor affinity is usually wash. It makes sense on a big 32+ cpu > Solaris or SGI system, but not much sense on a 2 or 4 cpu system. Right- I think I knew this. I guess I'm dating myself in that I kept on thinking of how useful processor affinity was on the Kubota (aka 'Ardent') 4 banger MIPS-3000 machines- but the cache architectures of this machine is much more like the SGI systems than the 4 way SMP machines you describe. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 23:39:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19169 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 23:39:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns10.nokia.com (ns10.nokia.com [131.228.6.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA19163 for ; Sun, 14 Feb 1999 23:39:54 -0800 (PST) (envelope-from marc.solsona@research.nokia.com) Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns10.nokia.com (8.8.8/8.6.9) with ESMTP id JAA10020 for ; Mon, 15 Feb 1999 09:39:53 +0200 (EET) Received: from pupu.research.nokia.com (pupu.research.nokia.com [131.228.13.130]) by pepper.research.nokia.com (8.9.1a/8.9.1) with ESMTP id JAA05291 for ; Mon, 15 Feb 1999 09:39:52 +0200 (EET) Received: from research.nokia.com (playa.research.nokia.com [131.228.13.35]) by pupu.research.nokia.com (8.9.1a/8.9.1) with ESMTP id JAA01617 for ; Mon, 15 Feb 1999 09:37:15 +0200 (EET) Message-ID: <36C7CF48.C8220783@research.nokia.com> Date: Mon, 15 Feb 1999 09:39:52 +0200 From: Marc Solsona Palomar X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: anoncvs, allocation limit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I've been using the 2.2.5 release for a while, and I've decided to go STABLE (too many upgrades so far). As I have only the 225CD I did the instalation of the 2.2.8 release with a passive ftp (slow but painless), and the machine is running perfectly (this one actually). The next step was to cvsup it to 2.2-STABLE, but no luck. The machine is behind a strict firewall and cvsup connections are unsuccessful. I don't have an account outside so I cannot use ssh. Then I've tried anoncvs: CVSROOT=anoncvs@anoncvs.freebsd.org:/cvs CVS_RSH=ssh And it was working quite well untill: S-> checkout (/cvs/src/share/dict/web2,v, 1.4.2.1, , web2) cvs [server aborted]: can not allocate 2486905 bytes Can I avoid the allocation problem in cvs? I can do it nightly, and the bandwidth is not a real problem, neither disk space. And besides I feel quite confortable working with cvs. Is there any other possibility with cvsup?? Is there any free account somewhere so I can create a tunnel? Known cvsup servers working with any other port number? Thank you, I have faith... -- Marc Solsona Palomar || mailto: marc.solsona@research.nokia.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 23:44:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19868 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 23:44:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA19858 for ; Sun, 14 Feb 1999 23:44:23 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 17662 invoked from network); 15 Feb 1999 07:44:19 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 07:44:19 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id CAA00356; Mon, 15 Feb 1999 02:44:18 -0500 (EST) Message-Id: <199902150744.CAA00356@y.dyson.net> Subject: Re: Processor affinity? In-Reply-To: <199902150650.WAA12919@apollo.backplane.com> from Matthew Dillon at "Feb 14, 99 10:50:02 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 02:44:18 -0500 (EST) Cc: mjacob@feral.com, mrcpu@internetcds.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > : > : > :Really? Hmm.. I would have thought for a machine that with local cache > :but expensive global access (e.g., sun4d architecture) that affinity is a > :win. Oh well, not my area of expertise. > > All modern SMP designs have per-cpu caches and nearly all have local > L1 and L2 caches ( because the L2 caches are what tie into the SMP > mechanisms of the backplane ). The expense of a main memory access > verses a cache access is always pretty big. > > There are various kinds of SMP caching schemes, but most of the amount > to the same generalities and only differ in their basic performance > characteristic. For example, a number of modern SMP designs use an > L2-read-shared and L2-write-allocate scheme and one L2 cache that misses > is actually able to get the data from another L2 cache belonging to > another cpu rather then have to go to main memory. > > The only issue with processor affinity, really, is the actual load on > the main memory. Processor affinity only makes sense when the load on > main memory is relatively high. Typically, SMP systems have a relatively > low main memory load ( and high L1 and L2 cache memory load ), so until > you have enough cpu's banging on the same main memory to saturate it, > processor affinity is usually wash. It makes sense on a big 32+ cpu > Solaris or SGI system, but not much sense on a 2 or 4 cpu system. > It actually does make sense on a 2 or 4 cpu system. The problem with performance associated with machines without a loaded memory bus isn't bandwidth, but is latency. On a 2 or 4 cpu system, the affinity should decay rapidly on # of active CPU cycles. I do have affinity code for SMP, and it makes a positive difference in performance, even with the big-lock FreeBSD kernel. The reason for diminishing gains on a 2 or 4 cpu system isn't bandwidth as much as it is the availability of fewer CPUs to choose from. By blindly choosing the wrong cpu, there will be much more latency assocated with refilling the cache on context switch. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 23:46:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20032 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 23:46:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA20023 for ; Sun, 14 Feb 1999 23:46:23 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 18789 invoked from network); 15 Feb 1999 07:46:20 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 07:46:20 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id CAA00364; Mon, 15 Feb 1999 02:46:21 -0500 (EST) Message-Id: <199902150746.CAA00364@y.dyson.net> Subject: Re: Processor affinity? In-Reply-To: from Jaye Mathisen at "Feb 14, 99 06:36:20 pm" To: mrcpu@internetcds.com (Jaye Mathisen) Date: Mon, 15 Feb 1999 02:46:21 -0500 (EST) Cc: hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jaye Mathisen said: > > For some reason that on the suface does not make sense to me, the perl > script moved back and forth among the CPU's, just about like clockwork, > every update or so of top. > Yes, that is a pseudo-bug in the FreeBSD SMP scheduler. It is fun to see the CPU activity lights on a box that shows it, with CPU utilization bouncing from CPU to CPU!!! Indeed, a few changes should fix that :-). I noticed that on a quad PPro about 2yrs ago!!! -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Feb 14 23:55:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20848 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 23:55:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tahiti.oss.uswest.net (tahiti.oss.uswest.net [204.147.85.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA20843 for ; Sun, 14 Feb 1999 23:55:40 -0800 (PST) (envelope-from rantapaa@uswest.net) Received: (from rantapaa@localhost) by tahiti.oss.uswest.net (8.8.5/8.6.12) id BAA21520; Mon, 15 Feb 1999 01:55:34 -0600 (CST) Message-ID: <19990215015534.A20671@oss.uswest.net> Date: Mon, 15 Feb 1999 01:55:34 -0600 From: Erik E Rantapaa To: hackers@FreeBSD.ORG Subject: select() can set errno to ECHILD? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have code running under 2.2.x which claims that this is happening. This behaviour is not documented in the man pages. I have not been able to duplicate it in a simple test program I wrote, but the log files for a Merit RADIUS server say that it is happening. Is this at all possible? Erik Rantapaa rantapaa@uswest.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 01:03:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA00781 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 01:03:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA00753 for ; Mon, 15 Feb 1999 01:03:11 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id BAA26388; Mon, 15 Feb 1999 01:02:51 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id BAA03244; Mon, 15 Feb 1999 01:02:50 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id BAA09932; Mon, 15 Feb 1999 01:02:47 -0800 (PST) From: Don Lewis Message-Id: <199902150902.BAA09932@salsa.gv.tsc.tdk.com> Date: Mon, 15 Feb 1999 01:02:47 -0800 In-Reply-To: Terry Lambert "Re: portability of shm, mmap, pipes and socket IPC" (Feb 10, 4:30pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Terry Lambert , peter@netplex.com.au (Peter Wemm) Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 10, 4:30pm, Terry Lambert wrote: } Subject: Re: portability of shm, mmap, pipes and socket IPC } > > FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, } > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, } > > since sockets are not backed by true vnode objects. } > } > Terry, read the bloody source before spreading unverified FUD like this.. } > The fcntl(2) ops F_SETOWN/F_GETOWN are translated into FIOSETOWN/FIOGETOWN } > ioctl's and are fully implemented. } } Sorry; I didn't realize that someone had kludged this to "work" after } the last time someone complained about it not working. It's "worked" since day 1. Take a look at rev 1.1 of kern_descrip.c. The F_SETOWN code in the fcntl() implementation contained the following: case F_SETOWN: if (fp->f_type == DTYPE_SOCKET) { ((struct socket *)fp->f_data)->so_pgid = uap->arg; return (0); } ... return ((*fp->f_ops->fo_ioctl) (fp, (int)TIOCSPGRP, (caddr_t)&uap->arg, p)); The ioctl() implementation in rev 1.1 of sys_generic.c contains: case FIOSETOWN: tmp = *(int *)data; if (fp->f_type == DTYPE_SOCKET) { ((struct socket *)fp->f_data)->so_pgid = tmp; error = 0; break; } ... error = (*fp->f_ops->fo_ioctl) (fp, (int)TIOCSPGRP, (caddr_t)&tmp, p); break; The soo_ioctl() implementation in rev 1.1 of sys_socket.c contains: case SIOCSPGRP: so->so_pgid = *(int *)data; return (0); The current implementation is less of a kludge since it removes duplicated special case code for sockets from two different parts of the kernel. BTW, mapping F_SETOWN to TIOCSPGRP is also the wrong thing to do for tty devices since it ties this functionality to the notion of the controlling terminal. Using TIOCSPGRP means that you can't open a tty device and do a F_SETOWN on the descriptor if a different tty device is your controlling tty, and you can't do F_SETOWN on multiple open tty devices. } > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, } > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, } > > since pipes are not backed by true vnode objects. } > } > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. } > *Only* the file locking parts are not implemented since it's of such little } > value with no seek space. } } Hmmmm. From my reading of the sources, this is actually a fairly } recent addition (November 11th, 1998, by Truckman). Nope, it was there before my commit. The previous implementation mapped F_SETOWN on a pipe descriptor to TIOCSPGRP, which has been implemented in pipe_ioctl() since version 1.21 of sys_pipe.c. Older versions of pipe_ioctl() implemented SIOCSPGRP, which would work if the ioctl() was done directly from userland, but the fcntl() interface would not work because it would try to do TIOCSPGRP. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 06:57:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14191 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 06:57:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14179 for ; Mon, 15 Feb 1999 06:57:44 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 15 Feb 1999 14:57:38 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1LNB7V7J; Mon, 15 Feb 1999 14:52:19 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10CPVA-0002Zu-00 for hackers@freebsd.org; Mon, 15 Feb 1999 15:00:00 +0000 To: hackers@FreeBSD.ORG Subject: Endianness in filesystems X-Mailer: nmh v0.26 Organization: Palmer & Harvey McLane Date: Mon, 15 Feb 1999 15:00:00 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I've been trying to mount a laser disk formatted on Solaris (SPARC) on my FreeBSD (x86) machine at home. It looks like I'm running into endiannes problems with the superblock... Has anybody managed to mount Solaris filesystems on FreeBSD before? If so, what did you have to do? Or am I trying to achieve that which there is no code for yet? FWIW, the Solaris box is equally unhappy about mounting FreeBSD formatted filesystems... -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 07:08:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA15442 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 07:08:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA15437 for ; Mon, 15 Feb 1999 07:08:22 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id QAA25908; Mon, 15 Feb 1999 16:05:06 +0100 (CET) Message-ID: <19990215160505.A25875@foobar.franken.de> Date: Mon, 15 Feb 1999 16:05:05 +0100 From: Harold Gutch To: Dom Mitchell , hackers@FreeBSD.ORG Subject: Re: Endianness in filesystems References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Dom Mitchell on Mon, Feb 15, 1999 at 03:00:00PM +0000 X-Organisation: BatmanSystemDistribution X-Mission: To free the world from the Penguin Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Feb 15, 1999 at 03:00:00PM +0000, Dom Mitchell wrote: > Hi all, > > I've been trying to mount a laser disk formatted on Solaris (SPARC) > on my FreeBSD (x86) machine at home. It looks like I'm running into > endiannes problems with the superblock... Has anybody managed to mount > Solaris filesystems on FreeBSD before? If so, what did you have to do? > Or am I trying to achieve that which there is no code for yet? > Have you tried vmount ? I don't know wether it will help you with your exact problem, but you are able to mount quite an amount of filesystems using it, far more than the ones supported by FreeBSD. You can get vmount from ftp://insl1.etec.uni-karlsruhe.de/pub/unix/FreeBSD/vmount/ bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 09:34:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04276 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 09:34:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from relay03.indigo.ie (relay03.indigo.ie [194.125.133.227]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA04258 for ; Mon, 15 Feb 1999 09:34:06 -0800 (PST) (envelope-from nsmart@kira.team400.ie) Received: (qmail 26348 messnum 46222 invoked from network[194.125.214.13/pc214-13.indigo.ie]); 15 Feb 1999 17:34:05 -0000 Received: from pc214-13.indigo.ie (HELO kira.team400.ie) (194.125.214.13) by relay03.indigo.ie (qp 26348) with SMTP; 15 Feb 1999 17:34:05 -0000 Message-ID: <36C85A77.EDBC00F9@kira.team400.ie> Date: Mon, 15 Feb 1999 17:33:43 +0000 From: Niall Smart Organization: Trinity Commerce X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Erik E Rantapaa CC: hackers@FreeBSD.ORG Subject: Re: select() can set errno to ECHILD? References: <19990215015534.A20671@oss.uswest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Erik E Rantapaa wrote: > > I have code running under 2.2.x which claims that this is happening. > This behaviour is not documented in the man pages. I have not been able to > duplicate it in a simple test program I wrote, but the log files for > a Merit RADIUS server say that it is happening. > > Is this at all possible? You are getting SIGCHLD while blocked in select, waitpid with WNOHANG in then handler returns ECHILD, the signal handler fails to restore errno. There was a similar bug in the rpc code a while back. Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 11:05:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14845 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 11:05:22 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA14840 for ; Mon, 15 Feb 1999 11:05:19 -0800 (PST) (envelope-from will@ns.oeno.com) Received: (qmail 13752 invoked by uid 1001); 15 Feb 1999 19:05:12 -0000 To: dyson@iquest.net Cc: hackers@FreeBSD.ORG Subject: Re: Processor affinity? References: <199902150650.WAA12919@apollo.backplane.com> <199902150744.CAA00356@y.dyson.net> From: Ville-Pertti Keinonen Date: 15 Feb 1999 21:03:09 +0200 In-Reply-To: dyson@iquest.net's message of "15 Feb 1999 09:46:22 +0200" Message-ID: <864sonmqvm.fsf@not.oeno.com> Lines: 35 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dyson@iquest.net (John S. Dyson) writes: > # of active CPU cycles. I do have affinity code for SMP, and it makes > a positive difference in performance, even with the big-lock FreeBSD kernel. What does it do? In order to be more useful than a last-run-on hint (which is pretty much useless for time-sharing), it needs to be able to select a thread that doesn't have the highest priority to run when the best processor for the highest-priority runnable (but not active) thread is (momentarily) running a even higher-priority thread. Doing something like this in a BSD scheduler is a bit difficult because of the priority buckets. It seems to me that you either give up O(1) thread selection (the Linux folks seem to be happy with O(n), but I don't like the idea) or have to do something moderately complex (such as per-processor run queues with load balancing, like DEC did with OSF/1). Or did you find a more elegant solution? > The reason for diminishing gains on a 2 or 4 cpu system isn't bandwidth as > much as it is the availability of fewer CPUs to choose from. By blindly > choosing the wrong cpu, there will be much more latency assocated with > refilling the cache on context switch. And with affinity, particularly if it is too strong, you'll occasionally have far more latency associated with getting a thread to run again when the right cpu wasn't available when the thread would "naturally" have run. I suspect that DEC's scheme does this too easily to interactive threads, but haven't done any real testing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 11:44:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21023 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 11:44:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20977 for ; Mon, 15 Feb 1999 11:44:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA18828; Mon, 15 Feb 1999 11:44:24 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 11:44:24 -0800 (PST) From: Matthew Dillon Message-Id: <199902151944.LAA18828@apollo.backplane.com> To: freebsd-hackers@FreeBSD.ORG Subject: inode / exec_map interlock ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I found an interesting interlock situation between what I believe to be a program binaries inode and the exec_map. The machine locked up trying to exec new programs. This was running a make -j10 buildworld on a machine with 16MB of ram configured, while testing my new VM system. I don't think the lockup is due to my VM system, though. It took it 7 hours of extremely heavy paging before it locked up. When I broke the machine out into DDB and did a ps, all of the cc's were stuck in 'inode' wait, while a single ld program was stuck in 'thrd_sleep'. I tracked 'thrd_sleep' down to a vm_map lock and the map down to the exec_map. I tracked down the inode lock to the 'cc' program binary. The inode had one shared lock and 7 waiters. The exec_map appears to own one shared lock with 6 waiters ( but most of the waiters are due to me trying to run other programs before breaking into the DDB ). I am guessing that there is an interlock situation with exec_map and a program inode where one process locks exec_map followed by the program inode, and another locks the program inode followed by exec_map. But I'm not familiar with that section of the code so I would appreciate any help. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:04:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26705 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:04:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA26695 for ; Mon, 15 Feb 1999 12:04:19 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 11326 invoked from network); 15 Feb 1999 20:04:15 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 20:04:15 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA01666; Mon, 15 Feb 1999 15:04:14 -0500 (EST) Message-Id: <199902152004.PAA01666@y.dyson.net> Subject: Re: Processor affinity? In-Reply-To: <864sonmqvm.fsf@not.oeno.com> from Ville-Pertti Keinonen at "Feb 15, 99 09:03:09 pm" To: will@iki.fi (Ville-Pertti Keinonen) Date: Mon, 15 Feb 1999 15:04:14 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen said: > > dyson@iquest.net (John S. Dyson) writes: > > > # of active CPU cycles. I do have affinity code for SMP, and it makes > > a positive difference in performance, even with the big-lock FreeBSD kernel. > > What does it do? > > In order to be more useful than a last-run-on hint (which is pretty > much useless for time-sharing), it needs to be able to select a > thread that doesn't have the highest priority to run when the best > processor for the highest-priority runnable (but not active) thread > is (momentarily) running a even higher-priority thread. > Yes. > > Doing something like this in a BSD scheduler is a bit difficult > because of the priority buckets. It seems to me that you either > give up O(1) thread selection (the Linux folks seem to be happy > with O(n), but I don't like the idea) or have to do something > moderately complex (such as per-processor run queues with load > balancing, like DEC did with OSF/1). > > Or did you find a more elegant solution? > Nope, but the key is to know when to give up. The code as it is bounces around with totally wild abandon. On a small number of processors, a little bit of extra work, isn't bad. Scanning all of the processor queues is not an option, but diddling the effective priorities a little bit is okay (IMO). For realtime, this is of course wrong. > > And with affinity, particularly if it is too strong, you'll > occasionally have far more latency associated with getting a thread > to run again when the right cpu wasn't available when the thread > would "naturally" have run. > Yes. > > I suspect that DEC's scheme does this too easily to interactive > threads, but haven't done any real testing. > IMO, my FreeBSD scheme does appear to improve things, and make performance more consistantly high. It isn't ready for prime-time, because my current kernel work is purely SMP only (I cannot build a working UP kernel!!!) lat_ctx from lmbench does show a significant (but not earth shattering) 20-30% improvement. lat_ctx is a worst nut-case example, so real world processes will see less. More work needs to be done in the pipe context switch area (and in fact, I had been working on the pipe code ending about 2-3mos ago for this reason.) My time in the last 3wks has been tied up doing what I am paid to do, but now I can look more towards really fun stuff. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:27:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00291 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:27:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA00280 for ; Mon, 15 Feb 1999 12:27:09 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 5699 invoked from network); 15 Feb 1999 20:27:06 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 20:27:06 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA01706; Mon, 15 Feb 1999 15:27:04 -0500 (EST) Message-Id: <199902152027.PAA01706@y.dyson.net> Subject: Re: inode / exec_map interlock ? (Ask the authors) In-Reply-To: <199902151944.LAA18828@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 11:44:24 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 15:27:04 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > I found an interesting interlock situation between what I believe to > be a program binaries inode and the exec_map. The machine locked up > trying to exec new programs. > > This was running a make -j10 buildworld on a machine with 16MB of ram > configured, while testing my new VM system. I don't think the lockup is > due to my VM system, though. It took it 7 hours of extremely heavy > paging before it locked up. > > When I broke the machine out into DDB and did a ps, all of the cc's > were stuck in 'inode' wait, while a single ld program was stuck in > 'thrd_sleep'. > > I tracked 'thrd_sleep' down to a vm_map lock and the map down to > the exec_map. I tracked down the inode lock to the 'cc' program binary. > The inode had one shared lock and 7 waiters. The exec_map appears to > own one shared lock with 6 waiters ( but most of the waiters are due to > me trying to run other programs before breaking into the DDB ). > > I am guessing that there is an interlock situation with exec_map and > a program inode where one process locks exec_map followed by the program > inode, and another locks the program inode followed by exec_map. But > I'm not familiar with that section of the code so I would appreciate > any help. > I don't know what you are trying to do in your code, but there is alot of history of problems in that area. I suspect that you might be making one of the mistakes that we used to do, and there is a resource deadlock problem in that area. I suggest that you look at some of the mailing-list archives (either in -hackers or in -current) for information on such deadlocks. It could be cloaked by other subjects. Hint: it isn't generally a good idea to fault data into the kernel. If that isn't the problem, then there are other deadlock issues (throughout the VM system structure), that need to be carefully considered before hacking away. I strongly suggest that if you are hacking away at DGs and my VM code, that you contact the authors, rather than randomly asking questions on the mailing lists :-). Being very busy, I cannot answer questions immediately all the time. However, DG and I are the authors of the existing code (mostly leaving old copyrights on for reasons of convienience), so contact the authors who are available. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:33:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01578 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:33:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01570 for ; Mon, 15 Feb 1999 12:33:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA19277; Mon, 15 Feb 1999 12:33:19 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 12:33:19 -0800 (PST) From: Matthew Dillon Message-Id: <199902152033.MAA19277@apollo.backplane.com> To: "John S. Dyson" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (Ask the authors) References: <199902152027.PAA01706@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :I don't know what you are trying to do in your code, but there is alot of :history of problems in that area. I suspect that you might be making one of :the mistakes that we used to do, and there is a resource deadlock problem in :that area. ??? I'm not making any mistakes as far as I can tell. I haven't touched the locking in the map code. John, please... you have to get out of the habit of assuming that everything is my fault. Either that or read the email more carefully. I believe this to be a long standing bug, not something new. It just happens to be rather hard to reproduce, is all. :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:34:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01645 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:34:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA01630 for ; Mon, 15 Feb 1999 12:33:56 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 13164 invoked from network); 15 Feb 1999 20:33:53 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 20:33:53 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA01773; Mon, 15 Feb 1999 15:33:52 -0500 (EST) Message-Id: <199902152033.PAA01773@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902151944.LAA18828@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 11:44:24 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 15:33:52 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I am guessing that there is an interlock situation with exec_map and > a program inode where one process locks exec_map followed by the program > inode, and another locks the program inode followed by exec_map. But > I'm not familiar with that section of the code so I would appreciate > any help. > Another comment, it would be good to communicate with the code authors, so that we can clear the modifications to the FreeBSD codebase. DG is trying to watch your progress, and I have continually offered to help. I really don't care if you hack my code, but I think that you might be running into some historical mistakes. BTW, have you found/fixed the non-blocking swap pager problem yet. It seems that existing bugs should be fixed first. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:35:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01992 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:35:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01984 for ; Mon, 15 Feb 1999 12:35:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA19311; Mon, 15 Feb 1999 12:35:11 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 12:35:11 -0800 (PST) From: Matthew Dillon Message-Id: <199902152035.MAA19311@apollo.backplane.com> To: "John S. Dyson" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) References: <199902152033.PAA01773@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :BTW, have you found/fixed the non-blocking swap pager problem yet. It seems :that existing bugs should be fixed first. What non-blocking swap pager problem? this is the third time you've brought this up, and the third time I've asked you to explain what the frag you are talking about, and the the third time I have not received any sort of explanation. -Matt :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. : Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:45:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03116 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:45:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03104 for ; Mon, 15 Feb 1999 12:45:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA19435; Mon, 15 Feb 1999 12:44:58 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 12:44:58 -0800 (PST) From: Matthew Dillon Message-Id: <199902152044.MAA19435@apollo.backplane.com> To: Tony Overfield Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? References: <3.0.6.32.19990215142354.03966330@bugs.us.dell.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I think that this closely describes the problem I tried to :report to you earlier, "hangs in inode state". If you fix :it, I'll retest for you to make sure my problem went away :too. : :Tony (looking at that other email) ... Yes! That's exactly the same problem. It looks like you were running the same test I was - a big -jN buildworld. Also, looking at your other email... you have a process stuck in an inode wait state in 'ld' too! Your original email goes back to December 31st, long before I even began working on the VM system ( so there! John! ). Ok, we know where to look -- it's obviously related to the exec_map. It's just a matter of finding where in the code the locks are being made out-of-order. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 12:54:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04055 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 12:54:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04050 for ; Mon, 15 Feb 1999 12:54:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA19505; Mon, 15 Feb 1999 12:54:14 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 12:54:14 -0800 (PST) From: Matthew Dillon Message-Id: <199902152054.MAA19505@apollo.backplane.com> To: Tony Overfield , freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? References: <3.0.6.32.19990215142354.03966330@bugs.us.dell.com> <199902152044.MAA19435@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Your original email goes back to December 31st, long before I even began : working on the VM system ( so there! John! ). ( that is, before I started committing things other then comment adds ) ( Matt sticks out his tongue and makes a face ) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 13:12:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06511 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 13:12:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from gate.usaor.net (gate.usaor.net [209.166.160.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06494; Mon, 15 Feb 1999 13:12:45 -0800 (PST) (envelope-from heart@usaor.net) Received: from president (m11-vp03.sgi.net [209.166.185.76]) by gate.usaor.net (8.8.8/8.8.5) with SMTP id PAA22427; Mon, 15 Feb 1999 15:52:58 -0500 (EST) Message-ID: <069701be5925$4ce39d80$4cb9a6d1@president> From: "JD Corcoran" To: "Sally Jo Caldwell" Subject: Fw: Simplified Risk Management Software Date: Mon, 15 Feb 1999 15:46:19 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0694_01BE58FB.640D9580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0694_01BE58FB.640D9580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: JD Corcoran Date: Monday, February 15, 1999 3:42 PM Subject: Re: Simplified Risk Management Software Here's an e-mail that was sent to me that I may be of interest to you.=20 ATTENTION: BROKERS* CHIEF FINANCIAL OFFICERS* INVESTORS* MARKET = MANAGERS* TRADERS:=20 *If you perceive charting, financial data, trading systems and/or = technical analysis as vital to your success, this is a piece of software = you need to examine.=20 *This software is the most innovative product on the market today for = surveillance, accounting, tracking and risk management of your futures = and stock portfolios or any other object or material that has a = calculated value. *It is common knowledge that most market participants are trading = without any or use limited financial instrumentation to guide them. *Do you think it is wise to engage a volatile and unpredictable market = without sophisticated financial software? *SuccesSoft / StockSoft is the missing link if you feel that you have = invested a lot of time and money in your career, yet the market does not = return what you would like.=20 *SuccesSoft 7.0 is the instrument panel which guides you to maximizing = your profits while managing your risk! FACT: Automobiles and jets have mandated vital instrumentation which = enables the operator to maximize their potential.=20 FACT: Markets move rapidly, which greatly affects the participants=92 = capital and market preservation. FACT: This is your opportunity to MAXIMIZE your abilities by utilizing = SuccesSoft 7.0. -------------------------------------------------------------------------= ------- * * * If more market players had used SuccesSoft at initiation, they = would still be vital players in the market today. * * *=20 -------------------------------------------------------------------------= ------- SuccesSoft / StockSoft are NOT more of the same trading software=85it is = based on your financial objectives with strong emphasis on risk = management.=20 It is a market tool that pays for itself everyday just as a GOOD tool = should. It would be a wise decision to invest a few minutes at = http://www.successoft.com in order to see examples of how SuccesSoft 7.0 = can benefit you EVERY DAY!!! Managers, don=92t you think that the traders who you supervise in these = intensively competitive and volatile times should have every ADVANTAGE = working for them to manage risk? Knowing break even is a glance away = when you can hedge / spread with a simple mouse click. Brokers, don't you think you should put your clients on the cutting edge = of the markets and maximize their profits EVERY DAY. Providing this = service enhances customer loyalty and promotes new business. CFO's, don't you think now is the time to financially monitor your = company's equity issues and/or pertinent operating materials. The = information provided by the software is a necessary compliment to your = position. Traders, don't you think having simplified profit and loss objectives = are crucial to you since you may have limited funds? In Auto Mode, you = can forecast prices on the fly, and sophisticated accounting is = performed for you instantly. SuccesSoft and StockSoft are engineered to merge the distinct financial = needs of ALL market participants into a single powerful tool. =20 With the 'Export File' feature, all of the screens can be exported to = file that can easily be e-mailed or accessed through a network. This = feature can be used for traders that are supervised, and market results = can quickly be sent to management for analysis. The SuccesSoft/StockSoft system provides high levels of integrity. All = exported files are locked out and the deletion of financial data is = password protected. This is your opportunity!!! Come visit us at http://www.successoft.com. = You will not be disappointed. "POWER UP and ENGAGE your limitless potential HERE and NOW".=20 SuccesSoft Corporation Pittsburgh, Pennsylvania U.S.A. 1.888.414 SSOFT / 1.888.414.7763 Technical Assistance: 1.724.863.8653=20 Fax: 1.724.861.5379 Please, this was not indented as "spam" mail. We hate it too. This was = sent because you expressed in interested in the financial markets and we = thought it might help you. =20 * "Per Section 301, Paragraph (a)(2)(C) of S. 1618, further = transmissions to you by the sender of this email may be stopped at no = cost to you by sending a reply to this email address with the word = "remove" in the subject line." ------=_NextPart_000_0694_01BE58FB.640D9580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original = Message-----
From:=20 JD Corcoran <heart@usaor.net>
Date: = Monday,=20 February 15, 1999 3:42 PM
Subject: Re: Simplified Risk = Management=20 Software

Here's an e-mail that was sent to me that I may be of interest to = you.

ATTENTION:  BROKERS* CHIEF FINANCIAL = OFFICERS*=20 INVESTORS* MARKET MANAGERS* TRADERS:

*If you perceive charting, financial data, trading systems and/or = technical=20 analysis as vital to your success, this is a piece of software you need = to=20 examine.

*This software is the most innovative product on the market today for = surveillance, accounting, tracking and risk management of your futures = and stock=20 portfolios or any other object or material that has a calculated = value.

*It is common knowledge that most market participants are trading = without any=20 or use limited financial instrumentation to guide them.

*Do you think it is wise to engage a volatile and unpredictable = market=20 without sophisticated financial software?

*SuccesSoft / StockSoft is the missing link if you feel that you have = invested a lot of time and money in your career, yet the market does not = return=20 what you would like.

*SuccesSoft 7.0 is the instrument panel which guides you to = maximizing your=20 profits while managing your risk!

FACT: Automobiles and jets have mandated vital instrumentation which = enables=20 the operator to maximize their potential.

FACT: Markets move rapidly, which greatly affects the = participants’=20 capital and market preservation.

FACT: This is your opportunity to MAXIMIZE your abilities by = utilizing=20 SuccesSoft 7.0.

* * * If more market = players had used=20 SuccesSoft at initiation, they would still be vital players in the = market today.=20 * * *
SuccesSoft / StockSoft are NOT more of the same trading = software…it is=20 based on your financial objectives with strong emphasis on risk = management.=20

It is a market tool that pays for itself everyday just as a GOOD tool = should.

It would be a wise decision to invest a few minutes at http://www.successoft.com in = order to=20 see examples of how SuccesSoft 7.0 can benefit you EVERY DAY!!!

Managers, don’t you think that the traders who you supervise in = these=20 intensively competitive and volatile times should have every ADVANTAGE = working=20 for them to manage risk?  Knowing break even is a glance away when = you can=20 hedge / spread with a simple mouse click.

Brokers, don't you think you should put your clients on the cutting = edge of=20 the markets and maximize their profits EVERY DAY.  Providing this = service=20 enhances customer loyalty and promotes new business.

CFO's, don't you think now is the time to financially monitor your = company's=20 equity issues and/or pertinent operating materials.  The = information=20 provided by the software is a necessary compliment to your position.

Traders, don't you think having simplified profit and loss objectives = are=20 crucial to you since you may have limited funds?  In Auto Mode, you = can=20 forecast prices on the fly, and sophisticated accounting is performed = for you=20 instantly.

SuccesSoft and StockSoft are engineered to merge the distinct = financial needs=20 of ALL market participants into a single powerful = tool.   

With the 'Export File' feature, all of the screens can be exported to = file=20 that can easily be e-mailed or accessed through a network.  This = feature=20 can be used for traders that are supervised, and market results can = quickly be=20 sent to management for analysis.

The SuccesSoft/StockSoft system provides high levels of = integrity.  All=20 exported files are locked out and the deletion of financial data is = password=20 protected.

This is your opportunity!!!  Come visit us at http://www.successoft.com.  = You=20 will not be disappointed.

"POWER UP and ENGAGE your limitless potential = HERE and=20 NOW".

 

SuccesSoft Corporation

Pittsburgh, Pennsylvania  U.S.A.

1.888.414 SSOFT / 1.888.414.7763

Technical Assistance: 1.724.863.8653

Fax: 1.724.861.5379

Please, this was not indented = as=20 "spam" mail.  We hate it too.  This was sent because = you=20 expressed in interested in the financial markets and we thought it might = help=20 you. 

* "Per Section 301, Paragraph (a)(2)(C) of S. 1618, further=20 transmissions to you by the sender of this email may be stopped at no = cost to=20 you by sending a reply to this email address with the word = "remove" in=20 the subject line."

------=_NextPart_000_0694_01BE58FB.640D9580-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 13:44:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11243 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 13:44:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA11232 for ; Mon, 15 Feb 1999 13:44:23 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 602 invoked from network); 15 Feb 1999 21:44:14 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 21:44:14 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA01873; Mon, 15 Feb 1999 16:44:14 -0500 (EST) Message-Id: <199902152144.QAA01873@y.dyson.net> Subject: Re: inode / exec_map interlock ? (Ask the authors) In-Reply-To: <199902152033.MAA19277@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 12:33:19 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 16:44:14 -0500 (EST) Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > :> > :I don't know what you are trying to do in your code, but there is alot of > :history of problems in that area. I suspect that you might be making one of > :the mistakes that we used to do, and there is a resource deadlock problem in > :that area. > > ??? I'm not making any mistakes as far as I can tell. I haven't touched > the locking in the map code. > > John, please... you have to get out of the habit of assuming that > everything is my fault. Either that or read the email more carefully. > I didn't say that. I ask that you try to COMMUNICATE with people, and not assume that we (the developers of the VM code) don't know about VM code. You asked a question about code running with YOUR version of the existing VM code, and make the assumption that it is a bug in the existing codebase, and perhaps it is abuse of the existing codebase. There are some difficult to properly handle problems associated with certain portions of the code, and you are welcome to communicate with DG, me or others if you need help. Without a review process of YOUR version of our VM code, we cannot tell what is going on. If the code isn't reviewed, then it will need to be. > > I believe this to be a long standing bug, not something new. It just > happens to be rather hard to reproduce, is all. > Yep, it is an issue of the exec_map being a limited resource (if it is the problem that I remember.) DG is more of the exec_map person (with the image-activators.) It is easy to prove the deadlock. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 13:47:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11599 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 13:47:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11586 for ; Mon, 15 Feb 1999 13:47:01 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id QAA14975; Mon, 15 Feb 1999 16:46:19 -0500 (EST) (envelope-from luoqi) Date: Mon, 15 Feb 1999 16:46:19 -0500 (EST) From: Luoqi Chen Message-Id: <199902152146.QAA14975@lor.watermarkgroup.com> To: dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: VOP_REMOVE() rules for freeing a_cnp ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I can't make heads or tails of the VOP_REMOVE() rules for freeing > a_cnp. > I guess you meant freeing a_cnp->cn_pnbuf. For VOP_REMOVE() shouldn't need to free pnbuf because it's already freed by namei itself (namei frees pnbuf unless SAVENAME or SAVESTART is set). > The man page doesn't say anything about having to free cnp. > > ufs_remove() doesn't bother. > This is correct. > nfs_remove() always frees it. > This is wrong. > And the unlink() system call seems to expect the cnp to be freed > by the VOP_REMOVE() function. > See above. > Typically the rule for freeing a struct componentname in a VOP > routine is 'free it if you return an error, otherwise only free > it if the SAVESTART flag is not set in cn_flags'. > Personally I feel it should be the caller's responsibility to free pnbuf, but not VOP routines', just as VOP routines shouldn't vrele any vnode arguments, otherwise implementation of stackable FS would be a nightmare. > I would appreciate it if a VFS guru could look at this junk and > tell me whos right. > > Matthew Dillon > > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 13:56:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12960 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 13:56:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from exchange-server.modacad.com (mail.modacad.com [206.253.27.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12951 for ; Mon, 15 Feb 1999 13:56:29 -0800 (PST) (envelope-from matthew@netsol.net) Received: from mattl (node99.modacad.com [206.253.27.99]) by exchange-server.modacad.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1LGCK4N5; Mon, 15 Feb 1999 13:55:22 -0800 Message-ID: <001e01be58eb$9ada4ff0$0d2814ac@mattl.MAIN> From: "Matthew" To: Subject: 3.0 unable to receive packet by default? Date: Mon, 15 Feb 1999 14:00:55 -0000 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, guys I just installed the 3.0 subscriber CD, I found that you can only ping out but not some one ping you or do telnet to you. I found this is at the time I did a ftp out, the user name and pass phrase passed and then i did a "ls", then I am stuck. It turns out no communication can come back. How weird. Is this the default behavior of 3.0? I checked the firewall thing, or route, etc. dones look like the problem. I'm wondering if I need to look into the net3 socket code for any change someone in the team did. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 14:02:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13751 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:02:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA13746 for ; Mon, 15 Feb 1999 14:02:32 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4044.ime.net [209.90.195.54]) by Loki.orland.u91.k12.me.us (8.9.3/8.8.8-Loki) with SMTP id RAA02998; Mon, 15 Feb 1999 17:02:30 -0500 (EST) (envelope-from netmonger@genesis.ispace.com) X-Server-ID: Loki.orland.u91.k12.me.us, OCSNet - Orland Maine USA X-Coord-Name: Drew "Droobie" Baxter, OneNetwork Exchange X-Coord-Addr: Droobie@Openlink.orland.me.us X-Coord-Pager: USA: 207-471-2719, http://pagedroo.orland.me.us Message-Id: <4.1.19990215165902.03c5df10@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Feb 1999 16:59:47 -0500 To: "Matthew" , From: Drew Baxter Subject: Re: 3.0 unable to receive packet by default? In-Reply-To: <001e01be58eb$9ada4ff0$0d2814ac@mattl.MAIN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:00 AM 2/15/99 , Matthew wrote: >Hi, guys >I just installed the 3.0 subscriber CD, I found that you can only ping out >but not some one ping you or do telnet to you. > >I found this is at the time I did a ftp out, the user name and pass phrase >passed and then i did a "ls", then I am stuck. It turns out no communication >can come back. How weird. Is this the default behavior of 3.0? I checked the >firewall thing, or route, etc. dones look like the problem. > >I'm wondering if I need to look into the net3 socket code for any change >someone in the team did. Care to show me the output of IPFW show? --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP DSS/1024 Public Key ID: 0x409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 14:07:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14281 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:07:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA14276 for ; Mon, 15 Feb 1999 14:07:08 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 26408 invoked from network); 15 Feb 1999 22:07:06 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 22:07:06 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id RAA01900; Mon, 15 Feb 1999 17:07:05 -0500 (EST) Message-Id: <199902152207.RAA01900@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902152035.MAA19311@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 12:35:11 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 17:07:05 -0500 (EST) Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > : > :BTW, have you found/fixed the non-blocking swap pager problem yet. It seems > :that existing bugs should be fixed first. > > What non-blocking swap pager problem? this is the third time you've > brought this up, and the third time I've asked you to explain what > the frag you are talking about, and the the third time I have not > received any sort of explanation. > Are you blocking on excessively large numbers of output requests? You know *exactly* the issue at hand, and it has to do with the backpressure needed to keep the pageout daemon from doing an evil nasty on all of the pages in the system. I *have* told you about this before, and it falls on deaf ears. I love to argue with those people who like to create huge pending I/O queues that totally kill I/O latencies, and make a system perform terribly -- when they *think* that bandwidth is the issue. There are numerous issues associated with pending I/O requests, and the above is only two of them. Bandwidth is *sometimes* the issue, and tagged queueing helps alot of applications, but is of only limited (but some) use in paging. The original version of your code appeared to have the problem, and if you have fixed it, or you aren't queueing more than a few pageouts at a time (perhaps <10 or so), then you are okay. Note that "pageouts" often imply the need for "pageins", and often the same disk for "pageouts" is used for "pageins". Some kind of read-around-write strategy can help, but new disk I/O subsystems can absorb lots of transactions, further destroying latency. Allowing too few I/O requests (like 1 or 2) has it's own set of problems. Paging I/O is almost never bandwidth limited, it is almost always latency or wait on needed page or resource. On a timesharing system, with lots of processes, a hog process can easily push the pageout daemon to the point of freeing all pages. The key to the blocking has to do with giving the pagedaemon a rest, at the same time as keeping the I/O subsystem from being totally sandbagged with requests (further causing performance to fall into the abyss.) A large system will almost never be totally starved of memory, if you don't let the pageout daemon do it's dirty work into oblivion. I have said the above before, and now it is public. I hope that the competition doesn't see the above comments, because it will help them. The only reason why you get negative feedback from me (and others), is because you do not take advantage of tools available, and sometimes seem to believe that ego is a good replacement for collecting information, learning about the codebase that you are hacking, and simple courtesy in letting the original authors of the code keep you from making the same mistakes that they have. This courtesy extends to the userbase, who shouldn't be exposed to code that hasn't been reviewed. I have made mistakes in the past, and one thing that I didn't do, was to avoid asking for help. When someone was patient enough to work with me on the code, and to review it, I took advantage of it (and gave proper credit.) My ego doesn't support the short term buzz of committing code, but long term pain. One reason why I quit (amongst many) is that DG and I quit communicating (and I still don't know why), and I lost my reviewer/co-contributor. This put too much pressure on me over a year or so, and I know the reality of creating new works: collaboration is superior to cowboy behavior. The kernel itself, and VM code also needs a total rework. This isn't what is happening in the work that I have seen so far. There are upper level architectural considerations that have a body of knowlege residing in only a few people. *If* I am in that body of people, I possess only a small portion of those ideas, but I do try to communicate with, and learn from those who do know more than me. Again, this is the ego thing again, however, collaboration between *equals* or *near equals* works alot better than ramroding ideas, without communicating *effectively* with that body of knowledge. If you were effectively communicating with the existant body of knowledge, you would find alot less resistance to your changes. There are people with their livelihoods dependent on the FreeBSD codebase, and it should be treated with respect because of that. MAYBE you didn't know, but alot of communication happened behind the scenes regarding all of the FreeBSD VM and VFS code. Little such communication appears to be happening with you, and when it does, it is often one sided. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 14:12:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15059 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:12:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA15054 for ; Mon, 15 Feb 1999 14:12:10 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id RAA15389; Mon, 15 Feb 1999 17:11:38 -0500 (EST) (envelope-from luoqi) Date: Mon, 15 Feb 1999 17:11:38 -0500 (EST) From: Luoqi Chen Message-Id: <199902152211.RAA15389@lor.watermarkgroup.com> To: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I found an interesting interlock situation between what I believe to > be a program binaries inode and the exec_map. The machine locked up > trying to exec new programs. > > This was running a make -j10 buildworld on a machine with 16MB of ram > configured, while testing my new VM system. I don't think the lockup is > due to my VM system, though. It took it 7 hours of extremely heavy > paging before it locked up. > > When I broke the machine out into DDB and did a ps, all of the cc's > were stuck in 'inode' wait, while a single ld program was stuck in > 'thrd_sleep'. > > I tracked 'thrd_sleep' down to a vm_map lock and the map down to > the exec_map. I tracked down the inode lock to the 'cc' program binary. > The inode had one shared lock and 7 waiters. The exec_map appears to > own one shared lock with 6 waiters ( but most of the waiters are due to > me trying to run other programs before breaking into the DDB ). > > I am guessing that there is an interlock situation with exec_map and > a program inode where one process locks exec_map followed by the program > inode, and another locks the program inode followed by exec_map. But > I'm not familiar with that section of the code so I would appreciate > any help. > > -Matt > Matthew Dillon > > I have a fix for this problem posted to -current a while ago: do a search on "deadlock". (I should have filed a PR, but I kept forgetting). It would also be nice to change "thrd_sleep" to something more sensible, say "vmmap". -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 14:13:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15273 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:13:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA15265 for ; Mon, 15 Feb 1999 14:13:44 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 4165 invoked from network); 15 Feb 1999 22:13:40 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 22:13:40 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id RAA01910; Mon, 15 Feb 1999 17:13:40 -0500 (EST) Message-Id: <199902152213.RAA01910@y.dyson.net> Subject: Re: Processor affinity? In-Reply-To: <864sonmqvm.fsf@not.oeno.com> from Ville-Pertti Keinonen at "Feb 15, 99 09:03:09 pm" To: will@iki.fi (Ville-Pertti Keinonen) Date: Mon, 15 Feb 1999 17:13:40 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen said: > > Doing something like this in a BSD scheduler is a bit difficult > because of the priority buckets. > One more comment: The main problem that I was trying to solve was the silly bouncing. That is probably worse than any other problem on a FreeBSD SMP system. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 14:24:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16323 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 14:24:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA16318 for ; Mon, 15 Feb 1999 14:24:04 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 15486 invoked from network); 15 Feb 1999 22:24:00 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 15 Feb 1999 22:24:00 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id RAA01945; Mon, 15 Feb 1999 17:23:58 -0500 (EST) Message-Id: <199902152223.RAA01945@y.dyson.net> Subject: Re: inode / exec_map interlock ? In-Reply-To: <199902152054.MAA19505@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 12:54:14 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Feb 1999 17:23:58 -0500 (EST) Cc: tony@dell.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > : Your original email goes back to December 31st, long before I even began > : working on the VM system ( so there! John! ). > > ( that is, before I started committing things other then comment adds ) > > ( Matt sticks out his tongue and makes a face ) > There are issues and problems with exec_map and the issue needs to be revisited. However, you are not exposing the modified VM code for review, so it isn't easy to 2nd guess what you are doing. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 15:46:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24367 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 15:46:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24362 for ; Mon, 15 Feb 1999 15:46:51 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id PAA03482 for ; Mon, 15 Feb 1999 15:46:50 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id PAA52073; Mon, 15 Feb 1999 15:46:49 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 15 Feb 1999 15:46:49 -0800 (PST) Message-Id: <199902152346.PAA52073@vashon.polstra.com> To: hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <36C61A00.76960BF1@softweyr.com> References: <10481.918927420@zippy.cdrom.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <36C61A00.76960BF1@softweyr.com>, Wes Peters wrote: > > Actually, given the capabilities of Perforce, most of those would > be unneeded. They already have a web interface, and the Perforce > server supports read-only users and distributed, read-only depots, > which could probably replace CVSup and CTM. It's much slower than CVSup. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 15:50:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24979 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 15:50:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24974 for ; Mon, 15 Feb 1999 15:50:51 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id RAA04318 for hackers@freebsd.org; Mon, 15 Feb 1999 17:50:50 -0600 (CST) From: Kevin Day Message-Id: <199902152350.RAA04318@home.dragondata.com> Subject: vm_page_zero_fill To: hackers@FreeBSD.ORG Date: Mon, 15 Feb 1999 17:50:48 -0600 (CST) 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm currently playing with FreeBSD in an embedded system, where security is of no concern. The system I'm using has relatively poor memory bandwidth, so I was looking for places to optimize. I know how the vm system zeros pages before giving them to me, which isn't really necessary. (I'm not sure about other software on the fbsd distribution, but all code I've written expects malloc(), new, etc to have garbage in them, not be zeroed) I don't pretend to understand the VM system, but as a quick test, I made vm_page_zero_fill a NOP. (This seemed like where this was getting done). The system ran, but inetd, sed and ld kept crashing on sig 11's or 6's. Everything else I ran seemed ok though. While I know ther are better ways of doing this, am I going to be fighting a huge battle of making the kernel, as well as userland tools capable of dealing with nonzero'ed memory, or am I seeing a completely different problem? If this is a really stupid question, feel free to flame. I'm sure it's a case of ignorance on my part. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 15:54:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25390 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 15:54:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25384 for ; Mon, 15 Feb 1999 15:54:10 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id PAA03529 for ; Mon, 15 Feb 1999 15:54:09 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id PAA52115; Mon, 15 Feb 1999 15:54:08 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 15 Feb 1999 15:54:08 -0800 (PST) Message-Id: <199902152354.PAA52115@vashon.polstra.com> To: hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <10481.918927420@zippy.cdrom.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <10481.918927420@zippy.cdrom.com>, Jordan K. Hubbard wrote: > If we wanted to use a commercial solution then the choice would be > more than clear - Perforce! Our CVS repository meister(s) like it a > lot ... Make that "one of our CVS repository meisters ..." I'm not particularly wild about it myself. For starters, it could use something like "cvs -nq upd". In the project I'm involved with where Perforce is used, I bet that 20% of the submits (== commits) are followed immediately by another one saying, "Oops, these files should have been included in the last submit." I also miss the ability to do diffs between two revisions, neither of which is your current working version. And something equivalent to "cvs ann" would be nice to have, too. The remote depot is nice when network conditions are good. But when they're not, you're just SOL. You might as well go find something else to work on. Other people on the project who know Perforce better than I do seem to like it OK, though. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 15:57:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25793 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 15:57:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from exchange-server.modacad.com (mail.modacad.com [206.253.27.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25783 for ; Mon, 15 Feb 1999 15:57:58 -0800 (PST) (envelope-from matthew@netsol.net) Received: from mattl (node99.modacad.com [206.253.27.99]) by exchange-server.modacad.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1LGCK4RB; Mon, 15 Feb 1999 15:56:53 -0800 Message-ID: <003701be58fc$94a8dcd0$0d2814ac@mattl.MAIN> From: "Matthew" To: "Drew Baxter" Cc: Subject: Re: 3.0 unable to receive packet by default? Date: Mon, 15 Feb 1999 16:02:26 -0000 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Your 3.0 is running on a single CPU style. I compiled the smp kernel and then just going right in the debuging mode. Looks like single CPU configuration is stable. -----Original Message----- From: Drew Baxter To: Matthew Date: Tuesday, February 16, 1999 12:03 AM Subject: Re: 3.0 unable to receive packet by default? >At 10:47 AM 2/15/99 , Matthew wrote: >>Is there any version that is reliable like 2.2.2. The 3.0 I run through me >>in debuging mode with smp eabled. >> >>Is 2.8 release kernel's same as 2.2.2? where the vm is not messed up? > >Well I used to be a 2.1 user until I moved up to 3.0.. I've been using 3.0 >since the first SNAP releases, and I Must say, it's a vast improvement. It >is very reliable for me, and my PII-333 with 32mb does a good job over the >POS Windows NT Workstation with 128mb.. > >2.2.8 probably has some improvements over 2.2.2.. As it goes I haven't >touched 2.2 since I moved upward to 3.0. 3.0 IS worth the moving up, >although you may want to work with a 2.2 server and then CVSUP the Current, >then do a make aout-to-elf. Perhaps that would fix any problems you're having. > >It would seem your ability to get connections in may be to do with inetd or >your connection though. Any connectivity problems I had were either due to >IPFW (which I strongly recommend having running), or due to problems with >my NIC configuration. But if 2.2 works fine for you, then perhaps starting >there and doing the upgrade may be an easier transition. > > >--- >Drew "Droobie" Baxter >Network Admin/Professional Computer Nerd(TM) >OneEX: The OneNetwork Exchange, Bangor Maine USA >http://www.droo.orland.me.us > >PGP DSS/1024 Public Key ID: 0x409A1F7D > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 16:07:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27806 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 16:07:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Loki.orland.u91.k12.me.us (Loki.orland.u91.k12.me.us [169.244.111.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27800 for ; Mon, 15 Feb 1999 16:07:19 -0800 (PST) (envelope-from netmonger@genesis.ispace.com) Received: from celeris (56k-port4044.ime.net [209.90.195.54]) by Loki.orland.u91.k12.me.us (8.9.3/8.8.8-Loki) with SMTP id TAA03131; Mon, 15 Feb 1999 19:07:20 -0500 (EST) (envelope-from netmonger@genesis.ispace.com) X-Server-ID: Loki.orland.u91.k12.me.us, OCSNet - Orland Maine USA X-Coord-Name: Drew "Droobie" Baxter, OneNetwork Exchange X-Coord-Addr: Droobie@Openlink.orland.me.us X-Coord-Pager: USA: 207-471-2719, http://pagedroo.orland.me.us Message-Id: <4.1.19990215190318.03d43f10@genesis.ispace.com> X-Sender: netmonger@genesis.ispace.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 15 Feb 1999 19:03:53 -0500 To: "Matthew" From: Drew Baxter Subject: Re: 3.0 unable to receive packet by default? Cc: In-Reply-To: <003701be58fc$94a8dcd0$0d2814ac@mattl.MAIN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:02 AM 2/15/99 , Matthew wrote: >Your 3.0 is running on a single CPU style. I compiled the smp kernel and >then just going right in the debuging mode. Looks like single CPU >configuration is stable. I'll have to drop another processor in.. My machine does do SMP, it's just Win95 (primary OS on it, sadly) doesn't :) --- Drew "Droobie" Baxter Network Admin/Professional Computer Nerd(TM) OneEX: The OneNetwork Exchange, Bangor Maine USA http://www.droo.orland.me.us PGP DSS/1024 Public Key ID: 0x409A1F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 16:17:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00244 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 16:17:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00239 for ; Mon, 15 Feb 1999 16:17:34 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id QAA03617; Mon, 15 Feb 1999 16:17:33 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id QAA52267; Mon, 15 Feb 1999 16:17:32 -0800 (PST) (envelope-from jdp@polstra.com) Date: Mon, 15 Feb 1999 16:17:32 -0800 (PST) Message-Id: <199902160017.QAA52267@vashon.polstra.com> To: nsmart@kira.team400.ie Subject: Re: select() can set errno to ECHILD? In-Reply-To: <36C85A77.EDBC00F9@kira.team400.ie> References: <19990215015534.A20671@oss.uswest.net> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <36C85A77.EDBC00F9@kira.team400.ie>, Niall Smart wrote: > Erik E Rantapaa wrote: > > > > I have code running under 2.2.x which claims that this is happening. > > This behaviour is not documented in the man pages. I have not been able to > > duplicate it in a simple test program I wrote, but the log files for > > a Merit RADIUS server say that it is happening. > > > > Is this at all possible? > > You are getting SIGCHLD while blocked in select, waitpid with WNOHANG in > then handler returns ECHILD, the signal handler fails to restore errno. But when the signal handler returns, it will return to select() again, right? And select will either continue and eventually succeed returning some number >= 0, or it will itself set errno (perhaps to EINTR) and return -1, right? So if the caller of select checks its return value and only looks at errno if the return value is -1, I can't see how anything the signal handler does could confuse it. In other words, if there is a bug in the application then it must be that the application fails to check the return value of select before examining errno. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 16:45:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03426 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 16:45:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03409 for ; Mon, 15 Feb 1999 16:45:43 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA10185; Mon, 15 Feb 1999 17:55:49 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd010120; Mon Feb 15 17:55:34 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA22056; Mon, 15 Feb 1999 17:45:20 -0700 (MST) From: Terry Lambert Message-Id: <199902160045.RAA22056@usr02.primenet.com> Subject: Re: Processor affinity? To: will@iki.fi (Ville-Pertti Keinonen) Date: Tue, 16 Feb 1999 00:45:20 +0000 (GMT) Cc: dyson@iquest.net, hackers@FreeBSD.ORG In-Reply-To: <864sonmqvm.fsf@not.oeno.com> from "Ville-Pertti Keinonen" at Feb 15, 99 09:03:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > # of active CPU cycles. I do have affinity code for SMP, and it makes > > a positive difference in performance, even with the big-lock FreeBSD kernel. > > What does it do? > > In order to be more useful than a last-run-on hint (which is pretty > much useless for time-sharing), it needs to be able to select a > thread that doesn't have the highest priority to run when the best > processor for the highest-priority runnable (but not active) thread > is (momentarily) running a even higher-priority thread. > > Doing something like this in a BSD scheduler is a bit difficult > because of the priority buckets. It seems to me that you either > give up O(1) thread selection (the Linux folks seem to be happy > with O(n), but I don't like the idea) or have to do something > moderately complex (such as per-processor run queues with load > balancing, like DEC did with OSF/1). > > Or did you find a more elegant solution? A very trivial affinity soloution is to have per CPU scheduler queues, and to keep a "quantum count" per CPU as well. Processes becoming "ready to run" are queued on the processor with the highest quantum count (e.g., highest process turnover rate, indicating relatively higher I/O binding). Hysteresis is introduced, such that processes are "sticky"; that is, unless the quantum count differential is over a certain amount, the process "prefers" to remain on the local CPU queue. This algorithm is sufficient to ensure sufficient affinity that blatant cache busting can be mostly avoided. Note that a characteristic load that turns over 15 quanta in N time units while another characteristic load turns over 7 quanta in the same N time units is normal, natural, and not a bad thing. A second trivial modification to the algorithm attempts to delay migration. If migration occurs from a processor with M processes consuming quantum, then you will want to delay for M+1 for the quantum count to see the effect of the previous migration, before jumping into the next migration. In reality, you want M(theta) -- the M qunatum clock ticks for the most loaded CPU. > > The reason for diminishing gains on a 2 or 4 cpu system isn't bandwidth as > > much as it is the availability of fewer CPUs to choose from. By blindly > > choosing the wrong cpu, there will be much more latency assocated with > > refilling the cache on context switch. > > And with affinity, particularly if it is too strong, you'll > occasionally have far more latency associated with getting a thread > to run again when the right cpu wasn't available when the thread > would "naturally" have run. The answer is to not "blindly" choose CPU's. Process loadiing characteristics are generally metastable over time. A third affinity optimization is "negative affinity". This is a behaviour modification based on threads within a process to maximize effective concurrency. A base assumption to this technique is that the functional decomposition into threrads in the first place was done correctly by the programmer, such that the threads will have little mutex or IPC interaction and/or heap sharing, which would otherwise result in interprocessor synchronization hits. It's basically all in how you implement it. Note that schedulable entity affinity is only one possible win. As well as cache lines, there is per CPU system resource affinity (per CPU pools) that can be leverages in exactly the same way to further reduce latency. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 17:53:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11042 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 17:53:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA11036 for ; Mon, 15 Feb 1999 17:53:15 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 13768 invoked from network); 16 Feb 1999 01:53:12 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 01:53:12 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id UAA24408; Mon, 15 Feb 1999 20:53:03 -0500 (EST) Message-Id: <199902160153.UAA24408@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902152350.RAA04318@home.dragondata.com> from Kevin Day at "Feb 15, 99 05:50:48 pm" To: toasty@home.dragondata.com (Kevin Day) Date: Mon, 15 Feb 1999 20:53:03 -0500 (EST) Cc: hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day said: > > I'm currently playing with FreeBSD in an embedded system, where security is > of no concern. The system I'm using has relatively poor memory bandwidth, so > I was looking for places to optimize. I know how the vm system zeros pages > before giving them to me, which isn't really necessary. (I'm not sure about > other software on the fbsd distribution, but all code I've written expects > malloc(), new, etc to have garbage in them, not be zeroed) > Userland won't like non-zeroed memory regions. Some of the kernel might balk at it also. > > I don't pretend to understand the VM system, but as a quick test, I made > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > That would be problematical. > > The system ran, but inetd, sed and ld kept crashing on sig 11's or 6's. > Everything else I ran seemed ok though. While I know ther are better ways of > doing this, am I going to be fighting a huge battle of making the kernel, as > well as userland tools capable of dealing with nonzero'ed memory, or am I > seeing a completely different problem? > Alot of code might do something like: int foo; main() { foo += 1; } and expect foo to be equal to 1 instead of being indeterminant. If you turn vm_page_zero_fill off entirely, then this will be a problem. The kernel code does things like this also, unfortunately. > > If this is a really stupid question, feel free to flame. I'm sure it's a > case of ignorance on my part. :) > What you ask for might produce unexpected behavior in existant code, but isn't (IMO) a out-of-the-question request. I would suggest that you produce a special binary type of some kind, and allow the kernel to give you pages that haven't been zeroed. You would also turn off the background prezero code. You could then run both converted and non-converted programs. The kernel could also set the vm behavior to trap with a special fault if a process reads a memory location without it being intialized by either a write, a pagein from disk or inheritance from a parent process. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 17:59:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11529 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 17:59:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from monk.via.net (monk.via.net [209.81.9.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11524 for ; Mon, 15 Feb 1999 17:59:31 -0800 (PST) (envelope-from joe@monk.via.net) Received: (from joe@localhost) by monk.via.net (8.8.8/8.8.8) id RAA27990; Mon, 15 Feb 1999 17:59:30 -0800 (PST) (envelope-from joe) From: Joe McGuckin Message-Id: <199902160159.RAA27990@monk.via.net> Date: Mon, 15 Feb 1999 17:59:29 -0800 (PST) To: julian@whistle.com Cc: hackers@FreeBSD.ORG Subject: Re[2]: "XESS" Spreadsheet for FreeBSD In-Reply-To: X-Mailer: Ishmail 1.3.1-970608-bsdi MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I actually bought the Linux version and run it under FreeBSD. I asked them at the time I purchased the license, when they were going to have a FreeBSD version. (They replied 'never'). I hope they change their mind. It's a solid product. I've never had it crash. Julian Elischer wrote: > The thing to do is to tell them that we'd like them to test the linux > version with freebsd and just add a note to say that it is tested under > linux emulation under FreeBSD.. > > this would give us the tool and let them know about FreeBSD. We probably > don't have ht enumbers to make them make a true FreeBSD port, but > I f they do a FreeBSD port and no-one buys it we are in a worse > situation than if we didn't. > > > On Sun, 14 Feb 1999, Randall Hopper wrote: > > > The XESS Spreadsheet folks (AIS) are considering a FreeBSD version. > > If anyone would also be interested in this, please forward your > > interest/input onto them (info@ais.com). > > > > Here's the URL for the spreadsheet: > > > > http://www.ais.com/Xess/xess4_product_sheet.html > > > > Randall > > > > ----- Forwarded message from shannon@ais.com ----- > > > > Date: Tue, 9 Feb 99 11:49:38 EST > > From: shannon@ais.com > > Subject: XESS on FreeBSD > > > > Hello Randall, > > > > You sent: > > > > > I would consider your product were there a version that runs on FreeBSD > > > (www.freebsd.org) as there apparently once was. However, it appears > > > you currently only have a Linux version, and it depends on Linux-specific > > > /proc entries such as /proc/cpuinfo /proc/version, so I can't run it > > > on FreeBSD, even under Linux emulation. > > > Just a datapoint > > > > XESS and XessLite have never been built specifically for FreeBSD. However, > > we have recently gotten enough interest that we are giving the idea of > > porting XESS and/or XessLite to FreeBSD. We would appreciate any input you > > might have and will let you know once we make a decision. > > > > Thank you for your interest in XESS! > > > > Sincerely, > > > > Shannon Tostanoski > > AIS Sales Admin > > shannon@ais.com > > > > ----- End forwarded message ----- > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message Joe McGuckin ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 90403 Phone: 650-969-2203 Cell: 415-710-4894 Fax: 650-969-2124 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 18:22:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14266 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 18:22:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA14259 for ; Mon, 15 Feb 1999 18:22:15 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA11848; Mon, 15 Feb 1999 18:13:22 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdx11846; Tue Feb 16 02:13:19 1999 Date: Mon, 15 Feb 1999 18:13:16 -0800 (PST) From: Julian Elischer To: Joe McGuckin cc: hackers@FreeBSD.ORG Subject: Re: Re[2]: "XESS" Spreadsheet for FreeBSD In-Reply-To: <199902160159.RAA27990@monk.via.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG really? I was told it could never work because it used /proc.. this is good news.. (I'll try again) julian On Mon, 15 Feb 1999, Joe McGuckin wrote: > > I actually bought the Linux version and run it under FreeBSD. I asked > them at the time I purchased the license, when they were going to > have a FreeBSD version. (They replied 'never'). > > I hope they change their mind. It's a solid product. I've never > had it crash. > > > Julian Elischer wrote: > > The thing to do is to tell them that we'd like them to test the linux > > version with freebsd and just add a note to say that it is tested under > > linux emulation under FreeBSD.. > > > > this would give us the tool and let them know about FreeBSD. We probably > > don't have ht enumbers to make them make a true FreeBSD port, but > > I f they do a FreeBSD port and no-one buys it we are in a worse > > situation than if we didn't. > > > > > > On Sun, 14 Feb 1999, Randall Hopper wrote: > > > > > The XESS Spreadsheet folks (AIS) are considering a FreeBSD version. > > > If anyone would also be interested in this, please forward your > > > interest/input onto them (info@ais.com). > > > > > > Here's the URL for the spreadsheet: > > > > > > http://www.ais.com/Xess/xess4_product_sheet.html > > > > > > Randall > > > > > > ----- Forwarded message from shannon@ais.com ----- > > > > > > Date: Tue, 9 Feb 99 11:49:38 EST > > > From: shannon@ais.com > > > Subject: XESS on FreeBSD > > > > > > Hello Randall, > > > > > > You sent: > > > > > > > I would consider your product were there a version that runs on FreeBSD > > > > (www.freebsd.org) as there apparently once was. However, it appears > > > > you currently only have a Linux version, and it depends on Linux-specific > > > > /proc entries such as /proc/cpuinfo /proc/version, so I can't run it > > > > on FreeBSD, even under Linux emulation. > > > > Just a datapoint > > > > > > XESS and XessLite have never been built specifically for FreeBSD. However, > > > we have recently gotten enough interest that we are giving the idea of > > > porting XESS and/or XessLite to FreeBSD. We would appreciate any input you > > > might have and will let you know once we make a decision. > > > > > > Thank you for your interest in XESS! > > > > > > Sincerely, > > > > > > Shannon Tostanoski > > > AIS Sales Admin > > > shannon@ais.com > > > > > > ----- End forwarded message ----- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > > Joe McGuckin > > ViaNet Communications > 1235 Pear Ave, Suite 107 > Mountain View, CA 90403 > > Phone: 650-969-2203 > Cell: 415-710-4894 > Fax: 650-969-2124 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 18:27:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA14603 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 18:27:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA14598 for ; Mon, 15 Feb 1999 18:27:38 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 23211 invoked from network); 16 Feb 1999 02:27:28 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 02:27:28 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id VAA24443; Mon, 15 Feb 1999 21:27:28 -0500 (EST) Message-Id: <199902160227.VAA24443@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902152207.RAA01900@y.dyson.net> from "John S. Dyson" at "Feb 15, 99 05:07:05 pm" To: dyson@iquest.net Date: Mon, 15 Feb 1999 21:27:28 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John S. Dyson said: > > MAYBE you didn't know, but alot of communication happened behind the scenes > regarding all of the FreeBSD VM and VFS code. Little such communication > appears to be happening with you, and when it does, it is often one sided. > To follow up on this demi-mess: I still am asking for better private communications, so that things don't get out of hand. There are some really interesting things happening on other fronts also, but with a focused goal of one person, it will exclude perhaps superior solutions to certain problems. I want FreeBSD to succeed, and if you contribute to FreeBSD, I want your work to succeed. Maybe what several people have been trying to do is to get cooperation going so this thing doesn't get out of hand. Way-back-when, FreeBSD was slightly less mission critical, and mistakes were slightly more tolerable. The competition was just as bad as we were, and standards were lower. FreeBSD has to be slightly more careful and slightly more structured, because a decrease in quality will be much more disruptive than any slight improvement. I applaud your *efforts* to improve the code. Work (in a physics sense) isn't guaranteed by effort though. If there were NO resources to utilize, then there would be no reason not to utilize them. There are resources available. When spearheading an effort, with a narrow and individual project, gaining interest of other developers will be difficult. If there were no competent people available to draw information from, then an individual project *might* be appropriate. FreeBSD isn't in that position though. One reason why you might be getting public criticism, is that private criticism hasn't been heeded. I have been lax in a few areas also, and one area where I am quite concerned is the recoding (without sufficient redesign) that is happening. There is mostly little algorithmic change going on, with recoding and relabeling going on. The swap-pager, on the other hand is an improvement (IMO), and a better platform to start from than the original code. If there are design flaws in it, the results of correcting them has a better chance to be correct than the original code. I claim that restructuring code, without a *significant* performance improvement is regression. Additionally, the areas like vm_page_alloc aren't where the CPU goes on a loaded system. To improve system performance, you have to profile it under various conditions. You must know that all VM code except for zeroing pages on a loaded system is almost insignificant in the scheme of things. The place ripe for improvement is architectural. (There might be some cases where vm_page_alloc or vm_page_lookup are significant, but it sure sounds like the results of artificial benchmarking to me :-)). The key to getting the respect of co-workers it to work WITH them, as opposed to doing things to them. Changing code, without significantly changing functionality is just wrong. For example, if you want to remove the object page_hint, then remove it. Please don't recode entire routines, especially if reverting routines to remove things like page_hint changes much of the code back to the way it originally was. I know for a fact that code existed prior to the page_hint stuff, but it just not might be committed. Both on code that I originated (if you include DG, me and certain other contributors , we essentially rewrote the VM system, and provided the performance that FreeBSD has today), and code that has been directly inherited, we didn't make changes without strong cause. We even resisted making semi-required formatting changes, because they complicate diffs. The ONLY reason for making gratuitious changes is to create a dependency by alienating other developers who are used to the existing code. That is (of course) not the conscious desire I am sure. It was my fault for not participating in the change of vm_page_alloc, and the new code is likely cleaner, but the disadvantage of disassociating from previous code seems to totally overwhelm any obvious advantage at this point. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 19:03:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA18006 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 19:03:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18001 for ; Mon, 15 Feb 1999 19:03:09 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id SAA12413; Mon, 15 Feb 1999 18:52:38 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdV12408; Tue Feb 16 02:52:29 1999 Date: Mon, 15 Feb 1999 18:52:19 -0800 (PST) From: Julian Elischer To: "John S. Dyson" cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902160227.VAA24443@y.dyson.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John, I've been sitting on the side here for a while. You have both got good points. You have a good point that recoding without significant change is more likely to just introduce bugs and by definition is not going to improve performance. However, just as Matt should heed the suggenstions of those who are senior to him in experience, you should realise that Matt's reasons are not purely for performance. Much of the present code is almost unreadable, and sorely lacking in comments and documentation. I for one am grateful for Matt for doing ht ework of cleaning and commenting. I can follow matt's commented code a lot easier than I could before, and that means that I can now contructively comment and help. I agree that he might do well to involve more people in this, but consider John that you DID resign involvement in this code, and people, while sad to see you go, did take you at your word. If you are coming back to this then you will be welcomed with oepn arms, but you need to realise that some people find it hard sitting on their hands for 2 days waiting for an answer, and that if you are not officially involved then they will be doing so as a courtesy. I for one want you involved in discussing these changes because your experience is invaluable.. however Matt is in the stage in his life at the moment wher he has the energy of 10 raging bulls (hmm I think I'm going overboard here), so you need to make sure that that is harnessed and used constructively. It would be better if you were to take on the role of design adviser to Matt, let him take responsibility for his own decisions and give him ideas of how you would want to see things done.. My opinion is that if you outline to him all the improvements you've been envisioning, and let him do the coding, we will all come out ahead.. you will have time to do what you need to do, Matt will get to learn your experience, and FreeBSD will get well commented and dovumented code, that is readble, and designed by someone that knows what they are doing (you). You are coming across as confronatational (to me anyhow). I know you so I know that you are not being so, but you and matt need to work out a formal arangement. I know Matt is also a very reasonable guy, and since he presently has some time on his hands, I think you should make use of it to all our advantages.. All I'm saying is try work WITH him rather than just shouting "Stop Stop Be Careful!" well, that's enough lecturing to my betters for today.. :-) julian On Mon, 15 Feb 1999, John S. Dyson wrote: > John S. Dyson said: > > > > MAYBE you didn't know, but alot of communication happened behind the scenes > > regarding all of the FreeBSD VM and VFS code. Little such communication > > appears to be happening with you, and when it does, it is often one sided. > > > To follow up on this demi-mess: > I still am asking for better private communications, so that things don't > get out of hand. There are some really interesting things happening on other > fronts also, but with a focused goal of one person, it will exclude perhaps > superior solutions to certain problems. > > I want FreeBSD to succeed, and if you contribute to FreeBSD, I want your > work to succeed. Maybe what several people have been trying to do is to > get cooperation going so this thing doesn't get out of hand. Way-back-when, > FreeBSD was slightly less mission critical, and mistakes were slightly more > tolerable. The competition was just as bad as we were, and standards were > lower. FreeBSD has to be slightly more careful and slightly more structured, > because a decrease in quality will be much more disruptive than any slight > improvement. > > I applaud your *efforts* to improve the code. Work (in a physics sense) isn't > guaranteed by effort though. If there were NO resources to utilize, then > there would be no reason not to utilize them. There are resources available. > > When spearheading an effort, with a narrow and individual project, gaining > interest of other developers will be difficult. If there were no competent > people available to draw information from, then an individual project *might* > be appropriate. FreeBSD isn't in that position though. > > One reason why you might be getting public criticism, is that private criticism > hasn't been heeded. I have been lax in a few areas also, and one area where > I am quite concerned is the recoding (without sufficient redesign) that is > happening. There is mostly little algorithmic change going on, with recoding > and relabeling going on. The swap-pager, on the other hand is an improvement > (IMO), and a better platform to start from than the original code. If there > are design flaws in it, the results of correcting them has a better chance > to be correct than the original code. I claim that restructuring code, without > a *significant* performance improvement is regression. Additionally, the areas > like vm_page_alloc aren't where the CPU goes on a loaded system. To improve > system performance, you have to profile it under various conditions. You must > know that all VM code except for zeroing pages on a loaded system is almost > insignificant in the scheme of things. The place ripe for improvement is > architectural. (There might be some cases where vm_page_alloc or > vm_page_lookup are significant, but it sure sounds like the results of > artificial benchmarking to me :-)). > > The key to getting the respect of co-workers it to work WITH them, as opposed > to doing things to them. Changing code, without significantly changing > functionality is just wrong. For example, if you want to remove the object > page_hint, then remove it. Please don't recode entire routines, especially if > reverting routines to remove things like page_hint changes much of the code > back to the way it originally was. I know for a fact that code existed prior > to the page_hint stuff, but it just not might be committed. > > Both on code that I originated (if you include DG, me and certain other > contributors , we essentially rewrote the VM system, and provided the > performance that FreeBSD has today), and code that has been directly > inherited, we didn't make changes without strong cause. We even resisted > making semi-required formatting changes, because they complicate diffs. > > The ONLY reason for making gratuitious changes is to create a dependency > by alienating other developers who are used to the existing code. That > is (of course) not the conscious desire I am sure. It was my fault for not > participating in the change of vm_page_alloc, and the new code is likely > cleaner, but the disadvantage of disassociating from previous code seems > to totally overwhelm any obvious advantage at this point. > > -- > John | Never try to teach a pig to sing, > dyson@iquest.net | it makes one look stupid > jdyson@nc.com | and it irritates the pig. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 19:37:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21442 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 19:37:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles245.castles.com [208.214.165.245]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21437 for ; Mon, 15 Feb 1999 19:37:28 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id TAA14312; Mon, 15 Feb 1999 19:29:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902160329.TAA14312@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Kevin Day cc: hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-reply-to: Your message of "Mon, 15 Feb 1999 17:50:48 CST." <199902152350.RAA04318@home.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Feb 1999 19:29:43 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I'm currently playing with FreeBSD in an embedded system, where security is > of no concern. The system I'm using has relatively poor memory bandwidth, so > I was looking for places to optimize. I know how the vm system zeros pages > before giving them to me, which isn't really necessary. (I'm not sure about > other software on the fbsd distribution, but all code I've written expects > malloc(), new, etc to have garbage in them, not be zeroed) > > I don't pretend to understand the VM system, but as a quick test, I made > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > > The system ran, but inetd, sed and ld kept crashing on sig 11's or 6's. > Everything else I ran seemed ok though. While I know ther are better ways of > doing this, am I going to be fighting a huge battle of making the kernel, as > well as userland tools capable of dealing with nonzero'ed memory, or am I > seeing a completely different problem? It's a bad idea; the C spec says that the BSS contains zeroes, so it's typically assumed that all unitialised globals will be zeroed. In addition, unless you're pounding the system or memory is very tight, zeroed pages are accumulated in the idle loop, so zeroing them doesn't actually cost anything. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 19:44:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22538 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 19:44:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22530 for ; Mon, 15 Feb 1999 19:44:35 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id VAA19696; Mon, 15 Feb 1999 21:44:22 -0600 (CST) From: Kevin Day Message-Id: <199902160344.VAA19696@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: <199902160329.TAA14312@dingo.cdrom.com> from Mike Smith at "Feb 15, 1999 7:29:43 pm" To: mike@smith.net.au (Mike Smith) Date: Mon, 15 Feb 1999 21:44:21 -0600 (CST) Cc: hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I'm currently playing with FreeBSD in an embedded system, where security is > > of no concern. The system I'm using has relatively poor memory bandwidth, so > > I was looking for places to optimize. I know how the vm system zeros pages > > before giving them to me, which isn't really necessary. (I'm not sure about > > other software on the fbsd distribution, but all code I've written expects > > malloc(), new, etc to have garbage in them, not be zeroed) > > > > I don't pretend to understand the VM system, but as a quick test, I made > > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > > > > The system ran, but inetd, sed and ld kept crashing on sig 11's or 6's. > > Everything else I ran seemed ok though. While I know ther are better ways of > > doing this, am I going to be fighting a huge battle of making the kernel, as > > well as userland tools capable of dealing with nonzero'ed memory, or am I > > seeing a completely different problem? > > It's a bad idea; the C spec says that the BSS contains zeroes, so it's > typically assumed that all unitialised globals will be zeroed. > > In addition, unless you're pounding the system or memory is very tight, > zeroed pages are accumulated in the idle loop, so zeroing them doesn't > actually cost anything. > My problem is that I have virtually 0 idle time. Any time spent idle is rare, as this is a graphical application, and the faster it runs the better. CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% idle Perhaps a change that would allow for malloc()'ed and new'ed memory to be able to take memory from the to-be-zero'ed list would be better, although that may be more work than I'm looking for.... Maybe this isn't the big area for improvement I thought it would be.... Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 20:10:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25798 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 20:10:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA25790 for ; Mon, 15 Feb 1999 20:10:34 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 13340 invoked from network); 16 Feb 1999 04:10:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 04:10:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id XAA00350; Mon, 15 Feb 1999 23:10:25 -0500 (EST) Message-Id: <199902160410.XAA00350@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: from Julian Elischer at "Feb 15, 99 06:52:19 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 15 Feb 1999 23:10:25 -0500 (EST) Cc: dyson@iquest.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer said: > unreadable, and sorely lacking in comments and documentation. I for one am > grateful for Matt for doing ht ework of cleaning and commenting. I can > follow matt's commented code a lot easier than I could before, and that > means that I can now contructively comment and help. > I don't agree that the code is easier to read. Perhaps I know the structure of the code, and understand how the MACH VM system works. However, in order to understand code, I don't have to rewrite sections of it, changing things while recoding. If one wanted to write a document describing the code, they should do the Lyons's book thing. This isn't what is happening. A few added comments wouldn't be bad either. > > I agree that he might > do well to involve more people in this, but consider John that you DID > resign involvement in this code, and people, while sad to see you go, did > take you at your word. > Yep, but I don't want to see FreeBSD destroyed with hackery. > > If you are coming back to this then you will be > welcomed with oepn arms, but you need to realise that some people find it > hard sitting on their hands for 2 days waiting for an answer, and that if > you are not officially involved then they will be doing so as a courtesy. > There is missing context, and it isn't just me. > > I for one want you involved in discussing these changes because your > experience is invaluable.. however Matt is in the stage in his life at the > moment wher he has the energy of 10 raging bulls (hmm I think I'm going > overboard here), so you need to make sure that that is harnessed and used > constructively. > Bulls in a china shop more likely. > > It would be better if you were to take on the role of design adviser to > Matt, let him take responsibility for his own decisions and give him > ideas of how you would want to see things done.. > If he'd listen, it wouldn't be a problem. There is too much unidirectional communication going on, and if I didn't care about FreeBSD, I'd kind of chuckle and walk away. More than I have tried to make sure that there isn't damage... > > My opinion is that if you outline to him all the improvements you've been > envisioning, and let him do the coding, we will all come out ahead.. > you will have time to do what you need to do, Matt will get to learn your > experience, and FreeBSD will get well commented and dovumented code, that > is readble, and designed by someone that knows what they are doing (you). > Matt doesn't listen. That is the problem. I have tried put myself into a position of being listened to, and it ends up that I have to become intense. I don't like being intense, it is quite painful to me. > > You are coming across as confronatational (to me anyhow). I know you so I > know that you are not being so, but you and matt need to work out a formal > arangement. I know Matt is also a very reasonable guy, and since he > presently has some time on his hands, I think you should make use of it to > all our advantages.. > I have found Matt to be not listening. If arguments come up, it should be that *he* has to prove the significant changes that he intends to make. If there was more cooperation between those who have been involved in the VM code and him, then the need for more formal proof could be softened. The lack of cooperation is not due the original authors. At the end of this email are commit messages from vm_page.c... Are there many review by lines? If there aren't, then it is either because the developers who designed and understand the purpose of the design of the code aren't being: 1) credited, 2) consulted or 3) they aren't agreeing to the changes which are happening anyway. Frankly, I don't agree with the concepts of some of the changes, and assertions are being made without authority. This would not be so important, but Matt is a new hacker on the code. Just because one set of changes were okayed, not all of them are. It seems that 2 others and myself (probably the only three people who understand the code), have had problems in dealing with this thing. In not listening to (heeding) mine and others suggestions, it seems that there is a problem of ego, and proving oneself. That doesn't help communications. This set of public responses is a result of 3-4 wks of frustration. I am trying to open communications after a long amount of frustration, and peer pressure will be the last viable approach for me. By adopting too many quick fixes, I can truthfully say that FreeBSD will be cutting itself out of some other, more interesting things... Too much energy is being spent on an expensive "indent" process. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. ---------------------------- revision 1.126 date: 1999/02/15 06:52:14; author: dillon; state: Exp; lines: +82 -112 Minor reorganization of vm_page_alloc(). No functional changes have been made but the code has been reorganized and documented to make it more readable, reduce the size of the code, and optimize the branch path caching capabilities that most modern processors have. ---------------------------- revision 1.125 date: 1999/02/08 00:37:35; author: dillon; state: Exp; lines: +34 -91 Rip out PQ_ZERO queue. PQ_ZERO functionality is now combined in with PQ_FREE. There is little operational difference other then the kernel being a few kilobytes smaller and the code being more readable. * vm_page_select_free() has been *greatly* simplified. * The PQ_ZERO page queue and supporting structures have been removed * vm_page_zero_idle() revamped (see below) PG_ZERO setting and clearing has been migrated from vm_page_alloc() to vm_page_free[_zero]() and will eventually be guarenteed to remain tracked throughout a page's life ( if it isn't already ). When a page is freed, PG_ZERO pages are appended to the appropriate tailq in the PQ_FREE queue while non-PG_ZERO pages are prepended. When locating a new free page, PG_ZERO selection operates from within vm_page_list_find() ( get page from end of queue instead of beginning of queue ) and then only occurs in the nominal critical path case. If the nominal case misses, both normal and zero-page allocation devolves into the same _vm_page_list_find() select code without any specific zero-page optimizations. Additionally, vm_page_zero_idle() has been revamped. Hysteresis has been added and zero-page tracking adjusted to conform with the other changes. Currently hysteresis is set at 1/3 (lo) and 1/2 (hi) the number of free pages. We may wish to increase both parameters as time permits. The hysteresis is designed to avoid silly zeroing in borderline allocation/free situations. ---------------------------- revision 1.124 date: 1999/02/07 20:45:15; author: dillon; state: Exp; lines: +75 -188 Remove L1 cache coloring optimization ( leave L2 cache coloring opt ). Rewrite vm_page_list_find() and vm_page_select_free() - make inline out of nominal case. ---------------------------- revision 1.123 date: 1999/01/28 00:57:57; author: dillon; state: Exp; lines: +16 -16 Fix warnings in preparation for adding -Wall -Wcast-qual to the kernel compile ---------------------------- revision 1.122 date: 1999/01/24 07:06:52; author: dillon; state: Exp; lines: +1 -2 Undo last commit - not a bug, just duplicate code. PG_MAPPED and PG_WRITEABLE are already cleared by vm_page_protect(). ---------------------------- revision 1.121 date: 1999/01/24 06:00:31; author: dillon; state: Exp; lines: +13 -4 vm_map_split() used to dirty the page manually after calling vm_page_rename(), but never pulled the page off PQ_CACHE if it was on PQ_CACHE. Dirty pages in PQ_CACHE are not allowed and a KASSERT was added in -4.x to test for this... and got hit. In -4.x, vm_page_rename() automatically dirties the page. This commit also has it deal with the PQ_CACHE case, deactivating the page in that case. ---------------------------- revision 1.120 date: 1999/01/24 02:29:26; author: dillon; state: Exp; lines: +3 -3 Clear PG_MAPPED as well as PG_WRITEABLE when a page is moved to the cache. ---------------------------- revision 1.119 date: 1999/01/24 01:04:04; author: dillon; state: Exp; lines: +7 -2 Clear PG_WRITEABLE in vm_page_cache(). This may or may not be a bug, but the bit should definitely be cleared. ---------------------------- revision 1.118 date: 1999/01/21 10:01:49; author: dillon; state: Exp; lines: +1 -1 The hash table used to be a table of doubly-link list headers ( two pointers per entry ). The table has been changed to a singly linked list of vm_page_t pointers. The table has been doubled in size, but the entries only take half the space so a net-zero change in memory use. The hash function has been changed, hopefully for the better. The combination of the larger hash table size of changed function should keep the chain length down to a reasonable number (0-3, average 1). vm_object->page_hint has been removed. This 'optimization' was not only never needed, but costs as much as a hash chain link to implement. While having page_hint in vm_object might result in better locality of reference, the cost is not worth the space in vm_object or the extra instructions in my view. vm_page_alloc*() functions have been inlined and call a generalized non-inlined vm_page_alloc_toq() which combines the standard alloc and zero-page alloc functions together, reducing code size and the L1 cache footprint. Some reordering has been done... not much. The delinking code should be faster ( because unlinking a doubly-linked list requires four memory ops and unlinking a singly linked list only requires two ), and we get a hash consistancy check for free. vm_page_rename() now automatically sets the page's dirty bits. vm_page_alloc() does not try to manually inline freeing a cache page. Instead, it now properly calls vm_page_free(m) ... vm_page_free() is really too complex to manually inline. vm_await(), supporting asleep(), has been added. ---------------------------- revision 1.117 date: 1999/01/21 08:29:12; author: dillon; state: Exp; lines: +288 -148 This is a rather large commit that encompasses the new swapper, changes to the VM system to support the new swapper, VM bug fixes, several VM optimizations, and some additional revamping of the VM code. The specific bug fixes will be documented with additional forced commits. This commit is somewhat rough in regards to code cleanup issues. Reviewed by: "John S. Dyson" , "David Greenman" ---------------------------- revision 1.116 date: 1999/01/10 01:58:29; author: eivind; state: Exp; lines: +5 -5 KNFize, by bde. ---------------------------- revision 1.115 date: 1999/01/08 17:31:27; author: eivind; state: Exp; lines: +7 -22 Split DIAGNOSTIC -> DIAGNOSTIC, INVARIANTS, and INVARIANT_SUPPORT as discussed on -hackers. Introduce 'KASSERT(assertion, ("panic message", args))' for simple check + panic. Reviewed by: msmith ---------------------------- revision 1.114 date: 1998/12/23 01:52:47; author: dillon; state: Exp; lines: +106 -19 Update comments to routines in vm_page.c, most especially whether a routine can block or not as part of a general effort to carefully document blocking/non-blocking calls in the kernel. ---------------------------- revision 1.113 date: 1998/11/11 15:07:57; author: dg; state: Exp; lines: +4 -4 Closed a small race condition between wiring/unwiring pages that involved the page's wire_count. ---------------------------- revision 1.112 date: 1998/10/28 13:41:43; author: dg; state: Exp; lines: +3 -13 Fixed wrong comments in and about vm_page_deactivate(). ---------------------------- revision 1.111 date: 1998/10/28 13:37:02; author: dg; state: Exp; lines: +14 -6 Added a second argument, "activate" to the vm_page_unwire() call so that the caller can select either inactive or active queue to put the page on. ---------------------------- revision 1.110 date: 1998/10/25 17:44:59; author: phk; state: Exp; lines: +1 -5 Nitpicking and dusting performed on a train. Removes trivial warnings about unused variables, labels and other lint. ---------------------------- revision 1.109 date: 1998/10/21 14:46:41; author: dg; state: Exp; lines: +4 -8 Nuked PG_TABLED flag. Replaced with m->object != NULL. ---------------------------- revision 1.108 date: 1998/10/21 11:43:04; author: dg; state: Exp; lines: +2 -1 Add a diagnostic printf for freeing a wired page. This will eventually be turned into a panic, but I want to make sure that all cases of freeing pages with wire_count==1 (which is/was allowed) have first been fixed. ---------------------------- revision 1.107 date: 1998/09/04 08:06:57; author: dfr; state: Exp; lines: +11 -11 Cosmetic changes to the PAGE_XXX macros to make them consistent with the other objects in vm. ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 20:41:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28727 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 20:41:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA28722 for ; Mon, 15 Feb 1999 20:41:31 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 20280 invoked from network); 16 Feb 1999 04:41:28 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 04:41:28 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id XAA00469; Mon, 15 Feb 1999 23:41:25 -0500 (EST) Message-Id: <199902160441.XAA00469@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902160344.VAA19696@home.dragondata.com> from Kevin Day at "Feb 15, 99 09:44:21 pm" To: toasty@home.dragondata.com (Kevin Day) Date: Mon, 15 Feb 1999 23:41:25 -0500 (EST) Cc: mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day said: > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > able to take memory from the to-be-zero'ed list would be better, although > that may be more work than I'm looking for.... > That *might* be reasonable. A special sbrk or somesuch. That sbrk would make a non-prezeroed map entry. vm_fault would just avoid doing the zero. > > Maybe this isn't the big area for improvement I thought it would be.... > I don't know, but it still sounds reasonable. Excluding the duplicated break code (mostly a copy), the changes to the map code (addition of a flag or so), and fault code (check for the non-zero flag, and don't zero), that would be perhaps 20-50 lines of code or less. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 21:55:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA06317 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 21:55:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA06312 for ; Mon, 15 Feb 1999 21:55:22 -0800 (PST) (envelope-from dmm125@bellatlantic.net) Received: from bellatlantic.net (client201-122-22.bellatlantic.net [151.201.122.22]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id AAA08893 for ; Tue, 16 Feb 1999 00:56:56 -0500 (EST) Message-ID: <36C8C170.4AA85CA@bellatlantic.net> Date: Tue, 16 Feb 1999 00:53:04 +0000 From: Donn Miller X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc CC: hackers@FreeBSD.ORG Subject: Systems programming for FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm looking for some info on how to use functions like inb() and outb() to do systems-level programming on FreeBSD. 1.) I need to know the FreeBSD equiv. of the Linux function ioperm(). I would think you just use open() on /dev/pio or /dev/io with the appropriate permissions. 2.) what include files do I need to use to use inb() and outb()? In Linux it's Is using ports my only/best option for doing systems-level programming for writing drivers for video cards, or should I use assembly? There's a Linux howto on systems programming, maybe FreeBSD is similar in that respect. so I can just use the Linux howto for FreeBSD. What are ports anyway, is it like you're writing to a special part of memory? Thanks Donn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 22:40:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11269 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 22:40:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11259 for ; Mon, 15 Feb 1999 22:40:08 -0800 (PST) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.1/8.9.1) with ESMTP id WAA07957; Mon, 15 Feb 1999 22:41:01 -0800 (PST) (envelope-from vince@venus.GAIANET.NET) Date: Mon, 15 Feb 1999 22:41:01 -0800 (PST) From: Vincent Poy To: Matthew cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0 unable to receive packet by default? In-Reply-To: <001e01be58eb$9ada4ff0$0d2814ac@mattl.MAIN> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 15 Feb 1999, Matthew wrote: > Hi, guys > I just installed the 3.0 subscriber CD, I found that you can only ping out > but not some one ping you or do telnet to you. > > I found this is at the time I did a ftp out, the user name and pass phrase > passed and then i did a "ls", then I am stuck. It turns out no communication > can come back. How weird. Is this the default behavior of 3.0? I checked the > firewall thing, or route, etc. dones look like the problem. > > I'm wondering if I need to look into the net3 socket code for any change > someone in the team did. Hi Matthew, Just wondering, what kind of ethernet card do you have in the machine and which driver are you using? We have a similar problem that our Linksys DEC 21140A based 10/100 card simply doesn't work and fails the autsense when upgraded to 3.0-RELEASE. It seems that 3.0-RELEASE will not allow all routes to go through the ethernet with the gateway option set to yes in /etc/rc.conf. Our machine serves as the WAN router with the eth0 Etinc Router card interface for the PPP T1 and it seems that traceroutes from the machines on the LAN doesn't get past the box except for a few routes which it will work. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 23:48:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17597 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 23:48:19 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17592 for ; Mon, 15 Feb 1999 23:48:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA21828; Mon, 15 Feb 1999 23:48:09 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 23:48:09 -0800 (PST) From: Matthew Dillon Message-Id: <199902160748.XAA21828@apollo.backplane.com> To: "John S. Dyson" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) References: <199902152207.RAA01900@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Are you blocking on excessively large numbers of output requests? You :know *exactly* the issue at hand, and it has to do with the backpressure :needed to keep the pageout daemon from doing an evil nasty on all of the :pages in the system. : :The original version of your code appeared to have the problem, and if :you have fixed it, or you aren't queueing more than a few pageouts at :a time (perhaps <10 or so), then you are okay. Note that "pageouts" :often imply the need for "pageins", and often the same disk for "pageouts" Excuse me, John, you aren't listening. The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE does not have one single line of source to prevent excessive queueing of I/O for pageout ops. The *NEW* VM CODE does not change this unless you are talking about the getpbuf() code changes, which is nothing more then safety valve to prevent any single subsystem from eating *all* available pbuf's in order to prevent the memory interlock that can occur with that case. I've repeated this three times to you so far. It's fallen on deaf ears three times now. You keep on accusing me of doing something wrong. I keep on telling you that I haven't done what you seem to think I have done. If you are going to continue to accuse me, then point to the code that you feel is broken. -Matt Matthew Dillon :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Feb 15 23:52:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18251 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 23:52:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18246 for ; Mon, 15 Feb 1999 23:52:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA21863; Mon, 15 Feb 1999 23:52:34 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 23:52:34 -0800 (PST) From: Matthew Dillon Message-Id: <199902160752.XAA21863@apollo.backplane.com> To: "John S. Dyson" Cc: tony@dell.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? References: <199902152223.RAA01945@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> ( Matt sticks out his tongue and makes a face ) :> :There are issues and problems with exec_map and the issue needs to be revisited. :However, you are not exposing the modified VM code for review, so it isn't easy to :2nd guess what you are doing. All major changes have been CC'd to you and DG. But the best answer I get is on the order of ( paraphrased ) "I might be able to look at it in a few days, or maybe never". Anyone and everyone is welcome to tie themselves into the work I'm doing. If you want, I can post the diffs to hackers. But I can't wait indefinitely for feedback before moving onto the next step. I don't think I've gotten a single review of the diffs I emailed you and DG in the last two weeks. All I've gotten have been general diatribes from you talking about the importance of the carefull coding you did which you never documented and you seem to alternate on believing that either everyone should understand inherently, or that only you understand and nobody should touch. At best, it's insulting. -Matt :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 01:30:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA26648 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 01:30:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA26641 for ; Tue, 16 Feb 1999 01:30:57 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id EAA18992; Tue, 16 Feb 1999 04:50:41 -0500 (EST) Date: Tue, 16 Feb 1999 04:50:39 -0500 (EST) From: perlsta To: Kevin Day cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902160344.VAA19696@home.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 15 Feb 1999, Kevin Day wrote: > > > > > > I'm currently playing with FreeBSD in an embedded system, where security is > > > of no concern. The system I'm using has relatively poor memory bandwidth, so > > > I was looking for places to optimize. I know how the vm system zeros pages > > > before giving them to me, which isn't really necessary. (I'm not sure about > > > other software on the fbsd distribution, but all code I've written expects > > > malloc(), new, etc to have garbage in them, not be zeroed) > > > > > > I don't pretend to understand the VM system, but as a quick test, I made > > > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > > > > It's a bad idea; the C spec says that the BSS contains zeroes, so it's > > typically assumed that all unitialised globals will be zeroed. > > > > In addition, unless you're pounding the system or memory is very tight, > > zeroed pages are accumulated in the idle loop, so zeroing them doesn't > > actually cost anything. > > > > My problem is that I have virtually 0 idle time. Any time spent idle is > rare, as this is a graphical application, and the faster it runs the better. > > CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% > idle This sounds sort of lame, but have you any spare DMA processors to do your dirty work for you? It will obviously be slow, but you could delay having the processor zero pages until your pre-zero'd pages and DMA pages are exhausted. Another area you may be interested in investigating is reusing memory, why are you forcing the system to give you zero'd pages beyond what it normally needs? Instead of forking and execing you might want to look into persistant daemons that use userland memory pools. If performance is SUCH a concern i'm wondering why you aren't already doing this to minimize this issue. Unix offers an incredibly simple and flexible programming enviornment, not all of the methods available are effecient, if you abuse the ease, don't expect speed. Last suggestion, start compiling things with -Wall, find uninitialized variable references, report them to a commiter who will tidy things up for you. This isn't really feasable, but it'd be nice to have _someone_ doing this. :) Why does your graphical application run inetd? :) -Alfred ( i like my second suggestion, it's what i'd look into ) > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > able to take memory from the to-be-zero'ed list would be better, although > that may be more work than I'm looking for.... > > Maybe this isn't the big area for improvement I thought it would be.... > > Kevin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 01:40:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA27882 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 01:40:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA27877 for ; Tue, 16 Feb 1999 01:40:30 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id DAA02860; Tue, 16 Feb 1999 03:40:15 -0600 (CST) From: Kevin Day Message-Id: <199902160940.DAA02860@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: from perlsta at "Feb 16, 1999 4:50:39 am" To: bright@cygnus.rush.net (perlsta) Date: Tue, 16 Feb 1999 03:40:15 -0600 (CST) Cc: mike@smith.net.au, hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I'm currently playing with FreeBSD in an embedded system, where security is > > > > of no concern. The system I'm using has relatively poor memory bandwidth, so > > > > I was looking for places to optimize. I know how the vm system zeros pages > > > > before giving them to me, which isn't really necessary. (I'm not sure about > > > > other software on the fbsd distribution, but all code I've written expects > > > > malloc(), new, etc to have garbage in them, not be zeroed) > > > > > > > > I don't pretend to understand the VM system, but as a quick test, I made > > > > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > > > > > > It's a bad idea; the C spec says that the BSS contains zeroes, so it's > > > typically assumed that all unitialised globals will be zeroed. > > > > > > In addition, unless you're pounding the system or memory is very tight, > > > zeroed pages are accumulated in the idle loop, so zeroing them doesn't > > > actually cost anything. > > > > > > > My problem is that I have virtually 0 idle time. Any time spent idle is > > rare, as this is a graphical application, and the faster it runs the better. > > > > CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% > > idle > > This sounds sort of lame, but have you any spare DMA processors to do your > dirty work for you? I'm DMA'ing everything that I can practically DMA, but I believe my problem is running out of bandwidth, not CPU at this point. > > Another area you may be interested in investigating is reusing memory, why > are you forcing the system to give you zero'd pages beyond what it > normally needs? Instead of forking and execing you might want to look > into persistant daemons that use userland memory pools. If performance is > SUCH a concern i'm wondering why you aren't already doing this to minimize > this issue. Unix offers an incredibly simple and flexible programming > enviornment, not all of the methods available are effecient, if you abuse > the ease, don't expect speed. I'm doing this whenever practical. Without really saying too much about a product that isn't announced, I can say that it's one device with 15-20 seperate applications in it, that wouldn't do well to be all one giant process. We're sorely out of memory bandwidth, so any memory use we can cut down on is a big win. This is my rationale. > > Last suggestion, start compiling things with -Wall, find uninitialized > variable references, report them to a commiter who will tidy things up for > you. This isn't really feasable, but it'd be nice to have _someone_ doing > this. :) I started doing this, but it looked like more work than it would be worth. I also wasn't sure if those sorts of changes would be committed, since (to requote): > > > the C spec says that the BSS contains zeroes, so it's > > > typically assumed that all unitialised globals will be zeroed. If this is something that can be relied upon, why add implicit zero's in the code? I may end up making changes to the tools we use, if I go this route, but is that something that the majority would feel to be worthwhile? > > Why does your graphical application run inetd? :) > It doesn't, but we use inetd to launch telnetd for debugging. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 04:16:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11347 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 04:16:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11342 for ; Tue, 16 Feb 1999 04:16:05 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id WAA28929; Tue, 16 Feb 1999 22:13:37 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma028924; Tue, 16 Feb 99 22:13:30 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id WAA18270; Tue, 16 Feb 1999 22:13:29 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id WAA24190; Tue, 16 Feb 1999 22:13:29 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id WAA28362; Tue, 16 Feb 1999 22:13:26 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199902161213.WAA28362@nymph.detir.qld.gov.au> To: freebsd-hackers@FreeBSD.ORG cc: syssgm@detir.qld.gov.au, dyson@iquest.net, dillon@apollo.backplane.com, julian@whistle.com Subject: Re: inode / exec_map interlock ? (follow up) References: <199902160410.XAA00350@y.dyson.net> In-Reply-To: <199902160410.XAA00350@y.dyson.net> from "John S. Dyson" at "Mon, 15 Feb 1999 23:10:25 -0500" Date: Tue, 16 Feb 1999 22:13:26 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ignoring all mention of ego and other personal disagreements, I offer my view. Periodically I throw myself into the VM system, barely make it up to speed, fix a bug or two (if I'm lucky), and then the pace of change puts me out of the running again. On Monday, 15th February 1999, "John S. Dyson" wrote: >I don't agree that the code is easier to read. Perhaps I know the >structure of the code, and understand how the MACH VM system works. >However, in order to understand code, I don't have to rewrite sections >of it, changing things while recoding. >Too much energy is being spent on an expensive "indent" process. I find the code much easier to read now. It takes me less time to do my VM code catch-up sprint. I think the expensive indent process is well worth it, and applaud Matt's efforts. In the long run, I think it will be cheap, rather than expensive. >Yep, but I don't want to see FreeBSD destroyed with hackery. This is a danger, but with the code becoming easier to understand, I expect that changes that are performance damaging will be repaired. Some small errors have already been reverted. Others will need to be first recognised, then deliberately repaired, as below: In a separate message on Monday, 15th February 1999, "John S. Dyson" wrote: >Are you blocking on excessively large numbers of output requests? You >know *exactly* the issue at hand, and it has to do with the backpressure >needed to keep the pageout daemon from doing an evil nasty on all of the >pages in the system. The pagedaemon on a test machine of mine used to spend much time waiting on "swpfre". Now, under 4.0, the paging rate has shot up (about 2x as a guess) and it is much less responsive. Of course it has only 16Mb of ram, and I thrash it. But I favour John's view that the new swap pager has a deficiency that must be rectified before it can be considered better (in all cases) than the previous version. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 04:29:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12447 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 04:29:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from blackcat.netlink.co.uk (blackcat.netlink.co.uk [194.88.142.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12440 for ; Tue, 16 Feb 1999 04:29:23 -0800 (PST) (envelope-from adamg@netlink.co.uk) Received: from netlink.co.uk (localhost [127.0.0.1]) by blackcat.netlink.co.uk (8.8.7/8.8.7) with ESMTP id MAA07008; Tue, 16 Feb 1999 12:28:29 GMT Message-ID: <36C9646D.4BBB218D@netlink.co.uk> Date: Tue, 16 Feb 1999 12:28:29 +0000 From: Adam Goryachev Organization: Netlink Internet X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: perlsta CC: hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have asked this question on freebsd-questions and freebsd-isp (you will see why in a sec) with absolutely no response. After subscribing to -hackers yesterday and seeing this message today it seems to answer the why part of my problem. However, if anyone can suggest a how to fix part then I would be extremely grateful.... Original question follows: > OK, I have seen a number of discussions on the mailing list archives regarding > what Active pages and inactive pages and buf etc all refer to.... but I have a > slightly different question. > > The way I understand all this is that Inact pages are pages that are > available, but they need some sort of processing before they can be malloc'ed > or show up in the Free section. OK, as I kinda thought but wasn't sure, I guess this is the zero-filling section... > Now I have noticed on a rather busy web server that upon startup everything > flies along smoothly, but the amount in the inactiv section just continues > increasing.... the only time it truly seems to decrease is when apache is not > running. > Also, occasionally, the load average goes right up (sometimes up over 100) and > a process called pagedaemon is using up all the CPU time... (all in the system > section). As soon as apache is killed, it's CPU utilisation drops down to 0 > within a minute or two, and restarting apache works fine for another few > hours.... Since then I've noticed that even if you don't kill apache it does eventually return to normal, but because we know have two competing processes, apache to allocate memory and pagedaemon to free it, so it takes a while and they both run slowly.... > This is running on FreeBSD 2.2.8 with apache 1.3.3 > > Top excerpt: > last pid: 22687; load averages: 51.05, 57.35, 37.37 > 15:19:57 242 processes: 60 running, 182 sleeping > CPU states: 4.4% user, 2.2% nice, 92.1% system, 1.3% interrupt, 0.0% idle > Mem: 140K Active, 364M Inact, 65M Wired, 57M Cache, 8350K Buf, 17M Free > Swap: 214M Total, 5652K Used, 209M Free, 3% Inuse > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 2 root -18 -5 0K 12K psleep 194:00 86.82% 86.82% pagedaemon > 4 root 34 0 0K 12K update 55:54 0.50% 0.50% update > 21894 httpd 2 0 11832K 10380K sbwait 0:01 0.19% 0.19% httpd > 22191 httpd 2 0 11856K 10404K select 0:00 0.08% 0.08% httpd > > It seems to me that there is supposed to be some sort of cleaning process > running to move pages from the Inactiv to the Free, (is that what pagedaemon > does??) but it isn't doing this properly. > > If anyone has any ideas on this, please let me know. > > PS, machine has a total of 512Mb RAM. Some extra background, the machine was running 2.2.5 until the load increased to the point where it was crashing (within minutes of bootup) with the (known) bug regarding pv_entry. Thus the upgrade to 2.2.8 whereupon it started crashing with different errors. Thus we upgraded the memory to first 384Mb and then 512Mb whereupon it no longer crashes but http responses aren't as quick as would be liked and there is the occasional 'cleanup' of memory which slows things right down.... Any ideas would be greatly appreciated. PS, basically it also seems as though whenever the machine should start to swap seriously, it crashes (ie, the case before the memory upgrade on 2.2.8) has anyone else come up against this problem as well???? perlsta wrote: > > On Mon, 15 Feb 1999, Kevin Day wrote: > > > > > I'm currently playing with FreeBSD in an embedded system, where security is > > My problem is that I have virtually 0 idle time. Any time spent idle is > > rare, as this is a graphical application, and the faster it runs the better. > > > > CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% > > idle > > Another area you may be interested in investigating is reusing memory, why > are you forcing the system to give you zero'd pages beyond what it > normally needs? Instead of forking and execing you might want to look > into persistant daemons that use userland memory pools. If performance is > SUCH a concern i'm wondering why you aren't already doing this to minimize > this issue. Unix offers an incredibly simple and flexible programming > enviornment, not all of the methods available are effecient, if you abuse > the ease, don't expect speed. > > Last suggestion, start compiling things with -Wall, find uninitialized > variable references, report them to a commiter who will tidy things up for > you. This isn't really feasable, but it'd be nice to have _someone_ doing > this. :) > > Why does your graphical application run inetd? :) > > -Alfred > > ( i like my second suggestion, it's what i'd look into ) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 06:03:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20360 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 06:03:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spooky.rwwa.com (rwwa.com [198.115.177.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA20354 for ; Tue, 16 Feb 1999 06:03:46 -0800 (PST) (envelope-from witr@rwwa.com) Received: from spooky.rwwa.com (localhost.rwwa.com [127.0.0.1]) by spooky.rwwa.com (8.8.7/8.8.7) with ESMTP id JAA02654 for ; Tue, 16 Feb 1999 09:08:28 -0500 (EST) (envelope-from witr@rwwa.com) Message-Id: <199902161408.JAA02654@spooky.rwwa.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: hackers@FreeBSD.ORG Subject: Re: Processor affinity? In-reply-to: Your message of "Mon, 15 Feb 1999 17:13:40 EST." <199902152213.RAA01910@y.dyson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Feb 1999 09:08:28 -0500 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dyson@iquest.net said: :- The main problem that I was trying to solve was the silly bouncing. But it can only be called "silly" if the scheduling latency introduced by bouncing to another CPU is greater than that introduced by waiting to schedule the process on the "current" CPU, right? Have you actually measured that? It seems reasonable to me that a scheduler might cause processes to periodically bounce from CPU to CPU, and still be optimizing "global" latency...depending on what the processes are doing. Or are you using some other measure of scheduling performance than latency? --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 7:19:30 1999 Received: (from root@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29263 for freebsd-hackers; Tue, 16 Feb 1999 07:19:29 -0800 (PST) (envelope-from peter) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA22157 for ; Tue, 16 Feb 1999 06:21:50 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 19557 invoked from network); 16 Feb 1999 14:21:37 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 14:21:37 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id JAA01397; Tue, 16 Feb 1999 09:21:36 -0500 (EST) Message-Id: <199902161421.JAA01397@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902161213.WAA28362@nymph.detir.qld.gov.au> from Stephen McKay at "Feb 16, 99 10:13:26 pm" To: syssgm@detir.qld.gov.au (Stephen McKay) Date: Tue, 16 Feb 1999 09:21:36 -0500 (EST) Cc: freebsd-hackers@freebsd.org, syssgm@detir.qld.gov.au, dyson@iquest.net, dillon@apollo.backplane.com, julian@whistle.com From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Stephen McKay said: > > This is a danger, but with the code becoming easier to understand, I expect > that changes that are performance damaging will be repaired. Some small > errors have already been reverted. Others will need to be first recognised, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > then deliberately repaired, as below: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > In a separate message on Monday, 15th February 1999, "John S. Dyson" wrote: > > >Are you blocking on excessively large numbers of output requests? You > >know *exactly* the issue at hand, and it has to do with the backpressure > >needed to keep the pageout daemon from doing an evil nasty on all of the > >pages in the system. > > The pagedaemon on a test machine of mine used to spend much time waiting on > "swpfre". Now, under 4.0, the paging rate has shot up (about 2x as a guess) > and it is much less responsive. Of course it has only 16Mb of ram, and I > thrash it. But I favour John's view that the new swap pager has a deficiency > that must be rectified before it can be considered better (in all cases) than > the previous version. > The very sad thing is that I told him about it a long time ago (before the commit.) He hasn't acknowleged it. I knew it before even testing the code, because I even understand what HE is doing, because I read code. The old code did block, and he noted that and somehow believed in his infinite wisdom that it shouldn't. The old code wouldn't have blocked if it would have worked better. This is one example, but the vast number of fast changes will increase entropy significantly. Maybe the code is easier to read, because some of the functionality and quality is being stripped out, trading simplicity? -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 7:22:36 1999 Received: (from root@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29601 for freebsd-hackers; Tue, 16 Feb 1999 07:22:35 -0800 (PST) (envelope-from peter) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA24206 for ; Tue, 16 Feb 1999 06:33:34 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 1608 invoked from network); 16 Feb 1999 14:33:30 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 14:33:30 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id JAA01411; Tue, 16 Feb 1999 09:33:30 -0500 (EST) Message-Id: <199902161433.JAA01411@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902160748.XAA21828@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 11:48:09 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 16 Feb 1999 09:33:30 -0500 (EST) Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > :Are you blocking on excessively large numbers of output requests? You > :know *exactly* the issue at hand, and it has to do with the backpressure > :needed to keep the pageout daemon from doing an evil nasty on all of the > :pages in the system. > : > :The original version of your code appeared to have the problem, and if > :you have fixed it, or you aren't queueing more than a few pageouts at > :a time (perhaps <10 or so), then you are okay. Note that "pageouts" > :often imply the need for "pageins", and often the same disk for "pageouts" > > Excuse me, John, you aren't listening. > > The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE > does not have one single line of source to prevent excessive queueing > of I/O for pageout ops. > You are wrong. Please look at the code. I will point the code out to you if you want, but I suspect that you don't want to know. > > You keep on accusing me of doing something wrong. I keep on telling you > that I haven't done what you seem to think I have done. If you are going > to continue to accuse me, then point to the code that you feel is broken. > You are wrong. It is entertaining to me to see you make such strong responses to simple, truthful assertions, and proof is simple. That makes me suspect that you really didn't understand the code, and is why I am quite worried about the changes that you have been making. I truely believed that you understood how the original swap pager worked, and now, I suspect that you only parroted the design, missing some important points. If there wasn't a tsleep or two in the code in strategic areas, I could have possibly understood your position. :-). The data structure improvements that you made in the swap pager were valuable, however you also stripped out important functionality. Already, there is anecdotal information regarding performance regressions. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 7:23:24 1999 Received: (from root@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29638 for freebsd-hackers; Tue, 16 Feb 1999 07:23:21 -0800 (PST) (envelope-from peter) Received: from csmd2.cs.uni-magdeburg.de (prinz-atm.CS.Uni-Magdeburg.De [141.44.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25382 for ; Tue, 16 Feb 1999 06:41:54 -0800 (PST) (envelope-from jesse@prinz-atm.CS.Uni-Magdeburg.De) Received: from knecht.cs.uni-magdeburg.de (knecht [141.44.21.3]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id PAA28193 for ; Tue, 16 Feb 1999 15:41:45 +0100 (MET) Received: (from jesse@localhost) by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) id PAA01708 for freebsd-hackers@freebsd.org; Tue, 16 Feb 1999 15:41:45 +0100 (MET) Message-ID: <19990216154145.A1700@cs.uni-magdeburg.de> Date: Tue, 16 Feb 1999 15:41:45 +0100 From: Roland Jesse To: freebsd-hackers@freebsd.org Subject: Makefile: >1 program without a single target each. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Assumed, I have the source code for more than just one program in a directory (because they share a couple source code files). How does the Makefile has to / should look like? Normally, I would do something like: PROG= myprog SRCS= myprog.c utils.c otherstuff.c NOMAN= No manual page yet. BINDIR= /usr/local/bin .include This is passed to: OBJS+= ${SRCS:N*.h:R:S/$/.o/g} ${PROG}: ${OBJS} ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDDESTDIR} ${LDADD} But what do I do when the Makefile is supposed to handle more than just one potential target? How do I specify the OBJS variable depending on the different source files? Scenario: PROG1= myprog PROG2= herprog SRCS1= myprog.c utils.c otherstuff.c SRCS2= herprog.c herprog.h utils.c otherstuff.c NOMAN= No manual page yet. BINDIR= /usr/local/bin .include I do not want to specify the whole compilation line for each program like in: MYOBJS= myprog.o utils.o otherstuff.o myprog: $(MYOBJS) ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} $(MYOBJS) ${LDDESTDIR} ${LDADD}HEROBJS= herprog.o utils.o otherstuff.o herprog: $(HEROBJS) ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} $(HEROBJS) ${LDDESTDIR} ${LDADD} Any ideas to get around the OBJS-problem are appreciated. Roland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 7:24:31 1999 Received: (from root@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29691 for freebsd-hackers; Tue, 16 Feb 1999 07:24:30 -0800 (PST) (envelope-from peter) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA27424 for ; Tue, 16 Feb 1999 07:01:42 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 24800 invoked from network); 16 Feb 1999 14:54:59 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 14:54:59 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id JAA01466; Tue, 16 Feb 1999 09:54:59 -0500 (EST) Message-Id: <199902161454.JAA01466@y.dyson.net> Subject: Re: inode / exec_map interlock ? In-Reply-To: <199902160752.XAA21863@apollo.backplane.com> from Matthew Dillon at "Feb 15, 99 11:52:34 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 16 Feb 1999 09:54:59 -0500 (EST) Cc: dyson@iquest.net, tony@dell.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > :> > :> ( Matt sticks out his tongue and makes a face ) > :> > :There are issues and problems with exec_map and the issue needs to be revisited. > :However, you are not exposing the modified VM code for review, so it isn't easy to > :2nd guess what you are doing. > > All major changes have been CC'd to you and DG. But the best answer I > get is on the order of ( paraphrased ) "I might be able to look at it > in a few days, or maybe never". > Please refer to my comments on suggested design requirements (specifically those on 10 Jan 99). If you violated those suggestions, maybe it is important to require formal review. Regressions aren't what FreeBSD needs. I happen to think in terms of higher level design issues (coding, programming and indenting are superficial to me). Does this mean that I have to start resolving design concepts to code? Geesh, I am very busy, and writing code to correct mistakes is really not fair to me. Maybe you should take on the attitude of encompassing more developers into your fold, and then *wait* until testing and information is returned before committing. Then, if there are comments that are contrary to your creation, DISCUSS that with the *experts* rather than ignoring something that you don't want to hear. It seems that a mature developer would wait until a process can complete. You have innundated people with code, and review is more complex than just looking at syntax issues. If you are indeed such a fast programmer, and since important ideas are being overlooked, maybe more time should be spent understanding what is going on. * The term *experts* isn't due to arrogance, but due to 4-5years of experience and mistakes. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 8: 4:38 1999 Received: from ice.cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02594 for ; Tue, 16 Feb 1999 08:04:34 -0800 (PST) (envelope-from brandon@ice.cold.org) Received: (from brandon@localhost) by ice.cold.org (8.8.8/8.8.5) id IAA15322 for freebsd-hackers@freebsd.org; Tue, 16 Feb 1999 08:26:00 -0700 (MST) Date: Tue, 16 Feb 1999 08:26:00 -0700 From: Brandon Gillespie To: freebsd-hackers@freebsd.org Subject: savecore before swapon? Message-ID: <19990216082600.A15274@ice.cold.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=AhhlLboLdkugWU4S; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.1i X-Operating-System: FreeBSD 2.2.8-RELEASE X-PGP-Public-Key: http://www.roguetrader.com/~brandon/brandon@roguetrader_com.pubkey Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii I havn't checked the source, but from my understanding shouldn't savecore be run before swapon is run, incase the swap device is the dump device? Or to look at it another way, when swapon is run on a swap device, does it look first to see if there is a dump in it, and if so what does it do? Right now we run swapon, then considerably later we run savecore. Assuming swapon just trashes whatever was in that device, running savecore is pretty much irrelevant, as most people I know (not necessarily in FreeBSD) use their swap device as a dump point. -Brandon Gillespie --AhhlLboLdkugWU4S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: QdTvRq5UZqLiWdxwbSK39V8oK9jyx/G6 iQA/AwUBNsmOBkv5XoQiMgn6EQIavgCg4AH9PCAUNwDQuTx/3rQ5HghKWAcAnA/j nAtTLcFbuhwklh08UcyDuIXG =XjDd -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 8:46:26 1999 Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA08004 for ; Tue, 16 Feb 1999 08:46:24 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id RAA14186 for ; Tue, 16 Feb 1999 17:03:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64881 for hackers@freebsd.org; Tue, 16 Feb 1999 17:03:12 +0100 (MET) Date: Tue, 16 Feb 1999 17:03:10 +0100 From: Eivind Eklund To: hackers@freebsd.org Subject: gdb sucks - and I need to get around it. help? Message-ID: <19990216170310.C60651@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anybody know of any way of getting gdb to step from the start of the program? I have an executable with absolutely no symbol data (symbol data is absolutely non-available) which I *have* to get to step through, if necessary by re-implementing gdb. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:17: 3 1999 Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11791 for ; Tue, 16 Feb 1999 09:16:54 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 16 Feb 1999 17:16:38 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 1LNB7XA8; Tue, 16 Feb 1999 17:11:12 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10Co9E-000J2n-00; Tue, 16 Feb 1999 17:19:00 +0000 To: Roland Jesse Cc: freebsd-hackers@freebsd.org Subject: Re: Makefile: >1 program without a single target each. X-Mailer: nmh v0.26 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Roland Jesse's message of "Tue, 16 Feb 1999 15:41:45 +0100" <19990216154145.A1700@cs.uni-magdeburg.de> Date: Tue, 16 Feb 1999 17:19:00 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16 February 1999, Roland Jesse proclaimed: > Assumed, I have the source code for more than just one program in a > directory (because they share a couple source code files). How does > the Makefile has to / should look like? From the top of /usr/src/share/mk/bsd.README: ------------------------------------------------------------------------ It's fairly difficult to make the BSD .mk files work when you're building multiple programs in a single directory. It's a lot easier split up the programs than to deal with the problem. Most of the agony comes from making the "obj" directory stuff work right, not because we switch to a new version of make. So, don't get mad at us, figure out a better way to handle multiple architectures so we can quit using the symbolic link stuff. (Imake doesn't count.) ------------------------------------------------------------------------ As to handling common code, you can handle this in other ways using the Makefile. I think specifying one of the OBJS files as ../otherprog/mysrc.c will do the trick, although I don't think it's the cleanest way. You may want to consider building a small library. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:17:31 1999 Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11843 for ; Tue, 16 Feb 1999 09:17:27 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id RAA01752; Tue, 16 Feb 1999 17:17:18 GMT From: Emmanuel DELOGET Message-Id: <199902161717.RAA01752@excalibur.oceanis.net> Subject: Re: Makefile: >1 program without a single target each. In-Reply-To: <19990216154145.A1700@cs.uni-magdeburg.de> from Roland Jesse at "Feb 16, 1999 3:41:45 pm" To: jesse@prinz-atm.CS.Uni-Magdeburg.De (Roland Jesse) Date: Tue, 16 Feb 1999 18:17:18 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As the well known Roland Jesse said... -> Hello, -> -> Assumed, I have the source code for more than just one program in a -> directory (because they share a couple source code files). How does -> the Makefile has to / should look like? -> -> Normally, I would do something like: -> -> [makefile deleted] -> -> But what do I do when the Makefile is supposed to handle more than -> just one potential target? How do I specify the OBJS variable -> depending on the different source files? -> -> [other deleted makefile] -> -> Any ideas to get around the OBJS-problem are appreciated. -> My idea is you may use a classic src/lib, src/prg1, src/prg2 directory tree. You may put the shared source files in the lib directory, with an independant Makefile. Then, in the other directories, you put the proggies related source code. I like this architecture, because it's very clear (don't spend hours about searching which files are related to a project, and which files are not). You may put a more basic makefile in the top src dir (something like # top Makefile ------------------------------------------------ TARGETDIRS = lib prg1 prg2 all : @for i in $(TARGETDIRS); do \ @echo "** entering directory "$$i ; \ (cd $$i ; $(MAKE) all CFLAGS=$(CFLAGS) ); \ @echo "** living directory "$$i ; \ done # src/lib Makefile --------------------------------------------- LIBNAME = mylib SRCS = lib_1.C lib_2.c lib_n.c OBJS = $(SRCS:.c=.o) all : $(OBJS) @$(AR) $(CREATEARCHVE) lib$(LIBNAME).a $(OBJS) @$(RANLIB) $(RANLIBOPTIONS) lib$(LIBNAME).a # src/prgn Makefile -------------------------------------------- # you may use the bsd.prog.mk file here, of course... LIBDIR += -L../lib LIBS += -lmylib SRCS = prgn_1.c prgn_p.c OBJS = $(SRCS:.c=.o) PRGNAME = prgn all : $(OBJS) $(CC) $(CFLAGS) -o $(PRGNAME) $(LIBDIR) $(LIBS) Of course, this is just an idea... ;) -> Roland -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:30:32 1999 Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13410 for ; Tue, 16 Feb 1999 09:30:25 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id MAA13779; Tue, 16 Feb 1999 12:50:00 -0500 (EST) Date: Tue, 16 Feb 1999 12:49:59 -0500 (EST) From: perlsta To: Kevin Day cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902160940.DAA02860@home.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Kevin Day wrote: > > > CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% > > > idle > > > > This sounds sort of lame, but have you any spare DMA processors to do your > > dirty work for you? > > I'm DMA'ing everything that I can practically DMA, but I believe my problem > is running out of bandwidth, not CPU at this point. I meant DMA'ing zero's into pages, but if you don't think that it's CPU then this may not help. > > Another area you may be interested in investigating is reusing memory, why > > are you forcing the system to give you zero'd pages beyond what it > > normally needs? Instead of forking and execing you might want to look > > into persistant daemons that use userland memory pools. If performance is > > SUCH a concern i'm wondering why you aren't already doing this to minimize > > this issue. Unix offers an incredibly simple and flexible programming > > enviornment, not all of the methods available are effecient, if you abuse > > the ease, don't expect speed. > > I'm doing this whenever practical. Without really saying too much about a > product that isn't announced, I can say that it's one device with 15-20 > seperate applications in it, that wouldn't do well to be all one giant > process. > > We're sorely out of memory bandwidth, so any memory use we can cut down on > is a big win. This is my rationale. This is my rationale here as well, you say you need performance but yet you aren't willing to meet halfway. You do NOT need to combine all your modular programs into a single large monolithic monstrosity, all i'm saying is that you may want to have each smaller program stay resident and answer requests via some sort of IPC mechanism instead of establishing simple pipelines as you constantly fork/exec. You are choosing easy, not speed. > > Last suggestion, start compiling things with -Wall, find uninitialized > > variable references, report them to a commiter who will tidy things up for > > you. This isn't really feasable, but it'd be nice to have _someone_ doing > > this. :) > > I started doing this, but it looked like more work than it would be worth. I > also wasn't sure if those sorts of changes would be committed, since (to > requote): I was sort of kidding about that suggestion. > > > > > the C spec says that the BSS contains zeroes, so it's > > > > typically assumed that all unitialised globals will be zeroed. > > If this is something that can be relied upon, why add implicit zero's in the > code? because lazy coders have depended on that feature for years now, and changing it would break too many things. not only that but it's nice to know that _some_ things will be zero'd out for you. > I may end up making changes to the tools we use, if I go this route, but is > that something that the majority would feel to be worthwhile? *shrug* i'm not a commiter > > > > > Why does your graphical application run inetd? :) > > > > > It doesn't, but we use inetd to launch telnetd for debugging. :) > oh :) -Alfred > > > Kevin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:33:19 1999 Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA13631 for ; Tue, 16 Feb 1999 09:33:17 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 15235 invoked from network); 16 Feb 1999 14:46:24 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 14:46:24 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id JAA01457; Tue, 16 Feb 1999 09:46:24 -0500 (EST) Message-Id: <199902161446.JAA01457@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902161433.JAA01411@y.dyson.net> from "John S. Dyson" at "Feb 16, 99 09:33:30 am" To: dyson@iquest.net Date: Tue, 16 Feb 1999 09:46:24 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John S. Dyson said: > Matthew Dillon said: > > > > The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE > > does not have one single line of source to prevent excessive queueing > > of I/O for pageout ops. > > > You are wrong. Please look at the code. I will point the code out to you > if you want, but I suspect that you don't want to know. > Please refer to the message that I sent to you on 10 Jan 99 for some more information in that arena. Apparently you didn't listen -- and what I said describes essentially what the nastier (but correctly working) swap pager does. I even explained to you in terms of "clogging" the I/O subsystem and blindly freeing pages. That is a *very* real problem, and the old swap pager largely stopped that from happening. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:42:51 1999 Received: from picnic.mat.net (b133.mat.net [206.246.122.133] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14530; Tue, 16 Feb 1999 09:42:43 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id MAA00747; Tue, 16 Feb 1999 12:41:34 -0500 (EST) Date: Tue, 16 Feb 1999 12:41:34 -0500 (EST) From: Chuck Robey To: Eivind Eklund cc: hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <19990216170310.C60651@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Eivind Eklund wrote: > Anybody know of any way of getting gdb to step from the start of the > program? > > I have an executable with absolutely no symbol data (symbol data is > absolutely non-available) which I *have* to get to step through, if > necessary by re-implementing gdb. You can tell the absolute address of main(), right? Can't you just set a breakpoint of the program to the address of main() directly (not symbolically) then start the program. It should stop immediately, then you can single step until you fall asleep, right? That's all if this is a C program. If it's C++, where there is stuff active even before main(), then I'm not sure the address you'd want, but it'd NOT be main(). I think I'd get it via objdump. It could read the elf headers and get it. > > Eivind. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:49:39 1999 Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15296 for ; Tue, 16 Feb 1999 09:49:38 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.2) with ESMTP id JAA22063; Tue, 16 Feb 1999 09:49:18 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Emmanuel DELOGET cc: jesse@prinz-atm.CS.Uni-Magdeburg.De (Roland Jesse), hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) Subject: Re: Makefile: >1 program without a single target each. In-reply-to: Your message of "Tue, 16 Feb 1999 18:17:18 +0100." <199902161717.RAA01752@excalibur.oceanis.net> Date: Tue, 16 Feb 1999 09:49:18 -0800 Message-ID: <22059.919187358@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > # top Makefile ------------------------------------------------ > TARGETDIRS = lib prg1 prg2 In BSD make, this is handled by SUBDIR=... and - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 9:57: 6 1999 Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA15954 for ; Tue, 16 Feb 1999 09:57:04 -0800 (PST) (envelope-from will@ns.oeno.com) Received: (qmail 23404 invoked by uid 1001); 16 Feb 1999 17:57:02 -0000 Date: 16 Feb 1999 17:57:01 -0000 Message-ID: <19990216175701.23401.qmail@ns.oeno.com> From: Ville-Pertti Keinonen To: tlambert@primenet.com CC: dyson@iquest.net, hackers@FreeBSD.ORG In-reply-to: <199902160045.RAA22056@usr02.primenet.com> (message from Terry Lambert on Tue, 16 Feb 1999 00:45:20 +0000 (GMT)) Subject: Re: Processor affinity? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A very trivial affinity soloution is to have per CPU scheduler > queues, and to keep a "quantum count" per CPU as well. Any kind of processor load calculation was what I was referring to by "moderately complex". Not that I don't think that it's worth it. > Processes becoming "ready to run" are queued on the processor with > the highest quantum count (e.g., highest process turnover rate, > indicating relatively higher I/O binding). Ignoring long-running, low-priority processes? They shouldn't affect the turnover rate because they can typically be pre-empted when an I/O bound process wakes up. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 10: 3: 8 1999 Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16528 for ; Tue, 16 Feb 1999 10:03:06 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id SAA02685; Tue, 16 Feb 1999 18:02:51 GMT From: Emmanuel DELOGET Message-Id: <199902161802.SAA02685@excalibur.oceanis.net> Subject: Re: Makefile: >1 program without a single target each. In-Reply-To: <22059.919187358@zippy.cdrom.com> from "Jordan K. Hubbard" at "Feb 16, 1999 9:49:18 am" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Tue, 16 Feb 1999 19:02:50 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As the well known Jordan K. Hubbard said... -> > # top Makefile ------------------------------------------------ -> > TARGETDIRS = lib prg1 prg2 -> -> In BSD make, this is handled by SUBDIR=... and Well... BSD is fabulous ;) I never looked at bsd.*.mk files - seems it may be a good idea to look at these. Thanx a lot. -> -> - Jordan -> -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 10: 8: 6 1999 Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16969 for ; Tue, 16 Feb 1999 10:08:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA37094; Tue, 16 Feb 1999 10:08:01 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 10:08:01 -0800 (PST) From: Matthew Dillon Message-Id: <199902161808.KAA37094@apollo.backplane.com> To: "John S. Dyson" Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) References: <199902161446.JAA01457@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is getting more then ridiculous. Tell me what the hell you think is broken rather then refer me to things that are just as vague as the last 6 emails we've traded. Right now all I see is you reacting to incorrect information with even more incorrect information and taking every comment made by people and turning it into an indictment without even so much as a shred of hard data to back it up. Tell me, specifically, what you believe is broken and where it is or stop talking to me alltogether. I absolutely refuse to be a party to this sort of shit any longer. I've attempted to get you to clarify what you believe the problem to be FOUR times now. And *FOUR* times I haven't gotten jack. -Matt Matthew Dillon :John S. Dyson said: :> Matthew Dillon said: :> > :> > The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE :> > does not have one single line of source to prevent excessive queueing :> > of I/O for pageout ops. :> > :> You are wrong. Please look at the code. I will point the code out to you :> if you want, but I suspect that you don't want to know. :> :Please refer to the message that I sent to you on 10 Jan 99 for some more :information in that arena. Apparently you didn't listen -- and what I :said describes essentially what the nastier (but correctly working) :swap pager does. : :I even explained to you in terms of "clogging" the I/O subsystem and blindly :freeing pages. That is a *very* real problem, and the old swap pager largely :stopped that from happening. : :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 10:20:13 1999 Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18020 for ; Tue, 16 Feb 1999 10:20:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA37246; Tue, 16 Feb 1999 10:19:59 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 10:19:59 -0800 (PST) From: Matthew Dillon Message-Id: <199902161819.KAA37246@apollo.backplane.com> To: Stephen McKay Cc: freebsd-hackers@freebsd.org, syssgm@detir.qld.gov.au, dyson@iquest.net, julian@whistle.com Subject: Re: inode / exec_map interlock ? (follow up) References: <199902160410.XAA00350@y.dyson.net> <199902161213.WAA28362@nymph.detir.qld.gov.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The pagedaemon on a test machine of mine used to spend much time waiting on :"swpfre". Now, under 4.0, the paging rate has shot up (about 2x as a guess) :and it is much less responsive. Of course it has only 16Mb of ram, and I :thrash it. But I favour John's view that the new swap pager has a deficiency :that must be rectified before it can be considered better (in all cases) than :the previous version. : :Stephen. The swpfre blockage was explicitly commented as being there to avoid a low-memory deadlock. Nothing more, nothing less. It was removed when there was no more danger of there being a low-memory deadlock. If it is supposed to serve another undocumented function it would not be particularly difficult to adjust the getpbuf() in the new swap pager to a trypbuf() and limit the number of parallel I/O's in that regard. In fact, it would be trivial. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 10:24: 4 1999 Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18555 for ; Tue, 16 Feb 1999 10:24:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA37290; Tue, 16 Feb 1999 10:23:41 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 10:23:41 -0800 (PST) From: Matthew Dillon Message-Id: <199902161823.KAA37290@apollo.backplane.com> To: perlsta Cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > This sounds sort of lame, but have you any spare DMA processors to do your :> > dirty work for you? :> :> I'm DMA'ing everything that I can practically DMA, but I believe my problem :> is running out of bandwidth, not CPU at this point. : :I meant DMA'ing zero's into pages, but if you don't think that it's CPU :then this may not help. If his problem is memory bandwidth, DMA won't help. If this is a turnkey application then there shouldn't be a page zeroing problem at all unless the application requires programs to be exec'd all over the place ( like a couple of times a second or worse ). If the application does not require a lot of program execing, then there are plenty of ways to mitigate the zeroing - in fact, the standard malloc()/free() already does it within the life of a process. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 10:38:27 1999 Received: from csmd2.cs.uni-magdeburg.de (prinz-atm.CS.Uni-Magdeburg.De [141.44.30.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19574 for ; Tue, 16 Feb 1999 10:38:19 -0800 (PST) (envelope-from jesse@prinz-atm.CS.Uni-Magdeburg.De) Received: from knecht.cs.uni-magdeburg.de (knecht [141.44.21.3]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id TAA07701 for ; Tue, 16 Feb 1999 19:38:13 +0100 (MET) Received: (from jesse@localhost) by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) id TAA09659 for freebsd-hackers@freebsd.org; Tue, 16 Feb 1999 19:38:12 +0100 (MET) Message-ID: <19990216193812.A9655@cs.uni-magdeburg.de> Date: Tue, 16 Feb 1999 19:38:12 +0100 From: Roland Jesse To: freebsd-hackers@freebsd.org Subject: Re: Makefile: >1 program without a single target each. Mail-Followup-To: freebsd-hackers@freebsd.org References: <19990216154145.A1700@cs.uni-magdeburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Dom Mitchell on Tue, Feb 16, 1999 at 05:19:00PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dom Mitchell wrote: > >From the top of /usr/src/share/mk/bsd.README: Ok, RTFM, I knew that I missed something. Thanks for all your fast replies. If everybody besides me thinks it bad to put everything into one single directory, it is probably a bad idea. Roland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11: 9:19 1999 Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21598 for ; Tue, 16 Feb 1999 11:09:17 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id LAA07575; Tue, 16 Feb 1999 11:09:16 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id LAA36579; Tue, 16 Feb 1999 11:09:15 -0800 (PST) (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 In-Reply-To: <199902161902.OAA29475@gatekeeper.itribe.net> Date: Tue, 16 Feb 1999 11:09:15 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Jamie Bowden Subject: Re: FreeBSD mention in LWN interview with A.C. Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jamie Bowden wrote: > On Mon, 15 Feb 1999, John Polstra wrote: > >> It's much slower than CVSup. > > Aren't you slightly biased? ;) Of course I'm biased, but that doesn't change the validity of my statement. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:10:46 1999 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA22020 for ; Tue, 16 Feb 1999 11:10:44 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <55762(5)>; Tue, 16 Feb 1999 11:10:43 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177546>; Tue, 16 Feb 1999 11:10:34 -0800 To: Brandon Gillespie cc: freebsd-hackers@freebsd.org Subject: Re: savecore before swapon? In-reply-to: Your message of "Tue, 16 Feb 99 07:26:00 PST." <19990216082600.A15274@ice.cold.org> Date: Tue, 16 Feb 1999 11:10:30 PST From: Bill Fenner Message-Id: <99Feb16.111034pst.177546@crevenia.parc.xerox.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Swapon doesn't actually modify the device, it just makes it available for swapping. So savecore will work if no swapping happens between the swapon and the savecore. However, you're right that the savecore should probably happen before the swapon. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:13:18 1999 Received: from gatekeeper.whistle.com (gatekeeper.whistle.com [207.76.204.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22285 for ; Tue, 16 Feb 1999 11:13:14 -0800 (PST) (envelope-from ambrisko@whistle.com) Received: (from smap@localhost) by gatekeeper.whistle.com (8.8.8/8.8.7) id LAA07536 for ; Tue, 16 Feb 1999 11:13:13 -0800 (PST) (envelope-from ambrisko@whistle.com) Received: from alpo.whistle.com(unknown 207.76.204.38) by gatekeeper.whistle.com via smap (V2.0) id xma007525; Tue, 16 Feb 99 11:12:46 -0800 Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA00571; Tue, 16 Feb 1999 11:01:19 -0800 (PST) Received: from crab.whistle.com(207.76.205.112), claiming to be "whistle.com" via SMTP by alpo.whistle.com, id smtpdNCU565; Tue Feb 16 19:01:16 1999 Received: (from ambrisko@localhost) by whistle.com (8.9.1/8.9.1) id LAA77291; Tue, 16 Feb 1999 11:00:21 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <199902161900.LAA77291@whistle.com> Subject: Re: Oskit and 3.0? In-Reply-To: from Julian Elischer at "Feb 14, 99 02:35:27 pm" To: julian@whistle.com (Julian Elischer) Date: Tue, 16 Feb 1999 11:00:21 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL29 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer writes: | we netboot elf kernels and aout kernels here.. | check with doug ambrisko (ambrisko@whistle.com) for his netbooting stuff. It would be nice if some commiter would commit pr: [1999/01/13] ports/9480 ports ELF kernel netboot I know one person is using is using it besides me. Note that since then we have found 2 bugs in it. One is that in my patches I forgot and init_serial in main and used option 131 for boot how to which was used for swap options. If someone lets me know if they are going to commit it then I will send them the patches. It is better then nothing and they support more cards then FreeBSD netboot. That OSKit looks interesting. BTW here is another data point for bootp/tftp kernel booting, iMac and other open firmware Mac's boot via bootp/tftp. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:15:54 1999 Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22536 for ; Tue, 16 Feb 1999 11:15:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA37772; Tue, 16 Feb 1999 11:15:44 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 11:15:44 -0800 (PST) From: Matthew Dillon Message-Id: <199902161915.LAA37772@apollo.backplane.com> To: perlsta Cc: "John S. Dyson" , freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I've noticed that the 'old' swapper or system seemed to leave a LOT of :swap still used en it wasn't trully needed. The new system seems to :reclaim these regeons as soon as they are swapped in. I've noticed the :new swapper is a bit more 'peppy' but i'm concerned that it is dooing what :John says. : :What's the deal here? Matt, even though your swapper lists pages as :'free' does it actually keep them around for reuse? What happens when a :page is READ faulted in, is the backing swap kept allocated to save on IO :later? The new swapper fixes a bunch of things, but the main thing you are probably seeing is the on-the-fly reallocation of swap backing store when swapping out dirty pages and the semi-on-the-fly deallocation of swap backing store when a page is dirtied again. The async I/O swamping problem is so minor it's hardly worth 4 hours of flying felder carp. It took 5 minutes to fix once someone ( other then John ) figured out what the problem was. It should be noted that the original code was documented *solely* as solving a low memory lockup condition. It said absolutely nothing about limiting parallel I/O. Anywhere. In fact, in a large-memory configuration the original code *wouldn't* limit the I/O load because it was scaled to the free page margin rather then scaled to I/O load. What a complete and utter waste of time. -Matt Matthew Dillon :One other thing, I has some trouble getting to sleep last night and :decided to venture into src/sys/vm, the comments are VERY helpful. The :kind of documentation going on here will really help people get into :systems programming, it is MUCH appreciated. : :-Alfred : : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:26:18 1999 Received: from mail.nerds4rent.com (ns2.freedomnet.com [198.240.104.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23537 for ; Tue, 16 Feb 1999 11:26:12 -0800 (PST) (envelope-from kbyanc@freedomnet.com) Received: from tech (tech.nerds4rent.com [198.240.104.20]) by mail.nerds4rent.com (8.8.8/8.8.8/antispam) with SMTP id OAA12536 for ; Tue, 16 Feb 1999 14:36:24 -0500 (EST) X-Envelope-To: From: "Kelly Yancey" To: Subject: symbol export question Date: Tue, 16 Feb 1999 14:32:15 -0500 Message-ID: <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I saw a similar question pop up a few days ago relating to Apache's DSO model, but I never saw an answer. I have a similar problem that I'm hoping that someone with more dynamic library experience can help me with... I have written a program which loads dynamic libraries using dlopen() and friends to implement optional functionality. The main executable can call dlsym() to properly resolve the symbols in the libraries and the libraries can call symbols exported from the main executable. Everything works. Now, for the trick...the only reason I can get it to work right is because I pass the -Xlinker -E parameter(s) to gcc so that it tells ld to export *all* the symbols in each the main executable and the modules. While this works, it seems like a nasty kludge. I looked at the PAM sources under /usr/src/lib/libpam and see that if PAM is compiled to use dynamic modules, it defines PAM_EXPORT as extern (which is then in turn used for each symbol declaration to be exported). Well, I have 2 problems with that: 1) I can't get it to work for me...I wrote a little test program to try it out which simply declares a single routine extern, when the module loads and tries to call the extern'ed routine in the main executable...it says "unresolved symbol..." The problem goes away as soon as I pass -Xlinker -E to gcc. 2) The real program is made of many source files with extern declarations all over the place to allow other object files to reference those symbols. I would really prefer if I could only share a subset of those routines with the modules (ie. only export a select set of functions from the executable). The same applies to some of the modules (although I don't really care as much except to prevent symbol conflicts between the main executable and modules). So the question is: what is the proper way to export symbols from an executable so that dynamicly loaded libraries can access just those symbols (not all symbols in the executable)? Presumably the same holds true for building libraries which don't export all of their symbols. Oh, and on a related note: the man page for dlopen() indicates that dlopen invokes _init() and dlclose() invokes _fini() in the dynamic library. My own testing indicates that while this is true, the standard C library implements _init() which calls main() (presumably all programs are actually started my calling _init() which the standard library handles and in turn calls the familiar main() ...for C at least). I suppose the standard library also intercepts _fini() and performs cleanup too. I found that I can get around the preprocessing by passing -nostdlib to gcc and implementing _init() and _fini() in the libraries myself. Is this advisable? What kind of cleanup could the standard library possibly be doing in _fini() and is there any other way for me to hook into to _fini() operation? I'de like to be able to dynamically add (or occasionally) remove the libraries from my process's address space and I need a way for the library to know when it is getting unloaded so that it can restore and vectors in the main executable it hooked. I suppose I could implement my own function in each library which the process calls before dlclose()ing it, but it just seems so nice to be able to use the function already provided for that purpose. I'm sorry that this e-mail came out so long...I know I'm really trying to pick some of those brains out there. But I appreciate any help I can get. Thanks very much in advance, Kelly ~kbyanc@posi.net~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:30:44 1999 Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA23948 for ; Tue, 16 Feb 1999 11:30:42 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 12795 invoked from network); 16 Feb 1999 19:30:40 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 16 Feb 1999 19:30:40 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA00391; Tue, 16 Feb 1999 14:30:39 -0500 (EST) Message-Id: <199902161930.OAA00391@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: from perlsta at "Feb 16, 99 02:20:45 pm" To: bright@cygnus.rush.net (perlsta) Date: Tue, 16 Feb 1999 14:30:39 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG perlsta said: > > I've noticed that the 'old' swapper or system seemed to leave a LOT of > swap still used en it wasn't trully needed. The new system seems to > reclaim these regeons as soon as they are swapped in. I've noticed the > new swapper is a bit more 'peppy' but i'm concerned that it is dooing what > John says. > Matt's code has a better allocator, and for that I applaud the code. Regressing behavior, when information is available and offered is not forward progress, but a loss of technology. You could have had the superior behavior of both, if the developer had listened. > > One other thing, I has some trouble getting to sleep last night and > decided to venture into src/sys/vm, the comments are VERY helpful. The > kind of documentation going on here will really help people get into > systems programming, it is MUCH appreciated. > If the code wasn't being substantially modified without review and agreement, I would agree. Function is more important than form, and function is being lost. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:51:44 1999 Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26036 for ; Tue, 16 Feb 1999 11:51:37 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id OAA11455; Tue, 16 Feb 1999 14:20:46 -0500 (EST) Date: Tue, 16 Feb 1999 14:20:45 -0500 (EST) From: perlsta To: Matthew Dillon cc: "John S. Dyson" , freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902161808.KAA37094@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Matthew Dillon wrote: > :John S. Dyson said: > :> Matthew Dillon said: > :> > > :> > The ORIGINAL VM CODE. Do I need to repeat that? The *ORIGINAL* VM CODE > :> > does not have one single line of source to prevent excessive queueing > :> > of I/O for pageout ops. > :> > > :> You are wrong. Please look at the code. I will point the code out to you > :> if you want, but I suspect that you don't want to know. > :> > :Please refer to the message that I sent to you on 10 Jan 99 for some more > :information in that arena. Apparently you didn't listen -- and what I > :said describes essentially what the nastier (but correctly working) > :swap pager does. > : > :I even explained to you in terms of "clogging" the I/O subsystem and blindly > :freeing pages. That is a *very* real problem, and the old swap pager largely > :stopped that from happening. Maybe this isn't the gretest time to jump in with a question, but i'm interested in the working of the former and current systems. I've noticed that the 'old' swapper or system seemed to leave a LOT of swap still used en it wasn't trully needed. The new system seems to reclaim these regeons as soon as they are swapped in. I've noticed the new swapper is a bit more 'peppy' but i'm concerned that it is dooing what John says. What's the deal here? Matt, even though your swapper lists pages as 'free' does it actually keep them around for reuse? What happens when a page is READ faulted in, is the backing swap kept allocated to save on IO later? One other thing, I has some trouble getting to sleep last night and decided to venture into src/sys/vm, the comments are VERY helpful. The kind of documentation going on here will really help people get into systems programming, it is MUCH appreciated. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 11:51:51 1999 Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26051 for ; Tue, 16 Feb 1999 11:51:45 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id OAA23318; Tue, 16 Feb 1999 14:07:32 -0500 (EST) Date: Tue, 16 Feb 1999 14:07:30 -0500 (EST) From: perlsta To: Matthew Dillon cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902161823.KAA37290@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Matthew Dillon wrote: > :> > This sounds sort of lame, but have you any spare DMA processors to do your > :> > dirty work for you? > :> > :> I'm DMA'ing everything that I can practically DMA, but I believe my problem > :> is running out of bandwidth, not CPU at this point. > : > :I meant DMA'ing zero's into pages, but if you don't think that it's CPU > :then this may not help. > > If his problem is memory bandwidth, DMA won't help. Yes, this is what i said, 'it may not help' > If this is a turnkey application then there shouldn't be a page zeroing > problem at all unless the application requires programs to be exec'd > all over the place ( like a couple of times a second or worse ). If > the application does not require a lot of program execing, then there > are plenty of ways to mitigate the zeroing - in fact, the standard > malloc()/free() already does it within the life of a process. This is why i suggested daemonizing the processes into a client/server model instead of fork/exec. Needless to say this would be a very interesting project. :) I love evil constraints. -Alfred > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 12: 1:18 1999 Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [209.49.144.254]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA26914 for ; Tue, 16 Feb 1999 12:01:12 -0800 (PST) (envelope-from jamie@itribe.net) Message-Id: <199902161902.OAA29475@gatekeeper.itribe.net> Received: forwarded by SMTP 1.5.2. Received: from localhost (jamie@localhost) by marsellus.itribe.net (8.8.5/8.8.6) with SMTP id OAA08295; Tue, 16 Feb 1999 14:01:43 -0500 (EST) Date: Tue, 16 Feb 1999 14:01:43 -0500 (EST) From: Jamie Bowden To: John Polstra cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <199902152346.PAA52073@vashon.polstra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 15 Feb 1999, John Polstra wrote: > In article <36C61A00.76960BF1@softweyr.com>, > Wes Peters wrote: > > > > Actually, given the capabilities of Perforce, most of those would > > be unneeded. They already have a web interface, and the Perforce > > server supports read-only users and distributed, read-only depots, > > which could probably replace CVSup and CTM. > > It's much slower than CVSup. Aren't you slightly biased? ;) Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 12: 5: 5 1999 Received: from cerebus.nectar.com (nectar-gw.nectar.com [204.0.249.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA27303 for ; Tue, 16 Feb 1999 12:05:00 -0800 (PST) (envelope-from nectar@nectar.com) Received: (from smap@localhost) by cerebus.nectar.com (8.9.1/8.9.1) id OAA16877; Tue, 16 Feb 1999 14:04:57 -0600 (CST) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com(10.0.0.101) by cerebus.nectar.com via smap (V2.1) id xma016875; Tue, 16 Feb 99 14:04:50 -0600 Received: from spawn.nectar.com (localhost [127.0.0.1]) by spawn.nectar.com (8.9.2/8.9.1) with ESMTP id OAA73745; Tue, 16 Feb 1999 14:04:49 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Message-Id: <199902162004.OAA73745@spawn.nectar.com> X-Mailer: exmh version 2.0.2 2/24/98 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-pgp262.txt From: Jacques Vidrine In-reply-to: <199902161900.LAA77291@whistle.com> References: <199902161900.LAA77291@whistle.com> Subject: Re: Oskit and 3.0? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Doug Ambrisko cc: julian@whistle.com (Julian Elischer), freebsd-hackers@FreeBSD.ORG Date: Tue, 16 Feb 1999 14:04:49 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a couple of diskless workstations here that I have been using a BOOTP kernel from floppy to get going, since the existing netboot doesn't support the xl driver. If this port works for me, I'll commit it and maintain it (pending a little feedback from the others on this thread who have said they'll test it). Thanks, Doug! Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org On 16 February 1999 at 11:00, Doug Ambrisko wrote: > Julian Elischer writes: > | we netboot elf kernels and aout kernels here.. > | check with doug ambrisko (ambrisko@whistle.com) for his netbooting stuff. > > It would be nice if some commiter would commit pr: > [1999/01/13] ports/9480 ports ELF kernel netboot > > I know one person is using is using it besides me. Note that since then we > have found 2 bugs in it. One is that in my patches I forgot and > init_serial in main and used option 131 for boot how to which was used > for swap options. If someone lets me know if they are going to commit > it then I will send them the patches. > > It is better then nothing and they support more cards then FreeBSD netboot. > > That OSKit looks interesting. > > BTW here is another data point for bootp/tftp kernel booting, iMac and > other open firmware Mac's boot via bootp/tftp. > > Doug A. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:12:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 6FC0110EB6 for ; Tue, 16 Feb 1999 13:12:08 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40356>; Wed, 17 Feb 1999 08:01:11 +1100 Date: Wed, 17 Feb 1999 08:12:01 +1100 From: Peter Jeremy Subject: Re: vm_page_zero_fill To: hackers@FreeBSD.ORG Message-Id: <99Feb17.080111est.40356@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day wrote: > all code I've written expects >malloc(), new, etc to have garbage in them, not be zeroed) As it should, because malloc() does not guarantee the contents of the returned memory :-). By disabling vm_page_zero_fill, you are also making BSS uninitialised. The C standard explicitly states that all uninitialised non-automatic variables will contain zero/NULL. Much C code relies on this - including library code that you may be explicitly or implicitly using. "John S. Dyson" wrote: > The kernel could also set the vm behavior to trap with a special >fault if a process reads a memory location without it being intialized >by either a write, a pagein from disk or inheritance from a parent >process. This is something that would be wonderful for general debugging. Unfortunately, I can't see how this could be made to work with anything better than page-size granularity (without making the performance abyssmal). Consider the code: static int foo[2]; int x, y; foo[0] = 10; x = foo[1]; y = foo[0]; How can I get the reference to foo[1] to trap, without the later reference to foo[0] trapping? Page-boundary alignment of foo and/or use of the i386 hardware breakpoint registers isn't allowed because it won't generalise. [The assignment to foo[0] is allowed to trap since this is probably where the physical page is allocated]. perlsta wrote: >Last suggestion, start compiling things with -Wall, find uninitialized >variable references, -Wall will only detect uninitialised automatic variables. Finding non-automatic variables that are read before being explicitly assigned is far more difficult (because it requires flow analysis of the entire program, not just a single function). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:21:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 629C710E8A; Tue, 16 Feb 1999 13:21:21 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id VAA59483; Tue, 16 Feb 1999 21:20:50 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 16 Feb 1999 21:20:49 +0000 (GMT) From: Doug Rabson To: Eivind Eklund Cc: hackers@freebsd.org Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <19990216170310.C60651@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Eivind Eklund wrote: > Anybody know of any way of getting gdb to step from the start of the > program? > > I have an executable with absolutely no symbol data (symbol data is > absolutely non-available) which I *have* to get to step through, if > necessary by re-implementing gdb. > > Eivind. I have had pretty good luck debugging things right from the first line of _rtld(). The trick is to run the program first and stop it (or let it fault if that is what is happening). Then you can set a breakpoint anywhere (before main, inside rtld or whatever) and it *should* hit the breakpoint the next time you run it. If it faults very early, gdb might not load rtld's symbol table but that can be solved with some careful use of add-symbol-file (it doesn't sound like you care about rtld though...) -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:21:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by hub.freebsd.org (Postfix) with ESMTP id A349610F9C for ; Tue, 16 Feb 1999 13:21:37 -0800 (PST) (envelope-from amarks@sarnoff.com) Received: from sarnoff.com ([130.33.14.232]) by postoffice.sarnoff.com (Netscape Messaging Server 3.5) with ESMTP id AAA32AA for ; Tue, 16 Feb 1999 16:21:36 -0500 Message-ID: <36C9E1A8.40F6780B@sarnoff.com> Date: Tue, 16 Feb 1999 16:22:48 -0500 From: "AARON MARKS" Reply-To: amarks@sarnoff.com Organization: Sarnoff Corporation X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Memory-Based VFS Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm implementing a memory-based VFS on 3.0-19981123. I have almost all of the VOP_* functions implemented but I ran into a slight problem with file copies. If I copy a file from and to a dir mounted on my fs, the kernel calls mmap to map the data in (I guess it would call vop_read if the data was too large). My problem is that the kernel never calls my vop_mmap (not even sure if it's supposed to) so I never get the opportunity to copy the data from my fs to kernel space so the data in the io vector pased to me at vop_write is invalid. Any ideas? Thanks, -A. -- Aaron J. Marks Communications and Computing Systems Lab Assoc. Member Tech Staff Advanced Networks and Computation Group amarks@sarnoff.com Sarnoff Corporation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:22:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from exchange-server.modacad.com (mail.modacad.com [206.253.27.98]) by hub.freebsd.org (Postfix) with ESMTP id 8B29E10FBB for ; Tue, 16 Feb 1999 13:22:37 -0800 (PST) (envelope-from matthew@netsol.net) Received: from mattl (node99.modacad.com [206.253.27.99]) by exchange-server.modacad.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1LGCKVQ8; Tue, 16 Feb 1999 13:21:34 -0800 Message-ID: <002101be59af$5637a9f0$0d2814ac@mattl.MAIN> From: "Matthew" To: "Vincent Poy" Cc: Subject: Re: 3.0 unable to receive packet by default? Date: Tue, 16 Feb 1999 13:22:00 -0000 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I did not even switch on the gateway option. This problem is very weird. The card I use is a PCI NE2000 compatible card. It's auto detected as ed1. I doublted if the kernel is tempered in some way such as the added natd, so 3.0 start to behave in a bizar way. -----Original Message----- From: Vincent Poy To: Matthew Cc: freebsd-hackers@FreeBSD.ORG Date: Tuesday, February 16, 1999 6:51 AM Subject: Re: 3.0 unable to receive packet by default? >On Mon, 15 Feb 1999, Matthew wrote: > >> Hi, guys >> I just installed the 3.0 subscriber CD, I found that you can only ping out >> but not some one ping you or do telnet to you. >> >> I found this is at the time I did a ftp out, the user name and pass phrase >> passed and then i did a "ls", then I am stuck. It turns out no communication >> can come back. How weird. Is this the default behavior of 3.0? I checked the >> firewall thing, or route, etc. dones look like the problem. >> >> I'm wondering if I need to look into the net3 socket code for any change >> someone in the team did. > >Hi Matthew, > > Just wondering, what kind of ethernet card do you have in the >machine and which driver are you using? We have a similar problem that >our Linksys DEC 21140A based 10/100 card simply doesn't work and fails the >autsense when upgraded to 3.0-RELEASE. It seems that 3.0-RELEASE will not >allow all routes to go through the ethernet with the gateway option set to >yes in /etc/rc.conf. Our machine serves as the WAN router with the eth0 >Etinc Router card interface for the PPP T1 and it seems that traceroutes >from the machines on the LAN doesn't get past the box except for a few >routes which it will work. > > >Cheers, >Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ >Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / [__ ] >GaiaNet Corporation - M & C Estate / / / / | / | __] ] >Beverly Hills, California USA 90210 / / / / / |/ / | __] ] >HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:40:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.74]) by hub.freebsd.org (Postfix) with ESMTP id 4896910E5E for ; Tue, 16 Feb 1999 13:40:17 -0800 (PST) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.1/8.9.1) with ESMTP id NAA12979; Tue, 16 Feb 1999 13:40:33 -0800 (PST) (envelope-from vince@venus.GAIANET.NET) Date: Tue, 16 Feb 1999 13:40:32 -0800 (PST) From: Vincent Poy To: Matthew Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0 unable to receive packet by default? In-Reply-To: <002101be59af$5637a9f0$0d2814ac@mattl.MAIN> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Matthew wrote: > I did not even switch on the gateway option. This problem is very weird. The > card I use is a PCI NE2000 compatible card. It's auto detected as ed1. I > doublted if the kernel is tempered in some way such as the added natd, so > 3.0 start to behave in a bizar way. Hmmm, the issue we had was that we don't even have the firewall option on but it is very picky on allowing packets on a certain destination as if 95% of all routes are rejected or something. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] > >On Mon, 15 Feb 1999, Matthew wrote: > > > >> Hi, guys > >> I just installed the 3.0 subscriber CD, I found that you can only ping > out > >> but not some one ping you or do telnet to you. > >> > >> I found this is at the time I did a ftp out, the user name and pass > phrase > >> passed and then i did a "ls", then I am stuck. It turns out no > communication > >> can come back. How weird. Is this the default behavior of 3.0? I checked > the > >> firewall thing, or route, etc. dones look like the problem. > >> > >> I'm wondering if I need to look into the net3 socket code for any change > >> someone in the team did. > > > >Hi Matthew, > > > > Just wondering, what kind of ethernet card do you have in the > >machine and which driver are you using? We have a similar problem that > >our Linksys DEC 21140A based 10/100 card simply doesn't work and fails the > >autsense when upgraded to 3.0-RELEASE. It seems that 3.0-RELEASE will not > >allow all routes to go through the ethernet with the gateway option set to > >yes in /etc/rc.conf. Our machine serves as the WAN router with the eth0 > >Etinc Router card interface for the PPP T1 and it seems that traceroutes > >from the machines on the LAN doesn't get past the box except for a few > >routes which it will work. > > > > > >Cheers, > >Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ > >Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / > [__ ] > >GaiaNet Corporation - M & C Estate / / / / | / | > __] ] > >Beverly Hills, California USA 90210 / / / / / |/ / | > __] ] > >HongKong Stars/Gravis UltraSound Mailing Lists Admin > /_/_/_/_/|___/|_|[____] > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:45: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 484C610FDE for ; Tue, 16 Feb 1999 13:45:00 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id QAA23030; Tue, 16 Feb 1999 16:44:28 -0500 (EST) (envelope-from luoqi) Date: Tue, 16 Feb 1999 16:44:28 -0500 (EST) From: Luoqi Chen Message-Id: <199902162144.QAA23030@lor.watermarkgroup.com> To: amarks@sarnoff.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Memory-Based VFS Question Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm implementing a memory-based VFS on 3.0-19981123. I have almost all > of the VOP_* functions implemented but I ran into a slight problem with > file copies. If I copy a file from and to a dir mounted on my fs, the > kernel calls mmap to map the data in (I guess it would call vop_read if > the data was too large). My problem is that the kernel never calls my > vop_mmap (not even sure if it's supposed to) so I never get the > opportunity to copy the data from my fs to kernel space so the data in > the io vector pased to me at vop_write is invalid. Any ideas? > > Thanks, > -A. > > -- > Aaron J. Marks Communications and Computing Systems Lab > Assoc. Member Tech Staff Advanced Networks and Computation Group > amarks@sarnoff.com Sarnoff Corporation > I don't think VOP_MMAP is used any where, you need to implement VOP_GETPAGES and VOP_PUTPAGES instead. The simplest way is to make them wrapper functions calling vnode_pager_generic_{get,put}pages, take a look at vm/vnode_pager.c -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:46:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (Postfix) with ESMTP id D60DD11024 for ; Tue, 16 Feb 1999 13:46:16 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id PAA15813 for ; Tue, 16 Feb 1999 15:46:14 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id PAA22780; Tue, 16 Feb 1999 15:42:06 -0600 Message-ID: <19990216154205.64792@right.PCS> Date: Tue, 16 Feb 1999 15:42:06 -0600 From: Jonathan Lemon To: hackers@freebsd.org Subject: system freeze while core dumping Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a machine running 3.0-STABLE from Jan 31, on which I'm running a fairly large process. If it coredumps, the entire system appears to lock up, and no new commands appear to executed until the coredump is complete (which, at about 117M, takes forever). The machine is a P-II, with a SCSI disk system (ahc, 2 7200 disks, 20MB/s), and 380MB mem. Any existing processes appear to run fine. iostat -o shows: tty fd0 da0 da1 pass0 cpu tin tout sps tps msps sps tps msps sps tps msps sps tps msps us ni sy in id 0 267 0 0 0.0 5673 154 6.5 0 0 0.0 0 0 0.0 0 0 1 2 98 0 81 0 0 0.0 8851 429 2.3 0 0 0.0 0 0 0.0 0 0 11 1 88 0 673 0 0 0.0 4816 86 11.6 0 0 0.0 0 0 0.0 0 0 0 0100 0 81 0 0 0.0 8118 68 14.6 0 0 0.0 0 0 0.0 0 0 19 0 81 0 540 0 0 0.0 3533 124 8.1 0 0 0.0 0 0 0.0 1 0 0 0 99 0 81 0 0 0.0 3485 121 8.3 0 0 0.0 0 0 0.0 0 0 0 0100 top shows the coredumping process seems to be perpetually waiting on "getblk". How can I prevent the dumping process from essentially freezing the system until it finishes? The problem also exists on a 3.0-CURRENT machine from November. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 13:54: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1BF8B11057 for ; Tue, 16 Feb 1999 13:54:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA39295; Tue, 16 Feb 1999 13:53:57 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 13:53:57 -0800 (PST) From: Matthew Dillon Message-Id: <199902162153.NAA39295@apollo.backplane.com> To: Jonathan Lemon Cc: hackers@FreeBSD.ORG Subject: Re: system freeze while core dumping References: <19990216154205.64792@right.PCS> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 0 540 0 0 0.0 3533 124 8.1 0 0 0.0 0 0 0.0 1 0 0 0 99 : 0 81 0 0 0.0 3485 121 8.3 0 0 0.0 0 0 0.0 0 0 0 0100 : :top shows the coredumping process seems to be perpetually waiting :on "getblk". : :How can I prevent the dumping process from essentially freezing the :system until it finishes? The problem also exists on a 3.0-CURRENT :machine from November. :-- :Jonathan This *may* have been fixed in -current with the getpbuf() fixes. I'm not entirely sure, but I seem to recall that the core dumping caused VFS clustering to occur which ( because it is essentially asynchronous ) ate all available pbuf's. The fix in -4.x limits the number of pbuf's that the clustering code can eat. Even if it is fixed, it probably still isn't optimal. The getpbuf() stuff is going to be backported to -3.x in the next month or two probably ( just to standardize the interface for the device drivers that use it ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14: 6:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id BB284110A3 for ; Tue, 16 Feb 1999 14:06:51 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id OAA12195; Tue, 16 Feb 1999 14:06:16 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id OAA10408; Tue, 16 Feb 1999 14:06:15 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id OAA14029; Tue, 16 Feb 1999 14:06:10 -0800 (PST) From: Don Lewis Message-Id: <199902162206.OAA14029@salsa.gv.tsc.tdk.com> Date: Tue, 16 Feb 1999 14:06:10 -0800 In-Reply-To: John Polstra "Re: select() can set errno to ECHILD?" (Feb 15, 4:17pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: John Polstra , nsmart@kira.team400.ie Subject: Re: select() can set errno to ECHILD? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 15, 4:17pm, John Polstra wrote: } Subject: Re: select() can set errno to ECHILD? } In article <36C85A77.EDBC00F9@kira.team400.ie>, } Niall Smart wrote: } > Erik E Rantapaa wrote: } > > } > > I have code running under 2.2.x which claims that this is happening. } > > This behaviour is not documented in the man pages. I have not been able to } > > duplicate it in a simple test program I wrote, but the log files for } > > a Merit RADIUS server say that it is happening. } > > } > > Is this at all possible? } > } > You are getting SIGCHLD while blocked in select, waitpid with WNOHANG in } > then handler returns ECHILD, the signal handler fails to restore errno. } } But when the signal handler returns, it will return to select() } again, right? And select will either continue and eventually succeed } returning some number >= 0, or it will itself set errno (perhaps to } EINTR) and return -1, right? So if the caller of select checks its } return value and only looks at errno if the return value is -1, I } can't see how anything the signal handler does could confuse it. The signal handler could be invoked and stomp errno after select() returns and before the userland code looks at errno. This isn't real likely to happen, but you'll probably get bitten by this sooner or later. } In other words, if there is a bug in the application then it must be } that the application fails to check the return value of select before } examining errno. Code that fails to check the return value of a syscall before looking at errno will tend to fail pretty frequently. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:22:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 45DA71105E for ; Tue, 16 Feb 1999 14:20:11 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id OAA08156; Tue, 16 Feb 1999 14:19:55 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id OAA00967; Tue, 16 Feb 1999 14:19:53 -0800 (PST) (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 In-Reply-To: <199902162206.OAA14029@salsa.gv.tsc.tdk.com> Date: Tue, 16 Feb 1999 14:19:53 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Don Lewis Subject: Re: select() can set errno to ECHILD? Cc: hackers@FreeBSD.ORG, nsmart@kira.team400.ie Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Don Lewis wrote: > The signal handler could be invoked and stomp errno after select() > returns and before the userland code looks at errno. This isn't > real likely to happen, but you'll probably get bitten by this sooner > or later. By Jove, you're right. Thanks! John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:29:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id D4FDA10EA2 for ; Tue, 16 Feb 1999 14:29:40 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA01173; Tue, 16 Feb 1999 14:26:14 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA24963; Tue, 16 Feb 1999 14:26:14 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id PAA04841; Tue, 16 Feb 1999 15:26:04 -0700 Message-ID: <36C9F07C.7F2C9367@softweyr.com> Date: Tue, 16 Feb 1999 15:26:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Donn Miller Cc: hackers@FreeBSD.ORG Subject: Re: Systems programming for FreeBSD References: <36C8C170.4AA85CA@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Donn Miller wrote: > > I'm looking for some info on how to use functions like inb() and outb() > to do systems-level programming on FreeBSD. > > 1.) I need to know the FreeBSD equiv. of the Linux function ioperm(). > I would think you just use open() on /dev/pio or /dev/io with the > appropriate permissions. "man io" tells us: IO(4) FreeBSD Kernel Interfaces Manual (i386 Architecture) IO(4) NAME io - I/O privilege file DESCRIPTION The special file /dev/io is a controlled security hole that allows a pro- cess to gain I/O privileges (which are normally reserved for kernel- internal code). Any process that holds a file descriptor on /dev/io open will get its IOPL bits in the flag register set, thus allowing it to per- form direct I/O operations. This can be useful in order to write user- land programs that handle some hardware directly. The entire access control is handled by the file access permissions of /dev/io, so care should be taken in granting rights for this device. Note that even read/only access will grant the full I/O privileges. FILES /dev/io SEE ALSO mem(4) HISTORY The io file appeared in FreeBSD 1.0. > > 2.) what include files do I need to use to use inb() and outb()? In > Linux it's machine/cpufunc.h > Is using ports my only/best option for doing systems-level programming > for writing drivers for video cards, or should I use assembly? Ports are your only choice when doing port-mapped I/O. Using assembler will make your driver run faster, IF you are a good assembly programmer. If not, you'll probably be better off writing C. If you want to write a driver for a video card, start with one of the existing drivers for a similar device. > There's a Linux howto on systems programming, maybe FreeBSD is similar > in that respect. so I can just use the Linux howto for FreeBSD. What > are ports anyway, is it like you're writing to a special part of memory? No, I/O ports are a separate address space from memory. I strongly suggest a good book on x86 architecture, but don't have any idea what one might be. Mine is ages old and probably isn't published anymore. Suggestions, hackers? -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:40:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 7F93A1103F for ; Tue, 16 Feb 1999 14:39:52 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA21425; Tue, 16 Feb 1999 15:39:44 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd021354; Tue Feb 16 15:39:32 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA07971; Tue, 16 Feb 1999 15:39:17 -0700 (MST) From: Terry Lambert Message-Id: <199902162239.PAA07971@usr08.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Tue, 16 Feb 1999 22:39:17 +0000 (GMT) Cc: toasty@home.dragondata.com, hackers@FreeBSD.ORG In-Reply-To: <199902160153.UAA24408@y.dyson.net> from "John S. Dyson" at Feb 15, 99 08:53:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Userland won't like non-zeroed memory regions. Some of the kernel might > balk at it also. I can understand the kernel assumptions... but user space???? > Alot of code might do something like: > > int foo; > > main() > { > foo += 1; > } > > and expect foo to be equal to 1 instead of being indeterminant. If you turn > vm_page_zero_fill off entirely, then this will be a problem. The kernel code > does things like this also, unfortunately. BSS is supposed to be zeroed on startup. I can see you *maybe* getting the pages for it out of /dev/zero, but /dev/zero would *have* to be special cased, for semantic, not security, reasons. If it's not using /dev/zero, then it should be done in crt0.o, not rely on the kernel to do the job. For the user code assumptions in other places, well, the FreeBSD crt0.o uses sufficiently more stack than the Linux equivalent that Linux programs can use stack variables as if they are zeroed (e.g. the standard Linux programmer trick of an uninitializaed sockaddr_in causes problems on FreeBSD). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:47:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0DAFF10EA0 for ; Tue, 16 Feb 1999 14:47:09 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA23404; Tue, 16 Feb 1999 15:58:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd023268; Tue Feb 16 15:58:21 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA08400; Tue, 16 Feb 1999 15:46:46 -0700 (MST) From: Terry Lambert Message-Id: <199902162246.PAA08400@usr08.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Tue, 16 Feb 1999 22:46:46 +0000 (GMT) Cc: toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902160441.XAA00469@y.dyson.net> from "John S. Dyson" at Feb 15, 99 11:41:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > > able to take memory from the to-be-zero'ed list would be better, although > > that may be more work than I'm looking for.... > > That *might* be reasonable. A special sbrk or somesuch. That sbrk > would make a non-prezeroed map entry. vm_fault would just avoid > doing the zero. Expecting sbrk'ed pages to be zero filled is just *wrong*. Sorry, but there is a *reason* that there are seperate malloc(3) and calloc(3) routines. The former is seperate from the latter because uncleared pages are supposed to occur faster, and because there was an expectation that the malloc(3) could return space already allocated to the process. Indeed, the ANSI C specification practically *prohibits* breaking memory back to the system, since it *requires* that a free'd region of a given size be re-malloc'able without a check of the malloc return code (though it doesn't guarantee contents). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:52:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 2F6DF10ECA for ; Tue, 16 Feb 1999 14:52:03 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA01400; Tue, 16 Feb 1999 14:49:57 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA25644; Tue, 16 Feb 1999 14:49:56 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id PAA07794; Tue, 16 Feb 1999 15:49:51 -0700 Message-ID: <36C9F60F.7AE40274@softweyr.com> Date: Tue, 16 Feb 1999 15:49:51 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra Cc: Jamie Bowden , hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > Jamie Bowden wrote: > > On Mon, 15 Feb 1999, John Polstra wrote: > > > >> It's much slower than CVSup. > > > > Aren't you slightly biased? ;) > > Of course I'm biased, but that doesn't change the validity of my > statement. Doing a single block transfer of a bunch of files (or changes) is always faster than starting numerous different connections to transfer individual files. CVSup has been very carefully optimized to use the network resources in an efficient manner, something that more general-purpose programs can't (or at least won't) do. John's comments about connectivity are quite accurate, too. Perforce works about like CVS "pserver" mode w.r.t. connectivity, it's only needed when you're doing a "p4" command. If you don't have connectivity, you have no "p4" commands. In a commercial environment, where the "net" is always up, this is not much of a limitation. To a remote FreeBSD hacker, who maintains a local CVS store updated with CVSup, it may be somewhat untenable. As I said, Perforce is an excellent product with much to recommend it, but probably not the best solution for FreeBSD. What we have works quite well, because it was developed by highly motivated developers to pretty much do exactly what FreeBSD needs. If only *every* development project were this lucky. Especially Linux... ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 14:57:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from csmd2.cs.uni-magdeburg.de (prinz-atm.CS.Uni-Magdeburg.De [141.44.30.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A1EE11010 for ; Tue, 16 Feb 1999 14:57:06 -0800 (PST) (envelope-from jesse@mail.CS.Uni-Magdeburg.De) Received: from knecht.cs.uni-magdeburg.de (knecht [141.44.21.3]) by csmd2.cs.uni-magdeburg.de (8.9.1a/8.9.1) with ESMTP id XAA10819 for ; Tue, 16 Feb 1999 23:57:04 +0100 (MET) Received: (from jesse@localhost) by knecht.cs.uni-magdeburg.de (8.8.8+Sun/8.8.8) id XAA09969 for hackers@FreeBSD.ORG; Tue, 16 Feb 1999 23:57:00 +0100 (MET) Message-ID: <19990216235700.A9965@cs.uni-magdeburg.de> Date: Tue, 16 Feb 1999 23:57:00 +0100 From: Roland Jesse To: FreeBSD Hackers Mail List Subject: Re: Makefile: >1 program without a single target each. References: <199902161717.RAA01752@excalibur.oceanis.net> <22059.919187358@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <22059.919187358@zippy.cdrom.com>; from Jordan K. Hubbard on Tue, Feb 16, 1999 at 09:49:18AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jordan K. Hubbard wrote: > In BSD make, this is handled by SUBDIR=... and Just in case, I want to build the whole thing not only on my FreeBSD machine but on some SGIs, too: What kind of make is BSD make exactly? It does not seem to be pmake, it is for sure not GNU make. Is there an archiv if its source code available (besides /usr/src/usr.bin/make/)? Thanks, Roland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 15:15:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 7E19E10F64 for ; Tue, 16 Feb 1999 15:15:25 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA10939; Tue, 16 Feb 1999 16:15:14 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd010870; Tue Feb 16 16:15:10 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09820; Tue, 16 Feb 1999 16:14:59 -0700 (MST) From: Terry Lambert Message-Id: <199902162314.QAA09820@usr08.primenet.com> Subject: Re: symbol export question To: kbyanc@freedomnet.com (Kelly Yancey) Date: Tue, 16 Feb 1999 23:14:59 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com> from "Kelly Yancey" at Feb 16, 99 02:32:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So the question is: what is the proper way to export symbols from an > executable so that dynamicly loaded libraries can access just those symbols > (not all symbols in the executable)? Presumably the same holds true for > building libraries which don't export all of their symbols. % man ld [ ... ] -export-dynamic When creating an ELF file, add all symbols to the dynamic symbol table. Normally, the dynamic symbol table contains only symbols which are used by a dy- namic object. This option is needed for some uses of dlopen. [ ... ] You might also want to look at the info file for gld, since the man page is seriously out of date, and there don't appear to be FreeBSD people who think that updating such things is cool (there needs to be a technical writer on the core team, and some university English department need to become sucked into^W^Winvolved with FreeBSD). See: --retain-symbols-file FILE Keep only symbols listed in FILE And: -Map FILE Write a map file Or: -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table -F SHLIB, --filter SHLIB Filter for shared object symbol table > Oh, and on a related note: the man page for dlopen() indicates that dlopen > invokes _init() and dlclose() invokes _fini() in the dynamic library. My own > testing indicates that while this is true, the standard C library implements > _init() which calls main() (presumably all programs are actually started my > calling _init() which the standard library handles and in turn calls the > familiar main() ...for C at least). I suppose the standard library also > intercepts _fini() and performs cleanup too. I found that I can get around > the preprocessing by passing -nostdlib to gcc and implementing _init() and > _fini() in the libraries myself. Is this advisable? What kind of cleanup > could the standard library possibly be doing in _fini() and is there any > other way for me to hook into to _fini() operation? This is not correct behaviour. What's supposed to happen is that all symbols in the .init and .fini *ELF sections* are supposed to be call on startup and shutdown. The C++ compiler *happens* to aggregate them into these particular functions in each of these sections, but it's not a hard requirement. As it is, you would not be able to use ld -r on an image linked shared to a library containing constructors. This is actually a deviation from the ELF specification (the IABI) and has been discussed in detail before, when someone tried to rename the functions to begin with dots "like the spec says" (sic). The code works because the _init/_fini are the first things in the respective .init/.fini sections. But the direct calls are actually *wrong*. > I'de like to be able to dynamically add (or occasionally) remove the > libraries from my process's address space and I need a way for the library > to know when it is getting unloaded so that it can restore and vectors in > the main executable it hooked. I suppose I could implement my own function > in each library which the process calls before dlclose()ing it, but it just > seems so nice to be able to use the function already provided for that > purpose. You are supposed to attribute the object/region so that it is put in the correct section. There is an undocumented linker option that can be used on a per object file basis (see the ld source code for details on usage; the one Makefile I built that depends on this is at home). There is also support for using "#pragma section(some_name)", I believe, but it may only exist in the Cygnus version of the compiler, or even only in the WIN32 specific version of the Cygnus compiler, since it's used in that environment to enable compilation of VXD's (Windows drivers). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 15:16:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id C01B710F23 for ; Tue, 16 Feb 1999 15:16:46 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA08825; Tue, 16 Feb 1999 16:16:39 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd008746; Tue Feb 16 16:16:37 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09873; Tue, 16 Feb 1999 16:16:19 -0700 (MST) From: Terry Lambert Message-Id: <199902162316.QAA09873@usr08.primenet.com> Subject: Re: Memory-Based VFS Question To: amarks@sarnoff.com Date: Tue, 16 Feb 1999 23:16:04 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <36C9E1A8.40F6780B@sarnoff.com> from "AARON MARKS" at Feb 16, 99 04:22:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm implementing a memory-based VFS on 3.0-19981123. I have almost all > of the VOP_* functions implemented but I ran into a slight problem with > file copies. If I copy a file from and to a dir mounted on my fs, the > kernel calls mmap to map the data in (I guess it would call vop_read if > the data was too large). My problem is that the kernel never calls my > vop_mmap (not even sure if it's supposed to) so I never get the > opportunity to copy the data from my fs to kernel space so the data in > the io vector pased to me at vop_write is invalid. Any ideas? It will use VOP_GETPAGES/VOP_PUTPAGES. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 16:24: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id E3AE710EC6 for ; Tue, 16 Feb 1999 16:23:56 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA12845; Tue, 16 Feb 1999 16:15:01 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdz12842; Wed Feb 17 00:14:58 1999 Date: Tue, 16 Feb 1999 16:14:54 -0800 (PST) From: Julian Elischer To: "John S. Dyson" Cc: perlsta , dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: <199902161930.OAA00391@y.dyson.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, John S. Dyson wrote: > perlsta said: > > > > I've noticed that the 'old' swapper or system seemed to leave a LOT of > > swap still used en it wasn't trully needed. The new system seems to > > reclaim these regeons as soon as they are swapped in. I've noticed the > > new swapper is a bit more 'peppy' but i'm concerned that it is dooing what > > John says. > > > Matt's code has a better allocator, and for that I applaud the code. > Regressing behavior, when information is available and offered is not > forward progress, but a loss of technology. You could have had the > superior behavior of both, if the developer had listened. > > > > > One other thing, I has some trouble getting to sleep last night and > > decided to venture into src/sys/vm, the comments are VERY helpful. The > > kind of documentation going on here will really help people get into > > systems programming, it is MUCH appreciated. > > > If the code wasn't being substantially modified without review and > agreement, I would agree. Function is more important than form, > and function is being lost. Matt has agreed to go back over the changes and retrofit any changes that are identified as being problems by you or alan or david. He is willing to do the work if he can get a clear description of what he needs to fix. He's also agreed to run all changes past either you or alan. julian > > -- > John | Never try to teach a pig to sing, > dyson@iquest.net | it makes one look stupid > jdyson@nc.com | and it irritates the pig. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 16:43:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 930C810E5F; Tue, 16 Feb 1999 16:43:16 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA13603; Tue, 16 Feb 1999 16:37:46 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdw13596; Wed Feb 17 00:37:35 1999 Date: Tue, 16 Feb 1999 16:37:28 -0800 (PST) From: Julian Elischer To: Eivind Eklund Cc: hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <19990216170310.C60651@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not sure but can't you put a breakpoint at a physical address? On Tue, 16 Feb 1999, Eivind Eklund wrote: > Anybody know of any way of getting gdb to step from the start of the > program? > > I have an executable with absolutely no symbol data (symbol data is > absolutely non-available) which I *have* to get to step through, if > necessary by re-implementing gdb. > > Eivind. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 16:50:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5AB1611020 for ; Tue, 16 Feb 1999 16:50:51 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id QAA08801; Tue, 16 Feb 1999 16:50:50 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id QAA96997; Tue, 16 Feb 1999 16:50:50 -0800 (PST) (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 In-Reply-To: <36C9F60F.7AE40274@softweyr.com> Date: Tue, 16 Feb 1999 16:50:50 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Wes Peters Subject: Re: FreeBSD mention in LWN interview with A.C. Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > Doing a single block transfer of a bunch of files (or changes) > is always faster than starting numerous different connections to > transfer individual files. CVSup has been very carefully optimized > to use the network resources in an efficient manner, something that > more general-purpose programs can't (or at least won't) do. In case anybody is interested, last week I made a brief write-up describing how CVSup manages to go fast. Go to here: http://www.polstra.com/projects/freeware/CVSup/ and then follow the link "How does CVSup go so fast?". There is also some related stuff in the "CVSup in Action" page. I would welcome editorial suggestions. I am probably too immersed in the project to be able to recognize whether the description is understandable or not. :-) John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 17:27:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 905001136A for ; Tue, 16 Feb 1999 17:26:59 -0800 (PST) (envelope-from peter.jeremy@AUSS2.ALCATEL.COM.AU) Received: by border.alcanet.com.au id <40408>; Wed, 17 Feb 1999 12:16:02 +1100 Date: Wed, 17 Feb 1999 12:26:51 +1100 From: Peter Jeremy Subject: Semaphore handling To: hackers@FreeBSD.ORG Message-Id: <99Feb17.121602est.40408@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG About Friday there was a thread covering semop(2) behaviour. As I mentioned, I'm looking through the current code (and man pages) [at a slower rate than I hoped] and trying to make them align to The Open Group's `Single Unix Specification, version 2' (http://www.opengroup.org/onlinepubs/7908799/). In the process, I've found a few anomolies which I'd like some input on before I implement them: 1) What are the rules regarding the use of gcc extensions in the kernel? (This doesn't appear to be mentioned in style(9)). Background: semop() currently uses the macro MAX_SOPS to specify the maximum number of sem_op's it can process at one time. IMHO, this is wrong, it should be using SEMOPM (via seminfo.semopm). The problem is that this value is needed to allocate a local buffer into which to copy the user's sem_ops. Currently this is an auto variable: struct sembuf sops[MAX_SOPS]; The simplest fix is to change this to: struct sembuf sops[seminfo.semopm]; but this is a gcc extension. The alternative is malloc() - either allocate/free the local buffer on each semop() call [which is slow] or allocate a single buffer and reuse it [which means more work for whoever puts fine-grained SMP locks into the semaphore handling]. 2) TOG is unclear as to the type for sem_num in struct sembuf. In semop(2) it's defined as `short', in sys/sem.h it's defined as `unsigned short'. We (and DEC) currently use ushort (Linux and Solaris use short). Which is the preferable type? 3) Neither FreeBSD nor TOG not clearly define semadj behaviour. The wording is (roughly) sem_op is subtracted from semadj in semop() and semadj is added to semval in exit(). There does not appear to be a clear definition for behaviour when a process exits for the following cases: a) semadj + semval > SEMVMX (maximum semaphore value). SEMAEM + SEMVMX < MAX_USHORT, so this may not be a problem (although I could write code that broke this). I can't see any realistic scenario where this would be a problem. b) semadj > semval TOG clearly defined semval as `unsigned short' [which breaks Terry's code], so semval can't go negative (which this implies). This could happen in the situation where a varying number of consumer processes exist and one dies, adjusting semval down. Since the problem occurs during exit() processing, it's not a simple problem of returning an error and letting the calling process resolve the problem. Comments please. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 17:51:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 4BB1F110A0 for ; Tue, 16 Feb 1999 17:51:19 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 25078 invoked from network); 17 Feb 1999 01:50:43 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 01:50:43 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id UAA00753; Tue, 16 Feb 1999 20:50:42 -0500 (EST) Message-Id: <199902170150.UAA00753@y.dyson.net> Subject: Re: inode / exec_map interlock ? (follow up) In-Reply-To: from Julian Elischer at "Feb 16, 99 04:14:54 pm" To: julian@whistle.com (Julian Elischer) Date: Tue, 16 Feb 1999 20:50:42 -0500 (EST) Cc: dyson@iquest.net, bright@cygnus.rush.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer said: > > > On Tue, 16 Feb 1999, John S. Dyson wrote: > > > perlsta said: > > > > > > I've noticed that the 'old' swapper or system seemed to leave a LOT of > > > swap still used en it wasn't trully needed. The new system seems to > > > reclaim these regeons as soon as they are swapped in. I've noticed the > > > new swapper is a bit more 'peppy' but i'm concerned that it is dooing what > > > John says. > > > > > Matt's code has a better allocator, and for that I applaud the code. > > Regressing behavior, when information is available and offered is not > > forward progress, but a loss of technology. You could have had the > > superior behavior of both, if the developer had listened. > > > > > > > > One other thing, I has some trouble getting to sleep last night and > > > decided to venture into src/sys/vm, the comments are VERY helpful. The > > > kind of documentation going on here will really help people get into > > > systems programming, it is MUCH appreciated. > > > > > If the code wasn't being substantially modified without review and > > agreement, I would agree. Function is more important than form, > > and function is being lost. > > Matt has agreed to go back over the changes and retrofit any changes that > are identified as being problems by you or alan or david. > He is willing to do the work if he can get a clear description of what he > needs to fix. He's also agreed to run all changes past either you or alan. > If we can get ALC to agree, I prefer him to be the first line (but I am willing to fill-in and support DG and ALC when needed.) Up until now, I can start with the existing new code, and I can help fix the missing abilities. After this, we need to move forward with a more conservative policy of defaulting to no functional changes (thereby minimizing the risk of regression.) It is likely that Matt will sometimes be able to *add* real capabilities to the code, and that is really cool. If this is agreeable, then I'll be *very* happy, and willing to participate in the background, where I feel most comfortable. FreeBSD is a legacy and needs to be treated carefully. There are things that I would have done differently than I originally did -- none of us has all of the answers, and a proper structure can make the total effectiveness more than any one member of the team. I remember working with DG, and he and I TOGETHER were much more effective than any one of us alone. Very little design happened without the other being consulted. This was very very effective, and it seems that other similar relationships should be cultivated. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 17:53: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 588EA110A0 for ; Tue, 16 Feb 1999 17:52:32 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 26855 invoked from network); 17 Feb 1999 01:52:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 01:52:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id UAA00758; Tue, 16 Feb 1999 20:52:28 -0500 (EST) Message-Id: <199902170152.UAA00758@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902162246.PAA08400@usr08.primenet.com> from Terry Lambert at "Feb 16, 99 10:46:46 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 16 Feb 1999 20:52:28 -0500 (EST) Cc: dyson@iquest.net, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > > > able to take memory from the to-be-zero'ed list would be better, although > > > that may be more work than I'm looking for.... > > > > That *might* be reasonable. A special sbrk or somesuch. That sbrk > > would make a non-prezeroed map entry. vm_fault would just avoid > > doing the zero. > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > Actually, you have to support that on most practical architectures. > > Sorry, but there is a *reason* that there are seperate malloc(3) > and calloc(3) routines. The former is seperate from the latter > because uncleared pages are supposed to occur faster, and because > there was an expectation that the malloc(3) could return space > already allocated to the process. Indeed, the ANSI C specification > practically *prohibits* breaking memory back to the system, since > it *requires* that a free'd region of a given size be re-malloc'able > without a check of the malloc return code (though it doesn't > guarantee contents). > > malloc and calloc are different. Memory is often recycled in the address space when using malloc. sbrk is a security violation if the pages aren't prezeroed (or defined to be something other than data in other processes or freed data from the kernel :-)). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 18:18:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id C2C2211132 for ; Tue, 16 Feb 1999 18:18:39 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA26146; Tue, 16 Feb 1999 19:18:39 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd026081; Tue Feb 16 19:18:23 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA16616; Tue, 16 Feb 1999 19:18:22 -0700 (MST) From: Terry Lambert Message-Id: <199902170218.TAA16616@usr08.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Wed, 17 Feb 1999 02:18:22 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902170152.UAA00758@y.dyson.net> from "John S. Dyson" at Feb 16, 99 08:52:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > > Actually, you have to support that on most practical architectures. [ ... ] > malloc and calloc are different. Memory is often recycled in the > address space when using malloc. sbrk is a security violation if > the pages aren't prezeroed (or defined to be something other than > data in other processes or freed data from the kernel :-)). Well, the intended application doesn't care about security, so it should be possible to turn it off. 8-). The thing that appalled me was what you said about BSS being zero'ed in the kernel space using zeroed pages instead of as a result of an explicit zeroing by the execution class loader. On second thought, though, are the BSS pages zeroed because they are backed by zero-fill pages, rather than grabbed in user space via sbrk? That's less apalling. You could conditionalize that code. I think the compile option he wants to add is "VM_FG_ZERO_PAGES" or something similar, that indicates the subsystem effected and the effect, and then "VM_DIRTY_PAGES_OK". In other words, I'd seperate turning off the background zeroing and the default-mandatory nature of pages zeroed for security rather than functional purposes. Another place that would have to be conditionalized, besides the /dev/zero and BSS issues, would be backing store for file pages allocated on a file extend. I know a number of programs that rely on the POSIX sideways promise that "holes contain zeros" (it's OK to break security, but not semantics). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 18:24:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 346B6113E5 for ; Tue, 16 Feb 1999 18:24:06 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA28801; Tue, 16 Feb 1999 19:23:56 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd028776; Tue Feb 16 19:23:52 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA16780; Tue, 16 Feb 1999 19:23:51 -0700 (MST) From: Terry Lambert Message-Id: <199902170223.TAA16780@usr08.primenet.com> Subject: Re: Memory-Based VFS Question To: luoqi@watermarkgroup.com (Luoqi Chen) Date: Wed, 17 Feb 1999 02:23:51 +0000 (GMT) Cc: amarks@sarnoff.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902162144.QAA23030@lor.watermarkgroup.com> from "Luoqi Chen" at Feb 16, 99 04:44:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't think VOP_MMAP is used any where, you need to implement > VOP_GETPAGES and VOP_PUTPAGES instead. The simplest way is to make them > wrapper functions calling vnode_pager_generic_{get,put}pages, take a look > at vm/vnode_pager.c You can't do that for something backed by pages not from a vnode. If the MFS was on a memory device (like the standard MFS), you could do this, but not with an MFS that can auto-resize-with-high-watermark. He will have to implement a non-default VOP_{GET|PUT}PAGES(). This is what is so insidious about having a default vfsops; if the generic ones would work, it'd be working already, via inheritance, but the fact that inheritance is taking place at all is not clear based on the new semantics failing-to-default instead of them failing-to-notimp. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 18:30:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 019AE1114C; Tue, 16 Feb 1999 18:27:13 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA29994; Tue, 16 Feb 1999 19:27:13 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd029938; Tue Feb 16 19:27:06 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA16880; Tue, 16 Feb 1999 19:27:05 -0700 (MST) From: Terry Lambert Message-Id: <199902170227.TAA16880@usr08.primenet.com> Subject: Re: gdb sucks - and I need to get around it. help? To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Wed, 17 Feb 1999 02:27:05 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <19990216170310.C60651@bitbox.follo.net> from "Eivind Eklund" at Feb 16, 99 05:03:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Anybody know of any way of getting gdb to step from the start of the > program? > > I have an executable with absolutely no symbol data (symbol data is > absolutely non-available) which I *have* to get to step through, if > necessary by re-implementing gdb. One really snotty way to do it is to write a small program that exec's the other program, and follow it through the exec. I've used this technique to work on ld.so before. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 18:36:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id A821D11345 for ; Tue, 16 Feb 1999 18:35:24 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA02570; Tue, 16 Feb 1999 19:35:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd002474; Tue Feb 16 19:35:07 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id TAA17123; Tue, 16 Feb 1999 19:34:51 -0700 (MST) From: Terry Lambert Message-Id: <199902170234.TAA17123@usr08.primenet.com> Subject: Re: inode / exec_map interlock ? (follow up) To: bright@cygnus.rush.net (perlsta) Date: Wed, 17 Feb 1999 02:34:51 +0000 (GMT) Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "perlsta" at Feb 16, 99 02:20:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What's the deal here? Matt, even though your swapper lists pages as > 'free' does it actually keep them around for reuse? What happens when a > page is READ faulted in, is the backing swap kept allocated to save on IO > later? I don't think the swapper does this, though it would be an optimization to utilize swap for clean pages from backing store. One real problem here is the ihash cache, which should probably not exist, but has to because the vnodes for UFS are not managed by UFS. You basically lose the association with the vnode, even if the inode stays in cache. One thing I was worried about after a casual perusal of the code (I don't have a hell of a lot of perusing time, at the moment, casual or otherwise) was dirty pages after a fork that are marked copy-on-write in the circumstance that the fork is *not* followed by an exec. I thought there might be a boundary condition that the new code was overlooking (but perhaps I'm missing something; it *was* a casual perusal). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19: 0:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 8CE3510FB6; Tue, 16 Feb 1999 19:00:05 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA12685; Wed, 17 Feb 1999 13:29:57 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA10346; Wed, 17 Feb 1999 13:29:52 +1030 (CST) Message-ID: <19990217132952.Z515@lemis.com> Date: Wed, 17 Feb 1999 13:29:52 +1030 From: Greg Lehey To: Chuck Robey , Eivind Eklund Cc: hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? References: <19990216170310.C60651@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Chuck Robey on Tue, Feb 16, 1999 at 12:41:34PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 16 February 1999 at 12:41:34 -0500, Chuck Robey wrote: > On Tue, 16 Feb 1999, Eivind Eklund wrote: > >> Anybody know of any way of getting gdb to step from the start of the >> program? >> >> I have an executable with absolutely no symbol data (symbol data is >> absolutely non-available) which I *have* to get to step through, if >> necessary by re-implementing gdb. > > You can tell the absolute address of main(), right? Can't you just set > a breakpoint of the program to the address of main() directly (not > symbolically) then start the program. It should stop immediately, then > you can single step until you fall asleep, right? > > That's all if this is a C program. If it's C++, where there is stuff > active even before main(), then I'm not sure the address you'd want, but > it'd NOT be main(). I think I'd get it via objdump. It could read the > elf headers and get it. There's stuff before main in C programs as well. The entry point of all C and C++ programs is start, which is in crt0.o or crt1.o. In a.out files, it used to be directly after the header at 0x1020. I'm not sure where the start address is in an ELF file. The clue should be here somewhere, but I can't see it: $ objdump --section-headers /bin/sh /bin/sh: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .init 00000006 08048074 08048074 00000074 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 00042c50 0804807c 0804807c 0000007c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .fini 00000006 0808accc 0808accc 00042ccc 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 3 .rodata 0000706d 0808acd4 0808acd4 00042cd4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .data 00002758 08092d44 08092d44 00049d44 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .ctors 00000008 0809549c 0809549c 0004c49c 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .dtors 00000008 080954a4 080954a4 0004c4a4 2**2 CONTENTS, ALLOC, LOAD, DATA 7 .bss 00008eec 080954b0 080954b0 0004c4b0 2**4 ALLOC 8 .comment 00000fdc 00000000 00000000 0004c4b0 2**0 CONTENTS, READONLY 9 .note 00000fdc 00000fdc 00000fdc 0004d48c 2**0 CONTENTS, READONLY 10 .gnu.warning.f_prealloc 0000003a 00001fb8 00001fb8 0004e468 2**0 CONTENTS, READONLY I set a breakpoint on the base address of the text segment, but it didn't hit: $ gdb /bin/sh GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) b *0x0804807c Breakpoint 1 at 0x804807c (gdb) r Starting program: /bin/sh warning: shared library handler failed to enable breakpoint # ^C Program received signal SIGINT, Interrupt. 0x806b234 in ?? () (gdb) bt #0 0x806b234 in ?? () #1 0x804f34a in ?? () #2 0x8054399 in ?? () #3 0x80541f5 in ?? () #4 0x80535e9 in ?? () #5 0x80511fb in ?? () #6 0x805118b in ?? () #7 0x80480e9 in ?? () (gdb) The backtrace looks like it's coming from that address, so I'd guess that the address is correct, and the "failed to enable breakpoint" warning is the problem. Is this a bug or a feature? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19: 1: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 6BC5A11010; Tue, 16 Feb 1999 19:00:35 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA12692; Wed, 17 Feb 1999 13:30:32 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA10357; Wed, 17 Feb 1999 13:30:32 +1030 (CST) Message-ID: <19990217133032.A515@lemis.com> Date: Wed, 17 Feb 1999 13:30:32 +1030 From: Greg Lehey To: Terry Lambert , Eivind Eklund Cc: hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? References: <19990216170310.C60651@bitbox.follo.net> <199902170227.TAA16880@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199902170227.TAA16880@usr08.primenet.com>; from Terry Lambert on Wed, Feb 17, 1999 at 02:27:05AM +0000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 17 February 1999 at 2:27:05 +0000, Terry Lambert wrote: >> Anybody know of any way of getting gdb to step from the start of the >> program? >> >> I have an executable with absolutely no symbol data (symbol data is >> absolutely non-available) which I *have* to get to step through, if >> necessary by re-implementing gdb. > > One really snotty way to do it is to write a small program that > exec's the other program, and follow it through the exec. I've used > this technique to work on ld.so before. Does this work on ELF executables? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19: 3:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id CE75B10EEC for ; Tue, 16 Feb 1999 19:01:34 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id UAA09741; Tue, 16 Feb 1999 20:13:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd009674; Tue Feb 16 20:13:01 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id UAA18215; Tue, 16 Feb 1999 20:01:18 -0700 (MST) From: Terry Lambert Message-Id: <199902170301.UAA18215@usr08.primenet.com> Subject: Re: Semaphore handling To: peter.jeremy@AUSS2.ALCATEL.COM.AU (Peter Jeremy) Date: Wed, 17 Feb 1999 03:01:18 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <99Feb17.121602est.40408@border.alcanet.com.au> from "Peter Jeremy" at Feb 17, 99 12:26:51 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1) What are the rules regarding the use of gcc extensions in the > kernel? (This doesn't appear to be mentioned in style(9)). > Background: semop() currently uses the macro MAX_SOPS to specify > the maximum number of sem_op's it can process at one time. IMHO, > this is wrong, it should be using SEMOPM (via seminfo.semopm). The > problem is that this value is needed to allocate a local buffer > into which to copy the user's sem_ops. Currently this is an auto > variable: > struct sembuf sops[MAX_SOPS]; > The simplest fix is to change this to: > struct sembuf sops[seminfo.semopm]; > but this is a gcc extension. This is bad. There are only two places where this is currently used. We do use linker sets, but those are more properly an "ld" extension. The linker set code can "go away" when support is added for multiple ELF section loading for binaries. More properly, the sections should be agregated, even if from seperate objects. There was an _init/.init discussion a while back, and the place to deal with this is a functional interface into the ELF image's ".init" section so that it is called when the object is instanced (in this case, the kernel being instanced by the kernel loader). The general consensus had been "make it compilable with a K & R compiler" until ANSI C was adopted a while ago. The CSRG code was pure K & R safe. Core will say "ANSI C, with prototypes". > The alternative is malloc() - either > allocate/free the local buffer on each semop() call [which is slow] > or allocate a single buffer and reuse it [which means more work for > whoever puts fine-grained SMP locks into the semaphore handling]. Fine grained SMP locks don't have to deal with POSIX semaphores, since they aren't SMP safe (use mutexes for SMP safety). The SVR4 semaphores are better implemented as mutexes, internally. My personal preference would be for realloc-type bechaviour as a result of sysctl modification, and a static pointer to the buffer, instead of an auto variable. Alternately, let it be slower, since it's a deprecated interface (John Dyson and other consumers of the interface might not like that, though). You also might want to talk to Amancio Hasty, since he was talking about implementing real semaphores and mutexes for pthreads to avoid the spinlock overhead in kaffe in the user space code. He found a couple of very interesting papers in the literature, one of which I think is probably the best implementation I have seen, and is SMP safe. > 2) TOG is unclear as to the type for sem_num in struct sembuf. In > semop(2) it's defined as `short', in sys/sem.h it's defined as > `unsigned short'. We (and DEC) currently use ushort (Linux and > Solaris use short). Which is the preferable type? [ ... ] > 3) Neither FreeBSD nor TOG not clearly define semadj behaviour. The > wording is (roughly) sem_op is subtracted from semadj in semop() > and semadj is added to semval in exit(). There does not appear to > be a clear definition for behaviour when a process exits for the > following cases: Solaris and UnixWare are definitive. This is a System V interface, and actual System V behaviour is authoritative. You may want to dig up a copy of the SVID III, if you can; it is probably better at rigorous definition than the Go Solo 2 Single UNIX Specification, since the latter is a compromise document meant to cover existing vender implementations, while the former is a documentation of System V behaviour. Note: The use of the ushort in sem.h is (potentially) intended to be a compatability bridge for a common underlying implementation; see semaphore.h on the CDROM, as well. Another possibile authority is the NIST/PCTS code, which tests POSIX Conformance, and *may* test this boundary (been a long time since I ran it). You can download it from the NIST archive (it's searchable using Altavista, if you don't know where it is). SCO has put out their packaging system. They may be willing to let out the SVID III compliance test, if someone hinted about maybe "standardizing on an ABI". If so, you will need TET to run it, and TET fails to build on FreeBSD, and is not permitted to be modified for conformance testing. If I remember correctly, it was because of a problem in the shell, which may have been subsequently fixed. This isn't an issue for this particular test, but it is an issue if you go and try to make a port of the thing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19: 8:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 4E26C10E6F for ; Tue, 16 Feb 1999 19:07:39 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 17051 invoked from network); 17 Feb 1999 03:07:36 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 03:07:36 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id WAA27574; Tue, 16 Feb 1999 22:07:35 -0500 (EST) Message-Id: <199902170307.WAA27574@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902170218.TAA16616@usr08.primenet.com> from Terry Lambert at "Feb 17, 99 02:18:22 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 16 Feb 1999 22:07:35 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > > > > Actually, you have to support that on most practical architectures. > > [ ... ] > > > malloc and calloc are different. Memory is often recycled in the > > address space when using malloc. sbrk is a security violation if > > the pages aren't prezeroed (or defined to be something other than > > data in other processes or freed data from the kernel :-)). > > Well, the intended application doesn't care about security, so it > should be possible to turn it off. 8-). > > The thing that appalled me was what you said about BSS being zero'ed > in the kernel space using zeroed pages instead of as a result of an > explicit zeroing by the execution class loader. > That is the way that it works. Explict zeroing is wasteful because it cannot easily take advantage of background prezeroing... However, recently prezeroed pages make for efficient usage of cache. The zero queue (and all others) are designed to take advantage of recent cache usage. > > On second thought, though, are the BSS pages zeroed because they > are backed by zero-fill pages, rather than grabbed in user space > via sbrk? That's less apalling. You could conditionalize that > code. > They are backed by zero-fill pages. Processes don't do the zeroing themselves because of security reasons (in current kernels.) The execution class loaders sometimes have to do explict zeroes due to broken non-aligned binary formats. The kernel has efficient mechanisms for providing zeroed pages, but I guess that there are times that even efficiently zeroing pages isn't fast enough. > > I think the compile option he wants to add is "VM_FG_ZERO_PAGES" > or something similar, that indicates the subsystem effected and > the effect, and then "VM_DIRTY_PAGES_OK". > > In other words, I'd seperate turning off the background zeroing and > the default-mandatory nature of pages zeroed for security rather > than functional purposes. > Well, that is an application issue (how you would want to implement it from an enable/disable standpoint.) All I am saying is that implementing the details of how it works is easy -- perhaps not obvious to a non-kernel hacker though. The kind of thing being asked for requires only an addition of a simple flag to a map entry, and the appropriate modification of how fault works when that flag is set. > > Another place that would have to be conditionalized, besides the > /dev/zero and BSS issues, would be backing store for file pages > allocated on a file extend. I know a number of programs that > rely on the POSIX sideways promise that "holes contain zeros" > (it's OK to break security, but not semantics). > Those pages should be zeroed anyway in any case. In the same way that bss almost has to be pre-zeroed (for reasonable behavior of standard C programs), proper zeroing of file contents is likely necessary to keep programmers from going nutty. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19:18: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id C2FBF11110; Tue, 16 Feb 1999 19:17:43 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.1/8.9.1) id OAA02264; Wed, 17 Feb 1999 14:24:27 +1100 (EST) (envelope-from jb) From: John Birrell Message-Id: <199902170324.OAA02264@cimlogic.com.au> Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <19990217132952.Z515@lemis.com> from Greg Lehey at "Feb 17, 1999 1:29:52 pm" To: grog@lemis.com (Greg Lehey) Date: Wed, 17 Feb 1999 14:24:27 +1100 (EST) Cc: chuckr@mat.net, eivind@FreeBSD.ORG, hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > There's stuff before main in C programs as well. The entry point of > all C and C++ programs is start, which is in crt0.o or crt1.o. In > a.out files, it used to be directly after the header at 0x1020. I'm > not sure where the start address is in an ELF file. The clue should > be here somewhere, but I can't see it: > > $ objdump --section-headers /bin/sh Look in the elf header, not the sections. The entry address is in e_entry (grep for that in the elf header files). The elf header starts at the beginning of the file. You have to read the elf header to know how many sections you have. Although the original question wasn't related to the kernel, it's worth noting that the PT_INTERP section (that occurs due to the need to link the kernel shareable to allow klds to work) requires e_entry to be offset by the size of the interpreter section. The GNU tools are somewhat fooled by what we are doing with our kernel. I found this out trying to decompress and elf kernel from flash into RAM in an embedded system. If you believe the e_entry value, BOOM! Offset it by the size of the PT_INTERP section and jump to the resulting address and the standard FreeBSD kernel runs embedded (no disk, no NFS). -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19:19:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (b133.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id CA17311044; Tue, 16 Feb 1999 19:18:45 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id WAA02051; Tue, 16 Feb 1999 22:17:22 -0500 (EST) Date: Tue, 16 Feb 1999 22:17:22 -0500 (EST) From: Chuck Robey To: Greg Lehey Cc: Eivind Eklund , hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <19990217132952.Z515@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Greg Lehey wrote: > There's stuff before main in C programs as well. I thought the stuff before main() in C programs was strictly dealing with shared loading (crt0.o stuff only), and only C++ programs had actual code (global constructors) to execute. I don't regard the loading stuff as part of a user's program, unless you're kernel hacking, because it is not in any way modified by any user source. Is this really incorrect? The entry point of > all C and C++ programs is start, which is in crt0.o or crt1.o. In > a.out files, it used to be directly after the header at 0x1020. I'm > not sure where the start address is in an ELF file. The clue should > be here somewhere, but I can't see it: ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 19:32: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 552891119B; Tue, 16 Feb 1999 19:31:53 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id OAA12854; Wed, 17 Feb 1999 14:01:52 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA10420; Wed, 17 Feb 1999 14:01:50 +1030 (CST) Message-ID: <19990217140149.B515@lemis.com> Date: Wed, 17 Feb 1999 14:01:49 +1030 From: Greg Lehey To: Chuck Robey Cc: Eivind Eklund , hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? References: <19990217132952.Z515@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Chuck Robey on Tue, Feb 16, 1999 at 10:17:22PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 16 February 1999 at 22:17:22 -0500, Chuck Robey wrote: > On Wed, 17 Feb 1999, Greg Lehey wrote: >> There's stuff before main in C programs as well. The entry point >> of all C and C++ programs is start, which is in crt0.o or crt1.o. >> In a.out files, it used to be directly after the header at 0x1020. >> I'm not sure where the start address is in an ELF file. The clue >> should be here somewhere, but I can't see it: > > I thought the stuff before main() in C programs was strictly dealing > with shared loading (crt0.o stuff only), and only C++ programs had > actual code (global constructors) to execute. I don't regard the > loading stuff as part of a user's program, unless you're kernel hacking, > because it is not in any way modified by any user source. > > Is this really incorrect? Yes. Take a look at /usr/src/lib/csu/i386/crt0.c and marvel. I certainly did. The last time I looked at this file, in BSD/386 1., it was about 20 instructions. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 20: 4:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (Postfix) with ESMTP id E0348115D8 for ; Tue, 16 Feb 1999 20:01:25 -0800 (PST) (envelope-from sjr@home.net) Received: (from sjr@localhost) by istari.home.net (8.9.2/8.8.6) id XAA14999; Tue, 16 Feb 1999 23:01:23 -0500 (EST) Date: Tue, 16 Feb 1999 23:01:23 -0500 (EST) From: "Stephen J. Roznowski" Message-Id: <199902170401.XAA14999@istari.home.net> To: freebsd-hackers@FreeBSD.ORG Subject: lpt -> nlpt change over problem? Cc: nsouch@teaser.fr, des@flood.ping.uio.no Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There still appears to be a problem with the lpt -> nlpt change over that recently occurred. In my custom kernel configuration I still had [I'm running 4.0-CURRENT]: ... device lpt0 at isa? port? tty irq 7 vector lptintr ... My kernel config-ed correctly, but errored during the build (no surprise). Shouldn't I get a warning of some sort during the "config KERNEL" step? Thanks, -SR To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 21: 1: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from monk.via.net (monk.via.net [209.81.9.10]) by hub.freebsd.org (Postfix) with ESMTP id 3290510E7D for ; Tue, 16 Feb 1999 21:00:58 -0800 (PST) (envelope-from joe@monk.via.net) Received: (from joe@localhost) by monk.via.net (8.8.8/8.8.8) id VAA21652 for hackers@freebsd.org; Tue, 16 Feb 1999 21:00:58 -0800 (PST) (envelope-from joe) From: Joe McGuckin Message-Id: <199902170500.VAA21652@monk.via.net> Date: Tue, 16 Feb 1999 21:00:57 -0800 (PST) To: hackers@freebsd.org Subject: 3.1-RELEASE hangs during floppy boot In-Reply-To: <19990216185048.A25590@caida.org> X-Mailer: Ishmail 1.3.1-970608-bsdi MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I made the 2 floppoes, no erros. Booting from the first, then inserting the second one when prompted seems to work until the SCSI disk is detected (da0), then it hangs and never recovers. Help! What happens after SCSI probing? I'm guessing that is where it's having problems. This machine sucessfully ran 3.0 release with no problems! Thanks, Joe Joe McGuckin ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 90403 Phone: 650-969-2203 Cell: 415-710-4894 Fax: 650-969-2124 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 21:16:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 51FF810F43; Tue, 16 Feb 1999 21:16:37 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10CzLg-0006SX-00; Tue, 16 Feb 1999 22:16:36 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id WAA51452; Tue, 16 Feb 1999 22:19:12 -0700 (MST) Message-Id: <199902170519.WAA51452@harmony.village.org> To: Nicolas Souchu Subject: Re: Aladdin chipset SMBus support available! Cc: takawata@shidahara1.planet.sci.kobe-u.ac.jp, Brian Feldman , current@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 14 Feb 1999 20:40:54 +0100." <19990214204054.42098@breizh.prism.uvsq.fr> References: <19990214204054.42098@breizh.prism.uvsq.fr> <199902141855.DAA03817@libr.scitec.kobe-u.ac.jp> Date: Tue, 16 Feb 1999 22:19:11 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Not to stop you in your tracks, but I would really love to see : somebody (more capable than the PAO people) work out a power : management architecture for us before we have too many more : hacks in this area... I'd have to agree that a unified power management architecture would be a good thing. There is also the new APCI to consider as well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 21:19: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from biggusdiskus.flyingfox.com (parker-T1-2-gw.sf3d.best.net [209.157.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 8323C111B1 for ; Tue, 16 Feb 1999 21:18:59 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.8/8.8.5) id WAA25521 for hackers@freebsd.org; Tue, 16 Feb 1999 22:25:50 -0800 (PST) Date: Tue, 16 Feb 1999 22:25:50 -0800 (PST) From: Jim Shankland Message-Id: <199902170625.WAA25521@biggusdiskus.flyingfox.com> To: hackers@freebsd.org Subject: Re: vm_page_zero_fill In-Reply-To: <199902170152.UAA00758@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Terry:] > Expecting sbrk'ed pages to be zero filled is just *wrong*. [John Dyson:] > Actually, you have to support that on most practical architectures. Architectures aside, the *semantics* have always been that newly sbrk-ed pages are zero-filled. It's been that way since at least v7. I went and looked for chapter and verse on this in the sbrk(2) man page, and was astonished not to find it. The Solaris man page mentions it, though, and I'll bet man page archaeologists can verify my assertion that this goes way, way back. Expecting to be able to get away with *not* zero=filling newly sbrk'ed pages is just *wrong*. Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 21:40:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 9EF1C10ED4 for ; Tue, 16 Feb 1999 21:40:15 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id AAA14546; Wed, 17 Feb 1999 00:59:14 -0500 (EST) Date: Wed, 17 Feb 1999 00:59:13 -0500 (EST) From: perlsta To: Wes Peters Cc: Donn Miller , hackers@FreeBSD.ORG Subject: Re: Systems programming for FreeBSD In-Reply-To: <36C9F07C.7F2C9367@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Wes Peters wrote: > Donn Miller wrote: > > > There's a Linux howto on systems programming, maybe FreeBSD is similar > > in that respect. so I can just use the Linux howto for FreeBSD. What > > are ports anyway, is it like you're writing to a special part of memory? > > No, I/O ports are a separate address space from memory. I strongly > suggest a good book on x86 architecture, but don't have any idea > what one might be. Mine is ages old and probably isn't published > anymore. > > Suggestions, hackers? 'PC Intern' is *THE* book. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 22:15:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 67F9F10F0C for ; Tue, 16 Feb 1999 22:15:48 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10D0EW-000I31C; Wed, 17 Feb 1999 01:13:16 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: PPP Problem To: hackers@freebsd.org Date: Wed, 17 Feb 1999 01:13:15 -0500 (EST) Cc: brian@awfulhak.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 754 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Running 2.2-stable with user-ppp. I set up a test PPP link, tunneling PPP over TCP. I do not run routed or gated. The PPP server (-direct) is located on my LAN gateway machine, which has my ISPs router defined as its gateway. There are no definitions in ppp.conf, ppp.linkup or ppp.linkdown that refer in any way to the 0.0.0.0/0 default definition. The client machine does have 0.0.0.0 as the 4th parameter to its set ifaddr command, which may contribute to the symptoms in some way. I'll try removing that next... Shortly after or when the link is made, the ppp program removes the default definition from the server's routing tables. So far I tried removing all references to HISADDR, MYADDR and disabling sroutes - nothing helped. Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 22:37:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [205.147.43.4]) by hub.freebsd.org (Postfix) with ESMTP id 09E9A10E84 for ; Tue, 16 Feb 1999 22:37:51 -0800 (PST) (envelope-from dave@jetcafe.org) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.8/8.8.5) with ESMTP id WAA13083 for ; Tue, 16 Feb 1999 22:37:51 -0800 (PST) Message-Id: <199902170637.WAA13083@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@freebsd.org Subject: getpwnam and getpwnam_r Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Feb 1999 22:37:51 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Where are the thread-safe, reentrant versions of this routine in FreeBSD 3.1? ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org Keep Usenet Free - http://www.jetcafe.org/~dave/usenet >>> The opinions expressed above are entirely my own <<< Nasrudin arrived at an all-comers horse race mounted on the slowest of oxen. Everyone laughed, an ox cannot run. "But I have seen it, when it was only a calf, running faster than a horse.", said Nasrudin. "So why should it not run faster, now that it is larger?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 23:26:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 112C310F25 for ; Tue, 16 Feb 1999 23:26:26 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA11075; Wed, 17 Feb 1999 00:26:13 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36CA6F15.58EB82DF@softweyr.com> Date: Wed, 17 Feb 1999 00:26:13 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Hayes Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: getpwnam and getpwnam_r References: <199902170637.WAA13083@hokkshideh.jetcafe.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dave Hayes wrote: > > Where are the thread-safe, reentrant versions of this routine in > FreeBSD 3.1? Not done yet. I'm working on them, all of them, but I've been up to my neck at work for the last two months. Here's my working list, gleaned from the solaris man pages: asctime_r ctime (3c) - convert date and time to string ctermid_r ctermid (3s) - generate path name for controlling terminal ctime_r ctime (3c) - convert date and time to string gmtime_r ctime (3c) - convert date and time to string localtime_r ctime (3c) - convert date and time to string gamma_r lgamma (3m) - log gamma function lgamma_r lgamma (3m) - log gamma function strtok_r string (3c) - string operations These are implemented, and should be in 3.1-RELEASE. (Some of them were already in the code, just not in the man pages yet. None of these were tremendously difficult to do, given the original code and Solaris man pages as a design document.) I was going to start on the network database routines next, but if you have a pressing need for the password/group database stuff, I can probably get them done fairly quickly. Or, if you'd like to implement them yourself and send me diffs, I'll be glad to look them over and commit them for you. Don't forget to include diffs for the man pages. ;^) Routines I haven't finished yet: fgetgrent_r getgrnam (3c) - get group entry fgetpwent_r getpwnam (3c) - get password entry fgetspent_r getspnam (3c) - get password entry getgrent_r getgrnam (3c) - get group entry getgrgid_r getgrnam (3c) - get group entry getgrnam_r getgrnam (3c) - get group entry gethostbyaddr_r gethostbyname (3n) - get network host entry gethostbyname_r gethostbyname (3n) - get network host entry gethostent_r gethostbyname (3n) - get network host entry getlogin_r getlogin (3c) - get login name getnetbyaddr_r getnetbyname (3n) - get network entry getnetbyname_r getnetbyname (3n) - get network entry getnetent_r getnetbyname (3n) - get network entry getnetgrent_r getnetgrent (3n) - get network group entry getprotobyname_r getprotobyname (3n) - get protocol entry getprotobynumber_r getprotobyname (3n) - get protocol entry getprotoent_r getprotobyname (3n) - get protocol entry getpwent_r getpwnam (3c) - get password entry getpwnam_r getpwnam (3c) - get password entry getpwuid_r getpwnam (3c) - get password entry getrpcbyname_r getrpcbyname (3n) - get RPC entry getrpcbynumber_r getrpcbyname (3n) - get RPC entry getrpcent_r getrpcbyname (3n) - get RPC entry getservbyname_r getservbyname (3n) - get service entry getservbyport_r getservbyname (3n) - get service entry getservent_r getservbyname (3n) - get service entry getspent_r getspnam (3c) - get password entry getspnam_r getspnam (3c) - get password entry rand_r rand (3c) - simple random-number generator readdir_r directory (3c) - directory operations tmpnam_r tmpnam (3s) - create a name for a temporary file ttyname_r ttyname (3c) - find name of a terminal If anyone has additions to this list, please feel free to send them to me. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Feb 16 23:49:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 3A0B410EC6 for ; Tue, 16 Feb 1999 23:49:33 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id HAA09138; Wed, 17 Feb 1999 07:43:51 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id HAA37802; Wed, 17 Feb 1999 07:43:38 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902170743.HAA37802@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: tom@tomqnx.com (Tom Torrance at home) Cc: hackers@freebsd.org, brian@awfulhak.org Subject: Re: PPP Problem In-reply-to: Your message of "Wed, 17 Feb 1999 01:13:15 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Feb 1999 07:43:38 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You must have a ``delete 0'' (same as ``delete 0.0.0.0'' or ``delete default'') somewhere. > Running 2.2-stable with user-ppp. > > I set up a test PPP link, tunneling PPP over TCP. > I do not run routed or gated. The PPP server (-direct) is located > on my LAN gateway machine, which has my ISPs router > defined as its gateway. There are no definitions in > ppp.conf, ppp.linkup or ppp.linkdown that refer in any > way to the 0.0.0.0/0 default definition. > > The client machine does have 0.0.0.0 as the 4th parameter to > its set ifaddr command, which may contribute to the symptoms > in some way. I'll try removing that next... > > Shortly after or when the link is made, the ppp program removes > the default definition from the server's routing tables. So far > I tried removing all references to HISADDR, MYADDR and disabling > sroutes - nothing helped. > > Regards, > Tom -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 0:43:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1906510F60 for ; Wed, 17 Feb 1999 00:43:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id JAA27201 for ; Wed, 17 Feb 1999 09:43:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA68932 for hackers@freebsd.org; Wed, 17 Feb 1999 09:43:29 +0100 (MET) Date: Wed, 17 Feb 1999 09:43:28 +0100 From: Eivind Eklund To: hackers@freebsd.org Subject: Re: gdb sucks - and I need to get around it. help? Message-ID: <19990217094328.C65865@bitbox.follo.net> References: <19990216170310.C60651@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990216170310.C60651@bitbox.follo.net>; from Eivind Eklund on Tue, Feb 16, 1999 at 05:03:10PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 16, 1999 at 05:03:10PM +0100, Eivind Eklund wrote: > Anybody know of any way of getting gdb to step from the start of the > program? > > I have an executable with absolutely no symbol data (symbol data is > absolutely non-available) which I *have* to get to step through, if > necessary by re-implementing gdb. Well, turns out that the behaviour / bug in question was triggered by more of gdb's weird behaviour. What was happening (which put me in the '*have* to' mode) was that top was getting segment violations due to being out of sync with the kernel, and I though that was a bad thing and should be fixed and su'ed and ran gdb on top - and got a # prompt. I have several 'role' PGP keys on this box, and a compromise would have been pretty icky. Thanks for all the suggestions - I'm sure I'll get to use them another day, as I've found this behaviour to be at least somewhat in my way time and time again. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 1:16:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 2FBC610ED5; Wed, 17 Feb 1999 01:16:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id JAA61059; Wed, 17 Feb 1999 09:14:47 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 17 Feb 1999 09:14:47 +0000 (GMT) From: Doug Rabson To: Warner Losh Cc: Nicolas Souchu , takawata@shidahara1.planet.sci.kobe-u.ac.jp, Brian Feldman , current@freebsd.org, hackers@freebsd.org Subject: Re: Aladdin chipset SMBus support available! In-Reply-To: <199902170519.WAA51452@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Warner Losh wrote: > : Not to stop you in your tracks, but I would really love to see > : somebody (more capable than the PAO people) work out a power > : management architecture for us before we have too many more > : hacks in this area... > > I'd have to agree that a unified power management architecture would > be a good thing. There is also the new APCI to consider as well. > > Warner And hot-docking/undocking with PnP reprobing of new devices... Ouch, stop hitting me. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 1:54:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id DFE5F10EB8 for ; Wed, 17 Feb 1999 01:54:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id BAA50836; Wed, 17 Feb 1999 01:54:06 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902170954.BAA50836@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Cc: Mike Smith Subject: bootloader write up ? Mime-Version: 1.0 Content-Type: tt/plain; charset=us-ascii Date: Wed, 17 Feb 1999 01:54:06 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just looking around for docs on the bootloader to help out the oskit team write a "boot loader adapter" so we may boot oskit kernels on FreeBSD 3.xx and higher systems. Tnks, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 3:59:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bbs.mpcs.com (bbs.mpcs.com [209.101.88.2]) by hub.freebsd.org (Postfix) with ESMTP id 6DBCC10EC6 for ; Wed, 17 Feb 1999 03:59:07 -0800 (PST) (envelope-from hg@penny.n2wx.ampr.org) Received: from pickle.n2wx.ampr.org (cc1017255-a.srst1.fl.home.com [24.3.122.197]) by bbs.mpcs.com (8.8.8/8.8.8/MPCS spamzap) with ESMTP id GAA21616; Wed, 17 Feb 1999 06:59:05 -0500 Received: (from root@localhost) by pickle.n2wx.ampr.org (8.9.2/8.8.2/n2wx) id GAA32962; Wed, 17 Feb 1999 06:59:03 -0500 (EST) Received: from penny.n2wx.ampr.org (penny.n2wx.ampr.org [172.16.0.5]) by pickle.n2wx.ampr.org (8.9.2/8.9.2/n2wx) with ESMTP id GAA32956; Wed, 17 Feb 1999 06:58:54 -0500 (EST) (envelope-from hg@n2wx.ampr.org) Received: (from hg@localhost) by penny.n2wx.ampr.org (8.9.2/8.8.8/n2wx) id GAA10270; Wed, 17 Feb 1999 06:58:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14026.44797.255019.909901@penny.south.mpcs.com> Date: Wed, 17 Feb 1999 06:58:53 -0500 (EST) From: Howard Goldstein Reply-To: hgoldste@bbs.mpcs.com To: Terry Lambert Cc: freebsd-hackers@freebsd.org Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902140105.SAA01804@usr06.primenet.com> References: <14021.27462.556760.465144@penny.south.mpcs.com> <199902140105.SAA01804@usr06.primenet.com> X-Mailer: VM 6.62 under Emacs 19.34.1 Organization: disorganization Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > > > > Realtime signals would help almost as much, perhaps in a more portable > > > > way. > > > > > > man setitimer > > > > 'Sir, may I please have some more?' > > > > I use it...I always feel dirty when I have setitimer signal a clumsy > > monolith that is itself in many ways like the one that deals with the > > aftermath of a select(). More timers, a la posix realtime signals > > (p1003B? I'm sure I'm citing the wrong posix id) would be cleaner, > > and would make it easier to write pthreaded applications. > > Silly Oliver Twist... POSIX is getting more and more barnacle > encrusted as time goes on. The POSIX stuff is to the point now > that it should be implemented in libraries, instead of kernels, > so that the majority of it can be ignored, while still allowing > you to claim conformance. Agreed. However, implemented as a library, will I be able to claim performance? A very quick dejanews scan seems to hint that libraries are not an uncontroversial place for them to reside in. > My personal preference for high concurrency, low overhead, SMP > scalable threads is a user space scheduler that consumes async call > gates. POSIX chickened out on this, and there are still calls that > you can make that force you to give away your quantum, and which > have no async alternatives. (Forced timeslice donation below) SMP changes things a lot, doesn't it... Nice part is there's a lot of new trail to blaze. Kind of starting to feel like around 20 years ago, minus Reagan and Blondie. > 'Some calls are more async than others.' > > >From my point of view, if the scheduler gives me a quantum, then > *it's MY quantum*, and anything that makes me "give part of it back" > for the dubious benefit of making a blocking call and taking a full > context switch is just plain stupid. A call that blocks can be a good thing. It all depends on what you're trying to accomplish, whether those other processes eating up cycles are also your processes or someone you don't really care about too much. Awaiting i/o, or expiration of a timer, these things seem like they could be more efficiently resolved in the kernel during blocking calls, at least when those other processes are mine! POSIX-like [*] realtime signals managed by the kernel potentially eliminate the userland dispatching stuff, resulting in even more joyful blocking. Granted, one man's dread is another man's joy... [*] it isn't so much conformance to a doc as it is the functionality that I sought, and nb., that was fallback functionality. If I have a modified time value in a modified select() I'll slink away from this. > See the other thread in this forum on FreeBSD vs. Network Appliance > market niches. NetApp uses a non-preemptive multitasking and > multithreaded kernel. This is good, because it eliminates context > switch thrashing. This is bad, because it's not SMP scalable, and, > like Windows 3.1, you have to trust all of your threads of execution > to "play nice". An async call gate, combined with a user space > scheduler, resolves the context switch thrashing equally well, while > still allowing the SMP scalability, and taking into account that > God can't write all of your threads of execution at the cost of > minimally necessary context switch overhead. Whee! I haven't reviewed that thread at any length; I'll try this weekend. It seems every significant packet switching project I've ever worked on we've either rolled our own non-preemptive executive (sans threads) or used something near-off-shelf (Hagar in a mostly X.25 switch comes to mind). I'm not sure a comparison is valid give the limited scope of what the o/s in a switch has to deal with compared to the more generic kinds of things we have to serve up in FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 5:16:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 75DC010F31 for ; Wed, 17 Feb 1999 05:15:58 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id OAA36322; Wed, 17 Feb 1999 14:15:45 +0100 (CET) (envelope-from des) To: "Stephen J. Roznowski" Cc: freebsd-hackers@FreeBSD.ORG, nsouch@teaser.fr Subject: Re: lpt -> nlpt change over problem? References: <199902170401.XAA14999@istari.home.net> From: Dag-Erling Smorgrav Date: 17 Feb 1999 14:15:44 +0100 In-Reply-To: "Stephen J. Roznowski"'s message of "Tue, 16 Feb 1999 23:01:23 -0500 (EST)" Message-ID: Lines: 37 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Stephen J. Roznowski" writes: > There still appears to be a problem with the lpt -> nlpt > change over that recently occurred. In my custom kernel > configuration I still had [I'm running 4.0-CURRENT]: > > ... > device lpt0 at isa? port? tty irq 7 vector lptintr > ... > > My kernel config-ed correctly, but errored during the build > (no surprise). > > Shouldn't I get a warning of some sort during the "config KERNEL" > step? No, because lpt0 is a valid device, since nlpt has been renamed to lpt. Your kernel config should read: device ppc0 at isa? port? tty irq 7 controller ppbus0 at ppc0 device lpt0 at ppbus? You might want to add more ppbus devices, such as: device plip0 at ppbus? device ppi0 at ppbus? (see the man pages for more devices) OBTW, if you're runninc 4.0 you should be aware that the "vector xxxintr" stuff is deprecated and serves no purpose (it's overridden by values hardcoded into every driver). Just remove that part from every device line in your kernel config. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 5:26:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2A0AA10E88 for ; Wed, 17 Feb 1999 05:26:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id OAA12574; Wed, 17 Feb 1999 14:26:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA70173; Wed, 17 Feb 1999 14:26:29 +0100 (MET) Date: Wed, 17 Feb 1999 14:26:28 +0100 From: Eivind Eklund To: Brandon Gillespie Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: savecore before swapon? Message-ID: <19990217142628.F69668@bitbox.follo.net> References: <19990216082600.A15274@ice.cold.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990216082600.A15274@ice.cold.org>; from Brandon Gillespie on Tue, Feb 16, 1999 at 08:26:00AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 16, 1999 at 08:26:00AM -0700, Brandon Gillespie wrote: > I havn't checked the source, but from my understanding shouldn't > savecore be run before swapon is run, incase the swap device is the > dump device? Or to look at it another way, when swapon is run on a > swap device, does it look first to see if there is a dump in it, and > if so what does it do? Right now we run swapon, then considerably > later we run savecore. Assuming swapon just trashes whatever was in > that device, running savecore is pretty much irrelevant, as most > people I know (not necessarily in FreeBSD) use their swap device as a > dump point. This is done intentionally, as fsck may in some cases require swap to be able to fsck large filesystems. It would make sense to have a sysctl 'only_swap_as_absolutely_last_resort_not_for_performance' AKA 'do_linux_swapping_scheme' which was set before the swapon, and unset after the crashdump. I don't know how to implement this. (It might be that one of the present sysctls does something like this - I've not checked). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 5:32: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6463910FC3 for ; Wed, 17 Feb 1999 05:32:03 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id OAA13074; Wed, 17 Feb 1999 14:31:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA70226; Wed, 17 Feb 1999 14:31:31 +0100 (MET) Date: Wed, 17 Feb 1999 14:31:31 +0100 From: Eivind Eklund To: Wes Peters Cc: John Polstra , Jamie Bowden , hackers@FreeBSD.ORG Subject: Re: FreeBSD mention in LWN interview with A.C. Message-ID: <19990217143130.G69668@bitbox.follo.net> References: <36C9F60F.7AE40274@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <36C9F60F.7AE40274@softweyr.com>; from Wes Peters on Tue, Feb 16, 1999 at 03:49:51PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Feb 16, 1999 at 03:49:51PM -0700, Wes Peters wrote: > As I said, Perforce is an excellent product with much to recommend it, > but probably not the best solution for FreeBSD. What we have works quite > well, because it was developed by highly motivated developers to pretty > much do exactly what FreeBSD needs. If only *every* development project > were this lucky. > > Especially Linux... ;^) http://www.bitkeeper.com/ Looks quite good. It is missing a number of features from my favourite (but not yet implemented) design, but it also has a number of nice aspects that I've missed... Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 6:19:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mgate05.so-net.ne.jp (mgate05.so-net.ne.jp [210.132.247.35]) by hub.freebsd.org (Postfix) with ESMTP id 3D2BB10EBE for ; Wed, 17 Feb 1999 06:19:24 -0800 (PST) (envelope-from sanewo@ba2.so-net.ne.jp) Received: from mail.ba2.so-net.ne.jp (mail.ba2.so-net.ne.jp [210.132.247.97]) by mgate05.so-net.ne.jp (8.8.8+3.0Wbeta9/3.6W99021523) with ESMTP id XAA03006 for ; Wed, 17 Feb 1999 23:19:19 +0900 (JST) Received: from ba2.so-net.ne.jp (p84b58b.sng2.ap.so-net.ne.jp [210.132.181.139]) by mail.ba2.so-net.ne.jp (8.8.8+3.0Wbeta9/3.7W99021712) with ESMTP id XAA13164 for ; Wed, 17 Feb 1999 23:19:16 +0900 (JST) Message-Id: <199902171419.XAA13164@mail.ba2.so-net.ne.jp> Gcc: nnmh:cc To: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? References: From: Takanori Saneto In-Reply-To: (Matthew Jacob's message of "Thu, 11 Feb 1999 09:34:52 -0800 (PST)") MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Feb 1999 23:19:17 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been getting the same panic couple times. In article , Matthew Jacob writes: >panic: softdep_sync_metadata: Unknown type bmsafemap I also got other types of problems during system shutdown (unmounting filesystems): * mfs process aborts with signal 11. There were no coredumps nor diagnostic logs so I can't get any deeper info. * Hang after "syncing disks ... done" message. I tried to check stack trace using DDB but no useful info could be found. (Maybe, I need to know how to find the info about waiting processes/threads). ==== dmesg output ==== Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #36: Sun Feb 14 01:22:50 JST 1999 sanewo@muse:/usr/src/sys/compile/MUSE Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping=1 Features=0x183f9ff> real memory = 134217728 (131072K bytes) config> pnp 1 0 enable os port0 0x220 port1 0x330 port2 0x388 irq0 5 drq0 1 drq1 5 config> pnp 1 2 enable os port0 0x620 port1 0xa20 port2 0xe20 config> quit avail memory = 127197184 (124216K bytes) Preloaded elf kernel "kernel" at 0xf034d000. Preloaded userconfig_script "/boot/pnp.conf" at 0xf034d09c. Preloaded splash_image_data "/boot/hanabatakeL8.BMP" at 0xf034d0e8. Preloaded elf module "splash_bmp.ko" at 0xf034d13c. Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 ide_pci0: rev 0x01 on pci0.4.1 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 9 on pci0.10.0 ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs de0: rev 0x22 int a irq 10 on pci0.11.0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:00:f4:95:74:32 Probing for devices on PCI bus 1: vga0: rev 0x21 int a irq 11 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00e4 [0xe4008c0e] Serial 0x054b753f Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x054b753f) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <12 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 Generic PS/2 mouse, device ID 0 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 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-16 wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0x80ff80ff on isa wdc1: unit 0 (atapi): , removable, accel, ovlap, dma, iordis acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3c0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.2 de0 XXX: driver didn't set ifq_maxlen ds0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen Waiting 15 seconds for SCSI devices to settle de0: enabling 10baseT port changing root device to wd0s3a da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) cd0 at ahc0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: cd present [1 x 2048 byte records] da2 at ahc0 bus 0 target 4 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da2: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) WARNING: / was not properly dismounted ffs_mountfs: superblock updated for soft updates (da2:ahc0:0:4:0): tagged openings now 64 ==== config file contents ==== machine "i386" ident GENERIC maxusers 32 options PQ_LARGECACHE # color for 512k/16k cache config kernel root on wd0 cpu "I686_CPU" options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT #allow user-level control of i386 ldt options SYSVSHM options SYSVSEM options SYSVMSG options "MD5" options "VM86" options DDB options KTRACE #kernel tracing options PERFMON #Pentium perfomance counter options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options INTRO_USERCONFIG #imply -c and show intro screen options INET #InterNETworking pseudo-device loop pseudo-device ether pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device tun 1 pseudo-device disc #Discard device pseudo-device streams #SVR4 STREAMS # FILESYSTEM OPTIONS options FFS options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES # Allow this many swap-devices. options NSWAPDEV=4 options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options "CLK_USE_I8254_CALIBRATION" options CLK_USE_TSC_CALIBRATION controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0x80ff80ff disk wd0 at wdc0 drive 0 controller wdc1 at isa? port "IO_WD2" bio irq 15 flags 0x80ff80ff options "CMD640" #Enable work around for CMD640 h/w bug options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM/R/RW controller ahc0 options AHC_ALLOW_MEMIO controller scbus0 at ahc0 # SCSI direct access dev device da0 at scbus0 target 1 device da1 at scbus0 target 2 device sa0 # SCSI sequencial access dev device pass0 # SCSI passthrough dev device cd0 # SCSI CD-ROM device ch0 # SCSI media changers device pt0 at scbus? # SCSI processor type device sctarg0 at scbus? # SCSI target # atkbdc0 controlls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts pseudo-device splash # The syscons console driver (sco color console compatible). device sc0 at isa? tty options MAXCONS=12 options SC_HISTORY_SIZE=1000 # number of history buffer lines options VESA device npx0 at isa? port IO_NPX iosiz 0x0 flags 0x0 irq 13 device apm0 at isa? device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 device de0 pseudo-device pty 16 # keep this if you want to be able to continue to use /stand/sysinstall pseudo-device gzip # Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. ## this entry is required but not used. PnP pcm will become pcm1 device pcm0 at isa ? port ? tty irq 7 drq 1 disable controller pnp0 # default is 8192 options "MSGBUF_SIZE=40960" -- Takanori "Roy" Saneto To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 7: 1:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (Postfix) with ESMTP id D3D1011031 for ; Wed, 17 Feb 1999 07:01:06 -0800 (PST) (envelope-from bs@adimus.de) Received: (from admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id QAA06348; Wed, 17 Feb 1999 16:00:47 +0100 (MET) Received: from mail by mx.adimus.de with local (Exim 1.92 #1) id 10D8Pk-0000df-00; Wed, 17 Feb 1999 15:57:24 +0100 Received: from det.adimus.de(192.168.0.1) via SMTP by adimus.de, id smtpdQB2335; Wed Feb 17 15:57:16 1999 Received: from bs by det.adimus.de with local (Exim 1.92 #1) id 10D8Pb-0000ZD-00; Wed, 17 Feb 1999 15:57:15 +0100 To: Roland Jesse Cc: FreeBSD Hackers Mail List Subject: Re: Makefile: >1 program without a single target each. References: <199902161717.RAA01752@excalibur.oceanis.net> <22059.919187358@zippy.cdrom.com> <19990216235700.A9965@cs.uni-magdeburg.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Benedikt Stockebrand Date: 17 Feb 1999 15:57:13 +0100 In-Reply-To: Roland Jesse's message of "Tue, 16 Feb 1999 23:57:00 +0100" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Roland Jesse writes: > Just in case, I want to build the whole thing not only on my FreeBSD > machine but on some SGIs, too: What kind of make is BSD make exactly? It > does not seem to be pmake, it is for sure not GNU make. Is there an > archiv if its source code available (besides /usr/src/usr.bin/make/)? I've once made a binary for Linux doing a "make -n" in /usr/src/usr.bin/make on a FreeBSD box, sending the output to a file and then ran that file as a shell script on the Linux box. Afterwards I copied /usr/share/mk from FreeBSD to the Linux box and was done. Yes, it's ugly. But it was either that or rewriting a 1000 lines Makefile for gmake. So long, Ben -- Benedikt Stockebrand Adimus Beratungsgesellschaft für System- System Administration & Design, und Netzwerkadministration mbH & Co KG IT Security, Remote System Mgmt Universitätsstr. 142, 44799 Bochum Opinions presented are my own. Tel. (02 34) 971 971 -2, Fax -9 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 8:26:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 5836B11073 for ; Wed, 17 Feb 1999 08:26:43 -0800 (PST) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 3A05B258; Wed, 17 Feb 1999 11:26:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with SMTP id 1F4D5257 for ; Wed, 17 Feb 1999 11:26:40 -0500 (EST) Date: Wed, 17 Feb 1999 11:26:39 -0500 (EST) From: David Miller To: freebsd-hackers@freebsd.org Subject: Simple scsi question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Briefly, I need to control /dev/uk0. scsi(8) does fine for simple non-data transferring commands, but I can't see how to use it to write megabytes of data out to the device. Since I eventually have to talk pretty low level to the device anyway, would one of the wise and kind readers here please point me to a piece of existing code for tape or disk or something which actually performs a low level write, including CDB setup? Thanks in advance:) --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 8:32: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5F3A710E66 for ; Wed, 17 Feb 1999 08:32:04 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA07623; Wed, 17 Feb 1999 08:31:38 -0800 Date: Wed, 17 Feb 1999 08:31:38 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Simple scsi question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG See Dave Mosberger Tang's SANE package- I believe it uses ukXXX. See the FreeBSD port's collection. Dave- all of this is gone away in CAM (3.X on forward)- that uses a different method, and the source to camcontrol(8) may give some examples of how that works. On Wed, 17 Feb 1999, David Miller wrote: > Briefly, I need to control /dev/uk0. scsi(8) does fine for simple > non-data transferring commands, but I can't see how to use it to write > megabytes of data out to the device. > > Since I eventually have to talk pretty low level to the device anyway, > would one of the wise and kind readers here please point me to a piece of > existing code for tape or disk or something which actually performs a low > level write, including CDB setup? > > Thanks in advance:) > > --- David > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 9:44:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id AF55210E66 for ; Wed, 17 Feb 1999 09:44:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA06913; Wed, 17 Feb 1999 09:44:28 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 09:44:28 -0800 (PST) From: Matthew Dillon Message-Id: <199902171744.JAA06913@apollo.backplane.com> To: Tor.Egge@fast.no Cc: hackers@freebsd.org Subject: Re: Problems in VM structure ? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is what the system appears to do: ( kern/kern_malloc.c ) vm_kmem_size = VM_KMEM_SIZE; mem_size = cnt.v_page_count * PAGE_SIZE; #if defined(VM_KMEM_SIZE_SCALE) if ((mem_size / VM_KMEM_SIZE_SCALE) > vm_kmem_size) vm_kmem_size = mem_size / VM_KMEM_SIZE_SCALE; #endif #if defined(VM_KMEM_SIZE_MAX) if (vm_kmem_size >= VM_KMEM_SIZE_MAX) vm_kmem_size = VM_KMEM_SIZE_MAX; #endif npg = (nmbufs * MSIZE + nmbclusters * MCLBYTES + vm_kmem_size) / PAGE_SIZE; kmemusage = (struct kmemusage *) kmem_alloc(kernel_map, (vm_size_t)(npg * sizeof(struct kmemusage))); kmem_map = kmem_suballoc(kernel_map, (vm_offset_t *)&kmembase, (vm_offset_t *)&kmemlimit, (vm_size_t)(npg * PAGE_SIZE)); ... ( i386/i386/machdep.c ) clean_map = kmem_suballoc(kernel_map, &clean_sva, &clean_eva, (nbuf*BKVASIZE) + (nswbuf*MAXPHYS) + pager_map_size); buffer_map = kmem_suballoc(clean_map, &buffer_sva, &buffer_eva, (nbuf*BKVASIZE)); pager_map = kmem_suballoc(clean_map, &pager_sva, &pager_eva, (nswbuf*MAXPHYS) + pager_map_size); pager_map->system_map = 1; exec_map = kmem_suballoc(kernel_map, &minaddr, &maxaddr, (16*(ARG_MAX+(PAGE_SIZE*3)))); mb_map_size = nmbufs * MSIZE + nmbclusters * MCLBYTES; mb_map_size = roundup2(mb_map_size, max(MCLBYTES, PAGE_SIZE)); ... mb_map = kmem_suballoc(kmem_map, (vm_offset_t *)&mbutl, &maxaddr, mb_map_size); ... The MAXUSERS calculation does this: #ifndef NMBCLUSTERS #define NMBCLUSTERS (512 + MAXUSERS * 16) #endif #ifndef NSFBUFS #define NSFBUFS (512 + MAXUSERS * 16) #endif #define NPROC (20 + 16 * MAXUSERS) #define MAXFILES (NPROC*2) Ok, so if we have 512MB of main memory and maxusers set to 256. NMBCLUSTRS = 4608 NSFBUFS = 4608 NPROC = 4116 MAXFILES = 8232 ( MCLBYTES = 2048 ) mem_size is 512MB vm_kmem_size = VM_KMEM_SIZE_MAX ( 80 MB ) kmem_map is 2.3 + 9.4 + 80 = around 90 MB. clean_map is 68MB + 4.1MB + 8.3MB = around 80 MB exec_map is 1.2MB So the total KVM allocated is 170MB. Starting at F0100000 we should have around 256MB of KVM. So why doesn't this work? I see a couple of problems right off the bat. If there is more then 2G of memory, mem_size being a signed int will screw things up. If mem_size is > 1G, the final-override-calculation will be wrong: if (vm_kmem_size > 2 * (cnt.v_page_count * PAGE_SIZE)) vm_kmem_size = 2 * (cnt.v_page_count * PAGE_SIZE); But if mem_size is 512MB, everything should work fine. Why doesn't it? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:17: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id ADF0F10FC4 for ; Wed, 17 Feb 1999 10:16:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA07326; Wed, 17 Feb 1999 10:16:56 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 10:16:56 -0800 (PST) From: Matthew Dillon Message-Id: <199902171816.KAA07326@apollo.backplane.com> To: Tor.Egge@fast.no, hackers@FreeBSD.ORG Subject: Re: Problems in VM structure ? References: <199902171744.JAA06913@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : So the total KVM allocated is 170MB. : : Starting at F0100000 we should have around 256MB of KVM. : : So why doesn't this work? I should amend this. It *should* work if you have 512MB of ram and set maxusers to 256. If you have more then 512MB of ram, it obviously will not work. But why are the systems experiencing random crashes? Shouldn't they panic right off the bat? So where are we missing a bounds check? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:21:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by hub.freebsd.org (Postfix) with ESMTP id 47EBD110CB for ; Wed, 17 Feb 1999 10:21:47 -0800 (PST) (envelope-from amarks@sarnoff.com) Received: from sarnoff.com ([130.33.14.232]) by postoffice.sarnoff.com (Netscape Messaging Server 3.5) with ESMTP id AAA5AF4; Wed, 17 Feb 1999 13:21:45 -0500 Message-ID: <36CB0903.B309BC62@sarnoff.com> Date: Wed, 17 Feb 1999 13:22:59 -0500 From: "AARON MARKS" Reply-To: amarks@sarnoff.com Organization: Sarnoff Corporation X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Memory-Based VFS Question References: <199902162316.QAA09873@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > It will use VOP_GETPAGES/VOP_PUTPAGES. Since the man page is not very instructive for these ops and I'm new to the FreeBSD kernel, is there a particular source that I can model these after? Should I just model after the generic functions (vnode_pager_generic_...)? Thanks, -A. -- Aaron J. Marks Communications and Computing Systems Lab Assoc. Member Tech Staff Advanced Networks and Computation Group amarks@sarnoff.com Sarnoff Corporation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:30:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 01CB5112EA; Wed, 17 Feb 1999 10:30:04 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA07135; Wed, 17 Feb 1999 11:29:58 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd007112; Wed Feb 17 11:29:55 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA19473; Wed, 17 Feb 1999 11:29:53 -0700 (MST) From: Terry Lambert Message-Id: <199902171829.LAA19473@usr07.primenet.com> Subject: Re: gdb sucks - and I need to get around it. help? To: grog@lemis.com (Greg Lehey) Date: Wed, 17 Feb 1999 18:29:53 +0000 (GMT) Cc: tlambert@primenet.com, eivind@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <19990217133032.A515@lemis.com> from "Greg Lehey" at Feb 17, 99 01:30:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> Anybody know of any way of getting gdb to step from the start of the > >> program? > >> > >> I have an executable with absolutely no symbol data (symbol data is > >> absolutely non-available) which I *have* to get to step through, if > >> necessary by re-implementing gdb. > > > > One really snotty way to do it is to write a small program that > > exec's the other program, and follow it through the exec. I've used > > this technique to work on ld.so before. > > Does this work on ELF executables? I haven't tried it since my machine at work was switched, some time after 3.0 became a little more stable and started putting the a.out libraries and ld.so in the correct place (weeks after -RELEASE). I rarely use source debuggers, preferring printf's and a deep understanding of whatever code I'm hacking on. It's a prejudice I carry from my VMS days, when the source level debugger linked into the image, expanded the image space, and made the program stop failing, more often than not; I haven't really trusted the damn things since. I actually *prefer* post-morteming core files, and instrumenting the code such that I know what's going wrong. I occasionally use the Microsoft source level debugger (I have to admit that getting the contents of variables as a tool-tip, merely by leaving the mouse pointer over them for a second is pretty damn cool), but like the VMS debugger (and, frequently, gdb), you have to remember what was happening right before everything went to hell, and then step through it and stop just before it happens again. Frankly, source level debuggers just take too frigging long to do the job. I can edit in 10 DPRINTF(("HERE #1\n"));'s recompile, run, see "HERE #6", edit in another 10 DPRINTF(("HERE #6.1\n"));'s, and be done before I could step through once, let alone twice. Maybe if someone invents a debugger that can replay the last 10 steps, and the last 10 control breaks, e.g., the last 10 for loop iterations, and the entry conditions into the for loop, the while loop before it, the function call they're in, etc.. It'd be a lot of state to hold onto, but it would make the thing at least minimally usable. Assuming it's not Windows, of course; if you BSOD, you'll have a hell of a time replaying anything. 8-(. Are you listening, xgdb or ups? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:39:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7F05511373 for ; Wed, 17 Feb 1999 10:39:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA09129; Wed, 17 Feb 1999 10:38:16 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 10:38:16 -0800 (PST) From: Matthew Dillon Message-Id: <199902171838.KAA09129@apollo.backplane.com> To: "AARON MARKS" Cc: Terry Lambert , freebsd-hackers@FreeBSD.ORG Subject: Re: Memory-Based VFS Question References: <199902162316.QAA09873@usr08.primenet.com> <36CB0903.B309BC62@sarnoff.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Terry Lambert wrote: :> :> :> It will use VOP_GETPAGES/VOP_PUTPAGES. : :Since the man page is not very instructive for these ops and I'm new to :the FreeBSD kernel, is there a particular source that I can model these :after? Should I just model after the generic functions :(vnode_pager_generic_...)? : :Thanks, :-A. : :-- :Aaron J. Marks Communications and Computing Systems Lab :Assoc. Member Tech Staff Advanced Networks and Computation Group :amarks@sarnoff.com Sarnoff Corporation I would simply use the vnode_pager_generic_putpages/getpages() routines to begin with. Once you have everything working you can optimize it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:39:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id C826811379 for ; Wed, 17 Feb 1999 10:39:13 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA03409; Wed, 17 Feb 1999 11:38:58 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd003290; Wed Feb 17 11:38:41 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA20158; Wed, 17 Feb 1999 11:38:39 -0700 (MST) From: Terry Lambert Message-Id: <199902171838.LAA20158@usr07.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Wed, 17 Feb 1999 18:38:39 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902170307.WAA27574@y.dyson.net> from "John S. Dyson" at Feb 16, 99 10:07:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The thing that appalled me was what you said about BSS being zero'ed > > in the kernel space using zeroed pages instead of as a result of an > > explicit zeroing by the execution class loader. > > That is the way that it works. Explict zeroing is wasteful because > it cannot easily take advantage of background prezeroing... However, > recently prezeroed pages make for efficient usage of cache. The zero > queue (and all others) are designed to take advantage of recent cache > usage. This is robbing Peter to pay Paul; in a way. The base assumption that you are hiding is that you aren't constrained by memory bandwidth. This isn't true if you are nearly saturating a PCI bus with 4 BT848's (to pick the highest memory bandwidth application I know about). Maybe we need to go back to first principles, and examine the assumptions about what constraints are in effect under various usage models, and make trades like these optional instead of mandatory. I think that's all he wants, anyway. In any case, it's always interesting when someone uses code in an unexpected way. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:42:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id B91B311324 for ; Wed, 17 Feb 1999 10:42:47 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10DBtM-000I33C; Wed, 17 Feb 1999 13:40:12 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: PPP Problem In-Reply-To: <199902170743.HAA37802@keep.lan.Awfulhak.org> from Brian Somers at "Feb 17, 1999 7:43:38 am" To: brian@Awfulhak.org (Brian Somers) Date: Wed, 17 Feb 1999 13:40:12 -0500 (EST) Cc: tom@tomqnx.com, hackers@freebsd.org, brian@awfulhak.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM919276812-541-0_ Content-Transfer-Encoding: 7bit Content-Length: 4660 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM919276812-541-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have not been able to duplicate the behaviour- perhaps that is true. BUT there are several things I find do not work properly when using ppp over TCP. Perhaps you could set me straight, but... 1) I would expect that with enable lqr and accept lqr, if the other side disappears (no response to 5 polls) I would expect the tunX connection to be torn down, and ppp.linkdown processed, and the ppp job to terminate. NONE of this seems to happen. 2) "ppp -direct loop-in" ignores a "kill -TERM xxx". This does not seem correct. How can ppp.linkdown ever be processed? 3) Granted that you can compensate in the routing table, the netmask configuration for the tunnel device seems incorrect. It is always set to the default for the IP. I would expect that if a netmask is supplied in the "set ifaddr" command, that would be used in setting up the tunnel configuration. 4) After a connection is set up, the named running on the client starts to cough: named: bind(dfd=24, [10.0.1.1].53): Permission denied named: deleting interface [10.0.1.1].53 This seems to be a harmless peculiarity of the new bind (The old one on the server doesn't do it) that I could eliminate by defining the IPs in my zone (or live with it). 5) Pinging the host side of the tunnel takes 5 times as long as when I ping an ethernet interface. Setting up a route for that IP to 127.0.0.1 fixes this. Would it not be a good idea for ppp to set this up automatically? Would you be kind enough to set me straight where required on the above? The docs are full of helpful hints/examples, but a tad short on specification as to how it "should" work:-) Regards, Tom > You must have a ``delete 0'' (same as ``delete 0.0.0.0'' or ``delete > default'') somewhere. > > > Running 2.2-stable with user-ppp. > > > > I set up a test PPP link, tunneling PPP over TCP. > > I do not run routed or gated. The PPP server (-direct) is located > > on my LAN gateway machine, which has my ISPs router > > defined as its gateway. There are no definitions in > > ppp.conf, ppp.linkup or ppp.linkdown that refer in any > > way to the 0.0.0.0/0 default definition. > > > > The client machine does have 0.0.0.0 as the 4th parameter to > > its set ifaddr command, which may contribute to the symptoms > > in some way. I'll try removing that next... > > > > Shortly after or when the link is made, the ppp program removes > > the default definition from the server's routing tables. So far > > I tried removing all references to HISADDR, MYADDR and disabling > > sroutes - nothing helped. > > > > Regards, > > Tom > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.conf Content-Description: ppp.conf Content-Transfer-Encoding: base64 ZGVmYXVsdDoNCglzZXQgdGltZW91dCAwDQoJc2V0IGxxcnBlcmlvZCAxMA0KCXNldCBsb2cgUGhh c2UgQ2hhdCBDb25uZWN0IExDUCBJUENQIENvbW1hbmQNCglkaXNhYmxlIHNyb3V0ZXMNCgllbmFi bGUgbHFyDQoJYWNjZXB0IGxxcg0KDQpsb29wOg0KCXNldCBkZXZpY2UgbWFpbHg6cHBwbG9vcA0K CXNldCBkaWFsDQoJc2V0IGxvZ2luDQoJc2V0IGF1dGhuYW1lIHh4eHgNCglzZXQgYXV0aGtleSB5 eXl5eQ0KCXNldCBpZmFkZHIgMTAuMC4xLjEvMjQgMTAuMC4xLjIvMjQgMjU1LjI1NS4yNTUuMCAw LjAuMC4wDQoNCmxvb3AtaW46DQoJZW5hYmxlIGNoYXANCglhbGxvdyBtb2RlIGRpcmVjdA0KCXNl dCBpZmFkZHIgMTAuMC4xLjIgMTAuMC4xLjEgMjU1LjI1NS4yNTUuMCANCglzZXQgc2VydmVyIC92 YXIvdG1wL3BhdGJzZCAiIiAwMTc3DQoNCmRpYWwtaW46DQoJZW5hYmxlIGNoYXANCglhbGxvdyBt b2RlIGRpcmVjdA0KCXNldCBpZmFkZHIgMTAuMC4yLjIgMTAuMC4yLjEgMjU1LjI1NS4yNTUuMA0K CXNldCBzZXJ2ZXIgL3Zhci90bXAvZGlhbHBwcCAiIiAwMTc3DQoNCnNsb29wOg0KCWxvYWQgbG9v cA0KCXNldCBkZXZpY2UgIS9ldGMvcHBwL3NlY3VyZQ0KDQoNCg0K --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.linkup Content-Description: ppp.linkup Content-Transfer-Encoding: 7bit 10.0.1.1: add 10.0.1.0/24 10.0.1.2 # add 205.150.43.0/24 10.0.1.2 10.0.1.2: add 10.0.1.0/24 10.0.1.1 add 159.249.0.0/16 10.0.1.1 10.0.2.1: add 10.0.2.0/24 10.0.2.2 add 205.150.43.0/24 10.0.2.2 10.0.2.2: add 10.0.2.0/24 10.0.2.1 --ELM919276812-541-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=ppp.linkdown Content-Description: ppp.linkdown Content-Transfer-Encoding: 7bit 10.0.2.1: # delete 205.150.43.0/24 10.0.1.2: delete 10.0.1.0/24 delete 159.249.0.0/16 10.0.2.1: delete 10.0.2.0/24 # delete 205.150.43.0/24 10.0.2.2: delete 10.0.2.0/24 --ELM919276812-541-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:43:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 4000D113A5 for ; Wed, 17 Feb 1999 10:43:48 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA11783; Wed, 17 Feb 1999 11:43:48 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd011583; Wed Feb 17 11:43:38 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA20466; Wed, 17 Feb 1999 11:43:16 -0700 (MST) From: Terry Lambert Message-Id: <199902171843.LAA20466@usr07.primenet.com> Subject: Re: vm_page_zero_fill To: jas@flyingfox.com (Jim Shankland) Date: Wed, 17 Feb 1999 18:43:15 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199902170625.WAA25521@biggusdiskus.flyingfox.com> from "Jim Shankland" at Feb 16, 99 10:25:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [Terry:] > > Expecting sbrk'ed pages to be zero filled is just *wrong*. > > [John Dyson:] > > Actually, you have to support that on most practical architectures. > > Architectures aside, the *semantics* have always been that newly > sbrk-ed pages are zero-filled. It's been that way since at least > v7. > > I went and looked for chapter and verse on this in the sbrk(2) > man page, and was astonished not to find it. The Solaris > man page mentions it, though, and I'll bet man page archaeologists > can verify my assertion that this goes way, way back. > > Expecting to be able to get away with *not* zero=filling newly > sbrk'ed pages is just *wrong*. It's a security mechanism. Read the old Bell Technical Journal (it has been reprinted tons of times). In general, you are not supposed to program as if you know the implementation details of malloc(). As David Wolfskill pointed out in an aside, AIX initializes sbrk'ed pages to 0xdeadbeef. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:44:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 1DD5A113A9 for ; Wed, 17 Feb 1999 10:44:22 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 3461 invoked from network); 17 Feb 1999 18:44:18 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 18:44:18 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id NAA69882; Wed, 17 Feb 1999 13:44:19 -0500 (EST) Message-Id: <199902171844.NAA69882@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171838.LAA20158@usr07.primenet.com> from Terry Lambert at "Feb 17, 99 06:38:39 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 17 Feb 1999 13:44:19 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > The thing that appalled me was what you said about BSS being zero'ed > > > in the kernel space using zeroed pages instead of as a result of an > > > explicit zeroing by the execution class loader. > > > > That is the way that it works. Explict zeroing is wasteful because > > it cannot easily take advantage of background prezeroing... However, > > recently prezeroed pages make for efficient usage of cache. The zero > > queue (and all others) are designed to take advantage of recent cache > > usage. > > This is robbing Peter to pay Paul; in a way. The base assumption > that you are hiding is that you aren't constrained by memory > bandwidth. This isn't true if you are nearly saturating a PCI > bus with 4 BT848's (to pick the highest memory bandwidth application > I know about). > Prezeroing doesn't take any significant CPU if there are no cycles available. It does increase latency slightly, if zeroing is allowed to happen. > > Maybe we need to go back to first principles, and examine the > assumptions about what constraints are in effect under various > usage models, and make trades like these optional instead of > mandatory. I think that's all he wants, anyway. > The prezeroing isn't adding any cost to him, the ability to support returning non-initialized data from the kernel would be useful. In that case, turning off prezeroing *might* help (but probably won't.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:44:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from stephens.ml.org (cm2081634025.ponderosa.ispchannel.com [208.163.40.25]) by hub.freebsd.org (Postfix) with ESMTP id D0F70113CE for ; Wed, 17 Feb 1999 10:44:39 -0800 (PST) (envelope-from tas@stephens.ml.org) Received: from stephens.ml.org (localhost.loc [127.0.0.1] (may be forged)) by stephens.ml.org (8.9.1/8.9.1) with ESMTP id SAA24903; Wed, 17 Feb 1999 18:44:38 GMT (envelope-from tas@stephens.ml.org) Message-Id: <199902171844.SAA24903@stephens.ml.org> To: freebsd-hackers@FreeBSD.ORG Cc: Thomas Stephens From: Thomas Stephens Subject: ELF, System V and multiple ABIs Date: Wed, 17 Feb 1999 10:44:38 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently noticed a potential ELF issue, and didn't find any references to it in the FreeBSD list archives, so am bringing it up here. I was looking over the latest System V ABI draft, and noticed there is an update (dated April 1998) which includes modifications to the ELF format. Significantly, the usage of the e_ident array in the ElfXX_Ehdr structure has changed slightly, in order to allow for multiple ABIs on each hardware platform. While the ELF format defined in the previous draft only used the first seven bytes of e_ident, with byte eight (EI_PAD) representing the start of padding, the current one adds two new values to support an OS/ABI identifier number followed by a version. As a side-effect, EI_PAD has been redefined: EI_OSABI 7 (OS/ABI identifier) EI_ABIVERSION 8 (OS/ABI version) EI_PAD 9 This new version of ELF currently defines EI_OSABI values for System V, HP-UX and stand-alone (embedded) applications, but it seems to me it would make things much easier if all ELF-compatible systems were to adopt it. The URL for the System V spec update is: http://www.sco.com/developer/gabi/contents.html One way or the other, this change means SCO binaries will be incompatible with FreeBSD's branding scheme. Assuming a move to IA-64, it would also affect potential compatibility with HP and IBM binaries. I'd be interested in any comments with regard to adopting this change in FreeBSD, as well as an idea the likelihood of Linux, NetBSD, etc. adopting it. Thomas Stephens tas@stephens.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:51:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id E5140113E6 for ; Wed, 17 Feb 1999 10:51:13 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA14782; Wed, 17 Feb 1999 11:51:13 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd014542; Wed Feb 17 11:50:57 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA21086; Wed, 17 Feb 1999 11:50:37 -0700 (MST) From: Terry Lambert Message-Id: <199902171850.LAA21086@usr07.primenet.com> Subject: Re: getpwnam and getpwnam_r To: wes@softweyr.com (Wes Peters) Date: Wed, 17 Feb 1999 18:50:36 +0000 (GMT) Cc: dave@jetcafe.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <36CA6F15.58EB82DF@softweyr.com> from "Wes Peters" at Feb 17, 99 00:26:13 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Where are the thread-safe, reentrant versions of this routine in > > FreeBSD 3.1? No additions to the list (I'm too tight for time to look at my CDROM at the moment). The routines getpwnam, getspnam are problematic, in general. A number of the cron-triggered VM bugs have to do with the dbm routines mmap'ping the password database (COW), and cron modifying the contents of the fields, as if they were static buffers in libc. It seems to me that the use of a static structure with pointers to the relevent "return data" will be problematic for threads based, reentrant versions of these routines. I am loathe to suggest TLS (thread local storage) as a soloution, since it could easily interfere with marshalling data between kernel threads (as it does on Windows 95/98/NT) due to it being outside the common address space as an implementation detail. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 10:59:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 4EC6A113CE for ; Wed, 17 Feb 1999 10:59:27 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA12237; Wed, 17 Feb 1999 11:59:17 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd012005; Wed Feb 17 11:59:03 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA21748; Wed, 17 Feb 1999 11:58:40 -0700 (MST) From: Terry Lambert Message-Id: <199902171858.LAA21748@usr07.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Wed, 17 Feb 1999 18:58:38 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902171844.NAA69882@y.dyson.net> from "John S. Dyson" at Feb 17, 99 01:44:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is robbing Peter to pay Paul; in a way. The base assumption > > that you are hiding is that you aren't constrained by memory > > bandwidth. This isn't true if you are nearly saturating a PCI > > bus with 4 BT848's (to pick the highest memory bandwidth application > > I know about). > > Prezeroing doesn't take any significant CPU if there are no cycles > available. It does increase latency slightly, if zeroing is allowed > to happen. He's strapped on memory bandwidth, not CPU cycles. He's willing to eat zeroing on in those cases where he has no choice because it impacts base functionality. > > Maybe we need to go back to first principles, and examine the > > assumptions about what constraints are in effect under various > > usage models, and make trades like these optional instead of > > mandatory. I think that's all he wants, anyway. > > The prezeroing isn't adding any cost to him, the ability to support > returning non-initialized data from the kernel would be useful. In > that case, turning off prezeroing *might* help (but probably won't.) Again, he's wanting to reclaim memory bandwidth from the prezeroing of pages that are prezeroed not because they need to be, but for security reasons that he doesn't care about. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11: 3:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 857B2114D4 for ; Wed, 17 Feb 1999 11:03:33 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id NAA25290; Wed, 17 Feb 1999 13:02:28 -0600 (CST) From: Kevin Day Message-Id: <199902171902.NAA25290@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171844.NAA69882@y.dyson.net> from "John S. Dyson" at "Feb 17, 1999 1:44:19 pm" To: dyson@iquest.net Date: Wed, 17 Feb 1999 13:02:27 -0600 (CST) Cc: tlambert@primenet.com, dyson@iquest.net, mike@smith.net.au, hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is robbing Peter to pay Paul; in a way. The base assumption > > that you are hiding is that you aren't constrained by memory > > bandwidth. This isn't true if you are nearly saturating a PCI > > bus with 4 BT848's (to pick the highest memory bandwidth application > > I know about). > > > Prezeroing doesn't take any significant CPU if there are no cycles > available. It does increase latency slightly, if zeroing is allowed > to happen. > > > > > Maybe we need to go back to first principles, and examine the > > assumptions about what constraints are in effect under various > > usage models, and make trades like these optional instead of > > mandatory. I think that's all he wants, anyway. > > > The prezeroing isn't adding any cost to him, the ability to support > returning non-initialized data from the kernel would be useful. In > that case, turning off prezeroing *might* help (but probably won't.) > I'm kinda surprised at the traffic my post generated, but I'm being bound by secrecy restraints to say much more than what I can here. I do really appreciate the help you're giving me though... The system I'm working on is a embedded, highly graphical 2D/3D product. These systems will not be connected to the internet, nor will anyone have keyboard/telnet/terminal/whatever access to them. They're about as secure as they're going to get, so my concerns are mostly speed over security. In looking with some logic analyzers, we're seeing that we're nearly out of PCI bandwidth, and we're hitting the memory very hard too. 99% of our run time is spent ferrying data from ram into the graphic device. Because of the nature of the product, we're needing more and more 'real-time' like operation. The delay from when a user does something, until he/she sees it on the screen is critical, as well as being able to handle many input devices, and radically change the scheduler's behavior when something 'interesting' comes in. (My current kludge for really really important data that must flow between a few processes quickly is mucking with rtprio, which is working, but I'd prefer to have much more control over the scheduler). After things still being slower than I wanted, I pulled out a logic analyzer. In watching memory accesses on the analyzer, we saw a lot of zeroing going on, especially after exec()'ing another application. (This system has one supervisory process, that will start any one of 20ish other applications, in response to what the user wants to do). Currently, the time spent loading/preparing the new application is a bit long, so I was looking at ways to shrink that down. That's where this discussion came from. While I don't want to get accused of not trying to figure this one out on my own.... Suppose I mmap a large (2MB or more) file. Should any zero'ing be going on when I touch those pages for the first time? From the analyzer, it looks like it's zeroing pages before putting what it read from the disk into them, but as you know, figuring out what's really going on by watching a logic analyzer is a form of witchcraft... If this is the case, turning this off would greatly help me. :) (If I'm not being clear enough, imagine mmap'ing a movie, and memcpy'ing it into a frame buffer at 60fps, to get an idea of the kind of data I'm going through) I hope this sort of explained my application, although I'm sure there are arguments either way if this is really going to help me or not. Thanks again, Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11: 9: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id EE1CF114CB for ; Wed, 17 Feb 1999 11:09:05 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA16503; Wed, 17 Feb 1999 12:09:05 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd016224; Wed Feb 17 12:08:42 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id MAA22366; Wed, 17 Feb 1999 12:08:25 -0700 (MST) From: Terry Lambert Message-Id: <199902171908.MAA22366@usr07.primenet.com> Subject: Re: Memory-Based VFS Question To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 17 Feb 1999 19:08:25 +0000 (GMT) Cc: amarks@sarnoff.com, tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902171838.KAA09129@apollo.backplane.com> from "Matthew Dillon" at Feb 17, 99 10:38:16 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> It will use VOP_GETPAGES/VOP_PUTPAGES. > : > :Since the man page is not very instructive for these ops and I'm new to > :the FreeBSD kernel, is there a particular source that I can model these > :after? Should I just model after the generic functions > :(vnode_pager_generic_...)? > > I would simply use the vnode_pager_generic_putpages/getpages() routines > to begin with. Once you have everything working you can optimize it. The generic code assumes a vnode as a backing store. If he does not have a vnode as a backing store, he can not use the generic code. Basically, if he could use it, since that's the default that's inherited from the default ops vector, it'd already be working, and he wouldn't be asking the question. He's asking, so ipso facto, he's not using a vnode as backing store. This makes sense, since he said he's writing a new MFS; he's probably managing the page allocation himself from the KVA space. To answer the question: pattern your code after the code in the file /sys/vm/device_pager.c's dev_pager_getpages()/dev_pager_putpages() code, and you should be OK. Matt was talking about creating vm_object_t aliases. This would actually be a place where they would be applicable, if the intent was to halve the page mapping/unmapping code path for an MFS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:10:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from midten.fast.no (midten.fast.no [195.139.251.11]) by hub.freebsd.org (Postfix) with ESMTP id E4831112DD for ; Wed, 17 Feb 1999 11:10:43 -0800 (PST) (envelope-from tegge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [195.139.251.11]) by midten.fast.no (8.9.1/8.9.1) with ESMTP id UAA17721; Wed, 17 Feb 1999 20:10:38 +0100 (CET) Message-Id: <199902171910.UAA17721@midten.fast.no> To: dillon@apollo.backplane.com Cc: hackers@freebsd.org Subject: Re: Problems in VM structure ? From: Tor.Egge@fast.no In-Reply-To: Your message of "Wed, 17 Feb 1999 09:44:28 -0800 (PST)" References: <199902171744.JAA06913@apollo.backplane.com> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 Feb 1999 20:10:38 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, so if we have 512MB of main memory and maxusers set to 256. > > NMBCLUSTRS = 4608 > NSFBUFS = 4608 > NPROC = 4116 > MAXFILES = 8232 > > ( MCLBYTES = 2048 ) > > mem_size is 512MB > vm_kmem_size = VM_KMEM_SIZE_MAX ( 80 MB ) > > kmem_map is 2.3 + 9.4 + 80 = around 90 MB. > clean_map is 68MB + 4.1MB + 8.3MB = around 80 MB > exec_map is 1.2MB > > So the total KVM allocated is 170MB. not# sysctl vm.zone vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 30, 72, 3385 SWAPMETA: 160, 257216, 0, 0, 0 unpcb: 64, 0, 16, 112, 271 ripcb: 96, 12288, 0, 84, 7 divcb: 96, 12288, 0, 0, 0 tcpcb: 288, 12288, 62, 36, 858 udpcb: 96, 12288, 15, 69, 593 unpcb: 64, 0, 0, 0, 0 socket: 192, 12288, 94, 53, 1736 AIOLIO: 704, 0, 0, 0, 0 AIOL: 64, 0, 0, 0, 0 AIOCB: 128, 0, 0, 0, 0 AIOP: 32, 0, 0, 0, 0 AIO: 96, 0, 0, 0, 0 NFSNODE: 288, 0, 235, 689, 3247 NFSMOUNT: 544, 0, 2, 12, 0 VNODE: 192, 0, 40258, 22, 39878 NAMEI: 1024, 0, 0, 16, 2336773 VMSPACE: 224, 0, 74, 34, 4169 PROC: 352, 0, 77, 39, 4172 DP fakepg: 64, 0, 6, 122, 5 PV ENTRY: 28, 1085214, 34500, 96507, 2058072 MAP ENTRY: 40, 0, 1754, 312, 1383328 KMAP ENTRY: 40, 32280, 139, 193, 6824 MAP: 100, 0, 7, 3, 7 VM OBJECT: 116, 0, 29465, 1871, 126952 All zones with ZONE_INTERRUPT flag has preallocated KVA and a nonzero max. --> 78 MB. SMP --> 4 MB per processor private kva last page dir entry reserved for alternate page table --> 4 MB Kernel text + data + bss --> 1.5 MB 78 MB + 4 MB + 4 MB + 1.5 MB + 170 MB --> 257.5 MB When looking at current kernel_map on a 512 MB SMP machine with maxusers set to 256, VM_KMEM_SIZE and VM_KMEM_SIZE_MAX set to 128 MB and NMBCLUSTERS set to 12288: (kgdb) print kernel_map->size $1 = 334737408 - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:27:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 5CF451114F for ; Wed, 17 Feb 1999 11:27:47 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 11208 invoked from network); 17 Feb 1999 19:27:34 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 19:27:34 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA69946; Wed, 17 Feb 1999 14:27:28 -0500 (EST) Message-Id: <199902171927.OAA69946@y.dyson.net> Subject: Re: Problems in VM structure ? In-Reply-To: <199902171910.UAA17721@midten.fast.no> from "Tor.Egge@fast.no" at "Feb 17, 99 08:10:38 pm" To: Tor.Egge@fast.no Date: Wed, 17 Feb 1999 14:27:28 -0500 (EST) Cc: dillon@apollo.backplane.com, hackers@freebsd.org From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tor.Egge@fast.no said: > > All zones with ZONE_INTERRUPT flag has preallocated KVA > and a nonzero max. --> 78 MB. > > SMP --> 4 MB per processor private kva > last page dir entry reserved for alternate page table --> 4 MB > Kernel text + data + bss --> 1.5 MB > > 78 MB + 4 MB + 4 MB + 1.5 MB + 170 MB --> 257.5 MB > > When looking at current kernel_map on a 512 MB SMP machine with > maxusers set to 256, VM_KMEM_SIZE and VM_KMEM_SIZE_MAX set to > 128 MB and NMBCLUSTERS set to 12288: > > (kgdb) print kernel_map->size > $1 = 334737408 > That is dangerously low. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:30:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (Postfix) with ESMTP id C996F1136E; Wed, 17 Feb 1999 11:30:41 -0800 (PST) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id OAA17995; Wed, 17 Feb 1999 14:31:20 -0500 (EST) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.1/8.8.5) with ESMTP id OAA11772; Wed, 17 Feb 1999 14:29:38 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.9.1/8.6.9) id OAA13214; Wed, 17 Feb 1999 14:29:50 -0500 (EST) Date: Wed, 17 Feb 1999 14:29:50 -0500 (EST) From: Thomas David Rivers Message-Id: <199902171929.OAA13214@lakes.dignus.com> To: grog@lemis.com, tlambert@primenet.com Subject: Re: gdb sucks - and I need to get around it. help? Cc: eivind@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199902171829.LAA19473@usr07.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Maybe if someone invents a debugger that can replay the last 10 > steps, and the last 10 control breaks, e.g., the last 10 for > loop iterations, and the entry conditions into the for loop, the > while loop before it, the function call they're in, etc.. It'd > be a lot of state to hold onto, but it would make the thing at > least minimally usable. Assuming it's not Windows, of course; if > you BSOD, you'll have a hell of a time replaying anything. 8-(. > > Are you listening, xgdb or ups? > > > Terry Lambert > terry@lambert.org Just F.Y.I. - the Tachyon mainframe emulator's debugger does something like this (see http://www.tachyonsoft.com/tachyon). It's not exactly germain to this discussion, but I thought I'd hold it up as an example... - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:31:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9C65B1159B for ; Wed, 17 Feb 1999 11:31:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA10322; Wed, 17 Feb 1999 11:31:12 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 11:31:12 -0800 (PST) From: Matthew Dillon Message-Id: <199902171931.LAA10322@apollo.backplane.com> To: Tor.Egge@fast.no Cc: hackers@FreeBSD.ORG Subject: Re: Problems in VM structure ? References: <199902171744.JAA06913@apollo.backplane.com> <199902171910.UAA17721@midten.fast.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :All zones with ZONE_INTERRUPT flag has preallocated KVA :and a nonzero max. --> 78 MB. : :SMP --> 4 MB per processor private kva :last page dir entry reserved for alternate page table --> 4 MB :Kernel text + data + bss --> 1.5 MB : : 78 MB + 4 MB + 4 MB + 1.5 MB + 170 MB --> 257.5 MB : :When looking at current kernel_map on a 512 MB SMP machine with :maxusers set to 256, VM_KMEM_SIZE and VM_KMEM_SIZE_MAX set to :128 MB and NMBCLUSTERS set to 12288: : : (kgdb) print kernel_map->size : $1 = 334737408 : :- Tor Egge Ach. So why isn't it panicing on boot? Why does the machine destabilize and die later on with all sorts of problems? Is it trying to use more page table entries then were allocated for the kernel_map? Is the submap allocator broken? Is there some test we can add to panic the machine at boot time if KVM is over-reserved? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:31:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id AFC8A115B0 for ; Wed, 17 Feb 1999 11:31:31 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 14966 invoked from network); 17 Feb 1999 19:31:29 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 19:31:29 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA69956; Wed, 17 Feb 1999 14:31:28 -0500 (EST) Message-Id: <199902171931.OAA69956@y.dyson.net> Subject: Re: savecore before swapon? In-Reply-To: <19990217142628.F69668@bitbox.follo.net> from Eivind Eklund at "Feb 17, 99 02:26:28 pm" To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Wed, 17 Feb 1999 14:31:28 -0500 (EST) Cc: brandon@roguetrader.com, freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund said: > On Tue, Feb 16, 1999 at 08:26:00AM -0700, Brandon Gillespie wrote: > > I havn't checked the source, but from my understanding shouldn't > > savecore be run before swapon is run, incase the swap device is the > > dump device? Or to look at it another way, when swapon is run on a > > swap device, does it look first to see if there is a dump in it, and > > if so what does it do? Right now we run swapon, then considerably > > later we run savecore. Assuming swapon just trashes whatever was in > > that device, running savecore is pretty much irrelevant, as most > > people I know (not necessarily in FreeBSD) use their swap device as a > > dump point. > > This is done intentionally, as fsck may in some cases require swap > to be able to fsck large filesystems. > > It would make sense to have a sysctl > 'only_swap_as_absolutely_last_resort_not_for_performance' AKA > 'do_linux_swapping_scheme' which was set before the swapon, and unset > after the crashdump. I don't know how to implement this. (It might > be that one of the present sysctls does something like this - I've not > checked). > sysctl -w vm.defer_swapspace_pageouts=1 It will still page nicely, but performance will be less when under memory load, because of less memory being available. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:46:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by hub.freebsd.org (Postfix) with ESMTP id 2D66D113A5 for ; Wed, 17 Feb 1999 11:45:24 -0800 (PST) (envelope-from amarks@sarnoff.com) Received: from sarnoff.com ([130.33.14.232]) by postoffice.sarnoff.com (Netscape Messaging Server 3.5) with ESMTP id AAA42B0; Wed, 17 Feb 1999 14:45:22 -0500 Message-ID: <36CB1C9B.77725962@sarnoff.com> Date: Wed, 17 Feb 1999 14:46:35 -0500 From: "AARON MARKS" Reply-To: amarks@sarnoff.com Organization: Sarnoff Corporation X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Cc: Matthew Dillon Subject: Re: Memory-Based VFS Question References: <199902171908.MAA22366@usr07.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I appologize for the ignorance, but: Terry Lambert wrote: > > The generic code assumes a vnode as a backing store. If he does not > have a vnode as a backing store, he can not use the generic code. What do you mean using a vnode as a backing store? A file in my MFS has a vnode allocated to it. > > Basically, if he could use it, since that's the default that's > inherited from the default ops vector, it'd already be working, > and he wouldn't be asking the question. > > He's asking, so ipso facto, he's not using a vnode as backing store. > > This makes sense, since he said he's writing a new MFS; he's probably > managing the page allocation himself from the KVA space. I think so. I allocate blocks of 8k memory and grow as necessary. > > To answer the question: pattern your code after the code in the file > /sys/vm/device_pager.c's dev_pager_getpages()/dev_pager_putpages() > code, and you should be OK. Great. I'll take a look-see. I have another question, though: I mapped my _{get,put}pages functions (they're empty, just print to console and return 0) to the vop functions but when I do a system file copy (via cp), the OS never calls my {get,put}pages functions. Thanks again, -A. -- Aaron J. Marks Communications and Computing Systems Lab Assoc. Member Tech Staff Advanced Networks and Computation Group amarks@sarnoff.com Sarnoff Corporation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 11:53:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 723F51161A for ; Wed, 17 Feb 1999 11:51:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA10456; Wed, 17 Feb 1999 11:51:18 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 11:51:18 -0800 (PST) From: Matthew Dillon Message-Id: <199902171951.LAA10456@apollo.backplane.com> To: Kevin Day Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: <199902171902.NAA25290@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The system I'm working on is a embedded, highly graphical 2D/3D product. :These systems will not be connected to the internet, nor will anyone have :keyboard/telnet/terminal/whatever access to them. They're about as secure as :they're going to get, so my concerns are mostly speed over security. : :In looking with some logic analyzers, we're seeing that we're nearly out of :PCI bandwidth, and we're hitting the memory very hard too. 99% of our run :time is spent ferrying data from ram into the graphic device. : :Because of the nature of the product, we're needing more and more :'real-time' like operation. The delay from when a user does something, until :... : :After things still being slower than I wanted, I pulled out a logic :analyzer. In watching memory accesses on the analyzer, we saw a lot of :zeroing going on, especially after exec()'ing another application. (This :... : :Currently, the time spent loading/preparing the new application is a bit :long, so I was looking at ways to shrink that down. That's where this Ahh. A couple of things. First, I presume that the amount of memory in the machine is not an issue... that you have enough to hold all the programs pretty much resident. In that case, simply preload the executables. That is, rather then take the latency hit when the user hits a button, take the latency hit when the user is idle and just tell the program to 'go' ( through a pipe ) when the user hits the button. Second, if you aren't already using a Xeon with its largest L2 cache configuration, you should probably be using a Xeon with its largest L2 cache configuration. Intel cpu's tend to fall on their face with DATA-memory-intensive applications due to their undersized caches. The undersized cache works ok for instructions because instructions are pretty compact, but it does not work well for data. If the box you are using does not have a 100MHz memory bus, you need to get one that does. :While I don't want to get accused of not trying to figure this one out on my :own.... Suppose I mmap a large (2MB or more) file. Should any zero'ing be :going on when I touch those pages for the first time? From the analyzer, it :looks like it's zeroing pages before putting what it read from the disk into :them, but as you know, figuring out what's really going on by watching a :logic analyzer is a form of witchcraft... If this is the case, turning this :off would greatly help me. :) It should not be zeroing pages before doing full reads into them. That is pretty well optimized, usually. Third, Memory->PCI transfers are best done with DMA ( as you already know ). For a frame store, you can eek out additiona l PCI bus speed by messing with the burst transfer length ( especially if the cpu is not heavily involved and can afford to stall a little more ). You should be able to push 120 MBytes/sec on a PCI bus by tuning the DMA burst. The PCI card should have a FIFO big enough to accomodate the burst, too. If you do a large transfer to a PCI card's frame buffer with memcpy() ( or equivalent ), you eat double the memory bandwidth plus blow away the data cache on the cpu. Fourth, if you are doing direct frame store from disk to a PCI card, you may wish to consider building a custom piece of hardware / firmware to actually use the SCSI bus to transfer the data directly ( i.e. put the frame store *on* the SCSI bus and have it master the data directly from the drives without host intervention ). This is a rather more complex solution. Fifth - double-wide (64 bit wide) PCI busses or AGP busses. AGP can certainly be done on a PC. I'm not sure what is available in regards to 64 bit PCI busses. However, both these options are departures from the norm and may not be cost effective. -Matt Matthew Dillon :(If I'm not being clear enough, imagine mmap'ing a movie, and memcpy'ing it :into a frame buffer at 60fps, to get an idea of the kind of data I'm going :through) : :I hope this sort of explained my application, although I'm sure there are :arguments either way if this is really going to help me or not. : :Thanks again, : :Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12: 3:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id F1BA010EAD for ; Wed, 17 Feb 1999 12:03:36 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 13504 invoked from network); 17 Feb 1999 20:03:34 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 20:03:34 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA70095; Wed, 17 Feb 1999 15:03:34 -0500 (EST) Message-Id: <199902172003.PAA70095@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171858.LAA21748@usr07.primenet.com> from Terry Lambert at "Feb 17, 99 06:58:38 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 17 Feb 1999 15:03:34 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > This is robbing Peter to pay Paul; in a way. The base assumption > > > that you are hiding is that you aren't constrained by memory > > > bandwidth. This isn't true if you are nearly saturating a PCI > > > bus with 4 BT848's (to pick the highest memory bandwidth application > > > I know about). > > > > Prezeroing doesn't take any significant CPU if there are no cycles > > available. It does increase latency slightly, if zeroing is allowed > > to happen. > > He's strapped on memory bandwidth, not CPU cycles. He's willing to > eat zeroing on in those cases where he has no choice because it > impacts base functionality. > If zeroing isn't allowed to happen, then there'll be no additional bandwidth used. > > > > The prezeroing isn't adding any cost to him, the ability to support > > returning non-initialized data from the kernel would be useful. In > > that case, turning off prezeroing *might* help (but probably won't.) > > Again, he's wanting to reclaim memory bandwidth from the prezeroing > of pages that are prezeroed not because they need to be, but for > security reasons that he doesn't care about. > That really doesn't make any (much) difference. Turning off prezeroing is easy anyway (sysctl.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12: 6: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 1A9ED110C4 for ; Wed, 17 Feb 1999 12:06:02 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id OAA29252; Wed, 17 Feb 1999 14:05:40 -0600 (CST) From: Kevin Day Message-Id: <199902172005.OAA29252@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171951.LAA10456@apollo.backplane.com> from Matthew Dillon at "Feb 17, 1999 11:51:18 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 17 Feb 1999 14:05:40 -0600 (CST) Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Currently, the time spent loading/preparing the new application is a bit > :long, so I was looking at ways to shrink that down. That's where this > > Ahh. A couple of things. First, I presume that the amount of memory > in the machine is not an issue... that you have enough to hold all > the programs pretty much resident. Right. We did have a problem with the vm system deciding to swap out nearly every executable, trying to cache all the data we were sending to the graphic system, but that went away largely when we switched to a 3.0 system. > > In that case, simply preload the executables. That is, rather then > take the latency hit when the user hits a button, take the latency > hit when the user is idle and just tell the program to 'go' ( through > a pipe ) when the user hits the button. Not really an option. We don't know which of the 20ish applications they're going to pick, and it's just one button to start them. > > Second, if you aren't already using a Xeon with its largest L2 > cache configuration, you should probably be using a Xeon with its > largest L2 cache configuration. Intel cpu's tend to fall on their > face with DATA-memory-intensive applications due to their > undersized caches. The undersized cache works ok for instructions > because instructions are pretty compact, but it does not work > well for data. Because of cost concerns, we're forced into a 586 series CPU. > > If the box you are using does not have a 100MHz memory bus, you need > to get one that does. Again, not possible. :) > > :While I don't want to get accused of not trying to figure this one out on my > :own.... Suppose I mmap a large (2MB or more) file. Should any zero'ing be > :going on when I touch those pages for the first time? From the analyzer, it > :looks like it's zeroing pages before putting what it read from the disk into > :them, but as you know, figuring out what's really going on by watching a > :logic analyzer is a form of witchcraft... If this is the case, turning this > :off would greatly help me. :) > > It should not be zeroing pages before doing full reads into them. > That is pretty well optimized, usually. What if I'm doing a partial read? Is a partial read even possible if I'm using the mmap method? > > Third, Memory->PCI transfers are best done with DMA ( as you > already know ). For a frame store, you can eek out additiona > l PCI bus speed by messing with the burst transfer length ( > especially if the cpu is not heavily involved and can afford > to stall a little more ). You should be able to push > 120 MBytes/sec on a PCI bus by tuning the DMA burst. > The PCI card should have a FIFO big enough to accomodate the > burst, too. If you do a large transfer to a PCI card's frame > buffer with memcpy() ( or equivalent ), you eat double the > memory bandwidth plus blow away the data cache on the cpu. I tried this, but ran into a few problems. First, I had to somehow convince the vm system to bring the pages in from disk, before doing the DMA, and making sure they were contiguously mapped to physical ram, and then forcing it not to dump them later. Never quite got past this hurdle. :) Is there a driver somewhere that does this? In my system, userland code mmap()'s data, and does memcpy's to a mmaped device that corresponds directly to the physical frame buffer. I wasn't really sure how to make sure the data ended up in a nice contiguous buffer to DMA it out of, without doing another copy. Also, just in a non-working test case, it actually seemed slower doing it this way, and I lost interest at this point. :) > > Fourth, if you are doing direct frame store from disk to a > PCI card, you may wish to consider building a custom piece > of hardware / firmware to actually use the SCSI bus to > transfer the data directly ( i.e. put the frame store *on* > the SCSI bus and have it master the data directly from the > drives without host intervention ). This is a rather more > complex solution. We're using IDE too. :) Thanks, Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12:12:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from midten.fast.no (midten.fast.no [195.139.251.11]) by hub.freebsd.org (Postfix) with ESMTP id DB5E71128A for ; Wed, 17 Feb 1999 12:12:38 -0800 (PST) (envelope-from tegge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [195.139.251.11]) by midten.fast.no (8.9.1/8.9.1) with ESMTP id VAA22106; Wed, 17 Feb 1999 21:12:34 +0100 (CET) Message-Id: <199902172012.VAA22106@midten.fast.no> To: dillon@apollo.backplane.com Cc: hackers@FreeBSD.ORG Subject: Re: Problems in VM structure ? From: Tor.Egge@fast.no In-Reply-To: Your message of "Wed, 17 Feb 1999 11:31:12 -0800 (PST)" References: <199902171931.LAA10322@apollo.backplane.com> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 17 Feb 1999 21:12:34 +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ach. > > So why isn't it panicing on boot? Why does the machine > destabilize and die later on with all sorts of problems? > Is it trying to use more page table entries then were allocated > for the kernel_map? Is the submap allocator broken? The numbers I gave for kva consumptions by zones etc. might not be completely accurate. Thus kernel_map might be sufficient large for boot. But kernel_map is used directly later (pipes, imgact_gzip, link_elf, resource lists, pmap_new_proc, ...), and one of those KVM consumers might have insufficient error handling when kernel_map no longer has sufficient contiguous free space. > Is there some test we can add to panic the machine at boot > time if KVM is over-reserved? You might give a warning (or panic) if kernel_map has less free space than some predefined limits (using kernel configuration parameters when calculating the limits). - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12:21:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 474EB112CA for ; Wed, 17 Feb 1999 12:20:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA10702; Wed, 17 Feb 1999 12:20:50 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 12:20:50 -0800 (PST) From: Matthew Dillon Message-Id: <199902172020.MAA10702@apollo.backplane.com> To: Kevin Day Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: <199902172005.OAA29252@home.dragondata.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :logic analyzer is a form of witchcraft... If this is the case, turning this :> :off would greatly help me. :) :> :> It should not be zeroing pages before doing full reads into them. :> That is pretty well optimized, usually. : :What if I'm doing a partial read? Is a partial read even possible if I'm :using the mmap method? The filesystem always does a full read even if you only do a partial read. This is true whether you use read() or access a page w/ mmap(), but it is doubly true with mmap(). :I tried this, but ran into a few problems. : :First, I had to somehow convince the vm system to bring the pages in from :disk, before doing the DMA, and making sure they were contiguously mapped to :physical ram, and then forcing it not to dump them later. Never quite got :past this hurdle. :) Is there a driver somewhere that does this? In my :system, userland code mmap()'s data, and does memcpy's to a mmaped device :that corresponds directly to the physical frame buffer. I wasn't really sure :how to make sure the data ended up in a nice contiguous buffer to DMA it out :of, without doing another copy. You would have to design a device to do it. Not terrible, but not trivial either. But that wouldn't get rid of the memcpy... the only way to get rid of the memcpy is to make the filesystem write the data from the file directly to the frame buffer by supplying ficticious pages directly to the underlying block device. This would be a difficult hack to do in the filesystem, but you might be able to do it talking to a raw device and not have to hack the system at all. For example, create a partition on the hard disk that you intend to access directly. i.e. no filesystem. If you mmap() the frame buffer, and issue a read() on the raw device interface for the partition with a pointer into the mmap()'d frame buffer, I *believe* this will result in direct DISK->PCI DMA. I'm not positive, though. :> the SCSI bus and have it master the data directly from the :> drives without host intervention ). This is a rather more :> complex solution. : :We're using IDE too. :) It is a DMA capable IDE controller, right? If not, you are S.O.L. :Thanks, : :Kevin -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12:35:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id B37D310F8D for ; Wed, 17 Feb 1999 12:35:17 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id VAA23473 for ; Wed, 17 Feb 1999 21:35:12 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id VAA00246 for ; Wed, 17 Feb 1999 21:35:15 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id VAA00882 for ; Wed, 17 Feb 1999 21:35:15 +0100 (CET) Date: Wed, 17 Feb 1999 21:35:11 +0100 From: Andre Albsmeier To: Takanori Saneto Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? Message-ID: <19990217213511.A1459@internal> References: <199902171419.XAA13164@mail.ba2.so-net.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199902171419.XAA13164@mail.ba2.so-net.ne.jp>; from Takanori Saneto on Wed, Feb 17, 1999 at 11:19:17PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17-Feb-1999 at 23:19:17 +0900, Takanori Saneto wrote: > I've been getting the same panic couple times. > > In article , > Matthew Jacob writes: > >panic: softdep_sync_metadata: Unknown type bmsafemap > > I also got other types of problems during system shutdown (unmounting > filesystems): > > * mfs process aborts with signal 11. > > There were no coredumps nor diagnostic logs so I can't get any deeper > info. > > * Hang after "syncing disks ... done" message. Same here on a 3.1-RELEASE system. I use 4 softupdated disks and an async mounted mfs. mfs never gets killed during system shutdown (some processes would not die, ...) and occasionaly I see the "panic: softdep_sync_metadata: Unknown type bmsafemap" message. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12:37:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 07D1C1121A; Wed, 17 Feb 1999 12:36:54 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id TAA62183; Wed, 17 Feb 1999 19:57:16 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 17 Feb 1999 19:57:16 +0000 (GMT) From: Doug Rabson To: Eivind Eklund Cc: Wes Peters , John Polstra , Jamie Bowden , hackers@freebsd.org Subject: Re: FreeBSD mention in LWN interview with A.C. In-Reply-To: <19990217143130.G69668@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Eivind Eklund wrote: > On Tue, Feb 16, 1999 at 03:49:51PM -0700, Wes Peters wrote: > > As I said, Perforce is an excellent product with much to recommend it, > > but probably not the best solution for FreeBSD. What we have works quite > > well, because it was developed by highly motivated developers to pretty > > much do exactly what FreeBSD needs. If only *every* development project > > were this lucky. > > > > Especially Linux... ;^) > > http://www.bitkeeper.com/ > > Looks quite good. It is missing a number of features from my > favourite (but not yet implemented) design, but it also has a number > of nice aspects that I've missed... BitKeeper sounds surprisingly good actually. I particularly like the idea of trees of repositories. It would make life much easier for larger projects (like architecture ports or renovating a major bus) which are being worked on by more than one person but which shouldn't happen in the main repository. Support for file renaming is cool too. I'm not suggesting we change, mind you. Give it a year or two to settle and see how well it works for the Linux folks. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 12:52:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7360C10E7F for ; Wed, 17 Feb 1999 12:52:49 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA14028; Wed, 17 Feb 1999 12:51:05 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdO14016; Wed Feb 17 20:50:54 1999 Date: Wed, 17 Feb 1999 12:50:52 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Kevin Day , dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902172020.MAA10702@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This all reminds me of the system we used at TRW under BSD4.[23] Mach OSF1 and FreeBSD for transfering image data. We allocated fixed memory buffers for image data and modified all the devices (disks, network, compression, display) to know how to directly transfer to and from these fixed buffers. Processes controlling the whole thing mmapped the fixed buffers and could thus sample the data. but on the whole they didn't get in the way of the transfers.. it would have slowed things down too much. On Wed, 17 Feb 1999, Matthew Dillon wrote: > :I tried this, but ran into a few problems. > : > :First, I had to somehow convince the vm system to bring the pages in from > :disk, before doing the DMA, and making sure they were contiguously mapped to > :physical ram, and then forcing it not to dump them later. Never quite got > :past this hurdle. :) Is there a driver somewhere that does this? In my > :system, userland code mmap()'s data, and does memcpy's to a mmaped device > :that corresponds directly to the physical frame buffer. I wasn't really sure > :how to make sure the data ended up in a nice contiguous buffer to DMA it out > :of, without doing another copy. > > You would have to design a device to do it. Not terrible, but not > trivial either. But that wouldn't get rid of the memcpy... the only > way to get rid of the memcpy is to make the filesystem write the > data from the file directly to the frame buffer by supplying > ficticious pages directly to the underlying block device. > > This would be a difficult hack to do in the filesystem, but you > might be able to do it talking to a raw device and not have to > hack the system at all. > > For example, create a partition on the hard disk that you intend > to access directly. i.e. no filesystem. > > If you mmap() the frame buffer, and issue a read() on the raw > device interface for the partition with a pointer into the > mmap()'d frame buffer, I *believe* this will result in > direct DISK->PCI DMA. I'm not positive, though. Yes this is exactly correct. The pages in your address space that represent the frame buffer will be used as the DMA addresses for the transfer. > > :> the SCSI bus and have it master the data directly from the > :> drives without host intervention ). This is a rather more > :> complex solution. > : > :We're using IDE too. :) > > It is a DMA capable IDE controller, right? If not, you are > S.O.L. As Matt says, a DMA IDE controller (that we support) will also transfer directly to the frame buffer if you mmap it. It uses approximatly the same code to work out the DMA addresses. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 13:17:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak.texar.com (pak.texar.com [207.112.49.1]) by hub.freebsd.org (Postfix) with ESMTP id 2968F10FED for ; Wed, 17 Feb 1999 13:17:34 -0800 (PST) (envelope-from dseg@pak.texar.com) Received: (from dseg@localhost) by pak.texar.com (8.8.8/8.8.3) id QAA11329; Wed, 17 Feb 1999 16:18:30 -0500 (EST) Date: Wed, 17 Feb 1999 16:18:30 -0500 (EST) From: Dan Seguin To: FreeBSD Hackers Subject: Test, please ignore Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Test To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 13:27: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak.texar.com (pak.texar.com [207.112.49.1]) by hub.freebsd.org (Postfix) with ESMTP id 94B4611586 for ; Wed, 17 Feb 1999 13:26:35 -0800 (PST) (envelope-from dseg@pak.texar.com) Received: (from dseg@localhost) by pak.texar.com (8.8.8/8.8.3) id QAA11349; Wed, 17 Feb 1999 16:27:32 -0500 (EST) Date: Wed, 17 Feb 1999 16:27:32 -0500 (EST) From: Dan Seguin To: FreeBSD Hackers Subject: LKM - interceptors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I'd like to ask if it is possible to write a LKM that would intercept certain system calls, (do something), then continue the (original) call. I've looked at the misc LKM and understand moving the sysent, and so on. Is it possible to reindex the sysent for your LKM (in all the places of the system calls that you want to intercept), effectively intercepting a number of system calls (say 3, 4 ,7 etc), then calling the original system calls from oldent? The goal of this would be to do something like truss but have it inside of the kernel instead of outside without modifying the kernel (hence the LKM). I hope I've made this clear enough. Dan Seguin Azure Automata, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 13:39:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 6A2A611194 for ; Wed, 17 Feb 1999 13:39:46 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 14115 invoked from network); 17 Feb 1999 21:39:30 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 17 Feb 1999 21:39:30 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id QAA70278; Wed, 17 Feb 1999 16:39:30 -0500 (EST) Message-Id: <199902172139.QAA70278@y.dyson.net> Subject: Re: vm_page_zero_fill In-Reply-To: <199902171838.LAA20158@usr07.primenet.com> from Terry Lambert at "Feb 17, 99 06:38:39 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 17 Feb 1999 16:39:30 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > > The thing that appalled me was what you said about BSS being zero'ed > > > in the kernel space using zeroed pages instead of as a result of an > > > explicit zeroing by the execution class loader. > > > > That is the way that it works. Explict zeroing is wasteful because > > it cannot easily take advantage of background prezeroing... However, > > recently prezeroed pages make for efficient usage of cache. The zero > > queue (and all others) are designed to take advantage of recent cache > > usage. > > This is robbing Peter to pay Paul; in a way. The base assumption > that you are hiding is that you aren't constrained by memory > bandwidth. This isn't true if you are nearly saturating a PCI > bus with 4 BT848's (to pick the highest memory bandwidth application > I know about). > I just realized something: Memory bandwidth is >> PCI bandwidth on good designs. I believe that the PCI and memory busses are decoupled on at least some X86 machines. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 13:50:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pak.texar.com (pak.texar.com [207.112.49.1]) by hub.freebsd.org (Postfix) with ESMTP id 4274710F61 for ; Wed, 17 Feb 1999 13:50:20 -0800 (PST) (envelope-from dseg@pak.texar.com) Received: (from dseg@localhost) by pak.texar.com (8.8.8/8.8.3) id QAA11382; Wed, 17 Feb 1999 16:51:17 -0500 (EST) Date: Wed, 17 Feb 1999 16:51:16 -0500 (EST) From: Dan Seguin To: FreeBSD Hackers Subject: LKM interceptors Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (I apologize if this is a repost, I'm not sure the original went out. Ran out of swap). Hi. I'd like to ask if it is possible to write a LKM that would intercept certain system calls, (do something), then continue the (original) call. I've looked at the misc LKM and understand moving the sysent, and so on. Is it possible to reindex the sysent for your LKM (in all the places of the system calls that you want to intercept), effectively intercepting a number of system calls (say 3, 4 ,7 etc), then calling the original system calls from oldent? The goal of this would be to do something like truss but have it inside of the kernel instead of outside without modifying the kernel (hence the LKM). I hope I've made this clear enough. Dan Seguin Azure Automata, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 14:32:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 85B1B10FCE for ; Wed, 17 Feb 1999 14:32:54 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA17384; Wed, 17 Feb 1999 14:24:02 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdE17373; Wed Feb 17 22:23:57 1999 Date: Wed, 17 Feb 1999 14:23:50 -0800 (PST) From: Julian Elischer To: Kevin Day Cc: dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902171902.NAA25290@home.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Kevin Day wrote: > > In looking with some logic analyzers, we're seeing that we're nearly out of > PCI bandwidth, and we're hitting the memory very hard too. 99% of our run > time is spent ferrying data from ram into the graphic device. theoretically clearing of memory pages should not generate any PCI traffic. The average architecture puts the memory on the processor side of the PCI bridge which means that memory cycles by the processor should not be passed to the PCI bus. If it is.. get better hardware! Having read you rdescription below, here are my questions/comments. This comes from the experience I have with large scale servers serving streams of high quality image data. What yo can do to fix your problem depends upon what the exact data-path of your product is.. I assume you have data arriving via DMA from a PCI device, being stored in a memory buffer, possibly manipulated by the processor, and sent out again via another PCI busmaster. Is this true? do you have your own hardware? can it be changed at all? do you have shared (PCI) memory on either the source or the destination? does the processor need to read the actual data (inline?) can you alter your 20 sub processes to stay resident and only start up once? (i.e. become daemons that accept work requests?) how much RAM on the machine, and how much buffer space do you require? etc. etc. > > Because of the nature of the product, we're needing more and more > 'real-time' like operation. The delay from when a user does something, until > he/she sees it on the screen is critical, as well as being able to handle > many input devices, and radically change the scheduler's behavior when > something 'interesting' comes in. (My current kludge for really really > important data that must flow between a few processes quickly is mucking > with rtprio, which is working, but I'd prefer to have much more control over > the scheduler). > > After things still being slower than I wanted, I pulled out a logic > analyzer. In watching memory accesses on the analyzer, we saw a lot of > zeroing going on, especially after exec()'ing another application. (This > system has one supervisory process, that will start any one of 20ish other > applications, in response to what the user wants to do). > > Currently, the time spent loading/preparing the new application is a bit > long, so I was looking at ways to shrink that down. That's where this > discussion came from. > > While I don't want to get accused of not trying to figure this one out on my > own.... Suppose I mmap a large (2MB or more) file. Should any zero'ing be > going on when I touch those pages for the first time? From the analyzer, it > looks like it's zeroing pages before putting what it read from the disk into > them, but as you know, figuring out what's really going on by watching a > logic analyzer is a form of witchcraft... If this is the case, turning this > off would greatly help me. :) > > (If I'm not being clear enough, imagine mmap'ing a movie, and memcpy'ing it > into a frame buffer at 60fps, to get an idea of the kind of data I'm going > through) > > I hope this sort of explained my application, although I'm sure there are > arguments either way if this is really going to help me or not. > > Thanks again, > > Kevin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 14:44:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 57E31112D4 for ; Wed, 17 Feb 1999 14:44:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA11578; Wed, 17 Feb 1999 14:44:15 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 14:44:15 -0800 (PST) From: Matthew Dillon Message-Id: <199902172244.OAA11578@apollo.backplane.com> To: "John S. Dyson" Cc: dyson@iquest.net, tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: <199902172139.QAA70278@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> This is robbing Peter to pay Paul; in a way. The base assumption :> that you are hiding is that you aren't constrained by memory :> bandwidth. This isn't true if you are nearly saturating a PCI :> bus with 4 BT848's (to pick the highest memory bandwidth application :> I know about). :> :I just realized something: : : Memory bandwidth is >> PCI bandwidth on good designs. I believe :that the PCI and memory busses are decoupled on at least some X86 machines. : :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. Main memory and the PCI bus are decoupled and buffered with FIFOs on all designs that I know of. That's what all those burst and write posting options are in the chipset BIOS. This is why you want to use DMA... it won't (much) stall main memory or the cpu while transfering data to or from the PCI bus. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:14: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 74D7E10FED for ; Wed, 17 Feb 1999 15:13:53 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA18843; Wed, 17 Feb 1999 15:04:12 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdP18838; Wed Feb 17 23:04:05 1999 Date: Wed, 17 Feb 1999 15:04:01 -0800 (PST) From: Julian Elischer To: Kevin Day Cc: Matthew Dillon , dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902172005.OAA29252@home.dragondata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Kevin Day wrote: > > > > > Third, Memory->PCI transfers are best done with DMA ( as you > > already know ). For a frame store, you can eek out additiona > > l PCI bus speed by messing with the burst transfer length ( > > especially if the cpu is not heavily involved and can afford > > to stall a little more ). You should be able to push > > 120 MBytes/sec on a PCI bus by tuning the DMA burst. > > The PCI card should have a FIFO big enough to accomodate the > > burst, too. If you do a large transfer to a PCI card's frame > > buffer with memcpy() ( or equivalent ), you eat double the > > memory bandwidth plus blow away the data cache on the cpu. > > I tried this, but ran into a few problems. > > First, I had to somehow convince the vm system to bring the pages in from > disk, before doing the DMA, and making sure they were contiguously mapped to > physical ram, and then forcing it not to dump them later. Never quite got > past this hurdle. :) Is there a driver somewhere that does this? In my > system, userland code mmap()'s data, and does memcpy's to a mmaped device > that corresponds directly to the physical frame buffer. I wasn't really sure > how to make sure the data ended up in a nice contiguous buffer to DMA it out > of, without doing another copy. Is the data on raw disk or in files? if on raw disk then: 1/ create a device called "/dev/bufferspace" this should allocate a N MB sequential buffer of reserved memory when the system boots. 2/ do all reads from the raw device. straight into this space. The VM system will step out of the way and let the DMA do all the work. (I assume you are using UltraDMA on your IDE drives right?) store the data on raw partitions using your own user level filesystem e.g. a simple system where working out where to look for the data is done by a library you lik with rather than a filesystem in the kernel. Use reads and writes to the raw disk devices to read the data. this is blazingly fast, and you should be able to use the aio stuff or the kernel thread stuff to 'preread' teh data in before you need it and to allocate the space in your static buffer. If you are reading files from a filesystem in the kernel then things get messier. Do you have to rewrite the data to disk? can they be read-only? etc.etc. > > Also, just in a non-working test case, it actually seemed slower doing it > this way, and I lost interest at this point. :) > > > > > Fourth, if you are doing direct frame store from disk to a > > PCI card, you may wish to consider building a custom piece > > of hardware / firmware to actually use the SCSI bus to > > transfer the data directly ( i.e. put the frame store *on* > > the SCSI bus and have it master the data directly from the > > drives without host intervention ). This is a rather more > > complex solution. > > We're using IDE too. :) > > > > Thanks, > > Kevin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:17:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id 9E00C1135D for ; Wed, 17 Feb 1999 15:17:03 -0800 (PST) (envelope-from nick@feralmonkey.org) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id A64DA780B; Wed, 18 Feb 1998 10:21:22 +1100 (EST) Date: Wed, 18 Feb 1998 10:21:22 +1100 (EST) From: To: Dan Seguin Cc: FreeBSD Hackers Subject: Re: LKM - interceptors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-83345488-887757682=:2871" Sender: owner-freebsd-hackers@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-83345488-887757682=:2871 Content-Type: TEXT/PLAIN; charset=US-ASCII See attached. Nick On Wed, 17 Feb 1999, Dan Seguin wrote: > > > Hi. I'd like to ask if it is possible to write a LKM that would intercept > certain system calls, (do something), then continue the (original) call. > I've looked at the misc LKM and understand moving the sysent, and so on. > Is it possible to reindex the sysent for your LKM (in all the places of > the system calls that you want to intercept), effectively > intercepting a number of system calls (say 3, 4 ,7 etc), then calling the > original system calls from oldent? > > > The goal of this would be to do something like truss but have it inside > of the kernel instead of outside without modifying the kernel (hence the > LKM). > > > I hope I've made this clear enough. > > > Dan Seguin > > Azure Automata, Inc. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > --0-83345488-887757682=:2871 Content-Type: APPLICATION/octet-stream; name="execve.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="execve.tar.gz" H4sIAEQb6jQAA+1YXWgbVxa+UpTYM6vQlNJS9mVvHZqOHFs/tiUtm9qJY7ut SWyHyHE2GHcYz1xJU82PmB8nagld0LbUFaWCvvWpeSl9KYTdwm4ppYWWhn0L yz4Udl8XDH7cfciSgnvu3CtpLFsNCyZllzl4dO+ce+65555z7nfumNwi6haR NxW1ptm2k1lSaqSsGwQdIeWy2cJUFiOMc8X8vpZRLlfEuFDIZacmsxP5AjAm i8UcwtmjNGIQ+a6nOBgjS1drPyX3qPH/Ubq0tDI/LRCWBaatiaWrc6Uuo5MW aVVcXlmaXZ7G2LJNxRLFtG6phq8R/OKmq6VrMDNt1mbEn3s7Ef2X1BfozIHA H8EacP6L+fzA8z85VczD+Z8qTkzl8pMUC3L5QjEbnf/HQZlRLEIMWNilFO4E XqTc1aruYvjzbKwR07Zcz1E8gqv2TUwUVzcauGH7Dq4RxyIGVhULbxKsbPou 0eh0vUzHsWYDaHjYhMqCYQjbZexVCXaJ6ju618Bloni+Q1ysbCm6oWwaJJhs 4ZccQi6W5tN41cZ1h2wRy6MzQYVrO55LFZmKoau67bsYEMg3QEnZsU06/6bt 1HSrMgbreMzMYEFigB4Dz0zjXDrYI43rhTJxFAM2WCONtO1UxNGMKJ7uIpzb cDNeo07cdHWmj113bPUgFx7PPJQN8p59cIS6/1B52PJBvlE7XLmqGMahA4Zd oXzxtAa13SJ49ZUFeWn25cU5+frK1XlhxCWuYpIRUYSz4Okqhjj7qodhHdmj 8cCjZjZ7TtTB/1Vd04iFpzG894kzc7Ht6BWZ5RObYjb4K3hblq9IEpenvsOj Y3jL1jU86iv1MUzFHeJtKcb6RioFK0B1kpcWS3MS05DqLQqiIgcrw1Y06aDN tO9xpaqppcQ3RIH2w0Qch+9FcG/qnlrFUiAqgKyqQKZdvrQkL8iXV2bnfyMK AmS0BFrJLd31XCnQnwJhQQCjfcfC0sLCbxdLq9RMQdhU7XpDOsPcsl66UeJu 2BjDZ0JOggzVXyd2WdrnRrp7QTg4N+02ZBpnsLrr12A1iBDwApPoTLq+Q5Qa HQtt5NpyZyvcun2GHGrrIOvCK0BeKb7hUb3MowuLy2uzl8/1ZITbINbxEsiA AuCEggjn95AY7g8h62wRJ4jl/GLpyuzq3CsSFwoEYHAMh/Ki74WqtnzDoEHu WtB15P7MrA9OTbo8l+XqFafigiRsHaRhu5BqZek5dlpSOMgnGqLxGQqOLOUE gQ2fPRu4J5iCpedAr2rWJX98pmzBqRzDI5lN3cq41ZEUPnMGAx/W2lrPbbAs FTKj8APZvljGwQQK2CMgjRVLC4C2rDuuh2FSAOXAMJUKHCAASHAIm1vR4XTC kBmMk3KZqB5l+bB9QNlsOhDL8BMQMpGbMtYHKcGhoMYJ9fGZuuyrDtHGZ1RH pgr5eeOW0+WXFLfWZxnFfxoG4rrYgNOWxou0hDQwn+J6OhwCpV4nUL1BNkB4 KFee7TQw4B0tUoD0DhOnltOAqZDyYatHxvWR4KDdDiLQyc/QoeicNwlSIMgD lgOpIHt+7uJ9BPSo+599BGsE339TA+9/uWIh27v/Teai+9/jpLdjQ3djCGHo JuH5hLPvwjOMuvkB6IzQte1/rpVa/nBrIZn7e/NBzBObD+Le9O5Ku91e2/nr 3t5e89vEW197Q39+Embunn9tuPo3UF39Hn52/gjD947/A7rPwrOdvw+/u79s gwwdDgR33geZ3RPtL56B6dvfv0cerL/6l29C624km7dPxUA/FdhVmg/j3rk3 hebDmJfcvdxuNx8e84q7c+17L0mfgbq1nfNdk4aZSel2aW0nT1d5BmyGfor2 RdZ/MpAefutrfwjejsEbt4DjL2LXJDSuo8Cm62DUtWRzmroP+U/coTv67sIp tHeccloTXyWg+Zw68YdP0L8+9udbFxPNWwnknWvVE18l6eBQd/CF1sZwa+5U C927kKD+B9nWlUT5zlMgVt6Ov3v8aei8czG+55/a85N7/vAd6ra9+++Rf6+/ KlMv9eg4PLEB4f4wFsQ1sQ0tLJT4HW9v8PZF3uahPQHtWS5/mr//B3SchL9d li8nv2TrnfwTYuMmy5uTVdYm6Pcj7DJ5g7+XENO/wvmLXH6ev5/ncqNcb5LL J1gb0FOh/vN0HthGXT5ObYCWBr9AZeIsp+dC/ljmeU3zbT3EV0P91+jacZao PpenwX2d839Pj01I/oNQ/yN4Kqo6Iau2WdcNoqWRLMsVy+8yZBXJrPDDCPtq QXLokoLk7g0TyaFKhGR290JycHVDcvfaAt1stquDHlU5dM8JXjTdrStwvT2Q DwPwn/4/5yigP6BHfP9PZHOFEP5PwPBUoTAR4f/joKHY2yiM/59xfoT/Ef4P wv8Yx/9jHP9P9OE/6sP/+AD8j3P8Rxz/4334f6IP/zt7+kWo/2yoj0N9WgsS HMN/jVhdoGG5EJK5hHp4fh2eX3G+jnr15Vao/y7q1ZcPUK++fIR6NeVT1KsX f4C2A9ZhDO4C+T6UDsF5pzyECkHoHB68oj+64BxeaPZVF1pDIooooogiiiii iCKKKKKIIvp/pR8B+BGkYQAoAAA= --0-83345488-887757682=:2871-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:18:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 60AE21131F; Wed, 17 Feb 1999 15:18:45 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id AAA25948; Thu, 18 Feb 1999 00:04:16 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id TAA00897; Wed, 17 Feb 1999 19:36:35 +0100 (CET) From: Wilko Bulte Message-Id: <199902171836.TAA00897@yedi.iaf.nl> Subject: Re: savecore before swapon? In-Reply-To: <19990217142628.F69668@bitbox.follo.net> from Eivind Eklund at "Feb 17, 99 02:26:28 pm" To: eivind@freebsd.org (Eivind Eklund) Date: Wed, 17 Feb 1999 19:36:35 +0100 (CET) Cc: brandon@roguetrader.com, freebsd-hackers@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Eivind Eklund wrote... > On Tue, Feb 16, 1999 at 08:26:00AM -0700, Brandon Gillespie wrote: > > I havn't checked the source, but from my understanding shouldn't > > savecore be run before swapon is run, incase the swap device is the > > dump device? Or to look at it another way, when swapon is run on a > > swap device, does it look first to see if there is a dump in it, and > > if so what does it do? Right now we run swapon, then considerably > > later we run savecore. Assuming swapon just trashes whatever was in > > that device, running savecore is pretty much irrelevant, as most > > people I know (not necessarily in FreeBSD) use their swap device as a > > dump point. > > This is done intentionally, as fsck may in some cases require swap > to be able to fsck large filesystems. > > It would make sense to have a sysctl > 'only_swap_as_absolutely_last_resort_not_for_performance' AKA > 'do_linux_swapping_scheme' which was set before the swapon, and unset > after the crashdump. I don't know how to implement this. (It might > be that one of the present sysctls does something like this - I've not > checked). Or start allocating swap 'backwards' from the high block# on the disk downwards. Assuming swap > physical mem and dumps starting at swap offset 0 this should be safe at all times (unless fsck really allocates all swap of course ;-) But this might be a lot of work, I'm not familiar with the VM. Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:20:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bsdserver.fhnet (ppp-11.alkor.ru [195.5.138.250]) by hub.freebsd.org (Postfix) with ESMTP id EC712112C0 for ; Wed, 17 Feb 1999 15:19:47 -0800 (PST) (envelope-from dmitry@furmansky.spb.su) Received: from daddy (daddy.fhnet [193.123.183.5]) by bsdserver.fhnet (8.8.8/8.8.8) with SMTP id CAA19965 for ; Thu, 18 Feb 1999 02:21:50 +0300 (MSK) (envelope-from dmitry@furmansky.spb.su) Message-ID: <000701be5acc$24b19a80$05b77bc1@daddy.fhnet> Reply-To: "Dmitry Furmansky" From: "Dmitry Furmansky" To: Subject: Subscribe Date: Thu, 18 Feb 1999 02:20:36 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BE5AE5.451EA740" 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BE5AE5.451EA740 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi! Is it possible right now, or I'll need to send some sort of special = letter somewhere? Thank you DF ------=_NextPart_000_0004_01BE5AE5.451EA740 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi!
Is it possible = right now, or=20 I'll need to send some sort of special letter somewhere?
Thank = you
DF
------=_NextPart_000_0004_01BE5AE5.451EA740-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:25:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles340.castles.com [208.214.167.40]) by hub.freebsd.org (Postfix) with ESMTP id DAC9310FEF for ; Wed, 17 Feb 1999 15:25:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA01510; Wed, 17 Feb 1999 15:20:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199902172320.PAA01510@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dyson@iquest.net Cc: tlambert@primenet.com (Terry Lambert), toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-reply-to: Your message of "Wed, 17 Feb 1999 16:39:30 EST." <199902172139.QAA70278@y.dyson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Feb 1999 15:20:50 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Memory bandwidth is >> PCI bandwidth on good designs. I believe > that the PCI and memory busses are decoupled on at least some X86 machines. "Almost all". -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:36:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 6D0821109F for ; Wed, 17 Feb 1999 15:36:24 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA10085; Wed, 17 Feb 1999 15:35:48 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA23989; Wed, 17 Feb 1999 15:35:47 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA05613; Wed, 17 Feb 1999 16:35:45 -0700 Message-ID: <36CB5251.90EC4591@softweyr.com> Date: Wed, 17 Feb 1999 16:35:45 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: hackers@freebsd.org Subject: Re: ifconfig kills my machine References: <199902082338.PAA01313@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Mike Smith wrote: > > > > > > > I've seen this on a Toshiba Equium 7000S, with onboard fxp0. The first > > > > DMA operation in the configuration of the chip never completes. I re- > > > > installed 2.2.7 on that machine, since I didn't have time to investigate > > > > then. If I ever get done with my "FPX" code at work (maybe this week, > > > > if I'm lucky) I'll poke into this fxp problem. ;^) > > > > > > I've also seen this on a (significant) number of IBM systems. We could > > > probably get FreeBSD certified on the NetFinity range if we can resolve > > > this. > > > > What can I do to help? I'd send the machine to you if I could, but it's > > Xylan property. If there's anything I can trap, printf, or debug, let > > me know. I'm willing to stay late and debug over the phone, or even > > setup a serial console and a modem if that'll help. > > Characterise the defect, report or fix. I just booted 3.1-R from kern + mfsroot floppies, and it was able to probe the fxp0 interface just fine. I'll take a run at upgrading this machine tonight or tomorrow, but it appears my problem has been fixed. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 15:48: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 1631210FEF for ; Wed, 17 Feb 1999 15:48:01 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA10150; Wed, 17 Feb 1999 15:47:28 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA24271; Wed, 17 Feb 1999 15:47:27 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA06998; Wed, 17 Feb 1999 16:47:25 -0700 Message-ID: <36CB550D.7C1065F3@softweyr.com> Date: Wed, 17 Feb 1999 16:47:25 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: dave@jetcafe.org, freebsd-hackers@FreeBSD.ORG Subject: Re: getpwnam and getpwnam_r References: <199902171850.LAA21086@usr07.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > Where are the thread-safe, reentrant versions of this routine in > > > FreeBSD 3.1? > > No additions to the list (I'm too tight for time to look at my CDROM > at the moment). > > The routines getpwnam, getspnam are problematic, in general. This is one of the reasons why I was putting them off 'til last. They're an ugly mess, and I'm fighting enough ugly messes at work right now. ;^( > A number of the cron-triggered VM bugs have to do with the dbm > routines mmap'ping the password database (COW), and cron modifying > the contents of the fields, as if they were static buffers in > libc. > > It seems to me that the use of a static structure with pointers > to the relevent "return data" will be problematic for threads > based, reentrant versions of these routines. That's what I'm getting rid of. The _r versions all use a caller-provided buffer to return the data in. The type of buffer provided by the caller is the caller's problem, not mine. If you hand me a buffer I cannot write into, I will gently inform you of this by segv'ing all over your program. > I am loathe to suggest TLS (thread local storage) as a soloution, > since it could easily interfere with marshalling data between > kernel threads (as it does on Windows 95/98/NT) due to it being > outside the common address space as an implementation detail. I actually had not given much thought to the implementation of the really ugly, dbm-based calls like getpw*. I'll burn that bridge when I get to it, I guess. The strtok and time functions were pretty straightforward, since they just run "inside" the caller-supplied buffer. I do, however, realize this is a sticky problem. I originally ventured down this path to support something I was working on, where I have a C++ class that starts a thread in it's constructor and "runs" the object in the thread. The storage used in this case is storage local to the object, allocated via "operator new" (and therefore malloc on G++/FreeBSD, right?). I haven't bothered to trace the performance ramifications of this storage model yet because the program is less than half implemented. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 16:28:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6F2051101A for ; Wed, 17 Feb 1999 16:28:11 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA20742; Wed, 17 Feb 1999 15:55:43 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdr20739; Wed Feb 17 23:55:41 1999 Date: Wed, 17 Feb 1999 15:55:38 -0800 (PST) From: Julian Elischer To: Andre Albsmeier Cc: Takanori Saneto , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? In-Reply-To: <19990217213511.A1459@internal> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG WHY would you async mount an MFS? it's an MFS! (?) On Wed, 17 Feb 1999, Andre Albsmeier wrote: > On Wed, 17-Feb-1999 at 23:19:17 +0900, Takanori Saneto wrote: > > I've been getting the same panic couple times. > > > > In article , > > Matthew Jacob writes: > > >panic: softdep_sync_metadata: Unknown type bmsafemap > > > > I also got other types of problems during system shutdown (unmounting > > filesystems): > > > > * mfs process aborts with signal 11. > > > > There were no coredumps nor diagnostic logs so I can't get any deeper > > info. > > > > * Hang after "syncing disks ... done" message. > > Same here on a 3.1-RELEASE system. I use 4 softupdated disks > and an async mounted mfs. mfs never gets killed during > system shutdown (some processes would not die, ...) and > occasionaly I see the "panic: softdep_sync_metadata: Unknown type bmsafemap" > message. > > -Andre > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 16:49:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DC423112B6; Wed, 17 Feb 1999 16:49:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA13082; Wed, 17 Feb 1999 16:49:24 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Feb 1999 16:49:24 -0800 (PST) From: Matthew Dillon Message-Id: <199902180049.QAA13082@apollo.backplane.com> To: Wilko Bulte Cc: eivind@FreeBSD.ORG (Eivind Eklund), brandon@roguetrader.com, freebsd-hackers@FreeBSD.ORG Subject: Re: savecore before swapon? References: <199902171836.TAA00897@yedi.iaf.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Or start allocating swap 'backwards' from the high block# on the disk :downwards. Assuming swap > physical mem and dumps starting at swap offset 0 :this should be safe at all times (unless fsck really allocates all swap :of course ;-) : :But this might be a lot of work, I'm not familiar with the VM. : :Wilko :_ ______________________________________________________________________ : | / o / / _ Arnhem, The Netherlands : |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl Hmm. Well, I don't want to reverse-index the swap allocation but it would be possible to set the hinting on the swap radix tree bitmap to allocate higher swap blocks first. I think it would be a little too much of a hack to be worthy of the kernel, though. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 17:13: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63]) by hub.freebsd.org (Postfix) with ESMTP id 05D6011053 for ; Wed, 17 Feb 1999 17:12:36 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.8.8/8.8.8) with ESMTP id BAA11516; Thu, 18 Feb 1999 01:12:31 GMT (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id BAA03944; Thu, 18 Feb 1999 01:12:17 GMT (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199902180112.BAA03944@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: tom@tomqnx.com (Tom Torrance at home) Cc: brian@Awfulhak.org (Brian Somers), hackers@freebsd.org Subject: Re: PPP Problem In-reply-to: Your message of "Wed, 17 Feb 1999 13:40:12 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Feb 1999 01:12:17 +0000 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have not been able to duplicate the behaviour- perhaps that is true. > > BUT there are several things I find do not work properly when using > ppp over TCP. Perhaps you could set me straight, but... > > 1) I would expect that with enable lqr and accept lqr, if the > other side disappears (no response to 5 polls) I would expect the > tunX connection to be torn down, and ppp.linkdown processed, and the > ppp job to terminate. NONE of this seems to happen. Hmm, have you enabled lcp & lqm logging ? Are they confirming that you're sending a sixth un-replied-to ECHO ? > 2) "ppp -direct loop-in" ignores a "kill -TERM xxx". This does > not seem correct. How can ppp.linkdown ever be processed? Is ppp logging the fact that it sees the signal ? Once ppp receives a TERM, it starts sending terminate requests to the peer. > 3) Granted that you can compensate in the routing table, the > netmask configuration for the tunnel device seems incorrect. It is > always set to the default for the IP. I would expect that if a > netmask is supplied in the "set ifaddr" command, that would be used > in setting up the tunnel configuration. This is a bug I recently introduced. It's in my TODO list and should be fixed fairly soon. > 4) After a connection is set up, the named running on the > client starts to cough: > named: bind(dfd=24, [10.0.1.1].53): Permission denied > named: deleting interface [10.0.1.1].53 > This seems to be a harmless peculiarity of the new bind (The old > one on the server doesn't do it) that I could eliminate by defining > the IPs in my zone (or live with it). This is because you've got named in a ``sandbox'' - running as user `bind' probably. It hasn't got permission to bind port 53 to newly configured interfaces. > 5) Pinging the host side of the tunnel takes 5 times as long > as when I ping an ethernet interface. Setting up a route for that IP > to 127.0.0.1 fixes this. Would it not be a good idea for ppp to > set this up automatically? Not really. If people want a loopback, they should configure one (POLA). Besides, it's quite common for people to use the same local interface address on their tun interface as their LAN - making routing a lot easier. Creating a loopback here would disturb quite a few people. > Would you be kind enough to set me straight where required on the above? > The docs are full of helpful hints/examples, but a tad short on > specification as to how it "should" work:-) If you can supply more detail about 1 & 2, I can look into any problems. > Regards, > Tom Cheers. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 19:31: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from h24-64-221-247.gv.wave.shaw.ca (24.64.221.247.bc.wave.home.com [24.64.221.247]) by hub.freebsd.org (Postfix) with ESMTP id 8B87010E67 for ; Wed, 17 Feb 1999 19:30:55 -0800 (PST) (envelope-from jake@h24-64-221-247.gv.wave.shaw.ca) Received: from h24-64-221-247.gv.wave.shaw.ca (localhost [127.0.0.1]) by h24-64-221-247.gv.wave.shaw.ca (8.9.3/8.9.2) with ESMTP id TAA01056 for ; Wed, 17 Feb 1999 19:30:55 -0800 (PST) (envelope-from jake@h24-64-221-247.gv.wave.shaw.ca) Message-Id: <199902180330.TAA01056@h24-64-221-247.gv.wave.shaw.ca> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: Re: softupdate panic, anyone seen this? In-reply-to: Your message of "Wed, 17 Feb 1999 21:35:11 +0100." <19990217213511.A1459@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Feb 1999 19:30:54 -0800 From: Jake Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > * mfs process aborts with signal 11. > > * Hang after "syncing disks ... done" message. > > occasionaly I see the "panic: softdep_sync_metadata: Unknown type bmsafemap" I was seeing all of this and other wierdness when I had mfs's mounted on /tmp and /var/tmp. I stopped mounting them and all the problems went away; my make world time even improved by 10-20 minutes. go figure... -- obfuscate v.t. darken; obscure; bewilder. int i;main(){for(;i["]; Wed, 17 Feb 1999 20:20:05 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DKwV-0007Uv-00; Wed, 17 Feb 1999 21:20:03 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id VAA64778; Wed, 17 Feb 1999 21:22:53 -0700 (MST) Message-Id: <199902180422.VAA64778@harmony.village.org> To: Nicolas Souchu Subject: Re: Regarding tcpdump and plip Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 08 Feb 1999 22:28:29 +0100." <19990208222829.53422@breizh.prism.uvsq.fr> References: <19990208222829.53422@breizh.prism.uvsq.fr> <199902080148.RAA09054@dingo.cdrom.com> <19990208195855.56187@breizh.prism.uvsq.fr> Date: Wed, 17 Feb 1999 21:22:53 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990208222829.53422@breizh.prism.uvsq.fr> Nicolas Souchu writes: : Ok. Is UPDATING only a -current resource or may it be updated in 3.1? Maybe. However, I don't think that I'll be doing it myself. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:33:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 0DD1911323 for ; Wed, 17 Feb 1999 20:33:33 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DL9Y-0007VE-00; Wed, 17 Feb 1999 21:33:32 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id VAA64812; Wed, 17 Feb 1999 21:36:22 -0700 (MST) Message-Id: <199902180436.VAA64812@harmony.village.org> To: Matthew Dillon Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 10 Feb 1999 01:07:44 PST." <199902100907.BAA79553@apollo.backplane.com> References: <199902100907.BAA79553@apollo.backplane.com> <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> Date: Wed, 17 Feb 1999 21:36:22 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902100907.BAA79553@apollo.backplane.com> Matthew Dillon writes: : The problem is that linux updates the timeval structure on return, : telling you how much time is left. Linux is the only system to do this. And it was flawed because if there is an interrupt that causes a higher priority process to run, the value is too small. The value is only an approximation. : Many programs assumed that tv was const... i.e. not modified by : the call, and so would initialize the structure once then use it : multiple times. It was before Linux. : I don't know what linux does now, but most programs these days : reinitialize tv on each select() call in order to work around : any potential problem. Linux's system call still modifies things. However, there is a bsd_select in most libraries that does the right thing, at least the thing that all other oses do. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:36:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from horse.supranet.net (horse.supranet.net [205.164.160.8]) by hub.freebsd.org (Postfix) with ESMTP id 845CF11323 for ; Wed, 17 Feb 1999 20:36:12 -0800 (PST) (envelope-from gavinb@supranet.net) Received: from zeus (ppp00-66.supranet.net [205.164.160.66]) by horse.supranet.net (8.9.1/8.9.1) with SMTP id WAA14433 for ; Wed, 17 Feb 1999 22:36:11 -0600 (CST) Message-Id: <4.1.19990217222002.03d38bc0@mail.supranet.net> X-Sender: gavinb@mail.supranet.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 17 Feb 1999 22:38:59 -0600 To: freebsd-hackers@freebsd.org From: Benjamin Gavin Subject: Problems with ipfw/nat Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I have posted a similar question to -stable, but got a non-existent response. I'll post it here, as it relates closer to this list (I believe). The problem I have been having is with a 3.0-STABLE (~2/8/99 CVSup). I have the machine running IPFW with NAT enabled. The outgoing NAT is working fine, and traffic to the internal LAN (from the outside) is being blocked nicely. However, I know face the following problem. I need to open a port (80) to the outside world on an internal machine. I have done the same thing with port 110 (POP3), and all went just great. I have included what I believe to be the relevant configuration files below: (I am doing this from home, so the syntax may be slightly off, but I think not.) _rc.conf.site_: gateway_enable="YES" firewall_enable="YES" firewall_type="/etc/rc.firewall.local" # Contains my local firewall rules firewall_quiet="NO" natd_enable="YES" natd_interface="fxp0" # My external ethernet card natd_flags="-f /etc/rc.natd" ifconfig_fxp0="inet xxx.xxx.xxx.66 netmask 255.255.255.192" ifconfig_fxp0_alias0="inet xxx.xxx.xxx.67 netmask 255.255.255.255" ifconfig_fxp1="inet 192.168.44.1 netmask 255.255.255.0" _rc.firewall.local_: ... # Other rules # added to trace all ip traffic to and from 192.168.44.17 through me allow log ip from any to 192.168.44.17 via fxp1 allow log ip from 192.168.44.17 to any via fxp1 # needed or packets get blocked in the middle allow log tcp from any to 192.168.44.17 80 via fxp0 ... # Other rules _rc.natd_: use_sockets yes same_ports yes dynamic yes # Redirect requests for port 80 on xxx.xxx.xxx.67 to 192.168.44.17:80 redirect_port 192.168.44.17:80 xxx.xxx.xxx.67:80 Here is the problem. Watching the logs (/var/log/messages) I see the port getting redirected and what looks like the packet leaving the interface to go to 192.168.44.17. However, I don't ever see that packet hit the web server. Is there something I am doing wrong? From the firewall I can get to the internal web server by using 192.168.44.17, but I can't get to it from outside. I don't see any response from the web server coming back into the firewall on either type of request (from the firewall itself, or from outside.) Any ideas?? Please, I am at a loss, this worked perfectly for POP3, but not for http? Or is it possibly something gone awry in the -STABLE version I am running? I was running an earlier version of -STABLE on the box with POP3 working. TIA, and sorry for the rather long message. Ben Gavin --------------------------------- Benjamin Gavin http://www.virtual-olympus.com/ *** Down with SPAM! *** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:37:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id A779B1134A for ; Wed, 17 Feb 1999 20:37:44 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DLDb-0007VU-00; Wed, 17 Feb 1999 21:37:43 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id VAA64853; Wed, 17 Feb 1999 21:40:33 -0700 (MST) Message-Id: <199902180440.VAA64853@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "10 Feb 1999 15:30:07 +0100." References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> Date: Wed, 17 Feb 1999 21:40:33 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : Matthew Dillon writes: : > The problem is that linux updates the timeval structure on return, : > telling you how much time is left. : : Yup. I wish FreeBSD did that - the man page already states that one : shouldn't rely on tv not being modified, so it shouldn't break POLA. No. I would think that changing it would violate POLA. Changing tv is bogus because it is only a lower bound, especially if you have multiple things running on the system. It creates a race condition that cannot be avoided, which is why it likely wasn't done in the first place. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:40:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id BC21911394 for ; Wed, 17 Feb 1999 20:40:10 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DLFs-0007Vf-00; Wed, 17 Feb 1999 21:40:04 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id VAA64894; Wed, 17 Feb 1999 21:42:49 -0700 (MST) Message-Id: <199902180442.VAA64894@harmony.village.org> To: Dag-Erling Smorgrav Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: "Daniel C. Sobral" , Matthew Dillon , Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG In-reply-to: Your message of "10 Feb 1999 16:02:24 +0100." References: <199902092246.PAA10658@usr02.primenet.com> <199902100403.MAA55849@spinner.netplex.com.au> <19990210085847.A11710@gil.physik.rwth-aachen.de> <199902100907.BAA79553@apollo.backplane.com> <36C19CC9.62FAA6F7@newsguy.com> Date: Wed, 17 Feb 1999 21:42:48 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Dag-Erling Smorgrav writes: : Yep, man pages are specs, and when the spec says tv may be modified by : select(), that means you can't expect it to remain untouched. That's in the bugs section: select() should probably return the time remaining from the original timeout, if any, by modifying the time value in place. This may be im- plemented in future versions of the system. Thus, it is unwise to assume that the timeout value will be unmodified by the select() call. Notice "should" and "may be" It doesn't say "Will" or "does". : On the contrary, it is extremely useful for implementing higher-level : timeouts. If you want to see the new installer come true, I need to : implement protocol-level timeouts in libfetch, and that means either : add a lot of gettimeofday() logic or fix select() to modify tv. Even if that represents an unavoidable race condition? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:43:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id A874A113CB for ; Wed, 17 Feb 1999 20:43:39 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from lot.gsoft.com.au (doconnor@lot.gsoft.com.au [203.38.152.106]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id PAA25201; Thu, 18 Feb 1999 15:13:09 +1030 (CST) (envelope-from doconnor@gsoft.com.au) 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 In-Reply-To: <199902180436.VAA64812@harmony.village.org> Date: Thu, 18 Feb 1999 15:13:09 +1030 (CST) From: "Daniel O'Connor" To: Warner Losh Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: hackers@FreeBSD.ORG, Matthew Dillon Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Feb-99 Warner Losh wrote: > Linux's system call still modifies things. However, there is a > bsd_select in most libraries that does the right thing, at least the > thing that all other oses do. Yeah, well, given the man page says you shouldn't assume the tv doesn't change, maybe they thought they could make things better :) I suppose it was naivity showing through.. Of course, who reads man pages anyway? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 20:56: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 4C67011412 for ; Wed, 17 Feb 1999 20:56:04 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DLVH-0007WI-00; Wed, 17 Feb 1999 21:55:59 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id VAA64976; Wed, 17 Feb 1999 21:58:50 -0700 (MST) Message-Id: <199902180458.VAA64976@harmony.village.org> To: "Daniel O'Connor" Subject: Re: portability of shm, mmap, pipes and socket IPC Cc: hackers@FreeBSD.ORG, Matthew Dillon In-reply-to: Your message of "Thu, 18 Feb 1999 15:13:09 +1030." References: Date: Wed, 17 Feb 1999 21:58:50 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Daniel O'Connor" writes: : Yeah, well, given the man page says you shouldn't assume the tv : doesn't change, maybe they thought they could make things better :) : I suppose it was naivity showing through.. I survived the Linux experience with this. There were a huge number of bugs were the system would use 100% of the systems. That isn't the improvement. It was a bad idea then, and it is a bad idea now as well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 21: 3: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 9E61011644 for ; Wed, 17 Feb 1999 21:02:13 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DLbI-0007WX-00; Wed, 17 Feb 1999 22:02:12 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id WAA65049 for ; Wed, 17 Feb 1999 22:05:03 -0700 (MST) Message-Id: <199902180505.WAA65049@harmony.village.org> Subject: select(2) proposed change To: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 17 Feb 1999 21:58:50 MST." <199902180458.VAA64976@harmony.village.org> References: <199902180458.VAA64976@harmony.village.org> Date: Wed, 17 Feb 1999 22:05:02 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please review the following change to the select(2) man page: Index: select.2 =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/sys/select.2,v retrieving revision 1.11 diff -u -r1.11 select.2 --- select.2 1998/08/24 01:09:34 1.11 +++ select.2 1999/02/18 05:02:28 @@ -186,6 +186,12 @@ by the .Fn select call. +Other systems may modify timeout, but no current ones do it by default. +A future, different system call might modify this change, but too +much legacy code exists which depends on this behavior. +Therefore, +.Fn select +will likely never change to modify timeout. .Sh HISTORY The .Fn select Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 21: 8:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id DB60210E6F for ; Wed, 17 Feb 1999 21:08:34 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DLhR-0007Wp-00; Wed, 17 Feb 1999 22:08:33 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id WAA65110 for ; Wed, 17 Feb 1999 22:11:24 -0700 (MST) Message-Id: <199902180511.WAA65110@harmony.village.org> Subject: Re: select(2) proposed change To: hackers@FreeBSD.ORG In-reply-to: Your message of "Wed, 17 Feb 1999 22:05:02 MST." <199902180505.WAA65049@harmony.village.org> References: <199902180505.WAA65049@harmony.village.org> <199902180458.VAA64976@harmony.village.org> Date: Wed, 17 Feb 1999 22:11:24 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902180505.WAA65049@harmony.village.org> Warner Losh writes: : Please review the following change to the select(2) man page: Actually, please review these changes. They are closer to english than the last one. Warner Index: select.2 =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/sys/select.2,v retrieving revision 1.11 diff -u -r1.11 select.2 --- select.2 1998/08/24 01:09:34 1.11 +++ select.2 1999/02/18 05:09:01 @@ -186,6 +186,12 @@ by the .Fn select call. +Other systems may modify timeout, but no current ones do it by default. +A future, different system call might modify timeval, but too much legacy +code exists which depends on this behavior. +Therefore, +.Fn select +will likely never change to modify timeout. .Sh HISTORY The .Fn select To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 22:46:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 6582810E64 for ; Wed, 17 Feb 1999 22:41:15 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id WAA15488 for ; Wed, 17 Feb 1999 22:10:41 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id WAA69235 for hackers@freebsd.org; Wed, 17 Feb 1999 22:10:41 -0800 (PST) (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, 17 Feb 1999 22:10:41 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: hackers@freebsd.org Subject: UIDs greater than 65535? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can anybody think of a reason why UIDs > 65535 wouldn't work under FreeBSD? They seem to work, and I can't find any reason why they shouldn't. Even the NFS protocol (though not necessarily all NFS servers) seems to be able to accomodate 4-byte UIDs. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 22:49:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 9006210FC3 for ; Wed, 17 Feb 1999 22:49:09 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id HAA20894 for ; Thu, 18 Feb 1999 07:13:42 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id HAA07266 for ; Thu, 18 Feb 1999 07:13:43 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA03908 for ; Thu, 18 Feb 1999 07:13:43 +0100 (CET) Date: Thu, 18 Feb 1999 07:13:42 +0100 From: Andre Albsmeier To: Julian Elischer Cc: Andre Albsmeier , Takanori Saneto , freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? Message-ID: <19990218071342.C2737@internal> References: <19990217213511.A1459@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Julian Elischer on Wed, Feb 17, 1999 at 03:55:38PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17-Feb-1999 at 15:55:38 -0800, Julian Elischer wrote: > WHY would you async mount an MFS? > it's an MFS! > (?) Don't know :-). I have taken the fstab line as it was posted on a list quite a while ago. I didn't ask myself about it because it always worked, but I think you are right, of course. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 23:10:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 0240410E64 for ; Wed, 17 Feb 1999 23:10:32 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id WAA15554; Wed, 17 Feb 1999 22:39:47 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id WAA69320; Wed, 17 Feb 1999 22:39:47 -0800 (PST) (envelope-from jdp@polstra.com) Date: Wed, 17 Feb 1999 22:39:47 -0800 (PST) Message-Id: <199902180639.WAA69320@vashon.polstra.com> To: kbyanc@freedomnet.com Subject: Re: symbol export question In-Reply-To: <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com>, Kelly Yancey wrote: > > I saw a similar question pop up a few days ago relating to Apache's DSO > model, but I never saw an answer. I have a similar problem that I'm hoping > that someone with more dynamic library experience can help me with... > > I have written a program which loads dynamic libraries using dlopen() and > friends to implement optional functionality. The main executable can call > dlsym() to properly resolve the symbols in the libraries and the libraries > can call symbols exported from the main executable. Everything works. Now, > for the trick...the only reason I can get it to work right is because I pass > the -Xlinker -E parameter(s) to gcc so that it tells ld to export *all* the > symbols in each the main executable and the modules. While this works, it > seems like a nasty kludge. No, it's the only way to do what you want to do. If you think it's a kludge, consider that it was the default in the a.out tools. You just didn't notice it before. :-) > I looked at the PAM sources under /usr/src/lib/libpam and see that if PAM > is compiled to use dynamic modules, it defines PAM_EXPORT as extern (which > is then in turn used for each symbol declaration to be exported). Well, I > have 2 problems with that: That's an entirely separate thing, which has nothing to do with your question above. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Feb 17 23:43:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id CA32D11128 for ; Wed, 17 Feb 1999 23:43:35 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id RAA07295; Thu, 18 Feb 1999 17:42:19 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma007279; Thu, 18 Feb 99 17:42:13 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id RAA15496; Thu, 18 Feb 1999 17:42:13 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id RAA19362; Thu, 18 Feb 1999 17:42:12 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id RAA27123; Thu, 18 Feb 1999 17:42:10 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199902180742.RAA27123@nymph.detir.qld.gov.au> To: Warner Losh Cc: freebsd-hackers@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: select(2) proposed change References: <199902180511.WAA65110@harmony.village.org> In-Reply-To: <199902180511.WAA65110@harmony.village.org> from Warner Losh at "Wed, 17 Feb 1999 22:11:24 -0700" Date: Thu, 18 Feb 1999 17:42:10 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 17th February 1999, Warner Losh wrote: >Actually, please review these changes. They are closer to english >than the last one. >+Other systems may modify timeout, but no current ones do it by default. I am possibly displaying my ignorance, but I thought linux did this by default. >+A future, different system call might modify timeval, but too much legacy >+code exists which depends on this behavior. >+Therefore, >+.Fn select >+will likely never change to modify timeout. I would prefer to keep the fire and brimstone warning. select() should be changed to do the subtraction. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0: 3:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from detlev.UUCP (56-sweet.camalott.com [208.239.153.56]) by hub.freebsd.org (Postfix) with ESMTP id 8CC5C1132B; Thu, 18 Feb 1999 00:02:48 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.2/8.9.1) id CAA02100; Thu, 18 Feb 1999 02:01:27 -0600 (CST) (envelope-from joelh) To: Greg Lehey Cc: Terry Lambert , Eivind Eklund , hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? References: <19990216170310.C60651@bitbox.follo.net> <199902170227.TAA16880@usr08.primenet.com> <19990217133032.A515@lemis.com> From: Joel Ray Holveck Date: 18 Feb 1999 02:01:24 -0600 In-Reply-To: Greg Lehey's message of "Wed, 17 Feb 1999 13:30:32 +1030" Message-ID: <864sok9m3v.fsf@detlev.UUCP> Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> Anybody know of any way of getting gdb to step from the start of the >>> program? >>> I have an executable with absolutely no symbol data (symbol data is >>> absolutely non-available) which I *have* to get to step through, if >>> necessary by re-implementing gdb. >> One really snotty way to do it is to write a small program that >> exec's the other program, and follow it through the exec. I've used >> this technique to work on ld.so before. > Does this work on ELF executables? I used this technique (using ld.so) to debug Emacs when I brought it to FreeBSD-ELF. This was before ELF became stabilized, but it used to work. Cheers, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0:13: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id D3D7E1129A for ; Thu, 18 Feb 1999 00:12:52 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DOZn-0007dh-00; Thu, 18 Feb 1999 01:12:51 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id BAA66534; Thu, 18 Feb 1999 01:15:44 -0700 (MST) Message-Id: <199902180815.BAA66534@harmony.village.org> To: Stephen McKay Subject: Re: select(2) proposed change Cc: freebsd-hackers@freebsd.org In-reply-to: Your message of "Thu, 18 Feb 1999 17:42:10 +1000." <199902180742.RAA27123@nymph.detir.qld.gov.au> References: <199902180742.RAA27123@nymph.detir.qld.gov.au> <199902180511.WAA65110@harmony.village.org> Date: Thu, 18 Feb 1999 01:15:43 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902180742.RAA27123@nymph.detir.qld.gov.au> Stephen McKay writes: : On Wednesday, 17th February 1999, Warner Losh wrote: : : >Actually, please review these changes. They are closer to english : >than the last one. : : >+Other systems may modify timeout, but no current ones do it by default. : : I am possibly displaying my ignorance, but I thought linux did this : by default. No. Linux used to do this by default, but no longer does it by default. There is a separate system call to do that. I must confess that I do not have a Linux system to absolutely verify this on, however. : >+A future, different system call might modify timeval, but too much legacy : >+code exists which depends on this behavior. : >+Therefore, : >+.Fn select : >+will likely never change to modify timeout. : : I would prefer to keep the fire and brimstone warning. Nothing has been remvoed, the warning is still there. : select() should : be changed to do the subtraction. Select should *NEVER* be changed to do the subtraction. There are *NO* current systems that do this by default. FreeBSD shouldn't change. It is a *********S***T***U***P***I***D********** idea to change the semantics of select(2) at this late stage of the game. I've been there with the Linux experiment back in the 0.99p14 timeframe of Linux. I cannot tell you the number of bogus programs out there that caused 100% cpu usage. If I recall my history correctly, a new system call was added, __bsd_select, which didn't change the timeout parameter. select was #defined to this, unless you did something to prevent it. I think at first this was in the -lbsd library that merged into libc over time and is now the default. I'll check with my Linux running friends to verify things. If you want to create a __linux_select or select2 or some *OTHER* system call that does this for you, then I have no objections. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0:13:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 30B7E113CF for ; Thu, 18 Feb 1999 00:13:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA19769; Thu, 18 Feb 1999 00:13:22 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Feb 1999 00:13:22 -0800 (PST) From: Matthew Dillon Message-Id: <199902180813.AAA19769@apollo.backplane.com> To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: select(2) proposed change References: <199902180505.WAA65049@harmony.village.org> <199902180458.VAA64976@harmony.village.org> <199902180511.WAA65110@harmony.village.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think it's a good clarification. -Matt Matthew Dillon : :In message <199902180505.WAA65049@harmony.village.org> Warner Losh writes: :: Please review the following change to the select(2) man page: : :Actually, please review these changes. They are closer to english :than the last one. : :Warner : :Index: select.2 :=================================================================== :RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/sys/select.2,v :retrieving revision 1.11 :diff -u -r1.11 select.2 :--- select.2 1998/08/24 01:09:34 1.11 :+++ select.2 1999/02/18 05:09:01 :@@ -186,6 +186,12 @@ : by the : .Fn select : call. :+Other systems may modify timeout, but no current ones do it by default. :+A future, different system call might modify timeval, but too much legacy :+code exists which depends on this behavior. :+Therefore, :+.Fn select :+will likely never change to modify timeout. : .Sh HISTORY : The : .Fn select : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0:29:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 4852511218 for ; Thu, 18 Feb 1999 00:27:59 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DOoK-0007eK-00; Thu, 18 Feb 1999 01:27:52 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id BAA66657; Thu, 18 Feb 1999 01:30:44 -0700 (MST) Message-Id: <199902180830.BAA66657@harmony.village.org> Subject: Re: select(2) proposed change To: Stephen McKay , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 18 Feb 1999 01:15:43 MST." <199902180815.BAA66534@harmony.village.org> References: <199902180815.BAA66534@harmony.village.org> <199902180742.RAA27123@nymph.detir.qld.gov.au> <199902180511.WAA65110@harmony.village.org> Date: Thu, 18 Feb 1999 01:30:43 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902180815.BAA66534@harmony.village.org> Warner Losh writes: : I've been there with the Linux experiment back in the 0.99p14 : timeframe of Linux. I cannot tell you the number of bogus programs : out there that caused 100% cpu usage. If I recall my history : correctly, a new system call was added, __bsd_select, which didn't : change the timeout parameter. select was #defined to this, unless you : did something to prevent it. I think at first this was in the -lbsd : library that merged into libc over time and is now the default. I'll : check with my Linux running friends to verify things. I've looked at the kernel more closely. The is sys_select which will, unless STICKY_TIMEOUTS is set, update the timeout. I don't have the sources to libc handy, but I do know that there are two flavors of select available. I'm unable to verify which one is actually the default. STICKY_TIMEOUTS is set when the personality is anything except PER_LINUX. Well, it isn't set for PER_BSD, but that is wrong since *NO* BSD based OS that I've ever seen has touched timeout. It is late, and I don't have the energy to look on the net to find the libc sources to check. The only Linux machine that i have access to is one that is running 1.1., which isn't exactly a current machine. Anyway, the point does remain that Linux is the *ONLY* os to *EVER* writeback timeout. And it takes no care, as far as I can tell, to ensure that the timeout value is used quickly enough in the general case for it not to suffer from race conditions which limit its usefulness. Finally, I do agree that new code should not assume that timeout is const. Just don't change FreeBSD to stomp on this value. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0:36:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 2969411099 for ; Thu, 18 Feb 1999 00:36:41 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id JAA13649 for ; Thu, 18 Feb 1999 09:36:38 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id JAA28048 for ; Thu, 18 Feb 1999 09:36:38 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id JAA04808 for ; Thu, 18 Feb 1999 09:36:39 +0100 (CET) Date: Thu, 18 Feb 1999 09:36:37 +0100 From: Andre Albsmeier To: John Polstra Cc: hackers@FreeBSD.ORG Subject: Re: UIDs greater than 65535? Message-ID: <19990218093637.A1696@internal> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from John Polstra on Wed, Feb 17, 1999 at 10:10:41PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17-Feb-1999 at 22:10:41 -0800, John Polstra wrote: > Can anybody think of a reason why UIDs > 65535 wouldn't work under > FreeBSD? They seem to work, and I can't find any reason why they > shouldn't. Even the NFS protocol (though not necessarily all NFS > servers) seems to be able to accomodate 4-byte UIDs. I can only tell that quotas get big problems with ultra large uid's. See PR# 2325. I have a local fix here... it is ugly as sin and it doesn't fix the problem but the effects. -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 0:56:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 2F0EF10E9F for ; Thu, 18 Feb 1999 00:56:55 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id AAA02681; Thu, 18 Feb 1999 00:54:16 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id AAA20324; Thu, 18 Feb 1999 00:54:15 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id AAA18603; Thu, 18 Feb 1999 00:54:13 -0800 (PST) From: Don Lewis Message-Id: <199902180854.AAA18603@salsa.gv.tsc.tdk.com> Date: Thu, 18 Feb 1999 00:54:12 -0800 In-Reply-To: Julian Elischer "Re: softupdate panic, anyone seen this?" (Feb 17, 3:55pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Julian Elischer , Andre Albsmeier Subject: Re: softupdate panic, anyone seen this? Cc: Takanori Saneto , freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 17, 3:55pm, Julian Elischer wrote: } Subject: Re: softupdate panic, anyone seen this? } WHY would you async mount an MFS? } it's an MFS! mount_mfs automagically sets the async flag To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 1:13: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id ECC5511031 for ; Thu, 18 Feb 1999 01:12:59 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id BAA02792; Thu, 18 Feb 1999 01:12:52 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id BAA20378; Thu, 18 Feb 1999 01:12:51 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id BAA18642; Thu, 18 Feb 1999 01:12:50 -0800 (PST) From: Don Lewis Message-Id: <199902180912.BAA18642@salsa.gv.tsc.tdk.com> Date: Thu, 18 Feb 1999 01:12:50 -0800 In-Reply-To: Jake "Re: softupdate panic, anyone seen this?" (Feb 17, 7:30pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Jake , hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Feb 17, 7:30pm, Jake wrote: } Subject: Re: softupdate panic, anyone seen this? } > > * mfs process aborts with signal 11. } > > * Hang after "syncing disks ... done" message. } > } > occasionaly I see the "panic: softdep_sync_metadata: Unknown type bmsafemap" After reading the source for softdep_sync_metadata(), I might believe this could happen if the system tried to sync the block device for a softdep filesystem before had synced all the files. } I was seeing all of this and other wierdness when I had mfs's mounted } on /tmp and /var/tmp. I don't know why MFS would have an effect on this. The only two things I can think of are either swapping to a file on a softdep filesystem, or somehow the softupdates stuff thinks it should be active on the MFS filesystems. What does /sbin/mount say about the mount flags on these filesystems? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 1:22:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 2FB3C113D0 for ; Thu, 18 Feb 1999 01:20:34 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id TAA10489; Thu, 18 Feb 1999 19:19:21 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma010483; Thu, 18 Feb 99 19:19:09 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id TAA17954; Thu, 18 Feb 1999 19:19:09 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id TAA23384; Thu, 18 Feb 1999 19:19:08 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id TAA29044; Thu, 18 Feb 1999 19:19:07 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199902180919.TAA29044@nymph.detir.qld.gov.au> To: Warner Losh Cc: Stephen McKay , freebsd-hackers@freebsd.org Subject: Re: select(2) proposed change References: <199902180742.RAA27123@nymph.detir.qld.gov.au> <199902180511.WAA65110@harmony.village.org> <199902180815.BAA66534@harmony.village.org> In-Reply-To: <199902180815.BAA66534@harmony.village.org> from Warner Losh at "Thu, 18 Feb 1999 01:15:43 -0700" Date: Thu, 18 Feb 1999 19:19:07 +1000 From: Stephen McKay Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 18th February 1999, Warner Losh wrote: >In message <199902180742.RAA27123@nymph.detir.qld.gov.au> Stephen McKay writes >: >: On Wednesday, 17th February 1999, Warner Losh wrote: >: >: >+Other systems may modify timeout, but no current ones do it by default. >: >: I am possibly displaying my ignorance, but I thought linux did this >: by default. > >No. Linux used to do this by default, but no longer does it by >default. There is a separate system call to do that... Well, OK then. Perhaps the wording should simply be that "No current systems modify timeout by default." >: select() should >: be changed to do the subtraction. > >Select should *NEVER* be changed to do the subtraction. There are >*NO* current systems that do this by default. FreeBSD shouldn't >change. It is a *********S***T***U***P***I***D********** idea to >change the semantics of select(2) at this late stage of the game. Don't hold back! Say what you really mean! ;-) >I've been there with the Linux experiment back in the 0.99p14 >timeframe of Linux. I cannot tell you the number of bogus programs >out there that caused 100% cpu usage... >If you want to create a __linux_select or select2 or some *OTHER* >system call that does this for you, then I have no objections. Well, no, I don't intend to add any modified select() yet. Perhaps when (and if) we add pselect (the variant that uses timespec instead of timeval) I might make a case for modifying timeout. I still think it is the right thing to do. Though I suppose some people might come after me with pitchforks. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 1:41:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id E6660115F4 for ; Thu, 18 Feb 1999 01:41:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id JAA63680; Thu, 18 Feb 1999 09:40:50 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 18 Feb 1999 09:40:50 +0000 (GMT) From: Doug Rabson To: AARON MARKS Cc: freebsd-hackers@freebsd.org, Matthew Dillon Subject: Re: Memory-Based VFS Question In-Reply-To: <36CB1C9B.77725962@sarnoff.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, AARON MARKS wrote: > I appologize for the ignorance, but: > > Terry Lambert wrote: > > > > The generic code assumes a vnode as a backing store. If he does not > > have a vnode as a backing store, he can not use the generic code. > > What do you mean using a vnode as a backing store? A file in my MFS has > a vnode allocated to it. > > > > > Basically, if he could use it, since that's the default that's > > inherited from the default ops vector, it'd already be working, > > and he wouldn't be asking the question. > > > > He's asking, so ipso facto, he's not using a vnode as backing store. > > > > This makes sense, since he said he's writing a new MFS; he's probably > > managing the page allocation himself from the KVA space. > > I think so. I allocate blocks of 8k memory and grow as necessary. > > > > > To answer the question: pattern your code after the code in the file > > /sys/vm/device_pager.c's dev_pager_getpages()/dev_pager_putpages() > > code, and you should be OK. > > Great. I'll take a look-see. > > I have another question, though: I mapped my _{get,put}pages functions > (they're empty, just print to console and return 0) to the vop functions > but when I do a system file copy (via cp), the OS never calls my > {get,put}pages functions. Strange. Are they in the table of vnode ops for your filesystem? Try setting a breakpoint in the vm code where it is about to call VOP_GETPAGES and single step to see where it goes. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 1:58: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 2E91010EA0; Thu, 18 Feb 1999 01:58:01 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 18 Feb 1999 09:57:59 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id F1KNMK1W; Thu, 18 Feb 1999 09:52:32 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10DQFo-000PGu-00; Thu, 18 Feb 1999 10:00:20 +0000 To: Terry Lambert Cc: grog@lemis.com (Greg Lehey), eivind@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? X-Mailer: nmh v0.26 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Terry Lambert's message of "Wed, 17 Feb 1999 18:29:53 GMT" <199902171829.LAA19473@usr07.primenet.com> Date: Thu, 18 Feb 1999 10:00:19 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17 February 1999, Terry Lambert proclaimed: > I occasionally use the Microsoft source level debugger (I have to > admit that getting the contents of variables as a tool-tip, merely > by leaving the mouse pointer over them for a second is pretty damn > cool), Have you looked at ddd? It's in the ports collection and it does that, too. It's rather nifty. It may also have some replay abilities; I've not looked into that though. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 6:13:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 608) id 3EB91113CF; Thu, 18 Feb 1999 06:13:29 -0800 (PST) From: "Jonathan M. Bresler" To: freebsd-hackers@freebsd.org Subject: FreeBSD-Rio released (fwd) Message-Id: <19990218141329.3EB91113CF@hub.freebsd.org> Date: Thu, 18 Feb 1999 06:13:29 -0800 (PST) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Boisvert sent this message to the list, but it bounced....nonetheless its a matter of interest to the FreeBSD community. From: "Peter M. Chen" Subject: Announcing Rio for FreeBSD The Rio (RAM I/O) project at Michigan is pleased to release an implementation of the Rio file cache for FreeBSD. The basic idea of Rio is to make memory as safe as disk from operating system crashes. Such "reliable main memory" is useful in a variety of contexts: * file systems: reliable main memory provides the semantics of synchronous writes with the performance of a pure write-back file system. The only disk writes needed are when the file cache becomes full. * transaction systems: reliable main memory allows a very simple and fast implementation of atomic, durable actions. We've built such a system, called Vista, that can achieve 2000x lower overhead per transaction than a comparable transaction system. Vista transactions can be done in a few microseconds. * checkpointing: Discount Checking is a checkpointing library that allows general applications to recover from operating system and application crashes. Discount Checking builds on Rio's reliable main memory and Vista's fast transactions to achieve very low overhead and a high degree of transparency. Discount Checking slows real applications down by less than 0.6%, even while taking checkpoints frequently enough to save every externally visible event. Discount Checking makes application and OS crashes appear as if the application pauses and resumes. Papers describing Rio, Vista, and Discount Checking are available on the Rio web page (http://www.eecs.umich.edu/Rio). Wee Teck Ng and Peter M. Chen EECS Department University of Michigan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 6:24:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (Postfix) with SMTP id 6E1F211424 for ; Thu, 18 Feb 1999 06:23:03 -0800 (PST) (envelope-from rminnich@Sarnoff.COM) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA14661; Thu, 18 Feb 1999 09:22:57 -0500 Date: Thu, 18 Feb 1999 09:22:57 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: freebsd-hackers@FreeBSD.ORG Subject: Re: Memory-Based VFS Question In-Reply-To: <36CB1C9B.77725962@sarnoff.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To fill in some detail: aaron is writing the memory-based file system that I mentioned on this list a few years back. This is NOT an MFS. This is more like the "malloc file system", i.e. the file system maintains its own inodes in memory, as well as data. This is eventually going to support private name spaces for FreeBSD, but in the intermediate step I think you folks might find other uses for it too. At the very least I think it will be a useful "vfs tutorial". Aaron has lots of stuff working at this point. ron Ron Minnich |"There is no neat distinction between operating system rminnich@sarnoff.com | software and the software that runs on top of it" (609)-734-3120 | Jim Allchin, Microsoft. [[[ No Comment ... ]]] ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 6:26: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id D61FE11419 for ; Thu, 18 Feb 1999 06:25:57 -0800 (PST) (envelope-from lile@stdio.com) Received: from heathers.stdio.com (lile@heathers.stdio.com [199.89.192.5]) by heathers.stdio.com (8.8.8/8.8.8) with ESMTP id JAA14687 for ; Thu, 18 Feb 1999 09:14:52 -0500 (EST) (envelope-from lile@stdio.com) Date: Thu, 18 Feb 1999 09:14:52 -0500 (EST) From: Larry Lile To: hackers@freebsd.org Subject: sockaddr_dl and source routing for token-ring Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am now working on source routing for the generic token-ring code and it appears that sockaddr_dl is the proper place to store the RIF. What I am curious about is what is the "proper" way to store the information in sockaddr_dl? struct sockaddr_dl { u_char sdl_len; /* Total length of sockaddr */ u_char sdl_family; /* AF_DLI */ u_short sdl_index; /* if != 0, system given index for interface */ u_char sdl_type; /* interface type */ u_char sdl_nlen; /* interface name length, no trailing 0 reqd. */ u_char sdl_alen; /* link level address length */ u_char sdl_slen; /* link layer selector length */ char sdl_data[12]; /* minimum work area, can be larger; contains both if name and ll address */ }; Should I just add "u_short sdl_routing[32] /* Token-ring source route */" or should I append the RIF to the end of sdl_data making it "sdl_data[78]". I prefer adding sdl_routing so that it could be #ifdef'd out of the kernel when no token-ring is present. The length of the RIF can be determined from the first two bytes so either way I should not have to add an sdl_xlen. The reason it is 32 u_short's long is that some token-ring vendors now allow 30 routing segments instead of the IBM standard of 16. Would this break anything in the network stack? Which method is more appropriate? Is there another more preferable method? Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 6:35:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id C4A6011552 for ; Thu, 18 Feb 1999 06:35:46 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id PAA97124; Thu, 18 Feb 1999 15:32:18 +0100 (CET) (envelope-from des) To: perlsta Cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: From: Dag-Erling Smorgrav Date: 18 Feb 1999 15:32:17 +0100 In-Reply-To: perlsta's message of "Tue, 16 Feb 1999 12:49:59 -0500 (EST)" Message-ID: Lines: 20 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG perlsta writes: > > > > > the C spec says that the BSS contains zeroes, so it's > > > > > typically assumed that all unitialised globals will be zeroed. > > If this is something that can be relied upon, why add implicit zero's in the > > code? > because lazy coders have depended on that feature for years now, and > changing it would break too many things. not only that but it's nice to > know that _some_ things will be zero'd out for you. If you have a *lot* of global data in your app, you basically have a choice between a) initializing them in main(), b) spending some CPU cycles zeroing the BSS at load time, or c) initializing them explicitly in the source code, which will move them into DATA and eat up disk space. Kind of stupid to waste disk space on a lot of zeroes. That leaves you with a) and b), and b) makes it easier on the programmer (though personally I wouldn't consider a) a big nuisance) DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 6:51:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from digistar.digistar.com (digistar.com [12.14.241.201]) by hub.freebsd.org (Postfix) with ESMTP id 29F2910EAD; Thu, 18 Feb 1999 06:51:53 -0800 (PST) (envelope-from freebsd@digistar.com) Received: from localhost (freebsd@localhost) by digistar.digistar.com (8.9.3/8.9.3/jsb) with ESMTP id IAA01754; Thu, 18 Feb 1999 08:51:53 -0600 Date: Thu, 18 Feb 1999 08:51:53 -0600 (CST) From: freebsd@digistar.com To: Undisclosed recipients: ; Subject: data buffers, disk i/o jsb Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, Is there a compile-time option that I can compile into the kernel to improve disk caching/buffering? I'm new to the list; if I'm in the wrong list, my apologies. My concern/question is I have recently put together a 2.2.8 test server and noticed that disk access is not up to expectations and I am looking for a way to remedy it. For example, when doing a du or a find across a single slice, the disk is physically accessed every time I du or find. I had expected the first find or du access to read and buffer the first pass, and the second find or du to read from the disk cache or buffer. It seems like there's a lot of wasted disk i/o when it could be avoided by reading from the disk cache. Also, if I boot from the boot floppy for installtion and install the ports collection, the install moves at a much faster pace, like 15K/s. If I install the ports collection after the install is completed (booting from the hard disk) the install takes FOREVER, like 2K/s and there is a HUGE amount of disk access. Is there a compile-time option that I can compile into the kernel to improve disk caching/buffering? Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 7:19:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-spool.is.co.za (mail-spool.is.co.za [196.4.160.4]) by hub.freebsd.org (Postfix) with ESMTP id 09B7A114D3 for ; Thu, 18 Feb 1999 07:19:22 -0800 (PST) (envelope-from geoffr@is.co.za) Received: from admin.is.co.za (admin.is.co.za [196.23.0.9]) by mail-spool.is.co.za (8.8.8/IShub#3) with ESMTP id RAA12474 for ; Thu, 18 Feb 1999 17:19:29 +0200 Received: from isjhbex01.is.co.za (isjhbex01.is.co.za [196.26.1.16]) by admin.is.co.za (8.8.6/8.7.3/ISsubsidiary#1) with ESMTP id RAA16269 for ; Thu, 18 Feb 1999 17:19:20 +0200 (GMT) Received: by isjhbex01.is.co.za with Internet Mail Service (5.5.2232.9) id <100PPLYC>; Thu, 18 Feb 1999 17:14:13 +0200 Message-ID: <3D5EC7D2992BD211A95600A0C9CE047F017E2265@isjhbex01.is.co.za> From: Geoff Rehmet To: "'hackers@freebsd.org'" Subject: Star Office 5 woes Date: Thu, 18 Feb 1999 17:14:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've managed to get (what appears to be) a successful Star Office 5 installation by following the transcript on lt.tar.com. However, when I try to register it, I run into the problem that I get a BASIC runtime error in the registration "wizard". I believe a number of other ppl have run into this same problem. Does anyone know how to resolve this? Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geoffr@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:15: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tabby.kudra.com (gw.kudra.com [199.6.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 4C5C7116EA for ; Thu, 18 Feb 1999 08:14:59 -0800 (PST) (envelope-from robert@kudra.com) Received: (from robert@localhost) by tabby.kudra.com (8.9.2/8.6.12) id LAA02709; Thu, 18 Feb 1999 11:14:56 -0500 (EST) Message-ID: <19990218111456.A2658@kudra.com> Date: Thu, 18 Feb 1999 11:14:56 -0500 From: Robert Sexton To: freebsd@digistar.com Cc: freebsd-hackers@freebsd.org Subject: Re: data buffers, disk i/o jsb References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from freebsd@digistar.com on Thu, Feb 18, 1999 at 08:51:53AM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 18, 1999 at 08:51:53AM -0600, freebsd@digistar.com wrote: > > hi, > > Is there a compile-time option that I can compile into the kernel to > improve disk caching/buffering? FreeBSD self tunes. Because of the Unified VM/Buffer Cache, resource allocation can change on the fly. Generally, it can tune itself better than you can. I'd have to defer to more experienced folks for a detailed explanation. > My concern/question is I have recently put together a 2.2.8 test server > and noticed that disk access is not up to expectations and I am looking > for a way to remedy it. I guess I'd have to ask what your expectations and needs are. You also haven't provided any details on your hardware. This is quite relevant to your question. > For example, when doing a du or a find across a single slice, the disk is > physically accessed every time I du or find. I had expected the first > find or du access to read and buffer the first pass, and the second find > or du to read from the disk cache or buffer. It seems like there's a lot > of wasted disk i/o when it could be avoided by reading from the disk > cache. This depends on the nature of the filesystem, and whats in it. In the case of /usr/ports, the tree is so mind bogglingly huge that it blows out most of the relevant caches. > Also, if I boot from the boot floppy for installtion and install the ports > collection, the install moves at a much faster pace, like 15K/s. If I > install the ports collection after the install is completed (booting from > the hard disk) the install takes FOREVER, like 2K/s and there is a HUGE > amount of disk access. This really can't be helped. The ports filesystem on one of my production machines contains almost 30k inodes. Building it is a nightmare. I'm told it'll build quite quickly on an asyncronous filesystem. (See Below) > Is there a compile-time option that I can compile into the kernel to > improve disk caching/buffering? None that I'm aware of. However, there are a number of other, better options. a. Mount filesystems with the noatime flag. This elimates a lot of inode updates when walking a large tree. b. Mount filesystems async. This provides terrific performance on large trees like ports, but is the digital equivalent of no seatbelts in a convertable. c. Switch to 3.0 and uses soft updates. This gives you most of the performance of async, but with a high degree of safety. -- Robert Sexton - robert@kudra.com, Cincinnati OH, USA As a software development model, Anarchy does not scale well. -Dave Welch Read the Newton FAQ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:26:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2B8EF11391 for ; Thu, 18 Feb 1999 08:26:15 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA22488 for ; Thu, 18 Feb 1999 08:26:01 -0800 Date: Thu, 18 Feb 1999 08:26:01 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-hackers@freebsd.org Subject: Panic in FFS/4.0 as of yesterday Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I started testing again to see what I could see. This is an alpha platform (*really* shouldn't matter, right? this ain't linux, this ain't no disco, pal....) Simple hardware. Alpha PC164 (432Mhz) with 256MB memory. Again, a very simple setup- just those stupid dirty buffer testing programs. A single 9GB filesystem (not root or swap). Softupdates not enabled, buf realloc still enabled (the 'default'- if it's broken, why ship with it enabled?). 100 instances of programs that write 150mb files and then check them one by one. The filesystem was nothing unusual- following concerns of others about CCD's this is wasn't even an CCD. Following concerns about fragsize and blocksize this was a Frag 1024 Blocksize 8192 (8192 is pagesize for alpha), and the actual size was truncated to make an exact geometry fit. System was completely unresponsive after starting this test. It eventually (I went home) started being responsive again since a 'sync' completed (thisis a usability problem, but I'l start whining about that when the system stays up long enough to be usable). When I came in this morning, it was in DDB with: panic: getnewbuf: cannot get buffer, infinite recursion failure panic Stopped at Debugger..ng+0x24: ldq ra,0(sp) <0xfffffe0007be59a0> db> t Debugger..ng() at Debugger..ng+0x24 panic..ng() at panic..ng+0xf0 getnewbuf..ng() at getnewbuf..ng+0x424 getblk..ng() at getblk..ng+0x3e0 bread..ng() at bread..ng+0x34 ffs_balloc..ng() at ffs_balloc..ng+0x784 ffs_write..ng() at ffs_write..ng+0x384 vn_write..ng() at vn_write..ng+0x160 write..ng() at write..ng+0x12c syscall..ng() at syscall..ng+0x1dc XentSys() at XentSys+0x50 (null)() at 0x120000fe8 Is it truly the case that other people don't find these panics? This is *not* that unusual a scenario for a server (well, maybe an NFS server, but there are most certainly other server types). -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:29:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 952E311559 for ; Thu, 18 Feb 1999 08:28:09 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10DWJ3-0000I4-00; Thu, 18 Feb 1999 18:28:05 +0200 From: Sheldon Hearn To: Geoff Rehmet Cc: "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes In-reply-to: Your message of "Thu, 18 Feb 1999 17:14:08 +0200." <3D5EC7D2992BD211A95600A0C9CE047F017E2265@isjhbex01.is.co.za> Date: Thu, 18 Feb 1999 18:28:05 +0200 Message-ID: <1119.919355285@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999 17:14:08 +0200, Geoff Rehmet wrote: > I believe a number of other ppl have run into this same problem. A number of people have, yes. -hackers is not the right list to find your answer on, though. Search the -current mailing list archive for "StarOffice AND BASIC" without the quotes. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:30:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 931BF11713 for ; Thu, 18 Feb 1999 08:30:01 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.1) id KAA41554; Thu, 18 Feb 1999 10:29:50 -0600 (CST) (envelope-from dick) Date: Thu, 18 Feb 1999 10:29:49 -0600 From: "Richard Seaman, Jr." To: Geoff Rehmet Cc: "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes Message-ID: <19990218102949.A38074@tar.com> References: <3D5EC7D2992BD211A95600A0C9CE047F017E2265@isjhbex01.is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3D5EC7D2992BD211A95600A0C9CE047F017E2265@isjhbex01.is.co.za>; from Geoff Rehmet on Thu, Feb 18, 1999 at 05:14:08PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Feb 18, 1999 at 05:14:08PM +0200, Geoff Rehmet wrote: > I've managed to get (what appears to be) a successful Star Office 5 > installation by following the transcript on lt.tar.com. > However, when I try to register it, I run into the problem that > I get a BASIC runtime error in the registration "wizard". > I believe a number of other ppl have run into this same problem. > Does anyone know how to resolve this? 1) Make sure you have your Office50/bin directory in your PATH environment. That seemed to fix it for me. 2) Others have reported that reinstalling seems to work 3) Others have reported that executing the "fix install" or whatever the command is called, has helped. 4) I think there are people who have not been able to solve this problem. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:56: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id E4B971177E for ; Thu, 18 Feb 1999 08:55:50 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id PAA12535; Wed, 17 Feb 1999 15:40:18 -0500 (EST) Date: Wed, 17 Feb 1999 15:30:08 -0500 (EST) From: perlsta Reply-To: perlsta To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: gdb sucks - and I need to get around it. help? In-Reply-To: <199902171829.LAA19473@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Terry Lambert wrote: > I actually *prefer* post-morteming core files, and instrumenting > the code such that I know what's going wrong. > > I occasionally use the Microsoft source level debugger (I have to > admit that getting the contents of variables as a tool-tip, merely > by leaving the mouse pointer over them for a second is pretty damn > cool), but like the VMS debugger (and, frequently, gdb), you have have you tried 'ddd' there is a statically linked Motif version in the packages collection, i find ddd VERY nice. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:56: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id BCB2A11671 for ; Thu, 18 Feb 1999 08:53:13 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id DAA26354; Thu, 18 Feb 1999 03:01:17 -0500 (EST) Date: Thu, 18 Feb 1999 02:51:07 -0500 (EST) From: Alfred Perlstein To: Warner Losh Cc: Dag-Erling Smorgrav , "Daniel C. Sobral" , Matthew Dillon , Christoph Kukulies , Peter Wemm , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC In-Reply-To: <199902180442.VAA64894@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 17 Feb 1999, Warner Losh wrote: > That's in the bugs section: > select() should probably return the time remaining from the original > timeout, if any, by modifying the time value in place. This may be im- > plemented in future versions of the system. Thus, it is unwise to assume > that the timeout value will be unmodified by the select() call. > > Notice "should" and "may be" It doesn't say "Will" or "does". > > : On the contrary, it is extremely useful for implementing higher-level > : timeouts. If you want to see the new installer come true, I need to > : implement protocol-level timeouts in libfetch, and that means either > : add a lot of gettimeofday() logic or fix select() to modify tv. > > Even if that represents an unavoidable race condition? Why has no one considered the idea of 'select2()' which would finally --------------------------------------------^^^ implement the argument modification? This would finally dispell confusion about what will do what, when where and why etc.. if properly documented of course. simple: select == non modifying behavior select2 == modifies Thisleaves legacy/dumb code alone and at the same time gives more functionality to applications that know how to use the interface... -Alfred > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 8:59:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.2.74]) by hub.freebsd.org (Postfix) with ESMTP id 565DC1178F for ; Thu, 18 Feb 1999 08:59:06 -0800 (PST) (envelope-from mmitchel@qualcomm.com) Received: from mmitchel (mmitchel.qualcomm.com [129.46.171.128]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id IAA14835; Thu, 18 Feb 1999 08:57:47 -0800 (PST) From: "Mike Mitchell" To: "Sheldon Hearn" , "Geoff Rehmet" Cc: Subject: RE: Star Office 5 woes Date: Thu, 18 Feb 1999 08:57:46 -0800 Message-ID: <000001be5b5f$ceb483b0$80ab2e81@mmitchel.qualcomm.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <1119.919355285@axl.noc.iafrica.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello The Windows version croaks big time if you use a "pound sign" (#) in any of the blanks during the registration process. Example "1000 Street Apt #55", be sure to drop the "#" from the entry. Mike Mitchell >-----Original Message----- >From: owner-freebsd-hackers@freebsd.org >[mailto:owner-freebsd-hackers@freebsd.org]On Behalf Of Sheldon Hearn >Sent: Thursday, February 18, 1999 8:28 AM >To: Geoff Rehmet >Cc: 'hackers@freebsd.org' >Subject: Re: Star Office 5 woes > > > > >On Thu, 18 Feb 1999 17:14:08 +0200, Geoff Rehmet wrote: > >> I believe a number of other ppl have run into this same problem. > >A number of people have, yes. -hackers is not the right list to find >your answer on, though. > >Search the -current mailing list archive for "StarOffice AND BASIC" >without the quotes. > >Ciao, >Sheldon. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 10: 6:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by hub.freebsd.org (Postfix) with ESMTP id 29AFE1174E for ; Thu, 18 Feb 1999 10:06:03 -0800 (PST) (envelope-from amarks@sarnoff.com) Received: from sarnoff.com ([130.33.14.232]) by postoffice.sarnoff.com (Netscape Messaging Server 3.5) with ESMTP id AAA52CA; Thu, 18 Feb 1999 13:05:52 -0500 Message-ID: <36CC56CA.BCBF6A4B@sarnoff.com> Date: Thu, 18 Feb 1999 13:07:06 -0500 From: "AARON MARKS" Reply-To: amarks@sarnoff.com Organization: Sarnoff Corporation X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG, Matthew Dillon Subject: Re: Memory-Based VFS Question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > > > I have another question, though: I mapped my _{get,put}pages functions > > (they're empty, just print to console and return 0) to the vop functions > > but when I do a system file copy (via cp), the OS never calls my > > {get,put}pages functions. > > Strange. Are they in the table of vnode ops for your filesystem? Try > setting a breakpoint in the vm code where it is about to call VOP_GETPAGES > and single step to see where it goes. Yes, they are in the vnodeopv_entry_desc structure as vop_getpages_desc and vop_putpages_desc. I stepped through the code and it goes to ufs_readwrite.c:ffs_getpages(). I also set breakpoints in my _getpages(), _putpages() functions and they never get called. -A. -- Aaron J. Marks Communications and Computing Systems Lab Assoc. Member Tech Staff Advanced Networks and Computation Group amarks@sarnoff.com Sarnoff Corporation To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11: 3:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 7278F1184B for ; Thu, 18 Feb 1999 11:03:19 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id OAA06719 for ; Thu, 18 Feb 1999 14:03:15 -0500 (EST) Message-Id: <199902181903.OAA06719@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 18 Feb 1999 14:13:20 -0500 To: hackers@freebsd.org From: Dennis Subject: cdrom.com bandwidth limits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seem obvious that ftp.cdrom.com has a limit of about 56kbs...is this a good idea? Considering that to download a release it now takes all day instead of 30 minutes, it substantially increases the chances of a failure and that multiple attempts will have to be made, which increases the overall bandwidth requirements rather than decreasing them. It also increases the number of simultanous downloads that are occuring. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11:22: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 59A5D11637 for ; Thu, 18 Feb 1999 11:21:57 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA02236; Thu, 18 Feb 1999 12:21:53 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id MAA10491; Thu, 18 Feb 1999 12:21:50 -0700 Date: Thu, 18 Feb 1999 12:21:50 -0700 Message-Id: <199902181921.MAA10491@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dennis Cc: hackers@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits In-Reply-To: <199902181903.OAA06719@etinc.com> References: <199902181903.OAA06719@etinc.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It seem obvious that ftp.cdrom.com has a limit of about 56kbs... Where do you get that idea? wcarchive.cdrom.com:/.2/FreeBSD/development/CVSup ncftp>get cvsupd-bin-15.3.tar.gz /dev/null Receiving file: /dev/null 100% 0 396701 bytes. ETA: 0:00 /dev/null: 396701 bytes received in 4.17 seconds, 92.83 K/s. wcarchive.cdrom.com:/.2/FreeBSD/development/CVSup ncftp> 93 K/s is *way* above 56kbs. Methink someone between you and WC has a limit. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11:43:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id CC44611424 for ; Thu, 18 Feb 1999 11:43:23 -0800 (PST) (envelope-from desar@club-internet.fr) Received: from club-internet.fr (ppp-175-103.velizy.club-internet.fr [195.36.175.103]) by front2.grolier.fr (8.9.0/8.9.2) with ESMTP id UAA25289 for ; Thu, 18 Feb 1999 20:43:21 +0100 (MET) Message-ID: <36CC6969.31F9BBEB@club-internet.fr> Date: Thu, 18 Feb 1999 19:26:34 +0000 From: Francois Desarmenien X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Searching an "old" BSD stdio Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello to all of you, May be some of you could help me. I have an old binary library, compiled with an old stdio implementation I'd like to relink on a modern system. So I'm looking everywhere for pointers to get an old BSD stdio, such as 4.2, which seems hard to find (at least for me). Thank you for any help you could give me, François Désarménien To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11:43:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 34284116A4 for ; Thu, 18 Feb 1999 11:43:40 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA17313; Thu, 18 Feb 1999 11:42:45 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdo17278; Thu Feb 18 19:42:26 1999 Date: Thu, 18 Feb 1999 11:42:10 -0800 (PST) From: Julian Elischer To: Don Lewis Cc: Jake , hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? In-Reply-To: <199902180912.BAA18642@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG remember that mfs is still a UFS and as such still calls the stub entrypoints for softupdates and is still subject to the 'syncer' daemon. On Thu, 18 Feb 1999, Don Lewis wrote: > On Feb 17, 7:30pm, Jake wrote: > } Subject: Re: softupdate panic, anyone seen this? > } > > * mfs process aborts with signal 11. > } > > * Hang after "syncing disks ... done" message. > } > > } > occasionaly I see the "panic: softdep_sync_metadata: Unknown type bmsafemap" > > After reading the source for softdep_sync_metadata(), I might believe this > could happen if the system tried to sync the block device for a softdep > filesystem before had synced all the files. > > } I was seeing all of this and other wierdness when I had mfs's mounted > } on /tmp and /var/tmp. > > I don't know why MFS would have an effect on this. The only two things > I can think of are either swapping to a file on a softdep filesystem, or > somehow the softupdates stuff thinks it should be active on the MFS > filesystems. What does /sbin/mount say about the mount flags on these > filesystems? > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11:49:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 4C756119E7 for ; Thu, 18 Feb 1999 11:49:24 -0800 (PST) (envelope-from sw@home.com) Received: from home.com ([24.1.73.90]) by mail.rdc1.sfba.home.com (InterMail v4.00.03 201-229-104) with ESMTP id <19990218194924.URJX12321.mail.rdc1.sfba.home.com@home.com>; Thu, 18 Feb 1999 11:49:24 -0800 Message-ID: <36CC6EB1.9EA987F4@home.com> Date: Thu, 18 Feb 1999 11:49:05 -0800 From: Sanjay Waghray Reply-To: sw@home.com Organization: Sanjay Waghray X-Mailer: Mozilla 4.5 [en]C-AtHome0405 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits References: <199902181903.OAA06719@etinc.com> <199902181921.MAA10491@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In fact I've seen transfer rates of uptp 600 K/s.... from a cable-modem connection. Nate Williams wrote: > > > It seem obvious that ftp.cdrom.com has a limit of about 56kbs... > > Where do you get that idea? > > wcarchive.cdrom.com:/.2/FreeBSD/development/CVSup > ncftp>get cvsupd-bin-15.3.tar.gz /dev/null > Receiving file: /dev/null > 100% 0 396701 > bytes. ETA: 0:00 > /dev/null: 396701 bytes received in 4.17 seconds, 92.83 K/s. > wcarchive.cdrom.com:/.2/FreeBSD/development/CVSup > ncftp> > > 93 K/s is *way* above 56kbs. Methink someone between you and WC has a > limit. > > Nate > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 11:53:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id 231FC1191D for ; Thu, 18 Feb 1999 11:53:22 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id OAA18754; Thu, 18 Feb 1999 14:53:12 -0500 (EST) Date: Thu, 18 Feb 1999 14:53:12 -0500 (EST) From: To: Nate Williams Cc: Dennis , hackers@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits In-Reply-To: <199902181921.MAA10491@mt.sri.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Nate Williams wrote: > 93 K/s is *way* above 56kbs. Methink someone between you and WC has a > limit. I routinely get 80-100 K/s to cdrom and numerous mirrors. -- Mike Hoskins Systems/Network Administrator SEI Data Network Services, Inc. http://www.seidata.com "In a world where an admin is rendered useless when the ball in his mouse has been taken out, its good to know that I know UNIX." -- toaster.sun4c.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 12:18:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9D06E113B8 for ; Thu, 18 Feb 1999 12:16:07 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA18269; Thu, 18 Feb 1999 12:08:44 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdS18262; Thu Feb 18 20:08:36 1999 Date: Thu, 18 Feb 1999 12:08:25 -0800 (PST) From: Julian Elischer To: Robert Sexton Cc: freebsd@digistar.com, freebsd-hackers@FreeBSD.ORG Subject: Re: data buffers, disk i/o jsb In-Reply-To: <19990218111456.A2658@kudra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Robert Sexton wrote: > > Also, if I boot from the boot floppy for installtion and install the ports > > collection, the install moves at a much faster pace, like 15K/s. If I > > install the ports collection after the install is completed (booting from > > the hard disk) the install takes FOREVER, like 2K/s and there is a HUGE > > amount of disk access. The install mounts the disk in ASYNC mode. if you do ityourself you leave it in sync mode which os slow for file creation and directory operations (which is about ll there is in the ports tree). In 3.x you can run in "soft updates" mode and get much better performance. > > This really can't be helped. The ports filesystem on one of my > production machines contains almost 30k inodes. > Building it is a nightmare. I'm told it'll build quite quickly on an > asyncronous filesystem. (See Below) > > > Is there a compile-time option that I can compile into the kernel to > > improve disk caching/buffering? > > None that I'm aware of. However, there are a number of other, better options. > > a. Mount filesystems with the noatime flag. > This elimates a lot of inode updates when walking a large tree. > b. Mount filesystems async. This provides terrific performance > on large trees like ports, but is the digital equivalent of > no seatbelts in a convertable. > c. Switch to 3.0 and uses soft updates. This gives you most of the > performance of async, but with a high degree of safety. yep julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 12:20:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1F97611817 for ; Thu, 18 Feb 1999 12:20:22 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.2/8.9.1) id VAA04531; Thu, 18 Feb 1999 21:20:21 +0100 (CET) (envelope-from des) To: hackers@freebsd.org Subject: [Alfred Perlstein ] Re: vm_page_zero_fill From: Dag-Erling Smorgrav Date: 18 Feb 1999 21:20:19 +0100 Message-ID: Lines: 53 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Start of forwarded message ------- Date: Thu, 18 Feb 1999 15:18:54 -0500 (EST) From: Alfred Perlstein To: Dag-Erling Smorgrav Subject: Re: vm_page_zero_fill Message-ID: Last night i was kinda bored so i started looking for things to optimize in freebsd, i noticed that the function src/sys/libkern/bcmp.c looked not optimal. After playing with "gcc -O -S bcmp.c" on several platforms, i386, sparc32, alpha. It seems to me that the function ought to be replaced with this: #include /* * bcmp -- vax cmpc3 instruction */ int bcmp(b1, b2, length) const void *b1, *b2; register size_t length; { register size_t i; for (i=0 ; i; Thu, 18 Feb 1999 13:02:02 -0800 (PST) (envelope-from vincef@penmax.com) Received: from rembrandt (rembrandt.penmax.com [10.1.3.2]) by penmax.com (8.8.8/8.8.8) with SMTP id QAA10569; Thu, 18 Feb 1999 16:05:47 -0500 (EST) (envelope-from vincef@penmax.com) Received: by rembrandt with Microsoft Mail id <01BE5B58.23FEBFA0@rembrandt>; Thu, 18 Feb 1999 16:02:53 -0500 Message-ID: <01BE5B58.23FEBFA0@rembrandt> From: Vincent Fleming To: "'Dennis'" , "hackers@FreeBSD.ORG" Subject: RE: cdrom.com bandwidth limits Date: Thu, 18 Feb 1999 16:02:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Huh? I just downloaded the ports collection at average speed above 50 k BYTES PER SECOND! Perhaps you just got it at a slow time. I've seen ftp.cdrom.com hit 200 k bytes per second. I've even installed FreeBSD off of it in less than 20 minutes, including ALL the sources and ports! Vince -----Original Message----- From: Dennis [SMTP:dennis@etinc.com] Sent: Thursday, February 18, 1999 2:13 PM To: hackers@FreeBSD.ORG Subject: cdrom.com bandwidth limits It seem obvious that ftp.cdrom.com has a limit of about 56kbs...is this a good idea? Considering that to download a release it now takes all day instead of 30 minutes, it substantially increases the chances of a failure and that multiple attempts will have to be made, which increases the overall bandwidth requirements rather than decreasing them. It also increases the number of simultanous downloads that are occuring. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 13:10:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id E2F231178F for ; Thu, 18 Feb 1999 13:09:49 -0800 (PST) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id QAA26581; Thu, 18 Feb 1999 16:09:29 -0500 (EST) Date: Thu, 18 Feb 1999 16:09:29 -0500 From: Christian Kuhtz To: Vincent Fleming Cc: "'Dennis'" , "hackers@FreeBSD.ORG" Subject: Re: cdrom.com bandwidth limits Message-ID: <19990218160929.Z12713@ns1.adsu.bellsouth.com> References: <01BE5B58.23FEBFA0@rembrandt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <01BE5B58.23FEBFA0@rembrandt>; from Vincent Fleming on Thu, Feb 18, 1999 at 04:02:52PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can only agree with Vincent. You got a slow sucky pipe. :) On Thu, Feb 18, 1999 at 04:02:52PM -0500, Vincent Fleming wrote: > Huh? I just downloaded the ports collection at average speed > above 50 k BYTES PER SECOND! > > Perhaps you just got it at a slow time. I've seen ftp.cdrom.com > hit 200 k bytes per second. I've even installed FreeBSD off of it in > less than 20 minutes, including ALL the sources and ports! > > Vince -- "Economics is extremely useful as a form of employment for economists." -- John Kenneth Galbraith [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 13:38: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id CD2F5119FF for ; Thu, 18 Feb 1999 13:35:52 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id VAA65515; Thu, 18 Feb 1999 21:35:56 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 18 Feb 1999 21:34:40 +0000 (GMT) From: Doug Rabson To: AARON MARKS Cc: freebsd-hackers@FreeBSD.ORG, Matthew Dillon Subject: Re: Memory-Based VFS Question In-Reply-To: <36CC56CA.BCBF6A4B@sarnoff.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, AARON MARKS wrote: > Doug Rabson wrote: > > > > > I have another question, though: I mapped my _{get,put}pages functions > > > (they're empty, just print to console and return 0) to the vop functions > > > but when I do a system file copy (via cp), the OS never calls my > > > {get,put}pages functions. > > > > Strange. Are they in the table of vnode ops for your filesystem? Try > > setting a breakpoint in the vm code where it is about to call VOP_GETPAGES > > and single step to see where it goes. > > Yes, they are in the vnodeopv_entry_desc structure as vop_getpages_desc > and vop_putpages_desc. I stepped through the code and it goes to > ufs_readwrite.c:ffs_getpages(). I also set breakpoints in my > _getpages(), _putpages() functions and they never get called. It can only get to ffs_getpages if the vnode is a UFS vnode (otherwise something really strange is going on). Are you sure that the vnode which was being paged was one of yours? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 13:58:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A70AC117A0 for ; Thu, 18 Feb 1999 13:58:20 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40350>; Fri, 19 Feb 1999 08:47:45 +1100 Date: Fri, 19 Feb 1999 08:58:07 +1100 From: Peter Jeremy Subject: Documenting sysctl knobs To: hackers@FreeBSD.ORG Message-Id: <99Feb19.084745est.40350@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to re-open this particular festering sore... I don't want to pick on Matt Dillon in particular, but a recent commit of his (dillon 1999/02/18 11:57:33 PST) states: > Add two swap tuneables to sysctl: > > vm.swap_async_max: 4 > vm.swap_cluster_max: 16 > > Recommended values are a cluster size of 8 or 16 pages. async_max is > about right for 1-4 swap devices. Reduce to 2 if swap is eating too much > bandwidth, or even 1 if swap is both eating too much bandwidth and sitting > on a slow network (10BaseT). > > The defaults work well across a broad range of configurations and should > normally be left alone. IMHO, this is the sort of documentation that is needed for all the tunable sysctl identifiers. The problem is that (IMHO again), CVS logs aren't the correct place for it - the information needs to be available to a sysadmin who doesn't have the CVS archive on-line (and may not even want to RTSL [*]). Adding several hundred bytes of text per identifier to the in-memory kernel image is also not the right place. man8/sysctl.8 may be a reasonable place, but it doesn't get updated (and the logistics involved in having lots of different people all trying to update a single file virtually guarantee that updates would be lost). Physically, the information needs to be in the source code near the sysctl OID definition - so it gets updated. It also needs to be accessible from either man or sysctl(8) - so the sysadmin doesn't need to rummage thru the source code. I can immediately think of two solutions: 1) Include the documentation as a parameter to the SYSCTL_OID macro (and it's various derivatives). This parameter gets inserted (as text) into an ELF section that's not loaded. sysctl(8) can locate the description by reading it out of the kernel image on disk. (The section could also be stripped out to reduce disk space if necessary). 2) Mark the documentation is some way (possibly, but not necessarily via the SYSCTL_OID macro) so that it can be easily extracted from the source by an awk or perl script and turned into a man page (or several) - ie there'd be a single automatically generated sysctl.oid(7) man page that documented all sysctl identifiers, or several man pages, each documenting a group of identifiers. [*] As a `production OS', it should not be necessary for the sysadmin to be intimately familiar with the source code. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 14:56: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 9F1A1118CB for ; Thu, 18 Feb 1999 14:55:57 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id WAA65754; Thu, 18 Feb 1999 22:55:47 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 18 Feb 1999 22:55:47 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Matthew Jacob wrote: > > I started testing again to see what I could see. This is an alpha platform > (*really* shouldn't matter, right? this ain't linux, this ain't no disco, > pal....) > > Simple hardware. Alpha PC164 (432Mhz) with 256MB memory. > > Again, a very simple setup- just those stupid dirty buffer testing > programs. A single 9GB filesystem (not root or swap). Softupdates not > enabled, buf realloc still enabled (the 'default'- if it's broken, why > ship with it enabled?). 100 instances of programs that write 150mb files > and then check them one by one. The filesystem was nothing unusual- > following concerns of others about CCD's this is wasn't even an CCD. > Following concerns about fragsize and blocksize this was a Frag 1024 > Blocksize 8192 (8192 is pagesize for alpha), and the actual size was > truncated to make an exact geometry fit. > > System was completely unresponsive after starting this test. It eventually > (I went home) started being responsive again since a 'sync' completed > (thisis a usability problem, but I'l start whining about that when the > system stays up long enough to be usable). > > When I came in this morning, it was in DDB with: > > panic: getnewbuf: cannot get buffer, infinite recursion failure I looked at this and I think this writerecursion test looks bogus (it certainly isn't recursing although it has obviously been entered by several independant process simultaneously. Could you send me the test program which makes this happen (alpha binary or source will do) and I'll try to reproduce it here on a spare 4G disk. It seems to me that the write recursion test should be done on a per-process basis. Perhaps the recursion count should be a field in struct proc. Sounds ugly though. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 15:20:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D56FE119C2 for ; Thu, 18 Feb 1999 15:19:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA27201; Thu, 18 Feb 1999 15:18:38 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Feb 1999 15:18:38 -0800 (PST) From: Matthew Dillon Message-Id: <199902182318.PAA27201@apollo.backplane.com> To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: Documenting sysctl knobs References: <99Feb19.084745est.40350@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We could do a javadoc like thingy where we document the item in a comment in the source code and then run a program to generate the documentation by scanning the the source. -Matt Matthew Dillon : :Just to re-open this particular festering sore... : :I don't want to pick on Matt Dillon in particular, but a recent commit :of his (dillon 1999/02/18 11:57:33 PST) states: : :> Add two swap tuneables to sysctl: :> :> vm.swap_async_max: 4 :> vm.swap_cluster_max: 16 :> :> Recommended values are a cluster size of 8 or 16 pages. async_max is :> about right for 1-4 swap devices. Reduce to 2 if swap is eating too much :> bandwidth, or even 1 if swap is both eating too much bandwidth and sitting :> on a slow network (10BaseT). :> :> The defaults work well across a broad range of configurations and should :> normally be left alone. : :IMHO, this is the sort of documentation that is needed for all the :tunable sysctl identifiers. The problem is that (IMHO again), CVS :logs aren't the correct place for it - the information needs to be :available to a sysadmin who doesn't have the CVS archive on-line (and :may not even want to RTSL [*]). Adding several hundred bytes of text :per identifier to the in-memory kernel image is also not the right :place. man8/sysctl.8 may be a reasonable place, but it doesn't get :updated (and the logistics involved in having lots of different :people all trying to update a single file virtually guarantee that :updates would be lost). : :Physically, the information needs to be in the source code near the :sysctl OID definition - so it gets updated. It also needs to be :accessible from either man or sysctl(8) - so the sysadmin doesn't need :to rummage thru the source code. : :I can immediately think of two solutions: :1) Include the documentation as a parameter to the SYSCTL_OID macro : (and it's various derivatives). This parameter gets inserted (as : text) into an ELF section that's not loaded. sysctl(8) can locate : the description by reading it out of the kernel image on disk. : (The section could also be stripped out to reduce disk space if : necessary). :2) Mark the documentation is some way (possibly, but not necessarily : via the SYSCTL_OID macro) so that it can be easily extracted from : the source by an awk or perl script and turned into a man page : (or several) - ie there'd be a single automatically generated : sysctl.oid(7) man page that documented all sysctl identifiers, : or several man pages, each documenting a group of identifiers. : :[*] As a `production OS', it should not be necessary for the sysadmin : to be intimately familiar with the source code. : :Peter : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 15:29: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D6E4B115B5 for ; Thu, 18 Feb 1999 15:28:31 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA24447; Thu, 18 Feb 1999 15:28:04 -0800 Date: Thu, 18 Feb 1999 15:28:04 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1136656806-4164134-919380484=:24373" Sender: owner-freebsd-hackers@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. --1136656806-4164134-919380484=:24373 Content-Type: TEXT/PLAIN; charset=US-ASCII The source is probably public domain. See attached .tgz. Edit and use the TEST csh script. I've never cleaned it up from the original author- so, yes, I know it looks somewhat stupid. I should also note that the same test on a 4KB filesystem is still charging along. -matt --1136656806-4164134-919380484=:24373 Content-Type: APPLICATION/octet-stream; name="breakit.tgz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: breakit tests Content-Disposition: attachment; filename="breakit.tgz" H4sIALmhzDYAA+0aa2/bODJfrV8xddutFNux7PgBxEmwubR7WCTbAG3vDoem KBQ9bG5kyZDoprm7/Peb4UOyZScNFrW33XIQWNRwZjjkPEhOdJWF3jXj7Z0N AvTc4bAPOzDsDQZdfBK46qleYDAY7He67qDfA+h0up3+DvQ3qZSGec69DGBn +rvnp1f3091MwjDehkLbhStl/9PTl+9evX23kTE6rjvsP2D/4WC/tH9vgPbv 7ncGO+BuRJsK/OD2f/qkfcWStp9PoBVZ1s/AMzaDI3At62bC4hDsjmNZAEXH M/FsQAeRoT9JoX6TMR4yDizMPM7SRJLU4fgneNZpq969OB0jh5DEUAyxqwHg GYNDxPRdcBALe5oHUCXqbOWALjSFVkoCI2TaQ+zxinz4idilfCRQOiaBHPfG Y/zRGviT0MewqCrAlhQQ4ytKNT9gEYlDn+LzHJ7gOoIDfBIm1KfWS8sOsyzN YJalfpjnLBkDCV4YoL5milLMZzETmhqLqCFMmE0XeO9ZCIt+luyv41+P4W/A x3DtBr3evfHf6w6Hlfjf7/RN/G8FnrLEj+dBCIc5D1i6Nzm2SpTPb2fhMgqd NqlQ5bd5mwjzZXTkJzyuUPIgZldVXIa+TzjraRBGLAnhDKOt27MslnC4mkdx mKAf4x6xC2ejWq29C4gZ8wmkEXVHYQa7bcufoBl38R1JiGbGM+ApBLeJN2X+ AqEWm0ZRHnJKdVKoF7NxoumQk09YLuil5FRE5xHUJ/Nx+Au26yMpKo1ibzwS zSieYx4lieKVJYyjPMo1Iy0m85KAlMRQ/MzDLAEhYsZZEow0Sg04Q8dEwdbU Y4mNTb+JP58cIZpeR0rkLqFH1n+tGvUgWjwz/8hVzShQDSkSV0934DTwrSka U++zaN9kKQ+bMGWJyAnY8j6LFjKJAZE4/kit993+4AMqWFNp1PZxquOQ4zBS X1LzUxPq0UF+kB7UHYcyYgs3lFotv2Hcn4DtO4CK1wB8Lw/hRfTiAN9q6BT+ 7NYuh2oq3Z0RdYukRQMXfKnkE7ZoNEayLQ2m13EtXy75yvkjg8dTZi8OVywb dqJm2FjqppTPci+eTTyFf19wtDofHIcmWM54HQlIEq3VldRqSa/dI+h3uiOJ VxNZ5LlWPPr9bL0MO05xp6Ef5+x+YdOKsN++KMw+2z1zVgXeWfqnQOKbhfFm 1TCeT+I49T0e6rDL2X9C3KJrFHdADVpbW8aQLb3dmXrEZMvEgC51VHa9/sf5 uVzLmdhc7bokrgvNaNvE0ww279AFVCCiYBmOWiUM7Zh2bK0SWm0i3mkMz8cA zSGfhT6LWBhg9Io+PDoRL3mfVL6ICT0MHi9sEDNpyGVzVGpzoKWdqvB2nBU6 DVRABYWerJLcLGZfRgvOscpcTle3GqvDlmx3FXZLmSIKRERRBJAr4OAXH9+8 /Neb/118PH3z6uSd0wTa63ECh+AKUxC3tgYxClsQMpph4ueRjZsCdjfrF9gJ kYdSA4jwYHRZf55f1i+TOsY+jaX5ls2o05S0o0xtOmHJTFxTWU6+lclKow8X sp9Y95qaqupvFIY6XqIUIVtsTwuB0dJ5VXm7EKcIj4tsSklwUdNC+0XywyIN S/LVySJaJGxEiS60UBOEWyittURJ9eSomI3QX1tG8NaFA1CUL5sG6if5NVoF N0U5/PNAbRPYIgOJUJdyVYczAkJmtCO8+vViVM0ACyodo10cnYTFgh9JGcLC NT9Oc5qVNr8l4zjzEXFnffmAY+BB0Od/Huac8c2M8cX7f9+t3v/7+31z/t8G fEP3/8H91//BFi7/g3vv/oM1N/92EH5qJ/M4/h4v/Qug41+XMf6E+//AHVTj f98ddkz8bwO+pfv/lgoABWF3Q6UCdl+pgP3FSgVXt3hs+IgZJPj69QL2B+oF ZblgTbWgZGKSiS0UC5gpFnw/xYKF2zmfeBxuQpjjwBiIfjqdeVkI3hgDIefy Lr7BIsIDmqFG4sZE0QFRlk4hYPm1rg5olbob06moY+g1qdYzKFjWFjUEO0vo /IOMU1WOWS2YPFDh+L5LG0yWNqiycfH6/N9fuZjBTDHjgWJGuaWQPfGhCxrd lYrGAul9ZQ3qfERVQ8igooZqrNQ0yqEeVdiAaTj1pzNb12G6SxKkWWrBfDrD vnw9VVOvu8yTarzX/zw5rw65uhrrKipl92pZZbGgYlmYPzD+T1XWKDNaDhhd INYQ0jkXPTnHLoFXRyTKx8QepJCkHP0Dd7E9vHZhAkE+q5hzcQbrNKE8jzXF EYeKwLIlhTpWmTAIC2xkFQhl0/pLlEzXKa0rBZ0n68l4SpQmpbeFRKBZW61j er3klxwuMjZmiRfjG7zBxboUIV6wkFQbGB6X8Jp1KMRjq9FYk9KEH9AE37MP yj+72FxDWdXnuTsMtD4vnvsvQD0pdzTkkjS15KaWC2sSY1XwJaep4vURV0hO rEp5Z622spDPs8R2pXv82fcVA18X9P1/Yx//7Dzm+59Otf7nul1z/98GfDv1 vwc//+lv4fOfh77+6f81v/4p4//tBhPAH4j/TtfU/7cC30n8b+Pzvx/w678y /n/zrkPi3oSPfaH+D/vdlf//Dbs9E//bgKfW6S/nJ39/ixfkI2iNLcuL4wP6 pkCGoPJWTAYScVDeFbRfpnjTfGafnjqAv0KWI0L1Z/zbw6d9/uvfHKppC0kL AnTsPFZAHHoJVRbR1XcFEzZ0NGl9zf3EgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgz8kPB/IrK/nQBQAAA= --1136656806-4164134-919380484=:24373-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 15:45:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 8D63611C42 for ; Thu, 18 Feb 1999 15:45:29 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA07788; Thu, 18 Feb 1999 16:59:38 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd007680; Thu Feb 18 16:59:28 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id QAA21085; Thu, 18 Feb 1999 16:45:03 -0700 (MST) From: Terry Lambert Message-Id: <199902182345.QAA21085@usr06.primenet.com> Subject: Re: gdb sucks - and I need to get around it. help?t To: bright@cygnus.rush.net Date: Thu, 18 Feb 1999 23:44:47 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "perlsta" at Feb 17, 99 03:30:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I actually *prefer* post-morteming core files, and instrumenting > > the code such that I know what's going wrong. > > > > I occasionally use the Microsoft source level debugger (I have to > > admit that getting the contents of variables as a tool-tip, merely > > by leaving the mouse pointer over them for a second is pretty damn > > cool), but like the VMS debugger (and, frequently, gdb), you have > > have you tried 'ddd' there is a statically linked Motif version in > the packages collection, i find ddd VERY nice. I've tried it; it's very nice, for a debugger. But none of my best friends are debuggers. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 16:27:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B14B1170E for ; Thu, 18 Feb 1999 16:27:19 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Fri, 19 Feb 1999 11:16:41 +1100 Date: Fri, 19 Feb 1999 11:27:11 +1100 From: Peter Jeremy Subject: Re: vm_page_zero_fill To: hackers@FreeBSD.ORG Message-Id: <99Feb19.111641est.40325@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: >If you have a *lot* of global data in your app, you basically have a >choice between a) initializing them in main(), b) spending some CPU >cycles zeroing the BSS at load time, Note that b) _may_ be more efficient that a). The FreeBSD kernel contains several (3 from memory) different bzero algorithms and selects one to suit the CPU (at least in theory). Some processors (eg SuperSPARC) include special bzero instructions which are only available to the kernel. (The downside is that the kernel initialises everything. The programmer may be able to get away with only initialising parts of the BSS). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 16:38:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id A3791115C7 for ; Thu, 18 Feb 1999 16:38:03 -0800 (PST) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id SAA28128; Thu, 18 Feb 1999 18:31:30 -0600 Received: from stlabcexg006.anheuser-busch.com(stlabcexg006 151.145.101.161) by gatewaya via smap (V2.1) id xma028113; Thu, 18 Feb 99 18:31:29 -0600 Received: by stlabcexg006.anheuser-busch.com with Internet Mail Service (5.5.2232.9) id ; Thu, 18 Feb 1999 18:33:55 -0600 Message-ID: From: "Alton, Matthew" To: freebsd-hackers@freebsd.org Subject: RE: FreeBSD-Rio released (fwd) Date: Thu, 18 Feb 1999 18:32:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is some very interesting work. I am going to look into this. I am currently under the impression that it is a Good Thing and should be in 4.x as a LINT option. > -----Original Message----- > From: Jonathan M. Bresler [SMTP:jmb@hub.freebsd.org] > Sent: Thursday, February 18, 1999 8:13 AM > To: freebsd-hackers@freebsd.org > Subject: FreeBSD-Rio released (fwd) > > > > Alex Boisvert sent this message to the list, but > it bounced....nonetheless its a matter of interest to the FreeBSD > community. > > From: "Peter M. Chen" > Subject: Announcing Rio for FreeBSD > > The Rio (RAM I/O) project at Michigan is pleased to release an implementation > of the Rio file cache for FreeBSD. The basic idea of Rio is to make memory as > safe as disk from operating system crashes. Such "reliable main memory" is > useful in a variety of contexts: > > * file systems: reliable main memory provides the semantics of > synchronous writes with the performance of a pure write-back > file system. The only disk writes needed are when the file > cache becomes full. > > * transaction systems: reliable main memory allows a very simple > and fast implementation of atomic, durable actions. We've built such a > system, called Vista, that can achieve 2000x lower overhead > per transaction than a comparable transaction system. Vista > transactions can be done in a few microseconds. > > * checkpointing: Discount Checking is a checkpointing library that > allows general applications to recover from operating system and > application crashes. Discount Checking builds on Rio's reliable main > memory and Vista's fast transactions to achieve very low overhead and a > high degree of transparency. Discount Checking slows real > applications down by less than 0.6%, even while taking checkpoints > frequently enough to save every externally visible event. Discount > Checking makes application and OS crashes appear as if the application > pauses and resumes. > > Papers describing Rio, Vista, and Discount Checking are available on > the Rio web page (http://www.eecs.umich.edu/Rio). > > Wee Teck Ng and Peter M. Chen > > EECS Department > University of Michigan > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 16:39:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.tamu.edu (clavin.cs.tamu.edu [128.194.130.106]) by hub.freebsd.org (Postfix) with ESMTP id F2DCB118B5 for ; Thu, 18 Feb 1999 16:39:41 -0800 (PST) (envelope-from gurudatt@cs.tamu.edu) Received: from dilbert.cs.tamu.edu (IDENT:2146@dilbert [128.194.133.100]) by cs.tamu.edu (8.9.1/8.9.1) with ESMTP id SAA25715 for ; Thu, 18 Feb 1999 18:39:04 -0600 (CST) Received: from localhost by dilbert.cs.tamu.edu (8.9.1/8.9.1) with SMTP id SAA09837 for ; Thu, 18 Feb 1999 18:37:50 -0600 (CST) X-Authentication-Warning: dilbert.cs.tamu.edu: gurudatt owned process doing -bs Date: Thu, 18 Feb 1999 18:37:50 -0600 (CST) From: Gurudatt Shenoy X-Sender: gurudatt@dilbert To: FreeBSD Hackers Subject: What libraries for socket programs in FreeBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Pardon my naivete: What libraries does one include to compile socket programs in freebsd? Thanks, ~gs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 16:48: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatewaya.anheuser-busch.com (gatewaya.anheuser-busch.com [151.145.250.252]) by hub.freebsd.org (Postfix) with SMTP id 92E5011721 for ; Thu, 18 Feb 1999 16:47:37 -0800 (PST) (envelope-from Matthew.Alton@anheuser-busch.com) Received: by gatewaya.anheuser-busch.com; id SAA28579; Thu, 18 Feb 1999 18:41:05 -0600 Received: from stlabcexg004.anheuser-busch.com(stlabcexg004 151.145.101.160) by gatewaya via smap (V2.1) id xma028575; Thu, 18 Feb 99 18:40:51 -0600 Received: by stlabcexg004.anheuser-busch.com with Internet Mail Service (5.5.2232.9) id ; Fri, 19 Feb 1999 00:43:14 -0000 Message-ID: From: "Alton, Matthew" To: "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: RE: What libraries for socket programs in FreeBSD? Date: Fri, 19 Feb 1999 00:42:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG man socket man connect man listen man bind ... > -----Original Message----- > From: Gurudatt Shenoy [SMTP:gurudatt@cs.tamu.edu] > Sent: Thursday, February 18, 1999 6:38 PM > To: FreeBSD Hackers > Subject: What libraries for socket programs in FreeBSD? > > > Pardon my naivete: > What libraries does one include to compile socket programs in freebsd? > solaris?> > > Thanks, > ~gs > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 17:14:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from regret.globalserve.net (regret.globalserve.net [209.90.144.72]) by hub.freebsd.org (Postfix) with ESMTP id EDE73113CA for ; Thu, 18 Feb 1999 17:14:41 -0800 (PST) (envelope-from dm@regret.globalserve.net) Received: (from dm@localhost) by regret.globalserve.net (8.9.3/8.9.1) id VAA22331; Thu, 18 Feb 1999 21:26:02 GMT (envelope-from dm) Message-ID: <19990218212602.B18058@globalserve.net> Date: Thu, 18 Feb 1999 21:26:02 +0000 From: "Dan - Sr. Admin" To: Gurudatt Shenoy Cc: freebsd-hackers@freebsd.org Subject: Re: What libraries for socket programs in FreeBSD? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Gurudatt Shenoy on Thu, Feb 18, 1999 at 06:37:50PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Pardon my naivete: > What libraries does one include to compile socket programs in freebsd? > solaris?> > > Thanks, > ~gs Usually, #include #include #include #include should get you covered. They're in libc. Regards, -- Dan Moschuk (TFreak!dm@globalserve.net) Senior Systems/Network Administrator Globalserve Communications Inc., a Primus Canada Company "Even a stopped clock is right twice a day" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 17:20:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id E03061142F for ; Thu, 18 Feb 1999 17:20:55 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id UAA07824; Thu, 18 Feb 1999 20:41:43 -0500 (EST) Date: Thu, 18 Feb 1999 20:41:41 -0500 (EST) From: Alfred Perlstein To: Gurudatt Shenoy Cc: FreeBSD Hackers Subject: Re: What libraries for socket programs in FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Gurudatt Shenoy wrote: > > Pardon my naivete: > What libraries does one include to compile socket programs in freebsd? > solaris?> They are mostly part of libc and therefor linked in by default. Basically you do not need these libs. -lsocket is a lame SRV4 (i think) thing because BSD sockets are simulated (poorly) via userland code. If you get any unresolved symbols check the function's manpage, or us 'nm' on the libraries in /usr/lib to locate it. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 17:43:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 63D7411BC9 for ; Thu, 18 Feb 1999 17:42:39 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA23111; Fri, 19 Feb 1999 12:12:35 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA22662; Fri, 19 Feb 1999 12:12:33 +1030 (CST) Message-ID: <19990219121232.A22647@lemis.com> Date: Fri, 19 Feb 1999 12:12:32 +1030 From: Greg Lehey To: Gurudatt Shenoy , FreeBSD Hackers Subject: Re: What libraries for socket programs in FreeBSD? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Gurudatt Shenoy on Thu, Feb 18, 1999 at 06:37:50PM -0600 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 18 February 1999 at 18:37:50 -0600, Gurudatt Shenoy wrote: > > Pardon my naivete: > What libraries does one include to compile socket programs in > freebsd? libc. It's included automatically. > solaris?> Solaris is System V, which got its networking stuff from BSD. They never got round to putting the networking functions into the C library. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 17:47:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 903A011889 for ; Thu, 18 Feb 1999 17:47:50 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Fri, 19 Feb 1999 12:37:11 +1100 Date: Fri, 19 Feb 1999 12:47:41 +1100 From: Peter Jeremy Subject: Re: vm_page_zero_fill To: hackers@FreeBSD.ORG Message-Id: <99Feb19.123711est.40325@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: >After playing with "gcc -O -S bcmp.c" on several platforms, i386, >sparc32, alpha. It seems to me that the function ought to be >replaced with this: [deleted] The code given is portable, but not optimal for any of these architectures - especially the Alpha. The original Alpha chips don't have character instructions so character handling is quite poor (and gcc2.7.x doesn't include support for the new character instructions). Optimal code for the Alpha would read 8-byte long-word aligned chunks from memory, then appropriately re-align and compare them. (There's some discussion about this, though not actual code, in the early Alpha white papers). A similar strategy probably holds for the SPARC (but 4-bytes loads except on UltraSPARCs). Something similar could be done on the ix86, but I'm not certain about the advantages. This _is_ one area where carefully hand-crafted code is worth the effort (especially on the RISC architectures). >it uses the "rep cmpsl" opcode, i have heard that using "movs/lods/cmps" >was no longer optimal after the 486 line, but i'm unsure. Sort of true. In theory, an explicit loop is faster than "rep cmps". Lack of CPU<->RAM bandwidth tends to make this less of an issue unless both strings are in L1 cache. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 18:52: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 783E610F64 for ; Thu, 18 Feb 1999 18:51:34 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id VAA01728; Thu, 18 Feb 1999 21:49:11 -0500 (EST) Date: Thu, 18 Feb 1999 21:49:10 -0500 (EST) From: Chuck Robey To: "Alton, Matthew" Cc: "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: RE: What libraries for socket programs in FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Alton, Matthew wrote: > man socket > man connect > man listen > man bind > ... He didn't ask what they were, he asked *where* they were. You don't need to bring in any extra libs, they're all in libc. Convenient. > > > -----Original Message----- > > From: Gurudatt Shenoy [SMTP:gurudatt@cs.tamu.edu] > > Sent: Thursday, February 18, 1999 6:38 PM > > To: FreeBSD Hackers > > Subject: What libraries for socket programs in FreeBSD? > > > > > > Pardon my naivete: > > What libraries does one include to compile socket programs in freebsd? > > > solaris?> > > > > Thanks, > > ~gs > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19: 1:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1AF9211552 for ; Thu, 18 Feb 1999 19:01:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id TAA25593; Thu, 18 Feb 1999 19:01:03 -0800 Date: Thu, 18 Feb 1999 19:01:02 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, btw- I should clarify a little about this test and some spice to the mix... The same test on a system that is 25% of the cpu power and 25% of the memory running solaris 2.7 Intel not only successfully has always runs this test but also retains a quite acceptable responsiveness. Please don't make me claim Slowlaris is better! -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19: 2: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lodge.guild.ab.ca (lodge.guild.ab.ca [209.91.118.66]) by hub.freebsd.org (Postfix) with ESMTP id D4685119FB for ; Thu, 18 Feb 1999 19:01:38 -0800 (PST) (envelope-from davidc@lodge.guild.ab.ca) Received: from localhost (davidc@localhost) by lodge.guild.ab.ca (8.9.1/8.9.1) with ESMTP id TAA55246 for ; Thu, 18 Feb 1999 19:46:25 -0700 (MST) Date: Thu, 18 Feb 1999 19:46:25 -0700 (MST) From: Chad David To: freebsd-hackers@freebsd.org Subject: coda and tunX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A while back I wrote a simple IP over UDP tunnel program using the tunX driver to solve a problem with my ISP. It has worked perfectly for months (we even run NFS over it). In the last week I installed coda 5.0.1 and got it working locally, but when I attempted to install the client on a remote machine venus would just time out. I am able to connect to the test server at CMU, but it refuses to use the tunnel interface. I work on the remote machine by sshing onto the machine over the tunnel, so I know it is working (NFS is mounted over it as I write this), but coda refuses to talk? Does anybody have any idea what is going on? Thanks. Chad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19:33:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by hub.freebsd.org (Postfix) with ESMTP id AC99E10E0C for ; Thu, 18 Feb 1999 19:33:24 -0800 (PST) (envelope-from mrcpu@internetcds.com) Received: from localhost (mrcpu@localhost) by schizo.cdsnet.net (8.8.8/8.7.3) with SMTP id TAA05325 for ; Thu, 18 Feb 1999 19:27:54 -0800 (PST) Date: Thu, 18 Feb 1999 19:27:54 -0800 (PST) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Anybody got the Linux PAM module for Apache 1.3.3 on FreeBSD 3.1-stable? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got it all compiled, but suspect that I must have pam.conf boobered up, or something. Apache 1.3.3ssl compiled out of ports, the Apache PAM module: http://blank.pages.de/pam/ modified the apache compile to link with -lpam. /etc/pam.conf contains: httpd auth required pam_unix.so try_first_pass httpd account required pam_unix.so try_first_pass httpd password required pam_unix.so try_first_pass Does the PAM library have some way to turn on debugging so log requests to see what' going on? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19:40:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 47AA810E0C for ; Thu, 18 Feb 1999 19:40:20 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 22622 invoked from network); 19 Feb 1999 03:40:03 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 19 Feb 1999 03:40:03 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id WAA00789; Thu, 18 Feb 1999 22:40:02 -0500 (EST) Message-Id: <199902190340.WAA00789@y.dyson.net> Subject: Re: Documenting sysctl knobs In-Reply-To: <199902182318.PAA27201@apollo.backplane.com> from Matthew Dillon at "Feb 18, 99 03:18:38 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 18 Feb 1999 22:40:02 -0500 (EST) Cc: peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > We could do a javadoc like thingy where we document the item in > a comment in the source code and then run a program to generate > the documentation by scanning the the source. > There is a comment field in the sysctl macro. It might not be sufficient, but then maybe a format could be defined for cross reference. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19:41:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 7081210E92 for ; Thu, 18 Feb 1999 19:41:41 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 23695 invoked from network); 19 Feb 1999 03:41:38 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 19 Feb 1999 03:41:38 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id WAA00795; Thu, 18 Feb 1999 22:41:32 -0500 (EST) Message-Id: <199902190341.WAA00795@y.dyson.net> Subject: Re: cdrom.com bandwidth limits In-Reply-To: <19990218160929.Z12713@ns1.adsu.bellsouth.com> from Christian Kuhtz at "Feb 18, 99 04:09:29 pm" To: ck@ns1.adsu.bellsouth.com (Christian Kuhtz) Date: Thu, 18 Feb 1999 22:41:32 -0500 (EST) Cc: vincef@penmax.com, dennis@etinc.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christian Kuhtz said: > > I can only agree with Vincent. You got a slow sucky pipe. :) > > On Thu, Feb 18, 1999 at 04:02:52PM -0500, Vincent Fleming wrote: > > Huh? I just downloaded the ports collection at average speed > > above 50 k BYTES PER SECOND! > > > > Perhaps you just got it at a slow time. I've seen ftp.cdrom.com > > hit 200 k bytes per second. I've even installed FreeBSD off of it in > > less than 20 minutes, including ALL the sources and ports! > > > Normally on a good T1, I get about 120-160k Bytes per second, but during "bad days" (net-wise, not wcarchive load wise), I have seen 50-60KBytes/sec. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 19:52:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id B7F1A11419 for ; Thu, 18 Feb 1999 19:52:28 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id TAA03803; Thu, 18 Feb 1999 19:49:54 -0800 (PST) Message-Id: <199902190349.TAA03803@implode.root.com> To: Dennis Cc: hackers@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits In-reply-to: Your message of "Thu, 18 Feb 1999 14:13:20 EST." <199902181903.OAA06719@etinc.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 18 Feb 1999 19:49:54 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >It seem obvious that ftp.cdrom.com has a limit of about 56kbs...is this >a good idea? Considering that to download a release it now takes all day >instead of 30 minutes, it substantially increases the chances of a failure >and that multiple attempts will have to be made, which increases the >overall bandwidth requirements rather than decreasing them. It also >increases the number of simultanous downloads that are occuring. ftp.cdrom.com has no bandwidth limiting. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:10:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-35.ppp.wenet.net [206.15.85.35]) by hub.freebsd.org (Postfix) with ESMTP id 4D88F113DE for ; Thu, 18 Feb 1999 20:10:36 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost [127.0.0.1]) by zippy.dyn.ml.org (8.9.2/8.9.1) with ESMTP id UAA01913; Thu, 18 Feb 1999 20:09:52 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Thu, 18 Feb 1999 20:09:51 -0800 (PST) From: Alex Zepeda To: Chuck Robey Cc: "Alton, Matthew" , "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: RE: What libraries for socket programs in FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Chuck Robey wrote: > On Fri, 19 Feb 1999, Alton, Matthew wrote: > > > man socket > > man connect > > man listen > > man bind > > ... > > He didn't ask what they were, he asked *where* they were. Yes, and the man pages should and usually do document which external libraries are needed. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:16:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (Postfix) with ESMTP id 0329E11586 for ; Thu, 18 Feb 1999 20:16:13 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id WAA08013 for ; Thu, 18 Feb 1999 22:16:08 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.6.13/8.6.4) id WAA23580; Thu, 18 Feb 1999 22:11:55 -0600 Message-ID: <19990218221154.34584@right.PCS> Date: Thu, 18 Feb 1999 22:11:55 -0600 From: Jonathan Lemon To: freebsd-hackers@freebsd.org Subject: Ethernet interrupt overhead Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have an application which is supposed to handle a lot of ethernet traffic (a proxy web server, actually). However, when under load, the kernel seems to spend an inordinate amount of time handling network interrupts. The machine in question is a P-II 300 with ~400MB memory, and is connected to a private 100BX switch. When using either of the following adapters: xl0: <3Com 3c905 Fast Etherlink XL 10/100BaseTX> rev 0x00 int a irq 10 on pci0.11.0 xl0: autoneg complete, link status good (full-duplex, 100Mbps) or pn0: <82c168/82c169 PNIC 10/100BaseTX> rev 0x21 int a irq 10 on pci0.11.0 pn0: autoneg complete, link status good (full-duplex, 100Mbps) I'm seeing (as reported via systat) that the machine is spending about 30% of it's time handling interrupts. The ethernet card is generating just under 10,000 interrupts per second. This seems to translate into roughly 9,000 cycles/packet, which seems rather high to me. Is this reasonable, or do I just have lousy ethernet cards? Would the EtherExpress (fxp0 driver) perform better under this load? -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:20: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 3546D115AD for ; Thu, 18 Feb 1999 20:18:55 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id XAA02303; Thu, 18 Feb 1999 23:15:21 -0500 (EST) Date: Thu, 18 Feb 1999 23:15:20 -0500 (EST) From: Chuck Robey To: Alex Zepeda Cc: "Alton, Matthew" , "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: RE: What libraries for socket programs in FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Alex Zepeda wrote: > On Thu, 18 Feb 1999, Chuck Robey wrote: > > > On Fri, 19 Feb 1999, Alton, Matthew wrote: > > > > > man socket > > > man connect > > > man listen > > > man bind > > > ... > > > > He didn't ask what they were, he asked *where* they were. > > Yes, and the man pages should and usually do document which external > libraries are needed. Not usually the ones that reside in libc, no, I haven't ever noticed that. I used to have to go looking with nm, when I was new to bsd. Certainly none of these do, and it's pretty common for other OSs to need net libs. I wasn't trying to be critical, but the advice offered no help. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:21:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.dyn.ml.org (pm3-35.ppp.wenet.net [206.15.85.35]) by hub.freebsd.org (Postfix) with ESMTP id C17D71141C for ; Thu, 18 Feb 1999 20:21:40 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost [127.0.0.1]) by zippy.dyn.ml.org (8.9.2/8.9.1) with ESMTP id UAA03107; Thu, 18 Feb 1999 20:21:27 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Thu, 18 Feb 1999 20:21:27 -0800 (PST) From: Alex Zepeda To: Chuck Robey Cc: "Alton, Matthew" , "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: RE: What libraries for socket programs in FreeBSD? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Chuck Robey wrote: > On Thu, 18 Feb 1999, Alex Zepeda wrote: > > > On Thu, 18 Feb 1999, Chuck Robey wrote: > > > > > On Fri, 19 Feb 1999, Alton, Matthew wrote: > > > > > > > man socket > > > > man connect > > > > man listen > > > > man bind > > > > ... > > > > > > He didn't ask what they were, he asked *where* they were. > > > > Yes, and the man pages should and usually do document which external > > libraries are needed. > > Not usually the ones that reside in libc, no, I haven't ever noticed > that. I used to have to go looking with nm, when I was new to bsd. > Certainly none of these do, and it's pretty common for other OSs to need > net libs. I wasn't trying to be critical, but the advice offered no > help. But if you don't give gcc any libraries to link with, by default it will at least link in libc, right? So one could implicitly assume that if the man page mentions no other libraries, it's in libc. Mostly, I've found this to be true. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:30:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 693F91178A for ; Thu, 18 Feb 1999 20:27:37 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id OAA24189; Fri, 19 Feb 1999 14:57:35 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA11838; Fri, 19 Feb 1999 14:57:33 +1030 (CST) Message-ID: <19990219145732.B93492@lemis.com> Date: Fri, 19 Feb 1999 14:57:32 +1030 From: Greg Lehey To: Alfred Perlstein , Gurudatt Shenoy Cc: FreeBSD Hackers Subject: Re: What libraries for socket programs in FreeBSD? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Alfred Perlstein on Thu, Feb 18, 1999 at 08:41:41PM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 18 February 1999 at 20:41:41 -0500, Alfred Perlstein wrote: > > > On Thu, 18 Feb 1999, Gurudatt Shenoy wrote: > >> >> Pardon my naivete: >> What libraries does one include to compile socket programs in freebsd? >> > solaris?> > > They are mostly part of libc and therefor linked in by default. Basically > you do not need these libs. -lsocket is a lame SRV4 (i think) thing because > BSD sockets are simulated (poorly) via userland code. Some System V implementations have native sockets. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 20:53: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id AE9A9115DB for ; Thu, 18 Feb 1999 20:53:00 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id VAA15840; Thu, 18 Feb 1999 21:52:33 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36CCEE11.7CFDBB98@softweyr.com> Date: Thu, 18 Feb 1999 21:52:33 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zepeda Cc: Chuck Robey , "Alton, Matthew" , "'Gurudatt Shenoy'" , FreeBSD Hackers Subject: Re: What libraries for socket programs in FreeBSD? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Zepeda wrote: > On Thu, 18 Feb 1999, Chuck Robey wrote: > > On Thu, 18 Feb 1999, Alex Zepeda wrote: > > > On Thu, 18 Feb 1999, Chuck Robey wrote: > > > > > > Yes, and the man pages should and usually do document which external > > > libraries are needed. > > > > Not usually the ones that reside in libc, no, I haven't ever noticed > > that. I used to have to go looking with nm, when I was new to bsd. > > Certainly none of these do, and it's pretty common for other OSs to need > > net libs. I wasn't trying to be critical, but the advice offered no > > help. > > But if you don't give gcc any libraries to link with, by default it will > at least link in libc, right? So one could implicitly assume that if the > man page mentions no other libraries, it's in libc. Mostly, I've found > this to be true. You are correct, sir; if a library is not mentioned in the man page that implies the function is in libc (or, in some cases, libc_r). If it is not, please submit a PR. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 21:15:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 32880114D3 for ; Thu, 18 Feb 1999 21:15:52 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id VAA21325; Thu, 18 Feb 1999 21:15:52 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id VAA00527; Thu, 18 Feb 1999 21:15:51 -0800 (PST) (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 In-Reply-To: <19990218093637.A1696@internal> Date: Thu, 18 Feb 1999 21:15:51 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Andre Albsmeier Subject: Re: UIDs greater than 65535? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andre Albsmeier wrote: > On Wed, 17-Feb-1999 at 22:10:41 -0800, John Polstra wrote: >> Can anybody think of a reason why UIDs > 65535 wouldn't work under >> FreeBSD? They seem to work, and I can't find any reason why they >> shouldn't. Even the NFS protocol (though not necessarily all NFS >> servers) seems to be able to accomodate 4-byte UIDs. > > I can only tell that quotas get big problems with ultra large uid's. > > See PR# 2325. I have a local fix here... it is ugly as sin and it > doesn't fix the problem but the effects. Thanks for telling me about this. I took a brief look at it. It looks like it won't be a problem for me, as long as the UID space is tightly packed. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 21:51:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 6ADA610E07 for ; Thu, 18 Feb 1999 21:51:14 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id BAA07617; Fri, 19 Feb 1999 01:12:10 -0500 (EST) Date: Fri, 19 Feb 1999 01:12:08 -0500 (EST) From: Alfred Perlstein To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <99Feb19.123711est.40325@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Peter Jeremy wrote: > Alfred Perlstein wrote: > >After playing with "gcc -O -S bcmp.c" on several platforms, i386, > >sparc32, alpha. It seems to me that the function ought to be > >replaced with this: > [deleted] > > The code given is portable, but not optimal for any of these > architectures - especially the Alpha. The original Alpha chips don't > have character instructions so character handling is quite poor (and > gcc2.7.x doesn't include support for the new character instructions). > > Optimal code for the Alpha would read 8-byte long-word aligned chunks > from memory, then appropriately re-align and compare them. (There's > some discussion about this, though not actual code, in the early Alpha > white papers). > > A similar strategy probably holds for the SPARC (but 4-bytes loads > except on UltraSPARCs). Something similar could be done on the ix86, > but I'm not certain about the advantages. > > This _is_ one area where carefully hand-crafted code is worth the > effort (especially on the RISC architectures). Yes, but after 'gcc -O -S' my code reduces the number of branches, and other ops on all archs. It's really a non-issue as the i386 code has this hand done in asm. I think it's more effecient because gcc is smart enough to use the index instead of 2 seperate pointers. > > >it uses the "rep cmpsl" opcode, i have heard that using "movs/lods/cmps" > >was no longer optimal after the 486 line, but i'm unsure. > Sort of true. In theory, an explicit loop is faster than "rep cmps". > Lack of CPU<->RAM bandwidth tends to make this less of an issue unless > both strings are in L1 cache. Aren't they both forced into L1 as soon as they are first accessed, making the rest of the code execute quicker? (at least on i586+) Next time i'll check if it's already hand coded asm before I pipe up about something like this. :) -Alfred > > Peter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 22:32:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (Postfix) with ESMTP id 991D311579 for ; Thu, 18 Feb 1999 22:32:35 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.1/8.9.1) with SMTP id WAA20324; Thu, 18 Feb 1999 22:32:32 -0800 (PST) Date: Thu, 18 Feb 1999 22:32:32 -0800 (PST) From: Chris Timmons To: Jonathan Lemon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Ethernet interrupt overhead In-Reply-To: <19990218221154.34584@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Some time ago when the fxp driver came on the scene we replaced a bunch of de driver cards with fxp ones and the percentage of time spent processing interrupts dropped from about 4% to about .9% on average. The cards are cheap now so you might as well grab one and try it! -c On Thu, 18 Feb 1999, Jonathan Lemon wrote: > I'm seeing (as reported via systat) that the machine is spending > about 30% of it's time handling interrupts. The ethernet card is > generating just under 10,000 interrupts per second. > > This seems to translate into roughly 9,000 cycles/packet, which > seems rather high to me. Is this reasonable, or do I just have > lousy ethernet cards? Would the EtherExpress (fxp0 driver) perform > better under this load? > -- > Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Feb 18 22:44:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 957E711637 for ; Thu, 18 Feb 1999 22:44:50 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from salomon.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id HAA28514 for ; Fri, 19 Feb 1999 07:44:48 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by salomon.siemens.de (8.9.3/8.9.3) with ESMTP id HAA16274 for ; Fri, 19 Feb 1999 07:44:48 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA13092 for ; Fri, 19 Feb 1999 07:44:48 +0100 (CET) Date: Fri, 19 Feb 1999 07:44:45 +0100 From: Andre Albsmeier To: John Polstra Cc: Andre Albsmeier , hackers@FreeBSD.ORG Subject: Re: UIDs greater than 65535? Message-ID: <19990219074445.C4890@internal> References: <19990218093637.A1696@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from John Polstra on Thu, Feb 18, 1999 at 09:15:51PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18-Feb-1999 at 21:15:51 -0800, John Polstra wrote: > > Andre Albsmeier wrote: > > On Wed, 17-Feb-1999 at 22:10:41 -0800, John Polstra wrote: > >> Can anybody think of a reason why UIDs > 65535 wouldn't work under > >> FreeBSD? They seem to work, and I can't find any reason why they > >> shouldn't. Even the NFS protocol (though not necessarily all NFS > >> servers) seems to be able to accomodate 4-byte UIDs. > > > > I can only tell that quotas get big problems with ultra large uid's. > > > > See PR# 2325. I have a local fix here... it is ugly as sin and it > > doesn't fix the problem but the effects. > > Thanks for telling me about this. I took a brief look at it. It > looks like it won't be a problem for me, as long as the UID space is > tightly packed. Hmm, I don't think it is the _packing_ of the UID space. It's the high UID's... If I understood it correctly, the quotas are handled as an array of structs (one 32 Byte struct for each user). My quota file has a size of 2097120. That means, 2097120/32 = 65535 entries which is correct. If you got a user ID of 10.000.000 the quota array should be already 320.000.000 bytes of size at least. The whole quota system is IMHO very inefficient for large UID's (well, large in the sense of being higher than 1.000.0000...). The reason, why I noticed it was the follwing: My users worked with PCNFS to write files to their public writable directories. Because they are lazy, they don't log into the PCNFS machine (net name *) and so PCNFS works as user nobody (-2), But -2 is 3^32-1 and this turned out to be the last UID :-). My local quick and dirty "fix" is (of course, I don't have UIDs above 65535): --- sbin/quotacheck/quotacheck.c.ORI Wed Aug 12 20:52:36 1998 +++ sbin/quotacheck/quotacheck.c Wed Aug 12 20:56:38 1998 @@ -501,6 +501,10 @@ struct fileusage *fup, **fhp; int len; +#ifdef ANDRE + if( id > 65535 ) + id = 65534; +#endif if ((fup = lookup(id, type)) != NULL) return (fup); if (name) --- sys/ufs/ufs/ufs_quota.c.ORI Mon Apr 27 19:28:30 1998 +++ sys/ufs/ufs/ufs_quota.c Thu Sep 18 08:48:59 1997 @@ -720,6 +720,10 @@ struct uio auio; int error; +#ifdef ANDRE + if( id > 65535 ) + id = 65534; +#endif dqvp = ump->um_quotas[type]; if (dqvp == NULLVP || (ump->um_qflags[type] & QTF_CLOSING)) { *dqp = NODQUOT; BTW, thanks for the fix to the linux stuff under 3.x: > jdp already fixed it :-) ... > > ! #define ELF_RTLD_ADDR(vmspace) \ > > ! (round_page((vm_offset_t)(vmspace)->vm_daddr + MAXDSIZ)) :-) -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 0:21:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id DE87B11540 for ; Fri, 19 Feb 1999 00:21:15 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA09674; Fri, 19 Feb 1999 07:09:38 +0100 From: Luigi Rizzo Message-Id: <199902190609.HAA09674@labinfo.iet.unipi.it> Subject: Re: Ethernet interrupt overhead To: jlemon@americantv.com (Jonathan Lemon) Date: Fri, 19 Feb 1999 07:09:38 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990218221154.34584@right.PCS> from "Jonathan Lemon" at Feb 18, 99 10:11:36 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1061 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm seeing (as reported via systat) that the machine is spending > about 30% of it's time handling interrupts. The ethernet card is > generating just under 10,000 interrupts per second. > > This seems to translate into roughly 9,000 cycles/packet, which > seems rather high to me. Is this reasonable, or do I just have cards are different. I was doing some testing few months ago, and on a P5-90 got the following costs for receiving a full-length pkt (measured using the Pentium cycle counter on a P5-90): ed: 25.000 ticks lnc: 5.000 ticks de: 1.000 ticks the latter two cards use DMA so they make a better use of the bus bandwidth and cpu. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: luigi@iet.unipi.it . Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 0:46:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id EDA4B115C6 for ; Fri, 19 Feb 1999 00:46:18 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id IAA67092; Fri, 19 Feb 1999 08:45:46 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 19 Feb 1999 08:45:46 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Matthew Jacob wrote: > > Oh, btw- I should clarify a little about this test and some spice to the > mix... The same test on a system that is 25% of the cpu power and 25% of > the memory running solaris 2.7 Intel not only successfully has always runs > this test but also retains a quite acceptable responsiveness. Please don't > make me claim Slowlaris is better! I'm sure that something very wrong is happening, don't worry. Hopefully, I will be able to see something. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 1:16:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C4E991141D for ; Fri, 19 Feb 1999 01:15:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA31066; Fri, 19 Feb 1999 01:15:40 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Feb 1999 01:15:40 -0800 (PST) From: Matthew Dillon Message-Id: <199902190915.BAA31066@apollo.backplane.com> To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Thu, 18 Feb 1999, Matthew Jacob wrote: : :> Oh, btw- I should clarify a little about this test and some spice to the :> mix... The same test on a system that is 25% of the cpu power and 25% of :> the memory running solaris 2.7 Intel not only successfully has always runs :> this test but also retains a quite acceptable responsiveness. Please don't :> make me claim Slowlaris is better! : :I'm sure that something very wrong is happening, don't worry. Hopefully, I :will be able to see something. : :-- :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 I've started testing the VN device. So far I've found it to be extremely unstable when using an NFSV2 or NFSV3 file as backing store. I'm going to try using an MFS based file as backing store next to see whether the problem is with the VN device or the NFS device. I've gotten the bmsafemap softupdates panic with softupdates mounted filesystems sitting on top of VN, but that was with the NFS-backed VN test which was unstable even without softupdates so I don't know if that is a real crash. I haven't tried reproducing the softupdates panic on its own merits yet. I want to fix VN first. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 1:37:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay1.ntu-kpi.kiev.ua (ntu-kpi.kiev.ua [195.178.136.20]) by hub.freebsd.org (Postfix) with ESMTP id 64C43114D4 for ; Fri, 19 Feb 1999 01:37:32 -0800 (PST) (envelope-from kapitan@hosix.ntu-kpi.kiev.ua) Received: from hosix.ntu-kpi.kiev.ua (IDENT:0@eth0.hosix.ntu-kpi.kiev.ua [10.100.0.6]) by relay1.ntu-kpi.kiev.ua (8.NYB/8.NYB) with ESMTP id LAA17920 for ; Fri, 19 Feb 1999 11:37:30 +0200 (EET) (envelope-from kapitan@hosix.ntu-kpi.kiev.ua) Received: from hosix.ntu-kpi.kiev.ua (kapitan.hosix.ntu-kpi.kiev.ua [10.100.24.12]) by hosix.ntu-kpi.kiev.ua (1.2.3.4/hidden) with ESMTP id LAA01781 for ; Fri, 19 Feb 1999 11:40:03 +0200 (EET) Message-ID: <36CD3064.CB090AA0@hosix.ntu-kpi.kiev.ua> Date: Fri, 19 Feb 1999 11:35:32 +0200 From: Yury Usmanov X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: subscribe Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 2: 6: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id BD7CF1141D for ; Fri, 19 Feb 1999 02:05:59 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10Dmon-000110-00; Fri, 19 Feb 1999 03:05:57 -0700 Received: (from imp@localhost) by harmony.village.org (8.9.2/8.8.3) id DAA01110 for hackers@freebsd.org; Fri, 19 Feb 1999 03:05:31 -0700 (MST) Date: Fri, 19 Feb 1999 03:05:31 -0700 (MST) From: Warner Losh Message-Id: <199902191005.DAA01110@harmony.village.org> To: hackers@freebsd.org Subject: fdisk Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How do I make fdisk(8) update the bios parameters for a disk drive. By BIOS parameters, I mean the bios parameters in sector 0. fdisk appears to set the incore copy (or at least purports to do so), but appear to update the parameters on the disk. Yes. I really really really want to do this. The disk is the only one system, but I could put it into another system. Actually, why do I want to do this? I'm wanting to make this disk bootable. I've installed boot0 (which appears to be working correctly). However, when I hit F1 or F2, nothing happens except a single disk access. If I boot off floppy, then enter wd(0,a)/boot/loader it works great. This usually indicates that the mbr parameters don't match the parameters which this bios comes up with. The boot message indicates a mismatch (since dmesg tells me cyl 3152, head 16, sectors 63). fdisk tells me 1576, head 32, sector 63. So am I barking up the wrong tree? Warner P.S. I think I need to port OpenBSD's disklabel and fdisk since they are slightly less frustrating that FreeBSD's. Todd Miller has done some good work there. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 2:30:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id 629731159F for ; Fri, 19 Feb 1999 02:29:40 -0800 (PST) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.2/8.9.2/UCB) id MAA66831; Fri, 19 Feb 1999 12:28:15 +0200 (EET) (envelope-from ru) Date: Fri, 19 Feb 1999 12:28:14 +0200 From: Ruslan Ermilov To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: fdisk Message-ID: <19990219122814.A65108@ucb.crimea.ua> Mail-Followup-To: Warner Losh , hackers@FreeBSD.ORG References: <199902191005.DAA01110@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: <199902191005.DAA01110@harmony.village.org>; from Warner Losh on Fri, Feb 19, 1999 at 03:05:31AM -0700 X-Operating-System: FreeBSD 3.0-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 19, 1999 at 03:05:31AM -0700, Warner Losh wrote: > How do I make fdisk(8) update the bios parameters for a disk drive. By BIOS > parameters, I mean the bios parameters in sector 0. > > fdisk appears to set the incore copy (or at least purports to do so), but > appear to update the parameters on the disk. > > Yes. I really really really want to do this. The disk is the only one > system, but I could put it into another system. > > Actually, why do I want to do this? > > I'm wanting to make this disk bootable. I've installed boot0 (which appears > to be working correctly). However, when I hit F1 or F2, nothing happens except > a single disk access. If I boot off floppy, then enter wd(0,a)/boot/loader > it works great. This usually indicates that the mbr parameters don't match > the parameters which this bios comes up with. The boot message indicates > a mismatch (since dmesg tells me cyl 3152, head 16, sectors 63). fdisk > tells me 1576, head 32, sector 63. > > So am I barking up the wrong tree? > > Warner > I suppose, you're talking about compatibility mode disk, are you? If yes, `fdisk -t -u' is supposed to test it, and `fdisk -u' -- to do it. > P.S. I think I need to port OpenBSD's disklabel and fdisk since they are > slightly less frustrating that FreeBSD's. Todd Miller has done some good > work there. > Could you tell us about the differences? -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank +380.652.247.647 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-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 2:40:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id E08CA1173E for ; Fri, 19 Feb 1999 02:40:29 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DnMC-00012J-00; Fri, 19 Feb 1999 03:40:28 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id DAA01379; Fri, 19 Feb 1999 03:40:02 -0700 (MST) Message-Id: <199902191040.DAA01379@harmony.village.org> To: Ruslan Ermilov Subject: Re: fdisk Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 19 Feb 1999 12:28:14 +0200." <19990219122814.A65108@ucb.crimea.ua> References: <19990219122814.A65108@ucb.crimea.ua> <199902191005.DAA01110@harmony.village.org> Date: Fri, 19 Feb 1999 03:40:02 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990219122814.A65108@ucb.crimea.ua> Ruslan Ermilov writes: : I suppose, you're talking about compatibility mode disk, are you? : If yes, `fdisk -t -u' is supposed to test it, and `fdisk -u' -- to do it. That doesn't work. That's kinda my whole point. : Could you tell us about the differences? In a nutshell, they have been enhanced to do the math that we've all done a zillion times (hmm, that last partition started at 132354 and was 12341235 sectors long, so the next partition starts at ...). Also they are nicer about editing things than the raw, bruit force approach that fdisk especially currently uses. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 3:49:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from excalibur.oceanis.net (ns.dotcom.fr [195.154.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 4566610E7B for ; Fri, 19 Feb 1999 03:49:01 -0800 (PST) (envelope-from pixel@excalibur.oceanis.net) Received: (from pixel@localhost) by excalibur.oceanis.net (8.9.1/8.9.1) id LAA26849; Fri, 19 Feb 1999 11:48:46 GMT From: Emmanuel DELOGET Message-Id: <199902191148.LAA26849@excalibur.oceanis.net> Subject: Re: TEXT_SET() macro In-Reply-To: <199902130015.RAA28440@usr01.primenet.com> from Terry Lambert at "Feb 13, 1999 0:15:36 am" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 19 Feb 1999 12:48:46 +0100 (MET) Cc: hackers@FreeBSD.ORG (FreeBSD Hackers Mail List) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As the well known and respected Terry Lambert said... ->> ->> I wanna know how it's working both at compile time and at run time ->> ->> (for example, does a lkm (yes lkm, not kld, since I'm working on a ->> ->> 2.2.8 release...) can declare linker_sets, or add entries in a kernel ->> ->> linker_set, [for example , the sysctl_ one - seems that I'm very ->> ->> interested in sysctls :)]. Thaks a lot. -> -> The answer is that it can declare linker sets for its own use, but -> can not add entries to a kernel linker set, as in: -> ->> -> You can declare sysctls in modules, but the sysctl code will not pick ->> -> them up so it's pretty useless. There is work pending to make that ->> -> possible. ->> -> ->> This seems that the sysctl_order function is called only on ->> the system init (due to SYSINIT), but it may be possible ->> to find a workaroud (I'm working on this for 2.2.8, ->> on the base of the D. Rabson patch for -current). -> -> The reason that this doesn't work is that linker sets are an artifact -> of the linker. But I still think that it is possible to find a workaround. In fact, the kernel relies on the linker_set facilities to do the sysctl init. Since lkm/kld linker_sets and kernel ones are not 'plug and play', the best solution, I think, is to use another alternative - which is, in fact, build a real tree in the kernel memory (maybe it's not a good idea, I don't know). Doug Rabson done this on -current, and I do this on 2.2.8 (yes, I still use 2.2.8, for some reason I've allready explained -even if these reasons are not valid, in fact, the main on is : my chief told me to not use a 3.x based kernel :)...). The linker sets facilities are still used in this new version, but they are used only for the registration process. I suggest you look at the code of DR for a better understanding of what I think (but I'm sure you have allready done this, isn't it ?). -> -> [lots of very interesting info deleted - the best infos I've ever -> read about linker_sets, in fact. Thx a lot] -> -> In general, linker sets are a structure with an element count, -> followed by an array of pointers of element count length, followed -> be a NULL pointer. -> -> In application, the element count is not used, and instead the -> lists are traversed until the NULL pointer is encountered. -> Well, this last assertion seems to not be really true (at least in the 2.2.8 kernel, as I've not read the -current sources). A lot of stuff in the kernel are still using the ls_count field, and seems to not rely on the NULL entry at the end of ls_items. -> [lots of very interesting info deleted (again)] -> -> In order to make this work for KLD's, the linker set agregation would -> need to occur at runtime. There are very good reasons for doing this, -> the foremost being that an ELF section archiver could aggregate drivers -> with a generic (tiny) kernel in order to support boot devices not -> supported by the generic (tiny) kernel. It is very easy to envision a -> distribution kernel without any drivers or even VFS modules by default. -> -> Making KLD's linker sets work is another good reason. -> That would be good, yes. The idea of a driver-less kernel is very very good, since FreeBSD is a stable OS that can be used in embbeded systems (like the one we're doing now). -> -> There are two technology changes which have to occur to be able to -> support runtime instead of linktime aggregation: -> -> 1) The element count *must* be deprecated entirely, for all -> cases. This may be a mildly complex change to the C++ -> compiler, if the element count is used instead of a list -> traversal. This may be the case, if NULL is a valid tag -> for a constructor/destructor place holder. A secondary I'm not a master in C++ core design, but I think that NULL cannot be a valid entry for C/Ds, since whenever you do not specify any C or/and D, the C++ compiler creates one (if he can't, he generates an error). I may be wrong, of course, son anyone that have more informatiosn on this subject is welcome. -> issue is all code relying on linker set technology. Making -> these changes would fully normalize the lists. -> 2) Agregation of linker sets needs to span ELF sections. wouch ! I'm not mastering the ELF stuff, in fact. But it seems that I don't have to, cos you are here :) -> -> This last item is the most important, since the first item is like -> removing an appendix. Yes, but, as I said before, it's a very big appendix... Removing all the occurence of ls_count in the code should be very long. Perhaps I'll try to do this later on -current, but I have no time for this on those days, so we'll have a FreeBSD 16.4.32 for year 2012 - a new era, where Microsoft, hurted by the opensource stuff, begin to give Windows 2012 with its source code under GPL licencing... rahhh... I'll still use things that work ;) -> -> The kernel code would have to treat the linker sets as a list of -> data on which a procedure needs to be run, *and which can be later -> rerun*, as needed. -> -> This means the linker set data itself can not be treated as static. -> -> Finally, the body of the kernel and the body of divisible drivers -> within the kernel must be treated seperately. The way to do this -> is to leverage the new ELF nature of the kernel, and implement the -> kernel and the divisible drivers in seperate ELF sections. This -> allows the driver to be later severed, if necessary, without -> damaging what would otherwise be a static aggregate list. -> -> I know that GCC supports ELF section attribution of code via a -> #pragma, per the Visual C++ compiler, in its effort to supply a -> compiler capable of compiling Windows 95/98/NT/CE code, though I -> don't know if this has been echo'ed into compilers for all -> platforms (e.g.: Linux and FreeBSD). -> -> You would probably have to implement an inline function identification -> semantic, or something similar, in order to apply section naming to -> entire drivers. -> -> FreeBSD would also have to relink objects that implemented a single -> driver from multiple source files, into a single section-attributed -> module. -> -> At that point, you would be able to, at load time, treat the sysctl -> linker set data atrributed sections as a continuation of the -> initialization iteration that occurred at system load. Well... Analyzing what you said may turn into : you have to work for three years to finally add new sysctls in a lkm/kld... I think I prefer the DR solution (despite it may looks like a hack) :) -> Terry Lambert -> terry@lambert.org -- ____________________________________________________________________ Emmanuel DELOGET [pixel] pixel@{dotcom.fr,epita.fr} ---- DotCom SA -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 6: 1:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id E76CE11646 for ; Fri, 19 Feb 1999 06:01:43 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10DqUU-0008O4-00; Fri, 19 Feb 1999 16:01:14 +0200 From: Sheldon Hearn To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: Documenting sysctl knobs In-reply-to: Your message of "Fri, 19 Feb 1999 08:58:07 +1100." <99Feb19.084745est.40350@border.alcanet.com.au> Date: Fri, 19 Feb 1999 16:01:14 +0200 Message-ID: <32243.919432874@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999 08:58:07 +1100, Peter Jeremy wrote: > IMHO, this is the sort of documentation that is needed for all the > tunable sysctl identifiers. The problem is that (IMHO again), CVS > logs aren't the correct place for it - the information needs to be > available to a sysadmin who doesn't have the CVS archive on-line (and > may not even want to RTSL [*]). Hi Peter, Your comments were certainly a very succinct summary of the two flamewars I've seen on this topic so far. Thanks for that. As you know, the idea of making the comments available via sysctl causes alergic reactions, so I won't get into that. However, your ideas on using a macro that's script-ripped out of the source and into a unified document looked exciting. If you were to do this work yourself and send diffs, I know that I, for one, would be _incredibly_ grateful. However, if you're hoping "someone else" will do it, you'll probably find that the kind of people who could do it easily don't need the same availability of comments it'd provide. In fact, the work required is doggy style but not hard. For each tunable, hunt the CVS logs and add to the source a reaonable comment from said logs. Hmmm... I wonder if I have time for this before I tie the knot. :-) Later, Sheldon (running out of "free" time in more ways than one). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 6:10:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 775191165B for ; Fri, 19 Feb 1999 06:10:11 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10DqcM-00005U-00; Fri, 19 Feb 1999 16:09:22 +0200 From: Sheldon Hearn To: dyson@iquest.net Cc: dillon@apollo.backplane.com (Matthew Dillon), peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: Documenting sysctl knobs In-reply-to: Your message of "Thu, 18 Feb 1999 22:40:02 EST." <199902190340.WAA00789@y.dyson.net> Date: Fri, 19 Feb 1999 16:09:22 +0200 Message-ID: <339.919433362@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999 22:40:02 EST, "John S. Dyson" wrote: > There is a comment field in the sysctl macro. It might not be sufficient, > but then maybe a format could be defined for cross reference. Hmmm... From sysctl(8): The following options are available: -a List all the currently available string or integer values. [...] -d Display the description rather than the value of the requested variable(s). And yet when I do ``syctl -ad'': sysctl: sysctl name -1 1024 2: No such file or directory What am I missing? Ciao, Sheldon. FreeBSD axl.noc.iafrica.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Fri Feb 19 01:31:01 SAST 1999 sheldonh@axl.noc.iafrica.com:/usr/src/sys/compile/AXL i386 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 6:12:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ceia.nordier.com (m2-44-dbn.dial-up.net [196.34.155.108]) by hub.freebsd.org (Postfix) with ESMTP id 2EAEE11731 for ; Fri, 19 Feb 1999 06:12:36 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id QAA08574; Fri, 19 Feb 1999 16:04:21 +0200 (SAT) From: Robert Nordier Message-Id: <199902191404.QAA08574@ceia.nordier.com> Subject: Re: fdisk In-Reply-To: <199902191040.DAA01379@harmony.village.org> from Warner Losh at "Feb 19, 99 03:40:02 am" To: imp@village.org (Warner Losh) Date: Fri, 19 Feb 1999 16:04:18 +0200 (SAT) Cc: ru@ucb.crimea.ua, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <19990219122814.A65108@ucb.crimea.ua> Ruslan Ermilov writes: > : I suppose, you're talking about compatibility mode disk, are you? > : If yes, `fdisk -t -u' is supposed to test it, and `fdisk -u' -- to do it. > > That doesn't work. That's kinda my whole point. The -u option is certainly intended to do this. Do the parameters actually fail to change, or is it just that boot0 still doesn't work? FWIW, if the disk still won't boot, and you want to send me the first sector of the disk (MBR), plus the first 16 sectors of the FreeBSD slice (boot blocks), I can probably work out what's going wrong. > > : Could you tell us about the differences? > > In a nutshell, they have been enhanced to do the math that we've all > done a zillion times (hmm, that last partition started at 132354 > and was 12341235 sectors long, so the next partition starts at ...). > Also they are nicer about editing things than the raw, bruit force > approach that fdisk especially currently uses. I actually made a start on a rewrite of fdisk, a month or so ago, though I don't think this will be done very soon. I'll look at the OpenBSD disklabel and fdisk changes and bring them across, if no-one else gets around to this first. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 6:13:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by hub.freebsd.org (Postfix) with ESMTP id AE47E116AF for ; Fri, 19 Feb 1999 06:13:50 -0800 (PST) (envelope-from peter.edwards@isocor.ie) Received: from isocor.ie (194.106.155.218) by penrose.isocor.ie; 19 Feb 1999 14:14:16 +0000 Message-ID: <36CD7145.EC9EA9D5@isocor.ie> Date: Fri, 19 Feb 1999 14:12:21 +0000 From: Peter Edwards Organization: ISOCOR X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: savecore before swapon? References: <199902171836.TAA00897@yedi.iaf.nl> <199902180049.QAA13082@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, How about _dumping_ to the end of the swap device, rather than hacking on the swap code. > :But this might be a lot of work, I'm not familiar with the VM. Ditto. Matthew Dillon wrote: > > :Or start allocating swap 'backwards' from the high block# on the disk > :downwards. Assuming swap > physical mem and dumps starting at swap offset 0 > :this should be safe at all times (unless fsck really allocates all swap > :of course ;-) > : > Hmm. Well, I don't want to reverse-index the swap allocation but it > would be possible to set the hinting on the swap radix tree bitmap > to allocate higher swap blocks first. I think it would be a little too > much of a hack to be worthy of the kernel, though. > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 7: 5:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ice.cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (Postfix) with ESMTP id 419E611673 for ; Fri, 19 Feb 1999 07:05:27 -0800 (PST) (envelope-from brandon@ice.cold.org) Received: (from brandon@localhost) by ice.cold.org (8.8.8/8.8.5) id IAA17588; Fri, 19 Feb 1999 08:05:19 -0700 (MST) Date: Fri, 19 Feb 1999 08:05:19 -0700 From: Brandon Gillespie To: Peter Edwards , freebsd-hackers@freebsd.org Subject: Re: savecore before swapon? Message-ID: <19990219080519.A17503@ice.cold.org> References: <199902171836.TAA00897@yedi.iaf.nl> <199902180049.QAA13082@apollo.backplane.com> <36CD7145.EC9EA9D5@isocor.ie> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=OXfL5xGRrasGEqWY; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.1i In-Reply-To: <36CD7145.EC9EA9D5@isocor.ie>; from Peter Edwards on Fri, Feb 19, 1999 at 02:12:21PM +0000 X-Operating-System: FreeBSD 2.2.8-RELEASE X-PGP-Public-Key: http://www.roguetrader.com/~brandon/brandon@roguetrader_com.pubkey Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii On Fri, Feb 19, 1999 at 02:12:21PM +0000, Peter Edwards wrote: > Hi, > How about _dumping_ to the end of the swap device, rather than hacking > on the swap code. Actually, I was thinking that rewriting the initial file checks in such a way that it first tries to do them without swap, if it fails it'll then query about starting swap (with a x-second timeout, defaulting to yes). Negative answer will result in a failure (and then init dropping into 'single user' mode)--where positive will just swapon -a, then run fsck again. Since 99% of the time it probably wont be an issue, I think this is probably the best solution (and simplest)... and it doesn't involve hacking anything other than the startup stuff. -Brandon Gillespie --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: tB1F0MgonsIEjAtl49U1N6s5J+y3tqhh iQA/AwUBNs19rkv5XoQiMgn6EQLipQCgtYFRujfgU9jMPZpP24u7Ni+nMZIAoMWR RhlrTlkYfUd7I6Tbi8WSAdsq =RJCh -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 7:42:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mgate07.so-net.ne.jp (mgate07.so-net.ne.jp [210.132.247.37]) by hub.freebsd.org (Postfix) with ESMTP id 3B92A11128 for ; Fri, 19 Feb 1999 07:42:13 -0800 (PST) (envelope-from sanewo@ba2.so-net.ne.jp) Received: from mail.ba2.so-net.ne.jp (mail.ba2.so-net.ne.jp [210.132.247.97]) by mgate07.so-net.ne.jp (8.8.8+3.0Wbeta9/3.6W99021523) with ESMTP id AAA26710 for ; Sat, 20 Feb 1999 00:42:12 +0900 (JST) Received: from ba2.so-net.ne.jp (p84b624.sng2.ap.so-net.ne.jp [210.132.182.36]) by mail.ba2.so-net.ne.jp (8.8.8+3.0Wbeta9/3.7W99021712) with ESMTP id AAA24794 for ; Sat, 20 Feb 1999 00:42:12 +0900 (JST) Message-Id: <199902191542.AAA24794@mail.ba2.so-net.ne.jp> To: freebsd-hackers@FreeBSD.ORG Subject: mfs behaviour change in last couple months? User-Agent: EMH/1.10.0 SEMI/1.13.3 (Komaiko) FLIM/1.12.6 (=?ISO-8859-4?Q?F?= =?ISO-8859-4?Q?amily-K=F2enmae?=) Emacs/20.3.92 (i686-pc-freebsd3.0) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII Date: Sat, 20 Feb 1999 00:42:11 +0900 From: SANETO Takanori Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have 128MB of memory and 700MB of swap area on my PC. I have 190MB of mfs, fstab entry of which is as follows: swap /tmp mfs rw,-s=380000 0 0 Recently (since the end of last year, I guess) I noticed that when mounting mfs, heavy disk I/O occurs. It seems that mfs's VM space is swapped (or paged) out when it is invoked (or when mfs newfs'es its VM space). Could it be because of an mfs implementation change? VM? Any ideas? -- Takanori "Roy" Saneto To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 8:24:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id 8809B118A6 for ; Fri, 19 Feb 1999 08:24:34 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id AAA07202; Sat, 20 Feb 1999 00:23:51 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199902191623.AAA07202@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Richard Seaman, Jr." Cc: Geoff Rehmet , "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes In-reply-to: Your message of "Thu, 18 Feb 1999 10:29:49 CST." <19990218102949.A38074@tar.com> Date: Sat, 20 Feb 1999 00:23:51 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Richard Seaman, Jr." wrote: > On Thu, Feb 18, 1999 at 05:14:08PM +0200, Geoff Rehmet wrote: > > I've managed to get (what appears to be) a successful Star Office 5 > > installation by following the transcript on lt.tar.com. > > However, when I try to register it, I run into the problem that > > I get a BASIC runtime error in the registration "wizard". > > I believe a number of other ppl have run into this same problem. > > Does anyone know how to resolve this? > > 1) Make sure you have your Office50/bin directory in your PATH environment. > That seemed to fix it for me. I've tried that, and all permutations of it (beginning, middle and end of path). Not the slightest difference. > 2) Others have reported that reinstalling seems to work No difference. I tried zapping the ~/.user.rdb file that it uses in between reinstalling as well, just in case. No joy there either. > 3) Others have reported that executing the "fix install" or whatever > the command is called, has helped. I hadn't tried this before.. (Office50/bin/setup; select "repair installation"), no joy their either. > 4) I think there are people who have not been able to solve this > problem. I don't know anybody who's been able to get it to work, except for you. :-) I was toying with the idea of using the fax/email method of registering and typing in the codes, but I decided to have a look around first. I tried the example scripts, and a good number of them also had the same sort of runtime errors. About the only thing left I can think of is hardware/memory/cpu differences. I upgraded my motherboard (doubled ram to 128MB) and a 50% faster cpu (still a cyrix though. :-(..) and replaced the drives with a much faster set and still didn't get any joy. What I'm curious to know is, does it consistantly work for you when you reinstall it and reregister it? Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 8:50:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 623441183A; Fri, 19 Feb 1999 08:50:13 -0800 (PST) To: dillon@FreeBSD.ORG Subject: Re: Re: softupdate panic, anyone seen this? (fwd) Cc: hackers@FreeBSD.ORG, jake@checker.org, julian@whistle.com, mckusick@McKusick.COM Message-Id: <19990219165013.623441183A@hub.freebsd.org> Date: Fri, 19 Feb 1999 08:50:13 -0800 (PST) From: hsu@FreeBSD.ORG (Jeffrey Hsu) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd appreciate it if someone could verify the double LIST_REMOVE() > bug. vn_syncer_add_to_worklist() already removes the vn from > the list ( assuming the VONWORKLIST v_flag is set, which it should be > in this case ). I've also come across the extra LIST_REMOVE in sched_sync() before and have been running the following patch which is nearly identical to yours for a few days now. The only other thing we might consider is removing the VONWORKLST flag checks which appear to be unnecessary now. But I've left them in as extra protection. Index: vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.186 diff -c -r1.186 vfs_subr.c *** vfs_subr.c 1999/02/04 18:25:39 1.186 --- vfs_subr.c 1999/02/18 19:31:08 *************** *** 948,954 **** /* * Move ourselves to the back of the sync list. */ - LIST_REMOVE(vp, v_synclist); vn_syncer_add_to_worklist(vp, syncdelay); } } --- 948,953 ---- *************** *** 2849,2860 **** --- 2848,2865 ---- } */ *ap; { struct vnode *vp = ap->a_vp; + int s; vp->v_mount->mnt_syncer = NULL; + + s = splbio(); + if (vp->v_flag & VONWORKLST) { LIST_REMOVE(vp, v_synclist); vp->v_flag &= ~VONWORKLST; } + + splx(s); return (0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 9: 3:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 48D0611424 for ; Fri, 19 Feb 1999 09:03:18 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id LAA49161; Fri, 19 Feb 1999 11:02:55 -0600 (CST) (envelope-from dick) Date: Fri, 19 Feb 1999 11:02:55 -0600 From: "Richard Seaman, Jr." To: Peter Wemm Cc: "Richard Seaman, Jr." , Geoff Rehmet , "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes Message-ID: <19990219110255.B44582@tar.com> References: <19990218102949.A38074@tar.com> <199902191623.AAA07202@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199902191623.AAA07202@spinner.netplex.com.au>; from Peter Wemm on Sat, Feb 20, 1999 at 12:23:51AM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 20, 1999 at 12:23:51AM +0800, Peter Wemm wrote: > I don't know anybody who's been able to get it to work, except for you. :-) Actually, I think quite a few people are running it ok. > I was toying with the idea of using the fax/email method of registering > and typing in the codes, but I decided to have a look around first. I > tried the example scripts, and a good number of them also had the same > sort of runtime errors. Yes, I think the problem is more than just the registration script. Somehow I think it can't find some of the files it needs, or the environment doesn't get set right, or something like that. > About the only thing left I can think of is hardware/memory/cpu > differences. I upgraded my motherboard (doubled ram to 128MB) and a 50% > faster cpu (still a cyrix though. :-(..) and replaced the drives with a > much faster set and still didn't get any joy. FWIW, I'm running it on a machine with K6-266, 256MB RAM, 512MB swap, and its on a 11.5GB UDMA drive. But, I really doubt that hardware is the issue. > What I'm curious to know is, does it consistantly work for you when you > reinstall it and reregister it? It consistently works, but I haven't tried reinstalling and re-registering except 1) the first time I installed it and had the same problems you do 2) the second time I reinstalled it, when it worked, and 3) the last time I installed it to generate the transcript that is at lt.tar.com. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 10:18:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 04CA011424 for ; Fri, 19 Feb 1999 10:18:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA00831; Fri, 19 Feb 1999 10:18:34 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Feb 1999 10:18:34 -0800 (PST) From: Matthew Dillon Message-Id: <199902191818.KAA00831@apollo.backplane.com> To: SANETO Takanori Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mfs behaviour change in last couple months? References: <199902191542.AAA24794@mail.ba2.so-net.ne.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have 128MB of memory and 700MB of swap area on my PC. : :I have 190MB of mfs, fstab entry of which is as follows: : :swap /tmp mfs rw,-s=380000 0 0 : :Recently (since the end of last year, I guess) I noticed that when :mounting mfs, heavy disk I/O occurs. It seems that mfs's VM space is :swapped (or paged) out when it is invoked (or when mfs newfs'es its VM :space). : :Could it be because of an mfs implementation change? VM? : :Any ideas? :-- :Takanori "Roy" Saneto There haven't been any changes specific to making it swap on startup. I've got a 300MB MFS partition and haven't noticed any heavy disk activity on startup. You could try reducing the number of pages mount_mfs touches when it newfs's the filesystem by specifying a higher bytes/inode ratio and playing with other insundry options. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 10:56:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rmstar.campus.luth.se (rmstar.campus.luth.se [130.240.197.32]) by hub.freebsd.org (Postfix) with ESMTP id 9D7BD1191C for ; Fri, 19 Feb 1999 10:56:09 -0800 (PST) (envelope-from murduth@rmstar.campus.luth.se) Received: from rmstar.campus.luth.se (murduth@LOCALHOST [127.0.0.1]) by rmstar.campus.luth.se (8.9.1/8.9.1) with ESMTP id TAA21622; Fri, 19 Feb 1999 19:56:03 +0100 (CET) (envelope-from murduth@rmstar.campus.luth.se) Message-Id: <199902191856.TAA21622@rmstar.campus.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: SANETO Takanori Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mfs behaviour change in last couple months? In-Reply-To: Your message of "Sat, 20 Feb 1999 00:42:11 +0900." <199902191542.AAA24794@mail.ba2.so-net.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Feb 1999 19:56:02 +0100 From: Joakim Henriksson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Recently (since the end of last year, I guess) I noticed that when > mounting mfs, heavy disk I/O occurs. It seems that mfs's VM space is > swapped (or paged) out when it is invoked (or when mfs newfs'es its VM > space). I have seen this also, i've even sent in a PR for it bin/9444 if anyone is interested. > Could it be because of an mfs implementation change? VM? This occured for me before any of the changes in the VM system came in so that is not the culprit anyway. Other than that i have absolutely no idea what could cause MFS to "touch" a lot of pages. -- regards/ Joakim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 10:59:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A3BFD11971 for ; Fri, 19 Feb 1999 10:59:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA01160; Fri, 19 Feb 1999 10:59:41 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Feb 1999 10:59:41 -0800 (PST) From: Matthew Dillon Message-Id: <199902191859.KAA01160@apollo.backplane.com> To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I started testing again to see what I could see. This is an alpha platform :(*really* shouldn't matter, right? this ain't linux, this ain't no disco, :pal....) : :Simple hardware. Alpha PC164 (432Mhz) with 256MB memory. : :Again, a very simple setup- just those stupid dirty buffer testing :programs. A single 9GB filesystem (not root or swap). Softupdates not :enabled, buf realloc still enabled (the 'default'- if it's broken, why :ship with it enabled?). 100 instances of programs that write 150mb files :and then check them one by one. The filesystem was nothing unusual- :following concerns of others about CCD's this is wasn't even an CCD. :Following concerns about fragsize and blocksize this was a Frag 1024 :Blocksize 8192 (8192 is pagesize for alpha), and the actual size was :truncated to make an exact geometry fit. : :System was completely unresponsive after starting this test. It eventually :(I went home) started being responsive again since a 'sync' completed :(thisis a usability problem, but I'l start whining about that when the :system stays up long enough to be usable). : :When I came in this morning, it was in DDB with: : :panic: getnewbuf: cannot get buffer, infinite recursion failure :panic :Stopped at Debugger..ng+0x24: ldq ra,0(sp) :<0xfffffe0007be59a0> :db> t :Debugger..ng() at Debugger..ng+0x24 :panic..ng() at panic..ng+0xf0 :getnewbuf..ng() at getnewbuf..ng+0x424 :getblk..ng() at getblk..ng+0x3e0 :bread..ng() at bread..ng+0x34 :ffs_balloc..ng() at ffs_balloc..ng+0x784 :ffs_write..ng() at ffs_write..ng+0x384 :vn_write..ng() at vn_write..ng+0x160 :write..ng() at write..ng+0x12c :syscall..ng() at syscall..ng+0x1dc :XentSys() at XentSys+0x50 :(null)() at 0x120000fe8 : :Is it truly the case that other people don't find these panics? This is :*not* that unusual a scenario for a server (well, maybe an NFS server, but :there are most certainly other server types). : :-matt The alpha has a way of bringing out bugs in the code. Kirk, Jeffrey, and I have committed a pretty serious fix to the vnode dirtyblkhd and syncer queueing code. I would be interested to know whether the new code solves the above problem or at least generates a more reasonable panic. So far so good for me... my make buildworld on an NFS-backed VN partition ( with softupdates off ) is working so far. It will be a few hours before I know whether it worked completely. If it works, I'll retest with softupdates turned on in that partition. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 11: 4: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8921311A6C for ; Fri, 19 Feb 1999 11:03:54 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA23211; Fri, 19 Feb 1999 10:58:24 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdg23191; Fri Feb 19 18:58:12 1999 Date: Fri, 19 Feb 1999 10:57:50 -0800 (PST) From: Julian Elischer To: Warner Losh Cc: hackers@FreeBSD.ORG Subject: Re: fdisk In-Reply-To: <199902191005.DAA01110@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The parameters are "synthesised" by assuming that the last sector of the BSD partition is ion the last sector of the last head of it's cylinder. so if you are trying ot say that the disk has 2 heads and 10 sectors per track you would manually set the ending head number to 1 and the ending sector to 10 (sectors are 1-based) The fact that the calculations wouldn't work out don't matter as NOTHING uses those numbers except the wd driver in a last ditch attempt to try find a geometry somewhere. julian On Fri, 19 Feb 1999, Warner Losh wrote: > How do I make fdisk(8) update the bios parameters for a disk drive. By BIOS > parameters, I mean the bios parameters in sector 0. > > fdisk appears to set the incore copy (or at least purports to do so), but > appear to update the parameters on the disk. > > Yes. I really really really want to do this. The disk is the only one > system, but I could put it into another system. > > Actually, why do I want to do this? > > I'm wanting to make this disk bootable. I've installed boot0 (which appears > to be working correctly). However, when I hit F1 or F2, nothing happens except > a single disk access. If I boot off floppy, then enter wd(0,a)/boot/loader > it works great. This usually indicates that the mbr parameters don't match > the parameters which this bios comes up with. The boot message indicates > a mismatch (since dmesg tells me cyl 3152, head 16, sectors 63). fdisk > tells me 1576, head 32, sector 63. > > So am I barking up the wrong tree? > > Warner > > P.S. I think I need to port OpenBSD's disklabel and fdisk since they are > slightly less frustrating that FreeBSD's. Todd Miller has done some good > work there. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 11:21:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A9C71189B for ; Fri, 19 Feb 1999 11:20:57 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA28524; Fri, 19 Feb 1999 11:20:29 -0800 Date: Fri, 19 Feb 1999 11:20:29 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902191859.KAA01160@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll be trying this later today, thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 11:23: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F0F8A11895 for ; Fri, 19 Feb 1999 11:22:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA01371; Fri, 19 Feb 1999 11:22:58 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Feb 1999 11:22:58 -0800 (PST) From: Matthew Dillon Message-Id: <199902191922.LAA01371@apollo.backplane.com> To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :I'll be trying this later today, thanks! : Uck. VN is still blowing up on me... but at least not with the syncer panic any more. There's some other interaction going on with NFS backed VN. It isn't crashing, but some of the files get corrupted. This should be easier to track down with the evidence of the file accessible. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 11:35:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 22A9111B85 for ; Fri, 19 Feb 1999 11:35:32 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id TAA81703; Fri, 19 Feb 1999 19:32:00 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 19 Feb 1999 19:32:00 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 18 Feb 1999, Matthew Jacob wrote: > > Oh, btw- I should clarify a little about this test and some spice to the > mix... The same test on a system that is 25% of the cpu power and 25% of > the memory running solaris 2.7 Intel not only successfully has always runs > this test but also retains a quite acceptable responsiveness. Please don't > make me claim Slowlaris is better! I haven't managed to make my machine crash yet (probably because I have a smaller drive and less memory) but I can certainly reproduce the reponsiveness problem (which is severe). It appears to be caused by a lock cascade leading to the root vnode being locked for long periods of time. I'm not quite sure of the sequence of events yet but it seems that the process holding the vnode lock is being starved out in favour of some of the processes which are writing their huge files. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 11:35:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 07FC711C47 for ; Fri, 19 Feb 1999 11:35:39 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.2/8.8.8) with ESMTP id TAA81667; Fri, 19 Feb 1999 19:26:00 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 19 Feb 1999 19:25:59 +0000 (GMT) From: Doug Rabson To: "Richard Seaman, Jr." Cc: Peter Wemm , Geoff Rehmet , "'hackers@freebsd.org'" Subject: Re: Star Office 5 woes In-Reply-To: <19990219110255.B44582@tar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Richard Seaman, Jr. wrote: > On Sat, Feb 20, 1999 at 12:23:51AM +0800, Peter Wemm wrote: > > > I don't know anybody who's been able to get it to work, except for you. :-) > > Actually, I think quite a few people are running it ok. > > > I was toying with the idea of using the fax/email method of registering > > and typing in the codes, but I decided to have a look around first. I > > tried the example scripts, and a good number of them also had the same > > sort of runtime errors. > > Yes, I think the problem is more than just the registration script. Somehow > I think it can't find some of the files it needs, or the environment doesn't > get set right, or something like that. > > > About the only thing left I can think of is hardware/memory/cpu > > differences. I upgraded my motherboard (doubled ram to 128MB) and a 50% > > faster cpu (still a cyrix though. :-(..) and replaced the drives with a > > much faster set and still didn't get any joy. > > FWIW, I'm running it on a machine with K6-266, 256MB RAM, 512MB swap, > and its on a 11.5GB UDMA drive. But, I really doubt that hardware is > the issue. > > > What I'm curious to know is, does it consistantly work for you when you > > reinstall it and reregister it? > > It consistently works, but I haven't tried reinstalling and re-registering > except 1) the first time I installed it and had the same problems you do > 2) the second time I reinstalled it, when it worked, and 3) the last time > I installed it to generate the transcript that is at lt.tar.com. When I first installed it, I had the problem and fixed it with the 'repair' option of the setup program. I had to reinstall it recently and I could not get the registration thing to work at all whatever I tried. Fortunately I had a record of the keys. Note that a new version is available (5.0.1) which probably addresses some of the registration issues. With this version, all the registration information (from the website when you fill in the form for downloading) is given to the setup program and there is no extra dialog to fill in after installation. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 12:24:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with SMTP id 618A811403 for ; Fri, 19 Feb 1999 12:24:06 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 10DwSz-0001Qz-00; Fri, 19 Feb 1999 13:24:05 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.2/8.8.3) with ESMTP id NAA05543; Fri, 19 Feb 1999 13:23:44 -0700 (MST) Message-Id: <199902192023.NAA05543@harmony.village.org> To: Robert Nordier Subject: Re: fdisk Cc: ru@ucb.crimea.ua, hackers@FreeBSD.ORG In-reply-to: Your message of "Sat, 19 Feb 1999 16:04:18 +0200." <199902191404.QAA08574@ceia.nordier.com> References: <199902191404.QAA08574@ceia.nordier.com> Date: Fri, 19 Feb 1999 13:23:43 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199902191404.QAA08574@ceia.nordier.com> Robert Nordier writes: : Warner Losh wrote: : > In message <19990219122814.A65108@ucb.crimea.ua> Ruslan Ermilov writes: : > : I suppose, you're talking about compatibility mode disk, are you? : > : If yes, `fdisk -t -u' is supposed to test it, and `fdisk -u' -- to do it. : > : > That doesn't work. That's kinda my whole point. : : The -u option is certainly intended to do this. Do the parameters : actually fail to change, or is it just that boot0 still doesn't : work? The parameters fail to change. I can do a fdisk right after the first one and they are still the same :-(. fdisk -i or -u doesn't matter. If I don't do a fdisk after the first one to verify, they still don't change. : FWIW, if the disk still won't boot, and you want to send me the : first sector of the disk (MBR), plus the first 16 sectors of the : FreeBSD slice (boot blocks), I can probably work out what's going : wrong. Cool. Both FreeBSD and Windows aren't booting, so I think it is a geometry problem. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 12:26:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from epistolic.cynic.net (epistolic.cynic.net [199.175.137.136]) by hub.freebsd.org (Postfix) with ESMTP id AB07011AB1 for ; Fri, 19 Feb 1999 12:25:18 -0800 (PST) (envelope-from cjs@cynic.net) Received: from localhost (localhost [[UNIX: localhost]]) by epistolic.cynic.net (8.9.1a/8.9.1) with SMTP id MAA20082; Fri, 19 Feb 1999 12:25:14 -0800 (PST) Date: Fri, 19 Feb 1999 12:25:13 -0800 (PST) From: Curt Sampson To: Peter Edwards Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: savecore before swapon? In-Reply-To: <36CD7145.EC9EA9D5@isocor.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Peter Edwards wrote: > Matthew Dillon wrote: > > > > :Or start allocating swap 'backwards' from the high block# on the disk > > :downwards. > > How about _dumping_ to the end of the swap device, rather than hacking > on the swap code. Not hard. See NetBSD's code to set dumplo and call the dump function in src/sys/arch/i386/i386/machdep.c. (I notice you have a dumplo variable in that FreeBSD file, too, but it's never set.) dev/scsipi/sd.c's sddump function starts the dump at offset dumplo (FreeBSD's old scsi/sd.c does the same. I don't know where the code in this file has gone to under CAM.) cjs -- Curt Sampson 604 801 5335 De gustibus, aut bene aut nihil. The most widely ported operating system in the world: http://www.netbsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 12:38:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5083111729 for ; Fri, 19 Feb 1999 12:38:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA02782; Fri, 19 Feb 1999 12:38:20 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Feb 1999 12:38:20 -0800 (PST) From: Matthew Dillon Message-Id: <199902192038.MAA02782@apollo.backplane.com> To: Curt Sampson Cc: Peter Edwards , freebsd-hackers@FreeBSD.ORG Subject: Re: savecore before swapon? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Matthew Dillon wrote: :> > :> > :Or start allocating swap 'backwards' from the high block# on the disk :> > :downwards. :> :> How about _dumping_ to the end of the swap device, rather than hacking :> on the swap code. : :Not hard. See NetBSD's code to set dumplo and call the dump function in :src/sys/arch/i386/i386/machdep.c. (I notice you have a dumplo variable :in that FreeBSD file, too, but it's never set.) : :dev/scsipi/sd.c's sddump function starts the dump at offset dumplo :(FreeBSD's old scsi/sd.c does the same. I don't know where the code :in this file has gone to under CAM.) : :cjs :-- :Curt Sampson 604 801 5335 De gustibus, aut bene aut nihil. Don'tcha love solutions that are staring you in the face? dumplo is the obvious solution. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 15:25:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 0B1BC11566 for ; Fri, 19 Feb 1999 15:22:39 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA08795; Fri, 19 Feb 1999 16:22:29 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd008729; Fri Feb 19 16:22:28 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA10132; Fri, 19 Feb 1999 16:20:47 -0700 (MST) From: Terry Lambert Message-Id: <199902192320.QAA10132@usr02.primenet.com> Subject: Re: vm_page_zero_fill To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 19 Feb 1999 23:20:36 +0000 (GMT) Cc: toasty@home.dragondata.com, dyson@iquest.net, tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902172020.MAA10702@apollo.backplane.com> from "Matthew Dillon" at Feb 17, 99 12:20:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :What if I'm doing a partial read? Is a partial read even possible if I'm > :using the mmap method? > > The filesystem always does a full read even if you only do a partial > read. This is true whether you use read() or access a page w/ mmap(), > but it is doubly true with mmap(). The only exception is the perhaps-not-page-aligned last blocks in the file. In this case, it zero fills the page before the read, in case of subsequent file extension. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 15:38:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C5B1F11412 for ; Fri, 19 Feb 1999 15:36:48 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA14451; Fri, 19 Feb 1999 16:36:47 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd014359; Fri Feb 19 16:36:36 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA10966; Fri, 19 Feb 1999 16:36:26 -0700 (MST) From: Terry Lambert Message-Id: <199902192336.QAA10966@usr02.primenet.com> Subject: Re: LKM - interceptors To: dseg@texar.com (Dan Seguin) Date: Fri, 19 Feb 1999 23:36:26 +0000 (GMT) Cc: FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Dan Seguin" at Feb 17, 99 04:27:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi. I'd like to ask if it is possible to write a LKM that would intercept > certain system calls, (do something), then continue the (original) call. > I've looked at the misc LKM and understand moving the sysent, and so on. > Is it possible to reindex the sysent for your LKM (in all the places of > the system calls that you want to intercept), effectively > intercepting a number of system calls (say 3, 4 ,7 etc), then calling the > original system calls from oldent? > > > The goal of this would be to do something like truss but have it inside > of the kernel instead of outside without modifying the kernel (hence the > LKM). Yes, it's possible. You would grab the function pointer from the systent for the daisy-chain, and then replace it with a pointer to your function instead. LKM/KLD system calls already work this way (see the code in /sys/kern/ for system call loading). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 15:45:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 14189118BD for ; Fri, 19 Feb 1999 15:43:58 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA18726; Fri, 19 Feb 1999 16:43:50 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd018616; Fri Feb 19 16:43:43 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA11287; Fri, 19 Feb 1999 16:42:15 -0700 (MST) From: Terry Lambert Message-Id: <199902192342.QAA11287@usr02.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Fri, 19 Feb 1999 23:42:09 +0000 (GMT) Cc: tlambert@primenet.com, toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902172139.QAA70278@y.dyson.net> from "John S. Dyson" at Feb 17, 99 04:39:30 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is robbing Peter to pay Paul; in a way. The base assumption > > that you are hiding is that you aren't constrained by memory > > bandwidth. This isn't true if you are nearly saturating a PCI > > bus with 4 BT848's (to pick the highest memory bandwidth application > > I know about). > > I just realized something: > > Memory bandwidth is >> PCI bandwidth on good designs. I believe > that the PCI and memory busses are decoupled on at least some X86 machines. Well, I was just guessing about an application that would eat sufficient memory bandwidth. If BT848's on PCI can't, then make up your own story for what his ultra-secret product actually is. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 15:54:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A0BBF1177A for ; Fri, 19 Feb 1999 15:52:41 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA21071; Fri, 19 Feb 1999 16:52:40 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd020896; Fri Feb 19 16:52:35 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA11969; Fri, 19 Feb 1999 16:52:08 -0700 (MST) From: Terry Lambert Message-Id: <199902192352.QAA11969@usr02.primenet.com> Subject: Re: softupdate panic, anyone seen this? To: julian@whistle.com (Julian Elischer) Date: Fri, 19 Feb 1999 23:52:08 +0000 (GMT) Cc: andre.albsmeier@mchp.siemens.de, sanewo@ba2.so-net.ne.jp, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Feb 17, 99 03:55:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > WHY would you async mount an MFS? > it's an MFS! So you don't have to stall the caller copying the page-off-vnode memory to the swappable-page memory. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:28: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 355E811394 for ; Fri, 19 Feb 1999 16:27:55 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA08146; Fri, 19 Feb 1999 17:27:45 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd008006; Fri Feb 19 17:27:40 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA14243; Fri, 19 Feb 1999 17:27:23 -0700 (MST) From: Terry Lambert Message-Id: <199902200027.RAA14243@usr02.primenet.com> Subject: Re: UIDs greater than 65535? To: jdp@polstra.com (John Polstra) Date: Sat, 20 Feb 1999 00:27:22 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "John Polstra" at Feb 17, 99 10:10:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can anybody think of a reason why UIDs > 65535 wouldn't work under > FreeBSD? They seem to work, and I can't find any reason why they > shouldn't. Even the NFS protocol (though not necessarily all NFS > servers) seems to be able to accomodate 4-byte UIDs. 65536 in an unsigned short is -1 is "nobody". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:31: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id D45691194E for ; Fri, 19 Feb 1999 16:30:52 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA05786; Fri, 19 Feb 1999 17:30:51 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd005743; Fri Feb 19 17:30:44 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA14495; Fri, 19 Feb 1999 17:30:42 -0700 (MST) From: Terry Lambert Message-Id: <199902200030.RAA14495@usr02.primenet.com> Subject: Re: UIDs greater than 65535? To: andre.albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Sat, 20 Feb 1999 00:30:41 +0000 (GMT) Cc: jdp@polstra.com, hackers@FreeBSD.ORG In-Reply-To: <19990218093637.A1696@internal> from "Andre Albsmeier" at Feb 18, 99 09:36:37 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Can anybody think of a reason why UIDs > 65535 wouldn't work under > > FreeBSD? They seem to work, and I can't find any reason why they > > shouldn't. Even the NFS protocol (though not necessarily all NFS > > servers) seems to be able to accomodate 4-byte UIDs. > > I can only tell that quotas get big problems with ultra large uid's. > > See PR# 2325. I have a local fix here... it is ugly as sin and it > doesn't fix the problem but the effects. FWIW, quotas also have unresolvable Year 2038 problems, as well. UFS/FFS itself cas Year 2038 problems as well. Fortunately, CSRG thought ahead on this one, and reserved some fields for making it 64 bit, and defined that they would be initialized to zero in FS's until they were used. Unfortunately, someone in FreeBSD stole them for nanoseconds, instead of just using a small reserved area for the one time value that "make" uses that can (perhaps -- worst failure case is extra builds of derived files) be argued to need the resolution. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:35:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.tar.com (ns.tar.com [204.95.187.2]) by hub.freebsd.org (Postfix) with ESMTP id 27BCF10E54 for ; Fri, 19 Feb 1999 16:35:53 -0800 (PST) (envelope-from dick@ns.tar.com) Received: (from dick@localhost) by ns.tar.com (8.9.3/8.9.3) id SAA54878; Fri, 19 Feb 1999 18:35:42 -0600 (CST) (envelope-from dick) Date: Fri, 19 Feb 1999 18:35:42 -0600 From: "Richard Seaman, Jr." To: Peter Wemm Cc: hackers@freebsd.org Subject: Re: Star Office 5 woes Message-ID: <19990219183542.F44582@tar.com> References: <19990218102949.A38074@tar.com> <199902191623.AAA07202@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199902191623.AAA07202@spinner.netplex.com.au>; from Peter Wemm on Sat, Feb 20, 1999 at 12:23:51AM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Feb 20, 1999 at 12:23:51AM +0800, Peter Wemm wrote: > > 4) I think there are people who have not been able to solve this > > problem. > > I don't know anybody who's been able to get it to work, except for you. :-) For the heck of it, I got the new version, so501_01.tar, and installed it. The installation (which now includes the registration) went fine. However, closing the printer setup task causes SO to hang. This didn't happen under the earlier version. Other than that, everything else I tried seems to work ok, but I confess I don't routinely use SO, and maybe haven't given it a complete work out. The only reason I ever installed it to begin with was as a test of the linux threads emulation code. Are there any specific scripts or tasks that don't work properly that I can try out to see if I can reproduce a problem? -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:36: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 3215F10E54 for ; Fri, 19 Feb 1999 16:36:06 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA07750; Fri, 19 Feb 1999 17:35:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd007633; Fri Feb 19 17:35:44 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA14755; Fri, 19 Feb 1999 17:35:39 -0700 (MST) From: Terry Lambert Message-Id: <199902200035.RAA14755@usr02.primenet.com> Subject: Re: select(2) proposed change To: imp@village.org (Warner Losh) Date: Sat, 20 Feb 1999 00:35:39 +0000 (GMT) Cc: syssgm@detir.qld.gov.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902180815.BAA66534@harmony.village.org> from "Warner Losh" at Feb 18, 99 01:15:43 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : select() should > : be changed to do the subtraction. > > Select should *NEVER* be changed to do the subtraction. There are > *NO* current systems that do this by default. FreeBSD shouldn't > change. It is a *********S***T***U***P***I***D********** idea to > change the semantics of select(2) at this late stage of the game. To play devil's advocate here: this particular argument didn't get me anywhere with the X3J11 committee with regards to "volatile", "noalias", and prototypes in place of mandating symbol attribution in object files, to catch the problem at link time. I think it has something to do with the IQ of groups. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:36:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4485E11998 for ; Fri, 19 Feb 1999 16:36:52 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id QAA26140; Fri, 19 Feb 1999 16:36:51 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.2/8.9.1) id QAA03555; Fri, 19 Feb 1999 16:36:51 -0800 (PST) (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 In-Reply-To: <199902200027.RAA14243@usr02.primenet.com> Date: Fri, 19 Feb 1999 16:36:50 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Terry Lambert Subject: Re: UIDs greater than 65535? Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >> Can anybody think of a reason why UIDs > 65535 wouldn't work under >> FreeBSD? They seem to work, and I can't find any reason why they >> shouldn't. Even the NFS protocol (though not necessarily all NFS >> servers) seems to be able to accomodate 4-byte UIDs. > > 65536 in an unsigned short is -1 is "nobody". Actually, nobody is 65534 on FreeBSD systems. But anyway, I've only found a couple of places where UIDs are stored in unsigned shorts: * In the API to the System V message functions, in . * In Linux programs run under emulation. There are also some limits in archive files, because UIDs are encoded as (*gag*) 5-digit decimal numbers. These problems are all avoidable in the application I have in mind. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:38:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 75A9611872 for ; Fri, 19 Feb 1999 16:38:19 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA12414; Fri, 19 Feb 1999 17:38:18 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd012382; Fri Feb 19 17:38:13 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA14993; Fri, 19 Feb 1999 17:38:11 -0700 (MST) From: Terry Lambert Message-Id: <199902200038.RAA14993@usr02.primenet.com> Subject: Re: softupdate panic, anyone seen this? To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sat, 20 Feb 1999 00:38:10 +0000 (GMT) Cc: jake@checker.org, hackers@FreeBSD.ORG In-Reply-To: <199902180912.BAA18642@salsa.gv.tsc.tdk.com> from "Don Lewis" at Feb 18, 99 01:12:50 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > After reading the source for softdep_sync_metadata(), I might believe this > could happen if the system tried to sync the block device for a softdep > filesystem before had synced all the files. > > I don't know why MFS would have an effect on this. The only two things > I can think of are either swapping to a file on a softdep filesystem, or > somehow the softupdates stuff thinks it should be active on the MFS > filesystems. What does /sbin/mount say about the mount flags on these > filesystems? Ah. MFS does this because it has synchronization issues getting to the backing store object (it's basically the VM/buffer cache coherency issue in SVR4). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:46: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 4B0B211A0A for ; Fri, 19 Feb 1999 16:45:52 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA11395; Fri, 19 Feb 1999 17:45:52 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd011322; Fri Feb 19 17:45:42 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA15474; Fri, 19 Feb 1999 17:45:39 -0700 (MST) From: Terry Lambert Message-Id: <199902200045.RAA15474@usr02.primenet.com> Subject: Re: Searching an "old" BSD stdio To: desar@club-internet.fr (Francois Desarmenien) Date: Sat, 20 Feb 1999 00:45:39 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <36CC6969.31F9BBEB@club-internet.fr> from "Francois Desarmenien" at Feb 18, 99 07:26:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hello to all of you, > > May be some of you could help me. > > I have an old binary library, compiled with an old stdio implementation > I'd like to relink on a modern system. > > So I'm looking everywhere for pointers to get an old BSD stdio, such as > 4.2, which seems hard to find (at least for me). You should be able to use the new one, and you should be asking this on -questions instead of -hackers. The answer is: look in the net2 code on gatekeeper.dec.com, or contact CSRG directly, after paying USL your license fee (I think it is now around US$250,000) for an old tape that they probably will refuse to sell you for legal reasons, or get them to rip out just the stdio (which they might do for a consulting fee). This is *probably* the same code in DEC Ultrix 4.x, so you may be able to get the code out of DEC (Compaq). Alternately, fix your code. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 16:51: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 4E18211AE3 for ; Fri, 19 Feb 1999 16:50:34 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id RAA12927; Fri, 19 Feb 1999 17:50:33 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd012798; Fri Feb 19 17:50:25 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id RAA15634; Fri, 19 Feb 1999 17:50:12 -0700 (MST) From: Terry Lambert Message-Id: <199902200050.RAA15634@usr02.primenet.com> Subject: Re: [Alfred Perlstein ] Re: vm_page_zero_fill To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Sat, 20 Feb 1999 00:50:11 +0000 (GMT) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Smorgrav" at Feb 18, 99 09:20:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Last night i was kinda bored so i started looking for things to > optimize in freebsd, i noticed that the function src/sys/libkern/bcmp.c > looked not optimal. > > After playing with "gcc -O -S bcmp.c" on several platforms, i386, > sparc32, alpha. It seems to me that the function ought to be > replaced with this: [ ... C code elided ... ] I think that we would do well to provide C code, wherever possible, for all assmebly language code, no matter how suboptimal this ends up being. The reason for this is portability to new platforms becomes more immediate, though less optimal. The assembly code can later be "back filled", as necessary, as an optimization. The ugliest place for this type of thinking is locore.s and the bios crap, but it would speed inclusion of new platforms, and is probably worth the effort. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 17: 1:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 727CF118AA for ; Fri, 19 Feb 1999 17:01:50 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA20670; Fri, 19 Feb 1999 18:01:44 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd020553; Fri Feb 19 18:01:34 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA16228; Fri, 19 Feb 1999 18:01:23 -0700 (MST) From: Terry Lambert Message-Id: <199902200101.SAA16228@usr02.primenet.com> Subject: Fixing dlopen, ld.so, and upgrading the resolver To: bright@cygnus.rush.net (Alfred Perlstein) Date: Sat, 20 Feb 1999 01:01:23 +0000 (GMT) Cc: gurudatt@cs.tamu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Alfred Perlstein" at Feb 18, 99 08:41:41 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What libraries does one include to compile socket programs in freebsd? > > > solaris?> > > They are mostly part of libc and therefor linked in by default. Basically > you do not need these libs. -lsocket is a lame SRV4 (i think) thing because > BSD sockets are simulated (poorly) via userland code. > > If you get any unresolved symbols check the function's manpage, or > us 'nm' on the libraries in /usr/lib to locate it. On the other hand, the -lnsl has been changed to -lresolve, and is standard on most platforms. The lack of this library in FreeBSD is caused by the resolver code being integrated into libc. It is probably time for this to change. It can still be *virtually* in libc in ELF by linking libc.so against libresolve.so (though I find this approach to be *highly* undesirable, since it means that things that link dynamically will need a different command line to link statically (e.g.: another library argument). By the same token, it's about time for an nsswitch, so that things like getpwent can be backed by password files or databases, for purposes other than authentication (e.g. PAM is useless for getting GECOS data out of an LDAP directory). PAM and an nsswitch imply a need for statically linked objects to be able to access dlopen and friends (or an end to static linking). SVR4 handles this with a libdlopen, and the execution class loader premaps the ld.so into all images. The library stub is basically jump table data for the premapped ld.so. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 17: 6: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id B13C411CA5 for ; Fri, 19 Feb 1999 17:05:54 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA21823; Fri, 19 Feb 1999 18:05:53 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd021795; Fri Feb 19 18:05:49 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA16481; Fri, 19 Feb 1999 18:05:41 -0700 (MST) From: Terry Lambert Message-Id: <199902200105.SAA16481@usr02.primenet.com> Subject: Re: What libraries for socket programs in FreeBSD? To: grog@lemis.com (Greg Lehey) Date: Sat, 20 Feb 1999 01:05:38 +0000 (GMT) Cc: bright@cygnus.rush.net, gurudatt@cs.tamu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990219145732.B93492@lemis.com> from "Greg Lehey" at Feb 19, 99 02:57:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > They are mostly part of libc and therefor linked in by default. Basically > > you do not need these libs. -lsocket is a lame SRV4 (i think) thing because > > BSD sockets are simulated (poorly) via userland code. > > Some System V implementations have native sockets. Specifically, for Solaris to be able to run statically linked SunOS 4.x binaries, it must support the socket family of calls a system calls. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 17:20:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 8D81E1192A for ; Fri, 19 Feb 1999 17:19:52 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA27484; Fri, 19 Feb 1999 18:19:52 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd027447; Fri Feb 19 18:19:49 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA17512; Fri, 19 Feb 1999 18:19:44 -0700 (MST) From: Terry Lambert Message-Id: <199902200119.SAA17512@usr02.primenet.com> Subject: Re: UIDs greater than 65535? To: jdp@polstra.com (John Polstra) Date: Sat, 20 Feb 1999 01:19:44 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "John Polstra" at Feb 19, 99 04:36:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> Can anybody think of a reason why UIDs > 65535 wouldn't work under > >> FreeBSD? They seem to work, and I can't find any reason why they > >> shouldn't. Even the NFS protocol (though not necessarily all NFS > >> servers) seems to be able to accomodate 4-byte UIDs. > > > > 65536 in an unsigned short is -1 is "nobody". > > Actually, nobody is 65534 on FreeBSD systems. But anyway, I've only > found a couple of places where UIDs are stored in unsigned shorts: I meant 65535, but yeah, -2 is right. I can't remember back to Ultrix, but I know -1 was *something*; ah, got it. It's who root becomes if you don't allow root access via NFS. > * In the API to the System V message functions, in . > * In Linux programs run under emulation. > > There are also some limits in archive files, because UIDs are encoded > as (*gag*) 5-digit decimal numbers. > > These problems are all avoidable in the application I have in mind. See the quota code. The thing uses a sparse file, and spazzes out > 65535. Not that it has spare space for the time_t going to 64 bits anyway. 8-(. I have a quota stacking layer that resolves both the Year 2038 issues and the uid_t/gid_t issues, includes version stamping the file, and has a format converter (quotacheck -c 1), but it won't run in an unhacked FreeBSD kernel because of my local VFS changes to support stacking layers actually working, and cleaner vnode based kernel file I/O. I think a stacking layer is the way to go; I can put quotas on my ext2fs and UMSDOS (stack over VFAT, using Udo Walter's attribute file: -linux--.--- [bletch] or mine: -umsdos-.--- [yea, symmetric, not OS tagged]) FS's. Woo hoo. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 21:22: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id B3F8B1161A for ; Fri, 19 Feb 1999 21:22:05 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA18122; Fri, 19 Feb 1999 22:21:51 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36CE466E.E29A845A@softweyr.com> Date: Fri, 19 Feb 1999 22:21:50 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Dag-Erling Smorgrav , hackers@FreeBSD.ORG Subject: Re: [Alfred Perlstein ] Re: vm_page_zero_fill References: <199902200050.RAA15634@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > I think that we would do well to provide C code, wherever possible, > for all assmebly language code, no matter how suboptimal this ends > up being. > > The reason for this is portability to new platforms becomes more > immediate, though less optimal. The assembly code can later be > "back filled", as necessary, as an optimization. > > The ugliest place for this type of thinking is locore.s and the bios > crap, but it would speed inclusion of new platforms, and is probably > worth the effort. Depending on the architecture in question, this might not even be that much of a loss. Architectures that have ONLY memory-mapped I/O, for instance, suffer less from low-level C code. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Feb 19 21:52:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 39FD210E6E for ; Fri, 19 Feb 1999 21:51:54 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA18165; Fri, 19 Feb 1999 22:51:26 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36CE4D5E.6C771232@softweyr.com> Date: Fri, 19 Feb 1999 22:51:26 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Greg Lehey , bright@cygnus.rush.net, gurudatt@cs.tamu.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: What libraries for socket programs in FreeBSD? References: <199902200105.SAA16481@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > Some System V implementations have native sockets. > > Specifically, for Solaris to be able to run statically linked SunOS 4.x > binaries, it must support the socket family of calls a system calls. Uh, no. Solaris supports all SunOS 4.x applications with a binary emulation layer that converts SunOS syscalls to Solaris emulation library calls. Some statically linked SunOS 4.x binaries don't work. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 1:48:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 0BBC111735 for ; Sat, 20 Feb 1999 01:48:06 -0800 (PST) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Sat, 20 Feb 1999 09:47:53 +0000 Received: from voodoo.pandhm.co.uk ([10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id F1KNMKZN; Sat, 20 Feb 1999 09:42:25 -0000 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 10E936-000ANG-00; Sat, 20 Feb 1999 09:50:13 +0000 To: Terry Lambert Cc: desar@club-internet.fr (Francois Desarmenien), freebsd-hackers@FreeBSD.ORG Subject: Re: Searching an "old" BSD stdio X-Mailer: nmh v0.26 X-Colour: Green Organization: Palmer & Harvey McLane In-Reply-To: Terry Lambert's message of "Sat, 20 Feb 1999 00:45:39 GMT" <199902200045.RAA15474@usr02.primenet.com> Date: Sat, 20 Feb 1999 09:50:12 +0000 From: Dom Mitchell Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 20 February 1999, Terry Lambert proclaimed: > > So I'm looking everywhere for pointers to get an old BSD stdio, such as > > 4.2, which seems hard to find (at least for me). > > [snip] > > The answer is: look in the net2 code on gatekeeper.dec.com, or > contact CSRG directly, after paying USL your license fee (I think > it is now around US$250,000) for an old tape that they probably > will refuse to sell you for legal reasons, or get them to rip out > just the stdio (which they might do for a consulting fee). Doesn't Kirk McKusick sell a complete BSD sources set on CDROM? I'd check the web page, but it appears to be inaccessible to me at the moment. I seem to recall that he required you obtain some kind of a license from SCO first, though... -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator Free your mind -- http://www.opensource.org/ -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 2: 8:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id 7ADA011302 for ; Sat, 20 Feb 1999 02:08:13 -0800 (PST) (envelope-from kim@telia.net) Received: from d1o202.telia.com (root@d1o202.telia.com [195.204.218.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id LAA20952 for ; Sat, 20 Feb 1999 11:08:11 +0100 (CET) Received: from telia.net (t2o212p6.telia.com [195.204.226.66]) by d1o202.telia.com (8.8.5/8.8.5) with ESMTP id LAA06901 for ; Sat, 20 Feb 1999 11:08:10 +0100 (CET) Message-ID: <36CE8982.A85F81FB@telia.net> Date: Sat, 20 Feb 1999 11:08:02 +0100 From: michael kim X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 2:17: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 01F4611740 for ; Sat, 20 Feb 1999 02:15:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id CAA07195; Sat, 20 Feb 1999 02:15:22 -0800 (PST) (envelope-from dillon) Date: Sat, 20 Feb 1999 02:15:22 -0800 (PST) From: Matthew Dillon Message-Id: <199902201015.CAA07195@apollo.backplane.com> To: Terry Lambert Cc: julian@whistle.com (Julian Elischer), andre.albsmeier@mchp.siemens.de, sanewo@ba2.so-net.ne.jp, freebsd-hackers@FreeBSD.ORG Subject: Re: softupdate panic, anyone seen this? References: <199902192352.QAA11969@usr02.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> WHY would you async mount an MFS? :> it's an MFS! : :So you don't have to stall the caller copying the page-off-vnode :memory to the swappable-page memory. : : Terry Lambert : terry@lambert.org So you don't have to do a context switch for each individual strategy call. -- Progress is being made on a number of fronts. I have about 9 commits ready to go as soon as they are approved which fix a bunch of things, including the VN device. And I have two patches that 'appear' to fix softupdates that have been sent to the softupdates crew for fodder. With them, I no longer get lockups or panics on a softupdates-enabled UFS filesystem sitting on a NFS-file-backed VN partition. ( But I've no idea if I'm solving the problems the right way. Probably not :-) ). I can now reliably make buildworld on the above said VN configuration ( as /usr/obj ). It's sweet, too... softupdates does an incredible job balancing the network load. It doles the file writes out to the network so smoothly I at first didn't realize that it was working. MFS, in contrast, eats system memory until the pageout daemon is forced to start paging it to swap in weird-looking bursts. The network I/O doesn't get in the way of the build at all - the system is 0% idle through most of it. I think the ultimate 'mfs' is going to be a direct-swap-backed VN partition running a softupdates-enabled UFS. The beast doesn't exist yet, but it wouldn't be too hard - we'd just use a vm_object instead of a vnode and vm_pager_get/put_pages(). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 4:17:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id C94C510E05 for ; Sat, 20 Feb 1999 04:17:40 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id MAA53242; Sat, 20 Feb 1999 12:17:10 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 20 Feb 1999 12:17:10 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902190915.BAA31066@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 19 Feb 1999, Matthew Dillon wrote: > :On Thu, 18 Feb 1999, Matthew Jacob wrote: > : > :> Oh, btw- I should clarify a little about this test and some spice to the > :> mix... The same test on a system that is 25% of the cpu power and 25% of > :> the memory running solaris 2.7 Intel not only successfully has always runs > :> this test but also retains a quite acceptable responsiveness. Please don't > :> make me claim Slowlaris is better! > : > :I'm sure that something very wrong is happening, don't worry. Hopefully, I > :will be able to see something. > : > :-- > :Doug Rabson Mail: dfr@nlsystems.com > :Nonlinear Systems Ltd. Phone: +44 181 442 9037 > > I've started testing the VN device. So far I've found it to be > extremely unstable when using an NFSV2 or NFSV3 file as backing > store. I'm going to try using an MFS based file as backing store > next to see whether the problem is with the VN device or the NFS device. > > I've gotten the bmsafemap softupdates panic with softupdates mounted > filesystems sitting on top of VN, but that was with the NFS-backed VN > test which was unstable even without softupdates so I don't know if > that is a real crash. > > I haven't tried reproducing the softupdates panic on its own merits > yet. I want to fix VN first. I've just been looking at the responsiveness problem associated with Matt Jacob's bulk writing test and I can see what is happening (although I'm not sure what to do about it). The system is unresponsive because the root inode is locked virtually all of the time and this is because of a lock cascade leading to a single process which is trying to rewrite a block of the directory which the test is running in (synchronously since the fs is not using softupdates). That process is waiting for its i/o to complete before unlocking the directory. Unfortunately the buffer is the last on the drive's buffer queue and there are 647 (for one instance which I examined in the debugger) buffers ahead of it, most of which are writing about 8k. About 4Mb of buffers on the queue are from a *single* process which seems extreme. The i/o for directories are being hugely delayed by the several bulk writing threads which the test has managed to start up and any directory which stays locked for long can easily lead to a locked root vnode (especially since there is a herd of processes in the test trying to create files in the same directory). I have modified my source tree to use bufq_insert_tail instead of bufqdisksort in scsi_da.c which didn't make any difference to the responsiveness problem (it probably made it worse since it would guarantee that the directory i/o is delayed by the maximum amount of time). It seems to me that there should be a mechanism to prevent the queued i/o lists from becoming so long (over 5Mb is queued on the machine which I have in the debugger), perhaps by throttling the writers if they start too much asynchronous i/o. I wonder if this can be treated as a similar problem to the swapper latency issues which John Dyson was talking about. I haven't seen the panic which Matt reported yet but I imagine that its an overload condition caused by the extreme amounts of pending i/o. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 10:13:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 295CE1183F for ; Sat, 20 Feb 1999 10:13:52 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id NAA27406 for ; Sat, 20 Feb 1999 13:13:46 -0500 (EST) Message-Id: <199902201813.NAA27406@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: race condition in rc/rc.network Date: Sat, 20 Feb 1999 13:13:46 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There exists a race condition in the startup scripts when using amd to automount a parition where shared libraries will be added with 'ldconfig_paths'. The problem is that AMD returns before it is fully ready, and is run (in network_pass3) almost immediately before the ldconfig line. The solution is from the 'wait4amd' script that is included in the am-utils distribution, but not included in our system?? It is basically to have a 'loose' loop check for amd being up before allowing the scripts to continue. I have included my diffs to rc.network below, and I hope they will find a warm, caring home in the CVS tree :) -- David Cross *** rc.network.old Sat Feb 20 12:56:18 1999 --- rc.network Sat Feb 20 13:05:29 1999 *************** *** 284,294 **** fi if [ "X${amd_enable}" = X"YES" ]; then ! echo -n ' amd' if [ "X${amd_map_program}" != X"NO" ]; then amd_flags="${amd_flags} `eval ${amd_map_program}`" fi amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null fi if [ "X${rwhod_enable}" = X"YES" ]; then --- 284,299 ---- fi if [ "X${amd_enable}" = X"YES" ]; then ! echo -n ' amd(' if [ "X${amd_map_program}" != X"NO" ]; then amd_flags="${amd_flags} `eval ${amd_map_program}`" fi amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null + while ! amq >/dev/null 2>&1; do + echo -n . + sleep 1; + done + echo -n ')' fi if [ "X${rwhod_enable}" = X"YES" ]; then To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 10:55:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from limbo.rtfm.net (limbo.rtfm.net [216.44.71.116]) by hub.freebsd.org (Postfix) with ESMTP id 91B5E111CF for ; Sat, 20 Feb 1999 10:55:00 -0800 (PST) (envelope-from nathan@limbo.rtfm.net) Received: (from nathan@localhost) by limbo.rtfm.net (8.9.3/8.9.1) id NAA00829 for hackers@FreeBSD.org; Sat, 20 Feb 1999 13:53:58 -0500 (EST) (envelope-from nathan) Message-ID: <19990220135357.A783@rtfm.net> Date: Sat, 20 Feb 1999 13:53:57 -0500 From: Nathan Dorfman To: hackers@FreeBSD.org Subject: pccard problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I'm having problems with pccard (3.1-R) and my PCCARD controller. This is a Fujitsu LifeBook 280dx, Lose95 identifies the controller as a Texas Instruments PCI-1220. chip3: rev 0x02 int a irq 9 on pci0.19.0 chip4: rev 0x02 int a irq 9 on pci0.19.1 It operates in some kind of Intel-compatible mode, and works just fine with PAO (pao3 and 3.0-R) and Linux (2.0.35 with pcmcia-cs 3.0.8). Stock 3.1-RELEASE pccard doesn't like it, however. a) it doesn't recognize card inserts/removes. the only way to get it to see a card as present is if the card is inserted at the time pcic is loaded b) allocate_driver() (userland calls the PIOCSDRV ioctl, which in turn calls this) locks up the machine in a very interesting way. The LED for the slot in question goes on, and the machine stops responding. At this point, I can't do *anything*, not even Ctrl+PrintScreen to drop to DDB. Now, if I eject the card in question, the system returns to normal. The ioctl(PIOCSDRV) returns errno 6 (ENXIO - No such device or address). This seems to indicate that find_driver("ed0") returns 0. I also get a few console messages: ed0: Unload Return IRQ=11 Because of problem a), I can't do anything now, not even read CIS data from the card, because it doesn't see that I've re-inserted the card (or removed it to begin with, for that matter). Now for more details: Card in question is an el cheapo NE2K clone. I stole a pccard.conf entry for it from PAO's pccard.conf (PAO, by the way, works perfectly, but I don't want to be stuck at 2.2.x or 3.0-R, and there is no PAO for 3.1-R; I'm also more interested in seeing pccard fixed in -stable so I can track it). The values I'm trying to use are: host address: 0xd4000 size 16k io 0x300-31f irq 11 These are the same values that lose95 uses (pccard works there too). The controller is on IRQ 9 in both cases. lose95 sets the pccard memory address to 0xc0000; I use 0xd0000 (FreeBSD's default), 0xc0000 causes garbled CIS data (that address is probably used, I don't know). I'm deeply grateful for any pointers in the right direction on this one. I'd really love to have this working soon so I can bring a working FreeBSD laptop to the FreeBSD Users New York group meeting on February 26. -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 11:46:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 510D611864 for ; Sat, 20 Feb 1999 11:45:48 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA22503; Sat, 20 Feb 1999 12:45:16 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd022325; Sat Feb 20 12:45:03 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA10350; Sat, 20 Feb 1999 12:44:41 -0700 (MST) From: Terry Lambert Message-Id: <199902201944.MAA10350@usr04.primenet.com> Subject: Re: What libraries for socket programs in FreeBSD? To: wes@softweyr.com (Wes Peters) Date: Sat, 20 Feb 1999 19:44:41 +0000 (GMT) Cc: tlambert@primenet.com, grog@lemis.com, bright@cygnus.rush.net, gurudatt@cs.tamu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: <36CE4D5E.6C771232@softweyr.com> from "Wes Peters" at Feb 19, 99 10:51:26 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Some System V implementations have native sockets. > > > > Specifically, for Solaris to be able to run statically linked SunOS 4.x > > binaries, it must support the socket family of calls a system calls. > > Uh, no. Solaris supports all SunOS 4.x applications with a binary > emulation layer that converts SunOS syscalls to Solaris emulation > library calls. Some statically linked SunOS 4.x binaries don't > work. Back when Weber State first purchased the new "icarus", and renamed the older SunOS 4.1.3 box to "cs", icarus was the first Solaris 2.x box there. I submitted a number of bugs to Sun, having to do with statically linked SunOS 4.1.3 binaries (including the X game "NodeRunner", my "LodeRunner" clone). I figured "what the hell?", since Weber had a support contract, and didn't have to pay per incident. In order to close these bug reports, Sun had to implement, among other things, a select(2) system call on Solaris. They did this in Solaris 2.3. I still have the trouble ticket resoloution email (somewhere). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 12:56:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9F72B118BF for ; Sat, 20 Feb 1999 12:56:19 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA11068; Sat, 20 Feb 1999 12:56:15 -0800 (PST) (envelope-from dillon) Date: Sat, 20 Feb 1999 12:56:15 -0800 (PST) From: Matthew Dillon Message-Id: <199902202056.MAA11068@apollo.backplane.com> To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Jacob's bulk writing test and I can see what is happening (although I'm :not sure what to do about it). : :The system is unresponsive because the root inode is locked virtually all :of the time and this is because of a lock cascade leading to a single :process which is trying to rewrite a block of the directory which the test :is running in (synchronously since the fs is not using softupdates). That :process is waiting for its i/o to complete before unlocking the directory. :Unfortunately the buffer is the last on the drive's buffer queue and there :are 647 (for one instance which I examined in the debugger) buffers ahead :of it, most of which are writing about 8k. About 4Mb of buffers on the :queue are from a *single* process which seems extreme. There isn't much we can do except to try to fix the lock cascade that occurs in namei and lookup. The problem is that the lower level vnode is locked before the parent vnode is released. What if we simply bumped the vnode's v_holdcnt or v_usecount in lookup instead of lock it, and then have the parent namei unlock the parent vnode prior to gaining a lock on the new vnode in its loop? This would limit the locking cascade to one vnode worst case. We would have to allow the bumping up and down of v_usecount by independant processes while an exclusive lock is held on it. :It seems to me that there should be a mechanism to prevent the queued i/o :lists from becoming so long (over 5Mb is queued on the machine which I :have in the debugger), perhaps by throttling the writers if they start too :much asynchronous i/o. I wonder if this can be treated as a similar :problem to the swapper latency issues which John Dyson was talking about. :-- Maybe. The difference is that the I/O topology is not known at the higher levels where the I/O gets queued, so it would be more difficult to calculate what the async limit should be in a scaleable way. -Matt Matthew Dillon :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 13: 9:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C27EE11910 for ; Sat, 20 Feb 1999 13:05:54 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id NAA32002 for ; Sat, 20 Feb 1999 13:05:40 -0800 Date: Sat, 20 Feb 1999 13:05:40 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As of the last set of fixes that added some more splbio protection, the testing has gone a lot better. Many thanks. Now I'll start raising the bar from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless someone says "No! No! Don't do that!") -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 13:32:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rah.star-gate.com (rah.star-gate.com [209.249.129.138]) by hub.freebsd.org (Postfix) with ESMTP id DF620118BA for ; Sat, 20 Feb 1999 13:32:15 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id NAA93070 for ; Sat, 20 Feb 1999 13:31:25 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199902202131.NAA93070@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Xf86 Disabler ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Feb 1999 13:31:25 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am looking for an x86 disabler (NON-GPL) . Its intended target is Netscape's Electric Fire (http://www.mozilla.org/projects/ef) . EF is a java VM capable of translating java to machine instructions and then executing them 8) Enjoy Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 13:36:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id BA3341193D for ; Sat, 20 Feb 1999 13:36:39 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA54093; Sat, 20 Feb 1999 21:35:40 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 20 Feb 1999 21:35:40 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902202056.MAA11068@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Feb 1999, Matthew Dillon wrote: > :Jacob's bulk writing test and I can see what is happening (although I'm > :not sure what to do about it). > : > :The system is unresponsive because the root inode is locked virtually all > :of the time and this is because of a lock cascade leading to a single > :process which is trying to rewrite a block of the directory which the test > :is running in (synchronously since the fs is not using softupdates). That > :process is waiting for its i/o to complete before unlocking the directory. > :Unfortunately the buffer is the last on the drive's buffer queue and there > :are 647 (for one instance which I examined in the debugger) buffers ahead > :of it, most of which are writing about 8k. About 4Mb of buffers on the > :queue are from a *single* process which seems extreme. > > There isn't much we can do except to try to fix the lock cascade that > occurs in namei and lookup. The problem is that the lower level vnode > is locked before the parent vnode is released. > > What if we simply bumped the vnode's v_holdcnt or v_usecount in lookup > instead of lock it, and then have the parent namei unlock the parent vnode > prior to gaining a lock on the new vnode in its loop? > > This would limit the locking cascade to one vnode worst case. We would > have to allow the bumping up and down of v_usecount by independant > processes while an exclusive lock is held on it. I always thought that the vnodes were locked that way during lookup to avoid more serious problems but I have never done the analysis to figure it out. Certainly there are some tricky cases in the way that lookup is used to prepare for a subsequent create or rename (but that isn't the issue here I think). If it works, then changing lookup to not require locks on both vnodes at the same time would be a good thing. One of the reasons that NFS doesn't have proper node locks is that a dead NFS server can lead to a hung machine though a lock cascade from the NFS mount point. > > :It seems to me that there should be a mechanism to prevent the queued i/o > :lists from becoming so long (over 5Mb is queued on the machine which I > :have in the debugger), perhaps by throttling the writers if they start too > :much asynchronous i/o. I wonder if this can be treated as a similar > :problem to the swapper latency issues which John Dyson was talking about. > :-- > > Maybe. The difference is that the I/O topology is not known at the > higher levels where the I/O gets queued, so it would be more difficult > to calculate what the async limit should be in a scaleable way. Understood. I played with a few non-solutions, limiting i/o on a mount point and on a vnode to an arbitrary limit but wasn't able to make a real difference to the responsiveness of the test. It does seem wrong that a single writer process can generate arbitrary amounts of latency (essentially only bounded by the number of available buffers) for other clients on the same drive. Ideally the driver should be able to propagate its 'queue full' signals up to the bio system but I can't see a way of doing that easily in the current code. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 13:51:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id D7B041194D for ; Sat, 20 Feb 1999 13:51:32 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA54157; Sat, 20 Feb 1999 21:50:51 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 20 Feb 1999 21:50:51 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Feb 1999, Matthew Jacob wrote: > > As of the last set of fixes that added some more splbio protection, the > testing has gone a lot better. Many thanks. Now I'll start raising the bar > from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless > someone says "No! No! Don't do that!") Its good that your panic seems to have been addressed but I can't see any quick solutions for the responsiveness problem. It appears to be a combination of the way that BSD looks up pathnames and the lack of any mechanism from stopping writer processes from monopolising the i/o queues. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 13:54:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id DD7611194A for ; Sat, 20 Feb 1999 13:54:35 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA20898; Sat, 20 Feb 1999 15:11:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd020845; Sat Feb 20 15:11:10 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA18160; Sat, 20 Feb 1999 14:54:20 -0700 (MST) From: Terry Lambert Message-Id: <199902202154.OAA18160@usr08.primenet.com> Subject: Interesting ld.so bug To: jdp@polstra.com (John Polstra) Date: Sat, 20 Feb 1999 21:54:19 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "John Polstra" at Feb 19, 99 04:36:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There appears to be a bug with ld.so. The following steps illustrate the bug: Create a shared library A, containing two functions, one dependent on the other: int A( int i) { int r; i++; r = B( i); return( r); } int B( int i) { int r; r = i + 2; return( r); } Create a shared library F, containing a function that calls the dependent function A from the shared library: int F( int i) { int r; i++; r = A( i); return( r); } Link shared library F against shared library A, such that you see it in the output of: objdump --all-headers libF.so.1 | grep NEEDS Create a shared object X; in it, call function F: void X( void) { int i; i = F( 5); printf( "F( 5) is %d\n", i); } Link the shared object X against the shared library F, such that you see it in the output of: objdump --all-headers X.So | grep NEEDS Now the fun part: o create a program that dlopen's X.So, and calls X() o gdb it o breakpoint dlopen o run o step through until A is called, and note that A is called correctly o step until just prior to calling B o note prior to the call to B that the jump table contains the correct fixup data; verify this by examining library libA.so.1 with ``objdump'' o attempt to step through the call to B o SIGSEGV Apparently, symbols in indirectly dependent libraries which are used by the indirectly dependent libraries are not fixed up correctly. It appears to be a failure to recurse on the leaf library so that it can self-reference its own symbols. This was noticed while attempting to implement a JNI in KAFFE, which uses dlopen's of shared objects to implement JNI. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 14: 5:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id EA13F118EC for ; Sat, 20 Feb 1999 14:05:56 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA24804; Sat, 20 Feb 1999 15:05:56 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd024681; Sat Feb 20 15:05:49 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA18466; Sat, 20 Feb 1999 15:05:39 -0700 (MST) From: Terry Lambert Message-Id: <199902202205.PAA18466@usr08.primenet.com> Subject: Re: Searching an "old" BSD stdio To: Dom.Mitchell@palmerharvey.co.uk (Dom Mitchell) Date: Sat, 20 Feb 1999 22:05:38 +0000 (GMT) Cc: tlambert@primenet.com, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Dom Mitchell" at Feb 20, 99 09:50:12 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Doesn't Kirk McKusick sell a complete BSD sources set on CDROM? I'd > check the web page, but it appears to be inaccessible to me at the > moment. I seem to recall that he required you obtain some kind of a > license from SCO first, though... The settlement agreement between UCB and USL, the terms of which are not permitted to be disclosed, made the Net and Net/2 distribution supposedly "illegal". Since you can't revoke a license granted in perpetuity (which is why Apple still has a valid license for the UCSD P system that they used to implement the original "QuickDraw"), DEC has declined to remove it from their gatekeeper.dec.com archive, as have hundreds of other licensees (even some institutions with more money than Bill Gates). Net was BSD 4.2, and Net/2 was BSD 4.3. I believe Kirk sells the 4.4-Lite2 CDROMs. If he sells others, it's only with proof of a Western Electric or later UNIX source license, to keep himself out of hot water. The specific requirement of the original poster was a BSD 4.2 stdio that could be linked against, presumably because of either promisucous reference to the implementation details of stdio, which have subsequently changed, or because a preexisting object file for which source is not available. If it's an object file, I'm pretty sure that they're screwed, unless they can contact the vendor of the box for the code; the stdio subsystem is one that every company thought they could "make better". If it's source, it'll probably have to be rewritten. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 14:11:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CBC611199A for ; Sat, 20 Feb 1999 14:11:02 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA32309; Sat, 20 Feb 1999 14:10:46 -0800 Date: Sat, 20 Feb 1999 14:10:45 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > > > As of the last set of fixes that added some more splbio protection, the > > testing has gone a lot better. Many thanks. Now I'll start raising the bar > > from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless > > someone says "No! No! Don't do that!") > > Its good that your panic seems to have been addressed but I can't see any > quick solutions for the responsiveness problem. It appears to be a > combination of the way that BSD looks up pathnames and the lack of any > mechanism from stopping writer processes from monopolising the i/o queues. yes, I saw the mail. fixing the panic is the first step. I'm not entirely sure that the root inode lock is the whole problem. I think another problem may be just growing very large delayed write queues- there doesn't seem to be any way any more to keep a single process from blowing the whole buffer cache- but I'd be the first to admit that my knowledge of this area of unix internals is 7-10 years old. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 14:28:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id A680411190 for ; Sat, 20 Feb 1999 14:28:49 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA14603; Sat, 20 Feb 1999 15:28:32 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd014564; Sat Feb 20 15:28:29 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA19198; Sat, 20 Feb 1999 15:28:15 -0700 (MST) From: Terry Lambert Message-Id: <199902202228.PAA19198@usr08.primenet.com> Subject: Re: softupdate panic, anyone seen this? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 20 Feb 1999 22:28:15 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, andre.albsmeier@mchp.siemens.de, sanewo@ba2.so-net.ne.jp, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902201015.CAA07195@apollo.backplane.com> from "Matthew Dillon" at Feb 20, 99 02:15:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> WHY would you async mount an MFS? > :> it's an MFS! > : > :So you don't have to stall the caller copying the page-off-vnode > :memory to the swappable-page memory. > > So you don't have to do a context switch for each individual strategy > call. That's what I meant by "stall". > I can now reliably make buildworld on the above said VN configuration > ( as /usr/obj ). It's sweet, too... softupdates does an incredible > job balancing the network load. It doles the file writes out to > the network so smoothly I at first didn't realize that it was working. Rightous. It's always the way that someone abuses a technology that makes the biggest steps forward. The unforseen application. It's terrifically funny that you get such a performance win from what is, in effect, "the anti-write-gatherer". 8-). At one time, write gathering was the be-all, end-all of NFS performance, short of battery backed static RAM. Think what you could do if you could use lease (opportunity lock) technology to manage distributed dependencies between two machines, using a Heidemann network proxy layer instead of relying on poor old NFS. There's actually a terrific paper out of Stanford on leases: Leases: an efficient fault-tolerant mechanism for distributed file cache consistency. Cary G. Gray and David R. Cheriton CS-TR-90-1298 January 1990 ...courtesy of http://sunsite.Berkeley.EDU/NCSTRL/ I'm pretty sure this is the basis of the NFSv3 LEASE code. I'm regretting ever more frequently the limitation of the soft updates technology to a specific soloution for a fixed directed acyclic graph (UFS + FFS order of operation dependencies), instead of a more general mechanism where edges are managed by contention resolvers (shades of netgraph). I know Kirk's stated reasons for this, but I have to say that I really, really disagree that specific registration of the UFS/FFS node contention resoloution code (e.g., a "dependency") would result in data structures any larger than the current ones. Besides, you only have to take the registration hit when you instance a file system, and filesystems know about themselves. Maybe someone who needs a PhD in CS will tackle generalizing the idea using the Ganger/Patt appendix A code so as to not "contaminate" themselves with the licensing issues for commercial use (e.g., too many cooks). I'd work on it, but I'm probably too polluted already, not from the code, but from the fact that Whistle has a strategic interest in having paid Kirk to do the port, and being an employee, I have a contract that prevents me from giving away the fort. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 14:42:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id CEF3D119BD for ; Sat, 20 Feb 1999 14:42:48 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA18282; Sat, 20 Feb 1999 15:42:42 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd018215; Sat Feb 20 15:42:35 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA19576; Sat, 20 Feb 1999 15:42:23 -0700 (MST) From: Terry Lambert Message-Id: <199902202242.PAA19576@usr08.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 20 Feb 1999 22:42:23 +0000 (GMT) Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199902202056.MAA11068@apollo.backplane.com> from "Matthew Dillon" at Feb 20, 99 12:56:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There isn't much we can do except to try to fix the lock cascade that > occurs in namei and lookup. The problem is that the lower level vnode > is locked before the parent vnode is released. That's on purpose. > What if we simply bumped the vnode's v_holdcnt or v_usecount in lookup > instead of lock it, and then have the parent namei unlock the parent vnode > prior to gaining a lock on the new vnode in its loop? This would open the race window the lock order is designed to prevent. You really need to look at the relookup code for the rename case to see why doing this is a really bad idea. > This would limit the locking cascade to one vnode worst case. We would > have to allow the bumping up and down of v_usecount by independant > processes while an exclusive lock is held on it. If you have access to a Solaris box, look in vnode.h, specifically at the HOLD and RELE macros. I don't think a hold is enough. I think the way to "fix" this is to have two queue insertion points, and insert directory writes as far forward as you can (some pigs are more equal than others). This would ensure short duration for directory operations. The second insertion point would be tracking the back-most directory write operation; typically, this would be the head of the queue, or serveral directory writes back from the head of the queue. Basically, you still do async, but vnode spanning operations get to "butt in line". I think you should include cross directory rename of files or directories, and simple renaming of directories in this list, as well as subdirectory deletions. You might also find an interaction with vfs.ffs.doasyncfree under pessimal conditions, on non-async mounted disks, FWIW. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 14:52:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id B98CB11A71 for ; Sat, 20 Feb 1999 14:52:35 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA20948; Sat, 20 Feb 1999 15:52:34 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd020893; Sat Feb 20 15:52:27 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA19845; Sat, 20 Feb 1999 15:52:21 -0700 (MST) From: Terry Lambert Message-Id: <199902202252.PAA19845@usr08.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dfr@nlsystems.com (Doug Rabson) Date: Sat, 20 Feb 1999 22:52:20 +0000 (GMT) Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 20, 99 09:35:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I always thought that the vnodes were locked that way during lookup to > avoid more serious problems but I have never done the analysis to figure > it out. Certainly there are some tricky cases in the way that lookup is > used to prepare for a subsequent create or rename (but that isn't the > issue here I think). See the rename code. > If it works, then changing lookup to not require locks on both vnodes at > the same time would be a good thing. One of the reasons that NFS doesn't > have proper node locks is that a dead NFS server can lead to a hung > machine though a lock cascade from the NFS mount point. The correct way to do this, IMO, is a back-off/retry, which would unlock the lock and queue the operation for retry, which would reacquire the lock. I swear I saw code in NFS to do this. Maybe it was pre-BSD4.4. > > Maybe. The difference is that the I/O topology is not known at the > > higher levels where the I/O gets queued, so it would be more difficult > > to calculate what the async limit should be in a scaleable way. > > Understood. I played with a few non-solutions, limiting i/o on a mount > point and on a vnode to an arbitrary limit but wasn't able to make a real > difference to the responsiveness of the test. > > It does seem wrong that a single writer process can generate arbitrary > amounts of latency (essentially only bounded by the number of available > buffers) for other clients on the same drive. Ideally the driver should be > able to propagate its 'queue full' signals up to the bio system but I > can't see a way of doing that easily in the current code. If the queue gets full, then the disk gets busy. In which case, you could convert to using sync writes for all pending directory operations. It should be pretty easy to do this kludge by (1) deciding how many waiters is "too many", and (2) checking if the mount is async. This would avoid propagating the changes up. I really think, though, that the correct fix is to flag the async writes for directory data in the code, and then when you do the lower level queue insertion, insert them ahead, per my other posting. I personally like the name "EXPEDITE" for the flag. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 15: 4: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 60ECB10E8D for ; Sat, 20 Feb 1999 15:03:58 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id XAA54281; Sat, 20 Feb 1999 23:03:24 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 20 Feb 1999 23:02:53 +0000 (GMT) From: Doug Rabson To: Matthew Jacob Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > > > > > > As of the last set of fixes that added some more splbio protection, the > > > testing has gone a lot better. Many thanks. Now I'll start raising the bar > > > from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless > > > someone says "No! No! Don't do that!") > > > > Its good that your panic seems to have been addressed but I can't see any > > quick solutions for the responsiveness problem. It appears to be a > > combination of the way that BSD looks up pathnames and the lack of any > > mechanism from stopping writer processes from monopolising the i/o queues. > > yes, I saw the mail. fixing the panic is the first step. > > I'm not entirely sure that the root inode lock is the whole problem. I > think another problem may be just growing very large delayed write queues- > there doesn't seem to be any way any more to keep a single process from > blowing the whole buffer cache- but I'd be the first to admit that my > knowledge of this area of unix internals is 7-10 years old. Certainly the root inode lock is the symptom. Even if it was fixed (by rewriting lookup), a single process can still generate unreasonable amounts of i/o. With a merged vmio system, this can cause huge latencies as we have seen. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 15:10: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4D15F10E05 for ; Sat, 20 Feb 1999 15:09:58 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA32537; Sat, 20 Feb 1999 15:09:36 -0800 Date: Sat, 20 Feb 1999 15:09:35 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > I'm not entirely sure that the root inode lock is the whole problem. I > > think another problem may be just growing very large delayed write queues- > > there doesn't seem to be any way any more to keep a single process from > > blowing the whole buffer cache- but I'd be the first to admit that my > > knowledge of this area of unix internals is 7-10 years old. > > Certainly the root inode lock is the symptom. Even if it was fixed (by > rewriting lookup), a single process can still generate unreasonable > amounts of i/o. With a merged vmio system, this can cause huge latencies > as we have seen. When I was at Kubota I did a bit of work in this area- essentially breaking the single bdelwri queue in 'generations' so that you could know when when pass had completed prior to allowing another set of passes (often dirtying the same buffers) to run- it was originally motivated to try and find a way to ensure that there was a known point at which I/O for delayed writes was complete. It strikes me that the lengths of such I/O (in a multidimensional measure of actual bytes, number of requests (before AND after clustering- clustering isn't always a win- particularly with 4th generation I/O hoses) and the number of different threads pushing I/O) becomes candidates for I/O scheduling at the VFS layer. Is anyone thinking along these lines? Sounds like a really good candidate for kernel threads... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 15:13:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id EB88010E8D for ; Sat, 20 Feb 1999 15:13:31 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id XAA54292; Sat, 20 Feb 1999 23:12:45 GMT (envelope-from dfr@nlsystems.com) Date: Sat, 20 Feb 1999 23:12:45 +0000 (GMT) From: Doug Rabson To: Terry Lambert Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: <199902202252.PAA19845@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 20 Feb 1999, Terry Lambert wrote: > > I always thought that the vnodes were locked that way during lookup to > > avoid more serious problems but I have never done the analysis to figure > > it out. Certainly there are some tricky cases in the way that lookup is > > used to prepare for a subsequent create or rename (but that isn't the > > issue here I think). > > See the rename code. > > > > If it works, then changing lookup to not require locks on both vnodes at > > the same time would be a good thing. One of the reasons that NFS doesn't > > have proper node locks is that a dead NFS server can lead to a hung > > machine though a lock cascade from the NFS mount point. > > The correct way to do this, IMO, is a back-off/retry, which would > unlock the lock and queue the operation for retry, which would > reacquire the lock. > > I swear I saw code in NFS to do this. Maybe it was pre-BSD4.4. I'm pretty sure it has never done this as long as I have been involved with NFS. I remember a (probably private) discussion with Rick Macklem a long time ago where he explained some of the problems with using exclusive node locks in NFS. I'm not sure how a filesystem can unilaterally decide to release an asserted lock. It seems to me that this policy can only happen at the level of the client code (otherwise the value of the lock disappears). > > > > Maybe. The difference is that the I/O topology is not known at the > > > higher levels where the I/O gets queued, so it would be more difficult > > > to calculate what the async limit should be in a scaleable way. > > > > Understood. I played with a few non-solutions, limiting i/o on a mount > > point and on a vnode to an arbitrary limit but wasn't able to make a real > > difference to the responsiveness of the test. > > > > It does seem wrong that a single writer process can generate arbitrary > > amounts of latency (essentially only bounded by the number of available > > buffers) for other clients on the same drive. Ideally the driver should be > > able to propagate its 'queue full' signals up to the bio system but I > > can't see a way of doing that easily in the current code. > > If the queue gets full, then the disk gets busy. In which case, you > could convert to using sync writes for all pending directory operations. This is what happens for NFS (since Shimokawa-san and I rewrote the queueing system in the NFS client a couple of years ago). In the NFS client, the queue lengths are capped at 2*#iod and any i/o after that threshold is synchronous. This was possible since the i/o implementation (rpc) was part of the filesystem. Local filesystems need extra communication channels with the underlying storage provider. > > It should be pretty easy to do this kludge by (1) deciding how many > waiters is "too many", and (2) checking if the mount is async. This > would avoid propagating the changes up. Deciding how many is "too many" is the hard part. It needs feedback from the driver really. > > I really think, though, that the correct fix is to flag the async > writes for directory data in the code, and then when you do the lower > level queue insertion, insert them ahead, per my other posting. > > I personally like the name "EXPEDITE" for the flag. 8-). I think promoting directory writes (and directory reads probably) might be the simplest solution. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:11:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id 4A2C6119D0 for ; Sat, 20 Feb 1999 16:11:24 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA10435; Sat, 20 Feb 1999 17:11:24 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd010421; Sat Feb 20 17:11:23 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA22231; Sat, 20 Feb 1999 17:11:22 -0700 (MST) From: Terry Lambert Message-Id: <199902210011.RAA22231@usr08.primenet.com> Subject: Re: Panic in FFS/4.0 as of yesterday To: dfr@nlsystems.com (Doug Rabson) Date: Sun, 21 Feb 1999 00:11:21 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Doug Rabson" at Feb 20, 99 11:12:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I swear I saw code in NFS to do this. Maybe it was pre-BSD4.4. > > I'm pretty sure it has never done this as long as I have been involved > with NFS. I remember a (probably private) discussion with Rick Macklem a > long time ago where he explained some of the problems with using exclusive > node locks in NFS. I'm not sure how a filesystem can unilaterally decide > to release an asserted lock. It seems to me that this policy can only > happen at the level of the client code (otherwise the value of the lock > disappears). I think you can return ESTALE/EAGAIN from the conflicting assertions. I'm afraid that I might have been referencing the SVR4 NFS code. I'm fuzzy on the date, but I definitely remember the code because I asked myself "Why the heck is it doing this?", and running down the answer. It couldn't have been more than 5 years ago, which puts it right on the line. > > It should be pretty easy to do this kludge by (1) deciding how many > > waiters is "too many", and (2) checking if the mount is async. This > > would avoid propagating the changes up. > > Deciding how many is "too many" is the hard part. It needs feedback from > the driver really. Or knowledge of queue depth at the time it's enqueued. Be kind of strange to call a sync write from the top of the async write queue, but that's where you'd want to do it, if you did it. > > I personally like the name "EXPEDITE" for the flag. 8-). > > I think promoting directory writes (and directory reads probably) might be > the simplest solution. Hum. This is trivial... Let's see... is there a free flag? Yes... OK, here's code to add the ability to expedite placement of async writes. It' doesn't insert them in order behind other expedited writes, so it turns the expedited stuff LIFO. This is probably suboptimal, but can't happen in dependent operations, so what the heck... When you use the code, be sure to *not* set the flag if soft updates are in effect (I think that's a caller issue, not a callee issue, since it would complicate the bdwrite code, probably unacceptably. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. ============================================================================ Index: buf.h =================================================================== RCS file: /cvs/freebsd/src/sys/sys/buf.h,v retrieving revision 1.61 diff -c -r1.61 buf.h *** buf.h 1998/11/13 01:01:44 1.61 --- buf.h 1999/02/21 00:01:24 *************** *** 141,147 **** #define B_DONE 0x00000200 /* I/O completed. */ #define B_EINTR 0x00000400 /* I/O was interrupted */ #define B_ERROR 0x00000800 /* I/O error occurred. */ ! #define B_AVAIL2 0x00001000 /* Available flag */ #define B_INVAL 0x00002000 /* Does not contain valid info. */ #define B_LOCKED 0x00004000 /* Locked in core (not reusable). */ #define B_NOCACHE 0x00008000 /* Do not cache block after use. */ --- 141,147 ---- #define B_DONE 0x00000200 /* I/O completed. */ #define B_EINTR 0x00000400 /* I/O was interrupted */ #define B_ERROR 0x00000800 /* I/O error occurred. */ ! #define B_EXPEDITE 0x00001000 /* Expedite operation */ #define B_INVAL 0x00002000 /* Does not contain valid info. */ #define B_LOCKED 0x00004000 /* Locked in core (not reusable). */ #define B_NOCACHE 0x00008000 /* Do not cache block after use. */ Index: vfs_bio.c =================================================================== RCS file: /cvs/freebsd/src/sys/kern/vfs_bio.c,v retrieving revision 1.193.2.2 diff -c -r1.193.2.2 vfs_bio.c *** vfs_bio.c 1999/01/25 01:59:26 1.193.2.2 --- vfs_bio.c 1999/02/21 00:04:48 *************** *** 793,803 **** if (bp->b_flags & B_LOCKED) { bp->b_flags &= ~B_ERROR; bp->b_qindex = QUEUE_LOCKED; ! TAILQ_INSERT_TAIL(&bufqueues[QUEUE_LOCKED], bp, b_freelist); /* buffers with stale but valid contents */ } else { bp->b_qindex = QUEUE_LRU; ! TAILQ_INSERT_TAIL(&bufqueues[QUEUE_LRU], bp, b_freelist); } if ((bp->b_flags & (B_LOCKED|B_DELWRI)) == 0) { --- 793,809 ---- if (bp->b_flags & B_LOCKED) { bp->b_flags &= ~B_ERROR; bp->b_qindex = QUEUE_LOCKED; ! if (bp->b_flags & B_EXPEDITE) ! TAILQ_INSERT_HEAD(&bufqueues[QUEUE_LOCKED], bp, b_freelist); ! else ! TAILQ_INSERT_TAIL(&bufqueues[QUEUE_LOCKED], bp, b_freelist); /* buffers with stale but valid contents */ } else { bp->b_qindex = QUEUE_LRU; ! if (bp->b_flags & B_EXPEDITE) ! TAILQ_INSERT_HEAD(&bufqueues[QUEUE_LRU], bp, b_freelist); ! else ! TAILQ_INSERT_TAIL(&bufqueues[QUEUE_LRU], bp, b_freelist); } if ((bp->b_flags & (B_LOCKED|B_DELWRI)) == 0) { *************** *** 806,812 **** /* unlock */ bp->b_flags &= ~(B_ORDERED | B_WANTED | B_BUSY | ! B_ASYNC | B_NOCACHE | B_AGE | B_RELBUF); splx(s); } --- 812,818 ---- /* unlock */ bp->b_flags &= ~(B_ORDERED | B_WANTED | B_BUSY | ! B_ASYNC | B_NOCACHE | B_AGE | B_RELBUF | B_EXPEDITE); splx(s); } ============================================================================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:12:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 6D57511A43 for ; Sat, 20 Feb 1999 16:11:56 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA04381; Sun, 21 Feb 1999 10:41:53 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA24243; Sun, 21 Feb 1999 10:41:49 +1030 (CST) Message-ID: <19990221104149.U93492@lemis.com> Date: Sun, 21 Feb 1999 10:41:49 +1030 From: Greg Lehey To: Terry Lambert , Dom Mitchell Cc: desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: UNIX license issues (was: Searching an "old" BSD stdio) References: <199902202205.PAA18466@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199902202205.PAA18466@usr08.primenet.com>; from Terry Lambert on Sat, Feb 20, 1999 at 10:05:38PM +0000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 20 February 1999 at 22:05:38 +0000, Terry Lambert wrote: >> Doesn't Kirk McKusick sell a complete BSD sources set on CDROM? I'd >> check the web page, but it appears to be inaccessible to me at the >> moment. I seem to recall that he required you obtain some kind of a >> license from SCO first, though... > > The settlement agreement between UCB and USL, the terms of which > are not permitted to be disclosed, made the Net and Net/2 > distribution supposedly "illegal". No, it meant that you still required a license. > Since you can't revoke a license granted in perpetuity (which is why > Apple still has a valid license for the UCSD P system that they used > to implement the original "QuickDraw"), DEC has declined to remove > it from their gatekeeper.dec.com archive, as have hundreds of other > licensees (even some institutions with more money than Bill Gates). Having a license doesn't normally mean you can put it on an ftp site for all comers. > Net was BSD 4.2, and Net/2 was BSD 4.3. You're a long way out. 4.3BSD came out in 1986. Net/1 came after 4.3BSD Tahoe, in 1989. Net/2 came after 4.3BSD Reno, in 1991. > I believe Kirk sells the 4.4-Lite2 CDROMs. Walnut Creek sells the 4.4BSD-Lite 2 CD-ROMS. Kirk sells a 4 CD-ROM set titled ``The CSRG archives''. The first CD contains 1BSD, 2BSD, 3BSD and 4BSD up to 4.3BSD. The second CD contains the remaining 4.3BSD flavours and 4.4BSD-Lite 1. The third CD contains 4.4BSD and 4.4BSD Lite 2, and the fourth contains the SCCS files of the /usr/src hierarchy. They leave off just about where the FreeBSD repository starts. > If he sells others, it's only with proof of a Western Electric or > later UNIX source license, to keep himself out of hot water. Correct, you need a source license. The easiest way is to get the SCO license, which will cost you $100. See http://minnie.cs.adfa.oz.au/PUPS/getlicense.html for further details. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:32:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 04D5F11A43 for ; Sat, 20 Feb 1999 16:32:15 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA22279; Sat, 20 Feb 1999 17:32:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd022265; Sat Feb 20 17:32:08 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA22703; Sat, 20 Feb 1999 17:32:07 -0700 (MST) From: Terry Lambert Message-Id: <199902210032.RAA22703@usr08.primenet.com> Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) To: grog@lemis.com (Greg Lehey) Date: Sun, 21 Feb 1999 00:32:07 +0000 (GMT) Cc: tlambert@primenet.com, Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990221104149.U93492@lemis.com> from "Greg Lehey" at Feb 21, 99 10:41:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The settlement agreement between UCB and USL, the terms of which > > are not permitted to be disclosed, made the Net and Net/2 > > distribution supposedly "illegal". > > No, it meant that you still required a license. From AT&T, which meant the the net distribution of the code was illegal, since it didn't meet the criteria for a "select group". Remember that the AT&T claims were Trade Secret claims, not Patent or Copyright claims. > > Since you can't revoke a license granted in perpetuity (which is why > > Apple still has a valid license for the UCSD P system that they used > > to implement the original "QuickDraw"), DEC has declined to remove > > it from their gatekeeper.dec.com archive, as have hundreds of other > > licensees (even some institutions with more money than Bill Gates). > > Having a license doesn't normally mean you can put it on an ftp site > for all comers. DEC disputes the legality of the revocation. So does MIT. MIT has more money and patents than God. If you piss of MIT, you are pretty much screwed on licensing for derivative works of their patents. With the new patent law gone to 20 years from date of filing (supposedly to stop submerged patents, but really to extend their length), you'd have a hard time using any post 1984 technology in a product without MIT's permission, or at least indifference. That was one of the reasons it was so damn annoying when UCB settled instead of taking MIT's public offer of backing. > > Net was BSD 4.2, and Net/2 was BSD 4.3. > > You're a long way out. 4.3BSD came out in 1986. Net/1 came after > 4.3BSD Tahoe, in 1989. Net/2 came after 4.3BSD Reno, in 1991. Sorry; I was relating it to the relative release dates of Ultrix vs. Net/1. My bad. > Kirk sells a 4 CD-ROM > set titled ``The CSRG archives''. The first CD contains 1BSD, 2BSD, > 3BSD and 4BSD up to 4.3BSD. The second CD contains the remaining > 4.3BSD flavours and 4.4BSD-Lite 1. The third CD contains 4.4BSD and > 4.4BSD Lite 2, and the fourth contains the SCCS files of the /usr/src > hierarchy. They leave off just about where the FreeBSD repository > starts. > > > If he sells others, it's only with proof of a Western Electric or > > later UNIX source license, to keep himself out of hot water. > > Correct, you need a source license. The easiest way is to get the SCO > license, which will cost you $100. See > http://minnie.cs.adfa.oz.au/PUPS/getlicense.html for further details. I already have two transferable SVR3 source licenses: one for my Amiga, and one for a Televideo terminal I bought from the local (at the time) University. The equipment serial numbers are on the source licensed machine manifest for the college, and the terminal is a "class B computing device". Actually, there are a heck of a lot of people from that era who also have source licenses for their own stuff, if they got a correct transfer document at sale time. I know of at least two other people. Wes may or may not have been there for "serial number day", when we wnt through all the equipment looking for class A or class B FCC certs and serial numbers all over campus to bloat the number of licenses. Unfortunately, I didn't get an SVR4 license; they changed the way they licensed to "by site" instead of "by machine". Also unfortunately, I don't have media, and I think media costs on SVR3 still exceed $100. 8-(. Does the republished Lyons V7 book count? That could be a cheaper alternative... plus you'd get a book. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:39:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B8CBE10E05 for ; Sat, 20 Feb 1999 16:39:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA00115; Sat, 20 Feb 1999 16:38:45 -0800 Date: Sat, 20 Feb 1999 16:38:45 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Terry Lambert Cc: Greg Lehey , Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) In-Reply-To: <199902210032.RAA22703@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Does the republished Lyons V7 book count? That could be a cheaper > alternative... plus you'd get a book. ;-). > Which is fine, except the fellow just wants libc source- not the kernel source. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:45:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id DBEC310E0B for ; Sat, 20 Feb 1999 16:45:17 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA04581; Sun, 21 Feb 1999 11:15:15 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA24341; Sun, 21 Feb 1999 11:15:14 +1030 (CST) Message-ID: <19990221111514.Z93492@lemis.com> Date: Sun, 21 Feb 1999 11:15:14 +1030 From: Greg Lehey To: mjacob@feral.com, Terry Lambert Cc: Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) References: <199902210032.RAA22703@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matt Jacob on Sat, Feb 20, 1999 at 04:38:45PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 20 February 1999 at 16:38:45 -0800, Matt Jacob wrote: > >> >> Does the republished Lyons V7 book count? That could be a cheaper >> alternative... plus you'd get a book. ;-). >> > > Which is fine, except the fellow just wants libc source- not the kernel > source. Also, Lyons was the Sixth Edition, and the original poster wanted 4.2BSD (I think). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 16:51:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4CD3410E05 for ; Sat, 20 Feb 1999 16:51:49 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id QAA00163; Sat, 20 Feb 1999 16:51:20 -0800 Date: Sat, 20 Feb 1999 16:51:20 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Greg Lehey Cc: Terry Lambert , Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) In-Reply-To: <19990221111514.Z93492@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> > >> Does the republished Lyons V7 book count? That could be a cheaper > >> alternative... plus you'd get a book. ;-). > >> > > > > Which is fine, except the fellow just wants libc source- not the kernel > > source. > > Also, Lyons was the Sixth Edition, and the original poster wanted > 4.2BSD (I think). > he wanted libc stdio source. That'd be v7, yes- not the 'portable I/O library' for PWB... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 17:13:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gras-varg.worldgate.com (gras-varg.worldgate.com [198.161.84.12]) by hub.freebsd.org (Postfix) with ESMTP id 421D710E66 for ; Sat, 20 Feb 1999 17:13:11 -0800 (PST) (envelope-from skafte@gras-varg.worldgate.com) Received: (from skafte@localhost) by gras-varg.worldgate.com (8.9.1a/8.9.1) id SAA07038 for freebsd-hackers@freebsd.org; Sat, 20 Feb 1999 18:13:10 -0700 (MST) Date: Sat, 20 Feb 1999 18:13:10 -0700 From: Greg Skafte To: freebsd-hackers@freebsd.org Subject: intel ether express pro 100's Message-ID: <19990220181309.A6999@gras-varg.worldgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Organization: WorldGate Inc. X-PGP-Fingerprint: 42 9C 2C A8 4D 2B C9 C4 7D B6 00 B0 50 47 20 97 X-URL: http://gras-varg.worldgate.com/~skafte Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG are there any issues or quirks with the new 100+ _management_ adapters they are based on the 82559 instead of the 82558 -- Email: skafte@worldgate.com Voice: +403 413 1910 Fax: +403 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 19:42:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 6553B11A77; Sat, 20 Feb 1999 19:42:46 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id OAA05234; Sun, 21 Feb 1999 14:12:45 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA43836; Sun, 21 Feb 1999 14:12:44 +1030 (CST) Message-ID: <19990221141243.G93492@lemis.com> Date: Sun, 21 Feb 1999 14:12:43 +1030 From: Greg Lehey To: FreeBSD Hackers , FreeBSD-isp@freebsd.org Subject: New breakin technique? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just found the following messages in my logs: Feb 21 10:13:11 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 Feb 21 10:13:14 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 Feb 21 13:41:55 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.82:0; Has anybody seen something like this? It looks as if somebody is trying to break in, but I didn't know that rpc.statd could start xterms. Under these circumstances, it would be interesting to know if rpc.statd *must* run as root. Wouldn't, say, bin be enough? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 21:57:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 035371154E for ; Sat, 20 Feb 1999 21:57:29 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id WAA08086; Sat, 20 Feb 1999 22:27:58 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36CF995E.C1ED0E8E@softweyr.com> Date: Sat, 20 Feb 1999 22:27:58 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Greg Lehey , Dom.Mitchell@palmerharvey.co.uk, desar@club-internet.fr, freebsd-hackers@FreeBSD.ORG Subject: Re: UNIX license issues (was: Searching an "old" BSD stdio) References: <199902210032.RAA22703@usr08.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > Greg Lehey wrote: > > Terry Lambert wrote: > > > > > If he sells others, it's only with proof of a Western Electric or > > > later UNIX source license, to keep himself out of hot water. > > > > Correct, you need a source license. The easiest way is to get the SCO > > license, which will cost you $100. See > > http://minnie.cs.adfa.oz.au/PUPS/getlicense.html for further details. > > I already have two transferable SVR3 source licenses: one for my Amiga, > and one for a Televideo terminal I bought from the local (at the time) > University. The equipment serial numbers are on the source licensed > machine manifest for the college, and the terminal is a "class B > computing device". Actually, there are a heck of a lot of people from > that era who also have source licenses for their own stuff, if they > got a correct transfer document at sale time. I know of at least two > other people. Wes may or may not have been there for "serial number > day", when we wnt through all the equipment looking for class A or > class B FCC certs and serial numbers all over campus to bloat the > number of licenses. Unfortunately, I didn't get an SVR4 license; they > changed the way they licensed to "by site" instead of "by machine". I think Johnnie got my TeleWidget 915 on that list, since it did actually come from WSU. If not, his 925 was certainly on the list, and I've probably got it around here somewhere. He left it with me when he moved to Germany. Come to think of it, his Everex Step system was probably on the list, too, and I've got that laying in pieces in the basement, along with the Sperry PC/IT that was the original Obie. > Also unfortunately, I don't have media, and I think media costs on > SVR3 still exceed $100. 8-(. I've probably still got Johnnie's set in a box downstairs. It took a LOT of 1.2MB 5.25" floppies to store the entire SVR3 source code, you know? > Does the republished Lyons V7 book count? That could be a cheaper > alternative... plus you'd get a book. ;-). I've got a 5th or 6th generation photocopy of the original down there somewhere, along with the Delft SVR4 internals training manuals, and a working port of cfront 1.2 to ISC SVR3/386. Ah, those were the days... Now VAX/VMS source was really hard to get your hands on, but we had that, too. Or, you could just get it the way Kevin Mitnick did - steal it from Rob Clyde. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22: 0:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id 07A1711B9D for ; Sat, 20 Feb 1999 22:00:09 -0800 (PST) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10EQA0-000I1nC; Sat, 20 Feb 1999 23:06:28 -0500 (EST) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: HEADS-UP: FS disaster To: hackers@freebsd.org Date: Sat, 20 Feb 1999 23:06:28 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1763 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have two systems that I cvsuped & updated (kernels only) today. RELENG_2_2 RELENG_3 (running softupdates (/ & /usr) /usr/home mounted via nfsv2 from the RELENG_2_2 system Both systems are losing files/directories. On the Releng_3 system, I kept writing a group of files to a directory and working with them. I would then go do something else, and when I looked for the files they were no longer there. This happened several times. Occasionally, I would do email on the RELENG_2_2 system. A few minutes ago, I fired up Elm again, and it offered to create a 'Mail' directory for me. My entire directory of saved mail has disappeared. It appears that when files or directories are written, they are accessible while in VM but they do NOT always get written to the disk!!! (except when flushed by a re-boot). On my test RELENG_3 system kernel is dated Feb 20 21:54 kernel.old Feb 20 10:20 more than one compile was done after the cvsup I recompiled to turn off softupdates. On my prod. RELENG_2_2-stable system kernel- Feb 20 10:42 kernel.old- Feb 13 00:10 one compile and install only today. I would expect them to be the very close... /usr/home is mounted on the RELENG_3 system via nfsv2. ********I don't do mail from the RELENG_3 system. The only reason I recompiled the production system today, was there was a change from luigi in both trees. I don't remember exactly what it was. It is possible the RELENG_3-stable system did the screwup though as it had access to the RELENG_2_2 /usr via nfs. I hope this info re symptoms helps. Be careful! Tom P.S. I am now running kernel.GENERIC on the RELENG_3 system & kernel.old on the RELENG_2_2 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22: 1:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id DB1C711BA6 for ; Sat, 20 Feb 1999 22:00:11 -0800 (PST) (envelope-from root@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10EQRx-000I21C; Sat, 20 Feb 1999 23:25:01 -0500 (EST) Message-Id: Date: Sat, 20 Feb 1999 23:25:01 -0500 (EST) From: root@tomqnx.com (Tom Torrance at home Root) To: hackers@freebsd.org Subject: HEADS UP: FS Disaster Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am also missing the 'Mail' directory from the RELENG_2_2-stable root partition which is NOT available to the RELENG_3-stable system. There is a very good chance that this is related to luigi's change, which is the only new item that went into the RELENG_2_2-stable kernel recompile today. Extreme appologies in advance if I am wrong, but I would look there first! Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22: 3:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 218AE11C49 for ; Sat, 20 Feb 1999 22:03:21 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id XAA04183 for ; Sat, 20 Feb 1999 23:36:44 -0500 (EST) Date: Sat, 20 Feb 1999 23:36:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: hackers@freebsd.org Subject: Unique timestamp mechanism in kernel? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For auditing support, I require a timestamp mechanism that guarantees a unique monotonically increasing time value expressed as a (second, nanosecond) tuple. Whether or not this serialization of events is a reasonable assumption is, of course, open to debate, but the POSIX spec seems to want it so I'm going along. Is there an existing mechanism to return such a value in the FreeBSD 4.0 kernel already? Monotime increases, but is not unique. nanotime reflects the current time but is not unique. If there isn't a mechanism, I'll just stick one in that fudges the time forwards to prevent a duplicate timestamp, but I'd rather rely on an existing mechanism if there is one. Also, on my cvsup from a few weeks ago, time(9) refers me to gettime(9) which appears not to exist. In the end I pulled what I needed out of kern/kern_clock.c. I can stick together a man page based on that if there isn't already one elsewhere that I am just missing for some reason :-). Thanks, Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22: 5:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shibumi.feralmonkey.org (shibumi.feralmonkey.org [203.41.114.182]) by hub.freebsd.org (Postfix) with ESMTP id D038A11B4A; Sat, 20 Feb 1999 22:05:25 -0800 (PST) (envelope-from nick@feralmonkey.org) Received: from shibumi (shibumi [203.41.114.182]) by shibumi.feralmonkey.org (Postfix) with ESMTP id 15EA5780B; Sat, 21 Feb 1998 17:10:35 +1100 (EST) Date: Sat, 21 Feb 1998 17:10:34 +1100 (EST) From: To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD-isp@freebsd.org Subject: Re: New breakin technique? In-Reply-To: <19990221141243.G93492@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There has been issues with statd on both solaris and linux. It may simply be someone running a mass-scan. Nick On Sun, 21 Feb 1999, Greg Lehey wrote: > I've just found the following messages in my logs: > > Feb 21 10:13:11 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 > Feb 21 10:13:14 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 > Feb 21 13:41:55 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.82:0; > > Has anybody seen something like this? It looks as if somebody is > trying to break in, but I didn't know that rpc.statd could start > xterms. > > Under these circumstances, it would be interesting to know if > rpc.statd *must* run as root. Wouldn't, say, bin be enough? > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22:11:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from omnivax (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 4188A10E60 for ; Sat, 20 Feb 1999 22:10:58 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id XAA12913 for hackers@freebsd.org; Sat, 20 Feb 1999 23:58:04 -0500 From: Bill Paul Message-Id: <199902210458.XAA12913@skynet.ctr.columbia.edu> Subject: How to handle jumbo etherney frames To: hackers@freebsd.org Date: Sat, 20 Feb 1999 23:58:02 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2493 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Recently I obtained the programming info for the Alteon Tigon gigabit ethernet chip (http://www.alteon.com/support/openkits). This is the chip used in the Alteon AceNIC, the 3Com 3c985 and the Netgear GA620 ethernet boards. The Tigon supports jumbo ethernet frames, which are 9014 bytes in size (14 bytes header, 9000 bytes data). The use of jumbo frames is optional, but I'd like to support them. The question is, what's the best mbuf allocation strategy for receiving frames this size? The scheme I normally use is to allocate a single mbuf with MGETHDR and then attach an mbuf cluster to that with MCLGET. An mbuf cluster buffer is 2K, which is enough to hold a complete ethernet frame up to the maximum frame size (1514). The address of the cluster buffer is passed to the ethernet controller, so that it can DMA received packets directly into the mbuf which can then be passed directly to ether_input() without any buffer copying. (And avoiding buffer copying at gigabit speeds is highly desireable.) I would like to use something similar for the jumbo frames, but I'm not entirely sure how to pre-allocate the buffers. I thought about allocating external mbuf storage independent of the cluster buffer pool, but 9K is larger than the page size, so I'd need to use contigmalloc() in order to be sure of getting contiguous pages (the chip will be DMAing into the buffers and it has no knowledge of the kernel's virtual page mappings). Using contigmalloc() can easily fail as memory becomes fragmented however. The alternative is to allocate an mbuf cluster chain, breaking up the packet into 2K chunks. I think this involves one MGETHDR(), four MGET()s and five MCLGETS(). It would be nice to find a quick and dirty way to allocate the chain, but I don't see one offhand. It's very possible that there's a more elegant way to handle this, but I haven't been able to think of any. If anyone has any suggesstions, I'd love to hear them. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 22:15:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (Postfix) with ESMTP id B763310E3B; Sat, 20 Feb 1999 22:15:53 -0800 (PST) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.3/8.9.2/best.sh) id WAA16375; Sat, 20 Feb 1999 22:14:54 -0800 (PST) Message-ID: <19990220221453.B15747@best.com> Date: Sat, 20 Feb 1999 22:14:53 -0800 From: "Jan B. Koum " To: Greg Lehey , FreeBSD Hackers , FreeBSD-isp@FreeBSD.ORG Subject: Re: New breakin technique? References: <19990221141243.G93492@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990221141243.G93492@lemis.com>; from Greg Lehey on Sun, Feb 21, 1999 at 02:12:43PM +1030 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Feb 21, 1999 at 02:12:43PM +1030, Greg Lehey wrote: > I've just found the following messages in my logs: > > Feb 21 10:13:11 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 > Feb 21 10:13:14 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.132:0 > Feb 21 13:41:55 freebie rpc.statd: Invalid hostname to sm_mon: ;/usr/openwin/bin/xterm -display 207.193.26.82:0; > > Has anybody seen something like this? It looks as if somebody is > trying to break in, but I didn't know that rpc.statd could start > xterms. > > Under these circumstances, it would be interesting to know if > rpc.statd *must* run as root. Wouldn't, say, bin be enough? > > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message This should go to -security@ but anyway - they think that freebie is a solaris box. There is remote exploit for rpc.statd for solaris. See: http://www.geek-girl.com/bugtraq/1997_4/0378.html But please don't run rpc.statd if you don't need it in any case? Thanks, :) -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 23: 2:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from eta.ee.fit.edu (eta.ee.fit.edu [163.118.30.136]) by hub.freebsd.org (Postfix) with ESMTP id ED29810E79; Sat, 20 Feb 1999 23:02:36 -0800 (PST) (envelope-from cr@eta.ee.fit.edu) Received: from localhost (cr@localhost) by eta.ee.fit.edu (8.8.7/8.8.7) with SMTP id BAA00895; Sun, 21 Feb 1999 01:47:27 -0500 Date: Sun, 21 Feb 1999 01:47:27 -0500 (EST) From: John Smith To: freebsd-hackers@freebsd.org Cc: freebsd-net@freebsd.org Subject: Packet generation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello; Can anyone help me find a packet generator that will compile on FreeBSD? I've tried spak, libnet, and spoofit.h; and spak does not compile under freebsd, libnet can't really do what I want; and spoofit.h is only of sending tcp and udp stuff; also for linux. (btw; spak does not really work under linux too) I would like to be able to send all kind of packets, and it must be native freebsd code. Any ideas/help appreciated. -John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Feb 20 23:37:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id DDA9D10E5A for ; Sat, 20 Feb 1999 23:37:44 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id BAA21850 for hackers@freebsd.org; Sun, 21 Feb 1999 01:37:43 -0600 (CST) From: Kevin Day Message-Id: <199902210737.BAA21850@home.dragondata.com> Subject: ESTALE the best approach? To: hackers@freebsd.org Date: Sun, 21 Feb 1999 01:37:42 -0600 (CST) 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Forgetting standards and past practices, is ESTALE a good approach to dealing with an NFS outage/reboot/whatever? Very few programs know how to deal with ESTALE, and I really have yet to see one that knows how to recover from it. I've come up to a machine with a load average of 20+, with lots of processes spinning, doing something like: 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000379 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000036 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000378 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000038 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000781 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000044 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000363 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000035 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000383 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000039 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000432 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000034 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000510 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000029 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.001082 RET read -1 errno 70 Stale NFS file handle 28591 eggdrop 0.000037 CALL read(0x6,0xd6800,0x400) 28591 eggdrop 0.000381 RET read -1 errno 70 Stale NFS file handle Because they not realize that ESTALE is a fatal condition, or lots of programs tend to just go bezerk at having a FD closed on them... I've been experimenting here with making any ESTALE return something other than ESTALE, to see what happens. EBADF was nearly as bad, as most programs that couldn't deal with ESTALE probably didn't expect a fd that they had already opened to be suddenly closed. EINVAL seemed to make most programs die on their own, but not all. Some also left some very cryptic/wrong diagnostics behind. ENOSPC stopped programs that were stuck in write() mostly, but obviously not if they were read()'ing like above. EIO was probably the best of the bunch, for just getting the program to stop freaking out, but even then, some programs didn't check for it. My next step is going to be to make nfsrv_fhtovp(?) actually kill the process instead of returning anything, in a final attempt to fix this, locally. Is there some justification for treating ESTALE like a transient error anyway? Did some implementation somewhere eventually restore things? Anyone have any comments on this? I've found that at least these programs cannot deal with ESTALE in some manner: cron apache httpd eggdrop afio bnc ircii bitchx Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message