From owner-freebsd-current Sun Aug 10 00:14:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA07487 for current-outgoing; Sun, 10 Aug 1997 00:14:49 -0700 (PDT) Received: from MindBender.serv.net (root@mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA07481 for ; Sun, 10 Aug 1997 00:14:45 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id AAA04251; Sun, 10 Aug 1997 00:14:30 -0700 (PDT) Message-Id: <199708100714.AAA04251@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Peter Mutsaers cc: freebsd-current@freebsd.org Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) In-reply-to: Your message of 09 Aug 97 00:54:13 +0200. <877mdw2smi.fsf@plm.xs4all.nl> Date: Sun, 10 Aug 1997 00:14:29 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>> On Thu, 7 Aug 1997 23:27:18 -0500 (EST), "John S. Dyson" >>> said: > JSD> This is the result of my "slow" recent, but not the latest, greatest > JSD> IDE drive (WD 4GB drive.): > JSD> dd if=/dev/rwd1 of=/dev/null count=1600 bs=64k > JSD> 104857600 bytes transferred in 10.881267 secs (9636525 bytes/sec) >Hmm, my NCR815 does: >~> dd if=/dev/rsd2 of=/dev/null count=1600 bs=64k >104857600 bytes transferred in 15.215823 secs (6891352 bytes/sec) >This is a seagate ST15150N. >But for Wide and/or Ultra SCSI you can expect better values. > >More interesting is: > >~> dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k&;dd if=/dev/rsd0 of=/dev/nul l count=1600 bs=64k& >i.e. start two of them at the same time. >I get as result: >104857600 bytes transferred in 41.430049 secs (2530955 bytes/sec) >104857600 bytes transferred in 41.437855 secs (2530478 bytes/sec) What would be much more interesting to me is if you would do this on a four-drive ccd stripe-set, both with Ultra-Wide SCSI and "UltraIDE". It would be interesting to have a process running non-stop, measuring the amount of left-over CPU, at the same time. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sun Aug 10 00:39:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA08306 for current-outgoing; Sun, 10 Aug 1997 00:39:53 -0700 (PDT) Received: from smtp2.xs4all.nl (smtp2.xs4all.nl [194.109.6.52]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA08301 for ; Sun, 10 Aug 1997 00:39:49 -0700 (PDT) Received: from asterix.xs4all.nl (root@asterix.xs4all.nl [194.109.6.11]) by smtp2.xs4all.nl (8.8.6/XS4ALL) with ESMTP id JAA20914; Sun, 10 Aug 1997 09:39:46 +0200 (CEST) Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.8.6/8.8.6) with UUCP id JAA19135; Sun, 10 Aug 1997 09:38:57 +0200 (MET DST) Received: (from plm@localhost) by plm.xs4all.nl (8.8.6/8.7.3) id JAA27620; Sun, 10 Aug 1997 09:34:39 +0200 (MET DST) Date: Sun, 10 Aug 1997 09:34:39 +0200 (MET DST) Message-Id: <199708100734.JAA27620@plm.xs4all.nl> From: Peter Mutsaers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michael L. VanLoon -- HeadCandy.com" Cc: Peter Mutsaers , freebsd-current@freebsd.org Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) In-Reply-To: <199708100714.AAA04251@MindBender.serv.net> References: <877mdw2smi.fsf@plm.xs4all.nl> <199708100714.AAA04251@MindBender.serv.net> X-Mailer: VM 6.31 under Emacs 19.34.1 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> On Sun, 10 Aug 1997 00:14:29 -0700, "Michael L. VanLoon -- >> HeadCandy.com" said: >> More interesting is: >> >> ~> dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k&;dd if=/dev/rsd0 of=/dev/nul "LV> l count=1600 bs=64k& >> i.e. start two of them at the same time. >> I get as result: >> 104857600 bytes transferred in 41.430049 secs (2530955 bytes/sec) >> 104857600 bytes transferred in 41.437855 secs (2530478 bytes/sec) "LV> What would be much more interesting to me is if you would do this on a "LV> four-drive ccd stripe-set, both with Ultra-Wide SCSI and "UltraIDE". "LV> It would be interesting to have a process running non-stop, measuring "LV> the amount of left-over CPU, at the same time. If only I had that hardware... -- /\_/\ ( o.o ) Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know ) ^ ( plm@xs4all.nl | the Netherlands | what I'm doing. From owner-freebsd-current Sun Aug 10 00:59:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA08874 for current-outgoing; Sun, 10 Aug 1997 00:59:06 -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 AAA08869 for ; Sun, 10 Aug 1997 00:59:03 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id CAA01850; Sun, 10 Aug 1997 02:58:47 -0500 (EST) From: "John S. Dyson" Message-Id: <199708100758.CAA01850@dyson.iquest.net> Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) In-Reply-To: <199708100714.AAA04251@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at "Aug 10, 97 00:14:29 am" To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Sun, 10 Aug 1997 02:58:47 -0500 (EST) Cc: plm@xs4all.nl, freebsd-current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > l count=1600 bs=64k& > >i.e. start two of them at the same time. > >I get as result: > >104857600 bytes transferred in 41.430049 secs (2530955 bytes/sec) > >104857600 bytes transferred in 41.437855 secs (2530478 bytes/sec) > > What would be much more interesting to me is if you would do this on a > four-drive ccd stripe-set, both with Ultra-Wide SCSI and "UltraIDE". > It would be interesting to have a process running non-stop, measuring > the amount of left-over CPU, at the same time. > That *would* be interesting. Here are the results for running 2 and 3 concurrent tests -- my GUESS it is likely that the drive is fairly slow because of the small (read ahead) cache on it -- this is on the same drive: 1600+0 records in 1600+0 records out 104857600 bytes transferred in 68.005133 secs (1541907 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 68.032161 secs (1541295 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 90.446126 secs (1159338 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 96.159300 secs (1090457 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 96.263071 secs (1089282 bytes/sec) John From owner-freebsd-current Sun Aug 10 01:07:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA09253 for current-outgoing; Sun, 10 Aug 1997 01:07:58 -0700 (PDT) Received: from MindBender.serv.net (root@mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09246; Sun, 10 Aug 1997 01:07:52 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id BAA04711; Sun, 10 Aug 1997 01:07:42 -0700 (PDT) Message-Id: <199708100807.BAA04711@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: dyson@freebsd.org cc: plm@xs4all.nl, freebsd-current@freebsd.org Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) In-reply-to: Your message of Sun, 10 Aug 97 02:58:47 -0500. <199708100758.CAA01850@dyson.iquest.net> Date: Sun, 10 Aug 1997 01:07:42 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> l count=1600 bs=64k& >> >i.e. start two of them at the same time. >> >I get as result: >> >104857600 bytes transferred in 41.430049 secs (2530955 bytes/sec) >> >104857600 bytes transferred in 41.437855 secs (2530478 bytes/sec) >> What would be much more interesting to me is if you would do this on a >> four-drive ccd stripe-set, both with Ultra-Wide SCSI and "UltraIDE". >> It would be interesting to have a process running non-stop, measuring >> the amount of left-over CPU, at the same time. >That *would* be interesting. Here are the results for running 2 and 3 >concurrent tests -- my GUESS it is likely that the drive is fairly slow >because of the small (read ahead) cache on it -- this is on the same >drive: > >1600+0 records in >1600+0 records out >104857600 bytes transferred in 68.005133 secs (1541907 bytes/sec) >1600+0 records in >1600+0 records out >104857600 bytes transferred in 68.032161 secs (1541295 bytes/sec) > >1600+0 records in >1600+0 records out >104857600 bytes transferred in 90.446126 secs (1159338 bytes/sec) >1600+0 records in >1600+0 records out >104857600 bytes transferred in 96.159300 secs (1090457 bytes/sec) >1600+0 records in >1600+0 records out >104857600 bytes transferred in 96.263071 secs (1089282 bytes/sec) Just for statistical fodder... This is on NetBSD, basically 1.2.1, using an Adaptec 2940UW, with tagged-command-queuing enabled. Four 1GB SCSI (not wide or ultra) drives, two of which are "ancient" technology (Seagate ST31200Ns), and two fairly decent (HP3323s), striped with a large ccd: [root@MindBender]~# dd if=/dev/rccd0f of=/dev/null count=1600 bs=64k 1600+0 records in 1600+0 records out 104857600 bytes transferred in 13 secs (8065969 bytes/sec) The machine is an Asus P55TP4N (Triton-1) motherboard, Cyrix 6x86 P166+ (the M1, not the M2), with 64MB EDO RAM. Once again, this doesn't tell us how much CPU was left over during the test, unfortunately... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-current Sun Aug 10 01:17:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA09810 for current-outgoing; Sun, 10 Aug 1997 01:17:28 -0700 (PDT) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09805 for ; Sun, 10 Aug 1997 01:17:12 -0700 (PDT) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id DAA13456; Sun, 10 Aug 1997 03:16:29 -0500 (CDT) Received: from sjx-ca28-29.ix.netcom.com(204.31.235.125) by dfw-ix15.ix.netcom.com via smap (V1.3) id sma013453; Sun Aug 10 03:16:21 1997 Received: (from asami@localhost) by blimp.mimi.com (8.8.6/8.6.9) id BAA17812; Sun, 10 Aug 1997 01:16:18 -0700 (PDT) Date: Sun, 10 Aug 1997 01:16:18 -0700 (PDT) Message-Id: <199708100816.BAA17812@blimp.mimi.com> To: ccsanady@friley01.res.iastate.edu CC: freebsd-current@freebsd.org In-reply-to: <199708092327.SAA01039@friley01.res.iastate.edu> (message from Chris Csanady on Sat, 9 Aug 1997 18:27:13 -0500 (CDT)) Subject: Re: exmh and current.. anyone? From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * How do you work around the stupid tcl8 problem? Install tcl76 and tk42 from the ports collection. If you want to free up the disk space used up by tcl8, delete all the files, and define NOTCL in /etc/make.conf so it won't be built next time you build the world. * That aside, I'd like to point out just how disgusted I am with the * people who are responsibe for the tcl/tk versioning mess.. To the same people who are largely responsible for bringing this operating system to you? :) Satoshi From owner-freebsd-current Sun Aug 10 02:34:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA13239 for current-outgoing; Sun, 10 Aug 1997 02:34:46 -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 CAA13233; Sun, 10 Aug 1997 02:34:42 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id CAA07329; Sun, 10 Aug 1997 02:32:55 -0700 (PDT) To: "Michael L. VanLoon -- HeadCandy.com" cc: dyson@FreeBSD.ORG, plm@xs4all.nl, freebsd-current@FreeBSD.ORG Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) In-reply-to: Your message of "Sun, 10 Aug 1997 01:07:42 PDT." <199708100807.BAA04711@MindBender.serv.net> Date: Sun, 10 Aug 1997 02:32:53 -0700 Message-ID: <7325.871205573@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Once again, this doesn't tell us how much CPU was left over during the > test, unfortunately... This suggests that what we really need is some sort of "strip chart recorder" interface to kernel statistics-gathering so that inter-relationship questions such as this one might be more easily answered. ;-) "Hmmmmmmmm." Jordan From owner-freebsd-current Sun Aug 10 03:07:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA14487 for current-outgoing; Sun, 10 Aug 1997 03:07:55 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA14470; Sun, 10 Aug 1997 03:07:45 -0700 (PDT) Received: from rv by groa.uct.ac.za with local (Exim 1.653 #1) id 0wxUu1-0005X3-00; Sun, 10 Aug 1997 12:07:13 +0200 Subject: Re: scsi time-out & lockup under smp To: jwd@unx.sas.com Date: Sun, 10 Aug 1997 12:07:12 +0200 (SAT) Cc: freebsd-current@freebsd.org, freebsd-smp@freebsd.org In-Reply-To: <199708091618.KAA06802@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 9, 97 10:18:00 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-Id: From: Russell Vincent Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Has anyone tried undefining PEND_INTS to fix this yet? Steve has gone off to sleep, so I thought I would get people caught up on the status of this. Last night I ran a machine with the latest kernel (the one with Steve's latest '3 locks' fix) and PEND_INTS undefined. The machine stayed up for 10 hours while doing its usual work of web cache and newsfeeds along with a make world. That seems to have fixed the problem. I have now defined PEND_INTS again and am running more tests. Nothing definite yet, but after a good hammering (_lots_ of CPU and disk activity) the machine is still running fine. I will know more within the next 12 hours, but it looks like the '3 locks' fix has solved the problem. Many thanks to Steve for helping out. -Russell From owner-freebsd-current Sun Aug 10 03:07:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA14501 for current-outgoing; Sun, 10 Aug 1997 03:07:59 -0700 (PDT) Received: from smtp.algonet.se (angel.algonet.se [194.213.74.112]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA14476 for ; Sun, 10 Aug 1997 03:07:49 -0700 (PDT) Received: (qmail 15589 invoked from network); 10 Aug 1997 08:36:28 -0000 Received: from kairos.algonet.se (HELO kairos) (mal@194.213.74.18) by angel.algonet.se with SMTP; 10 Aug 1997 08:36:28 -0000 Received: (mal@localhost) by kairos (SMI-8.6/8.6.12) id KAA03820; Sun, 10 Aug 1997 10:39:03 +0200 Date: Sun, 10 Aug 1997 10:39:03 +0200 Message-Id: <199708100839.KAA03820@kairos> From: Mats Lofkvist To: current@FreeBSD.ORG In-reply-to: <199708100651.XAA05892@hub.freebsd.org> (owner-current-digest@FreeBSD.ORG) Subject: Re: IDE vs SCSI was: flags 80ff works (like anybody doubted it) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The dd test on a 486/100 32MB with an old bt445s scsi controller and a quantum capella 2GB disk running FreeBSD 2.2.2R: bash# dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k 1600+0 records in 1600+0 records out 104857600 bytes transferred in 17.838889 secs (5878034 bytes/sec) bash# dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k & dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k [1] 297 1600+0 records in 1600+0 records out 104857600 bytes transferred in 32.622429 secs (3214279 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 32.574877 secs (3218971 bytes/sec) bash# dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k & sleep 1; dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k [1] 572 1600+0 records in 1600+0 records out 104857600 bytes transferred in 37.597098 secs (2788981 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 37.592102 secs (2789352 bytes/sec) bash# dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k & sleep 2; dd if=/dev/rsd0 of=/dev/null count=1600 bs=64k [1] 321 1600+0 records in 1600+0 records out 104857600 bytes transferred in 36.997771 secs (2834160 bytes/sec) 1600+0 records in 1600+0 records out 104857600 bytes transferred in 36.876216 secs (2843502 bytes/sec) (There was very audible searching on the disk going on when running the last two. Didn't seem to affect performance very much though.) This is not exactly high end hardware, still it performs quite good. _ Mats Lofkvist mal@algonet.se From owner-freebsd-current Sun Aug 10 03:27:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA15199 for current-outgoing; Sun, 10 Aug 1997 03:27:06 -0700 (PDT) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA15193 for ; Sun, 10 Aug 1997 03:26:58 -0700 (PDT) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id OAA28294; Sun, 10 Aug 1997 14:24:10 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.7/8.8.5) with ESMTP id OAA00695; Sun, 10 Aug 1997 14:03:41 +0400 (MSD) Message-Id: <199708101003.OAA00695@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Chris Csanady cc: freebsd-current@FreeBSD.ORG Subject: Re: exmh and current.. anyone? In-reply-to: Your message of "Sat, 09 Aug 1997 18:27:13 CDT." <199708092327.SAA01039@friley01.res.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 14:03:39 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How do you work around the stupid tcl8 problem? I got /usr/libdata/tcl/init.tcl from 2.2-stable and put it in /usr/local/lib/tcl7.5/. Not very nice, but simple. Dima From owner-freebsd-current Sun Aug 10 03:27:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA15235 for current-outgoing; Sun, 10 Aug 1997 03:27:39 -0700 (PDT) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA15228 for ; Sun, 10 Aug 1997 03:27:30 -0700 (PDT) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id OAA28295; Sun, 10 Aug 1997 14:24:11 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.7/8.8.5) with ESMTP id OAA00728; Sun, 10 Aug 1997 14:25:17 +0400 (MSD) Message-Id: <199708101025.OAA00728@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Jordan K. Hubbard" cc: Chris Csanady , freebsd-current@FreeBSD.ORG Subject: Re: exmh and current.. anyone? In-reply-to: Your message of "Sat, 09 Aug 1997 17:53:41 PDT." <6234.871174421@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 14:25:16 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > That aside, I'd like to point out just how disgusted I am with the > > people who are responsibe for the tcl/tk versioning mess.. > > > > Bad, bad, bad! > > I'm also pretty disgusted by somebody trying to fan the flames > of all this just 3 days after the acrimony has died down and > things are sort of back to normal. Chris? Shut up. There is a real problem here! Upgrade of the base system should not break 3rd party binaries! There is shared libraries verion numbers for it. But libtcl75.so.1.1 become broken by overwriting /usr/libdata/tcl. Perhaps, TCL 8.0 should use /usr/libdata/tcl80 instead. Dima From owner-freebsd-current Sun Aug 10 04:34:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA17332 for current-outgoing; Sun, 10 Aug 1997 04:34:04 -0700 (PDT) Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA17327 for ; Sun, 10 Aug 1997 04:34:01 -0700 (PDT) Received: from itfs.UUCP (root@localhost) by gw.itfs.nsk.su (8.6.12/8.6.12) with UUCP id SAA08355 for current@freebsd.org; Sun, 10 Aug 1997 18:33:58 +0700 Received: by itfs.nsk.su; Sun, 10 Aug 97 18:32:53 +0700 (NST) Received: (from daemon@localhost) by news.itfs.nsk.su (8.7.5/8.6.12) id SAA24104; Sun, 10 Aug 1997 18:30:42 +0700 (NSD) From: nnd@itfs.nsk.su To: current@freebsd.org Subject: Make and SMP - what can be done ? Date: 10 Aug 1997 11:30:41 GMT Message-ID: <5sk8p1$ld3@news.itfs.nsk.su> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Now when we can use SMP-FreeBSD and there is a possibility to speedup building various components of the system (making the kernel with 'make -j12' proves this very definitely) there is a question - HOW can we use it ? Trivial attempt to 'make buildworld' with "MAKE=make -j12" falls very quickly and shows at least that usual idiom - 'make all install clean cleandepend' can not be combined with '-j' flag because this flag breaks "compatible" semantics of sequential building of listed targets. One of possible solutions to this problem can be changing such idioms to 'make all;make install;make clean cleandepend', but it can slowdown building process due to more overhead of several make invocations instead of one make with many targets ;-( Another approach can be in supplaying additional dependencies (f.e. install depends of all and clean depends of install) or ".ORDER" targets with the same effect. Main problem with such an approach is that it can't be done "incrementally" - before I can make buildworld with "MAKE=make -j12" I must change ALL the Makefiles in the "world" ;-). More stepwise process may consists in adding global make flag (say, JFLAG which is set to "-j12" for SMP case and to "" for traditional systems) and using it in various parts of word-building alongside with modifying appropriate Makefiles. Is there any sense in my speculations ? Does anybody have some propositions for solving this problem ? And is there REAL problem at all ;-) ? N.Dudorov From owner-freebsd-current Sun Aug 10 09:59:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29542 for current-outgoing; Sun, 10 Aug 1997 09:59:32 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29537 for ; Sun, 10 Aug 1997 09:59:27 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id MAA15695; Sun, 10 Aug 1997 12:59:23 -0400 (EDT) Date: Sun, 10 Aug 1997 12:59:23 -0400 (EDT) From: Garrett Wollman Message-Id: <199708101659.MAA15695@khavrinen.lcs.mit.edu> To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: cvs commit: src/etc aliases In-Reply-To: <1521.871203688@critter.dk.tfs.com> References: <97Aug10.014925pdt.177512@crevenia.parc.xerox.com> <1521.871203688@critter.dk.tfs.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > Either they are there pointing to something, or they should be taken out > lock stock or barrel. Comments will not do anyone any good... Sure they will.... they will remind the administrator, when setting up the system, that there ought to be such entries and they should be pointed somewhere useful. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Sun Aug 10 10:43:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02220 for current-outgoing; Sun, 10 Aug 1997 10:43:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02214 for ; Sun, 10 Aug 1997 10:43:43 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA11578; Sun, 10 Aug 1997 11:43:37 -0600 (MDT) Message-Id: <199708101743.LAA11578@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: nnd@itfs.nsk.su cc: current@FreeBSD.ORG Subject: Re: Make and SMP - what can be done ? In-reply-to: Your message of "10 Aug 1997 11:30:41 GMT." <5sk8p1$ld3@news.itfs.nsk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 11:43:37 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Now when we can use SMP-FreeBSD and there is > a possibility to speedup building various components of > the system (making the kernel with 'make -j12' proves this > very definitely) there is a question - HOW can we use it ? You've touched on a topic dear to my heart! I took a stab at this once and gave up for lack of knowledge of the .mk system and its subltlies. There is a BIG win to be had here, my experiments suggest "make world" could be cut by around 25% if the -j option were added properly, maybe more. --- > More stepwise process may consists in adding global > make flag (say, JFLAG which is set to "-j12" for SMP case > and to "" for traditional systems) and using it in various > parts of word-building alongside with modifying appropriate > Makefiles. I added JMAKEFLAGS= -j12 to /etc/make.conf, then added JMAKEFLAGS to some of the lower level Makefiles, like the ones for libraries. This worked nicely. I found other Makefiles that just needed a little more work on the dependancies, they sometimes need to be more explicit in a parallel world. Things with YACC & LEX passes die horribly. for non SMP kernels the -j option still is a big win. It filters out the time spent spinning while waiting for disk IO, try -j4 when building a kernel on a UP system. --- > Is there any sense in my speculations ? > Does anybody have some propositions for solving this problem ? > And is there REAL problem at all ;-) ? Bottom line is that this is something that REALLY needs doing. You seem to have a good handle on the concept, go for it!!! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Sun Aug 10 10:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02848 for current-outgoing; Sun, 10 Aug 1997 10:54:07 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02843 for ; Sun, 10 Aug 1997 10:54:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA11619 for ; Sun, 10 Aug 1997 11:54:04 -0600 (MDT) Message-Id: <199708101754.LAA11619@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: current@FreeBSD.ORG Subject: Re: Trap 9 When Boot SMP In-reply-to: Your message of "Sat, 09 Aug 1997 16:23:28 CDT." <199708092123.QAA14184@zuhause.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 11:54:04 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Thomas found a 'fix', although we don't understand WHY the problem exists. It appears that %es is getting corrupted somewhere during boot. The 'solution' was: > The es value IS the culprit. > > Havn't found where it is being mangled, I suspect the > doreti code. > > I nailed es to ds at the top of smp_idleloop in init_smp.c. > asm("pushl %ds; popl %es"); --- This corruption of %es is very repeatable, with a value of 0x27 appearing: changing root device to sd2 APIC_IO: routing 8254 via 8259 pn pin 0 Fatal trap 9: general protection fault while in kernel mode cpuid = 0 instruction pointer = 0x8:0xf0216e22 stack pointer = 0x10:0xf42baea4 frame pointer = 0x10:0xf42bbaef8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6 (cpuidle1) interrupt mask kernel: type 9 trap, code = 0 CPU0 stopping CPUs: 0x00000002 stopped Stopped at _sccnputc+0x22: repe movsl (%esi),%es(%edi) db> trace _sccnputc(cff,53,5,f42baf24,f011fab7) at sccnputc+0x22 _cnputc(53,0,0,53,f42baf70) at _cnputc+0x42 _putchar(53,f42baf94) at _putchar+0x97 _kvprintf(f010d931,f011fa20,f42baf94,a,f42bafa8) at _kvprintf+065 _printf(f010d30,0,f010dadc,f02d2ff4,f01cd307) at _printf+0x3d _smp_idleloop(0) at smp_idleloop+0x24 _fork_trampoline(0,0,f066a200,f42b9000) at _fork_trampoline+0x13 --- anyone have any theories about this one? This is the only reported system having this problem, and I have no clues as to why... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Sun Aug 10 12:32:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09094 for current-outgoing; Sun, 10 Aug 1997 12:32:31 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09089 for ; Sun, 10 Aug 1997 12:32:28 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id PAA00657; Sun, 10 Aug 1997 15:32:27 -0400 (EDT) Date: Sun, 10 Aug 1997 15:32:27 -0400 (EDT) From: Garrett Wollman Message-Id: <199708101932.PAA00657@khavrinen.lcs.mit.edu> To: current@freebsd.org Subject: FYI -- sockaddr-in-mbuf changes Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk FYI, I am now running a kernel which has in it changes similar to those in the WOLLMAN_MBUF branch in the repository. It took a couple of minor changes to get it to work, and while I was at it I also got rid of the last MT_PCB mbufs in the standard kernel. If my machine doesn't crash mysteriously from this by the end of the week, I will be committing these changes. Hopefully by that time I will have performed the analogous work for the other supported protocol stacks as well. It's been a long couple of months... -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-current Sun Aug 10 13:27:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12564 for current-outgoing; Sun, 10 Aug 1997 13:27: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 NAA12555 for ; Sun, 10 Aug 1997 13:27:05 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11257; Sun, 10 Aug 1997 13:23:14 -0700 From: Terry Lambert Message-Id: <199708102023.NAA11257@phaeton.artisoft.com> Subject: Re: cvs commit: src/etc aliases To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Sun, 10 Aug 1997 13:23:14 -0700 (MST) Cc: phk@critter.dk.tfs.com, current@FreeBSD.ORG In-Reply-To: <199708101659.MAA15695@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Aug 10, 97 12:59:23 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Either they are there pointing to something, or they should be taken out > > lock stock or barrel. Comments will not do anyone any good... > > Sure they will.... they will remind the administrator, when setting up > the system, that there ought to be such entries and they should be > pointed somewhere useful. I think by default they should be pointed to root, to make them annoying if left unconfigured. I *don't* think they should be taken out. They are mandated by RFC. 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-current Sun Aug 10 16:12:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA22315 for current-outgoing; Sun, 10 Aug 1997 16:12:53 -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 QAA22307 for ; Sun, 10 Aug 1997 16:12:50 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53213(5)>; Sun, 10 Aug 1997 16:12:13 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177512>; Sun, 10 Aug 1997 16:12:03 -0700 To: Terry Lambert cc: current@freebsd.org Subject: Re: cvs commit: src/etc aliases In-reply-to: Your message of "Sun, 10 Aug 97 13:23:14 PDT." <199708102023.NAA11257@phaeton.artisoft.com> Date: Sun, 10 Aug 1997 16:11:56 PDT From: Bill Fenner Message-Id: <97Aug10.161203pdt.177512@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: >I *don't* think they should be taken out. They are mandated by RFC. I don't think they should be taken out either, but they are not mandated. 1. RFC2142 is Elective, not even Recommended and certainly not Required (see RFC2200). Elective means basically "if you are going to do something like this, you must do exactly this." 2. RFC2142 itself doesn't claim to apply to all hosts: The purpose of this memo is to aggregate and specify the basic set of mailbox names which organizations need to support. Most organizations do not need to support the full set of mailbox names defined here, since not every organization will implement the all of the associated services. However, if a given service is offerred, then the associated mailbox name(es) must be supported, resulting in delivery to a recipient appropriate for the referenced service or role. I could go either way on the commented / uncommentedness of the aliases in the default file, but I think it should go all one way or all the other. I disagree with the "it gives more ways for spammers to send to known userids" argument if they're all aliased to "root" -- "root" is already a well known userid. Bill From owner-freebsd-current Sun Aug 10 16:50:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24377 for current-outgoing; Sun, 10 Aug 1997 16:50:27 -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 QAA24371 for ; Sun, 10 Aug 1997 16:50:25 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA23462; Sun, 10 Aug 1997 16:42:39 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd023458; Sun Aug 10 23:42:30 1997 Date: Sun, 10 Aug 1997 16:40:14 -0700 (PDT) From: Julian Elischer To: Garrett Wollman cc: current@FreeBSD.ORG Subject: Re: FYI -- sockaddr-in-mbuf changes In-Reply-To: <199708101932.PAA00657@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk are you going to update your branch? :) On Sun, 10 Aug 1997, Garrett Wollman wrote: > FYI, I am now running a kernel which has in it changes similar to > those in the WOLLMAN_MBUF branch in the repository. It took a couple > of minor changes to get it to work, and while I was at it I also got [...] julian From owner-freebsd-current Sun Aug 10 18:42:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA00166 for current-outgoing; Sun, 10 Aug 1997 18:42:20 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA00105 for ; Sun, 10 Aug 1997 18:42:12 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id SAA12999; Sun, 10 Aug 1997 18:40:24 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199708110140.SAA12999@GndRsh.aac.dev.com> Subject: Re: cvs commit: src/etc aliases In-Reply-To: <97Aug10.161203pdt.177512@crevenia.parc.xerox.com> from Bill Fenner at "Aug 10, 97 04:11:56 pm" To: fenner@parc.xerox.com (Bill Fenner) Date: Sun, 10 Aug 1997 18:40:24 -0700 (PDT) Cc: terry@lambert.org, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Terry Lambert wrote: > >I *don't* think they should be taken out. They are mandated by RFC. > > I don't think they should be taken out either, but they are not mandated. > > 1. RFC2142 is Elective, not even Recommended and certainly not Required > (see RFC2200). Elective means basically "if you are going to do > something like this, you must do exactly this." > > 2. RFC2142 itself doesn't claim to apply to all hosts: > A point that most folks seem to be ignoring :-(, and the point that is very important to me. > The purpose of this memo is to aggregate and specify the basic set of > mailbox names which organizations need to support. Most > organizations do not need to support the full set of mailbox names > defined here, since not every organization will implement the all of > the associated services. However, if a given service is offerred, > then the associated mailbox name(es) must be supported, resulting in > delivery to a recipient appropriate for the referenced service or > role. Now please, go back and read that paragraph again everyone, make sure you fully and completely understand that it only mandates that if you offer the service you have to have the mailbox, and then later in the RFC you'll see that these are only required at the organizational in most cases. > > I could go either way on the commented / uncommentedness of the aliases > in the default file, but I think it should go all one way or all the > other. I'm defanitly of the opinion they should be commented, sans MAILER-DAEMON and postmaster, as they are required if sendmail is running, and the alias file only does anything if sendmail is running. Oh, and the pseudo users should be enabled as well. The additional ones from RFC2142 should be comments if they are there at all. > > I disagree with the "it gives more ways for spammers to send to known > userids" argument if they're all aliased to "root" -- "root" is already > a well known userid. But ``root'' is one almost every spammer in the world filters out as they KNOW that root is the one who is going to come hunting them down and/or filter them in major ways. Let's see.. joe mail bomb man wants to get to every host on the internet's webmaster... ftp rs.internic.net/domain/*.gz, crunch that through a bit of scripting, tag on webmaster@ and BOOOMMM.... I don't think the author of the RFC would have put it in the security section of the RFC if there was no concern about it. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-current Sun Aug 10 20:16:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA05001 for current-outgoing; Sun, 10 Aug 1997 20:16:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04974; Sun, 10 Aug 1997 20:16:39 -0700 (PDT) From: Sean Eric Fagan Received: (from sef@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id UAA14486; Sun, 10 Aug 1997 20:15:52 -0700 (PDT) Date: Sun, 10 Aug 1997 20:15:52 -0700 (PDT) Message-Id: <199708110315.UAA14486@freefall.freebsd.org> To: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: procfs patch Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following patch should fix the problem with procfs. These patches are to -current (well, a version I just checked out about an hour ago). I have 2.2-GAMMA diffs as well. Index: miscfs/procfs/procfs.h =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs.h,v retrieving revision 1.15 diff -u -r1.15 procfs.h --- procfs.h 1997/02/22 09:40:26 1.15 +++ procfs.h 1997/08/11 01:42:06 @@ -85,6 +85,18 @@ (bcmp((s), (cnp)->cn_nameptr, (len)) == 0)) #define KMEM_GROUP 2 + +/* + * Check to see whether access to target process is allowed + * Evaluates to 1 if access is allowed. + */ +#define CHECKIO(p1, p2) \ + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ + ((p2)->p_flag & P_SUGID) == 0) || \ + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) + /* * Format of a directory entry in /proc, ... * This must map onto struct dirent (see ) Index: miscfs/procfs/procfs_mem.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_mem.c,v retrieving revision 1.26 diff -u -r1.26 procfs_mem.c --- procfs_mem.c 1997/08/02 14:32:14 1.26 +++ procfs_mem.c 1997/08/11 01:44:26 @@ -277,6 +277,23 @@ if (uio->uio_resid == 0) return (0); + /* + * XXX + * We need to check for KMEM_GROUP because ps is sgid kmem; + * not allowing it here causes ps to not work properly. Arguably, + * this is a bug with what ps does. We only need to do this + * for Pmem nodes, and only if it's reading. This is still not + * good, as it may still be possible to grab illicit data if + * a process somehow gets to be KMEM_GROUP. Note that this also + * means that KMEM_GROUP can't change without editing procfs.h! + * All in all, quite yucky. + */ + + if (!CHECKIO(curp, p) && + ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && + (uio->uio_rw != UIO_READ)) + return EPERM; + return (procfs_rwmem(p, uio)); } Index: miscfs/procfs/procfs_regs.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_regs.c,v retrieving revision 1.7 diff -u -r1.7 procfs_regs.c --- procfs_regs.c 1997/08/02 14:32:16 1.7 +++ procfs_regs.c 1997/08/11 01:42:06 @@ -60,6 +60,8 @@ char *kv; int kl; + if (!CHECKIO(curp, p)) + return EPERM; kl = sizeof(r); kv = (char *) &r; Index: miscfs/procfs/procfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.30 diff -u -r1.30 procfs_vnops.c --- procfs_vnops.c 1997/08/02 14:32:20 1.30 +++ procfs_vnops.c 1997/08/11 01:43:41 @@ -127,16 +127,21 @@ } */ *ap; { struct pfsnode *pfs = VTOPFS(ap->a_vp); + struct proc *p1 = ap->a_p, *p2 = PFIND(pfs->pfs_pid); + + if (p2 == NULL) + return ENOENT; switch (pfs->pfs_type) { case Pmem: - if (PFIND(pfs->pfs_pid) == 0) - return (ENOENT); /* was ESRCH, jsp */ - if ((pfs->pfs_flags & FWRITE) && (ap->a_mode & O_EXCL) || (pfs->pfs_flags & O_EXCL) && (ap->a_mode & FWRITE)) return (EBUSY); + if (!CHECKIO(p1, p2) && + (p1->p_cred->pc_ucred->cr_gid != KMEM_GROUP)) + return EPERM; + if (ap->a_mode & FWRITE) pfs->pfs_flags = ap->a_mode & (FWRITE|O_EXCL); @@ -194,7 +199,6 @@ struct proc *a_p; } */ *ap; { - return (ENOTTY); } From owner-freebsd-current Sun Aug 10 23:36:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16119 for current-outgoing; Sun, 10 Aug 1997 23:36:11 -0700 (PDT) Received: from abby.skypoint.net (abby.skypoint.net [199.86.32.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16114 for ; Sun, 10 Aug 1997 23:36:09 -0700 (PDT) Received: (from uucp@localhost) by abby.skypoint.net (8.8.5/alexis 2.7) with UUCP id BAA14903; Mon, 11 Aug 1997 01:35:33 -0500 (CDT) Received: (from bruce@localhost) by zuhause.mn.org (8.8.7/8.8.5) id BAA00276; Mon, 11 Aug 1997 01:33:21 -0500 (CDT) Date: Mon, 11 Aug 1997 01:33:21 -0500 (CDT) Message-Id: <199708110633.BAA00276@zuhause.mn.org> From: Bruce Albrecht To: Steve Passe Cc: current@FreeBSD.ORG Subject: Re: Trap 9 When Boot SMP In-Reply-To: <199708101754.LAA11619@Ilsa.StevesCafe.com> References: <199708092123.QAA14184@zuhause.mn.org> <199708101754.LAA11619@Ilsa.StevesCafe.com> X-Mailer: VM 6.30 under 19.15p2 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > Hi, > > Thomas found a 'fix', although we don't understand WHY the problem exists. > It appears that %es is getting corrupted somewhere during boot. The > 'solution' was: > > > The es value IS the culprit. > > > > Havn't found where it is being mangled, I suspect the > > doreti code. > > > > I nailed es to ds at the top of smp_idleloop in init_smp.c. > > asm("pushl %ds; popl %es"); > > --- > anyone have any theories about this one? This is the only reported system > having this problem, and I have no clues as to why... I've been having the same problem since May on an Tyan ATX 1668 system (with a 5 week hiatus when my machine was sent back to the vendor for repairs, including problems with memory). At the time, Steve suspected that it was hardware, but this hack does allow me to run SMP now. Two things in common is that we both have Matrox accelerators and NCR SCSI controllers. Strangely enough, I did have SMP running for about a week in early May, but it stopped working about the time I did some hardware changes. Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #1: Mon Aug 11 01:21:47 CDT 1997 bruce@zuhause.mn.org:/usr/src/sys/compile/ZUHAUSE CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff real memory = 67108864 (65536K bytes) avail memory = 62504960 (61040K bytes) FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 DEVFS: ready for devices Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 ncr0: rev 0x12 int a irq 18 on pci0.12.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo scbus0 at ncr0 bus 0 sd1 at scbus0 target 0 lun 0 sd1: type 0 fixed SCSI 1 sd1: Direct-Access 40MB (82029 512 byte sectors) sd1: with 834 cyls, 3 heads, and an average 32 sectors/track st0 at scbus0 target 4 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access st0: 5.0 MB/s (200 ns, offset 8) density code 0x13, 512-byte blocks, write-enabled ch0 at scbus0 target 4 lun 1 ch0: type 8 removable SCSI 2 ch0: Medium-Changer 4 slots, 1 drive, 1 picker cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM cd0: asynchronous. cd present [293037 x 2048 byte records] ncr1: rev 0x03 int a irq 17 on pci0.13.0 ncr1: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo scbus1 at ncr1 bus 0 sd0 at scbus1 target 6 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access sd0: 20.0 MB/s (50 ns, offset 15) 3067MB (6281856 512 byte sectors) sd0: with 6810 cyls, 5 heads, and an average 184 sectors/track vga0: rev 0x01 int a irq 16 on pci0.14.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 at 0x60-0x64 irq 12 on motherboard psm0: device ID 0 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 npx0 on motherboard npx0: INT 16 interface sb0 at 0x220-0x22f irq 5 drq 1 on isa sb0: sbxvi0 drq 5 on isa sbxvi0: sbmidi0 at 0x330-0x331 on isa sbmidi0: joy0 at 0x201 on isa joy0: joystick DEVFS: ready to run APIC_IO: routing 8254 via 8259 on pin 0 SMP: All idle procs online. SMP: *** AUTO *** starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! ------- =============================================================================== MPTable, version 2.0.13 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fb100 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xf7 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f5d40 signature: 'PCMP' base table length: 284 version: 1.1 checksum: 0x93 OEM ID: 'INTEL ' Product ID: '440FX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 27 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 1 9 0xfbff 0 0x11 AP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 1 0 2 0 INT conforms conforms 1 1 2 1 INT conforms conforms 1 0 2 2 INT conforms conforms 1 3 2 3 INT conforms conforms 1 4 2 4 INT conforms conforms 1 5 2 5 INT conforms conforms 1 6 2 6 INT conforms conforms 1 7 2 7 INT active-hi edge 1 8 2 8 INT conforms conforms 1 9 2 9 INT conforms conforms 1 10 2 10 INT conforms conforms 1 11 2 11 INT conforms conforms 1 12 2 12 INT conforms conforms 1 13 2 13 INT conforms conforms 1 14 2 14 INT conforms conforms 1 15 2 15 INT active-lo level 0 14:A 2 16 INT active-lo level 0 13:A 2 17 INT active-lo level 0 12:A 2 18 SMI conforms conforms 1 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0:A 255 0 NMI conforms conforms 0 0:A 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs =============================================================================== From owner-freebsd-current Mon Aug 11 02:50:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA24599 for current-outgoing; Mon, 11 Aug 1997 02:50:48 -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 CAA24580; Mon, 11 Aug 1997 02:50:37 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA12034; Mon, 11 Aug 1997 02:53:05 -0700 (PDT) Message-Id: <199708110953.CAA12034@implode.root.com> To: Sean Eric Fagan cc: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-reply-to: Your message of "Sun, 10 Aug 1997 20:15:52 PDT." <199708110315.UAA14486@freefall.freebsd.org> From: David Greenman Reply-To: dg@root.com Date: Mon, 11 Aug 1997 02:53:05 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >+ /* >+ * XXX >+ * We need to check for KMEM_GROUP because ps is sgid kmem; >+ * not allowing it here causes ps to not work properly. Arguably, >+ * this is a bug with what ps does. We only need to do this >+ * for Pmem nodes, and only if it's reading. This is still not >+ * good, as it may still be possible to grab illicit data if >+ * a process somehow gets to be KMEM_GROUP. Note that this also >+ * means that KMEM_GROUP can't change without editing procfs.h! >+ * All in all, quite yucky. >+ */ >+ >+ if (!CHECKIO(curp, p) && >+ ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && >+ (uio->uio_rw != UIO_READ)) >+ return EPERM; If I read this right, you allow reads, correct? This would allow access to potentially sensitive information in the setuid process. If the above is changed to fail no matter what the operation, I think your fix should be okay. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Mon Aug 11 04:08:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA27446 for current-outgoing; Mon, 11 Aug 1997 04:08:14 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA27441; Mon, 11 Aug 1997 04:08:01 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id PAA28273; Mon, 11 Aug 1997 15:07:52 +0400 (MSD) Date: Mon, 11 Aug 1997 15:07:49 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Sean Eric Fagan cc: current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708110315.UAA14486@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 10 Aug 1997, Sean Eric Fagan wrote: > +#define CHECKIO(p1, p2) \ > + ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ > + ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ > + ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ > + ((p2)->p_flag & P_SUGID) == 0) || \ > + (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) Comparing uids gains absolutely nothing. The program can change uids many times and finaly do allowed combination. But "interesting" code or data from previous superuser mode can still left in the memory. I think any access to memory must be disallowed immediately after exec of setuid program issued by user (not setuid root) program. I.e. exec call must set some flag (in struct proc?) disabling procfs access and procfs call need to check this flag only. We also need some solution which completely disable access to parent memory from forked child because allowing it is against Unix ideology. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Mon Aug 11 05:52:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA01830 for current-outgoing; Mon, 11 Aug 1997 05:52:08 -0700 (PDT) Received: from lirmm.lirmm.fr (lirmm.lirmm.fr [193.49.104.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA01799 for ; Mon, 11 Aug 1997 05:51:55 -0700 (PDT) Received: from lirmm.fr (baobab.lirmm.fr [193.49.106.14]) by lirmm.lirmm.fr (8.8.5/8.8.5) with ESMTP id OAA21908; Mon, 11 Aug 1997 14:50:18 +0200 (MET DST) Message-Id: <199708111250.OAA21908@lirmm.lirmm.fr> To: jdp@polstra.com, current@FreeBSD.org Subject: Re: Philippe Charnier Date: Mon, 11 Aug 1997 14:50:16 +0200 From: "Philippe Charnier" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk John Polstra: > Does anybody find it odd that Philippe appeared on the scene around > the time that Mike Pritchard vanished? Could it be that they're one > and the same person? NO!, I'm not Mike nor Bill G. nor Hulk Hoggan from WWF. BUT Philippe. -------- -------- Philippe Charnier charnier@lirmm.fr LIRMM, 161 rue Ada, 34392 Montpellier cedex 5 -- France ------------------------------------------------------------------------ From owner-freebsd-current Mon Aug 11 06:22:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA03076 for current-outgoing; Mon, 11 Aug 1997 06:22:52 -0700 (PDT) Received: from hub.org (hub.org [207.107.138.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA03071 for ; Mon, 11 Aug 1997 06:22:44 -0700 (PDT) Received: from localhost (scrappy@localhost) by hub.org (8.8.5/8.7.5) with SMTP id JAA07667 for ; Mon, 11 Aug 1997 09:22:59 -0400 (EDT) Date: Mon, 11 Aug 1997 09:22:58 -0400 (EDT) From: The Hermit Hacker To: current@freebsd.org Subject: Wish List Item: DHCP for Instsall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi... I'm currently working in an academic environment, and we have, essentially, campus wide ethernet (the residences themselves are wired in). This morning, one of the students asked me about installing FreeBSD on his PC, using the FTP install, and had a slight problem... IPs on our network are fed by DHCP, so setting up his ethernet card to be on the network required my intervention in order for him to have a static IP temporarily, to perform the install. I haven't heard much talk about DHCP under FreeBSD, but has anyone thought about, or looked into, the possibility of using DHCP for both the install, and as part of the standard 'runtime'? Marc G. Fournier scrappy@hub.org Systems Administrator @ hub.org scrappy@freebsd.org From owner-freebsd-current Mon Aug 11 06:50:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA04423 for current-outgoing; Mon, 11 Aug 1997 06:50:13 -0700 (PDT) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA04414 for ; Mon, 11 Aug 1997 06:50:01 -0700 (PDT) Received: from sexta.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA07698 (5.67b/HUJI 4.153 for ); Mon, 11 Aug 1997 16:49:25 +0300 Received: from sexta.cs.huji.ac.il (danny@localhost [127.0.0.1]) by sexta.cs.huji.ac.il (8.8.5/1.1c) with ESMTP id QAA11212 for ; Mon, 11 Aug 1997 16:49:24 +0300 (IDT) Message-Id: <199708111349.QAA11212@sexta.cs.huji.ac.il> X-Mailer: exmh version 2.0gamma 1/27/96 To: current@FreeBSD.ORG Subject: ARPA Proxy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Aug 1997 16:49:24 +0300 From: Danny Braniss Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hello all, I guess this is more a Net/3 item but ... I'm trying to set up a host with 2 NICS, and want it to act as a proxy arp gateway/router (I think the term is L2-Bridging?). Looking at the kernel sources, i see that FreeBsd has a fix so as not to send ARP Reply to the 'wrong' interface, but there are, IMHO, some problems. Since im not sure this is the correct forum, if someone out there is willing to hear me out, i'll be much oblidged. danny -- Daniel Braniss e-mail: danny@cs.huji.ac.il Institute of Computer Science phone: +972 2 658 4385 The Hebrew University Fax: +972 2 561 7723 Jerusalem, Israel From owner-freebsd-current Mon Aug 11 07:40:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA06861 for current-outgoing; Mon, 11 Aug 1997 07:40:02 -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 HAA06818 for ; Mon, 11 Aug 1997 07:39:58 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id HAA11232; Mon, 11 Aug 1997 07:39:16 -0700 (PDT) To: The Hermit Hacker cc: current@FreeBSD.ORG Subject: Re: Wish List Item: DHCP for Instsall In-reply-to: Your message of "Mon, 11 Aug 1997 09:22:58 EDT." Date: Mon, 11 Aug 1997 07:39:15 -0700 Message-ID: <11228.871310355@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I haven't heard much talk about DHCP under FreeBSD, but has anyone > thought about, or looked into, the possibility of using DHCP for both the > install, and as part of the standard 'runtime'? It's definitely been thought about, just no satisfactory solution for actually doing it arrived at yet. Jordan From owner-freebsd-current Mon Aug 11 08:21:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA09451 for current-outgoing; Mon, 11 Aug 1997 08:21:42 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA09428; Mon, 11 Aug 1997 08:21:35 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA07362; Mon, 11 Aug 1997 08:21:25 -0700 Date: Mon, 11 Aug 1997 08:21:25 -0700 From: Sean Eric Fagan Message-Id: <199708111521.IAA07362@kithrup.com> To: ache@nagual.pp.ru, current@freebsd.org, security@freebsd.org Subject: Re: procfs patch Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Comparing uids gains absolutely nothing. Yes, it does: it makes it useful. Tell me: how many applications do *you* have that use procfs? >The program can change uids many times and finaly do allowed combination. >But "interesting" code or data from previous superuser mode can still left >in the memory. My patch is no different than the situation with core files. If a process has your UID, you can make it dump core, and then examine its data. This is an extensio of that. >I think any access to memory must be disallowed immediately after exec of >setuid program issued by user (not setuid root) program. I.e. exec call >must set some flag (in struct proc?) disabling procfs access and procfs >call need to check this flag only. Gosh, that's what I had originally, and everyone didn't like *that*. (Frankly, neither did I.) Sean. From owner-freebsd-current Mon Aug 11 08:41:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10731 for current-outgoing; Mon, 11 Aug 1997 08:41:17 -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 IAA10711; Mon, 11 Aug 1997 08:41:08 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA18095; Tue, 12 Aug 1997 01:36:41 +1000 Date: Tue, 12 Aug 1997 01:36:41 +1000 From: Bruce Evans Message-Id: <199708111536.BAA18095@godzilla.zeta.org.au> To: ache@nagual.pp.ru, sef@FreeBSD.ORG Subject: Re: procfs patch Cc: current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think any access to memory must be disallowed immediately after exec of >setuid program issued by user (not setuid root) program. I.e. exec call >must set some flag (in struct proc?) disabling procfs access and procfs >call need to check this flag only. Just close the procfs file descriptors on exec? >We also need some solution which >completely disable access to parent memory from forked child because >allowing it is against Unix ideology. But it is exactly what rfork() provides. Unix ideology is that file descriptors are not affected on exec unless this is asked for. The rfork fd sharing fix is wrong, and closing procfs file descriptors would be wrong. The exec should fail instead if it would cause a security hole. Bruce From owner-freebsd-current Mon Aug 11 08:45:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA10987 for current-outgoing; Mon, 11 Aug 1997 08:45:17 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA10966; Mon, 11 Aug 1997 08:45:12 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id IAA08497; Mon, 11 Aug 1997 08:45:00 -0700 Date: Mon, 11 Aug 1997 08:45:00 -0700 From: Sean Eric Fagan Message-Id: <199708111545.IAA08497@kithrup.com> To: ache@nagual.pp.ru, bde@zeta.org.au Subject: Re: procfs patch Cc: current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Just close the procfs file descriptors on exec? I thought about doing that. But I decided it was both too invasive, and too bothersome -- a root process would gets its fd's close, and it probably shouldn't. As I said, what I've got now should provide no more risks than dumping core does. Well, it allows for some greater control -- my truss program is not SUID root, and needs to be able to read process memory. But since the process should be owned by the user, I don't have a problem with it. Sean. From owner-freebsd-current Mon Aug 11 09:51:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15366 for current-outgoing; Mon, 11 Aug 1997 09:51:20 -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 JAA15355 for ; Mon, 11 Aug 1997 09:51:14 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA15410; Mon, 11 Aug 1997 09:47:29 -0700 From: Terry Lambert Message-Id: <199708111647.JAA15410@phaeton.artisoft.com> Subject: Re: cvs commit: src/etc aliases To: fenner@parc.xerox.com (Bill Fenner) Date: Mon, 11 Aug 1997 09:47:29 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <97Aug10.161203pdt.177512@crevenia.parc.xerox.com> from "Bill Fenner" at Aug 10, 97 04:11:56 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-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I *don't* think they should be taken out. They are mandated by RFC. > > I don't think they should be taken out either, but they are not mandated. They are mandated by RFC2142. The distinction I think you are missing is that RFC2142 is *not* mandated. However, there is "case law" in FreeBSD in this regard... specifically, FreeBSD enables RFC1323 and RFC1644 in its default configuration. > 1. RFC2142 is Elective, not even Recommended and certainly not Required > (see RFC2200). Elective means basically "if you are going to do > something like this, you must do exactly this." Yes. It is also a standards track protocol (see "Status of This Memo"). > 2. RFC2142 itself doesn't claim to apply to all hosts: [ ... ] I think this is the salient point upon which I'm basing my recommendation: > However, if a given service is offerred, > then the associated mailbox name(es) must be supported, resulting in > delivery to a recipient appropriate for the referenced service or > role. [ ... ] > I could go either way on the commented / uncommentedness of the aliases > in the default file, but I think it should go all one way or all the > other. I agree as well; but by default, the services offered by a FreeBSD host /must/ have the RFC mandated aliases if FreeBSD chooses to comply with RFC2142 as it has chosen to comply with RFC's 1323 and 1644. The default configuration of FreeBSD does not offer all of these services, so the RFC does not require all of the aliases. I think FreeBSD should do "the RFC1323/1644 thing" and enable all aliases. > I disagree with the "it gives more ways for spammers to send to known > userids" argument if they're all aliased to "root" -- "root" is already > a well known userid. I disagree with that as well; RFC822 mandates "postmaster", and RFC821 mandates accepting null addresses in the "MAIL FROM:
" in an SMTP session also "aid spammers". The correct mechanism for this is to use GetPeerName() on the connecting socket to refuse connections from spammers, and to use 521 responses (RFC1846) if connections are granted anyway. One can also enforce the domain requirement for "HELO" (in combination with 521 responses, this is a nice way to determine interstate wire fraud). In any case, additional aliases make the domain no less open to attack than it would otherise be. 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-current Mon Aug 11 09:57:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA15670 for current-outgoing; Mon, 11 Aug 1997 09:57:26 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15649 for ; Mon, 11 Aug 1997 09:57:17 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA15898; Mon, 11 Aug 1997 10:57:02 -0600 (MDT) Message-Id: <199708111657.KAA15898@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Bruce Albrecht cc: current@FreeBSD.ORG Subject: Re: Trap 9 When Boot SMP In-reply-to: Your message of "Mon, 11 Aug 1997 01:33:21 CDT." <199708110633.BAA00276@zuhause.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Aug 1997 10:57:02 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Steve Passe writes: > > Hi, > > > > Thomas found a 'fix', although we don't understand WHY the problem exists. > > It appears that %es is getting corrupted somewhere during boot. The > > 'solution' was: > > > > > The es value IS the culprit. > > > > > > Havn't found where it is being mangled, I suspect the > > > doreti code. > > > > > > I nailed es to ds at the top of smp_idleloop in init_smp.c. > > > asm("pushl %ds; popl %es"); > > > > --- > > anyone have any theories about this one? This is the only reported system > > having this problem, and I have no clues as to why... > > I've been having the same problem since May on an Tyan ATX 1668 system > (with a 5 week hiatus when my machine was sent back to the vendor for > repairs, including problems with memory). At the time, Steve > suspected that it was hardware, but this hack does allow me to run SMP > now. Two things in common is that we both have Matrox accelerators > and NCR SCSI controllers. Strangely enough, I did have SMP running > for about a week in early May, but it stopped working about the time I > did some hardware changes. do you recall what those hardware changes were? I don't see the Matrox being trouble at boot as there is no code specific to that card at boot time. The NCR code is a possibility, what/who's BIOS are you using for the NCR card? I'll add this patch to the code as some sort of "#ifdef 0" thing and document it as rogue hardware. Not much else to do until we can nail down exactly what the prblem is caused by. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Mon Aug 11 10:11:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16806 for current-outgoing; Mon, 11 Aug 1997 10:11:01 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA16783; Mon, 11 Aug 1997 10:10:56 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id LAA13714; Mon, 11 Aug 1997 11:10:33 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id LAA06171; Mon, 11 Aug 1997 11:10:03 -0600 (MDT) Date: Mon, 11 Aug 1997 11:10:02 -0600 (MDT) From: Marc Slemko To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >The program can change uids many times and finaly do allowed combination. > >But "interesting" code or data from previous superuser mode can still left > >in the memory. > > My patch is no different than the situation with core files. If a process > has your UID, you can make it dump core, and then examine its data. This is > an extensio of that. No you can't. BTDT. If a process has done a setuid() (well, more accurately if it has done a setuid() that has changed the uid) it will not dump core. ISTR that on Linux it took an awfully long time to get all the security holes out of procfs. Well, all of the more serious ones that have been found so far. From owner-freebsd-current Mon Aug 11 10:48:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA18932 for current-outgoing; Mon, 11 Aug 1997 10:48:13 -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 KAA18923 for ; Mon, 11 Aug 1997 10:48:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA15569; Mon, 11 Aug 1997 10:43:51 -0700 From: Terry Lambert Message-Id: <199708111743.KAA15569@phaeton.artisoft.com> Subject: Re: cvs commit: src/etc aliases To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Mon, 11 Aug 1997 10:43:51 -0700 (MST) Cc: fenner@parc.xerox.com, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <199708110140.SAA12999@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Aug 10, 97 06:40: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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I disagree with the "it gives more ways for spammers to send to known > > userids" argument if they're all aliased to "root" -- "root" is already > > a well known userid. > > But ``root'' is one almost every spammer in the world filters out as > they KNOW that root is the one who is going to come hunting them down > and/or filter them in major ways. Yeah, but a spammer who sens to "sales" is just asking to get spammed back... 8-). BTW: "sales" is one of those mailbox names that I would say should remain commented by default for strict conformance. 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-current Mon Aug 11 11:11:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA20244 for current-outgoing; Mon, 11 Aug 1997 11:11:16 -0700 (PDT) Received: from lamb.sas.com (uucp@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA20215 for ; Mon, 11 Aug 1997 11:11:09 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA19529; Mon, 11 Aug 1997 14:11:01 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA00815; Mon, 11 Aug 1997 14:10:52 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA02182; Mon, 11 Aug 1997 14:10:52 -0400 Message-Id: <199708111810.AA02182@iluvatar.unx.sas.com> Subject: nfs v3 & network appliance To: freebsd-current@freebsd.org Date: Mon, 11 Aug 1997 14:10:51 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have a copy of the latest snap up and running. Using nfs to access our v2 nfs servers works like a champ. However, trying to access a network appliance nfs fileserver which speaks v3 locks up tight. Does anyone have any ideas (or comments) that I might try? Has anyone actually used -current against a netapp fileserver? Thanks, John ps: No, this is NOT an SMP system.. :-) It does, however, do the exact same thing under smp. -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Mon Aug 11 11:11:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA20309 for current-outgoing; Mon, 11 Aug 1997 11:11:48 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA20297 for ; Mon, 11 Aug 1997 11:11:40 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA08543 for ; Mon, 11 Aug 1997 11:11:09 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id OAA15446; Mon, 11 Aug 1997 14:11:04 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id OAA01972; Mon, 11 Aug 1997 14:11:05 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id NAA11996; Mon, 11 Aug 1997 13:11:44 -0500 (CDT) Date: Mon, 11 Aug 1997 13:11:44 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199708111811.NAA11996@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: current@freebsd.org Subject: IDE flags 80ff events X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Using flags 0x80ff in current of 2200=GMT 8 Aug 1997, I observed this sequence of events during a tar extraction: wd2: interrupt timeout: wd2: status 58 error 0 wd2: interrupt timeout: wd2: status 50 error 1 wd2: wdunwedge failed: wd2: status 80 error 1 wd2s3e: wdstart: timeout waiting to give command reading fsbn 262320 of 262320-2 62335 (wd2s3 bn 262320; cn 21 tn 68 sn 51)wd2: status 80 error 1 From owner-freebsd-current Mon Aug 11 11:52:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA22820 for current-outgoing; Mon, 11 Aug 1997 11:52:45 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22815; Mon, 11 Aug 1997 11:52:40 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id WAA06268; Mon, 11 Aug 1997 22:52:25 +0400 (MSD) Date: Mon, 11 Aug 1997 22:52:23 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Sean Eric Fagan cc: FreeBSD-current , security@FreeBSD.ORG, Bruce Evans Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >Comparing uids gains absolutely nothing. > > Yes, it does: it makes it useful. Useful for what? Even if they are equal at the moment you check it not means that program was not setuided before your check and have secret data in memory. > >The program can change uids many times and finaly do allowed combination. > >But "interesting" code or data from previous superuser mode can still left > >in the memory. > > My patch is no different than the situation with core files. If a process > has your UID, you can make it dump core, and then examine its data. This is > an extensio of that. As I already write you, it is false in general case. If program was setuided, you can't make core from it even it runs with your UID currently. I don't see an extension here but old security hole (core-like one) reopening as I warn already. > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Now I like Bruce's idea that exec call should fail if procfs memory is open and setuid program is executed. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Mon Aug 11 12:02:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA23191 for current-outgoing; Mon, 11 Aug 1997 12:02:16 -0700 (PDT) Received: from lamb.sas.com (uucp@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23186 for ; Mon, 11 Aug 1997 12:02:11 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA17636; Mon, 11 Aug 1997 15:02:10 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA10530; Mon, 11 Aug 1997 14:50:16 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA02267; Mon, 11 Aug 1997 14:50:16 -0400 Message-Id: <199708111850.AA02267@iluvatar.unx.sas.com> Subject: Number of pci busses probed at boot time To: freebsd-current@freebsd.org Date: Mon, 11 Aug 1997 14:50:15 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, When I boot my system, the pci init code scans 255 pci busses looking for devices (which are found on bus 0 & 1). So, I thought I might reduce the number of pci busses probed... My confusion? Well, in pci.c, we have: static int pci_bushigh(void) { if (pic_cfgopen() == 0) return (-1); return (0); } and the return value is used in: int pci_probe(pciattach *parent) int bushigh; int bus = 0; bushigh = pci_bushigh(); while (bus <= bushigh) { ... So, how is the system finding ANY pci busses? The code above seems to only return 0 or -1. Could someone enlighten me please? Thanks, John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Mon Aug 11 12:11:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA23700 for current-outgoing; Mon, 11 Aug 1997 12:11:49 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA23678; Mon, 11 Aug 1997 12:11:40 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id MAA23776; Mon, 11 Aug 1997 12:11:26 -0700 Date: Mon, 11 Aug 1997 12:11:26 -0700 From: Sean Eric Fagan Message-Id: <199708111911.MAA23776@kithrup.com> To: ache@nagual.pp.ru, bde@zeta.org.au, current@freebsd.org, security@freebsd.org Subject: Re: procfs patch Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Useful for what? Even if they are equal at the moment you check it not >means that program was not setuided before your check and have secret data >in memory. Why are people having such a hard time reading the code? (Well, Bruce has -- I disagree with his objections, but he *has* read teh code, and does seem to understand what's going on.) The only "secret data" you have in memory after an exec would be file descriptors, and environment data. You can get the environment data by sending a core-dumping signal to the process. You can attach to it with ptrace(). You can read its memory with /proc//mem. THe process does not have P_SUGID set. Because it has done an exec since the last setuid/setgid. THis is clear if you read the kernel code. >> My patch is no different than the situation with core files. If a process >> has your UID, you can make it dump core, and then examine its data. This is >> an extensio of that. > >As I already write you, it is false in general case. If program was >setuided, you can't make core from it even it runs with your UID >currently. I don't see an extension here but old security hole (core-like >one) reopening as I warn already. Consider this: you run suid program it does some stuff, then sesetuid's to you it then exec's a program, as you You can make that last program core dump. Got it? It can core dump. It can core dump. It can core dump. I don't like repeating myself, but people don't seem to be reading. In teh above case, with my procfs changes, you cannot read the suid program's memory. YOu cannot read the suid program's memory after it setuid's to you. YOu can read the last program's memory. This is no worse than the core dump case. Because you can make it core dump, because it is you, and P_SUGID is not set. If you *read* the code I sent out, you'll see that it checks for P_SUGID being set, and fails (assuming the requesting process is not suser()). Is that clear yet? Do I need to repeat myself again? (Yes, I'm getting frustrated here.) >Now I like Bruce's idea that exec call should fail if procfs memory is >open and setuid program is executed. I don't. I hate it. It's bad. It makes things difficult for programs that want to use this. It is also unnecessary -- my changes do not have that particular hole. (IT's bad because it fails the principle of least surprise. You can't really argue "traditional unix semantics," because procfs was not in traditional unix. You can try arguing what SysVr4 does, but I'm not sure what that is. You can try arguing security -- but you'd darned well better be prepared to fix *everything* then, and not just spot check. You can try using traditional unix semantics as a guideline, and that's what I've done, in both this case and the rfork/exec case. And that boils down to: useability and principle of least surprise.) Once again: my procfs changes, for the most part, are no worse than core dumping. So, Andrey, why don't you go around demanding that core dumps be completely disabled. When you do that, I'll start to have some respect for your position; until then, you're just going to impress me as someone who hasn't read teh code I sent out. Is there still a security risk? Yes. It's very slight, and I can argue that most of the cases it matters are bad programming anyway. But it's there. But it is there without procfs, in the form of PT_ATTACH in ptrace. ANd much of it is there with core dumps. Sean. From owner-freebsd-current Mon Aug 11 12:27:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA24464 for current-outgoing; Mon, 11 Aug 1997 12:27:22 -0700 (PDT) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24459 for ; Mon, 11 Aug 1997 12:27:19 -0700 (PDT) Received: from pauling.salk.edu (pauling [198.202.70.108]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id MAA15814 for ; Mon, 11 Aug 1997 12:26:42 -0700 (PDT) Date: Mon, 11 Aug 1997 12:26:42 -0700 (PDT) From: Tom Bartol To: current@freebsd.org Subject: Jerky mouse motion in -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Is anyone else out there experiencing very jerky mouse motion under slight load (i.e. compiling a small program) using X and -current built early 8/11? Could this be a side effect of the new scheduling policy that John Dyson committed last night? Tom From owner-freebsd-current Mon Aug 11 12:34:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA24894 for current-outgoing; Mon, 11 Aug 1997 12:34:22 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA24867; Mon, 11 Aug 1997 12:34:12 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA23926; Mon, 11 Aug 1997 15:31:58 -0400 (EDT) Date: Mon, 11 Aug 1997 15:31:58 -0400 (EDT) From: Brian Mitchell To: Sean Eric Fagan cc: ache@nagual.pp.ru, bde@zeta.org.au, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111545.IAA08497@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >Just close the procfs file descriptors on exec? > > I thought about doing that. But I decided it was both too invasive, and too > bothersome -- a root process would gets its fd's close, and it probably > shouldn't. Maybe not. If you are root and execute a setuid program, is P_SUGID set? I would think not, but I have not checked. > > As I said, what I've got now should provide no more risks than dumping core > does. Well, it allows for some greater control -- my truss program is not > SUID root, and needs to be able to read process memory. But since the > process should be owned by the user, I don't have a problem with it. > > Sean. > Now -- how about disallowing access if the binary is unreadable :) From owner-freebsd-current Mon Aug 11 12:36:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA25100 for current-outgoing; Mon, 11 Aug 1997 12:36:48 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25061; Mon, 11 Aug 1997 12:36:29 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id PAA23907; Mon, 11 Aug 1997 15:29:20 -0400 (EDT) Date: Mon, 11 Aug 1997 15:29:20 -0400 (EDT) From: Brian Mitchell To: Sean Eric Fagan cc: ache@nagual.pp.ru, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111521.IAA07362@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > >I think any access to memory must be disallowed immediately after exec of > >setuid program issued by user (not setuid root) program. I.e. exec call > >must set some flag (in struct proc?) disabling procfs access and procfs > >call need to check this flag only. > > Gosh, that's what I had originally, and everyone didn't like *that*. > (Frankly, neither did I.) Yes, I advise everyone to try just denying access when P_SUGID is enabled. This is what my patch does, and it is simply unacceptable. I'm not sure sef's patch is perfect, but it's not bad. As for the kmem stuff, I originally did not like that, but look at the perms on the mem device! It allows kmem to be readable. I think we should duplicate those perms whenever possible. Granted this allows people who have managed to break gid kmem to look at privledged data (shadow files is one big example I can think of) it is certainly better than nothing. Besides. if they have gid kmem, they can do the exact same thing by munging through /dev/kmem, so denying them proc/#/mem is not a real big win in my book. There is a situation where we could get into trouble, although I don't think it occurs. exec suid program setuid(0) exec non suid program I don't know that this occurs anywhere, but things like this concern me and leave me wondering if perhaps we should revoke the fd(s) when we execute a setuid program. From owner-freebsd-current Mon Aug 11 13:22:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27612 for current-outgoing; Mon, 11 Aug 1997 13:22:02 -0700 (PDT) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27582; Mon, 11 Aug 1997 13:21:54 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id PAA11196; Mon, 11 Aug 1997 15:26:28 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 11 Aug 1997 15:26:28 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Sean Eric Fagan , FreeBSD-current , security@FreeBSD.ORG, Bruce Evans Subject: Re: procfs patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Gosh, that's what I had originally, and everyone didn't like *that*. > > (Frankly, neither did I.) > > Now I like Bruce's idea that exec call should fail if procfs memory is > open and setuid program is executed. why not have procfs check the UID of the file everytime an access is made VS the UID of the accessing program and denying access at that point? Alfred From owner-freebsd-current Mon Aug 11 13:26:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27974 for current-outgoing; Mon, 11 Aug 1997 13:26:31 -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 NAA27969 for ; Mon, 11 Aug 1997 13:26:28 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA03498; Mon, 11 Aug 1997 22:26:39 +0200 (MEST) From: Søren Schmidt Message-Id: <199708112026.WAA03498@sos.freebsd.dk> Subject: Re: Jerky mouse motion in -current In-Reply-To: from Tom Bartol at "Aug 11, 97 12:26:42 pm" To: bartol@salk.edu (Tom Bartol) Date: Mon, 11 Aug 1997 22:26:39 +0200 (MEST) Cc: current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Tom Bartol who wrote: > > Hi, > > Is anyone else out there experiencing very jerky mouse motion under slight > load (i.e. compiling a small program) using X and -current built early > 8/11? Could this be a side effect of the new scheduling policy that John > Dyson committed last night? Maybe, I've noticed changed behavior much like you too... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Mon Aug 11 13:58:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA29405 for current-outgoing; Mon, 11 Aug 1997 13:58:50 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA29394 for ; Mon, 11 Aug 1997 13:58:48 -0700 (PDT) Received: from rhiannon.scsn.net ([209.12.57.37]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-32322U5000L100S10000) with ESMTP id AAA86; Mon, 11 Aug 1997 17:01:22 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id QAA02501; Mon, 11 Aug 1997 16:58:40 -0400 (EDT) Message-ID: <19970811165839.34952@scsn.net> Date: Mon, 11 Aug 1997 16:58:39 -0400 From: "Donald J. Maddox" To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: Tom Bartol , current@FreeBSD.ORG Subject: Re: Jerky mouse motion in -current Reply-To: dmaddox@scsn.net References: <199708112026.WAA03498@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.79 In-Reply-To: =?iso-8859-1?Q?=3C199708112026=2EWAA03498=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Mon=2C_Aug_11=2C_1997_at_10=3A26=3A3?= =?iso-8859-1?Q?9PM_+0200?= Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Aug 11, 1997 at 10:26:39PM +0200, Søren Schmidt wrote: > In reply to Tom Bartol who wrote: > > > > Hi, > > > > Is anyone else out there experiencing very jerky mouse motion under slight > > load (i.e. compiling a small program) using X and -current built early > > 8/11? Could this be a side effect of the new scheduling policy that John > > Dyson committed last night? > > Maybe, I've noticed changed behavior much like you too... > That makes three of us :-( From owner-freebsd-current Mon Aug 11 14:04:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA29815 for current-outgoing; Mon, 11 Aug 1997 14:04:55 -0700 (PDT) Received: from mom.hooked.net (root@mom.hooked.net [206.80.6.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29807 for ; Mon, 11 Aug 1997 14:04:52 -0700 (PDT) Received: from zippy.dyn.ml.org (garbanzo@pm3-ppp1.well.com [206.15.85.1]) by mom.hooked.net (8.8.5/8.8.5) with SMTP id OAA10229; Mon, 11 Aug 1997 14:03:41 -0700 (PDT) Date: Mon, 11 Aug 1997 14:03:44 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: "John W. DeBoskey" cc: freebsd-current@FreeBSD.ORG Subject: Re: Number of pci busses probed at boot time In-Reply-To: <199708111850.AA02267@iluvatar.unx.sas.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, John W. DeBoskey wrote: > Hi, > > When I boot my system, the pci init code scans 255 pci busses > looking for devices (which are found on bus 0 & 1). So, I thought > I might reduce the number of pci busses probed... I'm assuming that you're using an SMP machine, however even if you're not this will probably apply to you. Since you obviously have the kernel sources, check out the file that should be in /usr/src/sys/i386/conf/SMP.GENERIC. This has an option "NBUS" and a value following it. This sets the number of busses that the kernel will probe for afaik. > So, how is the system finding ANY pci busses? The code above > seems to only return 0 or -1. Could someone enlighten me please? I haven't checked into the code much, but check into the files that contain support for your specific chipset. pcisupport.c might be a good place to start. - alex From owner-freebsd-current Mon Aug 11 14:46:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA01881 for current-outgoing; Mon, 11 Aug 1997 14:46:47 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA01875; Mon, 11 Aug 1997 14:46:42 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA08850; Tue, 12 Aug 1997 01:46:33 +0400 (MSD) Date: Tue, 12 Aug 1997 01:46:32 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Sean Eric Fagan cc: bde@zeta.org.au, current@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: procfs patch In-Reply-To: <199708111911.MAA23776@kithrup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997, Sean Eric Fagan wrote: > Consider this: > > you run suid program > it does some stuff, then sesetuid's to you > it then exec's a program, as you > > You can make that last program core dump. Got it? It can core dump. It > can core dump. It can core dump. At this point you just not make clear enough in your previous postings that _exec_ happens between setuid and core dump, it cause Marc's and my confusion. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Mon Aug 11 14:50:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA02091 for current-outgoing; Mon, 11 Aug 1997 14:50:51 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA02079 for ; Mon, 11 Aug 1997 14:50:48 -0700 (PDT) Received: from Mercury.mcs.net (fredriks@Mercury.mcs.net [192.160.127.80]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id QAA24061 for ; Mon, 11 Aug 1997 16:50:46 -0500 (CDT) Received: (from fredriks@localhost) by Mercury.mcs.net (8.8.5/8.8.2) id QAA21537 for current@freebsd.org; Mon, 11 Aug 1997 16:50:45 -0500 (CDT) From: Lars Fredriksen Message-Id: <199708112150.QAA21537@Mercury.mcs.net> Subject: pcic_probe panicing in current To: current@freebsd.org Date: Mon, 11 Aug 1997 16:50:45 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just tried to upgrade my current sources on my laptop from end of June, and a freshly built kernel now panics in pcic_probe when it tires to figure out what interrupts are free. Is this related to the recent changes by steve for SMP or is there something else going on here?? Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks-2.pr.mcs.net (home-home) From owner-freebsd-current Mon Aug 11 15:16:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA03571 for current-outgoing; Mon, 11 Aug 1997 15:16:22 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA03554; Mon, 11 Aug 1997 15:16:11 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16550 (5.67b/IDA-1.5); Tue, 12 Aug 1997 00:16:08 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id AAA00615; Tue, 12 Aug 1997 00:16:04 +0200 (CEST) X-Face: " Date: Tue, 12 Aug 1997 00:16:04 +0200 From: Stefan Esser To: "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG, Stefan Esser Subject: Re: Number of pci busses probed at boot time References: <199708111850.AA02267@iluvatar.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199708111850.AA02267@iluvatar.unx.sas.com>; from John W. DeBoskey on Mon, Aug 11, 1997 at 02:50:15PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 11, "John W. DeBoskey" wrote: > Hi, > > When I boot my system, the pci init code scans 255 pci busses > looking for devices (which are found on bus 0 & 1). So, I thought > I might reduce the number of pci busses probed... Which version of FreeBSD do you use ? > My confusion? Well, in pci.c, we have: > > static int > pci_bushigh(void) > { > if (pic_cfgopen() == 0) > return (-1); > return (0); > } Ahhh, this appears to be -current ... > and the return value is used in: > > int > pci_probe(pciattach *parent) > int bushigh; > int bus = 0; > > bushigh = pci_bushigh(); > while (bus <= bushigh) { > ... > > > So, how is the system finding ANY pci busses? The code above > seems to only return 0 or -1. Could someone enlighten me please? Sure! There are two ways to find the number of PCI buses: 1) Call the PCI BIOS. 2) Just check whether there is PCI to PCI bridge and which bus numbers are behind it. For various reasons I prefer method 2), although there is now BIOS32 support in FreeBSD, which does allow to use 1) as well ... Seems you got the number 255 as that of the highest bus behind some PCI to PCI bridge in a chip-set register, and the probe code obeys this value and scans all buses in between. I have thought about stopping the scan, if no single device was found on some PCI bus, but decided that this was bad, since a PCI extender box with no cards in it would have exactly that effect. Do you by chance have a PPro system with two PCI buses directly attached to the CPU ? If yes, then check out the code in pcisupport.c, functions fixbushigh_orion and fixbushigh_i1225. Can you please check what: # pciconf -r pci0:xx:0 0x48 returns on your system, if you replace xx with the PCI slot number of your host to PCI bridge(s) ? (On an Orion system, there are typically two host to PCI bridge chips.) Regards, STefan From owner-freebsd-current Mon Aug 11 18:50:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA15849 for current-outgoing; Mon, 11 Aug 1997 18:50:23 -0700 (PDT) Received: from mantar.slip.netcom.com (mantar.slip.netcom.com [192.187.167.134]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA15820 for ; Mon, 11 Aug 1997 18:50:04 -0700 (PDT) Received: from dual (DUAL [192.187.167.136]) by mantar.slip.netcom.com (8.8.7/8.8.7) with SMTP id SAA12870; Mon, 11 Aug 1997 18:44:40 -0700 (PDT) Message-Id: <3.0.3.32.19970811184432.00e56e70@mantar.slip.netcom.com> X-Sender: guest@mantar.slip.netcom.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 11 Aug 1997 18:44:32 -0700 To: =?iso-8859-1?Q?S=F8ren?= Schmidt , bartol@salk.edu (Tom Bartol) From: Manfred Antar Subject: Re: Jerky mouse motion in -current Cc: current@FreeBSD.ORG In-Reply-To: <199708112026.WAA03498@sos.freebsd.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id SAA15845 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 10:26 PM 8/11/97 +0200, Søren Schmidt wrote: >In reply to Tom Bartol who wrote: >> >> Hi, >> >> Is anyone else out there experiencing very jerky mouse motion under slight >> load (i.e. compiling a small program) using X and -current built early >> 8/11? Could this be a side effect of the new scheduling policy that John >> Dyson committed last night? > >Maybe, I've noticed changed behavior much like you too... > Me Too Manfred |==============================| | mantar@netcom.com | | Ph. (415) 681-6235 | |==============================| From owner-freebsd-current Mon Aug 11 19:21:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA17658 for current-outgoing; Mon, 11 Aug 1997 19:21:31 -0700 (PDT) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA17648 for ; Mon, 11 Aug 1997 19:21:25 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id UAA02043; Mon, 11 Aug 1997 20:20:45 -0600 (MDT) From: Kenneth Merry Message-Id: <199708120220.UAA02043@pluto.plutotech.com> Subject: Re: Jerky mouse motion in -current In-Reply-To: from Tom Bartol at "Aug 11, 97 12:26:42 pm" To: bartol@salk.edu (Tom Bartol) Date: Mon, 11 Aug 1997 20:20:45 -0600 (MDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom Bartol wrote... > Is anyone else out there experiencing very jerky mouse motion under slight > load (i.e. compiling a small program) using X and -current built early > 8/11? Could this be a side effect of the new scheduling policy that John > Dyson committed last night? Put this in your config file: options NO_SCHEDULE_MODS I had the same problem, and John says he'll look into it.. That define will disable the scheduling mods; it brings interactive performance under load back to normal for me. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-current Mon Aug 11 20:24:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA22793 for current-outgoing; Mon, 11 Aug 1997 20:24:40 -0700 (PDT) Received: from abby.skypoint.net (abby.skypoint.net [199.86.32.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA22768 for ; Mon, 11 Aug 1997 20:24:33 -0700 (PDT) Received: (from uucp@localhost) by abby.skypoint.net (8.8.5/alexis 2.7) with UUCP id WAA01000; Mon, 11 Aug 1997 22:18:23 -0500 (CDT) Received: (from bruce@localhost) by zuhause.mn.org (8.8.7/8.8.5) id WAA00320; Mon, 11 Aug 1997 22:10:52 -0500 (CDT) Date: Mon, 11 Aug 1997 22:10:52 -0500 (CDT) Message-Id: <199708120310.WAA00320@zuhause.mn.org> From: Bruce Albrecht To: Steve Passe Cc: current@FreeBSD.ORG Subject: Re: Trap 9 When Boot SMP In-Reply-To: <199708111657.KAA15898@Ilsa.StevesCafe.com> References: <199708110633.BAA00276@zuhause.mn.org> <199708111657.KAA15898@Ilsa.StevesCafe.com> X-Mailer: VM 6.30 under 19.15p2 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > do you recall what those hardware changes were? I had a disk drive die, so I replaced it, and I also reseated all of the SIMMs and PCI cards. Since then, I've also had the motherboard replaced because one of the CPU fan flanges broke during shipping. > I don't see the Matrox being trouble at boot as there is no code specific > to that card at boot time. The NCR code is a possibility, what/who's BIOS > are you using for the NCR card? It's an AMI Tyan Titan-Pro V3.00 10/25/96 BIOS, but this also failed with the Award BIOS. The NCR card uses the Symbios Logic SDMS V4.0 PCI SCSI BIOS, PCI Rev 2.0, 2.1 PCI-4.03.02. > > I'll add this patch to the code as some sort of "#ifdef 0" thing and document > it as rogue hardware. Not much else to do until we can nail down exactly > what the prblem is caused by. I don't have the time to do anything to help track this down for the next week or so, but I'll touch base then to see what I might do to help then. From owner-freebsd-current Mon Aug 11 21:07:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26253 for current-outgoing; Mon, 11 Aug 1997 21:07:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26244 for ; Mon, 11 Aug 1997 21:07:43 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id WAA17341; Mon, 11 Aug 1997 22:07:28 -0600 (MDT) Message-Id: <199708120407.WAA17341@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Alex cc: "John W. DeBoskey" , freebsd-current@FreeBSD.ORG Subject: Re: Number of pci busses probed at boot time In-reply-to: Your message of "Mon, 11 Aug 1997 14:03:44 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Aug 1997 22:07:28 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > When I boot my system, the pci init code scans 255 pci busses > > looking for devices (which are found on bus 0 & 1). So, I thought > > I might reduce the number of pci busses probed... > > I'm assuming that you're using an SMP machine, however even if you're not > this will probably apply to you. Since you obviously have the kernel > sources, check out the file that should be in > /usr/src/sys/i386/conf/SMP.GENERIC. This has an option "NBUS" and a value > following it. This sets the number of busses that the kernel will probe > for afaik. actually, no... NBUS merely reserves slots in a table for building mptable entries for an SMP kernel. It has nothing to do with any sort of bus probe. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Mon Aug 11 21:49:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA28498 for current-outgoing; Mon, 11 Aug 1997 21:49:03 -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 VAA28470; Mon, 11 Aug 1997 21:48:53 -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 WAA04805; Mon, 11 Aug 1997 22:48:52 -0600 (MDT) Message-Id: <199708120448.WAA04805@pluto.plutotech.com> To: current@FreeBSD.org, stable@FreeBSD.org Subject: Possible aic7xxx fix. Date: Mon, 11 Aug 1997 22:48:26 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk For those of you who have been experiencing the "Timedout while idle" and other aic7xxx breakage, please try the following patch and let me know if it helps you out. Thanks __ Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== Index: dev/aic7xxx/aic7xxx.reg =================================================================== RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.reg,v retrieving revision 1.4 diff -c -r1.4 aic7xxx.reg *** aic7xxx.reg 1997/06/27 19:38:39 1.4 --- aic7xxx.reg 1997/08/12 04:39:03 *************** *** 1079,1084 **** --- 1079,1099 ---- CUR_SCBID { size 1 } + /* + * Running count of commands placed in + * the QOUTFIFO. This is cleared by the + * kernel driver every FIFODEPTH commands. + */ + CMDOUTCNT { + size 1 + } + /* + * Maximum number of entries allowed in + * the QOUT/INFIFO. + */ + FIFODEPTH { + size 1 + } ARG_1 { size 1 mask SEND_MSG 0x80 Index: dev/aic7xxx/aic7xxx.seq =================================================================== RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.seq,v retrieving revision 1.74 diff -c -r1.74 aic7xxx.seq *** aic7xxx.seq 1997/06/27 19:38:42 1.74 --- aic7xxx.seq 1997/08/12 04:32:54 *************** *** 643,648 **** --- 643,657 ---- complete: /* Post the SCB and issue an interrupt */ + .if ( SCB_PAGING ) + /* + * Spin loop until there is space + * in the QOUTFIFO. + */ + mov A, FIFODEPTH; + cmp CMDOUTCNT, A je .; + inc CMDOUTCNT; + .endif mov QOUTFIFO,SCB_TAG; mvi INTSTAT,CMDCMPLT; test SCB_CONTROL, ABORT_SCB jz dma_next_scb; Index: i386/scsi/aic7xxx.c =================================================================== RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.c,v retrieving revision 1.120 diff -c -r1.120 aic7xxx.c *** aic7xxx.c 1997/07/20 16:21:34 1.120 --- aic7xxx.c 1997/08/12 04:41:58 *************** *** 784,789 **** --- 784,798 ---- int_cleared = 0; while (qoutcnt = (ahc_inb(ahc, QOUTCNT) & ahc->qcntmask)) { + if ((ahc->flags & AHC_PAGESCBS) != 0) { + ahc->cmdoutcnt += qoutcnt; + if (ahc->cmdoutcnt >= ahc->qfullcount) { + pause_sequencer(ahc); + ahc_outb(ahc, CMDOUTCNT, 0); + unpause_sequencer(ahc, + /*unpause_always*/FALSE); + } + } for (; qoutcnt > 0; qoutcnt--) { scb_index = ahc_inb(ahc, QOUTFIFO); scb = ahc->scb_data->scbarray[scb_index]; *************** *** 2305,2310 **** --- 2314,2322 ---- * their QCount registers. */ ahc_outb(ahc, QCNTMASK, ahc->qcntmask); + + ahc_outb(ahc, FIFODEPTH, ahc->qfullcount); + ahc_outb(ahc, CMDOUTCNT, 0); /* We don't have any waiting selections */ ahc_outb(ahc, WAITING_SCBH, SCB_LIST_NULL); Index: i386/scsi/aic7xxx.h =================================================================== RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.h,v retrieving revision 1.41 diff -c -r1.41 aic7xxx.h *** aic7xxx.h 1997/06/27 19:39:20 1.41 --- aic7xxx.h 1997/08/12 04:36:46 *************** *** 265,270 **** --- 265,271 ---- * waiting for space in the QINFIFO. */ u_int8_t activescbs; + u_int8_t cmdoutcnt; u_int16_t needsdtr_orig; /* Targets we initiate sync neg with */ u_int16_t needwdtr_orig; /* Targets we initiate wide neg with */ u_int16_t needsdtr; /* Current list of negotiated targets */ From owner-freebsd-current Mon Aug 11 23:00:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA02135 for current-outgoing; Mon, 11 Aug 1997 23:00:33 -0700 (PDT) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02129 for ; Mon, 11 Aug 1997 23:00:28 -0700 (PDT) Received: from pauling.salk.edu (pauling [198.202.70.108]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id XAA23307; Mon, 11 Aug 1997 23:00:25 -0700 (PDT) Date: Mon, 11 Aug 1997 23:00:22 -0700 (PDT) From: Tom Bartol To: Kenneth Merry cc: current@FreeBSD.ORG Subject: Re: Jerky mouse motion in -current In-Reply-To: <199708120220.UAA02043@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Great! Thanks for the "option" info. We'll be rootin' for you, John!! Tom On Mon, 11 Aug 1997, Kenneth Merry wrote: > Tom Bartol wrote... > > Is anyone else out there experiencing very jerky mouse motion under slight > > load (i.e. compiling a small program) using X and -current built early > > 8/11? Could this be a side effect of the new scheduling policy that John > > Dyson committed last night? > > Put this in your config file: > > options NO_SCHEDULE_MODS > > I had the same problem, and John says he'll look into it.. That > define will disable the scheduling mods; it brings interactive performance > under load back to normal for me. > > Ken > -- > Kenneth Merry > ken@plutotech.com > From owner-freebsd-current Mon Aug 11 23:05:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA02529 for current-outgoing; Mon, 11 Aug 1997 23:05:14 -0700 (PDT) Received: from dog.farm.org ([209.1.236.251]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02519 for ; Mon, 11 Aug 1997 23:05:06 -0700 (PDT) Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id XAA09369; Mon, 11 Aug 1997 23:06:38 -0700 (PDT) Date: Mon, 11 Aug 1997 23:06:38 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199708120606.XAA09369@dog.farm.org> To: jwd@unx.sas.com (John W. DeBoskey) Cc: freebsd-current@freebsd.org Subject: Re: nfs v3 & network appliance Newsgroups: cs-monolit.gated.lists.freebsd.current Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199708111810.AA02182@iluvatar.unx.sas.com> you wrote: > I have a copy of the latest snap up and running. Using nfs to > access our v2 nfs servers works like a champ. However, trying to > access a network appliance nfs fileserver which speaks v3 locks > up tight. > Does anyone have any ideas (or comments) that I might try? Has > anyone actually used -current against a netapp fileserver? I have used different vintages of 2.2 branch, and it stopped working around October (not very sure, but NFSv3 is broken in 2.2.1 and later; maybe it was fixed very recently). No idea about current, but I expect it to be in the same stage. The quick test is rm -rf big directory structure (like /sys tree). We run F330 with 4.1c (tried with several versions starting with 4.0 betas). Try disabling tcp mounts (if you enable them on a client); NetApp claim a bug in v3/TCP. -- "Now is the time for the quick brown fox to jump over the moon." - rblander@undergrad.math.uwaterloo.ca From owner-freebsd-current Tue Aug 12 01:34:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA10135 for current-outgoing; Tue, 12 Aug 1997 01:34:00 -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 BAA10130 for ; Tue, 12 Aug 1997 01:33:57 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id BAA00242 for ; Tue, 12 Aug 1997 01:33:56 -0700 (PDT) Message-Id: <199708120833.BAA00242@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: current@FreeBSD.ORG Subject: SECOND POST: bt848 broken on current Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Aug 1997 01:33:55 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Curious, is anyone able to run a matrox meteor with a recent kernel? >From a kernel perpective the bt848 and the meteor behave pretty much the same. I am pretty sure that the problems that I having has got to be related to either the PCI interface or vm page allocation. The exact the same driver has work pretty much earlier on the year so something changed in the kernel recently which broke the Bt848 driver. continous stat e001200 PC 1000000 continous stat e001204 PC 1000000 The value PC is supposed to be the address of where the bt848 is executing the program and it looks like the card is failing to read its program residing on the host or the PCI latency is too long. Tnks, Amancio From owner-freebsd-current Tue Aug 12 02:37:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA12831 for current-outgoing; Tue, 12 Aug 1997 02:37:39 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA12802 for ; Tue, 12 Aug 1997 02:37:22 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id JAA12456 for current@FreeBSD.org; Tue, 12 Aug 1997 09:00:26 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.6) id IAA01929; Tue, 12 Aug 1997 08:56:30 +0200 (CEST) Message-ID: <19970812085630.29536@klemm.gtn.com> Date: Tue, 12 Aug 1997 08:56:30 +0200 From: Andreas Klemm To: current@FreeBSD.org Subject: SMP machine runs really slow, last kernel changes ??? Reply-To: andreas.klemm@wup.de, andreas@klemm.gtn.com, current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi ! My current kernel: FreeBSD 3.0-CURRENT #0: Mon Aug 11 07:56:36 CEST 1997 root@titan.klemm.gtn.com:/local/sys.bisdn/compile/BISDNSMP Since this morning I noticed, that my machine is really slow. I notoced this when I restarted my two rsa crack processes which are running with a nice level of 10. Never saw this before the last weeks under exactly the same circumstances. Andreas /// -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Tue Aug 12 03:33:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA14808 for current-outgoing; Tue, 12 Aug 1997 03:33:33 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA14803 for ; Tue, 12 Aug 1997 03:33:27 -0700 (PDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel1.hp.com (8.8.6/8.8.5) with ESMTP id DAA01216 for ; Tue, 12 Aug 1997 03:33:22 -0700 (PDT) Message-Id: <199708121033.DAA01216@palrel1.hp.com> Received: from localhost by postbox.india.hp.com with ESMTP (1.39.111.2/16.2) id AA285601868; Tue, 12 Aug 1997 16:01:08 +0530 To: freebsd-current@freebsd.org Subject: src-cur.3000xEmpty.gz corrupt? Date: Tue, 12 Aug 1997 16:01:08 +0530 From: A Joseph Koshy Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Has anyone else seen the following corruption in src-cur.3000xEmpty.gz? (foo) $ ctm -cvvvvvvvv src-cur.3000xEmpty.gz ... lots of output deleted ... FM d01(32) 2(32)<900> 3(32)<900> 4(32)<644> 505(32) 6(10)<61087> 7(10)FileData wasn't followed by a newline. Fatal error. (/usr/src/usr.sbin/ctm/ctm/ctm_input.c:100) src-cur.3000xEmpty.gz Fatal error: Corrupt patch. Exit(65) (foo) $ Regards, Koshy My Personal Opinions Only. From owner-freebsd-current Tue Aug 12 04:56:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA17700 for current-outgoing; Tue, 12 Aug 1997 04:56:03 -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 EAA17686 for ; Tue, 12 Aug 1997 04:55:59 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id NAA02332 for current@freebsd.org; Tue, 12 Aug 1997 13:56:17 +0200 (MEST) From: Søren Schmidt Message-Id: <199708121156.NAA02332@sos.freebsd.dk> Subject: Error in sleep ! To: current@freebsd.org (FreeBSD current) Date: Tue, 12 Aug 1997 13:56:17 +0200 (MEST) 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-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed sleep is"broken in current.. Run the little program at the end, and notice that the program exits the sleep call prematurely if a signal is catched. The remaining sleep period is not resumed after the signal.. This works as expected on 2.2.1 and the 10 or so other platforms I've tested sofar... Peter ?? #include myfunc() { printf("signal!\n"); } main() { signal(SIGINT, myfunc); printf("running\n"); sleep(20); printf("stopping\n"); } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Aug 12 07:12:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA23733 for current-outgoing; Tue, 12 Aug 1997 07:12:49 -0700 (PDT) Received: from cwsys.cwent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23709; Tue, 12 Aug 1997 07:12:36 -0700 (PDT) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.7/8.6.10) id HAA01007; Tue, 12 Aug 1997 07:12:21 -0700 (PDT) Message-Id: <199708121412.HAA01007@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd001003; Tue Aug 12 14:12:14 1997 Reply-to: cy@uumail.gov.bc.ca X-Mailer: MH To: dg@root.com cc: Sean Eric Fagan , current@freebsd.org, security@freebsd.org Subject: Re: procfs patch In-reply-to: Your message of "Mon, 11 Aug 1997 02:53:05 PDT." <199708110953.CAA12034@implode.root.com> Date: Tue, 12 Aug 1997 07:12:13 -0700 From: Cy Schubert Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >+ /* > >+ * XXX > >+ * We need to check for KMEM_GROUP because ps is sgid kmem; > >+ * not allowing it here causes ps to not work properly. Arguably, > >+ * this is a bug with what ps does. We only need to do this > >+ * for Pmem nodes, and only if it's reading. This is still not > >+ * good, as it may still be possible to grab illicit data if > >+ * a process somehow gets to be KMEM_GROUP. Note that this also > >+ * means that KMEM_GROUP can't change without editing procfs.h! > >+ * All in all, quite yucky. > >+ */ > >+ > >+ if (!CHECKIO(curp, p) && > >+ ((curp->p_cred->pc_ucred->cr_gid != KMEM_GROUP) && > >+ (uio->uio_rw != UIO_READ)) > >+ return EPERM; > > If I read this right, you allow reads, correct? This would allow access to > potentially sensitive information in the setuid process. If the above is > changed to fail no matter what the operation, I think your fix should be > okay. All this patch does, in addition to allowing the "standard" access list access, is allow KMEM_GROUP read access, so IMHO it's almost perfect. Could this be controllable via sysctl, which would be used at boot time with a one-line awk script to get kmem's gid and poke it into the kernel. If this is too risky, e.g. opens up a security hole that could be exploited in another way, we could make this definition, and others like it, as options in the kernel config file, thus allowing the values of special UID's and GID's to be configurable. Any thoughts? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca cy@uumail.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-current Tue Aug 12 07:39:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA25119 for current-outgoing; Tue, 12 Aug 1997 07:39:37 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA25107 for ; Tue, 12 Aug 1997 07:39:30 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id SAA21021; Tue, 12 Aug 1997 18:39:19 +0400 (MSD) Date: Tue, 12 Aug 1997 18:39:14 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: FreeBSD current Subject: Re: Error in sleep ! In-Reply-To: <199708121156.NAA02332@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Søren Schmidt wrote: > I've noticed sleep is"broken in current.. > Run the little program at the end, and notice that the program exits > the sleep call prematurely if a signal is catched. The remaining > sleep period is not resumed after the signal.. > This works as expected on 2.2.1 and the 10 or so other platforms > I've tested sofar... Hmm. Sleep supposed to exit on _any_ signal per POSIX. Where you find 10 platforms which breaks this rule? -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 07:51:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA25874 for current-outgoing; Tue, 12 Aug 1997 07:51:13 -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 HAA25853; Tue, 12 Aug 1997 07:51: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 IAA15534; Tue, 12 Aug 1997 08:50:58 -0600 (MDT) Message-Id: <199708121450.IAA15534@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 cc: current@FreeBSD.org, stable@FreeBSD.org Subject: Re: Possible aic7xxx fix. In-reply-to: Your message of "Mon, 11 Aug 1997 22:48:26 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Aug 1997 08:51:00 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk There was a small bug in the last patch I sent out. Please try this one instead. Thanks to Tor Egge for pointing out the problem. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== Index: dev/aic7xxx/aic7xxx.reg =================================================================== RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.reg,v retrieving revision 1.4 diff -c -r1.4 aic7xxx.reg *** aic7xxx.reg 1997/06/27 19:38:39 1.4 --- aic7xxx.reg 1997/08/12 14:25:35 *************** *** 1079,1084 **** --- 1079,1099 ---- CUR_SCBID { size 1 } + /* + * Running count of commands placed in + * the QOUTFIFO. This is cleared by the + * kernel driver every FIFODEPTH commands. + */ + CMDOUTCNT { + size 1 + } + /* + * Maximum number of entries allowed in + * the QOUT/INFIFO. + */ + FIFODEPTH { + size 1 + } ARG_1 { size 1 mask SEND_MSG 0x80 Index: dev/aic7xxx/aic7xxx.seq =================================================================== RCS file: /usr/cvs/src/sys/dev/aic7xxx/aic7xxx.seq,v retrieving revision 1.74 diff -c -r1.74 aic7xxx.seq *** aic7xxx.seq 1997/06/27 19:38:42 1.74 --- aic7xxx.seq 1997/08/12 14:25:35 *************** *** 643,648 **** --- 643,657 ---- complete: /* Post the SCB and issue an interrupt */ + .if ( SCB_PAGING ) + /* + * Spin loop until there is space + * in the QOUTFIFO. + */ + mov A, FIFODEPTH; + cmp CMDOUTCNT, A je .; + inc CMDOUTCNT; + .endif mov QOUTFIFO,SCB_TAG; mvi INTSTAT,CMDCMPLT; test SCB_CONTROL, ABORT_SCB jz dma_next_scb; Index: i386/scsi/aic7xxx.c =================================================================== RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.c,v retrieving revision 1.120 diff -c -r1.120 aic7xxx.c *** aic7xxx.c 1997/07/20 16:21:34 1.120 --- aic7xxx.c 1997/08/12 14:42:25 *************** *** 784,789 **** --- 784,802 ---- int_cleared = 0; while (qoutcnt = (ahc_inb(ahc, QOUTCNT) & ahc->qcntmask)) { + if ((ahc->flags & AHC_PAGESCBS) != 0) { + ahc->cmdoutcnt += qoutcnt; + if (ahc->cmdoutcnt >= ahc->qfullcount) { + /* + * Since paging only occurs on + * aic78X0 chips, we can use + * Auto Access Pause to clear + * the command count. + */ + ahc_outb(ahc, CMDOUTCNT, 0); + ahc->cmdoutcnt = 0; + } + } for (; qoutcnt > 0; qoutcnt--) { scb_index = ahc_inb(ahc, QOUTFIFO); scb = ahc->scb_data->scbarray[scb_index]; *************** *** 2305,2310 **** --- 2318,2326 ---- * their QCount registers. */ ahc_outb(ahc, QCNTMASK, ahc->qcntmask); + + ahc_outb(ahc, FIFODEPTH, ahc->qfullcount); + ahc_outb(ahc, CMDOUTCNT, 0); /* We don't have any waiting selections */ ahc_outb(ahc, WAITING_SCBH, SCB_LIST_NULL); Index: i386/scsi/aic7xxx.h =================================================================== RCS file: /usr/cvs/src/sys/i386/scsi/aic7xxx.h,v retrieving revision 1.41 diff -c -r1.41 aic7xxx.h *** aic7xxx.h 1997/06/27 19:39:20 1.41 --- aic7xxx.h 1997/08/12 14:25:36 *************** *** 265,270 **** --- 265,271 ---- * waiting for space in the QINFIFO. */ u_int8_t activescbs; + u_int8_t cmdoutcnt; u_int16_t needsdtr_orig; /* Targets we initiate sync neg with */ u_int16_t needwdtr_orig; /* Targets we initiate wide neg with */ u_int16_t needsdtr; /* Current list of negotiated targets */ From owner-freebsd-current Tue Aug 12 08:47:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA29594 for current-outgoing; Tue, 12 Aug 1997 08:47:03 -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 IAA29585 for ; Tue, 12 Aug 1997 08:46:58 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id RAA00378; Tue, 12 Aug 1997 17:46:51 +0200 (MEST) From: Søren Schmidt Message-Id: <199708121546.RAA00378@sos.freebsd.dk> Subject: Re: Error in sleep ! In-Reply-To: from "[______ ______]" at "Aug 12, 97 06:39:14 pm" To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 17:46:51 +0200 (MEST) Cc: current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to [______ ______] who wrote: [Charset KOI8-R unsupported, filtering to ASCII...] > On Tue, 12 Aug 1997, S_ren Schmidt wrote: > > > I've noticed sleep is"broken in current.. > > Run the little program at the end, and notice that the program exits > > the sleep call prematurely if a signal is catched. The remaining > > sleep period is not resumed after the signal.. > > This works as expected on 2.2.1 and the 10 or so other platforms > > I've tested sofar... > > Hmm. Sleep supposed to exit on _any_ signal per POSIX. Where you find > 10 platforms which breaks this rule? Hmm, we don't even use it correctly ourselves, check /bin/sleep !! I have the fear that it also is the case in other places. I've checked one more platform, SVR4.2MP it behaves like ours, but they have fixed their /bin/sleep :) How on earth did POSIX come up with that behavior ?? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Aug 12 09:10:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01200 for current-outgoing; Tue, 12 Aug 1997 09:10:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA01192 for ; Tue, 12 Aug 1997 09:10:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA19476; Tue, 12 Aug 1997 10:10:12 -0600 (MDT) Message-Id: <199708121610.KAA19476@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: andreas.klemm@wup.de, andreas@klemm.gtn.com, current@FreeBSD.ORG Subject: Re: SMP machine runs really slow, last kernel changes ??? In-reply-to: Your message of "Tue, 12 Aug 1997 08:56:30 +0200." <19970812085630.29536@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Aug 1997 10:10:12 -0600 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I don't *think* its the SMP code, my test machines run fine here. I would suspect an interaction with something else committed recently. You might try undefing PEND_INTS in smptests.h, thats the only thing changing recently. Anyone else see a slowdown? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Tue Aug 12 09:39:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA02998 for current-outgoing; Tue, 12 Aug 1997 09:39:22 -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 JAA02993 for ; Tue, 12 Aug 1997 09:39:20 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA25574; Tue, 12 Aug 1997 09:33:36 -0700 From: Terry Lambert Message-Id: <199708121633.JAA25574@phaeton.artisoft.com> Subject: Re: Error in sleep ! To: sos@sos.freebsd.dk (Søren Schmidt) Date: Tue, 12 Aug 1997 09:33:36 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: <199708121156.NAA02332@sos.freebsd.dk> from "Søren Schmidt" at Aug 12, 97 01:56:17 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I've noticed sleep is"broken in current.. > Run the little program at the end, and notice that the program exits=20 > the sleep call prematurely if a signal is catched. The remaining > sleep period is not resumed after the signal.. > This works as expected on 2.2.1 and the 10 or so other platforms > I've tested sofar... Type "man siginterrupt". 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-current Tue Aug 12 11:16:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08448 for current-outgoing; Tue, 12 Aug 1997 11:16:07 -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 LAA08437 for ; Tue, 12 Aug 1997 11:16:03 -0700 (PDT) Received: (qmail 593 invoked by uid 1000); 12 Aug 1997 18:16:20 -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: Tue, 12 Aug 1997 11:16:20 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: freebsd-current@freebsd.org Subject: Floating Point Exception in make release Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In -current (as of the 12th of August, dumps core in make release, cd /whereever_it_builds/usr/src/release/sysinstall chroot /whereever_it_builds make That's it. Simon From owner-freebsd-current Tue Aug 12 11:25:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08954 for current-outgoing; Tue, 12 Aug 1997 11:25:43 -0700 (PDT) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA08941 for ; Tue, 12 Aug 1997 11:25:17 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id MAA22693; Tue, 12 Aug 1997 12:24:36 -0600 (MDT) From: Kenneth Merry Message-Id: <199708121824.MAA22693@pluto.plutotech.com> Subject: Re: SMP machine runs really slow, last kernel changes ??? In-Reply-To: <199708121610.KAA19476@Ilsa.StevesCafe.com> from Steve Passe at "Aug 12, 97 10:10:12 am" To: smp@csn.net (Steve Passe) Date: Tue, 12 Aug 1997 12:24:36 -0600 (MDT) Cc: andreas.klemm@wup.de, andreas@klemm.gtn.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > Hi, > > I don't *think* its the SMP code, my test machines run fine here. I would > suspect an interaction with something else committed recently. You might > try undefing PEND_INTS in smptests.h, thats the only thing changing recently. > > Anyone else see a slowdown? Actually, I think it may have to do with the recent scheduling changes. I've seen slowdowns with both UP and SMP -current machines under load. Putting this in my config file fixes things: options NO_SCHEDULE_MODS Andreas mentioned that he didn't see the slowdown until he cranked up the two RSA crack processes. So I think it's probably the same problem.. John knows about it, and said that he would work on a fix. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-current Tue Aug 12 11:33:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA09816 for current-outgoing; Tue, 12 Aug 1997 11:33:48 -0700 (PDT) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA09806 for ; Tue, 12 Aug 1997 11:33:45 -0700 (PDT) From: dyson@iquest.net Received: (qmail 20461 invoked from network); 12 Aug 1997 18:33:31 -0000 Received: from iquest7.iquest.net (206.53.230.110) by iquest3.iquest.net with SMTP; 12 Aug 1997 18:33:31 -0000 Received: (qmail 27735 invoked by uid 4420); 12 Aug 1997 18:33:29 -0000 Message-ID: <19970812183329.27734.qmail@iquest7.iquest.net> Subject: Re: SMP machine runs really slow, last kernel changes ??? To: andreas.klemm@wup.de, andreas@klemm.gtn.com, current@FreeBSD.ORG Date: Tue, 12 Aug 1997 13:33:29 -0500 (EST) Cc: current@FreeBSD.ORG In-Reply-To: <19970812085630.29536@klemm.gtn.com> from "Andreas Klemm" at Aug 12, 97 08:56:30 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi ! > > My current kernel: > FreeBSD 3.0-CURRENT #0: Mon Aug 11 07:56:36 CEST 1997 > root@titan.klemm.gtn.com:/local/sys.bisdn/compile/BISDNSMP > > Since this morning I noticed, that my machine is really > slow. I notoced this when I restarted my two rsa crack > processes which are running with a nice level of 10. > > Never saw this before the last weeks under exactly the > same circumstances. > > Andreas /// > > -- > Andreas Klemm | klemm.gtn.com - powered by > Symmetric MultiProcessor FreeBSD > http://www.freebsd.org/~fsmp/SMP/SMP.html > http://www.freebsd.org/~fsmp/SMP/benches.html > From owner-freebsd-current Tue Aug 12 11:33:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA09826 for current-outgoing; Tue, 12 Aug 1997 11:33:49 -0700 (PDT) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA09812 for ; Tue, 12 Aug 1997 11:33:46 -0700 (PDT) From: dyson@iquest.net Received: (qmail 20454 invoked from network); 12 Aug 1997 18:33:31 -0000 Received: from iquest7.iquest.net (206.53.230.110) by iquest3.iquest.net with SMTP; 12 Aug 1997 18:33:31 -0000 Received: (qmail 27735 invoked by uid 4420); 12 Aug 1997 18:33:29 -0000 Message-ID: <19970812183329.27734.qmail@iquest7.iquest.net> Subject: Re: SMP machine runs really slow, last kernel changes ??? To: andreas.klemm@wup.de, andreas@klemm.gtn.com, current@FreeBSD.ORG Date: Tue, 12 Aug 1997 13:33:29 -0500 (EST) Cc: current@FreeBSD.ORG In-Reply-To: <19970812085630.29536@klemm.gtn.com> from "Andreas Klemm" at Aug 12, 97 08:56:30 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi ! > > My current kernel: > FreeBSD 3.0-CURRENT #0: Mon Aug 11 07:56:36 CEST 1997 > root@titan.klemm.gtn.com:/local/sys.bisdn/compile/BISDNSMP > > Since this morning I noticed, that my machine is really > slow. I notoced this when I restarted my two rsa crack > processes which are running with a nice level of 10. > > Never saw this before the last weeks under exactly the > same circumstances. > > Andreas /// > > -- > Andreas Klemm | klemm.gtn.com - powered by > Symmetric MultiProcessor FreeBSD > http://www.freebsd.org/~fsmp/SMP/SMP.html > http://www.freebsd.org/~fsmp/SMP/benches.html > From owner-freebsd-current Tue Aug 12 11:35:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA10081 for current-outgoing; Tue, 12 Aug 1997 11:35:24 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA10058 for ; Tue, 12 Aug 1997 11:35:16 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id WAA26135; Tue, 12 Aug 1997 22:35:09 +0400 (MSD) Date: Tue, 12 Aug 1997 22:35:07 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: current@FreeBSD.ORG Subject: Re: Error in sleep ! In-Reply-To: <199708121546.RAA00378@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Søren Schmidt wrote: > Hmm, we don't even use it correctly ourselves, check /bin/sleep !! > I have the fear that it also is the case in other places. What do you mean exactly? I just look at /bin/sleep and not find any non-POSIX behaviour... > How on earth did POSIX come up with that behavior ?? It was even in early POSIX.1 -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 12:08:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA11765 for current-outgoing; Tue, 12 Aug 1997 12:08:56 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11750 for ; Tue, 12 Aug 1997 12:08:52 -0700 (PDT) From: John Dyson Received: (from dyson@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA19009 for current@freebsd.org; Tue, 12 Aug 1997 12:08:48 -0700 (PDT) Date: Tue, 12 Aug 1997 12:08:48 -0700 (PDT) Message-Id: <199708121908.MAA19009@freefall.freebsd.org> To: current@FreeBSD.ORG Subject: Backed out 1/2 of the scheduling improvements Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Let me know how they work. Feel free to call me at 1-415-631-4044 in the Bay area for quicker feedback. John From owner-freebsd-current Tue Aug 12 12:36:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA13610 for current-outgoing; Tue, 12 Aug 1997 12:36:12 -0700 (PDT) Received: from lamb.sas.com (uucp@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA13605 for ; Tue, 12 Aug 1997 12:36:07 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA11277; Tue, 12 Aug 1997 15:35:59 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA16125; Tue, 12 Aug 1997 15:35:49 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA08461; Tue, 12 Aug 1997 15:35:49 -0400 Message-Id: <199708121935.AA08461@iluvatar.unx.sas.com> Subject: NFS V3 hangs To: current@freebsd.org Date: Tue, 12 Aug 1997 15:35:48 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have the latest -current snap loaded. I am using NFS to access a network appliance fileserver (which supports V3). The response time of doing an ls is non-trivial. cd targetdir (which contains 686 files) time ls returns 0.0u 0.0s 16:40.49 0.0% 704+1024k 0+0io 0pf+0w Ok, so I umount the directory and remount with the -2 option: cd targetdir (which contains 686 files) time ls returns 0.0u 0.0s 0:02.84 0.7% 78+170k 0+0io 0pf+0w Is this a known bug? And if not, what can I do to help solve the problem? I would really like to be able to use NFS V3 in this situation. FWIW: mount_nfs -U doesn't make any difference. Thanks! John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Tue Aug 12 12:48:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA14402 for current-outgoing; Tue, 12 Aug 1997 12:48:32 -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 MAA14395 for ; Tue, 12 Aug 1997 12:48:28 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id VAA01292; Tue, 12 Aug 1997 21:48:37 +0200 (MEST) From: Søren Schmidt Message-Id: <199708121948.VAA01292@sos.freebsd.dk> Subject: Re: Error in sleep ! In-Reply-To: from "[______ ______]" at "Aug 12, 97 10:35:07 pm" To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 21:48:37 +0200 (MEST) Cc: current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to [______ ______] who wrote: [Charset KOI8-R unsupported, filtering to ASCII...] > On Tue, 12 Aug 1997, S_ren Schmidt wrote: > > > Hmm, we don't even use it correctly ourselves, check /bin/sleep !! > > I have the fear that it also is the case in other places. > > What do you mean exactly? I just look at /bin/sleep and not find > any non-POSIX behaviour... Well to quote sleep(1): The sleep command suspends execution for a minimum of seconds. sleep is used to schedule the execution of other commands (see EXAMPLES below). The sleep utility exits with one of the following values: 0 On successful completion, or if the signal SIGALRM was received. >0 An error occurred. This is not how our sleep(1) functions!, it'll exit on the first signal it gets, because of the change in sleep(3)'s behavior.... > > How on earth did POSIX come up with that behavior ?? > > It was even in early POSIX.1 That doesn't mean they are right :) Now one has to encapsulte sleep(3) in a while loop to get it to actually sleep the specified time, thats plain an simple stupid, and also poses a risk for busy looping, a complete no-no i an *IX system... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Aug 12 13:13:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA16564 for current-outgoing; Tue, 12 Aug 1997 13:13:48 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA16551 for ; Tue, 12 Aug 1997 13:13:45 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id AAA27653; Wed, 13 Aug 1997 00:13:38 +0400 (MSD) Date: Wed, 13 Aug 1997 00:13:36 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: current@FreeBSD.ORG Subject: Re: Error in sleep ! In-Reply-To: <199708121948.VAA01292@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Søren Schmidt wrote: > Well to quote sleep(1): > The sleep command suspends execution for a minimum of seconds. sleep is > used to schedule the execution of other commands (see EXAMPLES below). > > The sleep utility exits with one of the following values: > > 0 On successful completion, or if the signal SIGALRM was received. > > >0 An error occurred. > > This is not how our sleep(1) functions!, it'll exit on the first signal > it gets, because of the change in sleep(3)'s behavior.... Your quote says nothing about /bin/sleep signals handling, only about exit codes. When signal != SIGALRM comes sleep exit with exit code >=0 (An error occured) Here is quote from Solaris manpage (their manpages usually better than ours :-) SunOS 5.5.1 Last change: 1 Feb 1995 1 NOTES If the sleep utility receives a SIGALRM signal, one of the following actions will be taken: +o Terminate normally with a zero exit status. +o Effectively ignore the signal. The sleep utility will take the standard action for all other signals. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Now one has to encapsulte sleep(3) in a while loop to get it to > actually sleep the specified time, thats plain an simple stupid, > and also poses a risk for busy looping, a complete no-no i an > *IX system... You can complain to POSIX commetee. BTW, it is strange for me 1) Why sleep must be different than, say, cat which exits on signal coming... 2) Why you send signals to sleep, if you want to sleep specified time. Even if you do such nasty things, use 'trap' to block signals before sleep. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 13:14:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA16591 for current-outgoing; Tue, 12 Aug 1997 13:14:04 -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 NAA16582 for ; Tue, 12 Aug 1997 13:14:00 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA01401; Tue, 12 Aug 1997 22:13:16 +0200 (MEST) From: Søren Schmidt Message-Id: <199708122013.WAA01401@sos.freebsd.dk> Subject: Re: Error in sleep ! In-Reply-To: <199708121633.JAA25574@phaeton.artisoft.com> from Terry Lambert at "Aug 12, 97 09:33:36 am" To: terry@lambert.org (Terry Lambert) Date: Tue, 12 Aug 1997 22:13:16 +0200 (MEST) Cc: current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Terry Lambert who wrote: > > I've noticed sleep is"broken in current.. > > Run the little program at the end, and notice that the program exits=20 > > the sleep call prematurely if a signal is catched. The remaining > > sleep period is not resumed after the signal.. > > This works as expected on 2.2.1 and the 10 or so other platforms > > I've tested sofar... > > Type "man siginterrupt". Hmm, then that man page is in error too in -current :( -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Aug 12 13:18:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA16898 for current-outgoing; Tue, 12 Aug 1997 13:18:28 -0700 (PDT) Received: from veda.is (root@veda.is [193.4.230.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA16891 for ; Tue, 12 Aug 1997 13:18:21 -0700 (PDT) Received: from ubiq.veda.is (adam@ubiq.veda.is [193.4.230.60]) by veda.is (8.8.7/8.8.5) with ESMTP id UAA12102; Tue, 12 Aug 1997 20:18:03 GMT From: Adam David Received: (from adam@localhost) by ubiq.veda.is (8.8.7/8.8.5) id UAA00721; Tue, 12 Aug 1997 20:18:00 GMT Date: Tue, 12 Aug 1997 20:18:00 GMT Message-Id: <199708122018.UAA00721@ubiq.veda.is> To: taavi@uninet.ee (Taavi Talvik) Cc: freebsd-current@freebsd.org Subject: Re: kernel with symbol table.. References: X-Newsreader: NN version 6.5.0 #2 (NOV) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I have configred kernel with "config -g BLAAH". However, >when startig up it hangs after messages: >Preserving kernel symbol table... >Real memory reported by BIOS != ... You need to strip -d the kernel before installing it. You only need the symbols for actual debug sessions, and there you would load them from the unstripped copy. Alternatively you could buy lots of memory and waste it. ;) There is a section on debugging kernels in the handbook. -- Adam David From owner-freebsd-current Tue Aug 12 14:05:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20214 for current-outgoing; Tue, 12 Aug 1997 14:05:20 -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 OAA20195 for ; Tue, 12 Aug 1997 14:04:57 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id XAA01981; Tue, 12 Aug 1997 23:05:08 +0200 (MEST) From: Søren Schmidt Message-Id: <199708122105.XAA01981@sos.freebsd.dk> Subject: Re: Error in sleep ! In-Reply-To: from "[______ ______]" at "Aug 13, 97 00:13:36 am" To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 23:05:08 +0200 (MEST) Cc: current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to [______ ______] who wrote: [Charset KOI8-R unsupported, filtering to ASCII...] > On Tue, 12 Aug 1997, S_ren Schmidt wrote: > > > Well to quote sleep(1): > > The sleep command suspends execution for a minimum of seconds. sleep is > > used to schedule the execution of other commands (see EXAMPLES below). > > > > The sleep utility exits with one of the following values: > > > > 0 On successful completion, or if the signal SIGALRM was received. > > > > >0 An error occurred. > > > > This is not how our sleep(1) functions!, it'll exit on the first signal > > it gets, because of the change in sleep(3)'s behavior.... > > Your quote says nothing about /bin/sleep signals handling, only about exit > codes. When signal != SIGALRM comes sleep exit with exit code >=0 (An > error occured) Yes but thats not documented anywhere... > > Now one has to encapsulte sleep(3) in a while loop to get it to > > actually sleep the specified time, thats plain an simple stupid, > > and also poses a risk for busy looping, a complete no-no i an > > *IX system... > > You can complain to POSIX commetee. BTW, it is strange for me > > 1) Why sleep must be different than, say, cat which exits on signal > coming... > 2) Why you send signals to sleep, if you want to sleep specified time. ARG! my gripe was with sleep(_3_), if my process hangs in a sleep (for good reason), and a signal to the process comes along, I want the handler called, and then the sleep should continue. With the new functionality this fails, and I have to put the sleep call in a loop where it gets reiterated until the sleeping period actually has expired. This strikes me as illogical and not very elegant, be it posix or not... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Tue Aug 12 14:13:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20922 for current-outgoing; Tue, 12 Aug 1997 14:13:01 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20910 for ; Tue, 12 Aug 1997 14:12:57 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA29786; Wed, 13 Aug 1997 01:12:45 +0400 (MSD) Date: Wed, 13 Aug 1997 01:12:44 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: Terry Lambert , current@FreeBSD.ORG Subject: Re: Error in sleep ! In-Reply-To: <199708122013.WAA01401@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Søren Schmidt wrote: > In reply to Terry Lambert who wrote: > > > I've noticed sleep is"broken in current.. > > > Run the little program at the end, and notice that the program exits=20 > > > the sleep call prematurely if a signal is catched. The remaining > > > sleep period is not resumed after the signal.. > > > This works as expected on 2.2.1 and the 10 or so other platforms > > > I've tested sofar... > > > > Type "man siginterrupt". > > Hmm, then that man page is in error too in -current :( This man page have nothing common with sleep signals interruption which directly required by POSIX in any case. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 14:30:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22117 for current-outgoing; Tue, 12 Aug 1997 14:30:58 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA22110 for ; Tue, 12 Aug 1997 14:30:54 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA00190; Wed, 13 Aug 1997 01:30:44 +0400 (MSD) Date: Wed, 13 Aug 1997 01:30:43 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: =?KOI8-R?Q?S=F8ren_Schmidt?= cc: current@FreeBSD.ORG Subject: Re: Error in sleep ! In-Reply-To: <199708122105.XAA01981@sos.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Søren Schmidt wrote: > Yes but thats not documented anywhere... I just add a note to sleep.1 manpage. > ARG! my gripe was with sleep(_3_), if my process hangs in a sleep > (for good reason), and a signal to the process comes along, I want > the handler called, and then the sleep should continue. With the > new functionality this fails, and I have to put the sleep call in > a loop where it gets reiterated until the sleeping period actually > has expired. This strikes me as illogical and not very elegant, be > it posix or not... One small thing to consider: if sleep(3) will be uninterruptable, sleep(1) will be uninterruptable too (i.e. you'll can't break sleep(1) by pressing ^C), it broke sleep(1) POSIX requirement too: sleep(1) must do standard action on signals other than SIGALRM. Not breaking sleep(1) by ^C looks illogical and not very elegant too :-) For uninterrupted sleep you can use usleep(3) call in FreeBSD, since it isn't described by POSIX, it still remains uninterruptable by signals other than SIGALRM. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 14:41:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22859 for current-outgoing; Tue, 12 Aug 1997 14:41: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 OAA22847 for ; Tue, 12 Aug 1997 14:41:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA07747; Tue, 12 Aug 1997 14:35:24 -0700 From: Terry Lambert Message-Id: <199708122135.OAA07747@phaeton.artisoft.com> Subject: Re: Error in sleep ! To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 14:35:24 -0700 (MST) Cc: sos@sos.freebsd.dk, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 01:12: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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Type "man siginterrupt". > > > > Hmm, then that man page is in error too in -current :( > > This man page have nothing common with sleep signals interruption which > directly required by POSIX in any case. The man page is for the BSD'ism of "siginterrupt", which was introduced in Ultrix. By default, in traditional BSD, after a signal, the call was restarted. This man page is incorrect about the default for FreeBSD; so is the signal man page. However, the function operates as expected, and can turn on call restart. There are *also* POSIX mechanisms to turn on call restart on a per-signal basis (man sigaction; look for SA_RESTART). The difference is that historically BSD programs will expect the call to restart, and historically System V programs will expect the call to return EINTR (and the programmer to garbage up his code and his libc with a bazillion checks for EINTR that he really doesn't want to have to make). In BSD's 4.2 and prior (except Ultrix), the lack of a siginterrupt() was handled by setjmp() in the code and longjmp() in the handler to prevent call restart. This was usually used in combination with an alarm() call... mostly for things like device open() timeouts, etc.. One hopes to God that whoever turned on POSIX behaviour as the default patched each and every lib(3) call that is supposed to act atomic to correctly deal with idempotence across multiple system calls for a supposedly atomic operation (for example, an alarm firing and interrupting an opendir() operation with an allocation made, but the first getdents() not performed, etc.). Otherwise, we are just waiting for all hell to break loose... 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-current Tue Aug 12 14:56:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA23802 for current-outgoing; Tue, 12 Aug 1997 14:56:31 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA23792 for ; Tue, 12 Aug 1997 14:56:19 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id BAA00563; Wed, 13 Aug 1997 01:54:53 +0400 (MSD) Date: Wed, 13 Aug 1997 01:54:52 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Terry Lambert cc: sos@sos.freebsd.dk, current@FreeBSD.ORG Subject: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708122135.OAA07747@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Terry Lambert wrote: > > > > Type "man siginterrupt". > > > > > > Hmm, then that man page is in error too in -current :( > > > > This man page have nothing common with sleep signals interruption which > > directly required by POSIX in any case. Also all this stuff have no relations with sleep(3), one thing is unclear to me: > By default, in traditional BSD, after a signal, the call was > restarted. > > This man page is incorrect about the default for FreeBSD; so > is the signal man page. As I check, man page says that it will be restarted for FreeBSD too. What is incorrect here? I just check signal.c and see that SA_RESTART is set unless expicitly disabled by siginterrupt(3)... -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 15:05:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA24417 for current-outgoing; Tue, 12 Aug 1997 15:05: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 PAA24407 for ; Tue, 12 Aug 1997 15:05:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA07903; Tue, 12 Aug 1997 15:00:11 -0700 From: Terry Lambert Message-Id: <199708122200.PAA07903@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 15:00:11 -0700 (MST) Cc: terry@lambert.org, sos@sos.freebsd.dk, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 01:54:52 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > By default, in traditional BSD, after a signal, the call was > > restarted. > > > > This man page is incorrect about the default for FreeBSD; so > > is the signal man page. > > As I check, man page says that it will be restarted for FreeBSD too. > What is incorrect here? I just check signal.c and see that SA_RESTART > is set unless expicitly disabled by siginterrupt(3)... The claim is that FreeBSD defaults have been brought into concordance with POSIX. And the man pages have not been updated. To the original poster: The system call restart of a sleep(3) does *not* guarantee that the elapsed time is subtracted from the argument when the restart is initiated (ie: if you sleep for 2 of 3 seconds, get a signal, and restart, the restart will likely be for another 3 seconds -- not the remaining 1). So depending on this behaviour is probably an error, in any case. 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-current Tue Aug 12 15:16:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA25106 for current-outgoing; Tue, 12 Aug 1997 15:16:14 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25082 for ; Tue, 12 Aug 1997 15:16:06 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id CAA00887; Wed, 13 Aug 1997 02:14:43 +0400 (MSD) Date: Wed, 13 Aug 1997 02:14:42 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Terry Lambert cc: sos@sos.freebsd.dk, current@FreeBSD.ORG Subject: Re: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708122200.PAA07903@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Terry Lambert wrote: > The claim is that FreeBSD defaults have been brought into concordance > with POSIX. And the man pages have not been updated. What POSIX says exactly about siginterrupt(3) and restartable syscalls? I can't check this section right now... > To the original poster: > > The system call restart of a sleep(3) does *not* guarantee that the > elapsed time is subtracted from the argument when the restart is > initiated (ie: if you sleep for 2 of 3 seconds, get a signal, and > restart, the restart will likely be for another 3 seconds -- not > the remaining 1). So depending on this behaviour is probably an > error, in any case. I still not understand why you decide to connect restartable syscalls with sleep(3) implementation. Both old and new sleep(3) variants not depends on restartable syscalls. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 15:18:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA25270 for current-outgoing; Tue, 12 Aug 1997 15:18:09 -0700 (PDT) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25214; Tue, 12 Aug 1997 15:17:26 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id QAA28713; Tue, 12 Aug 1997 16:17:24 -0600 (MDT) From: Kenneth Merry Message-Id: <199708122217.QAA28713@pluto.plutotech.com> Subject: Re: Backed out 1/2 of the scheduling improvements In-Reply-To: <199708121908.MAA19009@freefall.freebsd.org> from John Dyson at "Aug 12, 97 12:08:48 pm" To: dyson@FreeBSD.ORG (John Dyson) Date: Tue, 12 Aug 1997 16:17:24 -0600 (MDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk John Dyson wrote... > > Let me know how they work. Feel free to call me at 1-415-631-4044 in the > Bay area for quicker feedback. I think that did the trick. :) I tried a kernel build with make -j 5, and things slowed down somewhat, but it wasn't anything like it was before.. (and I *did* take NO_SCHEDLUE_MODS out of my config file before trying the changes) Thanks, Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-current Tue Aug 12 15:20:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA25545 for current-outgoing; Tue, 12 Aug 1997 15:20:34 -0700 (PDT) Received: from helmholtz.salk.edu (helmholtz.salk.edu [198.202.70.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA25529; Tue, 12 Aug 1997 15:20:19 -0700 (PDT) Received: from pauling.salk.edu (pauling [198.202.70.108]) by helmholtz.salk.edu (8.7.5/8.7.3) with SMTP id PAA08881; Tue, 12 Aug 1997 15:20:11 -0700 (PDT) Date: Tue, 12 Aug 1997 15:20:10 -0700 (PDT) From: Tom Bartol To: John Dyson cc: current@FreeBSD.ORG Subject: Re: Backed out 1/2 of the scheduling improvements In-Reply-To: <199708121908.MAA19009@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yes, that seems much better now thankyou! Tom On Tue, 12 Aug 1997, John Dyson wrote: > > Let me know how they work. Feel free to call me at 1-415-631-4044 in the > Bay area for quicker feedback. > > John > From owner-freebsd-current Tue Aug 12 15:46:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA27526 for current-outgoing; Tue, 12 Aug 1997 15:46: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 PAA27502 for ; Tue, 12 Aug 1997 15:46:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA08551; Tue, 12 Aug 1997 15:40:08 -0700 From: Terry Lambert Message-Id: <199708122240.PAA08551@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 12 Aug 1997 15:40:07 -0700 (MST) Cc: terry@lambert.org, sos@sos.freebsd.dk, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 02:14:42 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The claim is that FreeBSD defaults have been brought into concordance > > with POSIX. And the man pages have not been updated. > > What POSIX says exactly about siginterrupt(3) and restartable syscalls? POSIX says that system calls will not be restarted by default (the historical System V behaviour for signals). Since siginterrupt isn't a POSIX function, POSIX says nothing about it. However, if a system claims to be a POSIX system, it must exhibit default POSIX behaviours. If FreeBSD has been updated to exhibit POSIX behaviour (the original poster was claiming it had been), then the signal and siginterrupt man pages, which claim historical BSD behaviour, are wrong. They should claim POSIX behaviour instead. In other words, if the default behaviour is BSD, the man pages are correct, and if the default behaviour is POSIX, the man pages are broken. > > To the original poster: > > > > The system call restart of a sleep(3) does *not* guarantee that the > > elapsed time is subtracted from the argument when the restart is > > initiated (ie: if you sleep for 2 of 3 seconds, get a signal, and > > restart, the restart will likely be for another 3 seconds -- not > > the remaining 1). So depending on this behaviour is probably an > > error, in any case. > > I still not understand why you decide to connect restartable syscalls with > sleep(3) implementation. Both old and new sleep(3) variants not depends on > restartable syscalls. By default, if you intentionally send a signal to sleep(1), then you exit the sigpause() that sleep(3) uses to implement the sleep (it is expecting SIGALRM, but *any* signal will wake it up. Even a signal whose sigaction is SIG_DFL). The problem is that if I send a normally ignored signal to sleep(1) after it goes to sleep but before the interval is expired, the sleep doesn't keep going. I don't know if restarting a shell sleep is really a big problem; the sending of signals seems like a non-op... unless he's doing ^T status reporting, maybe? Or resizing the window containing the shell? In any case, I'd say that there may be a problem in SIG_DFL delivery handling. I still don't have a good handle on exactly what he wants to have happen; I know the threads safe libc calls nanosleep() instead; I'm betting that he is notiing a discrepancy in the behaviour in sleep(1) because of a threaded libc, more than anything else? Anyway, this is too much time on this topic for me... 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-current Tue Aug 12 16:01:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA28608 for current-outgoing; Tue, 12 Aug 1997 16:01:06 -0700 (PDT) Received: from veda.is (root@veda.is [193.4.230.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA28593 for ; Tue, 12 Aug 1997 16:00:57 -0700 (PDT) Received: from ubiq.veda.is (adam@ubiq.veda.is [193.4.230.60]) by veda.is (8.8.7/8.8.5) with ESMTP id XAA00976 for ; Tue, 12 Aug 1997 23:00:50 GMT From: Adam David Received: (from adam@localhost) by ubiq.veda.is (8.8.7/8.8.5) id XAA01534 for freebsd-current@freebsd.org; Tue, 12 Aug 1997 23:00:48 GMT Message-Id: <199708122300.XAA01534@ubiq.veda.is> Subject: /etc/mail.rc To: freebsd-current@freebsd.org Date: Tue, 12 Aug 1997 23:00:47 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is it intentional that /etc/mail.rc is clobbered by make install? Is this consistent with the policy that nothing in /etc gets clobbered, except perhaps example files? -- Adam David From owner-freebsd-current Tue Aug 12 16:09:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29176 for current-outgoing; Tue, 12 Aug 1997 16:09:02 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29152 for ; Tue, 12 Aug 1997 16:08:52 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id DAA01687; Wed, 13 Aug 1997 03:07:29 +0400 (MSD) Date: Wed, 13 Aug 1997 03:07:28 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net Reply-To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Terry Lambert cc: sos@sos.freebsd.dk, current@FreeBSD.ORG Subject: Re: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708122240.PAA08551@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 12 Aug 1997, Terry Lambert wrote: > POSIX says that system calls will not be restarted by default (the > historical System V behaviour for signals). Could you please send exact quote just about this particular thing? Many times POSIX is very unclear or can be misinterpreted. > If FreeBSD has been updated to exhibit POSIX behaviour (the original > poster was claiming it had been), then the signal and siginterrupt > man pages, which claim historical BSD behaviour, are wrong. They > should claim POSIX behaviour instead. Currently siginterrupt and signal man pages says nothing about POSIX conformance, so manpages are right independently of how we interpretate POSIX. > > I still not understand why you decide to connect restartable syscalls with > > sleep(3) implementation. Both old and new sleep(3) variants not depends on > > restartable syscalls. > > The problem is that if I send a normally ignored signal to sleep(1) > after it goes to sleep but before the interval is expired, the > sleep doesn't keep going. POSIX says exactly that _any_ non-blocked and non-ignored signal should terminate sleep(3)/sleep(1) including default no-op signals like ^T, etc. Ignored or blocked signals not affects sleep(3)/sleep(1) doing in both old and new implementations since blocked mask passed to sigpause/signanosleep. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Aug 12 16:13:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29597 for current-outgoing; Tue, 12 Aug 1997 16:13:36 -0700 (PDT) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29592 for ; Tue, 12 Aug 1997 16:13:30 -0700 (PDT) Received: from rhiannon.scsn.net ([208.133.153.98]) by mail.scsn.net (Post.Office MTA v3.1 release PO203a ID# 0-32322U5000L100S10000) with ESMTP id AAA136 for ; Tue, 12 Aug 1997 19:15:05 -0400 Received: (from root@localhost) by rhiannon.scsn.net (8.8.7/8.8.5) id TAA01658; Tue, 12 Aug 1997 19:13:15 -0400 (EDT) Message-ID: <19970812191314.21220@scsn.net> Date: Tue, 12 Aug 1997 19:13:14 -0400 From: "Donald J. Maddox" To: current@FreeBSD.ORG Subject: CVSup Suddenly Coredumping Reply-To: dmaddox@scsn.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've been using CVSup to keep this machine -current for quite a while, and never saw this one before: If I run a CVSup now, it gets through the whole procedure up to the Apache changes, then I get this: ---------------------------------------------------------------------- *** *** runtime error: *** ASSERT failed *** file "../src/RCSDelta.m3", line 182 *** Aug 12 18:51:25 rhiannon /kernel: pid 1554 (cvsup), uid 0: exited on signal 6 (c ore dumped) Cleaning up... ---------------------------------------------------------------------- ???? From owner-freebsd-current Tue Aug 12 16:32:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA00936 for current-outgoing; Tue, 12 Aug 1997 16:32:50 -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 QAA00929 for ; Tue, 12 Aug 1997 16:32:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA09419; Tue, 12 Aug 1997 16:26:53 -0700 From: Terry Lambert Message-Id: <199708122326.QAA09419@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru Date: Tue, 12 Aug 1997 16:26:53 -0700 (MST) Cc: terry@lambert.org, sos@sos.freebsd.dk, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 03:07:28 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > POSIX says that system calls will not be restarted by default (the > > historical System V behaviour for signals). > > Could you please send exact quote just about this particular thing? > Many times POSIX is very unclear or can be misinterpreted. Sorry, I don't have the standard handy. General Rule of thumb: POSIX favors System V behaviour. > > If FreeBSD has been updated to exhibit POSIX behaviour (the original > > poster was claiming it had been), then the signal and siginterrupt > > man pages, which claim historical BSD behaviour, are wrong. They > > should claim POSIX behaviour instead. > > Currently siginterrupt and signal man pages says nothing about POSIX > conformance, so manpages are right independently of how we interpretate > POSIX. They say what the FreeBSD defaults are, and they are (probably) wrong. > POSIX says exactly that _any_ non-blocked and non-ignored signal should > terminate sleep(3)/sleep(1) including default no-op signals like ^T, etc. I think there is a difference between "masked" and "sa_handler == SIG_DFL" here. 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-current Tue Aug 12 18:47:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA08181 for current-outgoing; Tue, 12 Aug 1997 18:47:16 -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 SAA08172 for ; Tue, 12 Aug 1997 18:47:11 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.6/8.8.5) with ESMTP id SAA06915; Tue, 12 Aug 1997 18:47:07 -0700 (PDT) Message-Id: <199708130147.SAA06915@austin.polstra.com> To: dmaddox@scsn.net Subject: Re: CVSup Suddenly Coredumping In-Reply-To: <19970812191314.21220@scsn.net> References: <19970812191314.21220@scsn.net> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Tue, 12 Aug 1997 18:47:07 -0700 From: John Polstra Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <19970812191314.21220@scsn.net>, Donald J. Maddox wrote: > I've been using CVSup to keep this machine -current for quite a while, > and never saw this one before: If I run a CVSup now, it gets through > the whole procedure up to the Apache changes, then I get this: > > ---------------------------------------------------------------------- > > *** > *** runtime error: > *** ASSERT failed > *** file "../src/RCSDelta.m3", line 182 > *** Yes, see my recent posting to -hackers for the full explanation. Briefly, the RCS files in the repository were fiddled in unorthodox ways that confuse CVSup in checkout mode. To recover, you'll need to "rm -rf /usr/ports/www/apache-current" and then run CVSup again. 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-current Tue Aug 12 19:52:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA12963 for current-outgoing; Tue, 12 Aug 1997 19:52: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 TAA12956 for ; Tue, 12 Aug 1997 19:52:52 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id TAA19444; Tue, 12 Aug 1997 19:52:26 -0700 (PDT) To: Simon Shapiro cc: freebsd-current@FreeBSD.ORG Subject: Re: Floating Point Exception in make release In-reply-to: Your message of "Tue, 12 Aug 1997 11:16:20 PDT." Date: Tue, 12 Aug 1997 19:52:26 -0700 Message-ID: <19441.871440746@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Uh.. But this doesn't tell us anything actually useful. :-) > In -current (as of the 12th of August, dumps core in make release, > > cd /whereever_it_builds/usr/src/release/sysinstall > chroot /whereever_it_builds > make > > > That's it. > > Simon From owner-freebsd-current Tue Aug 12 21:33:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA19940 for current-outgoing; Tue, 12 Aug 1997 21:33:24 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (wck-ca13-02.ix.netcom.com [204.31.231.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA19934 for ; Tue, 12 Aug 1997 21:33:21 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.6/8.6.9) id VAA06415; Tue, 12 Aug 1997 21:32:54 -0700 (PDT) Date: Tue, 12 Aug 1997 21:32:54 -0700 (PDT) Message-Id: <199708130432.VAA06415@silvia.HIP.Berkeley.EDU> To: smp@csn.net CC: nnd@itfs.nsk.su, current@freebsd.org In-reply-to: <199708101743.LAA11578@Ilsa.StevesCafe.com> (message from Steve Passe on Sun, 10 Aug 1997 11:43:37 -0600) Subject: Re: Make and SMP - what can be done ? From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * You've touched on a topic dear to my heart! I took a stab at this once * and gave up for lack of knowledge of the .mk system and its subltlies. Amen to the first sentence! I haven't tried looking into this yet, I might try after the "new world" dust settles as I'm quite interested in this area. * I added JMAKEFLAGS= -j12 to /etc/make.conf, then added JMAKEFLAGS * to some of the lower level Makefiles, like the ones for libraries. * This worked nicely. I found other Makefiles that just needed a little * more work on the dependancies, they sometimes need to be more explicit * in a parallel world. Things with YACC & LEX passes die horribly. Ask Bruce. He has gone through the tree many times and knows a lot of things already. Satoshi From owner-freebsd-current Tue Aug 12 22:20:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA22508 for current-outgoing; Tue, 12 Aug 1997 22:20:05 -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 WAA22466 for ; Tue, 12 Aug 1997 22:20:01 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id WAA20242; Tue, 12 Aug 1997 22:19:26 -0700 (PDT) To: Adam David cc: freebsd-current@FreeBSD.ORG Subject: Re: /etc/mail.rc In-reply-to: Your message of "Tue, 12 Aug 1997 23:00:47 -0000." <199708122300.XAA01534@ubiq.veda.is> Date: Tue, 12 Aug 1997 22:19:26 -0700 Message-ID: <20238.871449566@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Is it intentional that /etc/mail.rc is clobbered by make install? Is this Whoa! > consistent with the policy that nothing in /etc gets clobbered, except > perhaps example files? It's most definitely not. I'd consider the behavior a bug. Jordan From owner-freebsd-current Tue Aug 12 22:57:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA26032 for current-outgoing; Tue, 12 Aug 1997 22:57:03 -0700 (PDT) Received: from areality.dyndns.com (27pm01.ka.net [207.51.78.56]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA26027 for ; Tue, 12 Aug 1997 22:56:53 -0700 (PDT) Received: from localhost (wangel@localhost) by areality.dyndns.com (8.8.5/8.8.5) with SMTP id BAA09151 for ; Wed, 13 Aug 1997 01:56:24 -0400 (EDT) Date: Wed, 13 Aug 1997 01:56:18 -0400 (EDT) From: Gary Roberts To: freebsd-current@freebsd.org Subject: Make World Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Having some problems w/ make world. I just subscribed to the group so please don't flame me yet, if this topic has been discussed. First: here=`pwd`; dest=/usr/obj`echo $here | sed 's,^/usr/src,,'`; if test -d /usr/om find . -name obj | xargs rm -rf make cleandir make: don't know how to make cleandir. Stop *** Error code 2 Thanks Gary From owner-freebsd-current Tue Aug 12 23:31:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA28238 for current-outgoing; Tue, 12 Aug 1997 23:31:19 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA28230; Tue, 12 Aug 1997 23:31:10 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA01221; Wed, 13 Aug 1997 08:15:26 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.6) id HAA02079; Wed, 13 Aug 1997 07:59:21 +0200 (CEST) Message-ID: <19970813075920.21718@klemm.gtn.com> Date: Wed, 13 Aug 1997 07:59:20 +0200 From: Andreas Klemm To: John Dyson Cc: current@FreeBSD.ORG Subject: Re: Backed out 1/2 of the scheduling improvements References: <199708121908.MAA19009@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.79 In-Reply-To: <199708121908.MAA19009@freefall.freebsd.org>; from John Dyson on Tue, Aug 12, 1997 at 12:08:48PM -0700 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Aug 12, 1997 at 12:08:48PM -0700, John Dyson wrote: > > Let me know how they work. Feel free to call me at 1-415-631-4044 in the > Bay area for quicker feedback. Thanks, John. Everything is fine now. I´m running now: - cvsup - 2 rsa crack processes - kernel recompile (make -j 8) And the system is still ok. Andreas /// -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Tue Aug 12 23:49:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA29615 for current-outgoing; Tue, 12 Aug 1997 23:49:29 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [194.77.0.15]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA29600 for ; Tue, 12 Aug 1997 23:49:20 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA04072 for current@FreeBSD.ORG; Wed, 13 Aug 1997 08:30:22 +0200 (MET DST) Received: (from andreas@localhost) by klemm.gtn.com (8.8.7/8.8.6) id IAA04660; Wed, 13 Aug 1997 08:15:25 +0200 (CEST) Message-ID: <19970813081525.56075@klemm.gtn.com> Date: Wed, 13 Aug 1997 08:15:25 +0200 From: Andreas Klemm To: current@FreeBSD.ORG Subject: Re: The "Peter principle" at work... References: <19499.871441059@time.cdrom.com> <199708130404.EAA01995@ubiq.veda.is> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.79 In-Reply-To: <199708130404.EAA01995@ubiq.veda.is>; from Adam David on Wed, Aug 13, 1997 at 04:04:47AM +0000 X-Disclaimer: A free society is one where it is safe to be unpopular X-Operating-System: FreeBSD 3.0-CURRENT SMP Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Aug 13, 1997 at 04:04:47AM +0000, Adam David wrote: > jkh agrees with phk that this is inconsistent... > > > /etc/cron.d > > > versus > > > /etc/namedb > > cron.d == cron directory, containing executable scripts for cron > namedb == (domain) name database, containing zone data files cron.d comes with a completely new idea of splitting daily, weekly and monthly. This justifies a name change. namedb (name database) wasnt changed and should stay as it it IMHO. I´d also accept if the name for namedb would change, but I see no real reason for it and some disadvantages: - It would cost extra work in the documentation area - would possibly break shell scripts for customers because the base dir changes - people are simly used to have a /etc/namedb, why break with old traditions for no good reason. [ trimmed Cc ] Andreas /// -- Andreas Klemm | klemm.gtn.com - powered by Symmetric MultiProcessor FreeBSD http://www.freebsd.org/~fsmp/SMP/SMP.html http://www.freebsd.org/~fsmp/SMP/benches.html From owner-freebsd-current Wed Aug 13 01:21:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA03957 for current-outgoing; Wed, 13 Aug 1997 01:21:29 -0700 (PDT) Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA03944 for ; Wed, 13 Aug 1997 01:21:11 -0700 (PDT) Received: from itfs.UUCP (uucp@localhost) by gw.itfs.nsk.su (8.6.12/8.6.12) with UUCP id PAA10610 for current@freebsd.org; Wed, 13 Aug 1997 15:20:52 +0700 Received: by itfs.nsk.su; Wed, 13 Aug 97 15:11:49 +0700 (NST) Received: (from daemon@localhost) by news.itfs.nsk.su (8.7.5/8.6.12) id PAA18029; Wed, 13 Aug 1997 15:08:18 +0700 (NSD) From: nnd@itfs.nsk.su To: current@freebsd.org Subject: Re: Make and SMP - what can be done ? Date: 13 Aug 1997 08:08:16 GMT Message-ID: <5srq1g$b4e@news.itfs.nsk.su> References: <199708130432.VAA06415@silvia.HIP.Berkeley.EDU> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Satoshi Asami wrote: > * You've touched on a topic dear to my heart! I took a stab at this once > * and gave up for lack of knowledge of the .mk system and its subltlies. > Amen to the first sentence! I haven't tried looking into this yet, I > might try after the "new world" dust settles as I'm quite interested > in this area. > * I added JMAKEFLAGS= -j12 to /etc/make.conf, then added JMAKEFLAGS > * to some of the lower level Makefiles, like the ones for libraries. > * This worked nicely. I found other Makefiles that just needed a little > * more work on the dependancies, they sometimes need to be more explicit > * in a parallel world. Things with YACC & LEX passes die horribly. My first result from some experiments in this area was just sended as a PR about inconsistent make behavior - it treats -j12 flags differently in various command line positions - i.e. before or after some variable definitions. I doubght that this is "a feature" and not "a plain bug", so I hope that somebody will observe and commit applied to PR fix. P.S. Looking at make's work with -j12 flag gives me strange feelings about intentions of author(s) of such an "extension" to traditional make behavior ;-) Is there any papers/READMEs on this topic ? P.P.S. Due to the fact that majority of Makefiles expect traditional make behavior and work with "make -j12" only by incident (:-) can we consider "make -j12" behavior as "undefined" in some areas and make it more "compatible" with traditional make - f.e. to make command line supplied targets evaluation strictly sequentional ? Or will this make us "unreasonably uncompatible" ? (with what ?) N.Dudorov From owner-freebsd-current Wed Aug 13 01:34:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA04417 for current-outgoing; Wed, 13 Aug 1997 01:34:17 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (wck-ca13-02.ix.netcom.com [204.31.231.194]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA04411 for ; Wed, 13 Aug 1997 01:34:14 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.8.6/8.6.9) id BAA09380; Wed, 13 Aug 1997 01:34:02 -0700 (PDT) Date: Wed, 13 Aug 1997 01:34:02 -0700 (PDT) Message-Id: <199708130834.BAA09380@silvia.HIP.Berkeley.EDU> To: wangel@areality.dyndns.com CC: freebsd-current@freebsd.org In-reply-to: (message from Gary Roberts on Wed, 13 Aug 1997 01:56:18 -0400 (EDT)) Subject: Re: Make World From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * Having some problems w/ make world. I just subscribed to the group so * please don't flame me yet, if this topic has been discussed. I don't plan to flame you, but you shouldn't cut too much out of the log. We need a few more lines before this to even start. Satoshi From owner-freebsd-current Wed Aug 13 03:32:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA09561 for current-outgoing; Wed, 13 Aug 1997 03:32:38 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09538; Wed, 13 Aug 1997 03:32:28 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id DAA28185; Wed, 13 Aug 1997 03:32:23 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA19153; Wed, 13 Aug 1997 03:32:22 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA17410; Wed, 13 Aug 1997 03:32:20 -0700 (PDT) From: Don Lewis Message-Id: <199708131032.DAA17410@salsa.gv.tsc.tdk.com> Date: Wed, 13 Aug 1997 03:32:20 -0700 In-Reply-To: Cy Schubert "Re: procfs patch" (Aug 12, 7:12am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: cy@uumail.gov.bc.ca, dg@root.com Subject: Re: procfs patch Cc: Sean Eric Fagan , current@FreeBSD.ORG, security@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 12, 7:12am, Cy Schubert wrote: } Subject: Re: procfs patch } All this patch does, in addition to allowing the "standard" access list } access, is allow KMEM_GROUP read access, so IMHO it's almost perfect. } Could this be controllable via sysctl, which would be used at boot time } with a one-line awk script to get kmem's gid and poke it into the kernel. I think it would be better as a mount option than a global variable. It sounds kind of icky, but mount_procfs could stat /dev/kmem to find the proper gid ... --- Truck From owner-freebsd-current Wed Aug 13 07:31:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA19901 for current-outgoing; Wed, 13 Aug 1997 07:31:17 -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 HAA19895 for ; Wed, 13 Aug 1997 07:31:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA14481; Thu, 14 Aug 1997 00:26:58 +1000 Date: Thu, 14 Aug 1997 00:26:58 +1000 From: Bruce Evans Message-Id: <199708131426.AAA14481@godzilla.zeta.org.au> To: ache@nagual.pp.ru, sos@sos.freebsd.dk Subject: Re: Error in sleep ! Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Here is quote from Solaris manpage (their manpages usually better >than ours :-) > >SunOS 5.5.1 Last change: 1 Feb 1995 1 This seems to have been "Obtained:" from the POSIX.2 spec :-). In the following, ">" quotes ache's mail and "&" quotes a draft version of the spec: >NOTES &4.57.5.4 Asynchronous Events & > If the sleep utility receives a SIGALRM signal, one of the & If the sleep utility receives a SIGALRM signal, one of the > following actions will be taken: & following actions shall be taken: > & > +o Terminate normally with a zero exit status. & (1) Terminate normally with a zero exit status > & > +o Effectively ignore the signal. & (2) Effectively ignore the signal > & & (3) Provide the default behavior for signals described in 2.11.5.4. & This could include terminating with a nonzero exit status. & > The sleep utility will take the standard action for all & The sleep utility shall take the standard action for all other signals; > other signals. & see 2.11.5.4. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bruce From owner-freebsd-current Wed Aug 13 08:11:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21950 for current-outgoing; Wed, 13 Aug 1997 08:11:18 -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 IAA21945 for ; Wed, 13 Aug 1997 08:11:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA15776; Thu, 14 Aug 1997 01:08:49 +1000 Date: Thu, 14 Aug 1997 01:08:49 +1000 From: Bruce Evans Message-Id: <199708131508.BAA15776@godzilla.zeta.org.au> To: adam@veda.is, freebsd-current@FreeBSD.ORG Subject: Re: /etc/mail.rc Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Is it intentional that /etc/mail.rc is clobbered by make install? Is this >consistent with the policy that nothing in /etc gets clobbered, except >perhaps example files? It is a bug. Bruce From owner-freebsd-current Wed Aug 13 08:21:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA22359 for current-outgoing; Wed, 13 Aug 1997 08:21:17 -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 IAA22350 for ; Wed, 13 Aug 1997 08:21:09 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA16131; Thu, 14 Aug 1997 01:19:37 +1000 Date: Thu, 14 Aug 1997 01:19:37 +1000 From: Bruce Evans Message-Id: <199708131519.BAA16131@godzilla.zeta.org.au> To: ache@nagual.pp.ru, terry@lambert.org Subject: Re: siginterrupt (was Re: Error in sleep !) Cc: current@FreeBSD.ORG, sos@sos.freebsd.dk Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> POSIX says that system calls will not be restarted by default (the >> historical System V behaviour for signals). > >Could you please send exact quote just about this particular thing? >Many times POSIX is very unclear or can be misinterpreted. It is usually very clear :-). I don't have the exact quote handy, but the main point is that sa_flags == 0 gives "normal" behaviour (with no restart, etc). POSIX doesn't define any interesting SA_* macros for the flags; it only reserves SA_*. Some systems define an SA_RESTART macro for restarting syscalls. >Currently siginterrupt and signal man pages says nothing about POSIX >conformance, so manpages are right independently of how we interpretate >POSIX. siginterrupt() and signal() aren't in POSIX. >> The problem is that if I send a normally ignored signal to sleep(1) >> after it goes to sleep but before the interval is expired, the >> sleep doesn't keep going. > >POSIX says exactly that _any_ non-blocked and non-ignored signal should >terminate sleep(3)/sleep(1) including default no-op signals like ^T, etc. sleep(1) always terminated on ^C (only caught signals are restarted). Bruce From owner-freebsd-current Wed Aug 13 09:44:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA11923 for current-outgoing; Wed, 13 Aug 1997 09:44: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 JAA11917 for ; Wed, 13 Aug 1997 09:44:35 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12578; Wed, 13 Aug 1997 09:39:32 -0700 From: Terry Lambert Message-Id: <199708131639.JAA12578@phaeton.artisoft.com> Subject: Re: Floating Point Exception in make release To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 13 Aug 1997 09:39:32 -0700 (MST) Cc: Shimon@i-Connect.Net, freebsd-current@FreeBSD.ORG In-Reply-To: <19441.871440746@time.cdrom.com> from "Jordan K. Hubbard" at Aug 12, 97 07:52:26 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Uh.. But this doesn't tell us anything actually useful. :-) > > > In -current (as of the 12th of August, dumps core in make release, > > > > cd /whereever_it_builds/usr/src/release/sysinstall > > chroot /whereever_it_builds > > make It tells you he is in the sysinstall directory. 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-current Wed Aug 13 09:51:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12191 for current-outgoing; Wed, 13 Aug 1997 09:51: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 JAA12183 for ; Wed, 13 Aug 1997 09:51:05 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA18733; Thu, 14 Aug 1997 02:47:26 +1000 Date: Thu, 14 Aug 1997 02:47:26 +1000 From: Bruce Evans Message-Id: <199708131647.CAA18733@godzilla.zeta.org.au> To: ache@nagual.pp.ru, bde@zeta.org.au Subject: Re: siginterrupt (was Re: Error in sleep !) Cc: current@FreeBSD.ORG, sos@sos.freebsd.dk, terry@lambert.org Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I mean not application which uses some signal interface but initial >handling of SIG_DFL _before_ any sigaction() or signal() used. I.e. is it >safe per POSIX to have SA_RESTART for SIG_DFL action initially at >application startup (before any application actions)? The initial value for sa_flags seems to be unspecified. In practice, it is 0 in FreeBSD. This probably only matters if you use sigaction() to find the old value and write a modified value, since SA_RESTART doesn't affect SIG_DFL actions (it only affects caught signals). It doesn't matter for the other flags, since the "BSD default" for them is off. Bruce From owner-freebsd-current Wed Aug 13 09:52:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA12319 for current-outgoing; Wed, 13 Aug 1997 09:52: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 JAA12314 for ; Wed, 13 Aug 1997 09:52:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA12611; Wed, 13 Aug 1997 09:47:24 -0700 From: Terry Lambert Message-Id: <199708131647.JAA12611@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Wed, 13 Aug 1997 09:47:24 -0700 (MST) Cc: bde@zeta.org.au, current@FreeBSD.ORG, sos@sos.freebsd.dk, terry@lambert.org In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 08:25: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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The caller of sigaction() decides the initial value. In portable > > POSIX programs, the value must be either 0 or SA_NOCLDSTOP, since > > SA_NOCLDSTOP is the only POSIX flag. For signal(), the value is > > implementation-defined. (I said that signal() is non-POSIX. Actually, > > it is inherited from ANSI C, and thus gives fuzzy ANSI signal semantics.) > > I mean not application which uses some signal interface but initial > handling of SIG_DFL _before_ any sigaction() or signal() used. I.e. is it > safe per POSIX to have SA_RESTART for SIG_DFL action initially at > application startup (before any application actions)? POSIX recognizes only the flag SA_NOCLDSTOP, as Bruce notes above. Look at /usr/include/sys/signal.h: [ ... ] #ifndef _POSIX_SOURCE #define SA_ONSTACK 0x0001 /* take signal on signal stack */ #define SA_RESTART 0x0002 /* restart system call on signal return */ #define SA_RESETHAND 0x0004 /* reset to SIG_DFL when taking signal */ #define SA_NODEFER 0x0010 /* don't mask the signal we're delivering */ #ifdef COMPAT_SUNOS #define SA_USERTRAMP 0x0100 /* do not bounce off kernel's sigtramp */ #endif #endif /* _POSIX_SOURCE */ #define SA_NOCLDSTOP 0x0008 /* do not generate SIGCHLD on child stop */ [ ... ] For a POSIX compatible compiled libc, it's *IMPOSSIBLE* to have an *undefined* flag set by default. That should put this thing to rest, once and for all... 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-current Wed Aug 13 10:21:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA13794 for current-outgoing; Wed, 13 Aug 1997 10:21:46 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA13761; Wed, 13 Aug 1997 10:20:44 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.6/3.5Wpl3) with ESMTP id CAA03222; Thu, 14 Aug 1997 02:20:41 +0900 (JST) Message-Id: <199708131720.CAA03222@gneiss.eps.nagoya-u.ac.jp> To: current@FreeBSD.org Cc: dyson@FreeBSD.org, bde@FreeBSD.org Subject: Read-only mount of union filesystem From: KATO Takenori X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 14 Aug 1997 02:20:41 +0900 Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk This mail is Cc'ed to Bruce who notified me the problem, and also to John who handbook says coordinator of union fs is. Bruce notified me that union fs doesn't support read-only mount. I, now, consider that there are two ways to implement read-only mount: 1. To modify each fs layer stuff. 2. To modify vfs layer stuff. FreeBSD-current chose first way that each filesystem stuff should handle MNT_RDONLY flag. On the contrary, NetBSD uses later way and MNT_RDONLY flag is handled in sys/kern/vfs_{lookup,syscall,vnops}.c. I will add patches for above two ways below. I prefer latter way because it is general way and maintainer of each filesystem doesn't need to be care of upper layer. 1. Following patch supports rdonly moount in union fs layer: ---------- BEGIN ---------- begin 644 rdonly-unionfs.diff.gz M'XL(",4I\3,``W)D;VYL>2UU;FEO;F9S+F1I9F8`K95[C^(V$,#_#I]B3I4X M2!-VR=Z&EU@)+;F6'A=66>!:515*$X=-+[$CV\EJ[_79:SLD0(\[ME412BS/ MT_.;<<(XBL#T:>`">V(7:;`I.,=8*O=([%#5W7G^-& M>X="F.1;Z%Y!UQI:O6&W"]W!H-(08@]2DF,N$J;(#TV"DZ=.Z>%"ON((6JT` M9^9-@#=1XF\9-&%V/Y_<+V_=-C2;T`H+(2TVRHUYDV*N](3:6W>Y\:8+=_Z; M5)3>M-H5]E,4DPS&8Y@Z[DK=-N*VN*>$XQM!QO\?J^/9(G M!O@ACD(4`2;\"7%5+I'RH:<$8>GI2N8@Q)IV*,PX_=WZ0\I?=EY*C9.$[%>& M90\."/4LP^KW:T+:9_7,$:6$PAC*;D@(>9]GW5:>FC=YNLFS#-$B,Z"I5J)L M1IF/IC5KFM\TMCTP[/Y5 MW335#&,2(M"+;/3U)O,+%):2\[/-&1!\T`[L_&3[H@:^X"EB-6']SIL).+(7 MROUGT*Y@L<>8!P_'AOPI0Y4\\!F"M>?\-(1R.9UYU7+NOAF>X?:YFNN6A`#' M5-KP8@SN:CY?WU507L]^7=VU0LK%]0+KY6+ESA9N78'V(X7OA[N5B/ MJIM?#>SH6;?[?^B`[Z+63U[AA30I_-WDB-JOW<5Z,I=378GR.)2"EGAO>+N6 ME[=1I;3=*6V/E6JYS^,4=7BQ82@X"G/L)OV6VEY#8I*1Y*(.]8UO"LAOBJPS MJ#K_[.,P066GD@@$,1R(Q/`61/$1!?+G7T@P%'?Q!T0)L/@#,AI_`Y;ZYF.Q #"``` ` end ---------- END ---------- I'm not 100% sure of the change in union_lookup(). 2. Following patch supports rdonly mount in vfs layer: ---------- BEGIN ---------- begin 644 rdonly-vfs.diff.gz M'XL("!PG\3,``W)D;VYL>2UV9G,N9&EF9@#M66UOXC@0_MS^BKDO7>`")>$E M2:NNQ+7I'BJ%%=#NK4ZGR$T,C0I.E)CTJMO^]QL[A`*%"G8%M-U%;>+8,V// M,\],K-CU>CW(D]!I0O00'=[1D!7\T.L?QKW('OC^W2@H.).AF=[]7"[W@M+> M%^I";=0'M02J>E0L'97*H)JFOI_/YQ=;?*Y2T1*5W.Q/3ETN591R6079`;"W M!SFH]\`)*>$>ZP-A+A`.%&]^#P+";QD94@7X+67@$/SW6>2Y-$R5R6#@WPO- MGC>@P'VXH8DUZA;&,H?[O^'=ZT$F='TV>,C"?W)DCX:A'\()6.W6>>O[ MP@9QD\='Z7>Z:&SG=[5H^/8-,LP-\A^99[LQWF-[Z(\8SW\<,F[W!J0/!W#9 M[-KMLU:S\36[EI>+0E71#*6"X4]#=2BON/HS+Y(.@.N%U.%^^`#WH<WAN`BHE3+NE*ME-Y63E?+!BZZO/N>"D^,.`!S"U@VXT"Z?-WZ;#>L6L?*Q($"XB__,;!'F)>N`G+`_M*N M=ZVLE(X9[FJ<.RG;N+"MOTX;5YWZ-0(N'MM6M_T5+:`L!OBZUNVV[>95HY$Y MB)%58=(MFX68R.A&N)S.::W]*3,B:%)V)6)I<,3Z.E97V)*S)J9FEQF,%Q>, M.,HD#R'EHY!!1MJ174E52S'1)RFQ34Q$NJQ`%%G<>5,%[,PZJ*F%?-61YF(AZ.'`XQ\UT*N6P/)^W9+N'DO3%3B%XU&ZW3 M"RE9G`PL9VE5L%2?8^G.$'OSO%TK`HLY;!J*:A2KK[*6#@4?9D`3/?BRA%JC M\=EJ7W8V6U01%P1'-=YY45T1YBU75Z-41O#+VANIKIOCZOIEUB@+WE:,GZ[, M;IK)/UYO#;V$H3&T5UEO1YX[BQYVS(GTYT7ZJ?^=AZKCS,`WS MI]MY[(CV/[XA,4U3T8I%5?`(-X=Z0%GAL1]3!Z7G\=_&?\>,2038G.1+/ MZ$^Q6)S;F#\SK2XV/7QN6EUH>E.O"*VHZ1B+J0/'-_F*6#FHWQ'5UJK/&Q?:E&17WA2[LI7H]Z4AJ2^JXIFCKAISAP M&!^__#Y[_++JH[CMM-IH71U)HP@29)=GC*Q@&3^:DCJOG[?2L3]J M9Y-F(YW@!D&]2^P^BJN\3,["ZCV!1$@_1!`A:!AX3O_E0"+$U1/'DX#^W8Z% M!6;R]:P`#Q_$,68OI!@'#J,`,75H`=#@6/@>\27>0!$-A[`/')ZB[K%^8?]_ (951%\*DB``#$ ` end ---------- END ---------- After this patch is aplied, redundant code remains in each filesystem stuff, but it should not have bad effect except for filesize and execution time. I will commit one of them after discussion. Please comment. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Aug 13 10:41:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA15257 for current-outgoing; Wed, 13 Aug 1997 10:41:47 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA15247 for ; Wed, 13 Aug 1997 10:41:38 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id VAA17243; Wed, 13 Aug 1997 21:40:04 +0400 (MSD) Date: Wed, 13 Aug 1997 21:39:57 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Bruce Evans cc: current@FreeBSD.ORG, sos@sos.freebsd.dk, terry@lambert.org Subject: Re: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708131647.CAA18733@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997, Bruce Evans wrote: > >I mean not application which uses some signal interface but initial > >handling of SIG_DFL _before_ any sigaction() or signal() used. I.e. is it > >safe per POSIX to have SA_RESTART for SIG_DFL action initially at > >application startup (before any application actions)? > > The initial value for sa_flags seems to be unspecified. In practice, it > is 0 in FreeBSD. This probably only matters if you use sigaction() to > find the old value and write a modified value, since SA_RESTART doesn't > affect SIG_DFL actions (it only affects caught signals). It doesn't > matter for the other flags, since the "BSD default" for them is off. So, it means that we still compatible with POSIX here. I'll change the default behaviour on FreeBSD to the default behaviour for signal(3) on FreeBSD to make siginterrupt(3) man page more clear. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Aug 13 11:24:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA17970 for current-outgoing; Wed, 13 Aug 1997 11:24:56 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.129.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA17965 for ; Wed, 13 Aug 1997 11:24:53 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id UAA05442; Wed, 13 Aug 1997 20:24:14 +0200 (CEST) To: KATO Takenori cc: current@FreeBSD.ORG Subject: Re: Read-only mount of union filesystem In-reply-to: Your message of "Thu, 14 Aug 1997 02:20:41 +0900." <199708131720.CAA03222@gneiss.eps.nagoya-u.ac.jp> Date: Wed, 13 Aug 1997 20:24:13 +0200 Message-ID: <5440.871496653@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199708131720.CAA03222@gneiss.eps.nagoya-u.ac.jp>, KATO Takenori wri > 2. To modify vfs layer stuff. Way to go! -- 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-current Wed Aug 13 11:25:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA17997 for current-outgoing; Wed, 13 Aug 1997 11:25: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 LAA17960; Wed, 13 Aug 1997 11:24:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12802; Wed, 13 Aug 1997 11:19:46 -0700 From: Terry Lambert Message-Id: <199708131819.LAA12802@phaeton.artisoft.com> Subject: Re: Read-only mount of union filesystem To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Wed, 13 Aug 1997 11:19:46 -0700 (MST) Cc: current@FreeBSD.ORG, dyson@FreeBSD.ORG, bde@FreeBSD.ORG In-Reply-To: <199708131720.CAA03222@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Aug 14, 97 02:20:41 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm not 100% sure of the change in union_lookup(). > > > 2. Following patch supports rdonly mount in vfs layer: [ ... ] > I will commit one of them after discussion. Please comment. I support the second patch. Note that read-only devices need to propagate this falg as an override from the device attributes. 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-current Wed Aug 13 11:27:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA18165 for current-outgoing; Wed, 13 Aug 1997 11:27:24 -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 LAA18153 for ; Wed, 13 Aug 1997 11:27:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA12815; Wed, 13 Aug 1997 11:22:02 -0700 From: Terry Lambert Message-Id: <199708131822.LAA12815@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Wed, 13 Aug 1997 11:22:02 -0700 (MST) Cc: bde@zeta.org.au, current@FreeBSD.ORG, sos@sos.freebsd.dk, terry@lambert.org In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 09:39:57 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So, it means that we still compatible with POSIX here. > I'll change > the default behaviour on FreeBSD > to > the default behaviour for signal(3) on FreeBSD > to make siginterrupt(3) man page more clear. Still wrong. FreeBSD does not restart system calls by default. I think it was a bad decision, but it's one required for a strict POSIX environment. I think it's wrong because it makes it hard to make section 3 calls behave as system calls in the face of call restart. Oh well. 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-current Wed Aug 13 11:35:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA18795 for current-outgoing; Wed, 13 Aug 1997 11:35:36 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA18787 for ; Wed, 13 Aug 1997 11:35:33 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id WAA18212; Wed, 13 Aug 1997 22:34:31 +0400 (MSD) Date: Wed, 13 Aug 1997 22:34:28 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Terry Lambert cc: bde@zeta.org.au, current@FreeBSD.ORG, sos@sos.freebsd.dk Subject: Re: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708131822.LAA12815@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Aug 1997, Terry Lambert wrote: > > So, it means that we still compatible with POSIX here. > > I'll change > > the default behaviour on FreeBSD > > to > > the default behaviour for signal(3) on FreeBSD > > to make siginterrupt(3) man page more clear. > > Still wrong. FreeBSD does not restart system calls by default. Hmm. What do you mean exacly in "by default"? When program use signal(3), it have restartable syscalls, but this case not covered by POSIX at all since there is no signal(3) in POSIX. When program use sigaction(2) with sa_flags == 0, it _not_ have restartable syscalls as POSIX requires. > I think it was a bad decision, but it's one required for a strict > POSIX environment. IMHO, we already are inside strict POSIX requirement in this area. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Aug 13 12:55:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA23981 for current-outgoing; Wed, 13 Aug 1997 12:55: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 MAA23973 for ; Wed, 13 Aug 1997 12:55:40 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA12930; Wed, 13 Aug 1997 12:50:32 -0700 From: Terry Lambert Message-Id: <199708131950.MAA12930@phaeton.artisoft.com> Subject: Re: siginterrupt (was Re: Error in sleep !) To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Wed, 13 Aug 1997 12:50:32 -0700 (MST) Cc: terry@lambert.org, bde@zeta.org.au, current@FreeBSD.ORG, sos@sos.freebsd.dk In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Aug 13, 97 10:34:28 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > So, it means that we still compatible with POSIX here. > > > I'll change > > > the default behaviour on FreeBSD > > > to > > > the default behaviour for signal(3) on FreeBSD > > > to make siginterrupt(3) man page more clear. > > > > Still wrong. FreeBSD does not restart system calls by default. > > Hmm. What do you mean exacly in "by default"? Without you specifically calling siginterrupt() to toggle SA_RESTART from off to on (default is off), or calling sigaction() to set the SA_RESTART bit in the sa_flags filed (non-POSIX flag value). > When program use signal(3), it have restartable syscalls, but this case > not covered by POSIX at all since there is no signal(3) in POSIX. It's very odd, and not terribly consistent. I know. 8-|. > When program use sigaction(2) with sa_flags == 0, it _not_ have > restartable syscalls as POSIX requires. > > > I think it was a bad decision, but it's one required for a strict > > POSIX environment. > > IMHO, we already are inside strict POSIX requirement in this area. What if you call neither sigaction(), nor signal()? What if you call sleep(3)? What behaviour does it have? That's the point... 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-current Wed Aug 13 13:17:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA25134 for current-outgoing; Wed, 13 Aug 1997 13:17:04 -0700 (PDT) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25128 for ; Wed, 13 Aug 1997 13:16:58 -0700 (PDT) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.7/8.8.7) id AAA19999; Thu, 14 Aug 1997 00:15:33 +0400 (MSD) Date: Thu, 14 Aug 1997 00:15:29 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Terry Lambert cc: bde@zeta.org.au, current@FreeBSD.ORG, sos@sos.freebsd.dk Subject: Re: siginterrupt (was Re: Error in sleep !) In-Reply-To: <199708131950.MAA12930@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Aug 1997, Terry Lambert wrote: > Without you specifically calling siginterrupt() to toggle SA_RESTART > from off to on (default is off), or calling sigaction() to set the Oh, no. siginterrupt() affects signal() only and default is _on_ for signal(). siginterrupt() not affects sigaction() at all. > What if you call neither sigaction(), nor signal()? What if you > call sleep(3)? What behaviour does it have? That's the point... As Bruce already says, only catched signals affects syscalls (restartable or not), so you must to call either signal() or sigaction() to have signal catched. POSIX requirement not affects SIG_DFL action. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Aug 13 13:58:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27148 for current-outgoing; Wed, 13 Aug 1997 13:58:09 -0700 (PDT) Received: from atlantis.nconnect.net (root@atlantis.nconnect.net [207.227.50.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27099 for ; Wed, 13 Aug 1997 13:57:38 -0700 (PDT) Received: from arabian (arabian.microxp.com [207.227.65.13]) by atlantis.nconnect.net (8.8.4/8.7.3) with SMTP id QAA03324 for ; Wed, 13 Aug 1997 16:03:07 -0500 (CDT) Received: by localhost with Microsoft MAPI; Wed, 13 Aug 1997 16:03:39 -0500 Message-ID: <01BCA802.76946950.randyd@nconnect.net> From: Randy DuCharme Reply-To: "randyd@nconnect.net" To: "'current@freebsd.org'" Subject: missing kern_exit.c Date: Wed, 13 Aug 1997 16:03:38 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The latest cvs update seems to have removed this file. In attempting to build a UP kernel from sources grabbed an hour ago it stopped not being able to find the file. Am I between updates? --- Randall D DuCharme Novell, Microsoft and UNIX Systems Engineer Networking Service & Support Computer Specialists BSD/OS Authorized Resellers & 414-253-9998 414-253-9919 (fax) BSDI Internet Success Partners From owner-freebsd-current Wed Aug 13 14:52:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA00861 for current-outgoing; Wed, 13 Aug 1997 14:52:33 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA00849 for ; Wed, 13 Aug 1997 14:52:31 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id RAA11255; Wed, 13 Aug 1997 17:52:30 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id RAA28581; Wed, 13 Aug 1997 17:52:29 -0400 (EDT) To: "randyd@nconnect.net" cc: "'current@freebsd.org'" From: "Gary Palmer" Subject: Re: missing kern_exit.c In-reply-to: Your message of "Wed, 13 Aug 1997 16:03:38 CDT." <01BCA802.76946950.randyd@nconnect.net> Date: Wed, 13 Aug 1997 17:52:29 -0400 Message-ID: <28578.871509149@orion.webspan.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randy DuCharme wrote in message ID <01BCA802.76946950.randyd@nconnect.net>: > The latest cvs update seems to have removed this file. I think freefall crashed and the file was wiped by fsck :( I just noticed this myself. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Wed Aug 13 20:32:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA18914 for current-outgoing; Wed, 13 Aug 1997 20:32:44 -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 UAA18906; Wed, 13 Aug 1997 20:32:42 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id UAA00314; Wed, 13 Aug 1997 20:32:40 -0700 (PDT) Message-Id: <199708140332.UAA00314@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org cc: current@freebsd.org Subject: YES!, bktr now works 8) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Aug 1997 20:32:40 -0700 From: Amancio Hasty Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Add the following line in btkr_attach: fun = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); pci_conf_write(tag, PCI_COMMAND_STATUS_REG, fun | 4); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add this ^^^^^^^^^^^^^^^^^^^ That sets the bt848 to be able to act as a dma initiator. Most likely the new pci interface cleared that bit cause I have never set it and the driver has worked in the past;additionally, the may 22 release of current seems to work on my other PC. I just supped a new kernel yesterday . Before this weekend I will make sure that the latest bktr driver gets checked in. For further info on the video capture driver and respective apps, see: http://freebsd.org/~fsmp/HomeAuto/Bt848.html Now, dont stay up too late watching movies on your FreeBSD box , is really meant for hacking 8) Amancio From owner-freebsd-current Wed Aug 13 21:59:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA23105 for current-outgoing; Wed, 13 Aug 1997 21:59:42 -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 VAA23100 for ; Wed, 13 Aug 1997 21:59:40 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id VAA23455; Wed, 13 Aug 1997 21:59:44 -0700 (PDT) Message-Id: <199708140459.VAA23455@implode.root.com> To: Terry Lambert cc: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori), current@FreeBSD.ORG Subject: Re: Read-only mount of union filesystem In-reply-to: Your message of "Wed, 13 Aug 1997 11:19:46 PDT." <199708131819.LAA12802@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 13 Aug 1997 21:59:44 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I'm not 100% sure of the change in union_lookup(). >> >> >> 2. Following patch supports rdonly mount in vfs layer: >[ ... ] > >> I will commit one of them after discussion. Please comment. > >I support the second patch. > >Note that read-only devices need to propagate this falg as an >override from the device attributes. I changed the behavior in FreeBSD to what it is now (which is also the same as it is in Lite-2). For information on why it is this way, see PR#782. In my opinion, the current structure is correct. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Thu Aug 14 01:11:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA04522 for current-outgoing; Thu, 14 Aug 1997 01:11:34 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA04517; Thu, 14 Aug 1997 01:11:31 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA12402 (5.67b/IDA-1.5); Thu, 14 Aug 1997 10:11:25 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id KAA00877; Thu, 14 Aug 1997 10:10:56 +0200 (CEST) X-Face: " Date: Thu, 14 Aug 1997 10:10:56 +0200 From: Stefan Esser To: Amancio Hasty Cc: Kenneth Merry , multimedia@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: YES!, bktr now works 8) References: <199708140525.XAA08949@pluto.plutotech.com> <199708140532.WAA00445@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199708140532.WAA00445@rah.star-gate.com>; from Amancio Hasty on Wed, Aug 13, 1997 at 10:32:04PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 13, Amancio Hasty wrote: > > > fun = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); > > > pci_conf_write(tag, PCI_COMMAND_STATUS_REG, fun | 4); > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add this ^^^^^^^^^^^^^^^^^^^ Well, I'm not sure about the name, but a function that enables or disables bits in the PCI command register might be a good idea. How about: enables = pci_enable(PCI_MEM|PCI_PORT|PCI_DMA); enables = pci_disable(PCI_MEM|PCI_PORT|PCI_DMA); where the result is in fact the low order three bits from the command register after trying to set them according to the parameter ? Regards, STefan From owner-freebsd-current Thu Aug 14 01:12:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA04614 for current-outgoing; Thu, 14 Aug 1997 01:12:16 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA04606; Thu, 14 Aug 1997 01:12:13 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA12428 (5.67b/IDA-1.5); Thu, 14 Aug 1997 10:12:11 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id KAA00844; Thu, 14 Aug 1997 10:02:56 +0200 (CEST) X-Face: " Date: Thu, 14 Aug 1997 10:02:55 +0200 From: Stefan Esser To: Amancio Hasty Cc: multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: YES!, bktr now works 8) References: <199708140332.UAA00314@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199708140332.UAA00314@rah.star-gate.com>; from Amancio Hasty on Wed, Aug 13, 1997 at 08:32:40PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 13, Amancio Hasty wrote: > > > Add the following line in btkr_attach: > > fun = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); > pci_conf_write(tag, PCI_COMMAND_STATUS_REG, fun | 4); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add this ^^^^^^^^^^^^^^^^^^^ > > That sets the bt848 to be able to act as a dma initiator. The Bus-Master enable bit ... It is typically set by the card BIOS, or else by the driver. The PCI bus code should **not** automatically enable this bit, since it may crash the system, depending on the state of the PCI device. > Most likely the new pci interface cleared that bit cause I have never > set it and the driver has worked in the past;additionally, the may 22 > release of current seems to work on my other PC. No, the PCI driver does NOT clear it. The previous version of the PCI code bogously set the bus-master enable bit. I'm not sure how to deal with this correctly. I do not want the drivers to fiddle with configuration space registers, unless absolutely necessary. I could provide a "pci_enable_busmaster()" function, which hides the details ... The enable bits (memory, port and bus-master) in the PCI command register are meant to isolate the device from the PCI bus, if not set. It is bad to set at least the bus-master enable before the device has been initialised. It may be too late to set the bus-master enable after the device has initialised, because it may need that feature enabled for the initialisation ... (The PCI code set the bus-master DMA enable bit whenever the driver called pci_map_mem() or pci_map_port(). But since the PCI device can only be configured *after* some port or memory window has been mapped, this was definitely too early!) I had an interesting mail exchange with Tony Overfield on that topic, and I think the -current behaviour of the PCI code (to leave the bus-master enable bit alone) is correct ... > I just supped a new kernel yesterday . > > Before this weekend I will make sure that the latest bktr driver gets > checked in. I'm sorry this caused you trouble, but the previous behaviour of the PCI code was not correct. It may cause warm boots to fail, for example. (Cold boots will generally work, since the device is expected to be in a reset state.) Regards, STefan From owner-freebsd-current Thu Aug 14 01:51:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA06512 for current-outgoing; Thu, 14 Aug 1997 01:51:45 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA06504 for ; Thu, 14 Aug 1997 01:51:35 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.6/3.5Wpl3) with ESMTP id RAA04702; Thu, 14 Aug 1997 17:49:47 +0900 (JST) Message-Id: <199708140849.RAA04702@gneiss.eps.nagoya-u.ac.jp> To: dg@root.com Cc: terry@lambert.org, current@FreeBSD.ORG Subject: Re: Read-only mount of union filesystem From: KATO Takenori In-Reply-To: Your message of "Wed, 13 Aug 1997 21:59:44 -0700" References: <199708140459.VAA23455@implode.root.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 14 Aug 1997 17:49:46 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I changed the behavior in FreeBSD to what it is now (which is also the > same as it is in Lite-2). For information on why it is this way, see PR#782. > In my opinion, the current structure is correct. I understand why vfs layer shouldn't reference v_mount. But, IMHO, fs independent operation should be in upper layer. The problem in PR#782 may be solved by following method: 1. Prepare special mount struct whose mnt_flag is or'ed by special flag (e.g., MNT_DEAD). 2. When vnode is cleaned, v_mount points the special mount struct instead of beeing NULL'ed. 3. vfs layer checks MNT_RDONLY and MNT_DEAD. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Thu Aug 14 03:30:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA09959 for current-outgoing; Thu, 14 Aug 1997 03:30:43 -0700 (PDT) Received: from critter.dk.tfs.com ([140.145.230.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA09954 for ; Thu, 14 Aug 1997 03:30:39 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id MAA02421 for ; Thu, 14 Aug 1997 12:29:44 +0200 (CEST) To: current@freebsd.org Subject: kernel profiling data... From: Poul-Henning Kamp Date: Thu, 14 Aug 1997 12:29:44 +0200 Message-ID: <2419.871554584@critter.dk.tfs.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Should anybody be interested, I'm currently running my kernel with basic- block profiling. If there are any particular piece of code you want to get some numbers for, let me know. Here is a snapshot per procedure. The metric is "number of bytes * number of executions" which doesn't take procedure calls into account. It's still a pretty good metric anyway: 2141424420 pmap_pte_quick 2123382399 malloc 1967036165 vm_pageout_page_stats 1891991217 sc_bcopy /* this is special in my code */ 1849258604 pmap_is_managed 1822361685 in_cksum 1745752719 lookup 1647903703 selscan 1621132031 userret 1525817854 free 1478288512 hardclock 1384795000 scanc 1238605405 select 1228973774 __qdivrem 1203676414 ffs_sync 1136352924 timeout 1076999688 splvm 1072813562 vfs_msync 960134796 tcp_output 874196469 VOP_ISLOCKED 839275470 splhigh 825929764 inbc 754320392 lockstatus 753825169 vm_pageout_scan 659921964 getit 656055743 cpu_clockupdate 631443113 edintr_sc 608603985 outbv 601732656 clock_latency 560227824 ufs_islocked 528477347 cache_lookup -- 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. From owner-freebsd-current Thu Aug 14 04:05:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA11367 for current-outgoing; Thu, 14 Aug 1997 04:05:52 -0700 (PDT) Received: from critter.dk.tfs.com ([140.145.230.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA11361 for ; Thu, 14 Aug 1997 04:05:48 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id NAA02687; Thu, 14 Aug 1997 13:04:54 +0200 (CEST) To: Poul-Henning Kamp cc: current@freebsd.org Subject: Re: kernel profiling data... In-reply-to: Your message of "Thu, 14 Aug 1997 12:29:44 +0200." <2419.871554584@critter.dk.tfs.com> Date: Thu, 14 Aug 1997 13:04:53 +0200 Message-ID: <2685.871556693@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <2419.871554584@critter.dk.tfs.com>, Poul-Henning Kamp writes: > >Should anybody be interested, I'm currently running my kernel with basic- >block profiling. If there are any particular piece of code you want >to get some numbers for, let me know. > >Here is a snapshot per procedure. The metric is "number of bytes * number >of executions" which doesn't take procedure calls into account. It's still >a pretty good metric anyway: Argh! integer overflow :-( Here is the correct data: 4707340384 syscall 4537661363 lockmgr 3652643072 ufs_dirbadentry 3305145500 ufs_lookup 2651069178 splx 2626861812 statclock 2545337950 pmap_ts_referenced 2366684927 pmap_pte_quick 2151130267 malloc 2142457647 vm_pageout_page_stats 1979759650 pmap_is_managed 1933368283 in_cksum 1891991217 sc_bcopy 1799029727 selscan 1770893872 lookup 1766265769 userret 1566383288 hardclock 1546053323 free 1428182323 scanc 1365260343 select 1304664809 __qdivrem 1275887817 ffs_sync 1207845430 timeout 1164030293 splvm 1136430326 vfs_msync 1026993813 tcp_output 926535753 VOP_ISLOCKED 893236520 splhigh 854388172 inbc 798634314 lockstatus 777287232 vm_pageout_scan -- 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-current Thu Aug 14 06:50:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA18352 for current-outgoing; Thu, 14 Aug 1997 06:50:25 -0700 (PDT) Received: from methan.chemie.fu-berlin.de (methan.chemie.fu-berlin.de [160.45.22.81]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA18344 for ; Thu, 14 Aug 1997 06:50:10 -0700 (PDT) Received: by methan.chemie.fu-berlin.de (Smail3.1.29.1) from uriela.in-berlin.de (192.109.42.147) with smtp id ; Thu, 14 Aug 97 15:50 MET DST Received: by uriela.in-berlin.de (/\oo/\ Smail3.1.29.1 #29.8) id ; Thu, 14 Aug 97 15:48 MET DST Received: from dva by never.never.mind.de with uucp (Smail3.1.28.1 #1) id m0wz0Ht-000EstC; Thu, 14 Aug 97 15:50 MET DST Received: by dva.in-berlin.de via smail with stdio id for current@freebsd.org; Thu, 14 Aug 1997 15:46:54 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1 built CET-26-Nov) Message-Id: From: balu@dva.in-berlin.de (Boris Staeblow) Subject: Very slow Ethernet-performance with de0 To: current@freebsd.org Date: Thu, 14 Aug 1997 15:46:54 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL34 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've big problems with performance on my local network. Both machines (P166/P200 MMX, 430 HX) running (very) current (as of Aug 13) - same DEC21041 based network cards. No special kernel-configs. host1: ------ de0: rev 0x11 int a irq 9 on pci0.10.0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:ad:1c:af:a8 de0: flags=8843 mtu 1500 inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:80:ad:1c:af:a8 media: autoselect (10base2/BNC) status: active host2: ------ de0: rev 0x11 int a irq 11 on pci0.13.0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:ad:1c:ac:97 de0: flags=8843 mtu 1500 inet 10.0.0.11 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:80:ad:1c:ac:97 media: autoselect (10base2/BNC) status: active benchmark on a NFS-mounted drive: % iozone 10 Writing the 10 Megabyte file, 'iozone.tmp'...16.531250 seconds Reading the file...55.671875 seconds IOZONE performance measurements: 634299 bytes/second for writing the file 188349 bytes/second for reading the file ftp-benchmark: ncftp>mget test.tgz Receiving file: test.tgz 100% 0 2576406 bytes. ETA: 0:00 test.tgz: 2576406 bytes received in 157.45 seconds, 15.98 K/s. ^^^^^^^^^ telnet: When i cat a large ascii-file in a telnet session the transfer stops sometimes for 1-2 secs. ping-test: % ping -c 100000 -f host2 PING host2 (10.0.0.11): 56 data bytes ..................... --- host2 ping statistics --- 100020 packets transmitted, 100000 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.294/0.520/17.794/0.300 ms (seems to be OK) - cable + termination is 100% ok - Filetransfers with Windows 95 on both sides are perfecly fast. - There's no additional network load (tested with tcpdump) - This performance problem exist since serval months Can someone give me a hint? Anyone with similar problems? Boris -- balu@dva.in-berlin.de Boris Staeblow From owner-freebsd-current Thu Aug 14 07:58:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA21640 for current-outgoing; Thu, 14 Aug 1997 07:58:27 -0700 (PDT) Received: from onyx.atipa.com (user13529@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA21629 for ; Thu, 14 Aug 1997 07:58:21 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 14 Aug 1997 15:01:04 -0000 Date: Thu, 14 Aug 1997 09:01:03 -0600 (MDT) From: Atipa X-Sender: freebsd@dot.ishiboo.com To: Boris Staeblow cc: current@FreeBSD.ORG Subject: Re: Very slow Ethernet-performance with de0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Have you tried the alternate de driver from ftp.3amsoftware.com? I have found that is works really well, especially on not-so-common NICs (generics, etc.). The timings can be off on the standard driver. I have also had very similar results with a NIC that went bad during a sup. That was the hardest thing in the world to diagnose, since my constant had been, "well, I KNOW the ethernet card works since it was fine yesterday..." After 6 hours, I finally decided to try a different card and it fixed eveything. Kevin On Thu, 14 Aug 1997, Boris Staeblow wrote: > > I've big problems with performance on my local network. > Both machines (P166/P200 MMX, 430 HX) running (very) current (as of Aug 13) > - same DEC21041 based network cards. No special kernel-configs. > > host1: > ------ > de0: rev 0x11 int a irq 9 on pci0.10.0 > de0: 21041 [10Mb/s] pass 1.1 > de0: address 00:80:ad:1c:af:a8 > > de0: flags=8843 mtu 1500 > inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 > ether 00:80:ad:1c:af:a8 > media: autoselect (10base2/BNC) status: active > > host2: > ------ > > de0: rev 0x11 int a irq 11 on pci0.13.0 > de0: 21041 [10Mb/s] pass 1.1 > de0: address 00:80:ad:1c:ac:97 > > de0: flags=8843 mtu 1500 > inet 10.0.0.11 netmask 0xffffff00 broadcast 10.0.0.255 > ether 00:80:ad:1c:ac:97 > media: autoselect (10base2/BNC) status: active > > > benchmark on a NFS-mounted drive: > > % iozone 10 > > Writing the 10 Megabyte file, 'iozone.tmp'...16.531250 seconds > Reading the file...55.671875 seconds > > IOZONE performance measurements: > 634299 bytes/second for writing the file > 188349 bytes/second for reading the file > > ftp-benchmark: > > ncftp>mget test.tgz > Receiving file: test.tgz > 100% 0 2576406 bytes. ETA: 0:00 > test.tgz: 2576406 bytes received in 157.45 seconds, 15.98 K/s. > ^^^^^^^^^ > > telnet: > > When i cat a large ascii-file in a telnet session the transfer stops > sometimes for 1-2 secs. > > ping-test: > > % ping -c 100000 -f host2 > PING host2 (10.0.0.11): 56 data bytes > ..................... > --- host2 ping statistics --- > 100020 packets transmitted, 100000 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.294/0.520/17.794/0.300 ms > > (seems to be OK) > > - cable + termination is 100% ok > - Filetransfers with Windows 95 on both sides are perfecly fast. > - There's no additional network load (tested with tcpdump) > - This performance problem exist since serval months > > Can someone give me a hint? Anyone with similar problems? > > Boris > > -- > balu@dva.in-berlin.de > Boris Staeblow > From owner-freebsd-current Thu Aug 14 09:12:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26602 for current-outgoing; Thu, 14 Aug 1997 09:12:44 -0700 (PDT) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26593 for ; Thu, 14 Aug 1997 09:12:39 -0700 (PDT) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.6/3.5Wpl3) with ESMTP id BAA01115; Fri, 15 Aug 1997 01:12:21 +0900 (JST) Message-Id: <199708141612.BAA01115@gneiss.eps.nagoya-u.ac.jp> To: dg@root.com Cc: current@FreeBSD.ORG Subject: Re: Read-only mount of union filesystem From: KATO Takenori In-Reply-To: Your message of "Wed, 13 Aug 1997 21:59:44 -0700" References: <199708140459.VAA23455@implode.root.com> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 15 Aug 1997 01:12:21 +0900 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > same as it is in Lite-2). For information on why it is this way, see PR#782. > In my opinion, the current structure is correct. Does this mean that files system is unmounted between getvnode/namei and referencing v_mount? ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Thu Aug 14 11:05:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA02942 for current-outgoing; Thu, 14 Aug 1997 11:02:43 -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 LAA02930 for ; Thu, 14 Aug 1997 11:02:34 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wz4DW-0000h6-00; Thu, 14 Aug 1997 12:01:50 -0600 To: current@freebsd.org Subject: LPR/LPD in -current Date: Thu, 14 Aug 1997 12:01:50 -0600 From: Warner Losh Message-Id: Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings, lpr/lpd in current seem to be working for me. I've not seen any complaints in the last two weeks or so, so I'd like to merge the changes I've made there back into -stable. Any objections? Warner From owner-freebsd-current Thu Aug 14 11:32:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04328 for current-outgoing; Thu, 14 Aug 1997 11:32:42 -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 LAA04323; Thu, 14 Aug 1997 11:32:36 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id LAA01437; Thu, 14 Aug 1997 11:32:31 -0700 (PDT) To: wollman@freebsd.org cc: current@freebsd.org Subject: Well, I guess it's about time I mentioned this little problem... Date: Thu, 14 Aug 1997 11:32:30 -0700 Message-ID: <1433.871583550@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David G. and I poked around at the problem a bit during a recent phone conversation of ours, but nothing really came to mind as a solution. Here's the scenario: Box G, a FreeBSD 3.0-current machine, contains an SMC ethernet card configured as ed0 and a standard serial port with a ISDN Terminal Adaptor running at 115.2KBaud and configured as sl0. This slip line goes to another ISDN TA which is plugged into hub.freebsd.org, everything on that side configured pretty much the same way. Box A, a FreeBSD 2.2-stable machine, talks to box G over its own PCI NIC, configured as de0. Box G is configured as this machine's default gateway and it's your basic, standard "n machines on a LAN being served by one gateway machine with an ISDN connection" situation. Now here's where it gets weird. By and large, everything works just fine on this LAN and the FreeBSD/ISDN machine has been serving rather happily in this role for over a year. The only flies in the ointment have been certain URLs which just never seemed to be reachable from Box A, whether the browser was Netscape or Lynx or whatever. At first I just wrote this off to the flakey nature of the net in general, but then I started getting suspicious when I noticed that these "stubborn URLs" actually worked just fine from Box G or from hub.freebsd.org, it just failed to work from Box A. During my conversation with David, he suggested that I drop the MTU on box A's ethernet interface from 1500 to 500 and TADA! Suddenly these URLs (one of which is http://www.sunlabs.com/) could be visited just fine from box A, no problems. So the question is: What is it about the MTU size of the ethernet interface on box A which effects the ability of the gateway box G to pass traffic to box A? Here's the tcpdump trace of the attempt to connect from lynx when the MTU of ed0 on box A is set to 1500: 11:30:53.276132 time.cdrom.com.1216 > rocky.sunlabs.com.http: S 2243214515:2243214515(0) win 16384 (DF) 11:30:53.501585 rocky.sunlabs.com.http > time.cdrom.com.1216: S 294104724:294104724(0) ack 2243214516 win 8760 (DF) 11:30:53.501696 time.cdrom.com.1216 > rocky.sunlabs.com.http: . ack 1 win 16384 (DF) 11:30:53.503656 time.cdrom.com.1216 > rocky.sunlabs.com.http: . 1:513(512) ack 1 win 16384 (DF) 11:30:53.797419 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 513 win 8760 (DF) 11:30:53.797508 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) 11:30:56.480098 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) 11:30:56.698495 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 667 win 8760 (DF) And now with the MTU of ed0 on box A set to 500: 11:30:15.890262 time.cdrom.com.1215 > rocky.sunlabs.com.http: S 2235648945:2235648945(0) win 16384 (DF) 11:30:16.075893 rocky.sunlabs.com.http > time.cdrom.com.1215: S 288164975:288164975(0) ack 2235648946 win 9200 (DF) 11:30:16.075990 time.cdrom.com.1215 > rocky.sunlabs.com.http: . ack 1 win 16560 (DF) 11:30:16.077957 time.cdrom.com.1215 > rocky.sunlabs.com.http: . 1:461(460) ack 1 win 16560 (DF) 11:30:16.331161 rocky.sunlabs.com.http > time.cdrom.com.1215: . ack 461 win 9200 (DF) 11:30:16.331258 time.cdrom.com.1215 > rocky.sunlabs.com.http: P 461:667(206) ack 1 win 16560 (DF) 11:30:16.640626 rocky.sunlabs.com.http > time.cdrom.com.1215: P 1:461(460) ack 667 win 9200 (DF) 11:30:16.780091 time.cdrom.com.1215 > rocky.sunlabs.com.http: . ack 461 win 16560 (DF) 11:30:17.036760 rocky.sunlabs.com.http > time.cdrom.com.1215: . 461:921(460) ack 667 win 9200 (DF) 11:30:17.078112 rocky.sunlabs.com.http > time.cdrom.com.1215: . 921:1381(460) ack 667 win 9200 (DF) Any ideas on what I should try here to further debug this oddness? Thanks! Jordan From owner-freebsd-current Thu Aug 14 11:40:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04963 for current-outgoing; Thu, 14 Aug 1997 11:40:49 -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 LAA04947 for ; Thu, 14 Aug 1997 11:40:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA17226; Thu, 14 Aug 1997 10:54:34 -0700 From: Terry Lambert Message-Id: <199708141754.KAA17226@phaeton.artisoft.com> Subject: Re: Read-only mount of union filesystem To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Thu, 14 Aug 1997 10:54:34 -0700 (MST) Cc: dg@root.com, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <199708140849.RAA04702@gneiss.eps.nagoya-u.ac.jp> from "KATO Takenori" at Aug 14, 97 05:49:46 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I changed the behavior in FreeBSD to what it is now (which is also the > > same as it is in Lite-2). For information on why it is this way, see PR#782. > > In my opinion, the current structure is correct. > > I understand why vfs layer shouldn't reference v_mount. But, IMHO, fs > independent operation should be in upper layer. The problem in PR#782 > may be solved by following method: > > 1. Prepare special mount struct whose mnt_flag is or'ed by special > flag (e.g., MNT_DEAD). > 2. When vnode is cleaned, v_mount points the special mount struct > instead of beeing NULL'ed. > 3. vfs layer checks MNT_RDONLY and MNT_DEAD. Yes. The current arrangement of the mount code is awful; each FS has duplicate mount code, and some have a working root mount and some don't. IMO, the distinction between mounting root vs. mounting non-root, and *especially* the NFS export manipulations, is terribly artificial. In my ideal world, the mount would take place, and there would be a seperate, upper-level mapping of the resulting mountpoint vnode into the FS hierarchy afterwards. It would be this mapping which would do the NFS export manipulations, and handle the "root" vs. "non-root" distinctions. 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-current Thu Aug 14 11:40:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04955 for current-outgoing; Thu, 14 Aug 1997 11:40:49 -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 LAA04944 for ; Thu, 14 Aug 1997 11:40:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA17240; Thu, 14 Aug 1997 10:56:44 -0700 From: Terry Lambert Message-Id: <199708141756.KAA17240@phaeton.artisoft.com> Subject: Re: kernel profiling data... To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Thu, 14 Aug 1997 10:56:44 -0700 (MST) Cc: phk@dk.tfs.com, current@FreeBSD.ORG In-Reply-To: <2685.871556693@critter.dk.tfs.com> from "Poul-Henning Kamp" at Aug 14, 97 01:04:53 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Argh! integer overflow :-( > > Here is the correct data: Hee hee... I *thought* "VOP_ISLOCKED" was pretty damn high up... 8-) 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-current Thu Aug 14 12:48:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08570 for current-outgoing; Thu, 14 Aug 1997 12:48:01 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08561 for ; Thu, 14 Aug 1997 12:47:51 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id PAA15776; Thu, 14 Aug 1997 15:46:45 -0400 (EDT) Date: Thu, 14 Aug 1997 15:46:45 -0400 (EDT) From: Charles Henrich Message-Id: <199708141946.PAA15776@crh.cl.msu.edu> To: jkh@time.cdrom.com, freebsd-current@freebsd.org Subject: Re: Well, I guess it's about time I mentioned this little problem... Newsgroups: lists.freebsd.current References: <5svn1t$qq6$1@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 CURRENT #1 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.current you write: >Any ideas on what I should try here to further debug this oddness? I had a similar problem with SMC cards and some ancient IBM router equipment, setting the MTU to just under 1500 (1450/1480ish) solved the problem. My guess was that the internal buffers in the IBM were broken by being 1500 instead of (1524?) for ethernet packets.. Perhaps it is FreeBSD that is broken? This first showed up when we moved from 2.1 to 2.1.7. -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-current Thu Aug 14 13:51:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA12750 for current-outgoing; Thu, 14 Aug 1997 13:51: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 NAA12742; Thu, 14 Aug 1997 13:51:00 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA06701; Thu, 14 Aug 1997 22:51:07 +0200 (MEST) From: Søren Schmidt Message-Id: <199708142051.WAA06701@sos.freebsd.dk> Subject: Re: Well, I guess it's about time I mentioned this little problem... In-Reply-To: <1433.871583550@time.cdrom.com> from "Jordan K. Hubbard" at "Aug 14, 97 11:32:30 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 14 Aug 1997 22:51:07 +0200 (MEST) Cc: wollman@FreeBSD.ORG, current@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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > David G. and I poked around at the problem a bit during a recent phone > conversation of ours, but nothing really came to mind as a solution. > > Here's the scenario: > > Box G, a FreeBSD 3.0-current machine, contains an SMC ethernet card > configured as ed0 and a standard serial port with a ISDN Terminal > Adaptor running at 115.2KBaud and configured as sl0. This slip line > goes to another ISDN TA which is plugged into hub.freebsd.org, > everything on that side configured pretty much the same way. > > Box A, a FreeBSD 2.2-stable machine, talks to box G over its own PCI > NIC, configured as de0. Box G is configured as this machine's default > gateway and it's your basic, standard "n machines on a LAN being > served by one gateway machine with an ISDN connection" situation. > > Now here's where it gets weird. By and large, everything works just > fine on this LAN and the FreeBSD/ISDN machine has been serving rather > happily in this role for over a year. The only flies in the ointment > have been certain URLs which just never seemed to be reachable from > Box A, whether the browser was Netscape or Lynx or whatever. At first > I just wrote this off to the flakey nature of the net in general, but > then I started getting suspicious when I noticed that these "stubborn > URLs" actually worked just fine from Box G or from hub.freebsd.org, it > just failed to work from Box A. During my conversation with David, he > suggested that I drop the MTU on box A's ethernet interface from 1500 > to 500 and TADA! Suddenly these URLs (one of which is > http://www.sunlabs.com/) could be visited just fine from box A, no > problems. Looks an awfull lot like the problem I have with running cvsup.. Wheneven I try my gateway machine (2.2.2) gets hosed at just lets avery other tcp packet through :(, setting the MTU lower helps but does not entirely cure the problem. I'm using userlevel ppp though so there is a bit difference... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Thu Aug 14 14:42:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA15156 for current-outgoing; Thu, 14 Aug 1997 14:42:33 -0700 (PDT) Received: from critter.dk.tfs.com (critter.phk.freebsd.dk [195.8.129.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15151; Thu, 14 Aug 1997 14:42:23 -0700 (PDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.6/8.8.5) with ESMTP id XAA03901; Thu, 14 Aug 1997 23:41:48 +0200 (CEST) To: "Jordan K. Hubbard" cc: wollman@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Well, I guess it's about time I mentioned this little problem... In-reply-to: Your message of "Thu, 14 Aug 1997 11:32:30 PDT." <1433.871583550@time.cdrom.com> Date: Thu, 14 Aug 1997 23:41:48 +0200 Message-ID: <3899.871594908@critter.dk.tfs.com> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <1433.871583550@time.cdrom.com>, "Jordan K. Hubbard" writes: >David G. and I poked around at the problem a bit during a recent phone >conversation of ours, but nothing really came to mind as a solution. > >Any ideas on what I should try here to further debug this oddness? I cannot run cvsup from my laptop using usermode ppp over a serial line, unless I reduce the mtu of the tun0 interface. reducing it to 1200 works reliably. Are we trying to send oversize packets under some circumstances ? -- 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-current Thu Aug 14 15:00:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA16248 for current-outgoing; Thu, 14 Aug 1997 15:00:15 -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 PAA16240; Thu, 14 Aug 1997 15:00:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA19308; Thu, 14 Aug 1997 14:54:39 -0700 From: Terry Lambert Message-Id: <199708142154.OAA19308@phaeton.artisoft.com> Subject: Re: Well, I guess it's about time I mentioned this little problem... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 14 Aug 1997 14:54:39 -0700 (MST) Cc: wollman@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <1433.871583550@time.cdrom.com> from "Jordan K. Hubbard" at Aug 14, 97 11:32:30 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > During my conversation with David, he > suggested that I drop the MTU on box A's ethernet interface from 1500 > to 500 and TADA! Suddenly these URLs (one of which is > http://www.sunlabs.com/) could be visited just fine from box A, no > problems. > > So the question is: What is it about the MTU size of the ethernet > interface on box A which effects the ability of the gateway box G to > pass traffic to box A? Well, for my first wild guess, I'd like to propose that you disable the 1323/1644 stuff on the boxes where it's on, and try again, if possible... The act of lowering the MTU is probably resulting in fragging of the packets which come in at a higher MTU, and as such, disabling the data+ACK stuff (if it's on -- logically, you can't leave the ACK in the first packet if it's not the only packet). It *could* be a FreeBSD bug, but I think it's probably the other end, if I had to guess (which I do ;-)). 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-current Thu Aug 14 17:46:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25435 for current-outgoing; Thu, 14 Aug 1997 17:46:23 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA25427; Thu, 14 Aug 1997 17:46:15 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id UAA06890; Thu, 14 Aug 1997 20:46:13 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id UAA19318; Thu, 14 Aug 1997 20:46:13 -0400 (EDT) To: "Jordan K. Hubbard" cc: wollman@FreeBSD.ORG, current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Well, I guess it's about time I mentioned this little problem... In-reply-to: Your message of "Thu, 14 Aug 1997 11:32:30 PDT." <1433.871583550@time.cdrom.com> Date: Thu, 14 Aug 1997 20:46:12 -0400 Message-ID: <19316.871605972@orion.webspan.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote in message ID <1433.871583550@time.cdrom.com>: > So the question is: What is it about the MTU size of the ethernet > interface on box A which effects the ability of the gateway box G to > pass traffic to box A? I think there is something missing here ... namely the MTU of the SLIP line (the 115k ISDN) is 552 vs his ethernets 1500. The tcpdumps don't show any ICMP traffic from the gateway, so either the tcpdump filter was incorrect or (when in gateway mode) our path MTU discovery support is broken... Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-current Thu Aug 14 17:46:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25470 for current-outgoing; Thu, 14 Aug 1997 17:46:41 -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 RAA25463; Thu, 14 Aug 1997 17:46:37 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53165(5)>; Thu, 14 Aug 1997 17:45:48 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177512>; Thu, 14 Aug 1997 17:45:08 -0700 To: "Jordan K. Hubbard" cc: wollman@freebsd.org, current@freebsd.org Subject: Re: Well, I guess it's about time I mentioned this little problem... In-reply-to: Your message of "Thu, 14 Aug 97 11:32:30 PDT." <1433.871583550@time.cdrom.com> Date: Thu, 14 Aug 1997 17:45:01 PDT From: Bill Fenner Message-Id: <97Aug14.174508pdt.177512@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My bet is broken path mtu discovery in the opposite direction. >11:30:53.276132 time.cdrom.com.1216 > rocky.sunlabs.com.http: S 2243214515:2243214515(0) win 16384 s 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) >11:30:53.501585 rocky.sunlabs.com.http > time.cdrom.com.1216: S 294104724:294104724(0) ack 2243214516 > win 8760 (DF) >11:30:53.501696 time.cdrom.com.1216 > rocky.sunlabs.com.http: . ack 1 win 16384 (DF) >11:30:53.503656 time.cdrom.com.1216 > rocky.sunlabs.com.http: . 1:513(512) ack 1 win 16384 (DF) >11:30:53.797419 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 513 win 8760 (DF) >11:30:53.797508 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) For some reason, we send only 512 bytes in the first packet, but that's probably not interesting in this case since we send a small first packet the second time. What's interesting is that in the one that works, the return ACK for byte #667 is piggybacked on the other end's MSS-sized data packet -- so, if in this one, the ACK for byte #667 is also piggybacked on the MSS-sized data packet, it's a 1500-byte packet, which is apparently getting dropped without proper notification on the way back to us. >11:30:56.480098 time.cdrom.com.1216 > rocky.sunlabs.com.http: P 513:667(154) ack 1 win 16384 (DF) >11:30:56.698495 rocky.sunlabs.com.http > time.cdrom.com.1216: . ack 667 win 8760 (DF) We retransmit because we haven't gotten an ACK, and rocky replies with a dataless ACK. It doesn't include any data since it's still doing slow-start towards us. rocky keeps retransmitting that first MSS(MTU)-sized packet, it keeps getting dropped and MTU discovery isn't working so we never hear from it again. Bill From owner-freebsd-current Thu Aug 14 18:06:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26408 for current-outgoing; Thu, 14 Aug 1997 18:06:16 -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 SAA26403; Thu, 14 Aug 1997 18:06:06 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52847(4)>; Thu, 14 Aug 1997 18:05:31 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177512>; Thu, 14 Aug 1997 18:05:25 -0700 To: "Jordan K. Hubbard" cc: wollman@freebsd.org, current@freebsd.org Subject: Re: Well, I guess it's about time I mentioned this little problem... In-reply-to: Your message of "Thu, 14 Aug 97 11:32:30 PDT." <1433.871583550@time.cdrom.com> Date: Thu, 14 Aug 1997 18:05:17 PDT From: Bill Fenner Message-Id: <97Aug14.180525pdt.177512@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for forgetting to answer the most important Q: "Jordan K. Hubbard" wrote: >Any ideas on what I should try here to further debug this oddness? tcpdump on the network on the other end of G's ISDN line (I assume this is the hub/freefall/ampere net) and see if you see the packets from rocky, and if you see ICMP errors from G2 (which I assume is hub), and if your router to the outside world (which I assume is gate-free.cdrom.com) is configured to drop them (bad idea). I assume the PMTU to G2 is at least 1500 and the ISDN link has the narrowest MTU on the path? Bill (Note that when talking about network problems, it's usually best to give real names instead of A and G so that other people can do debugging without having to guess what machines you're talking about) From owner-freebsd-current Thu Aug 14 18:33:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28010 for current-outgoing; Thu, 14 Aug 1997 18:33:23 -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 SAA28005; Thu, 14 Aug 1997 18:33:20 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.6/8.6.9) with ESMTP id SAA03096; Thu, 14 Aug 1997 18:33:14 -0700 (PDT) To: Bill Fenner cc: wollman@freebsd.org, current@freebsd.org Subject: Re: Well, I guess it's about time I mentioned this little problem... In-reply-to: Your message of "Thu, 14 Aug 1997 17:45:01 PDT." <97Aug14.174508pdt.177512@crevenia.parc.xerox.com> Date: Thu, 14 Aug 1997 18:33:14 -0700 Message-ID: <3092.871608794@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > My bet is broken path mtu discovery in the opposite direction. Sounds quite plausible to me. Erm... So, what now? :-) Jordan From owner-freebsd-current Thu Aug 14 18:36:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28175 for current-outgoing; Thu, 14 Aug 1997 18:36:21 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA28161 for ; Thu, 14 Aug 1997 18:36:01 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA08481; Thu, 14 Aug 1997 21:35:50 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA21417; Thu, 14 Aug 1997 21:35:17 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA20620; Thu, 14 Aug 1997 21:34:47 -0400 Message-Id: <199708150134.AA20620@iluvatar.unx.sas.com> Subject: Missing/Bad library during X install To: freebsd-current@freebsd.org Date: Thu, 14 Aug 1997 21:34:47 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just tried installing X on a machine that I haven't used for awhile, but ran into a missing library while trying to run XF86Setup: libtcl.so.75.1 Oh no... I think... lot's of tcl stuff going on... Well, I simlinked what I thought might work: lrwxrwxrwx 1 root bin 17 Aug 13 11:08 libtcl.so.75.1 -> ./libtcl80.so.1.2 Well, XF86Setup started to come up, and then locked... reboot time.. Does anyone have any quick ideas? I don't really want to rebuild the entire X distribution to bring the library usage up to date... Thanks, John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Thu Aug 14 18:41:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28437 for current-outgoing; Thu, 14 Aug 1997 18:41:13 -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 SAA28432; Thu, 14 Aug 1997 18:40:58 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52033(3)>; Thu, 14 Aug 1997 18:40:24 PDT Received: by crevenia.parc.xerox.com id <177512>; Thu, 14 Aug 1997 18:40:12 -0700 From: Bill Fenner To: fenner@parc.xerox.com, jkh@time.cdrom.com Subject: Re: Well, I guess it's about time I mentioned this little problem... Cc: current@freebsd.org, wollman@freebsd.org Message-Id: <97Aug14.184012pdt.177512@crevenia.parc.xerox.com> Date: Thu, 14 Aug 1997 18:40:03 PDT Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> My bet is broken path mtu discovery in the opposite direction. > >Sounds quite plausible to me. Erm... So, what now? :-) Uh... good question. It doesn't seem to be anything wrong with your configuration, since the traceroute from TCP/IP Illustrated v1 can discover your PMTU from here: traceroute to time.cdrom.com (204.216.27.226), 30 hops max outgoing MTU = 1500 1 ciscokid (192.216.54.234) 9 ms 4 ms 4 ms 2 0 (131.119.38.165) 17 ms 19 ms 16 ms 3 paloalto-br2.bbnplanet.net (131.119.0.194) 16 ms 16 ms 16 ms 4 sanjose1-br1.bbnplanet.net (4.0.1.9) 18 ms 18 ms 19 ms 5 198.32.136.10 (198.32.136.10) 21 ms 22 ms 24 ms 6 165.113.0.249 (165.113.0.249) 25 ms 29 ms 24 ms 7 165.113.55.2 (165.113.55.2) 43 ms 30 ms 44 ms 8 165.113.118.2 (165.113.118.2) 43 ms 38 ms 49 ms 9 hub.FreeBSD.ORG (204.216.27.18) 42 ms 52 ms 43 ms 10 hub.FreeBSD.ORG (204.216.27.18) 36 ms fragmentation required and DF set, next hop MTU = 552 10 jkh-sl0-h.cdrom.com (204.216.27.194) 173 ms 169 ms 174 ms 11 time.cdrom.com (204.216.27.226) 182 ms 178 ms 180 ms The only other thing to do is to complain to the administrators of rocky.sunlabs.com and ask them to fix their network or host implementation. Last time I tried to find someone at sunlabs.com to talk to about their strange FTP server, I ended up hitting a "don't bother us, we don't have time to support this service" wall... Bill From owner-freebsd-current Thu Aug 14 19:45:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA01804 for current-outgoing; Thu, 14 Aug 1997 19:45:51 -0700 (PDT) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA01799 for ; Thu, 14 Aug 1997 19:45:45 -0700 (PDT) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Thu, 14 Aug 1997 21:45:44 -0500 Message-ID: From: Raul Zighelboim To: "'Jordan K. Hubbard'" Cc: current@FreeBSD.ORG Subject: RE: Well, I guess it's about time I mentioned this little problem ... Date: Thu, 14 Aug 1997 21:45:42 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So the question is: What is it about the MTU size of the ethernet > interface on box A which effects the ability of the gateway box G to > pass traffic to box A? > [Raul Zighelboim] I have seen this exact porblem and similar solution (reducing the MTU size) except that.... - FreeeBSD server was acting as a proxy/socks server running either fwtk or nec socks. - the ppp link was not on the FreeBSD (2.2.2-RELEASE and/or 2.1.5-RELEASE), but out of an Ascend pipeline 50. The FreeBSD box had two Etehrnet interfaces, 2 3C509 ISA cards on two isolated networks.... I was able to load any page from the FreeBSD server. But some pages on the internal network would just not load. an example of a 'problen page' was http://www.uscourts.gov. Just my 0.05cents on the subject... From owner-freebsd-current Thu Aug 14 20:08:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA02695 for current-outgoing; Thu, 14 Aug 1997 20:08:54 -0700 (PDT) Received: from shell.monmouth.com (root@shell.monmouth.com [205.164.220.9]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02686 for ; Thu, 14 Aug 1997 20:08:51 -0700 (PDT) Received: from i4got.lakewood.com (fh-ppp39.monmouth.com [205.164.221.71]) by shell.monmouth.com (8.8.5/8.7.3) with ESMTP id XAA09578; Thu, 14 Aug 1997 23:06:18 -0400 (EDT) Received: (from pechter@localhost) by i4got.lakewood.com id XAA00435 (8.8.5/IDA-1.6); Thu, 14 Aug 1997 23:08:46 -0400 (EDT) From: Bill Pechter Message-ID: <199708150308.XAA00435@i4got.lakewood.com> Subject: Re: Well, I guess it's about time I mentioned this little problem ... In-Reply-To: from Raul Zighelboim at "Aug 14, 97 09:45:42 pm" To: mango@staff.communique.net (Raul Zighelboim) Date: Thu, 14 Aug 1997 23:08:46 -0400 (EDT) Cc: freebsd-current@freebsd.org Reply-to: pechter@lakewood.com X-Phone-Number: 908-389-3592 X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > - FreeeBSD server was acting as a proxy/socks server running > either fwtk or nec socks. > - the ppp link was not on the FreeBSD (2.2.2-RELEASE and/or > 2.1.5-RELEASE), but out of an Ascend pipeline 50. The FreeBSD box had > two Etehrnet interfaces, 2 3C509 ISA cards on two isolated networks.... > > I was able to load any page from the FreeBSD server. But some > pages on the internal network would just not load. an example of a > 'problen page' was http://www.uscourts.gov. > > Just my 0.05cents on the subject... > I see the exact thing under 2.2.2-Current with Microsoft TCP clients. However, lowering the mtu to 1024 -- speeds everything up and it works fine. The FreeBSD box is running a WD8216 and the clients are NE2000's. Bill ------------------------------------------------------------------------------ Bill Pechter | 17 Meredith Drive Tinton Falls, NJ 07724 | 908-389-3592 pechter@lakewood.com | Save computing history, give an old geek old hardware. This msg brought to you by the letters PDP and the number 11. From owner-freebsd-current Thu Aug 14 20:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03169 for current-outgoing; Thu, 14 Aug 1997 20:23:02 -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 UAA03157; Thu, 14 Aug 1997 20:22:53 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id UAA00376; Thu, 14 Aug 1997 20:22:47 -0700 (PDT) Message-Id: <199708150322.UAA00376@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Stefan Esser cc: Kenneth Merry , multimedia@freebsd.org, freebsd-current@freebsd.org Subject: Re: YES!, bktr now works 8) In-reply-to: Your message of "Thu, 14 Aug 1997 10:10:56 +0200." <19970814101056.02120@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Aug 1997 20:22:47 -0700 From: Amancio Hasty Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I trust your judgment on the proposed API: enables = pci_enable(PCI_MEM|PCI_PORT|PCI_DMA); enables = pci_disable(PCI_MEM|PCI_PORT|PCI_DMA); Don't worry I understand the issues involved and I don't mind making the calls to enable/disable the bt848 board. Care to patch the pci interface so I can then check in my latest bt848 driver? Also, have you documented your PCI interface? Got to go something cool is on my FreeBSD TV 8) Cheers, Amancio >From The Desk Of Stefan Esser : > On Aug 13, Amancio Hasty wrote: > > > > fun = pci_conf_read(tag, PCI_COMMAND_STATUS_REG); > > > > pci_conf_write(tag, PCI_COMMAND_STATUS_REG, fun | 4); > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ add this ^^^^^^^^^^^^^^^^^^^ > > Well, I'm not sure about the name, but a function that > enables or disables bits in the PCI command register > might be a good idea. > > How about: > > enables = pci_enable(PCI_MEM|PCI_PORT|PCI_DMA); > enables = pci_disable(PCI_MEM|PCI_PORT|PCI_DMA); > > where the result is in fact the low order three bits > from the command register after trying to set them > according to the parameter ? > > Regards, STefan From owner-freebsd-current Thu Aug 14 20:38:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03733 for current-outgoing; Thu, 14 Aug 1997 20:38:53 -0700 (PDT) Received: from veda.is (root@veda.is [193.4.230.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA03726 for ; Thu, 14 Aug 1997 20:38:48 -0700 (PDT) Received: from ubiq.veda.is (adam@ubiq.veda.is [193.4.230.60]) by veda.is (8.8.7/8.8.5) with ESMTP id DAA20206; Fri, 15 Aug 1997 03:38:30 GMT From: Adam David Received: (from adam@localhost) by ubiq.veda.is (8.8.7/8.8.5) id DAA07618; Fri, 15 Aug 1997 03:38:28 GMT Message-Id: <199708150338.DAA07618@ubiq.veda.is> Subject: VirtualHost in Apache 1.2.1 ? To: freebsd-current@freebsd.org Date: Fri, 15 Aug 1997 03:38:27 +0000 (GMT) Cc: apache-bugs@apache.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [cross-posted, please observe relevant Cc: in replies] I recently upgraded to Apache 1.2.1 and noticed that my VirtualHost directives stopped working. This is freshly compiled under FreeBSD 3.0-current. Is this a known problem or is something weird going on? (I'd rather check this out before delving into the guts of it). Port 80 BindAddress foo.bar.com ServerName foo.bar.com ServerName a.b.com ... ServerName foo.bar.com ... There are no listen directives anywhere and no BindAddress directives inside the VirtualHost sections. The above config listens on foo.bar.com:80 only, as if the VirtualHost sections weren't there. This setup was working fine before the upgrade. There are no pertinent errors in the logs. -- Adam David From owner-freebsd-current Thu Aug 14 21:05:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA04901 for current-outgoing; Thu, 14 Aug 1997 21:05:31 -0700 (PDT) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04890 for ; Thu, 14 Aug 1997 21:05:25 -0700 (PDT) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id XAA17019 for ; Thu, 14 Aug 1997 23:04:47 -0500 (CDT) Received: from sil-wa2-25.ix.netcom.com(206.214.137.57) by dfw-ix2.ix.netcom.com via smap (V1.3) id sma016991; Thu Aug 14 23:04:21 1997 Message-ID: <33F3D541.41C67EA6@ix.netcom.com> Date: Thu, 14 Aug 1997 21:04:17 -0700 From: "Thomas D. Dean" X-Mailer: Mozilla 3.01 (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: cvsup Failure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I attempted to update my sourece tree with cvsup. cvsup failed with the message: *** *** runtime error: *** ASSERT failed *** file "../src/RCSDelta.m3", line 182 *** The command line was cvsup /usr/sup/current-supfile and, current-supfile is *default host=cvsup.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress src-all src-contrib-crypto src-eBones src-secure ports-all What can I do to correct this error? It is repeatable. From owner-freebsd-current Thu Aug 14 21:37:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06372 for current-outgoing; Thu, 14 Aug 1997 21:37:45 -0700 (PDT) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA06367 for ; Thu, 14 Aug 1997 21:37:43 -0700 (PDT) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id XAA22535 for ; Thu, 14 Aug 1997 23:37:12 -0500 (CDT) Received: from sil-wa2-25.ix.netcom.com(206.214.137.57) by dfw-ix2.ix.netcom.com via smap (V1.3) id sma022522; Thu Aug 14 23:36:51 1997 Message-ID: <33F3DCDF.167EB0E7@ix.netcom.com> Date: Thu, 14 Aug 1997 21:36:47 -0700 From: "Thomas D. Dean" X-Mailer: Mozilla 3.01 (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: FreeBSDCurrent Subject: Make fails After Update Source Tree. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I fetched the CVS tree, last week. make world completed OK. I updated the CVS tree with -current. The src-all part of the update completed OK make failed when building lib/libncurses/libncurses.a, complaining about a missing version.h. I did 'touch lib/libncurses/version.h' and the build completed. Is there a missing file? make terminated with a fatal error: ===> bin/chmod ===> bin/cp ===> bin/csh ===> bin/date cc -O -Wall -c /usr/src/bin/date/date.c /usr/src/bin/date/date.c: In function `setthetime': /usr/src/bin/date/date.c:183: warning: implicit declaration of function `strptime' /usr/src/bin/date/date.c:183: warning: assignment makes pointer from integer without a cast cc -O -Wall -c /usr/src/bin/date/vary.c cc -O -Wall -static -o date date.o netdate.o vary.o -lutil date.o: Undefined symbol `_strptime' referenced from text segment *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 1 error Where is strptime? No man, No apropos, Not in /usr/lib/* From owner-freebsd-current Thu Aug 14 21:50:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06829 for current-outgoing; Thu, 14 Aug 1997 21:50:42 -0700 (PDT) Received: from venus.GAIANET.NET (vince@venus.GAIANET.NET [207.211.200.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA06816 for ; Thu, 14 Aug 1997 21:50:40 -0700 (PDT) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.8.5/8.8.5) with SMTP id VAA05377; Thu, 14 Aug 1997 21:51:08 -0700 (PDT) Date: Thu, 14 Aug 1997 21:51:07 -0700 (PDT) From: Vincent Poy To: "Thomas D. Dean" cc: current@FreeBSD.ORG Subject: Re: cvsup Failure In-Reply-To: <33F3D541.41C67EA6@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 14 Aug 1997, Thomas D. Dean wrote: > I attempted to update my sourece tree with cvsup. > > cvsup failed with the message: > > *** > *** runtime error: > *** ASSERT failed > *** file "../src/RCSDelta.m3", line 182 > *** > > The command line was cvsup /usr/sup/current-supfile > > and, current-supfile is > > *default host=cvsup.FreeBSD.org > *default base=/usr > *default prefix=/usr > *default release=cvs tag=. > *default delete use-rel-suffix > *default compress > src-all > src-contrib-crypto > src-eBones > src-secure > ports-all > > What can I do to correct this error? It is repeatable. This is from /usr/ports/www/apache-current. What I did was simply rm -rf /usr/ports/www/apache-current and then restarted cvsup again. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] From owner-freebsd-current Thu Aug 14 22:10:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08089 for current-outgoing; Thu, 14 Aug 1997 22:10:33 -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 WAA08082 for ; Thu, 14 Aug 1997 22:10:30 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id WAA00321 for ; Thu, 14 Aug 1997 22:10:29 -0700 (PDT) Message-Id: <199708150510.WAA00321@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: current@freebsd.org Subject: isa.c:isa_dmastatus(int chan) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Aug 1997 22:10:29 -0700 From: Amancio Hasty Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can someone delete the enclosed data from isa_dmastatus? isa_dmastatus(int chan) { u_long cnt = 0; int ffport, waport; u_long low1, high1, low2, high2; u_long ef; /* delete this block of code */ /* channel active? */ if ((dma_inuse & (1 << chan)) == 0) { printf("isa_dmastatus: channel %d not active\n", chan); return(-1); } /* still busy? */ if ((dma_busy & (1 << chan)) == 0) { return(0); } /* end of delete block */ ---- isa_dmastatus is really meant for the sound driver and we are using in auto dma mode. Also it is a bad idea to print diagnostic messages such as the above . Tnks, Amancio From owner-freebsd-current Thu Aug 14 22:12:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08205 for current-outgoing; Thu, 14 Aug 1997 22:12:30 -0700 (PDT) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA08179 for ; Thu, 14 Aug 1997 22:12:03 -0700 (PDT) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.8.5) with UUCP id XAA08049; Thu, 14 Aug 1997 23:11:15 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id XAA03502; Thu, 14 Aug 1997 23:10:37 -0600 (MDT) Date: Thu, 14 Aug 1997 23:10:37 -0600 (MDT) From: Marc Slemko To: Adam David cc: freebsd-current@FreeBSD.ORG, apache-bugs@apache.org Subject: Re: VirtualHost in Apache 1.2.1 ? In-Reply-To: <199708150338.DAA07618@ubiq.veda.is> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm not sure what version you upgraded from, but that isn't the way Apache works in 1.2. Don't recall how far you would have to go back. Think of BindAddress and Listen as ways to tell Apache which ports and IPs to bind to, and VirtualHost sections as telling Apache how to handle connections to those ports once it gets them. If a.b.com is on a different IP than foo.bar.com, your config will break because the server won't be listening on a.b.com. To get port 8080 to work as well, you need something like: Listen 80 Listen 8080 (you can't just add a Listen 8080 or port 80 will stop working) and you also want a Port 8080 in the 8080 VirtualHost section so things like redirects work correctly. Generally it is best to stay away from BindAddress. This is probably best asked on comp.infosystems.www.unix, since it probably isn't a bug and isn't FreeBSD related. On Fri, 15 Aug 1997, Adam David wrote: > [cross-posted, please observe relevant Cc: in replies] > > I recently upgraded to Apache 1.2.1 and noticed that my VirtualHost > directives stopped working. This is freshly compiled under FreeBSD > 3.0-current. Is this a known problem or is something weird going on? > (I'd rather check this out before delving into the guts of it). > > Port 80 > BindAddress foo.bar.com > ServerName foo.bar.com > > ServerName a.b.com > ... > > > ServerName foo.bar.com > ... > > > There are no listen directives anywhere and no BindAddress directives > inside the VirtualHost sections. The above config listens on foo.bar.com:80 > only, as if the VirtualHost sections weren't there. This setup was working > fine before the upgrade. > > There are no pertinent errors in the logs. > > -- > Adam David > From owner-freebsd-current Fri Aug 15 02:53:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA18583 for current-outgoing; Fri, 15 Aug 1997 02:53:28 -0700 (PDT) Received: from necropolis.org ([207.66.220.160]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA18572 for ; Fri, 15 Aug 1997 02:53:23 -0700 (PDT) Received: from localhost (edmond@localhost) by necropolis.org (8.8.7/8.8.5) with SMTP id CAA06370 for ; Fri, 15 Aug 1997 02:49:17 -0700 (PDT) X-Authentication-Warning: necropolis.org: edmond owned process doing -bs Date: Fri, 15 Aug 1997 02:49:15 -0700 (PDT) From: "Andrew N. Edmond" X-Sender: edmond@necropolis.org To: current@freebsd.org Subject: 3.0: problems with libc_r and native pthreads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I upgraded one of my single processor machines to FreeBSD 3.0 (august 11th SNAP) to test out the new native pthreads, and have a question to ask (or perhaps error to report). I wrote a multithreaded program that's running a thread with listen() and an accept() in a loop, that when hit reads about 512 bytes of data from the socket, spawns a new thread and goes back to accept() wait for another connection. Now, with mit-pthreads, I can throw a good 500 hits per second into this mechanism and it runs perfectly without any loss of data. If instead I use libc_r, I get this error message: error reading stream message: Resource temporarily unavailable error reading stream message: Resource temporarily unavailable error reading stream message: Resource temporarily unavailable error reading stream message: Resource temporarily unavailable error reading stream message: Resource temporarily unavailable This is generated from this code: listen(socketOpen, QUEUED_CONNECTS); do { ptrbuf = buf = (char *) malloc (PACKET_SIZE); bzero(buf, sizeof(buf)); msgSock = accept(socketOpen, 0, 0); if (msgSock == -1) perror ("error on accept"); else do { if ((nread = read(msgSock, ptrbuf, 256)) < 0) ---> perror("error reading stream message"); ptrbuf += nread; } while (nread != 0); close(msgSock); // add to thread pool tpool_add_work(threadPool, myFunction, (void *)buf); } while (1); I assume this is because there are not enough file descriptors available for some reason in libc_r (but there is in mit-pthreads!). I even set: #define FD_SETSIZE 8192 In the source of my program before any other includes. Is this a libc_r error or am I missing something? Andy ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: \-/ :::::::: Andrew N. Edmond - finger for PGP key :::::::::: \-/ /-\ :::::: ............ :::::: /-\ \-/ ::: edmond@lycaeum.org :::::: an1@anon.nymserver.com ::: \-/ /-\ : Director of the Lycaeum :: the Nymserver Administrator : /-\ \-/ ::: www.lycaeum.org :::::: www.nymserver.com ::: \-/ ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: From owner-freebsd-current Fri Aug 15 03:19:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA19630 for current-outgoing; Fri, 15 Aug 1997 03:19:40 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA19621 for ; Fri, 15 Aug 1997 03:19:34 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.5/8.8.6) id UAA04171 for freebsd-current@freebsd.org; Fri, 15 Aug 1997 20:19:30 +1000 Received: from localhost.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id UAA02923; Fri, 15 Aug 1997 20:20:34 +1000 (EST) Message-Id: <199708151020.UAA02923@ogre.dtir.qld.gov.au> To: freebsd-current@freebsd.org cc: syssgm@dtir.qld.gov.au Subject: Re: isa.c:isa_dmastatus(int chan) References: <199708150510.WAA00321@rah.star-gate.com> In-Reply-To: <199708150510.WAA00321@rah.star-gate.com> from Amancio Hasty at "Fri, 15 Aug 1997 05:10:29 +0000" Date: Fri, 15 Aug 1997 20:20:34 +1000 From: Stephen McKay Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Friday, 15th August 1997, Amancio Hasty wrote: >Can someone delete the enclosed data from isa_dmastatus? > > >isa_dmastatus(int chan) >{ > u_long cnt = 0; > int ffport, waport; > u_long low1, high1, low2, high2; > u_long ef; >/* delete this block of code */ > /* channel active? */ > if ((dma_inuse & (1 << chan)) == 0) { > printf("isa_dmastatus: channel %d not active\n", chan); > return(-1); > } > > /* still busy? */ > if ((dma_busy & (1 << chan)) == 0) { > return(0); > } > >/* end of delete block */ Calling isa_dma_acquire() first will satisfy the first condition, and I think it makes sense to do so. The second condition is trickier, and whether or not it should be deleted depends on what you mean by "busy". Once the channel is in cascade mode, you can think of it as busy. So, in that case, you would add "dma_busy |= 1 << chan" to isa_dmacascade(). You might have other opinions of cascade mode, then the fix is different. >isa_dmastatus is really meant for the sound driver and we are using >in auto dma mode. But it should work for everything. Although this routine has been debated already, it still needs some improvement. Stephen. From owner-freebsd-current Fri Aug 15 06:31:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA26516 for current-outgoing; Fri, 15 Aug 1997 06:31:58 -0700 (PDT) Received: from firewall.ftf.dk (root@[129.142.64.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26511 for ; Fri, 15 Aug 1997 06:31:54 -0700 (PDT) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id PAA28409; Fri, 15 Aug 1997 15:58:06 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id PAA18710; Fri, 15 Aug 1997 15:33:02 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id PAA28002; Fri, 15 Aug 1997 15:30:24 +0200 (CEST) Message-ID: <19970815153024.08234@deepo.prosa.dk> Date: Fri, 15 Aug 1997 15:30:24 +0200 From: Philippe Regnauld To: "Jordan K. Hubbard" Cc: freebsd-current@freebsd.org Subject: Re: Well, I guess it's about time I mentioned this little problem... References: <1433.871583550@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: Main Body X-Mailer: Mutt 0.69 In-Reply-To: <1433.871583550@time.cdrom.com>; from Jordan K. Hubbard on Thu, Aug 14, 1997 at 11:32:30AM -0700 X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jordan K. Hubbard writes: > just failed to work from Box A. During my conversation with David, he > suggested that I drop the MTU on box A's ethernet interface from 1500 > to 500 and TADA! Suddenly these URLs (one of which is > http://www.sunlabs.com/) could be visited just fine from box A, no > problems. Had the same problem with the _same_ setup: 1 ep0 card 1 user land ppp at 115.2Kbps on a Lasat ISDN TA to an ISP using V.120. Everything works fine, _except_ when I ran UUCP over TCP: hang. I changed the "packet size" (that's what the Lasat modem doc. calls it) from 1024 to 2048... and it now works. -- -- Phil -[ Philippe Regnauld / Systems Administrator / regnauld@deepo.prosa.dk ]- -[ Location.: +55.4N +11.3E PGP Key: finger regnauld@hotel.prosa.dk ]- From owner-freebsd-current Fri Aug 15 07:59:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA00776 for current-outgoing; Fri, 15 Aug 1997 07:59:47 -0700 (PDT) Received: from morse.satech.net.au (morse.satech.net.au [203.56.210.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA00763 for ; Fri, 15 Aug 1997 07:59:15 -0700 (PDT) Received: from matte.box.net.au (matte.satech.net.au [203.1.91.219]) by morse.satech.net.au (8.8.5/8.8.5.SAT.GJR.970426) with ESMTP id AAA22733 for ; Sat, 16 Aug 1997 00:29:14 +0930 Received: from box.net.au (localhost.satech.net.au [127.0.0.1]) by matte.box.net.au (8.8.7/8.7.3) with ESMTP id AAA03368 for ; Sat, 16 Aug 1997 00:29:26 +0930 (CST) Message-ID: <33F46ECC.5FF69529@box.net.au> Date: Sat, 16 Aug 1997 00:29:25 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: Keeping your /etc directory up to date. Content-Type: multipart/mixed; boundary="------------A220918225F8DFB68062F26C" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------A220918225F8DFB68062F26C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I saw the need so I wrote the attached script. Read the comments at the top of the script but basically the bourne shell script "etcud" (meaning /etc update) does a comparison between /usr/src/etc and /etc with MD5 checksums. It will optionally show you RCS version id's, diffs between files, and all files (not only those where the MD5 checksums mismatch). One of the best features is the ability to specify an egrep exclusion or inclusion pattern for file names. And there is also option -t for typical usage which excludes common files which are bound to mismatch the MD5 checksum comparison. I seriously think this script should be run by people after each make world like: "etcud -t -v". Anyway, here is the usage: Usage: etcud [-a] [-v] [-d] [-n] [-t] [-r ] [-i | -e ] -a Also output information for files where the checksums match -v Display RCS version strings if present -d Display diffs between the files -n Non-exact mode - i.e. dont use '-x' with egrep -t Typical usage. This is the same as etcud -e "group|hosts|motd|shells|rc.local|master.passwd" -r Directory where the source distribution is found -i Inclusion filename pattern (those files to check) -e Exclusion filename pattern (those file to ignore) And here is some sample output for my -CURRENT upgrade from ctm-src-cur.2947 to ctm-src-cur.3002: matte: {34} etcud -t -v MD5 check FAILED for /usr/src/etc/etc.i386/rc.i386 /etc/etc.i386/rc.i386 /usr/src/etc/etc.i386/rc.i386 VER> # $Id: rc.i386,v 1.29 1997/07/06 07:19:12 peter Exp $ /etc/etc.i386/rc.i386 VER> # $Id: rc.i386,v 1.28 1997/06/02 06:43:52 markm Exp $ MD5 check FAILED for /usr/src/etc/mtree/BSD.var.dist /etc/mtree/BSD.var.dist /usr/src/etc/mtree/BSD.var.dist VER> # $Id: BSD.var.dist,v 1.31 1997/07/29 11:23:14 ache Exp $ /etc/mtree/BSD.var.dist VER> # $Id: BSD.var.dist,v 1.30 1997/05/03 20:15:15 jkh Exp $ MD5 check FAILED for /usr/src/etc/mtree/BSD.local.dist /etc/mtree/BSD.local.dist /usr/src/etc/mtree/BSD.local.dist VER> # $Id: BSD.local.dist,v 1.30 1997/08/01 13:16:39 phk Exp $ /etc/mtree/BSD.local.dist VER> # $Id: BSD.local.dist,v 1.28 1997/06/10 07:55:10 asami Exp $ MD5 check FAILED for /usr/src/etc/mtree/BSD.usr.dist /etc/mtree/BSD.usr.dist /usr/src/etc/mtree/BSD.usr.dist VER> # $Id: BSD.usr.dist,v 1.94 1997/08/01 13:16:40 phk Exp $ /etc/mtree/BSD.usr.dist VER> # $Id: BSD.usr.dist,v 1.91 1997/06/04 10:51:09 asami Exp $ MD5 check FAILED for /usr/src/etc/namedb/make-localhost /etc/namedb/make-localhost MD5 check FAILED for /usr/src/etc/aliases /etc/aliases /usr/src/etc/aliases VER> # $Id: aliases,v 1.5 1997/08/09 14:58:49 phk Exp $ /etc/aliases VER> # $Id: aliases,v 1.4 1997/06/29 23:09:07 wosch Exp $ MD5 check FAILED for /usr/src/etc/amd.map /etc/amd.map MD5 check FAILED for /usr/src/etc/hosts.lpd /etc/hosts.lpd MD5 check FAILED for /usr/src/etc/login.access /etc/login.access MD5 check FAILED for /usr/src/etc/netstart /etc/netstart /usr/src/etc/netstart VER> # $Id: netstart,v 1.52 1997/07/05 19:35:45 pst Exp $ /etc/netstart VER> # $Id: netstart,v 1.51 1997/05/18 20:11:44 jkh Exp $ MD5 check FAILED for /usr/src/etc/rpc /etc/rpc MD5 check FAILED for /usr/src/etc/ttys /etc/ttys MD5 check FAILED for /usr/src/etc/Makefile /etc/Makefile /usr/src/etc/Makefile VER> # $Id: Makefile,v 1.154 1997/08/02 00:22:44 davidn Exp $ /etc/Makefile VER> # $Id: Makefile,v 1.151 1997/06/04 03:58:52 asami Exp $ MD5 check FAILED for /usr/src/etc/csh.login /etc/csh.login MD5 check FAILED for /usr/src/etc/inetd.conf /etc/inetd.conf MD5 check FAILED for /usr/src/etc/rc /etc/rc /usr/src/etc/rc VER> # $Id: rc,v 1.133 1997/07/13 13:22:15 jkh Exp $ /etc/rc VER> # $Id: rc,v 1.131 1997/06/25 11:48:47 pst Exp $ MD5 check FAILED for /usr/src/etc/security /etc/security /usr/src/etc/security VER> # $Id: security,v 1.21 1997/08/01 01:25:21 brian Exp $ /etc/security VER> # $Id: security,v 1.20 1997/03/03 07:03:50 mpp Exp $ MD5 check FAILED for /usr/src/etc/rc.conf /etc/rc.conf /usr/src/etc/rc.conf VER> # $Id: rc.conf,v 1.20 1997/07/06 08:28:34 peter Exp $ /etc/rc.conf VER> # $Id: rc.conf,v 1.19 1997/06/24 22:36:42 dima Exp $ MD5 check FAILED for /usr/src/etc/login.conf /etc/login.conf /usr/src/etc/login.conf VER> # $Id: login.conf,v 1.13 1997/07/11 22:11:13 guido Exp $ /etc/login.conf VER> # $Id: login.conf,v 1.12 1997/05/23 12:46:52 ache Exp $ MD5 check FAILED for /usr/src/etc/rc.network /etc/rc.network /usr/src/etc/rc.network VER> # $Id: rc.network,v 1.9 1997/07/06 00:33:34 pst Exp $ /etc/rc.network VER> # $Id: rc.network,v 1.8 1997/05/19 07:46:48 jkh Exp $ /etc/rc.shutdown does not exist! -- /=====================================================================\ | Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@box.net.au | \=====================================================================/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 --------------A220918225F8DFB68062F26C Content-Type: text/plain; charset=us-ascii; name="etcud" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="etcud" #!/bin/sh # # etcud 1.3 - Compare /etc with /usr/src/etc to check for updated files # # etcud [-a] [-v] [-d] [-n] [-t] [-r ] [-i | -e ] # # This script compares the MD5 checksums of files found in the etc # directory of the source distribution (/usr/src/etc by default) with # those in /etc to alert you when /etc files need updating. # # Options: # # -a Also output information for files where the checksums match. # -v Display RCS version strings if present. # -d Display diffs between the files. # -n Non-exact mode. i.e. dont use '-x' with egrep for inclusion # and exclusion patterns. For power users only! # -t Typical usage. This is the same as etcud -e $DEF_EXCL # -r Set the root directory of the source distribution. # -i Inclusion filename pattern (those files to check). # -e Exclusion filename pattern (those file to ignore). # # Inclusion and exclusion patterns must be an egrep pattern which is a list # of file names separated by the pipe character. The filenames must be # relative to the etc directory of the source distribution (/usr/src/etc # by default). # # By default the script will use egrep -x which means the patterns must # exactly match for the files to be included or excluded. This is # generally what you want as you probably want to be able to type # "etcud -e hosts" to exclude the file /etc/hosts but not the file # /etc/hosts.lpd. Power users can use -n to disable the use of -x # with egrep. This can be useful when dealing with the ppp directory # for example. # # NOTES # - You can use EITHER an exclusion OR an inclusion file pattern, not # both. Subsequent uses will be ignored with a warning. # # - Use of the typical option (-t) will run etcud with the default # exclusion pattern, set at $DEF_EXCL below. This mode overrides # any previously specified inclusion or exclusion patterns with a # warning. This mode also silently ignores -n. # # AUTHOR: Matthew Thyer 3 August 1997 # ############################################################################### # The default directory for the source distribution DEF_SRC_ROOT=/usr/src # The typical exclusion list DEF_EXCL="group|hosts|motd|shells|rc.local|master.passwd" # opt_all=0 opt_ver=0 opt_diffs=0 opt_non_exact=0 opt_typical=0 opt_inc=0 opt_exc=0 error=0 cmd_name=`basename $0` usage () { echo "Usage: $cmd_name [-a] [-v] [-d] [-n] [-t] [-r ] [-i | -e ]" echo " -a Also output information for files where the checksums match" echo " -v Display RCS version strings if present" echo " -d Display diffs between the files" echo " -n Non-exact mode - i.e. dont use '-x' with egrep" echo " -t Typical usage. This is the same as etcud -e \"$DEF_EXCL\"" echo " -r Directory where the source distribution is found" echo " -i Inclusion filename pattern (those files to check)" echo " -e Exclusion filename pattern (those file to ignore)" } show_ver () { the_ver=`grep '$Id:' $src_files/$x` if [ $? -eq 0 ] ; then echo "$src_files/$x VER> $the_ver" fi the_ver=`grep '$Id:' /etc/$x` if [ $? -eq 0 ] ; then echo " /etc/$x VER> $the_ver" fi } do_check () { if [ -r /etc/$x ] ; then if [ `md5 /etc/$x | cut -d' ' -f4` != `md5 $src_files/$x | cut -d' ' -f4` ] ; then echo MD5 check FAILED for $src_files/$x /etc/$x if [ $opt_ver -eq 1 ] ; then show_ver fi if [ $opt_diffs -eq 1 ] ; then diff $src_files/$x /etc/$x echo fi elif [ $opt_all -eq 1 ] ; then echo MD5 check PASSED for $src_files/$x /etc/$x if [ $opt_ver -eq 1 ] ; then show_ver fi fi else # the file is not readable.... why ? perhaps it doesn't exist if [ ! -f /etc/$x ] ; then echo /etc/$x does not exist! else echo -n /etc/$x is not readable.... if [ `id -u` -ne 0 ] ; then echo perhaps you should be ROOT! else echo for some strange reason!!! fi fi fi } # The main program begins..... # First get the options while [ $# -ne 0 ] ; do case $1 in -a) opt_all=1 ;; -v) opt_ver=1 ;; -d) opt_diffs=1 ;; -n) opt_non_exact=1 ;; -t) opt_typical=1 if [ $opt_inc -eq 1 -o $opt_exc -eq 1 ] ; then echo "Warning: Typical usage overriding prior inclusion or exclusion pattern" opt_inc=0 fi opt_exc=1 patt=$DEF_EXCL ;; -r) shift if [ $# -eq 0 ] ; then error=1 echo "Error: -r requires an argument" usage break else if [ -d $1 ] ; then SRC_ROOT=$1 else error=1 echo "Error: Source directory \"$1\" does not exist" usage break fi fi ;; -i) shift if [ $# -eq 0 ] ; then error=1 echo "Error: -i requires an argument" usage break else if [ $opt_inc -eq 1 -o $opt_exc -eq 1 ] ; then echo "Warning: subsequent inclusion pattern ignored" else patt=$1 opt_inc=1 fi fi ;; -e) shift if [ $# -eq 0 ] ; then error=1 echo "Error: -e requires an argument" usage break else if [ $opt_inc -eq 1 -o $opt_exc -eq 1 ] ; then echo "Warning: subsequent exclusion pattern ignored" else patt=$1 opt_exc=1 fi fi ;; *) error=1 usage break ;; esac shift done if [ $error -eq 1 ] ; then exit fi src_files=`echo ${SRC_ROOT:=$DEF_SRC_ROOT}/etc | sed 's/\/\/$//'` cd $src_files # Can only do non_exact mode if we are not doing a typical egrep_flags="-x" if [ $opt_non_exact -eq 1 -a $opt_typical -eq 0 ] ; then egrep_flags="" fi if [ $opt_exc -eq 1 ] ; then egrep_flags=$egrep_flags" -v " fi if [ $opt_inc -eq 1 -o $opt_exc -eq 1 ] ; then find . -type f -exec echo {} \; | sed 's/^\.\///' | egrep $egrep_flags $patt | while read x ; do do_check done else find . -type f -exec echo {} \; | sed 's/^\.\///' | while read x ; do do_check done fi --------------A220918225F8DFB68062F26C-- From owner-freebsd-current Fri Aug 15 08:27:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA02043 for current-outgoing; Fri, 15 Aug 1997 08:27:46 -0700 (PDT) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA02038 for ; Fri, 15 Aug 1997 08:27:43 -0700 (PDT) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id KAA06729 for ; Fri, 15 Aug 1997 10:27:11 -0500 (CDT) Received: from sil-wa2-08.ix.netcom.com(206.214.137.40) by dfw-ix6.ix.netcom.com via smap (V1.3) id sma006712; Fri Aug 15 10:27:03 1997 Message-ID: <33F47544.41C67EA6@ix.netcom.com> Date: Fri, 15 Aug 1997 08:27:00 -0700 From: "Thomas D. Dean" X-Mailer: Mozilla 3.01 (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: Make fails After Update Source Tree. References: <33F3DCDF.167EB0E7@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk A fix. >make failed when building lib/libncurses/libncurses.a, complaining >about a missing version.h. I did 'touch lib/libncurses/version.h' >and the build completed. Is there a missing file? make depend in lib/libncurses # removes version.h dependency I did a 'make depend' in /usr/src. But, this causes almost everything to be rebuilt! >make terminated with a fatal error: >... >cc -O -Wall -static -o date date.o netdate.o vary.o -lutil >date.o: Undefined symbol `_strptime' referenced from text segment cp include/time.h /usr/include # define for strptime() make install in lib/libc # get strptime in libc.* From owner-freebsd-current Fri Aug 15 09:22:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA04614 for current-outgoing; Fri, 15 Aug 1997 09:22:42 -0700 (PDT) Received: from morse.satech.net.au (morse.satech.net.au [203.56.210.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA04604 for ; Fri, 15 Aug 1997 09:22:16 -0700 (PDT) Received: from matte.box.net.au (matte.satech.net.au [203.1.91.219]) by morse.satech.net.au (8.8.5/8.8.5.SAT.GJR.970426) with ESMTP id BAA23709 for ; Sat, 16 Aug 1997 01:52:22 +0930 Received: from box.net.au (localhost [127.0.0.1]) by matte.box.net.au (8.8.7/8.7.3) with ESMTP id BAA07042 for ; Sat, 16 Aug 1997 01:42:38 +0930 (CST) Message-ID: <33F47FF6.C06FDE95@box.net.au> Date: Sat, 16 Aug 1997 01:42:38 +0930 From: Matthew Thyer X-Mailer: Mozilla 4.02b7 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: Re: Keeping your /etc directory up to date. References: <33F46ECC.5FF69529@box.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You might want to change the order of the diff command at line 97 before anyone commits this script. It would be more intuitive that way. However I would like to leave the order the same in the messages: MD5 check FAILED for $src_files/$x /etc/$x MD5 check PASSED for $src_files/$x /etc/$x as it makes it easier to do an X windows cut and paste to your 'cp -p' command. Matthew Thyer wrote: > I saw the need so I wrote the attached script. > [snip] -- /=====================================================================\ | Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@box.net.au | \=====================================================================/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 From owner-freebsd-current Fri Aug 15 09:26:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA04814 for current-outgoing; Fri, 15 Aug 1997 09:26:42 -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 JAA04806 for ; Fri, 15 Aug 1997 09:26:38 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA23029; Fri, 15 Aug 1997 09:20:56 -0700 From: Terry Lambert Message-Id: <199708151620.JAA23029@phaeton.artisoft.com> Subject: Re: 3.0: problems with libc_r and native pthreads To: edmond@shaman.lycaeum.org (Andrew N. Edmond) Date: Fri, 15 Aug 1997 09:20:56 -0700 (MST) Cc: current@FreeBSD.ORG In-Reply-To: from "Andrew N. Edmond" at Aug 15, 97 02:49:15 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-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I assume this is because there are not enough file descriptors available > for some reason in libc_r (but there is in mit-pthreads!). I even set: > > #define FD_SETSIZE 8192 > > In the source of my program before any other includes. What was it before you compiled libc_r? 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-current Fri Aug 15 09:38:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA05322 for current-outgoing; Fri, 15 Aug 1997 09:38:11 -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 JAA05317 for ; Fri, 15 Aug 1997 09:38:07 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id JAA01391; Fri, 15 Aug 1997 09:37:18 -0700 (PDT) Message-Id: <199708151637.JAA01391@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Stephen McKay cc: freebsd-current@FreeBSD.ORG Subject: Re: isa.c:isa_dmastatus(int chan) In-reply-to: Your message of "Fri, 15 Aug 1997 20:20:34 +1000." <199708151020.UAA02923@ogre.dtir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Aug 1997 09:37:18 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk For now , I am just going to duplicate isa_dmastatus in the sound driver. I can call isa_dma_acquire however that leaves me wide open for the second condition . Tnks, Amancio >From The Desk Of Stephen McKay : > On Friday, 15th August 1997, Amancio Hasty wrote: > > >Can someone delete the enclosed data from isa_dmastatus? > > > > > >isa_dmastatus(int chan) > >{ > > u_long cnt = 0; > > int ffport, waport; > > u_long low1, high1, low2, high2; > > u_long ef; > >/* delete this block of code */ > > /* channel active? */ > > if ((dma_inuse & (1 << chan)) == 0) { > > printf("isa_dmastatus: channel %d not active\n", chan); > > return(-1); > > } > > > > /* still busy? */ > > if ((dma_busy & (1 << chan)) == 0) { > > return(0); > > } > > > >/* end of delete block */ > > Calling isa_dma_acquire() first will satisfy the first condition, and I > think it makes sense to do so. The second condition is trickier, and > whether or not it should be deleted depends on what you mean by "busy". > Once the channel is in cascade mode, you can think of it as busy. So, > in that case, you would add "dma_busy |= 1 << chan" to isa_dmacascade(). > You might have other opinions of cascade mode, then the fix is different. > > >isa_dmastatus is really meant for the sound driver and we are using > >in auto dma mode. > > But it should work for everything. Although this routine has been debated > already, it still needs some improvement. > > Stephen. From owner-freebsd-current Fri Aug 15 09:51:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA05926 for current-outgoing; Fri, 15 Aug 1997 09:51:55 -0700 (PDT) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA05919 for ; Fri, 15 Aug 1997 09:51:52 -0700 (PDT) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id LAA27714 for ; Fri, 15 Aug 1997 11:51:20 -0500 (CDT) Received: from sil-wa2-08.ix.netcom.com(206.214.137.40) by dfw-ix6.ix.netcom.com via smap (V1.3) id sma027414; Fri Aug 15 11:51:00 1997 Message-ID: <33F488F1.167EB0E7@ix.netcom.com> Date: Fri, 15 Aug 1997 09:50:57 -0700 From: "Thomas D. Dean" X-Mailer: Mozilla 3.01 (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: Make Broke in lkm/vm86 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Make fails in lkm/vm86. One noticable difference in vm86 make output and, say, nfs make output is the warning about the obj directory. 'Warning: Object directory not changed from original /usr/src/lkm/vm86' --- first --- celebris: {159} cd nfs celebris: {160} make -n -d A | grep OBJDIR ... CANONICALOBJDIR = /usr/obj/usr/src/lkm/nfs .OBJDIR = /usr/obj/usr/src/lkm/nfs --- and --- celebris: {161} cd ../vm86 celebris: {162} make -n -d A | grep OBJDIR ... CANONICALOBJDIR = /usr/obj/usr/src/lkm/vm86 .OBJDIR = /usr/src/lkm/vm86 ---- make (cc) seems to not like a lot of things about vm86 looks like some mis-direction, a problem in definitions. Warning: Object directory not changed from original /usr/src/lkm/vm86 cc -O -I. -DLKM -DVM86_MODULE -DKERNEL -DACTUALLY_LKM_NOT_KERNEL -I/usr/src/lkm/vm86/../../sys -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -c /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c In file included from /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:53: /usr/include/machine/md_var.h:71: warning: redundant redeclaration of `fusword' in same scope /usr/src/lkm/vm86/../../sys/sys/systm.h:123: warning: previous declaration of `fusword' /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:56: warning: `struct vm86frame' declared inside parameter list /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:56: warning: its scope is only this definition or declaration, /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:56: warning: which is probably not what you want. /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:92: warning: `struct vm86frame' declared inside parameter list /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `PUSH': /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:94: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:95: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:95: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: At top level: /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:99: warning: `struct vm86frame' declared inside parameter list /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `PUSHL': /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:101: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:102: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:102: dereferencing pointer to incomplete type /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: At top level: /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:106: warning: `struct vm86frame' declared inside parameter list < cut a lot of similar things> /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:387: `VM86_GET_VME' undeclared (first use this function) /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:388: storage size of `sa' isn't known /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `vm86_load': /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:412: `vm86_emulate' undeclared (first use this function) /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:413: `vm86_sysarch' undeclared (first use this function) /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `vm86_unload': /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:421: `vm86_emulate' undeclared (first use this function) /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:422: `vm86_sysarch' undeclared (first use this function) *** Error code 1 Stop. *** Error code 1 Stop. From owner-freebsd-current Fri Aug 15 10:25:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA07529 for current-outgoing; Fri, 15 Aug 1997 10:25:25 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA07468 for ; Fri, 15 Aug 1997 10:24:12 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA04289; Fri, 15 Aug 1997 13:23:36 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA14375; Fri, 15 Aug 1997 13:19:37 -0400 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA22964; Fri, 15 Aug 1997 13:19:37 -0400 Message-Id: <199708151719.AA22964@iluvatar.unx.sas.com> Subject: More nfs issues against -current To: freebsd-current@freebsd.org Date: Fri, 15 Aug 1997 13:19:36 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, A few days ago I posted about nfs v2 vs. nfs v3 and some serious performance degradation. This is against the lastest -current source. Well, for the last few days, I've been running my current box with -2 on my mount points. Today, I tried to copy some seme-large files to my machine, and the system is putting the following out onto the console: nfs server netapp01:/home: not responding Aug 15, 12:54:41 mrose /kernel: nfs server netapp01:/home: not responding nfs server netapp01:/home: is alive again Aug 15, 12:55:17 mrose /kernel: nfs server netapp01:/home: is alive again This has been going on now for about 2 hours. The netapp01 machine is fine. I can copy the files in question to my HP workstation, or my NT workstation, without any problems. ie: under hpux: jwd %timex cp X33* /tmp real 55.02 user 0.15 sys 6.43 So, nfs v3 locks up for 30 minute intervals on me, and v2 appears to "flakey". Does anyone have any ideas on what the problem might be, or where I should start looking? Thanks, John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-current Fri Aug 15 10:43:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA08329 for current-outgoing; Fri, 15 Aug 1997 10:43:18 -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 KAA08320 for ; Fri, 15 Aug 1997 10:43:13 -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 MAA12686; Fri, 15 Aug 1997 12:58:09 -0500 (CDT) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id MAA09901; Fri, 15 Aug 1997 12:44:23 -0500 Message-ID: <19970815124422.25599@right.PCS> Date: Fri, 15 Aug 1997 12:44:22 -0500 From: Jonathan Lemon To: "Thomas D. Dean" Cc: current@FreeBSD.ORG Subject: Re: Make Broke in lkm/vm86 References: <33F488F1.167EB0E7@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <33F488F1.167EB0E7@ix.netcom.com>; from Thomas D. Dean on Aug 08, 1997 at 09:50:57AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 08, 1997 at 09:50:57AM -0700, Thomas D. Dean wrote: > Make fails in lkm/vm86. > > One noticable difference in vm86 make output and, say, > nfs make output is the warning about the obj directory. > > 'Warning: Object directory not changed from original /usr/src/lkm/vm86' I'll look into this. I'm going to remove it as an LKM, so this should go away. > ---- make (cc) seems to not like a lot of things about vm86 > looks like some mis-direction, a problem in definitions. > [ ... ] > > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:387: `VM86_GET_VME' > undeclared (first use this function) > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:388: storage size of `sa' > isn't known > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `vm86_load': > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:412: `vm86_emulate' > undeclared (first use this function) > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:413: `vm86_sysarch' > undeclared (first use this function) > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c: In function `vm86_unload': > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:421: `vm86_emulate' > undeclared (first use this function) > /usr/src/lkm/vm86/../../sys/i386/i386/vm86.c:422: `vm86_sysarch' > undeclared (first use this function) > *** Error code 1 This looks like a problem with the header files; my guess is that it's not picking up the new include file. -- Jonathan From owner-freebsd-current Fri Aug 15 11:48:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12077 for current-outgoing; Fri, 15 Aug 1997 11:48:19 -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 LAA12071 for ; Fri, 15 Aug 1997 11:48:12 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.6/8.8.5) with ESMTP id LAA27295; Fri, 15 Aug 1997 11:47:29 -0700 (PDT) Message-Id: <199708151847.LAA27295@austin.polstra.com> To: tomdean@ix.netcom.com Subject: Re: cvsup Failure In-Reply-To: <33F3D541.41C67EA6@ix.netcom.com> References: <33F3D541.41C67EA6@ix.netcom.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Fri, 15 Aug 1997 11:47:29 -0700 From: John Polstra Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <33F3D541.41C67EA6@ix.netcom.com>, Thomas D. Dean wrote: > I attempted to update my sourece tree with cvsup. > > cvsup failed with the message: > > *** > *** runtime error: > *** ASSERT failed > *** file "../src/RCSDelta.m3", line 182 > *** This has already been discussed a lot in both the -current and -hackers lists, so if you want the gory details look at the mailing list archives. The solution that Vince gave you (rm -rf apache-current) is the right way to fix it. 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-current Fri Aug 15 13:33:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA18140 for current-outgoing; Fri, 15 Aug 1997 13:33:40 -0700 (PDT) Received: from peedub.gj.org (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA18069 for ; Fri, 15 Aug 1997 13:32:58 -0700 (PDT) Received: from peedub.gj.org (localhost [127.0.0.1]) by peedub.gj.org (8.8.6/8.6.9) with ESMTP id WAA16885 for ; Fri, 15 Aug 1997 22:31:20 GMT Message-Id: <199708152231.WAA16885@peedub.gj.org> X-Mailer: exmh version 2.0delta 6/3/97 To: freebsd-current@freebsd.org Subject: Re: Make Broke in lkm/vm86 Reply-To: Gary Jennejohn In-reply-to: Your message of "Fri, 15 Aug 1997 09:50:57 MST." <33F488F1.167EB0E7@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Aug 1997 22:31:19 +0000 From: Gary Jennejohn Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Thomas D. Dean" writes: >Make fails in lkm/vm86. > [snip] it failed for me too until I remembered to do "make includes" in /usr/src. --- Gary Jennejohn Home - Gary.Jennejohn@munich.netsurf.de Work - gjennejohn@frt.dec.com From owner-freebsd-current Fri Aug 15 15:16:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA22170 for current-outgoing; Fri, 15 Aug 1997 15:16:07 -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 PAA22131 for ; Fri, 15 Aug 1997 15:16:00 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id RAA00969 for current@freebsd.org; Fri, 15 Aug 1997 17:15:53 -0500 (EST) From: "John S. Dyson" Message-Id: <199708152215.RAA00969@dyson.iquest.net> Subject: Minor word of warning about APM with WD DMA To: current@freebsd.org Date: Fri, 15 Aug 1997 17:15:53 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gang, This is just a heads-up, but it is a not-so-well known secret that I use IDE drives often (I am a cheap-skate.) When going to work on-site at NCI/Navio/Oracle or whatever it is called today, I usually set my machine to run in powersaving mode. Since the DMA changes (which I have enabled), my filesystems appear to be readily scrambled when APM is ON. This is just a caveat, so that others might not get hosed by the problem. Not sure what is really going on here, so I am hesitating to lay-blame on mixing DMA and APM right now, and will not get a chance to look at it myself for a while. So, beware!!! :-). John From owner-freebsd-current Fri Aug 15 16:27:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25059 for current-outgoing; Fri, 15 Aug 1997 16:27:41 -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 QAA25050 for ; Fri, 15 Aug 1997 16:27:37 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA20894; Fri, 15 Aug 1997 16:29:14 -0700 (PDT) Message-Id: <199708152329.QAA20894@implode.root.com> To: "John W. DeBoskey" cc: freebsd-current@FreeBSD.ORG Subject: Re: More nfs issues against -current In-reply-to: Your message of "Fri, 15 Aug 1997 13:19:36 EDT." <199708151719.AA22964@iluvatar.unx.sas.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 15 Aug 1997 16:29:14 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, for the last few days, I've been running my current box with >-2 on my mount points. Today, I tried to copy some seme-large files >to my machine, and the system is putting the following out onto the >console: > >nfs server netapp01:/home: not responding >Aug 15, 12:54:41 mrose /kernel: nfs server netapp01:/home: not responding >nfs server netapp01:/home: is alive again >Aug 15, 12:55:17 mrose /kernel: nfs server netapp01:/home: is alive again ... > Does anyone have any ideas on what the problem might be, or where >I should start looking? I think there is a bug in the timeout calculation. Try specifying a large timeout value (see the -d and -t options in the mount_nfs man page). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Fri Aug 15 17:29:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA28480 for current-outgoing; Fri, 15 Aug 1997 17:29:35 -0700 (PDT) Received: from labs.usn.blaze.net.au (root@labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA28466 for ; Fri, 15 Aug 1997 17:29:29 -0700 (PDT) Received: from labs.usn.blaze.net.au (davidn@local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.7/8.8.5) with ESMTP id KAA00864; Sat, 16 Aug 1997 10:29:14 +1000 (EST) Message-Id: <199708160029.KAA00864@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Amancio Hasty cc: current@hub.freebsd.org Subject: Re: exmh and current.. anyone? In-reply-to: Your message of "Sat, 09 Aug 1997 22:41:40 MST." <199708100541.WAA00914@rah.star-gate.com> 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: Sat, 16 Aug 1997 10:29:14 +1000 From: David Nugent Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From The Desk Of Jeffrey Hsu : > > > How do you work around the stupid tcl8 problem? > > > > I had to do this the other day and I just ftp'ed the tcl8 and tk8 > > distribution from ftp.smli.com, untarred them in the same subdirectory, > > and built and installed just tk. > > Hmm... > > I think we have bigger problem and that is perhaps some that are > running current shouldn't be running current. For those willing to accept the "risks", I'd actually prefer to see it that way. Bugs are usually shaken out first in current, and having only developers run that code means it gets significantly less exposure. Still, your comment is valid. I just wouldn't like to see it become so much as a discouragement to run -current as a warning to those who would like to do so that it isn't the platform to pick if you want to run a stable system that won't require some reconfiguration now and then. While I also "complained" on this same issue in the earlier thread, my complaint did not relate directly to any inconvenience I personally suffered (in fact, I've already been running tcl/tk8 for some weeks with some apps - all of them had to be adjusted, but only TkDesk broke beyond all repair), just its effect on ports and attempting to define some solutions (which have been largely shrugged off for little reason, but then - I don't see things from the same perspective and I'm obviously missing something). I'm quite prepared to put up with those sorts of problems, as should anyone who runs -current. I believe that Satoshi's final "solution" which I first saw suggested by Michael Smith, that the ports tree should be as independent as possible from the base system, is probably for the best anyway. tcl and perl (does anything in the source tree use embedded perl yet? nvi?) are probably "special" in this regard because their interface tends to be very library version dependant, and with tcl there is the problem with init.tcl and other anciliaries. APIs for other libraries are usually added to and enhanced, but rarely actually change so radically. As someone pointed out, if the new tcl8 initialisation files were moved into /usr/libdata/tcl8.0/ rather than their current location, it would mitigate problems with any transition from 2.2 to -current as the existing files and libraries would remain intact. I honestly hope this is changed at some point before the 3.0 release. It would also have the side-effect that the version in the -current branch of the day can change without yet another a repeat of this entire episode. It is quite possible that we'll see tcl version 8.1 or higher before 3.0 looks even close to release. If it has to be there, and apparently it does, I'd far prefer to see it maintained and kept current. Regards, David -- David Nugent - Unique Computing Pty Ltd - Melbourne, Australia davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/ From owner-freebsd-current Fri Aug 15 19:03:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA01791 for current-outgoing; Fri, 15 Aug 1997 19:03:21 -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 TAA01786 for ; Fri, 15 Aug 1997 19:03:18 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id TAA03324; Fri, 15 Aug 1997 19:03:11 -0700 (PDT) Message-Id: <199708160203.TAA03324@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: David Nugent cc: current@hub.freebsd.org Subject: Re: exmh and current.. anyone? In-reply-to: Your message of "Sat, 16 Aug 1997 10:29:14 +1000." <199708160029.KAA00864@labs.usn.blaze.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Aug 1997 19:03:11 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of David Nugent : > As someone pointed out, if the new tcl8 initialisation files were > moved into /usr/libdata/tcl8.0/ rather than their current location, > it would mitigate problems with any transition from 2.2 to -current > as the existing files and libraries would remain intact. I honestly Wrong , again the issue is not tcl8.xxx rather is what it ought to be requirement: a resonable ability to resolve technical issues. Yes, we need users on current however people should understand that is a fluid environment. Peace and Have fun, Amancio From owner-freebsd-current Fri Aug 15 19:13:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA02257 for current-outgoing; Fri, 15 Aug 1997 19:13:02 -0700 (PDT) Received: from mail.san.rr.com (san.rr.com [204.210.0.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA02252 for ; Fri, 15 Aug 1997 19:13:00 -0700 (PDT) Received: (from uucp@localhost) by mail.san.rr.com (8.8.7/8.8.7) id TAA06917 for ; Fri, 15 Aug 1997 19:12:29 -0700 (PDT) Message-Id: <199708160212.TAA06917@mail.san.rr.com> Received: from dt5h1n61.san.rr.com(204.210.31.97) by mail via smap (V2.0) id xma006903; Fri, 15 Aug 97 19:12:26 -0700 From: "Studded" To: "current@freebsd.org" Date: Fri, 15 Aug 97 19:12:01 -0700 Reply-To: "Studded" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Wish List Item: DHCP for Instsall Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 11 Aug 1997 07:39:15 -0700, Jordan K. Hubbard wrote: >> I haven't heard much talk about DHCP under FreeBSD, but has anyone >> thought about, or looked into, the possibility of using DHCP for both the >> install, and as part of the standard 'runtime'? > >It's definitely been thought about, just no satisfactory solution for >actually doing it arrived at yet. Given the growing popularity of cable modems that use dycp to negotiate a connection at startup, this is going to be a more frequent request. Doug Do thou amend they face, and I'll amend my life. -Shakespeare, "Henry V" From owner-freebsd-current Fri Aug 15 21:53:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA07581 for current-outgoing; Fri, 15 Aug 1997 21:53:44 -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 VAA07575 for ; Fri, 15 Aug 1997 21:53:42 -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 VAA26801 for ; Fri, 15 Aug 1997 21:53:37 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.6/8.8.5) with SMTP id VAA11787 for ; Fri, 15 Aug 1997 21:53:36 -0700 (PDT) Date: Fri, 15 Aug 1997 21:53:36 -0700 (PDT) From: Chris Timmons Reply-To: Chris Timmons To: freebsd-current@freebsd.org Subject: world makers: watch for stale depends! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just upgraded usr.bin/global to v2.0 and in the process, modified it to build from src/contrib/global sources. If your world build has problems in global, make sure that you do a 'make cleandepend' (or just zap /usr/obj and start fresh.) -Chris From owner-freebsd-current Sat Aug 16 02:11:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA14598 for current-outgoing; Sat, 16 Aug 1997 02:11:58 -0700 (PDT) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA14591; Sat, 16 Aug 1997 02:11:48 -0700 (PDT) Received: from wall.jhs.no_domain (localhost [127.0.0.1]) by wall.jhs.no_domain (8.8.5/8.6.9) with ESMTP id QAA00905; Fri, 15 Aug 1997 16:17:26 +0200 (MET DST) Message-Id: <199708151417.QAA00905@wall.jhs.no_domain> To: Andrew Gordon cc: current@freebsd.org, isdn@muc.ditec.de, steve@visint.co.uk Subject: Re: ISDN drivers/cards From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: Home: Lists: Work: X-web: http://www.freebsd.org/~jhs/ X-address: Holz Strasse 27d, 80469 Munich, Germany X-tel: Home +49.89.268616, Work +49.89.607.29788 Fax +49.89.2608126, Data +49.89.26023276 X-company: Vector Systems Ltd, Unix & Internet Consultants. X-software: FreeBSD (Unix) + EXMH 1.6.9 (PGP key on web) In-reply-to: Your message of "Sat, 09 Aug 1997 17:35:56 BST." Date: Fri, 15 Aug 1997 16:17:25 +0200 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reference: > From: Andrew Gordon > Date: Sat, 9 Aug 1997 17:35:56 +0100 (BST) > Message-id: Hi, Andrew Gordon wrote: > On Wed, 6 Aug 1997, Julian H. Stacey wrote: > > > steve@visint.co.uk writes: > > > > I tried using bisdn, both with -current and 2.2.2, without much luck, > I have seen problems with the PPP patches installed, but not otherwise. I have no problems, but then I don't use PPP code, so I'm an incomplete test. > > > Well, just wanted to say that in case someone suggests that we should all > > > be using bisdn. Because IMHO, it sucks, and really shouldn't be used as a > > > base for future code either. (except as a bad example.) > > Well, you are intitled to your opinion, but expressing it in the form > of general abuse (as opposed to specific criticism of techniques used) > is not at all helpful. Andrew, do you realise in the mail you addressed to me as To: "Julian H. Stacey" Cc: current@FreeBSD.ORG, isdn@muc.ditec.de that the criticism was from steve@visint.co.uk, not from jhs@freebsd.org ? As you (Andrew) did not assert a cc: steve@visint.co.uk steve@visint.co.uk won't have seen your reply unless he happens to be subscribed to one of the lists. Sorry to point this out so pedantically, but I do not want anyone confusing it as me coming out with those anti bisdn source code opinions ! I'm a very happy user of the code. If you want to admonish Steve please do it addressed directly to him, & cc'd or not to lists as you see appropriate, but not in a mail addressed to me, Thanks :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Sat Aug 16 02:50:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA15696 for current-outgoing; Sat, 16 Aug 1997 02:50:13 -0700 (PDT) Received: from mail0.iij.ad.jp (mail0.iij.ad.jp [202.232.2.113]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA15691 for ; Sat, 16 Aug 1997 02:50:10 -0700 (PDT) Received: from uucp2.iij.ad.jp (uucp2.iij.ad.jp [202.232.2.202]) by mail0.iij.ad.jp (8.8.5+2.7Wbeta5/3.5Wpl4-MAIL) with SMTP id SAA19721; Sat, 16 Aug 1997 18:50:05 +0900 (JST) Received: (from uucp@localhost) by uucp2.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id SAA24528; Sat, 16 Aug 1997 18:50:05 +0900 Received: from tyd1.tydfam.iijnet.or.jp (tyd1.tydfam.iijnet.or.jp [192.168.1.2]) by tydfam.iijnet.or.jp (8.8.6/3.4W2-uucp) with ESMTP id JAA00424; Sat, 9 Aug 1997 09:04:29 +0900 (JST) Received: from localhost.tydfam.iijnet.or.jp (localhost.tydfam.iijnet.or.jp [127.0.0.1]) by tyd1.tydfam.iijnet.or.jp (8.8.6/3.4Wnomx) with SMTP id JAA00363; Sat, 9 Aug 1997 09:04:28 +0900 (JST) Message-Id: <199708090004.JAA00363@tyd1.tydfam.iijnet.or.jp> X-Authentication-Warning: tyd1.tydfam.iijnet.or.jp: localhost.tydfam.iijnet.or.jp [127.0.0.1] didn't use HELO protocol To: jdp@polstra.com Cc: current@freebsd.org Subject: Re: Q) CVSup operation Reply-To: ken@tydfam.iijnet.or.jp In-Reply-To: Your message of "Fri, 08 Aug 1997 08:59:28 -0700" References: <199708081559.IAA00625@austin.polstra.com> X-Mailer: Mew version 1.70 on Emacs 19.34.2 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 09 Aug 1997 09:04:28 +0900 From: Takeshi Yamada Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry, it was my organic memory error. It was exactly the same REL_15_1 and 15.2. It was the matter of "-P m". From owner-freebsd-current Sat Aug 16 11:08:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03192 for current-outgoing; Sat, 16 Aug 1997 11:08:55 -0700 (PDT) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03170; Sat, 16 Aug 1997 11:08:45 -0700 (PDT) Received: from wall.jhs.no_domain (localhost [127.0.0.1]) by wall.jhs.no_domain (8.8.5/8.6.9) with ESMTP id UAA04051; Sat, 16 Aug 1997 20:12:12 +0200 (MET DST) Message-Id: <199708161812.UAA04051@wall.jhs.no_domain> To: freebsd-current@FreeBSD.ORG cc: Dmitrij Tejblum , Chris Csanady Subject: TCL/TK versioning in all path/name accesses From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: Home: Lists: Work (firewall blocks incoming): X-web: http://www.freebsd.org/~jhs/ X-address: Holz Strasse 27d, 80469 Munich, Germany X-tel: Home +49.89.268616, Work +49.89.607.29788 Fax +49.89.2608126, Data +49.89.26023276 X-company: Vector Systems Ltd, Unix & Internet Consultants. X-software: FreeBSD (Unix) + EXMH 1.6.9 (PGP key on web) In-reply-to: Your message of "Sun, 10 Aug 1997 14:25:16 +0400." <199708101025.OAA00728@tejblum.dnttm.rssi.ru> Date: Sat, 16 Aug 1997 20:10:29 +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk ( I bcc'd ports@ for info, but so's to avoid cross post follow up ) Reference: > Subject: Re: exmh and current.. anyone? > From: Dmitrij Tejblum > Date: Sun, 10 Aug 1997 14:25:16 +0400 > Message-id: <199708101025.OAA00728@tejblum.dnttm.rssi.ru> Hi, Dmitrij Tejblum wrote: > There is a real problem here! Upgrade of the base system should not break 3rd > > party binaries! There is shared libraries verion numbers for it. But > libtcl75.so.1.1 become broken by overwriting /usr/libdata/tcl. Perhaps, TCL 8 > .0 > should use /usr/libdata/tcl80 instead. Version numbers in _all_ Tcl/Tk path/names would be great ! We're about half way there (looking at 2.2.2), but libdata still needs to be done, as does various ports read-during-make accesses (write accesses are better, more (but incomplete) use of numbered path/names. It's untenable for my 2.2.2 box at work to have one combi mix of tcl/tk stuff needed for FreeBSD src & ports dependencies such as vi & exmh, & another conflicting mix of versions required for use to provide compatibility with my customer's application, (which runs across a range of OSs, & is not about to have its version numbers changed for any one OS). Add to that 2.2.2 scenario, the scenario of current using Tcl 8, & it becomes tiresome, _unless_ we have a clear way of specifying Tcl/Tk versions required for all accesses, read & write, src, ports, & commercial add on packages. Yesterday I tore all the tcl tk stuff with generic non version specific access out of my machine, & reinstalled the exact versions I needed all with version numbers in the path (libdata included), & will later reinstall whatever breaks on FreeBSD src/, so at least the version requirements of my project at work no longer get suborned by FreeBSD's non version specific path/names. It'll become progressively harder to keep src & all ports Tcl/Tk apps dependencies aligned, as ports/ grows, & totaly impossible to keep in step with versions used by customer's own apps (for which FreeBSD is a host), so if all those lib include libdata & bin dirs/filenames could have a version indicator in, life would be much easier :-) Zap EG /usr/libdata/tcl/init.tcl & -ltcl etc & only use explicit /usr/libdata/tcl/[7.4,7.6,8.0}/init.tcl ... -ltcl76 for {include lib libdata bin local}, for {src & ports & your own commercial software you want to make safe from version problems}. FreeBSD could then support simultaneously use of apps. requiring different tcl/tk versions, instead of ther present situation where one breaks one Tcl/Tk app while fixing another app's version dependency. Only truly version independent or naive packages should reach out version-blind with such as "-ltcl", & none of the FreeBSD src/ or ports/ should read or install into any non versioned tcl/tk path/name. To help, I've prepared a ports/lang/tcl75 (for compatibility with tk4.1 & tix) (at work so can't send-pr it yet), & have analysed version-blind read & write access conflicts of some of ports/, & plan to prepare diffs next week or so. Version number path/name dependencies are a pain in general, but we seem to need them for Tcl/Tk. PS I carefully express no opinion on the merits/demerits of the recent warmly debated "should we/shouldn't we" Tcl/Tk 8 topic (which I read but took no part in :-). It seems to me, whether or not Tcl/Tk8 exists, that we have had a version selection problem at least as long as we have had tcl7.4 & tcl7.6 & tk4.1 &4.2 etc. I support Dmitrij Tejblum's suggestion, but as to which of /usr/libdata/tcl80 76 74 etc /usr/libdata/tcl/80 /usr/libdata/tcl/8.0 well, I'd be grateful whichever the powers that be choose, just not /usr/libdata/tcl :-) Apologies, I've gone on too long ;-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Sat Aug 16 11:09:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03260 for current-outgoing; Sat, 16 Aug 1997 11:09:23 -0700 (PDT) Received: from wall.jhs.no_domain (vector.muc.ditec.de [194.120.126.35]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03216; Sat, 16 Aug 1997 11:09:01 -0700 (PDT) Received: (from jhs@localhost) by wall.jhs.no_domain (8.8.5/8.6.9) id QAA02403; Sat, 16 Aug 1997 16:06:34 +0200 (MET DST) Date: Sat, 16 Aug 1997 16:06:34 +0200 (MET DST) Message-Id: <199708161406.QAA02403@wall.jhs.no_domain> To: hardware@freebsd.org cc: leo@marco.de, gj@freebsd.org, jkh@freebsd.org Subject: free token ring hardware offered, if you reply quickly. From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Email: Home: Lists: Work (firewall blocks incoming): X-web: http://www.freebsd.org/~jhs/ X-address: Holz Strasse 27d, 80469 Munich, Germany X-tel: Home +49.89.268616, Work +49.89.607.29788 Fax +49.89.2608126, Data +49.89.26023276 X-company: Vector Systems Ltd, Unix & Internet Consultants. X-software: FreeBSD (Unix) + EXMH 1.6.9 (PGP key on web) Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I sent this To: hardware@freebsd.org bcc: current@freebsd.org cc: various friends to inform but avoid follow-up overload. Available free to any Free/Net/OpenBSD/Linux type hacker ... (except recipient to pay shippings from Munich Germany & I've no time to find out what that would cost).. & Due to be chucked out within a week to make space ... so answer me quickly!: The heap weighs about 13.5 Kilogrammes. 2 * Token Ring 8 Port (+RI +RO) MAU Multiple Access Unit (Hub), Front: Proteon proNET-4 Back: Model P2710 (2 Technology Drive, Westboro MA 01581) SN30770002170 400mA 9V DC Documents in perfect condition, labelled: UNISYS Personal Workstation USERNET Token Ring Intelligent Wire Center, Installation Guide, Operating Guide, Manuel d'Installation, Installationsanleitung, Manuale di installazione, Guia de instalaci'on I have 1 power supply (220V/9V) for the 2 MAUs, + daisy chain power cable included. Doc says: "Three wire centers can share one transformer". Shipping Crate: 64 x 15 x 35 centimetre. 2 * ISA 16 bit PC cards Cabletron Systems Inc PN 9000275-03 On flange: 9 pin D + RJ + 4 LEDs 5.25" Floppy, 1 Manual for 2 cards. Zustand: Gut Documentation: include sealed floppy. 3 * 3Com TokenLink Plus (1 still in original seal. Docu: inc orig floppy Now simply in my way, so available free, NO FreeBSD drivers available, you'll need to write some, or use it under some horrific Gates-OS, which is what it was used with before. I have no docu beyond user manuals, & no time to make enquiries, just phone or mail me an address, find me a shipping authorisation with FedEx/UPS/DHL/whatever, so I don't pay the freight & it's yours. Note Jordan had found some volunteer to write FreeBSD token ring drivers for more modern hardware, but I've seen no announcement of progress, so I see no harm in offering this free perhaps to give the PD C src community a 2nd route to token ring support ? gj@freebsd.org looked at the hardwar & pronounced it very old. old it may be, but the friend I got it from assures me it's in full working order, but I have a new job, no time or space, & am having a clear out ... anyone want to take it off my hands ? Matthias, (& others) please feel free to copy this across to appropriate lists for other PD hacker groups, Thanks. Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-current Sat Aug 16 11:28:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA04112 for current-outgoing; Sat, 16 Aug 1997 11:28:26 -0700 (PDT) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA04103 for ; Sat, 16 Aug 1997 11:28:22 -0700 (PDT) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id WAA06648 for freebsd-current@freebsd.org; Sat, 16 Aug 1997 22:26:53 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.7/8.8.5) with ESMTP id WAA00740 for ; Sat, 16 Aug 1997 22:29:13 +0400 (MSD) Message-Id: <199708161829.WAA00740@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: freebsd-current@freebsd.org Subject: make -DNOCLEAN world Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Aug 1997 22:29:12 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -DNOCLEAN now almost useless in make world. 'make bootstrap' clobber subdirectories in /usr/obj/usr/src/tmp/usr/include, making them symlinks, and 'make includes' replace the symlinks to directories again. So, almost all source file rebuilded. Probably, 'make includes' should be run with SHARED=symlinks. Dima From owner-freebsd-current Sat Aug 16 14:37:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11911 for current-outgoing; Sat, 16 Aug 1997 14:37:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11906 for ; Sat, 16 Aug 1997 14:37:51 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.7/8.8.5) with ESMTP id PAA02987 for ; Sat, 16 Aug 1997 15:37:50 -0600 (MDT) Message-Id: <199708162137.PAA02987@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: current@freebsd.org Subject: damage in current to i386/isa/aic6360.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Aug 1997 15:37:49 -0600 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just cvsupped current and could not make depend for GENERIC: ../../i386/isa/aic6360.c:1311: unterminated macro call ../../i386/isa/aic6360.c:2464: warning: preprocessing directive not recognized I looked at it and it is obviosly damaged. So I removed my local copy, re-cvsupped, new copy came down, but it also is damaged. So I saved my copy in my commit tree on freefall as aic6360.c.GOOD, then did a cvs update: 265 % cvs update cvs update: Updating . cvs update: warning: aic6360.c was lost U aic6360.c ? aic6360.c.GOOD cvs update: Updating bs cvs update: Updating ic cvs update: Updating matcd cvs update: Updating pcvt cvs update: Updating sound cvs update: Updating sound/gustest 266 % /sbin/md5 aic6360.c.GOOD MD5 (aic6360.c.GOOD) = d16bdd25bf75921abaee57f02c770986 267 % /sbin/md5 aic6360.c MD5 (aic6360.c) = bd2ec1bdb8600e3eec591efed36df7c8 aic6360.c.GOOD: * $Id: aic6360.c,v 1.30 1997/07/20 14:09:50 bde Exp $ aic6360.c: * $Id: aic6360.c,v 1.30 1997/07/20 14:09:50 bde Exp $ --- It doesn't appear that there was a new commit, looks like file damage in the CVS tree. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-current Sat Aug 16 23:14:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09742 for current-outgoing; Sat, 16 Aug 1997 23:14:25 -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 XAA09734; Sat, 16 Aug 1997 23:14:21 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id XAA01038; Sat, 16 Aug 1997 23:14:15 -0700 (PDT) Message-Id: <199708170614.XAA01038@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Kyle Mestery cc: freebsd-multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Problem with my Wincast, fxtv In-reply-to: Your message of "Sat, 16 Aug 1997 22:42:20 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Aug 1997 23:14:15 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yes, just nuke this out from isa.c:isa_dmastatus and you will be okay, /* channel active? */ if ((dma_inuse & (1 << chan)) == 0) { /* printf("isa_dmastatus: channel %d not active\n", chan); return(-1); */ } /* still busy? */ if ((dma_busy & (1 << chan)) == 0) { /* return(0); */ } Next release of the sound driver will not use isa_dmastatus from isa.c rather I will duplicate the functionality in the sound driver. Amancio >From The Desk Of Kyle Mestery : > > Hi, I have a problem with my Wincast/TV card and/or fxtv. I think it is > the card based on what Steve had told me, but I thought I would see if > anyone else had any ideas before I return it for a new one (with the UPS > strike and all, returning it will be a couple of weeks or a month =(.) > > The problem is I get only certain channels. I get channels 2-6, 14-20, > and then the upper 90s, but nothing else. The ones I do get come in clear > and all, but the other ones are pure snow. Does anyone have any ideas? > Steve has suggested that the card is flakey, which I am beginning to > believe. Here is my setup: > > 3.0-CURRENT from Monday, August 11 > Wincast/TV > Latest fxtv > > Also, on a separate note sound has ceased working on quake for me now. I > updated my kernel this morning. Here are the errors I am seeing (and I > see thousangs of these!!!) > isa_dmastatus: channel 5 not active > isa_dmastatus: channel 5 not active > isa_dmastatus: channel 5 not active > isa_dmastatus: channel 5 not active > isa_dmastatus: channel 5 not active > > I tried a new kernel and the same hting. Sound works for a second, and > then nothing. THe only thing different I have done is added a Buslogic > BT-946c SCSI card. Any ideas? I will try removing the card and see if > that works or not. Thanks! > > Kyle Mestery > StorageTek's Network Systems Group > 7600 Boone Ave. N., Brooklyn Park, MN 55428 > mesteka@anubis.network.com, mestery@winternet.com > From owner-freebsd-current Sat Aug 16 23:18:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09953 for current-outgoing; Sat, 16 Aug 1997 23:18:18 -0700 (PDT) Received: from gw.itfs.nsk.su (gw.itfs.nsk.su [193.124.36.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA09945 for ; Sat, 16 Aug 1997 23:18:11 -0700 (PDT) Received: from itfs.UUCP (root@localhost) by gw.itfs.nsk.su (8.6.12/8.6.12) with UUCP id NAA26775 for current@freebsd.org; Sun, 17 Aug 1997 13:18:07 +0700 Received: by itfs.nsk.su; Sun, 17 Aug 97 13:18:31 +0700 (NST) Received: (from daemon@localhost) by news.itfs.nsk.su (8.7.5/8.6.12) id NAA09497; Sun, 17 Aug 1997 13:15:26 +0700 (NSD) From: nnd@itfs.nsk.su To: current@freebsd.org Subject: Re: Make and SMP - what can be done ? Date: 17 Aug 1997 06:15:24 GMT Message-ID: <5t64ts$7ae@news.itfs.nsk.su> References: <199708130432.VAA06415@silvia.HIP.Berkeley.EDU> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is a report of my experiments in "parallel" world making. Let's start from the end ;-) 1) This was done with standard /usr/src/Makefile # time make buildworld >& bw1.out 10842.7u 5987.9s 4:31:58.43 103.1% 360+502k 36885+26932io 2133pf+0w ^^^^^^^^^^^^^^^^^ 2) And this was done with my patches to /usr/src/bin/make, /usr/src/Makefile and /usr/src/games/boggle/Makefile (see below) # time make -dmj -j12 buildworld >& bwj.out 11880.6u 5732.4s 3:10:37.60 153.9% 454+556k 38401+44577io 2254pf+0w ^^^^^^^^^^^^^^^^^ Both makes was on the same system (FreeBSD-3.0 as of 970808, SMP kernel on two P-133 Gateway GA-586DX m/b with 128M EDO memory and /usr/{src,obj} both on ccd0 (two IBM DORS-32160W)). What have I done ? Current buildworld structure is not very suitable for "parallel" making ;-( especially in "make depend" and "make all install ..." cases. So I take an easy path to avoid "parallelism" in this steps while using it in "make all" parts. 1) I've patched /usr/bin/make in such a way that -B flag (compatible mode) will be propagated to "nested" make's (see make.patch below); 2) I've change /usr/src/Makefile so that all 'depend' parts was done in "compatible mode" and all 'all install clean cleandepend' parts splits to 'all' (which can be made "in parallel") and 'install clean cleandepend' which again was done in "compatible mode" (see Makefile.patch below); 3) I've patched /usr/src/games/boggle/Makefile which leads to error in 'make -j12 all" case and is incorrect independently of any "parallell making" (see my PR bin/4314 for this). If you use SMP FreeBSD and build world often you can try to speed-up this task in ~1.49 times :-). After that you can speend some time on Makefile's and mk-files studying and make FreeBSD's buildworld structure fully "parallel"-safe ! ;-) N.Dudorov make.patch================================================= diff -ruN src/usr.bin/make/main.c src/usr.bin/make-patched/main.c --- src/usr.bin/make/main.c Fri Aug 15 17:59:11 1997 +++ src/usr.bin/make-patched/main.c Fri Aug 15 18:07:14 1997 @@ -190,6 +190,7 @@ break; case 'B': compatMake = TRUE; + Var_Append(MAKEFLAGS, "-B", VAR_GLOBAL); break; #ifdef REMOTE case 'L': Makefile.patch============================================= --- src/Makefile Sat Aug 16 20:17:41 1997 +++ src/Makefile.MY Sat Aug 16 20:17:34 1997 @@ -216,8 +216,9 @@ @echo "--------------------------------------------------------------" mkdir -p ${WORLDTMP}/usr/bin cd ${.CURDIR}/usr.bin/make && \ - ${IBMAKE} -I${.CURDIR}/share/mk ${OBJDIR} clean cleandepend depend && \ - ${IBMAKE} -I${.CURDIR}/share/mk ${MK_FLAGS} all install clean cleandepend + ${IBMAKE} -I${.CURDIR}/share/mk ${OBJDIR} -B clean cleandepend depend && \ + ${IBMAKE} -I${.CURDIR}/share/mk ${MK_FLAGS} all && \ + ${IBMAKE} -I${.CURDIR}/share/mk ${MK_FLAGS} -B install clean cleandepend @echo @echo "--------------------------------------------------------------" @echo " Making hierarchy" @@ -251,7 +252,7 @@ @echo "--------------------------------------------------------------" @echo " Rebuilding /usr/include" @echo "--------------------------------------------------------------" - cd ${.CURDIR} && ${BMAKE} includes + cd ${.CURDIR} && ${BMAKE} -B includes @echo @echo "--------------------------------------------------------------" @echo " Rebuilding tools needed to build the libraries" @@ -271,7 +272,7 @@ @echo "--------------------------------------------------------------" @echo " Rebuilding dependencies" @echo "--------------------------------------------------------------" - cd ${.CURDIR} && ${XMAKE} depend + cd ${.CURDIR} && ${XMAKE} -B depend @echo @echo "--------------------------------------------------------------" @echo " Building everything.." @@ -413,12 +414,15 @@ cd ${.CURDIR}/include && find -dx . | cpio -dump ${DESTDIR}/usr/include cd ${.CURDIR}/include && make symlinks .endif - cd ${.CURDIR}/usr.bin/make && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} - cd ${.CURDIR}/usr.bin/xinstall && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} - cd ${.CURDIR}/usr.bin/lex && ${MAKE} bootstrap && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} -DNOLIB all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/make && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/xinstall && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/lex && ${MAKE} bootstrap && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} -DNOLIB all && \ + ${MAKE} ${MK_FLAGS} -DNOLIB -B install ${CLEANDIR} ${OBJDIR} # # include-tools - generally the same as 'bootstrap', except that it's for @@ -429,8 +433,9 @@ # on cleaned away headers in ${WORLDTMP}. # include-tools: - cd ${.CURDIR}/usr.bin/rpcgen && ${MAKE} cleandepend depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/rpcgen && ${MAKE} -B cleandepend depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} # # includes - possibly generate and install the include files. @@ -499,8 +504,9 @@ usr.bin/nm \ usr.bin/ranlib \ usr.bin/uudecode - cd ${.CURDIR}/$d && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/$d && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endfor # @@ -508,44 +514,54 @@ # libraries: .if exists(lib/csu/i386) - cd ${.CURDIR}/lib/csu/i386 && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/lib/csu/i386 && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(lib/libcompat) - cd ${.CURDIR}/lib/libcompat && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/lib/libcompat && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(lib/libncurses) - cd ${.CURDIR}/lib/libncurses && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/lib/libncurses && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(lib/libtermcap) - cd ${.CURDIR}/lib/libtermcap && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/lib/libtermcap && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(gnu) - cd ${.CURDIR}/gnu/lib && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/gnu/lib && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(secure) && !defined(NOCRYPT) && !defined(NOSECURE) - cd ${.CURDIR}/secure/lib && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/secure/lib && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(lib) - cd ${.CURDIR}/lib && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/lib && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(usr.bin/lex/lib) - cd ${.CURDIR}/usr.bin/lex/lib && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/lex/lib && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(eBones) && !defined(NOCRYPT) && defined(MAKE_EBONES) - cd ${.CURDIR}/eBones/lib && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/eBones/lib && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif .if exists(usr.sbin/pcvt/keycap) - cd ${.CURDIR}/usr.sbin/pcvt/keycap && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.sbin/pcvt/keycap && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endif # @@ -615,8 +631,9 @@ usr.sbin/chown \ usr.sbin/mtree \ usr.sbin/zic - cd ${.CURDIR}/$d && ${MAKE} depend && \ - ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/$d && ${MAKE} -B depend && \ + ${MAKE} ${MK_FLAGS} all && \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} .endfor .include